Re: [IronPython] How do I test if a variable is defined?
Tony Meyer wrote: On Wed, Nov 5, 2008 at 8:06 AM, Michael Foord [EMAIL PROTECTED] wrote: Marty Nelson wrote: How do I test in Iron Python (in python) if a variable is defined? [...] try: name except NameError: # variable 'name' is not defined If you're running some sort of checker (pylint, pychecker) over this, you might get a warning about the name line not doing anything. To avoid that, you'll sometimes see a variant like this: try: unused = name except NameError: # variable 'name' is not defined. Except then PyLint will complain that 'unused' is unused, plus you code no longer accurately conveys its intent. I prefer to filter (or disable) that particular warning rather than change the code. Michael Cheers, Tony ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Ironclad problem, with which someone here may be able to help
Hi all
While running the numpy tests, I've come across a situation which, to
the best of my knowledge, is simply impossible. I'm hoping that one of
the local .NET gurus will be able to tell me what I'm missing, or point
me somewhere I can get more insight.
The 4 methods involved are as follows:
---
public int GetThreadId()
{
return Thread.CurrentThread.ManagedThreadId;
}
public void WriteFlush(string info)
{
Console.WriteLine(info);
Console.Out.Flush();
}
public void EnsureGIL()
{
Monitor.Enter(this.dispatcherLock);
this.WriteFlush(String.Format(
EnsureGIL ({1}) {0}, this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
}
public void ReleaseGIL()
{
this.WriteFlush(String.Format(
ReleaseGIL ({1}) {0}\n, this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
Monitor.Exit(this.dispatcherLock);
}
---
...and they can, and do, occasionally produce output as follows:
---
EnsureGIL (443) 2
EnsureGIL (443) 1 - omg, wtf, bbq, etc.
ReleaseGIL (443) 2
EnsureGIL (443) 2
ReleaseGIL (443) 1
ReleaseGIL (443) 2
---
When this happens, the process continues happily for a short time and
then falls over in a later call to ReleaseGIL (after successfully
calling it several times). The error is Object synchronization method
was called from an unsynchronized block of code, which I understand to
mean you can't release this lock because you don't hold it.
It doesn't happen very often, but I can usually reproduce it by running
test_multiarray.TestFromToFile.test_malformed a few hundred times. It
may be relevant to note that thread 2 is the GC thread, and thread 1 is
the main thread. I have considered the following possibilities:
(1) That I'm locking on the wrong object. I believe that isn't the case,
because it's constructed only once, as a new Object() (ie, a reference
type), and is only subsequently used for locking; and, because it keeps
the same ipy id throughout.
(2) That Monitor.Enter occasionally allows two different threads to
acquire the same lock. I consider this extremely unlikely, because...
well, how many multithreaded .NET apps already exist? If Monitor really
were broken, I think we'd probably know about it by now.
(3) That calling Flush() on a SyncTextWriter (the type of Console.Out)
doesn't actually do anything, and the output is somehow wrongly ordered
(although I can't imagine how this could actually be: if the locking is
really working, then my console writes are strictly sequential). I don't
have access to the code, so I have no idea how it's implemented, but
even if this is the case it doesn't help much with the fundamental
problem (the synchronisation error which follows).
Apart from the above, I'm out of ideas. Can anyone suggest what I've missed?
William
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Ironclad problem, with which someone here may be able to help
Incidentally, logging a Stopwatch timestamp in WriteFlush reveals that,
yes, the calls really are happening in the order they appear to be. So,
option (3) appears to be a red herring, and options (1) and (2) remain
unchanged.
William Reade wrote:
Hi all
While running the numpy tests, I've come across a situation which, to
the best of my knowledge, is simply impossible. I'm hoping that one of
the local .NET gurus will be able to tell me what I'm missing, or
point me somewhere I can get more insight.
The 4 methods involved are as follows:
---
public int GetThreadId()
{
return Thread.CurrentThread.ManagedThreadId;
}
public void WriteFlush(string info)
{
Console.WriteLine(info);
Console.Out.Flush();
}
public void EnsureGIL()
{
Monitor.Enter(this.dispatcherLock);
this.WriteFlush(String.Format(
EnsureGIL ({1}) {0}, this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
}
public void ReleaseGIL()
{
this.WriteFlush(String.Format(
ReleaseGIL ({1}) {0}\n, this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
Monitor.Exit(this.dispatcherLock);
}
---
...and they can, and do, occasionally produce output as follows:
---
EnsureGIL (443) 2
EnsureGIL (443) 1 - omg, wtf, bbq, etc.
ReleaseGIL (443) 2
EnsureGIL (443) 2
ReleaseGIL (443) 1
ReleaseGIL (443) 2
---
When this happens, the process continues happily for a short time and
then falls over in a later call to ReleaseGIL (after successfully
calling it several times). The error is Object synchronization
method was called from an unsynchronized block of code, which I
understand to mean you can't release this lock because you don't hold
it.
It doesn't happen very often, but I can usually reproduce it by
running test_multiarray.TestFromToFile.test_malformed a few hundred
times. It may be relevant to note that thread 2 is the GC thread, and
thread 1 is the main thread. I have considered the following
possibilities:
(1) That I'm locking on the wrong object. I believe that isn't the
case, because it's constructed only once, as a new Object() (ie, a
reference type), and is only subsequently used for locking; and,
because it keeps the same ipy id throughout.
(2) That Monitor.Enter occasionally allows two different threads to
acquire the same lock. I consider this extremely unlikely, because...
well, how many multithreaded .NET apps already exist? If Monitor
really were broken, I think we'd probably know about it by now.
(3) That calling Flush() on a SyncTextWriter (the type of Console.Out)
doesn't actually do anything, and the output is somehow wrongly
ordered (although I can't imagine how this could actually be: if the
locking is really working, then my console writes are strictly
sequential). I don't have access to the code, so I have no idea how
it's implemented, but even if this is the case it doesn't help much
with the fundamental problem (the synchronisation error which follows).
Apart from the above, I'm out of ideas. Can anyone suggest what I've
missed?
William
___
Users mailing list
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
Re: [IronPython] How do I test if a variable is defined?
Can't you just do.. 'variable_name' in locals() or 'variable_name' in dir() Regards, Ken On Nov 5, 2008, at 4:07 AM, Michael Foord wrote: Tony Meyer wrote: On Wed, Nov 5, 2008 at 8:06 AM, Michael Foord [EMAIL PROTECTED] wrote: Marty Nelson wrote: How do I test in Iron Python (in python) if a variable is defined? [...] try: name except NameError: # variable 'name' is not defined If you're running some sort of checker (pylint, pychecker) over this, you might get a warning about the name line not doing anything. To avoid that, you'll sometimes see a variant like this: try: unused = name except NameError: # variable 'name' is not defined. Except then PyLint will complain that 'unused' is unused, plus you code no longer accurately conveys its intent. I prefer to filter (or disable) that particular warning rather than change the code. Michael Cheers, Tony ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ ___ Users mailing list 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
Re: [IronPython] Ironclad problem, with which someone here may be able to help
So, the obvious question for me is whether or not you're using any
finalizers.
On Wed, Nov 5, 2008 at 5:57 AM, William Reade
[EMAIL PROTECTED]wrote:
Hi all
While running the numpy tests, I've come across a situation which, to the
best of my knowledge, is simply impossible. I'm hoping that one of the local
.NET gurus will be able to tell me what I'm missing, or point me somewhere I
can get more insight.
The 4 methods involved are as follows:
---
public int GetThreadId()
{
return Thread.CurrentThread.ManagedThreadId;
}
public void WriteFlush(string info)
{
Console.WriteLine(info);
Console.Out.Flush();
}
public void EnsureGIL()
{
Monitor.Enter(this.dispatcherLock);
this.WriteFlush(String.Format(
EnsureGIL ({1}) {0}, this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
}
public void ReleaseGIL()
{
this.WriteFlush(String.Format(
ReleaseGIL ({1}) {0}\n, this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
Monitor.Exit(this.dispatcherLock);
}
---
...and they can, and do, occasionally produce output as follows:
---
EnsureGIL (443) 2
EnsureGIL (443) 1 - omg, wtf, bbq, etc.
ReleaseGIL (443) 2
EnsureGIL (443) 2
ReleaseGIL (443) 1
ReleaseGIL (443) 2
---
When this happens, the process continues happily for a short time and then
falls over in a later call to ReleaseGIL (after successfully calling it
several times). The error is Object synchronization method was called from
an unsynchronized block of code, which I understand to mean you can't
release this lock because you don't hold it.
It doesn't happen very often, but I can usually reproduce it by running
test_multiarray.TestFromToFile.test_malformed a few hundred times. It may be
relevant to note that thread 2 is the GC thread, and thread 1 is the main
thread. I have considered the following possibilities:
(1) That I'm locking on the wrong object. I believe that isn't the case,
because it's constructed only once, as a new Object() (ie, a reference
type), and is only subsequently used for locking; and, because it keeps the
same ipy id throughout.
(2) That Monitor.Enter occasionally allows two different threads to acquire
the same lock. I consider this extremely unlikely, because... well, how many
multithreaded .NET apps already exist? If Monitor really were broken, I
think we'd probably know about it by now.
(3) That calling Flush() on a SyncTextWriter (the type of Console.Out)
doesn't actually do anything, and the output is somehow wrongly ordered
(although I can't imagine how this could actually be: if the locking is
really working, then my console writes are strictly sequential). I don't
have access to the code, so I have no idea how it's implemented, but even if
this is the case it doesn't help much with the fundamental problem (the
synchronisation error which follows).
Apart from the above, I'm out of ideas. Can anyone suggest what I've
missed?
William
___
Users mailing list
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
[IronPython] IronPython 2: Bug in Indexing (Blocker)
Hello Guys,
Discovered a bug in indexing Python objects in IronPython 2.
The following code:
class X(object):
def __setitem__(self, key, value):
print repr(key)
def f(a, b):
X()[a, b] = object()
f(1, 2)
f('one', 'two')
Produces the following exception:
Traceback (most recent call last):
File bugtest.py, line 9, in bugtest.py
File bugtest.py, line 6, in f
TypeError: Specified cast is not valid.
It looks like IronPython has a call site that is now expecting integers
the second time round.
Switching to using explicit tuples for indexing works around the problem:
X()[(a, b)] = object()
However this kind of indexing is an *extremely* common way to use our
spreadsheet API from user code, so we couldn't release with this bug in
place.
(Doing the indexing outside of the function also avoids the problem
interestingly enough.)
All the best,
Michael Foord
--
Michael Foord
Senior Software Engineer, Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372
Try out Resolver One! http://www.resolversystems.com/get-it/
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@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Ironclad problem, with which someone here may be able to help
...or, for that matter, any __del__ methods from within Python -- which
ultimately are handled by finalization.
On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher [EMAIL PROTECTED]wrote:
So, the obvious question for me is whether or not you're using any
finalizers.
On Wed, Nov 5, 2008 at 5:57 AM, William Reade [EMAIL PROTECTED]
wrote:
Hi all
While running the numpy tests, I've come across a situation which, to the
best of my knowledge, is simply impossible. I'm hoping that one of the local
.NET gurus will be able to tell me what I'm missing, or point me somewhere I
can get more insight.
The 4 methods involved are as follows:
---
public int GetThreadId()
{
return Thread.CurrentThread.ManagedThreadId;
}
public void WriteFlush(string info)
{
Console.WriteLine(info);
Console.Out.Flush();
}
public void EnsureGIL()
{
Monitor.Enter(this.dispatcherLock);
this.WriteFlush(String.Format(
EnsureGIL ({1}) {0}, this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
}
public void ReleaseGIL()
{
this.WriteFlush(String.Format(
ReleaseGIL ({1}) {0}\n, this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
Monitor.Exit(this.dispatcherLock);
}
---
...and they can, and do, occasionally produce output as follows:
---
EnsureGIL (443) 2
EnsureGIL (443) 1 - omg, wtf, bbq, etc.
ReleaseGIL (443) 2
EnsureGIL (443) 2
ReleaseGIL (443) 1
ReleaseGIL (443) 2
---
When this happens, the process continues happily for a short time and then
falls over in a later call to ReleaseGIL (after successfully calling it
several times). The error is Object synchronization method was called from
an unsynchronized block of code, which I understand to mean you can't
release this lock because you don't hold it.
It doesn't happen very often, but I can usually reproduce it by running
test_multiarray.TestFromToFile.test_malformed a few hundred times. It may be
relevant to note that thread 2 is the GC thread, and thread 1 is the main
thread. I have considered the following possibilities:
(1) That I'm locking on the wrong object. I believe that isn't the case,
because it's constructed only once, as a new Object() (ie, a reference
type), and is only subsequently used for locking; and, because it keeps the
same ipy id throughout.
(2) That Monitor.Enter occasionally allows two different threads to
acquire the same lock. I consider this extremely unlikely, because... well,
how many multithreaded .NET apps already exist? If Monitor really were
broken, I think we'd probably know about it by now.
(3) That calling Flush() on a SyncTextWriter (the type of Console.Out)
doesn't actually do anything, and the output is somehow wrongly ordered
(although I can't imagine how this could actually be: if the locking is
really working, then my console writes are strictly sequential). I don't
have access to the code, so I have no idea how it's implemented, but even if
this is the case it doesn't help much with the fundamental problem (the
synchronisation error which follows).
Apart from the above, I'm out of ideas. Can anyone suggest what I've
missed?
William
___
Users mailing list
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
Re: [IronPython] Ironclad problem, with which someone here may be able to help
Hi Curt
I am indeed; that's how I know thread 2 is the GC thread. Is locking
during GC forbidden?
William
Curt Hagenlocher wrote:
...or, for that matter, any __del__ methods from within Python --
which ultimately are handled by finalization.
On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
So, the obvious question for me is whether or not you're using any
finalizers.
On Wed, Nov 5, 2008 at 5:57 AM, William Reade
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote:
Hi all
While running the numpy tests, I've come across a situation
which, to the best of my knowledge, is simply impossible. I'm
hoping that one of the local .NET gurus will be able to tell
me what I'm missing, or point me somewhere I can get more insight.
The 4 methods involved are as follows:
---
public int GetThreadId()
{
return Thread.CurrentThread.ManagedThreadId;
}
public void WriteFlush(string info)
{
Console.WriteLine(info);
Console.Out.Flush();
}
public void EnsureGIL()
{
Monitor.Enter(this.dispatcherLock);
this.WriteFlush(String.Format(
EnsureGIL ({1}) {0}, this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
}
public void ReleaseGIL()
{
this.WriteFlush(String.Format(
ReleaseGIL ({1}) {0}\n, this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
Monitor.Exit(this.dispatcherLock);
}
---
...and they can, and do, occasionally produce output as follows:
---
EnsureGIL (443) 2
EnsureGIL (443) 1 - omg, wtf, bbq, etc.
ReleaseGIL (443) 2
EnsureGIL (443) 2
ReleaseGIL (443) 1
ReleaseGIL (443) 2
---
When this happens, the process continues happily for a short
time and then falls over in a later call to ReleaseGIL (after
successfully calling it several times). The error is Object
synchronization method was called from an unsynchronized block
of code, which I understand to mean you can't release this
lock because you don't hold it.
It doesn't happen very often, but I can usually reproduce it
by running test_multiarray.TestFromToFile.test_malformed a few
hundred times. It may be relevant to note that thread 2 is the
GC thread, and thread 1 is the main thread. I have considered
the following possibilities:
(1) That I'm locking on the wrong object. I believe that isn't
the case, because it's constructed only once, as a new
Object() (ie, a reference type), and is only subsequently
used for locking; and, because it keeps the same ipy id
throughout.
(2) That Monitor.Enter occasionally allows two different
threads to acquire the same lock. I consider this extremely
unlikely, because... well, how many multithreaded .NET apps
already exist? If Monitor really were broken, I think we'd
probably know about it by now.
(3) That calling Flush() on a SyncTextWriter (the type of
Console.Out) doesn't actually do anything, and the output is
somehow wrongly ordered (although I can't imagine how this
could actually be: if the locking is really working, then my
console writes are strictly sequential). I don't have access
to the code, so I have no idea how it's implemented, but even
if this is the case it doesn't help much with the fundamental
problem (the synchronisation error which follows).
Apart from the above, I'm out of ideas. Can anyone suggest
what I've missed?
William
___
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
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Ironclad problem, with which someone here may be able to help
Locking during finalization is often considered to be a bad idea. In
particular, locking without a timeout introduces the possibility that you
will hang the finalization thread, preventing further objects from being
finalized. But clearly, that's not what's happening here.
Other questions that probably don't matter but might be interesting to know:
Can we assume that the finalization thread isn't the first place where this
lock is required? That your log starts somewhere in the middle?
Is this under x86 or x64 or both?
Are you creating any additional AppDomains in the process?
On Wed, Nov 5, 2008 at 10:15 AM, William Reade
[EMAIL PROTECTED]wrote:
Hi Curt
I am indeed; that's how I know thread 2 is the GC thread. Is locking during
GC forbidden?
William
Curt Hagenlocher wrote:
...or, for that matter, any __del__ methods from within Python -- which
ultimately are handled by finalization.
On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher [EMAIL PROTECTED]mailto:
[EMAIL PROTECTED] wrote:
So, the obvious question for me is whether or not you're using any
finalizers.
On Wed, Nov 5, 2008 at 5:57 AM, William Reade
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote:
Hi all
While running the numpy tests, I've come across a situation
which, to the best of my knowledge, is simply impossible. I'm
hoping that one of the local .NET gurus will be able to tell
me what I'm missing, or point me somewhere I can get more insight.
The 4 methods involved are as follows:
---
public int GetThreadId()
{
return Thread.CurrentThread.ManagedThreadId;
}
public void WriteFlush(string info)
{
Console.WriteLine(info);
Console.Out.Flush();
}
public void EnsureGIL()
{
Monitor.Enter(this.dispatcherLock);
this.WriteFlush(String.Format(
EnsureGIL ({1}) {0}, this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
}
public void ReleaseGIL()
{
this.WriteFlush(String.Format(
ReleaseGIL ({1}) {0}\n, this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
Monitor.Exit(this.dispatcherLock);
}
---
...and they can, and do, occasionally produce output as follows:
---
EnsureGIL (443) 2
EnsureGIL (443) 1 - omg, wtf, bbq, etc.
ReleaseGIL (443) 2
EnsureGIL (443) 2
ReleaseGIL (443) 1
ReleaseGIL (443) 2
---
When this happens, the process continues happily for a short
time and then falls over in a later call to ReleaseGIL (after
successfully calling it several times). The error is Object
synchronization method was called from an unsynchronized block
of code, which I understand to mean you can't release this
lock because you don't hold it.
It doesn't happen very often, but I can usually reproduce it
by running test_multiarray.TestFromToFile.test_malformed a few
hundred times. It may be relevant to note that thread 2 is the
GC thread, and thread 1 is the main thread. I have considered
the following possibilities:
(1) That I'm locking on the wrong object. I believe that isn't
the case, because it's constructed only once, as a new
Object() (ie, a reference type), and is only subsequently
used for locking; and, because it keeps the same ipy id
throughout.
(2) That Monitor.Enter occasionally allows two different
threads to acquire the same lock. I consider this extremely
unlikely, because... well, how many multithreaded .NET apps
already exist? If Monitor really were broken, I think we'd
probably know about it by now.
(3) That calling Flush() on a SyncTextWriter (the type of
Console.Out) doesn't actually do anything, and the output is
somehow wrongly ordered (although I can't imagine how this
could actually be: if the locking is really working, then my
console writes are strictly sequential). I don't have access
to the code, so I have no idea how it's implemented, but even
if this is the case it doesn't help much with the fundamental
problem (the synchronisation error which follows).
Apart from the above, I'm out of ideas. Can anyone suggest
what I've missed?
William
___
Users mailing list
Users@lists.ironpython.com mailto:Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Ironclad problem, with which someone here may be able to help
The log starts in the middle (after many lock/unlocks, some from each
thread); I'm running on x86; and I have no additional AppDomains.
I don't think it would be safe for me to entirely avoid locking during
finalization, but I could probably cut it down to a quick lock, on a
separate object, to enqueue pointers for cleanup and deallocation on the
main thread. However, I'm reluctant to do that until I'm sure that the
problem is specifically related to GC, otherwise it'll just come back as
soon as anyone tries any serious multithreading :).
Curt Hagenlocher wrote:
Locking during finalization is often considered to be a bad idea. In
particular, locking without a timeout introduces the possibility that
you will hang the finalization thread, preventing further objects from
being finalized. But clearly, that's not what's happening here.
Other questions that probably don't matter but might be interesting to
know:
Can we assume that the finalization thread isn't the first place where
this lock is required? That your log starts somewhere in the middle?
Is this under x86 or x64 or both?
Are you creating any additional AppDomains in the process?
On Wed, Nov 5, 2008 at 10:15 AM, William Reade
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Hi Curt
I am indeed; that's how I know thread 2 is the GC thread. Is
locking during GC forbidden?
William
Curt Hagenlocher wrote:
...or, for that matter, any __del__ methods from within Python
-- which ultimately are handled by finalization.
On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote:
So, the obvious question for me is whether or not you're
using any
finalizers.
On Wed, Nov 5, 2008 at 5:57 AM, William Reade
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
wrote:
Hi all
While running the numpy tests, I've come across a situation
which, to the best of my knowledge, is simply
impossible. I'm
hoping that one of the local .NET gurus will be able to
tell
me what I'm missing, or point me somewhere I can get
more insight.
The 4 methods involved are as follows:
---
public int GetThreadId()
{
return Thread.CurrentThread.ManagedThreadId;
}
public void WriteFlush(string info)
{
Console.WriteLine(info);
Console.Out.Flush();
}
public void EnsureGIL()
{
Monitor.Enter(this.dispatcherLock);
this.WriteFlush(String.Format(
EnsureGIL ({1}) {0}, this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
}
public void ReleaseGIL()
{
this.WriteFlush(String.Format(
ReleaseGIL ({1}) {0}\n, this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
Monitor.Exit(this.dispatcherLock);
}
---
...and they can, and do, occasionally produce output as
follows:
---
EnsureGIL (443) 2
EnsureGIL (443) 1 - omg, wtf, bbq, etc.
ReleaseGIL (443) 2
EnsureGIL (443) 2
ReleaseGIL (443) 1
ReleaseGIL (443) 2
---
When this happens, the process continues happily for a
short
time and then falls over in a later call to ReleaseGIL
(after
successfully calling it several times). The error is
Object
synchronization method was called from an
unsynchronized block
of code, which I understand to mean you can't release
this
lock because you don't hold it.
It doesn't happen very often, but I can usually
reproduce it
by running
test_multiarray.TestFromToFile.test_malformed a few
hundred times. It may be relevant to note that thread 2
is the
GC thread, and thread 1 is the main thread. I have
considered
the following possibilities:
(1) That I'm locking on the wrong object. I believe
that isn't
the case, because it's constructed only once, as a new
Re: [IronPython] IronPython 2: Bug in Indexing (Blocker)
Thanks for the report. I've opened CodePlex bug #19350 to track this
(http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19350).
I believe the fix is actually pretty simple and we'll discuss whether we'll
take it for 2.0 final at our Friday team meeting. If you want to try out the
fix either to unblock yourself or just see if there's other issues lurking
behind it you can do this change:
return new MetaObject[] {
arguments[0],
new MetaObject(
Ast.Call(
typeof(PythonOps).GetMethod(MakeTuple),
Ast.NewArrayInit(typeof(object), tupleArgs)
),
- Restrictions.Empty
+ Restrictions.Combine(arguments)
),
arguments[arguments.Length-1]
};
If you just search for return new MetaObject[] in
PythonProtocol.Operations.cs you'll get to the right spot. There's a 2nd spot
about 20 lines later for the getter case which has the same issue fix.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Wednesday, November 05, 2008 8:03 AM
To: Discussion of IronPython
Subject: [IronPython] IronPython 2: Bug in Indexing (Blocker)
Hello Guys,
Discovered a bug in indexing Python objects in IronPython 2.
The following code:
class X(object):
def __setitem__(self, key, value):
print repr(key)
def f(a, b):
X()[a, b] = object()
f(1, 2)
f('one', 'two')
Produces the following exception:
Traceback (most recent call last):
File bugtest.py, line 9, in bugtest.py
File bugtest.py, line 6, in f
TypeError: Specified cast is not valid.
It looks like IronPython has a call site that is now expecting integers
the second time round.
Switching to using explicit tuples for indexing works around the problem:
X()[(a, b)] = object()
However this kind of indexing is an *extremely* common way to use our
spreadsheet API from user code, so we couldn't release with this bug in
place.
(Doing the indexing outside of the function also avoids the problem
interestingly enough.)
All the best,
Michael Foord
--
Michael Foord
Senior Software Engineer, Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372
Try out Resolver One! http://www.resolversystems.com/get-it/
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@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
Re: [IronPython] How do I test if a variable is defined?
That worked great, thanks. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Miller Sent: Wednesday, November 05, 2008 7:46 AM To: Discussion of IronPython Subject: Re: [IronPython] How do I test if a variable is defined? Can't you just do.. 'variable_name' in locals() or 'variable_name' in dir() Regards, Ken On Nov 5, 2008, at 4:07 AM, Michael Foord wrote: Tony Meyer wrote: On Wed, Nov 5, 2008 at 8:06 AM, Michael Foord [EMAIL PROTECTED] wrote: Marty Nelson wrote: How do I test in Iron Python (in python) if a variable is defined? [...] try: name except NameError: # variable 'name' is not defined If you're running some sort of checker (pylint, pychecker) over this, you might get a warning about the name line not doing anything. To avoid that, you'll sometimes see a variant like this: try: unused = name except NameError: # variable 'name' is not defined. Except then PyLint will complain that 'unused' is unused, plus you code no longer accurately conveys its intent. I prefer to filter (or disable) that particular warning rather than change the code. Michael Cheers, Tony ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com === Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto.___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Extension methods in python
Is there the equivalent of extension method in python? I want to put a variable into the script scope and create extension methods for it. Does this make sense and is it possible? === Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto.___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Extension methods in python
If it's an object defined in Python you can usually attach methods directly to the object or it's Python type. But otherwise we have no support for automatically adding .NET extension methods to existing types currently. It is a frequent request and we will probably get to it at some point. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marty Nelson Sent: Wednesday, November 05, 2008 1:50 PM To: Discussion of IronPython Subject: [IronPython] Extension methods in python Is there the equivalent of extension method in python? I want to put a variable into the script scope and create extension methods for it. Does this make sense and is it possible? === Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Extension methods in python
If it's an object defined in Python you can usually attach methods directly to the object or it's Python type. So how would this work? Let's say I had injested a variable into the scope from c#: scope.SetVarialble(widget, hello world) Can I do something in python so that I can then type: print widget.ToFoo() print widget.ToBar() That would theoretically output: hello worldFoo hello worldBar But otherwise we have no support for automatically adding .NET extension methods to existing types currently. It is a frequent request and we will probably get to it at some point. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marty Nelson Sent: Wednesday, November 05, 2008 1:50 PM To: Discussion of IronPython Subject: [IronPython] Extension methods in python Is there the equivalent of extension method in python? I want to put a variable into the script scope and create extension methods for it. Does this make sense and is it possible? === Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto.___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Extension methods in python
In this case widget is the string hello world so it won't work. If it was instead something like: class x(object): pass a = x() ... Then in C# you could do: widget = scope.GetVariable(a) then you could do engine.Operations.SetMember(widget, foo, () = hello world); and then back in Python: a.foo() prints hello world. Probably not what you're looking for but it's all that is there today :( From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marty Nelson Sent: Wednesday, November 05, 2008 3:59 PM To: Discussion of IronPython Subject: Re: [IronPython] Extension methods in python If it's an object defined in Python you can usually attach methods directly to the object or it's Python type. So how would this work? Let's say I had injested a variable into the scope from c#: scope.SetVarialble(widget, hello world) Can I do something in python so that I can then type: print widget.ToFoo() print widget.ToBar() That would theoretically output: hello worldFoo hello worldBar But otherwise we have no support for automatically adding .NET extension methods to existing types currently. It is a frequent request and we will probably get to it at some point. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marty Nelson Sent: Wednesday, November 05, 2008 1:50 PM To: Discussion of IronPython Subject: [IronPython] Extension methods in python Is there the equivalent of extension method in python? I want to put a variable into the script scope and create extension methods for it. Does this make sense and is it possible? === Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] _WindowsError and errno
Hi IronPython team, Is there any reason why _WindowsError sets errno to 22 in all cases? There's some code in Django that checks if e.errno = errno.EEXIST. The exception that gets thrown by IronPython has winerror = 17 (and the message string says [Errno 17]...!), but e.errno is 22 (EINVAL). Fixing #19310 would avoid the problem in this case (it's the same chunk of code), but I'm curious in general what the reason is. - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] _WindowsError and errno
It's because when I initially looked at WindowsError it sure seemed like 22 was the error code that was always used :). If you do: for i in xrange(100): print WindowsError(i, i).errno on CPython You'll see a large amount of the errno's are set to 22 (including 0 and 1) - apparently I didn't test enough combinations initially :( I think we have another bug on this somewhere too and we just need to spend the time to get the mapping right. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Hardy Sent: Wednesday, November 05, 2008 4:43 PM To: Discussion of IronPython Subject: [IronPython] _WindowsError and errno Hi IronPython team, Is there any reason why _WindowsError sets errno to 22 in all cases? There's some code in Django that checks if e.errno = errno.EEXIST. The exception that gets thrown by IronPython has winerror = 17 (and the message string says [Errno 17]...!), but e.errno is 22 (EINVAL). Fixing #19310 would avoid the problem in this case (it's the same chunk of code), but I'm curious in general what the reason is. - Jeff ___ Users mailing list 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
Re: [IronPython] Ironclad problem, with which someone here may be able to help
I would suggest getting a snap shot of the call stacks when this is happening
if that's possible. I can't pin anything down but I wonder if you could have
an STA object or something that otherwise requires message pumping. That
message pumping could happen while you're doing a Monitor.Enter call. If that
was happening maybe there is some subtle CLR bug or a surprise feature? It is
surprising that Monitor.Enter can go re-entrant but it can...
So it'd be interesting to get thread snapshots and see if
EnsureGIL (443) 2
EnsureGIL (443) 1 - omg, wtf, bbq, etc.
Could be happening because Thread 1 experiences contention, blocks and pumps
messages, causing the finalizer thread (2) to run, the lock is acquired and ...
?
Only other thing I could think of is does it repro on other machines? Maybe
it's a hardware bug as unlikely as that seems?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William Reade
Sent: Wednesday, November 05, 2008 10:01 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Ironclad problem, with which someone here may be able
to help
The log starts in the middle (after many lock/unlocks, some from each
thread); I'm running on x86; and I have no additional AppDomains.
I don't think it would be safe for me to entirely avoid locking during
finalization, but I could probably cut it down to a quick lock, on a
separate object, to enqueue pointers for cleanup and deallocation on the
main thread. However, I'm reluctant to do that until I'm sure that the
problem is specifically related to GC, otherwise it'll just come back as
soon as anyone tries any serious multithreading :).
Curt Hagenlocher wrote:
Locking during finalization is often considered to be a bad idea. In
particular, locking without a timeout introduces the possibility that
you will hang the finalization thread, preventing further objects from
being finalized. But clearly, that's not what's happening here.
Other questions that probably don't matter but might be interesting to
know:
Can we assume that the finalization thread isn't the first place where
this lock is required? That your log starts somewhere in the middle?
Is this under x86 or x64 or both?
Are you creating any additional AppDomains in the process?
On Wed, Nov 5, 2008 at 10:15 AM, William Reade
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Hi Curt
I am indeed; that's how I know thread 2 is the GC thread. Is
locking during GC forbidden?
William
Curt Hagenlocher wrote:
...or, for that matter, any __del__ methods from within Python
-- which ultimately are handled by finalization.
On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote:
So, the obvious question for me is whether or not you're
using any
finalizers.
On Wed, Nov 5, 2008 at 5:57 AM, William Reade
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
wrote:
Hi all
While running the numpy tests, I've come across a situation
which, to the best of my knowledge, is simply
impossible. I'm
hoping that one of the local .NET gurus will be able to
tell
me what I'm missing, or point me somewhere I can get
more insight.
The 4 methods involved are as follows:
---
public int GetThreadId()
{
return Thread.CurrentThread.ManagedThreadId;
}
public void WriteFlush(string info)
{
Console.WriteLine(info);
Console.Out.Flush();
}
public void EnsureGIL()
{
Monitor.Enter(this.dispatcherLock);
this.WriteFlush(String.Format(
EnsureGIL ({1}) {0}, this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
}
public void ReleaseGIL()
{
this.WriteFlush(String.Format(
ReleaseGIL ({1}) {0}\n, this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
Monitor.Exit(this.dispatcherLock);
}
---
...and they can, and do, occasionally produce output as
follows:
---
EnsureGIL (443) 2
EnsureGIL (443) 1 - omg,
