From hemanth at broadcom.com  Mon Apr  6 19:07:28 2015
From: hemanth at broadcom.com (Hemanth M B)
Date: Mon, 6 Apr 2015 17:07:28 +0000
Subject: [Ironpython-users] import error: scapy on ironpython (windows)
Message-ID: <650E8E7A30AA6E4697EAF063DB83FB88014049B4@SJEXCHMB05.corp.ad.broadcom.com>

Hi All,

I am facing problem to import scapy.all in ironpython shell. It is throwing an error mentioned below:

>>> from scapy.all import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\scapy\all.py", line 16, in <module>
  File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\scapy\arch\__init__.py", line 54, in <module>
AttributeError: 'module' object has no attribute 'uname'

Note:
I have installed scapy using command "ipy -X:Frames -m pip install scapy" and it got installed. As I verified with the scapy official website, one of the prerequisite is pywin32. At par to my knowledge ironpython doesn't support pywin32.

Help me to resolve.


Thanks and Regards,
Hemanth M B
@9010054054

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150406/d693abaf/attachment.html>

From hemanth at broadcom.com  Tue Apr  7 06:27:22 2015
From: hemanth at broadcom.com (Hemanth M B)
Date: Tue, 7 Apr 2015 04:27:22 +0000
Subject: [Ironpython-users] jumbo payload
Message-ID: <650E8E7A30AA6E4697EAF063DB83FB8801404A31@SJEXCHMB05.corp.ad.broadcom.com>


Hi all,

I was using scapy to send jumbo payloads in linux OS. Jumbo packets are nothing but the packet mtu size is more than normal 1500 bytes i.e., 1500 to 9014 bytes. Please let me know how to send jumbo payloads using ironpython.

Note:
Ironpython doesn't support scapy.
Scapy is a powerful interactive packet manipulation program. It is able to forge or decode packets of a wide number of protocols, send them on the wire, capture them, match requests and replies, and much more.

Thanks and Regards,
Hemanth M B
@9010054054

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150407/c64321d7/attachment.html>

From hemanth at broadcom.com  Wed Apr  8 16:49:10 2015
From: hemanth at broadcom.com (Hemanth M B)
Date: Wed, 8 Apr 2015 14:49:10 +0000
Subject: [Ironpython-users] usage of Async readline() method in ironpython
Message-ID: <650E8E7A30AA6E4697EAF063DB83FB8801404FCF@SJEXCHMB05.corp.ad.broadcom.com>

HI All,

I am using System.Diagnostics namespace to spawn a console application. I want use asyncronous read and syncronous write, since the application is interactive. I want to use BeginOutputreadline() method. But I don't know how to use in IronPython. Please help me with sample code. Also let me know if there is any other alternatives.

Note:
I used readline() method which hangs/freezes.


Thanks and Regards,
Hemanth M B

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150408/c695a86b/attachment.html>

From hemanth at broadcom.com  Thu Apr  9 06:58:17 2015
From: hemanth at broadcom.com (Hemanth M B)
Date: Thu, 9 Apr 2015 04:58:17 +0000
Subject: [Ironpython-users] Failing to read the standard output
Message-ID: <650E8E7A30AA6E4697EAF063DB83FB880140506F@SJEXCHMB05.corp.ad.broadcom.com>


Hi All,

I am using System.Diagnostics namespace to spawn a console application. I want use asynchronous read and synchronous write, since the application is interactive. If I use synchronous read as mentioned below code, I need to close the stream writer before reading to end. Please help me to make code interactive.

Working Code:

import System
from System.Diagnostics import *
targetDir = "C:\\Users\\Administrator\\Desktop\\AMD64"
p = Process()
p.StartInfo.WorkingDirectory = targetDir
p.StartInfo.FileName = "C:\\Users\\Administrator\\Desktop\\AMD64\\WinFWUpg.exe"
#p.StartInfo.Arguments = "/c WinFWUpg.exe"
p.StartInfo.UseShellExecute = False
p.StartInfo.CreateNoWindow = False
p.StartInfo.RedirectStandardInput = True
p.StartInfo.RedirectStandardOutput = True
p.StartInfo.RedirectStandardError = True
p.Start()
sw = p.StandardInput
sr = p.StandardOutput
se = p.StandardError
print "success"
sw.WriteLine("dir\n")
sw.WriteLine("dev 1\n")
sw.Flush()
sw.Close()
print sr.ReadToEnd()


Not Working code:

import System
from System.Diagnostics import *
targetDir = "C:\\Users\\Administrator\\Desktop\\AMD64"
p = Process()
p.StartInfo.WorkingDirectory = targetDir
p.StartInfo.FileName = "C:\\Users\\Administrator\\Desktop\\AMD64\\WinFWUpg.exe"
#p.StartInfo.Arguments = "/c WinFWUpg.exe"
p.StartInfo.UseShellExecute = False
p.StartInfo.CreateNoWindow = False
p.StartInfo.RedirectStandardInput = True
p.StartInfo.RedirectStandardOutput = True
p.StartInfo.RedirectStandardError = True
p.Start()
sw = p.StandardInput
sr = p.StandardOutput
se = p.StandardError
print "success"
sw.WriteLine("dir\n")
while True:
    outline = sr.ReadLine()   /// Hangs here
    if not outline == None:
        print outline
    else:
        break
sw.WriteLine("dev 1\n")
sw.Flush()
sw.Close()
print sr.ReadToEnd()


Thanks and Regards,
Hemanth M B

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150409/47cbb70c/attachment.html>

From sebasmagri at gmail.com  Wed Apr  8 15:04:08 2015
From: sebasmagri at gmail.com (=?UTF-8?B?U2ViYXN0acOhbiBNYWdyw60=?=)
Date: Wed, 8 Apr 2015 08:34:08 -0430
Subject: [Ironpython-users] AttributeError when using methods from a
	DirectShowLib Interface
Message-ID: <CADmKEd7WhgBOQM3oEK+fF9x3mLArmc1tzNUUh5T5_RwdpSm1QA@mail.gmail.com>

Hi!

I'm trying to use DirectShowLib for some basic media detection with the
`IMediaDet` interface. However, trying to use methods of the interface from
the instance throws `AttributeError` every time.

This is the script I'm using to test:

---
    import clr

    clr.AddReference('DirectShowLib')

    from DirectShowLib.DES import IMediaDet, DESError


    class Detector(IMediaDet):
        def __init__(self, *args, **kwargs):
            super(Detector, self).__init__(*args, **kwargs)


    mdet = Detector()

    print('Detector: {}\n'.format(mdet))
    print('Detector dir: {}\n'.format(dir(mdet)))
    print('Detector.put_Filename: {}\n'.format(mdet.put_Filename))
    print('Detector.put_Filename dir: {}\n'.format(dir(mdet.put_Filename)))
    print('Detector.put_Filename.Overloads: {}\n'.format(
        mdet.put_Filename.Overloads
    ))
    print('Detector.put_Filename.Overloads dir: {}\n'.format(
        dir(mdet.put_Filename.Overloads)
    ))
    print('Detector object is instance of IMediaDet: {}\n'.format(
        isinstance(mdet, IMediaDet)
    ))
    mdet.put_Filename('VID_20150207_133726.mp4')
---

And it prints the following information, finally throwing an error when I
try to use the method:

---
$ ipy -X:Debug -X:ShowClrExceptions -X:ExceptionDetail testdshow.py
Detector: <Detector object at 0x000000000000002B>

Detector dir: ['EnterBitmapGrabMode', 'Equals', 'GetBitmapBits',
'GetHashCode', 'GetSampleGrabber', 'GetType', 'MemberwiseClone',
'ReferenceEquals', 'ToString', 'WriteBitmapBits', '__class__',
'__delattr__', '__dict__', '__doc__', '__format__', '__getattribute__',
'__hash__', '__init__', '__module__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__',
'__subclasshook__', '__weakref__', 'get_CurrentStream', 'get_Filename',
'get_Filter', 'get_FrameRate', 'get_OutputStreams', 'get_StreamLength',
'get_StreamMediaType', 'get_StreamType', 'get_StreamTypeB',
'put_CurrentStream', 'put_Filename', 'put_Filter']

Detector.put_Filename: <built-in method put_Filename of Detector object at
0x000000000000002B>

Detector.put_Filename dir: ['DeclaringType', 'Equals', 'GetHashCode',
'GetType', 'MemberwiseClone', 'Overloads', 'ReferenceEquals', 'Targets',
'ToString', '__call__', '__class__', '__cmp__', '__delattr__', '__doc__',
'__format__', '__ge__', '__get__', '__getattribute__', '__gt__',
'__hash__', '__init__', '__le__', '__lt__', '__module__', '__name__',
'__new__', '__reduce__', '__reduce_ex__', '__repr__', '__self__',
'__setattr__', '__sizeof__', '__str__', '__subclasshook__']

Detector.put_Filename.Overloads: {'put_Filename(self: Object#IMediaDet_4$4,
newVal: str) -> int\r\n': <built-in method put_Filename of Detector object
at 0x000000000000002B>}

Detector.put_Filename.Overloads dir: ['Equals', 'Function', 'Functions',
'GetHashCode', 'GetOverload', 'GetTargetFunction', 'GetType', 'Item',
'MemberwiseClone', 'ReferenceEquals', 'Targets', 'ToString', '__class__',
'__delattr__', '__doc__', '__format__', '__getattribute__', '__getitem__',
'__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__',
'__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__']

Detector object is instance of IMediaDet: True

'Detector' object has no attribute 'put_Filename'
   at
IronPython.Runtime.Operations.PythonOps.MissingInvokeMethodException(Object
o, String name)
   at IronPython.NewTypes.System.Object#IMediaDet_4$4.put_Filename(String
newVal)
   at
Microsoft.Scripting.Interpreter.FuncCallInstruction`3.Run(InterpretedFrame
frame)
   at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame
frame)
   at Microsoft.Scripting.Interpreter.LightLambda.Run4[T0,T1,T2,T3,TRet](T0
arg0, T1 arg1, T2 arg2, T3 arg3)
   at
System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite
site, T0 arg0, T1 arg1, T2 arg2)
   at __main__$15.__main__(FunctionCode $functionCode) in testdshow.py:line
22
   at IronPython.Compiler.RuntimeScriptCode.InvokeTarget(Scope scope)
   at IronPython.Compiler.RuntimeScriptCode.Run(Scope scope)
   at IronPython.Hosting.PythonCommandLine.RunFileWorker(String fileName)
   at IronPython.Hosting.PythonCommandLine.RunFile(String fileName)
AttributeError: 'Detector' object has no attribute 'put_Filename'
CLR Exception:
    MissingMemberException
:
'Detector' object has no attribute 'put_Filename'
---

I suspect it could be something related with overloading.

Any hints on why it's not working?

Best Regards,

-- 
Sebasti?n Ram?rez Magr?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150408/df7149ea/attachment.html>

From tvinh at broadcom.com  Thu Apr  9 20:06:52 2015
From: tvinh at broadcom.com (Vinh Ton)
Date: Thu, 9 Apr 2015 18:06:52 +0000
Subject: [Ironpython-users] Example for using AppDomain
Message-ID: <A8744B73D4D1664F908F7BC00A278981194443@IRVEXCHMB15.corp.ad.broadcom.com>

Hi,

Can someone post an example for running IronPython in a separate AddDomain.

Thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150409/dd847433/attachment.html>

From sommerhoff at gmail.com  Mon Apr 13 07:39:13 2015
From: sommerhoff at gmail.com (Andres Sommerhoff)
Date: Mon, 13 Apr 2015 02:39:13 -0300
Subject: [Ironpython-users] Fwd: weakref random "SystemError" and
 "ValueError" exception (affecting _weakrefset.py and abc.py)
In-Reply-To: <CAO1Y6_UC98veY=q89Pda24y6rK093-5oTFJpYNCjuqgZ8nzd3Q@mail.gmail.com>
References: <CAO1Y6_UC98veY=q89Pda24y6rK093-5oTFJpYNCjuqgZ8nzd3Q@mail.gmail.com>
Message-ID: <CAO1Y6_WmeEm8Q_oPJ_Oh9LqpJqUnBt-9jVVjWyXz21uWDOg2-w@mail.gmail.com>

Dear IronPython gurus!

Hopping you can help me with a kind of ramdom bug (unexpected
SystemError and ValueError exception) in _weakrefset.py (it would be
great if you can replicate it by running my script below. Please let me
know).

The error is random, but I managed to reproduce it by running the
"ramdomly" ofending code 100.000 times inside a loop (Script attached).
Note that the test takes only a few seconds, and in my PC it throws
regularly between 5 to 30 exception for all those cycles). I see there are
other people suffering for the same, but without solution or workaround yet
(
https://mail.python.org/pipermail/ironpython-users/2014-November/017332.html
and https://github.com/IronLanguages/main/issues/1187)

In my case, weakref error was related with an intensive use of isinstance()
inside "Pulp" library (an optimization python library). *Just for your
reference*:* isintance() use internally a WeakSet as a cache for the class
types, which in turn use weakref (see ABCMeta.__instancecheck__() in the
standard file "abc.py"). *
In my test script I have isolated the problem to WeakSet only (I isolated
it to clean the bug from the "abc.py" and "Pulp" library stuff). The
exception happens inside *WeakSet.__contains__()* function (from
_weakrefset.py file). As stated, it happens randomly, but apparently only
related with a GC collect cycle into a memory "hungry" python script . I
ran the test script in two PCs with similar results: Windows 7 64bits and
Windows 7 32bits. Both using ipy.exe 32bit version 2.7.4 (2.7.0.40). The
.NET version is 4.0.30319.18444 (32-bit). The test script does:

   1. It simulate a "memory intensive" python code (creating a weakref
   object of 2kb to 12kb in each loop. If smaller, like 0.1kb objects, then
   the bug don't show up)
   2. It manually runs GC.collect() every 1.000 cycles (should collect
   those weakref objects)
   3. ... and it repeat (100.000 times) the following "offending" boolean
   test:

       test = item in WeakSetObject   *#<- Repeated 100.000 times. *
*                                      #-> it fails between 10 to 20 times
with an unexpected exception*

*NOTE 1:* The "item" is an object added to the WeakSet at the beginning of
the script, but "item" should not GC collected as it also keeps a normal
(not weak) reference alive.

*NOTE 2:* The boolean test should give always True, which is the case 99.9%
of the time. Less than 0.01%, the boolean test fails raising an exception
of the type "ValueError" *(Description:"Index was out of range") *or a bit
more frequent "SystemError" *(Description:"Handle is not initialized")*.
This happens 5 to 30 times in 100.000 test cycle (Seems very small, but it
is important enough to avoid a practical construction of a medium size
optimization problem with "Pulp" library).

Tracking down the error, the exception ValueError is raised in line 70 and
the exception "SystemError" in line 73 of "_weakrefset.py" .

    On "Lib\_weakrefset.py"
    35 :class WeakSet(object):
    ....
    68 :    def __contains__(self, item):
    69 :        try:
    **70*:           wr = ref(item)      # <- here is raised "ValueError"
Exception ("Index was out of range")
    71 :        except TypeError:
    72 :            return False
    **73*:       return wr in self.data  # <- here is raised "SystemError"
Exception ("Handle is not initialized")

Continuing after the exception, when executing the same boolean test again,
it works fine (same item, same WeakSetObject, same execution, local and
global context. Script was not started again!). I.e. if you catch the
exception and continue the execution, It is like as if the exception never
happened before (it's like a runtime lapsus!).

I believe to fix the source of the problem, Ironpython should trap or avoid
the error in weakref module itself (C# code). I don't know how... can
someone kindly help me to fix this?
Cheers,
Andres Sommerhoff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150413/de470068/attachment.html>
-------------- next part --------------
#
# file: testWeakSetError.py
#

#EXPLANATION ABOUT THE TEST SCRIPT:
#    This test script is somehow based in the way abc.py class handle 
#  a weakSet as a cache for speeding up the ABCMeta.__instancecheck__(),
#  which overrides the buildin isinstance(). The abc.py check the cache by 
#  testing "test=classX in WeakSetObjAsCache", which fails when 
#  the seldom exception is raised inside WeakSet.__contains__().

#    The boolean test is a simple "test = item in WeakSetObject" which performs 
#  as expected 99.9% of the time and the result is True. "item" is a 
#  normal (not weak) reference, so it should not be killed 
#  by gc.collection, and "item" was added to WeakSetObject before. This
#  boolean test is inside a loop that repeat the test 100.000 times. On every
#  cycle of the loop, is it also added a new instance of 
#  a big (RAM) object (just 2kb to 12kb each obj), which will be 
#  stay as a weakref inside the WeakSet. Every 1000 cycles a gc.collection()
#  is manually performed, which should clean some of this big objects. The 
#  error (exception) start to happen around cycle 12.000th (sometimes sooner).
#  The error consist in an untrapped exception of the type:
#       (ValueError) or (SystemError)
#  After 100.000 cycles I count around 10 or 20 errors. For a real python
#  application, that is enough frequent to stop the execution of a medium size
#  optimization problem (Pulp library make intensive use of "isinstance()", 
#  and what buildin function use WeakSet under the hook as a cache.) 
 
import gc, sys, traceback 
from _weakrefset import WeakSet

#Big Object -> takes 2 to 12kb of RAM!
class BigObjClass(object):
    def __init__(self,id):
        self.useRAM = str(id)*1000 # Less than <100 or bigger than >10000 no error is produced (not knowing why?) 

item       = BigObjClass(id="AA")
weakSetObj = WeakSet()
weakSetObj.add(item) # adding an item instance 

errorcount=0
for i in xrange(100000): #<- Do several loops until you get the error
    #Simulating ram intensive python script (it must be inside the loop, otherwise no error is expected)
    t = BigObjClass(id=i) # A new instance, takes 2 to 12kb of RAM!
    weakSetObj.add(t)  #<- Adding it to WeakSet. It is a weakref so the 2 to 12kb of RAM should be retrieved when gc.collect()
    
    #The boolean Test
    try:
        test = item in weakSetObj  #<- OFENDING CODE: THIS TEST IS WHERE SOMETIMES THE ERROR IS PRODUCED!!!
        assert test==True
    except Exception as e: 
        errorcount += 1
        (extype, exvalue, extraceback) = sys.exc_info()
        
        print "\n####################################################"
        print "Error in Loop",i,"coming from WeakSet.__contains__:"
        print type(e), e
        #print "------------- TRACEBACK -------------"
        traceback.print_exception(extype,exvalue,extraceback,limit=10,file=sys.stdout)
        print "####################################################\n"
    
    # Garbage Collection from time to time (necessary to get the error)
    if i%1000==0:  # If too small (i.e. <100) the error is not shown! If too big -> memoryout exception
        howmuch = gc.collect() #should collect the BigObjs created in the loop, but not "item" as it is normal referenced   
        print "loop",i, " doing gc.collect(): ",howmuch

print
print "In total:", errorcount, "errors in 100000 tests = %",  errorcount/100000.0*100      
print "End"        

From andy at agraham.demon.co.uk  Mon Apr 13 16:55:43 2015
From: andy at agraham.demon.co.uk (Andrew Graham)
Date: Mon, 13 Apr 2015 15:55:43 +0100
Subject: [Ironpython-users] Fwd: weakref random "SystemError" and
	"ValueError" exception (affecting _weakrefset.py and abc.py)
In-Reply-To: <CAO1Y6_WmeEm8Q_oPJ_Oh9LqpJqUnBt-9jVVjWyXz21uWDOg2-w@mail.gmail.com>
References: <CAO1Y6_UC98veY=q89Pda24y6rK093-5oTFJpYNCjuqgZ8nzd3Q@mail.gmail.com>
 <CAO1Y6_WmeEm8Q_oPJ_Oh9LqpJqUnBt-9jVVjWyXz21uWDOg2-w@mail.gmail.com>
Message-ID: <6A8B073CBC6345ECAB4C3B9FCBDE5ED0@AndyDesktop>

I confirm the same problem, except that it happens more often for me, about 50 to 60 times each time I run the test. 
It smells like some sort of ?unsynchronised acess by different threads to an object problem ?. 

One (very) hacky way round it until the real cause is established is to modify __contains__() in _weakrefset.py line 68 to retry until it gets a proper result

    def __contains__(self, item):
        while 1:
            try:
                try:
                    wr = ref(item)
                except TypeError:
                    return False
                return wr in self.data
            except Exception:
                pass

Regards

Andy Graham

From: Andres Sommerhoff 
Sent: Monday, April 13, 2015 6:39 AM
To: ironpython-users at python.org 
Subject: [Ironpython-users] Fwd: weakref random "SystemError" and "ValueError" exception (affecting _weakrefset.py and abc.py)

Dear IronPython gurus!

Hopping you can help me with a kind of ramdom bug (unexpected SystemError and ValueError exception) in _weakrefset.py (it would be great if you can replicate it by running my script below. Please let me know). 

The error is random, but I managed to reproduce it by running the "ramdomly" ofending code 100.000 times inside a loop (Script attached). Note that the test takes only a few seconds, and in my PC it throws regularly between 5 to 30 exception for all those cycles). I see there are other people suffering for the same, but without solution or workaround yet (https://mail.python.org/pipermail/ironpython-users/2014-November/017332.html and https://github.com/IronLanguages/main/issues/1187)
In my case, weakref error was related with an intensive use of isinstance() inside "Pulp" library (an optimization python library). Just for your reference: isintance() use internally a WeakSet as a cache for the class types, which in turn use weakref (see ABCMeta.__instancecheck__() in the standard file "abc.py"). 

In my test script I have isolated the problem to WeakSet only (I isolated it to clean the bug from the "abc.py" and "Pulp" library stuff). The exception happens inside WeakSet.__contains__() function (from _weakrefset.py file). As stated, it happens randomly, but apparently only related with a GC collect cycle into a memory "hungry" python script . I ran the test script in two PCs with similar results: Windows 7 64bits and Windows 7 32bits. Both using ipy.exe 32bit version 2.7.4 (2.7.0.40). The .NET version is 4.0.30319.18444 (32-bit). The test script does: 
  1.. It simulate a "memory intensive" python code (creating a weakref object of 2kb to 12kb in each loop. If smaller, like 0.1kb objects, then the bug don't show up) 
  2.. It manually runs GC.collect() every 1.000 cycles (should collect those weakref objects) 
  3.. ... and it repeat (100.000 times) the following "offending" boolean test:
       test = item in WeakSetObject  #<- Repeated 100.000 times. 
                                      #-> it fails between 10 to 20 times with an unexpected exception

NOTE 1: The "item" is an object added to the WeakSet at the beginning of the script, but "item" should not GC collected as it also keeps a normal (not weak) reference alive. 

NOTE 2: The boolean test should give always True, which is the case 99.9% of the time. Less than 0.01%, the boolean test fails raising an exception of the type "ValueError" (Description:"Index was out of range") or a bit more frequent "SystemError" (Description:"Handle is not initialized"). This happens 5 to 30 times in 100.000 test cycle (Seems very small, but it is important enough to avoid a practical construction of a medium size optimization problem with "Pulp" library). 
Tracking down the error, the exception ValueError is raised in line 70 and the exception "SystemError" in line 73 of "_weakrefset.py" .

    On "Lib\_weakrefset.py" 

    35 :class WeakSet(object):
    ....
    68 :    def __contains__(self, item):
    69 :        try:
    *70:           wr = ref(item)     # <- here is raised "ValueError" Exception ("Index was out of range")
    71 :        except TypeError:
    72 :            return False
    *73:       return wr in self.data # <- here is raised "SystemError" Exception ("Handle is not initialized")
Continuing after the exception, when executing the same boolean test again, it works fine (same item, same WeakSetObject, same execution, local and global context. Script was not started again!). I.e. if you catch the exception and continue the execution, It is like as if the exception never happened before (it's like a runtime lapsus!). 

I believe to fix the source of the problem, Ironpython should trap or avoid the error in weakref module itself (C# code). I don't know how... can someone kindly help me to fix this?

Cheers, 
Andres Sommerhoff





--------------------------------------------------------------------------------
_______________________________________________
Ironpython-users mailing list
Ironpython-users at python.org
https://mail.python.org/mailman/listinfo/ironpython-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150413/c3eec56b/attachment.html>

From sommerhoff at gmail.com  Mon Apr 13 18:29:47 2015
From: sommerhoff at gmail.com (Andres Sommerhoff)
Date: Mon, 13 Apr 2015 13:29:47 -0300
Subject: [Ironpython-users] Fwd: weakref random "SystemError" and
 "ValueError" exception (affecting _weakrefset.py and abc.py)
In-Reply-To: <6A8B073CBC6345ECAB4C3B9FCBDE5ED0@AndyDesktop>
References: <CAO1Y6_UC98veY=q89Pda24y6rK093-5oTFJpYNCjuqgZ8nzd3Q@mail.gmail.com>
 <CAO1Y6_WmeEm8Q_oPJ_Oh9LqpJqUnBt-9jVVjWyXz21uWDOg2-w@mail.gmail.com>
 <6A8B073CBC6345ECAB4C3B9FCBDE5ED0@AndyDesktop>
Message-ID: <CAO1Y6_VUsNFWJd-5y5feph6P9tYShJJPhfiHgVyPNEDAeY0XmA@mail.gmail.com>

Thank you Andrew, good to know you could replicate it. I went to very
similar workarround with __contains__(), but yours is more elegant with the
"while 1". However, I will recommend to repeat only a few times (to avoid a
possible endless loop) and to catch the two unexpected exception only
(SystemError,
ValueError). So I suggest the following workaround based in your proposal
should be:

    def __contains__(self, item):
        while 1:
            try:
                try:
                    wr = ref(item)
                except TypeError:
                    return False
                return wr in self.data
            except (SystemError, ValueError): #i.e: Don't
catch KeyboardInterrupt, MemoryError, etc
                try: i+=1
                except: i=0       # i declared here. Don't want waste
resource outside... (not Pythonic, I know)
                if i==10: raise   # Retry max 10 times and re-raise

However, would like if someone can debug the error in the C# code of
weakref. I'm afraid that the workaround will leave some potential error
open beside __contains__(). I see than inside _weakrefset.py the functions
add(), remove(), discard(), __isub__(), etc are also using the problematic
"ref()" function. The error could eventually happen there or even outside
_weakrefset.py.

Looking forward some IronPython Guru can check the c# code. I
will appreciate the help on that! In the meantime, I will use the
__contains__() as above, trying to tackle the most common case.

Regards,
Andres Sommerhoff



On Mon, Apr 13, 2015 at 11:55 AM, Andrew Graham <andy at agraham.demon.co.uk>
wrote:

>   I confirm the same problem, except that it happens more often for me,
> about 50 to 60 times each time I run the test.
> It smells like some sort of ?unsynchronised acess by different threads to
> an object problem ?.
>
> One (very) hacky way round it until the real cause is established is to
> modify __contains__() in _weakrefset.py line 68 to retry until it gets a
> proper result
>
>     def __contains__(self, item):
>         while 1:
>             try:
>                 try:
>                     wr = ref(item)
>                 except TypeError:
>                     return False
>                 return wr in self.data
>             except Exception:
>                 pass
>
> Regards
>
> Andy Graham
>
>  *From:* Andres Sommerhoff <sommerhoff at gmail.com>
> *Sent:* Monday, April 13, 2015 6:39 AM
> *To:* ironpython-users at python.org
> *Subject:* [Ironpython-users] Fwd: weakref random "SystemError" and
> "ValueError" exception (affecting _weakrefset.py and abc.py)
>
>   Dear IronPython gurus!
>
> Hopping you can help me with a kind of ramdom bug (unexpected SystemError
> and ValueError exception) in _weakrefset.py (it would be great if you can
> replicate it by running my script below. Please let me know).
>
> The error is random, but I managed to reproduce it by running the
> "ramdomly" ofending code 100.000 times inside a loop (Script attached).
> Note that the test takes only a few seconds, and in my PC it throws
> regularly between 5 to 30 exception for all those cycles). I see there are
> other people suffering for the same, but without solution or workaround yet
> (
> https://mail.python.org/pipermail/ironpython-users/2014-November/017332.html
> and https://github.com/IronLanguages/main/issues/1187)
>
> In my case, weakref error was related with an intensive use of
> isinstance() inside "Pulp" library (an optimization python library). *Just
> for your reference*:* isintance() use internally a WeakSet as a cache for
> the class types, which in turn use weakref (see ABCMeta.__instancecheck__()
> in the standard file "abc.py"). *
> In my test script I have isolated the problem to WeakSet only (I isolated
> it to clean the bug from the "abc.py" and "Pulp" library stuff). The
> exception happens inside *WeakSet.__contains__()* function (from
> _weakrefset.py file). As stated, it happens randomly, but apparently only
> related with a GC collect cycle into a memory "hungry" python script . I
> ran the test script in two PCs with similar results: Windows 7 64bits and
> Windows 7 32bits. Both using ipy.exe 32bit version 2.7.4 (2.7.0.40). The
> .NET version is 4.0.30319.18444 (32-bit). The test script does:
>
>    1. It simulate a "memory intensive" python code (creating a weakref
>    object of 2kb to 12kb in each loop. If smaller, like 0.1kb objects, then
>    the bug don't show up)
>    2. It manually runs GC.collect() every 1.000 cycles (should collect
>    those weakref objects)
>    3. ... and it repeat (100.000 times) the following "offending" boolean
>    test:
>
>        test = item in WeakSetObject  *#<- Repeated 100.000 times. *
> *                                      #-> it fails between 10 to 20 times
> with an unexpected exception*
>
> *NOTE 1:* The "item" is an object added to the WeakSet at the beginning
> of the script, but "item" should not GC collected as it also keeps a normal
> (not weak) reference alive.
>
> *NOTE 2:* The boolean test should give always True, which is the case
> 99.9% of the time. Less than 0.01%, the boolean test fails raising an
> exception of the type "ValueError" *(Description:"Index was out of
> range") *or a bit more frequent "SystemError" *(Description:"Handle is
> not initialized")*. This happens 5 to 30 times in 100.000 test cycle
> (Seems very small, but it is important enough to avoid a practical
> construction of a medium size optimization problem with "Pulp" library).
>
> Tracking down the error, the exception ValueError is raised in line 70 and
> the exception "SystemError" in line 73 of "_weakrefset.py" .
>
>     On "Lib\_weakrefset.py"
>     35 :class WeakSet(object):
>     ....
>     68 :    def __contains__(self, item):
>     69 :        try:
>     **70*:           wr = ref(item)     # <- here is raised "ValueError"
> Exception ("Index was out of range")
>     71 :        except TypeError:
>     72 :            return False
>     **73*:       return wr in self.data # <- here is raised "SystemError"
> Exception ("Handle is not initialized")
>
> Continuing after the exception, when executing the same boolean test
> again, it works fine (same item, same WeakSetObject, same execution, local
> and global context. Script was not started again!). I.e. if you catch the
> exception and continue the execution, It is like as if the exception never
> happened before (it's like a runtime lapsus!).
>
> I believe to fix the source of the problem, Ironpython should trap or
> avoid the error in weakref module itself (C# code). I don't know how... can
> someone kindly help me to fix this?
> Cheers,
> Andres Sommerhoff
>
>
>
>
>
> ------------------------------
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150413/1cb43f8f/attachment.html>

From pawel.jasinski at gmail.com  Tue Apr 14 00:41:40 2015
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Tue, 14 Apr 2015 00:41:40 +0200
Subject: [Ironpython-users] Fwd: weakref random "SystemError" and
 "ValueError" exception (affecting _weakrefset.py and abc.py)
In-Reply-To: <CAO1Y6_VUsNFWJd-5y5feph6P9tYShJJPhfiHgVyPNEDAeY0XmA@mail.gmail.com>
References: <CAO1Y6_UC98veY=q89Pda24y6rK093-5oTFJpYNCjuqgZ8nzd3Q@mail.gmail.com>
 <CAO1Y6_WmeEm8Q_oPJ_Oh9LqpJqUnBt-9jVVjWyXz21uWDOg2-w@mail.gmail.com>
 <6A8B073CBC6345ECAB4C3B9FCBDE5ED0@AndyDesktop>
 <CAO1Y6_VUsNFWJd-5y5feph6P9tYShJJPhfiHgVyPNEDAeY0XmA@mail.gmail.com>
Message-ID: <CA+7conmxrJqRjK+oHzE1VqFVRN3u4w=isky6ThVOrmLcUfR7ug@mail.gmail.com>

did anybody try it with the 2.7.4?
I wonder it is something we introduced in 2.7.5.
--pawel

On Mon, Apr 13, 2015 at 6:29 PM, Andres Sommerhoff <sommerhoff at gmail.com> wrote:
> Thank you Andrew, good to know you could replicate it. I went to very
> similar workarround with __contains__(), but yours is more elegant with the
> "while 1". However, I will recommend to repeat only a few times (to avoid a
> possible endless loop) and to catch the two unexpected exception only
> (SystemError, ValueError). So I suggest the following workaround based in
> your proposal should be:
>
>     def __contains__(self, item):
>         while 1:
>             try:
>                 try:
>                     wr = ref(item)
>                 except TypeError:
>                     return False
>                 return wr in self.data
>             except (SystemError, ValueError): #i.e: Don't catch
> KeyboardInterrupt, MemoryError, etc
>                 try: i+=1
>                 except: i=0       # i declared here. Don't want waste
> resource outside... (not Pythonic, I know)
>                 if i==10: raise   # Retry max 10 times and re-raise
>
> However, would like if someone can debug the error in the C# code of
> weakref. I'm afraid that the workaround will leave some potential error open
> beside __contains__(). I see than inside _weakrefset.py the functions add(),
> remove(), discard(), __isub__(), etc are also using the problematic "ref()"
> function. The error could eventually happen there or even outside
> _weakrefset.py.
>
> Looking forward some IronPython Guru can check the c# code. I will
> appreciate the help on that! In the meantime, I will use the __contains__()
> as above, trying to tackle the most common case.
>
> Regards,
> Andres Sommerhoff
>
>
>
> On Mon, Apr 13, 2015 at 11:55 AM, Andrew Graham <andy at agraham.demon.co.uk>
> wrote:
>>
>> I confirm the same problem, except that it happens more often for me,
>> about 50 to 60 times each time I run the test.
>> It smells like some sort of ?unsynchronised acess by different threads to
>> an object problem ?.
>>
>> One (very) hacky way round it until the real cause is established is to
>> modify __contains__() in _weakrefset.py line 68 to retry until it gets a
>> proper result
>>
>>     def __contains__(self, item):
>>         while 1:
>>             try:
>>                 try:
>>                     wr = ref(item)
>>                 except TypeError:
>>                     return False
>>                 return wr in self.data
>>             except Exception:
>>                 pass
>>
>> Regards
>>
>> Andy Graham
>>
>> From: Andres Sommerhoff
>> Sent: Monday, April 13, 2015 6:39 AM
>> To: ironpython-users at python.org
>> Subject: [Ironpython-users] Fwd: weakref random "SystemError" and
>> "ValueError" exception (affecting _weakrefset.py and abc.py)
>>
>> Dear IronPython gurus!
>>
>> Hopping you can help me with a kind of ramdom bug (unexpected SystemError
>> and ValueError exception) in _weakrefset.py (it would be great if you can
>> replicate it by running my script below. Please let me know).
>>
>> The error is random, but I managed to reproduce it by running the
>> "ramdomly" ofending code 100.000 times inside a loop (Script attached). Note
>> that the test takes only a few seconds, and in my PC it throws regularly
>> between 5 to 30 exception for all those cycles). I see there are other
>> people suffering for the same, but without solution or workaround yet
>> (https://mail.python.org/pipermail/ironpython-users/2014-November/017332.html
>> and https://github.com/IronLanguages/main/issues/1187)
>>
>> In my case, weakref error was related with an intensive use of
>> isinstance() inside "Pulp" library (an optimization python library). Just
>> for your reference: isintance() use internally a WeakSet as a cache for the
>> class types, which in turn use weakref (see ABCMeta.__instancecheck__() in
>> the standard file "abc.py").
>>
>> In my test script I have isolated the problem to WeakSet only (I isolated
>> it to clean the bug from the "abc.py" and "Pulp" library stuff). The
>> exception happens inside WeakSet.__contains__() function (from
>> _weakrefset.py file). As stated, it happens randomly, but apparently only
>> related with a GC collect cycle into a memory "hungry" python script . I ran
>> the test script in two PCs with similar results: Windows 7 64bits and
>> Windows 7 32bits. Both using ipy.exe 32bit version 2.7.4 (2.7.0.40). The
>> .NET version is 4.0.30319.18444 (32-bit). The test script does:
>>
>> It simulate a "memory intensive" python code (creating a weakref object of
>> 2kb to 12kb in each loop. If smaller, like 0.1kb objects, then the bug don't
>> show up)
>> It manually runs GC.collect() every 1.000 cycles (should collect those
>> weakref objects)
>> ... and it repeat (100.000 times) the following "offending" boolean test:
>>
>>        test = item in WeakSetObject  #<- Repeated 100.000 times.
>>                                       #-> it fails between 10 to 20 times
>> with an unexpected exception
>>
>> NOTE 1: The "item" is an object added to the WeakSet at the beginning of
>> the script, but "item" should not GC collected as it also keeps a normal
>> (not weak) reference alive.
>>
>> NOTE 2: The boolean test should give always True, which is the case 99.9%
>> of the time. Less than 0.01%, the boolean test fails raising an exception of
>> the type "ValueError" (Description:"Index was out of range") or a bit more
>> frequent "SystemError" (Description:"Handle is not initialized"). This
>> happens 5 to 30 times in 100.000 test cycle (Seems very small, but it is
>> important enough to avoid a practical construction of a medium size
>> optimization problem with "Pulp" library).
>>
>> Tracking down the error, the exception ValueError is raised in line 70 and
>> the exception "SystemError" in line 73 of "_weakrefset.py" .
>>
>>     On "Lib\_weakrefset.py"
>>
>>     35 :class WeakSet(object):
>>     ....
>>     68 :    def __contains__(self, item):
>>     69 :        try:
>>     *70:           wr = ref(item)     # <- here is raised "ValueError"
>> Exception ("Index was out of range")
>>     71 :        except TypeError:
>>     72 :            return False
>>     *73:       return wr in self.data # <- here is raised "SystemError"
>> Exception ("Handle is not initialized")
>>
>> Continuing after the exception, when executing the same boolean test
>> again, it works fine (same item, same WeakSetObject, same execution, local
>> and global context. Script was not started again!). I.e. if you catch the
>> exception and continue the execution, It is like as if the exception never
>> happened before (it's like a runtime lapsus!).
>>
>> I believe to fix the source of the problem, Ironpython should trap or
>> avoid the error in weakref module itself (C# code). I don't know how... can
>> someone kindly help me to fix this?
>>
>> Cheers,
>> Andres Sommerhoff
>>
>>
>>
>>
>>
>> ________________________________
>> _______________________________________________
>> Ironpython-users mailing list
>> Ironpython-users at python.org
>> https://mail.python.org/mailman/listinfo/ironpython-users
>
>
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>

From sommerhoff at gmail.com  Tue Apr 14 02:13:23 2015
From: sommerhoff at gmail.com (Andres Sommerhoff)
Date: Mon, 13 Apr 2015 21:13:23 -0300
Subject: [Ironpython-users] Fwd: weakref random "SystemError" and
	"ValueError" exception (affecting _weakrefset.py and abc.py)
In-Reply-To: <CA+7conmxrJqRjK+oHzE1VqFVRN3u4w=isky6ThVOrmLcUfR7ug@mail.gmail.com>
References: <CAO1Y6_UC98veY=q89Pda24y6rK093-5oTFJpYNCjuqgZ8nzd3Q@mail.gmail.com>
 <CAO1Y6_WmeEm8Q_oPJ_Oh9LqpJqUnBt-9jVVjWyXz21uWDOg2-w@mail.gmail.com>
 <6A8B073CBC6345ECAB4C3B9FCBDE5ED0@AndyDesktop>
 <CAO1Y6_VUsNFWJd-5y5feph6P9tYShJJPhfiHgVyPNEDAeY0XmA@mail.gmail.com>
 <CA+7conmxrJqRjK+oHzE1VqFVRN3u4w=isky6ThVOrmLcUfR7ug@mail.gmail.com>
Message-ID: <F5B2AC9F-F9C0-4508-A5C9-EAC4236F55F8@gmail.com>

Hi Pawel, its actually very old to me (more than a year). I'm suffering gradually as the code went more complex. At the beginning was not a big issue. Now, it is not a chance to run some code under IronPython without the weakref exception (so Im running it in Cpython or with the workarround of my previous email). Please note that I have tested only with 2.7.4, not with 2.7.5 yet (as 2.7.4 is the version that comes with SolverStudio software)

Can you try the script yourself?

Thank you for helping on this!

Regards, 
Andres

> El 13-04-2015, a las 19:41, Pawel Jasinski <pawel.jasinski at gmail.com> escribi?:
> 
> did anybody try it with the 2.7.4?
> I wonder it is something we introduced in 2.7.5.
> --pawel
> 
>> On Mon, Apr 13, 2015 at 6:29 PM, Andres Sommerhoff <sommerhoff at gmail.com> wrote:
>> Thank you Andrew, good to know you could replicate it. I went to very
>> similar workarround with __contains__(), but yours is more elegant with the
>> "while 1". However, I will recommend to repeat only a few times (to avoid a
>> possible endless loop) and to catch the two unexpected exception only
>> (SystemError, ValueError). So I suggest the following workaround based in
>> your proposal should be:
>> 
>>    def __contains__(self, item):
>>        while 1:
>>            try:
>>                try:
>>                    wr = ref(item)
>>                except TypeError:
>>                    return False
>>                return wr in self.data
>>            except (SystemError, ValueError): #i.e: Don't catch
>> KeyboardInterrupt, MemoryError, etc
>>                try: i+=1
>>                except: i=0       # i declared here. Don't want waste
>> resource outside... (not Pythonic, I know)
>>                if i==10: raise   # Retry max 10 times and re-raise
>> 
>> However, would like if someone can debug the error in the C# code of
>> weakref. I'm afraid that the workaround will leave some potential error open
>> beside __contains__(). I see than inside _weakrefset.py the functions add(),
>> remove(), discard(), __isub__(), etc are also using the problematic "ref()"
>> function. The error could eventually happen there or even outside
>> _weakrefset.py.
>> 
>> Looking forward some IronPython Guru can check the c# code. I will
>> appreciate the help on that! In the meantime, I will use the __contains__()
>> as above, trying to tackle the most common case.
>> 
>> Regards,
>> Andres Sommerhoff
>> 
>> 
>> 
>> On Mon, Apr 13, 2015 at 11:55 AM, Andrew Graham <andy at agraham.demon.co.uk>
>> wrote:
>>> 
>>> I confirm the same problem, except that it happens more often for me,
>>> about 50 to 60 times each time I run the test.
>>> It smells like some sort of ?unsynchronised acess by different threads to
>>> an object problem ?.
>>> 
>>> One (very) hacky way round it until the real cause is established is to
>>> modify __contains__() in _weakrefset.py line 68 to retry until it gets a
>>> proper result
>>> 
>>>    def __contains__(self, item):
>>>        while 1:
>>>            try:
>>>                try:
>>>                    wr = ref(item)
>>>                except TypeError:
>>>                    return False
>>>                return wr in self.data
>>>            except Exception:
>>>                pass
>>> 
>>> Regards
>>> 
>>> Andy Graham
>>> 
>>> From: Andres Sommerhoff
>>> Sent: Monday, April 13, 2015 6:39 AM
>>> To: ironpython-users at python.org
>>> Subject: [Ironpython-users] Fwd: weakref random "SystemError" and
>>> "ValueError" exception (affecting _weakrefset.py and abc.py)
>>> 
>>> Dear IronPython gurus!
>>> 
>>> Hopping you can help me with a kind of ramdom bug (unexpected SystemError
>>> and ValueError exception) in _weakrefset.py (it would be great if you can
>>> replicate it by running my script below. Please let me know).
>>> 
>>> The error is random, but I managed to reproduce it by running the
>>> "ramdomly" ofending code 100.000 times inside a loop (Script attached). Note
>>> that the test takes only a few seconds, and in my PC it throws regularly
>>> between 5 to 30 exception for all those cycles). I see there are other
>>> people suffering for the same, but without solution or workaround yet
>>> (https://mail.python.org/pipermail/ironpython-users/2014-November/017332.html
>>> and https://github.com/IronLanguages/main/issues/1187)
>>> 
>>> In my case, weakref error was related with an intensive use of
>>> isinstance() inside "Pulp" library (an optimization python library). Just
>>> for your reference: isintance() use internally a WeakSet as a cache for the
>>> class types, which in turn use weakref (see ABCMeta.__instancecheck__() in
>>> the standard file "abc.py").
>>> 
>>> In my test script I have isolated the problem to WeakSet only (I isolated
>>> it to clean the bug from the "abc.py" and "Pulp" library stuff). The
>>> exception happens inside WeakSet.__contains__() function (from
>>> _weakrefset.py file). As stated, it happens randomly, but apparently only
>>> related with a GC collect cycle into a memory "hungry" python script . I ran
>>> the test script in two PCs with similar results: Windows 7 64bits and
>>> Windows 7 32bits. Both using ipy.exe 32bit version 2.7.4 (2.7.0.40). The
>>> .NET version is 4.0.30319.18444 (32-bit). The test script does:
>>> 
>>> It simulate a "memory intensive" python code (creating a weakref object of
>>> 2kb to 12kb in each loop. If smaller, like 0.1kb objects, then the bug don't
>>> show up)
>>> It manually runs GC.collect() every 1.000 cycles (should collect those
>>> weakref objects)
>>> ... and it repeat (100.000 times) the following "offending" boolean test:
>>> 
>>>       test = item in WeakSetObject  #<- Repeated 100.000 times.
>>>                                      #-> it fails between 10 to 20 times
>>> with an unexpected exception
>>> 
>>> NOTE 1: The "item" is an object added to the WeakSet at the beginning of
>>> the script, but "item" should not GC collected as it also keeps a normal
>>> (not weak) reference alive.
>>> 
>>> NOTE 2: The boolean test should give always True, which is the case 99.9%
>>> of the time. Less than 0.01%, the boolean test fails raising an exception of
>>> the type "ValueError" (Description:"Index was out of range") or a bit more
>>> frequent "SystemError" (Description:"Handle is not initialized"). This
>>> happens 5 to 30 times in 100.000 test cycle (Seems very small, but it is
>>> important enough to avoid a practical construction of a medium size
>>> optimization problem with "Pulp" library).
>>> 
>>> Tracking down the error, the exception ValueError is raised in line 70 and
>>> the exception "SystemError" in line 73 of "_weakrefset.py" .
>>> 
>>>    On "Lib\_weakrefset.py"
>>> 
>>>    35 :class WeakSet(object):
>>>    ....
>>>    68 :    def __contains__(self, item):
>>>    69 :        try:
>>>    *70:           wr = ref(item)     # <- here is raised "ValueError"
>>> Exception ("Index was out of range")
>>>    71 :        except TypeError:
>>>    72 :            return False
>>>    *73:       return wr in self.data # <- here is raised "SystemError"
>>> Exception ("Handle is not initialized")
>>> 
>>> Continuing after the exception, when executing the same boolean test
>>> again, it works fine (same item, same WeakSetObject, same execution, local
>>> and global context. Script was not started again!). I.e. if you catch the
>>> exception and continue the execution, It is like as if the exception never
>>> happened before (it's like a runtime lapsus!).
>>> 
>>> I believe to fix the source of the problem, Ironpython should trap or
>>> avoid the error in weakref module itself (C# code). I don't know how... can
>>> someone kindly help me to fix this?
>>> 
>>> Cheers,
>>> Andres Sommerhoff
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ________________________________
>>> _______________________________________________
>>> Ironpython-users mailing list
>>> Ironpython-users at python.org
>>> https://mail.python.org/mailman/listinfo/ironpython-users
>> 
>> 
>> 
>> _______________________________________________
>> Ironpython-users mailing list
>> Ironpython-users at python.org
>> https://mail.python.org/mailman/listinfo/ironpython-users
>> 

From pawel.jasinski at gmail.com  Tue Apr 14 11:15:08 2015
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Tue, 14 Apr 2015 11:15:08 +0200
Subject: [Ironpython-users] Fwd: weakref random "SystemError" and
 "ValueError" exception (affecting _weakrefset.py and abc.py)
In-Reply-To: <F5B2AC9F-F9C0-4508-A5C9-EAC4236F55F8@gmail.com>
References: <CAO1Y6_UC98veY=q89Pda24y6rK093-5oTFJpYNCjuqgZ8nzd3Q@mail.gmail.com>
 <CAO1Y6_WmeEm8Q_oPJ_Oh9LqpJqUnBt-9jVVjWyXz21uWDOg2-w@mail.gmail.com>
 <6A8B073CBC6345ECAB4C3B9FCBDE5ED0@AndyDesktop>
 <CAO1Y6_VUsNFWJd-5y5feph6P9tYShJJPhfiHgVyPNEDAeY0XmA@mail.gmail.com>
 <CA+7conmxrJqRjK+oHzE1VqFVRN3u4w=isky6ThVOrmLcUfR7ug@mail.gmail.com>
 <F5B2AC9F-F9C0-4508-A5C9-EAC4236F55F8@gmail.com>
Message-ID: <CA+7con=MbWTBykaKHYOWmbkDe_KCo4X2Fzanh1H7w_POaAD94Q@mail.gmail.com>

I can reproduce it with 2.7.4 and 2.7.5.
--pawel

On Tue, Apr 14, 2015 at 2:13 AM, Andres Sommerhoff <sommerhoff at gmail.com> wrote:
> Hi Pawel, its actually very old to me (more than a year). I'm suffering gradually as the code went more complex. At the beginning was not a big issue. Now, it is not a chance to run some code under IronPython without the weakref exception (so Im running it in Cpython or with the workarround of my previous email). Please note that I have tested only with 2.7.4, not with 2.7.5 yet (as 2.7.4 is the version that comes with SolverStudio software)
>
> Can you try the script yourself?
>
> Thank you for helping on this!
>
> Regards,
> Andres
>
>> El 13-04-2015, a las 19:41, Pawel Jasinski <pawel.jasinski at gmail.com> escribi?:
>>
>> did anybody try it with the 2.7.4?
>> I wonder it is something we introduced in 2.7.5.
>> --pawel
>>
>>> On Mon, Apr 13, 2015 at 6:29 PM, Andres Sommerhoff <sommerhoff at gmail.com> wrote:
>>> Thank you Andrew, good to know you could replicate it. I went to very
>>> similar workarround with __contains__(), but yours is more elegant with the
>>> "while 1". However, I will recommend to repeat only a few times (to avoid a
>>> possible endless loop) and to catch the two unexpected exception only
>>> (SystemError, ValueError). So I suggest the following workaround based in
>>> your proposal should be:
>>>
>>>    def __contains__(self, item):
>>>        while 1:
>>>            try:
>>>                try:
>>>                    wr = ref(item)
>>>                except TypeError:
>>>                    return False
>>>                return wr in self.data
>>>            except (SystemError, ValueError): #i.e: Don't catch
>>> KeyboardInterrupt, MemoryError, etc
>>>                try: i+=1
>>>                except: i=0       # i declared here. Don't want waste
>>> resource outside... (not Pythonic, I know)
>>>                if i==10: raise   # Retry max 10 times and re-raise
>>>
>>> However, would like if someone can debug the error in the C# code of
>>> weakref. I'm afraid that the workaround will leave some potential error open
>>> beside __contains__(). I see than inside _weakrefset.py the functions add(),
>>> remove(), discard(), __isub__(), etc are also using the problematic "ref()"
>>> function. The error could eventually happen there or even outside
>>> _weakrefset.py.
>>>
>>> Looking forward some IronPython Guru can check the c# code. I will
>>> appreciate the help on that! In the meantime, I will use the __contains__()
>>> as above, trying to tackle the most common case.
>>>
>>> Regards,
>>> Andres Sommerhoff
>>>
>>>
>>>
>>> On Mon, Apr 13, 2015 at 11:55 AM, Andrew Graham <andy at agraham.demon.co.uk>
>>> wrote:
>>>>
>>>> I confirm the same problem, except that it happens more often for me,
>>>> about 50 to 60 times each time I run the test.
>>>> It smells like some sort of ?unsynchronised acess by different threads to
>>>> an object problem ?.
>>>>
>>>> One (very) hacky way round it until the real cause is established is to
>>>> modify __contains__() in _weakrefset.py line 68 to retry until it gets a
>>>> proper result
>>>>
>>>>    def __contains__(self, item):
>>>>        while 1:
>>>>            try:
>>>>                try:
>>>>                    wr = ref(item)
>>>>                except TypeError:
>>>>                    return False
>>>>                return wr in self.data
>>>>            except Exception:
>>>>                pass
>>>>
>>>> Regards
>>>>
>>>> Andy Graham
>>>>
>>>> From: Andres Sommerhoff
>>>> Sent: Monday, April 13, 2015 6:39 AM
>>>> To: ironpython-users at python.org
>>>> Subject: [Ironpython-users] Fwd: weakref random "SystemError" and
>>>> "ValueError" exception (affecting _weakrefset.py and abc.py)
>>>>
>>>> Dear IronPython gurus!
>>>>
>>>> Hopping you can help me with a kind of ramdom bug (unexpected SystemError
>>>> and ValueError exception) in _weakrefset.py (it would be great if you can
>>>> replicate it by running my script below. Please let me know).
>>>>
>>>> The error is random, but I managed to reproduce it by running the
>>>> "ramdomly" ofending code 100.000 times inside a loop (Script attached). Note
>>>> that the test takes only a few seconds, and in my PC it throws regularly
>>>> between 5 to 30 exception for all those cycles). I see there are other
>>>> people suffering for the same, but without solution or workaround yet
>>>> (https://mail.python.org/pipermail/ironpython-users/2014-November/017332.html
>>>> and https://github.com/IronLanguages/main/issues/1187)
>>>>
>>>> In my case, weakref error was related with an intensive use of
>>>> isinstance() inside "Pulp" library (an optimization python library). Just
>>>> for your reference: isintance() use internally a WeakSet as a cache for the
>>>> class types, which in turn use weakref (see ABCMeta.__instancecheck__() in
>>>> the standard file "abc.py").
>>>>
>>>> In my test script I have isolated the problem to WeakSet only (I isolated
>>>> it to clean the bug from the "abc.py" and "Pulp" library stuff). The
>>>> exception happens inside WeakSet.__contains__() function (from
>>>> _weakrefset.py file). As stated, it happens randomly, but apparently only
>>>> related with a GC collect cycle into a memory "hungry" python script . I ran
>>>> the test script in two PCs with similar results: Windows 7 64bits and
>>>> Windows 7 32bits. Both using ipy.exe 32bit version 2.7.4 (2.7.0.40). The
>>>> .NET version is 4.0.30319.18444 (32-bit). The test script does:
>>>>
>>>> It simulate a "memory intensive" python code (creating a weakref object of
>>>> 2kb to 12kb in each loop. If smaller, like 0.1kb objects, then the bug don't
>>>> show up)
>>>> It manually runs GC.collect() every 1.000 cycles (should collect those
>>>> weakref objects)
>>>> ... and it repeat (100.000 times) the following "offending" boolean test:
>>>>
>>>>       test = item in WeakSetObject  #<- Repeated 100.000 times.
>>>>                                      #-> it fails between 10 to 20 times
>>>> with an unexpected exception
>>>>
>>>> NOTE 1: The "item" is an object added to the WeakSet at the beginning of
>>>> the script, but "item" should not GC collected as it also keeps a normal
>>>> (not weak) reference alive.
>>>>
>>>> NOTE 2: The boolean test should give always True, which is the case 99.9%
>>>> of the time. Less than 0.01%, the boolean test fails raising an exception of
>>>> the type "ValueError" (Description:"Index was out of range") or a bit more
>>>> frequent "SystemError" (Description:"Handle is not initialized"). This
>>>> happens 5 to 30 times in 100.000 test cycle (Seems very small, but it is
>>>> important enough to avoid a practical construction of a medium size
>>>> optimization problem with "Pulp" library).
>>>>
>>>> Tracking down the error, the exception ValueError is raised in line 70 and
>>>> the exception "SystemError" in line 73 of "_weakrefset.py" .
>>>>
>>>>    On "Lib\_weakrefset.py"
>>>>
>>>>    35 :class WeakSet(object):
>>>>    ....
>>>>    68 :    def __contains__(self, item):
>>>>    69 :        try:
>>>>    *70:           wr = ref(item)     # <- here is raised "ValueError"
>>>> Exception ("Index was out of range")
>>>>    71 :        except TypeError:
>>>>    72 :            return False
>>>>    *73:       return wr in self.data # <- here is raised "SystemError"
>>>> Exception ("Handle is not initialized")
>>>>
>>>> Continuing after the exception, when executing the same boolean test
>>>> again, it works fine (same item, same WeakSetObject, same execution, local
>>>> and global context. Script was not started again!). I.e. if you catch the
>>>> exception and continue the execution, It is like as if the exception never
>>>> happened before (it's like a runtime lapsus!).
>>>>
>>>> I believe to fix the source of the problem, Ironpython should trap or
>>>> avoid the error in weakref module itself (C# code). I don't know how... can
>>>> someone kindly help me to fix this?
>>>>
>>>> Cheers,
>>>> Andres Sommerhoff
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ________________________________
>>>> _______________________________________________
>>>> Ironpython-users mailing list
>>>> Ironpython-users at python.org
>>>> https://mail.python.org/mailman/listinfo/ironpython-users
>>>
>>>
>>>
>>> _______________________________________________
>>> Ironpython-users mailing list
>>> Ironpython-users at python.org
>>> https://mail.python.org/mailman/listinfo/ironpython-users
>>>

From sommerhoff at gmail.com  Tue Apr 14 18:04:48 2015
From: sommerhoff at gmail.com (Andres Sommerhoff)
Date: Tue, 14 Apr 2015 13:04:48 -0300
Subject: [Ironpython-users] Fwd: weakref random "SystemError" and
 "ValueError" exception (affecting _weakrefset.py and abc.py)
In-Reply-To: <CA+7con=MbWTBykaKHYOWmbkDe_KCo4X2Fzanh1H7w_POaAD94Q@mail.gmail.com>
References: <CAO1Y6_UC98veY=q89Pda24y6rK093-5oTFJpYNCjuqgZ8nzd3Q@mail.gmail.com>
 <CAO1Y6_WmeEm8Q_oPJ_Oh9LqpJqUnBt-9jVVjWyXz21uWDOg2-w@mail.gmail.com>
 <6A8B073CBC6345ECAB4C3B9FCBDE5ED0@AndyDesktop>
 <CAO1Y6_VUsNFWJd-5y5feph6P9tYShJJPhfiHgVyPNEDAeY0XmA@mail.gmail.com>
 <CA+7conmxrJqRjK+oHzE1VqFVRN3u4w=isky6ThVOrmLcUfR7ug@mail.gmail.com>
 <F5B2AC9F-F9C0-4508-A5C9-EAC4236F55F8@gmail.com>
 <CA+7con=MbWTBykaKHYOWmbkDe_KCo4X2Fzanh1H7w_POaAD94Q@mail.gmail.com>
Message-ID: <CAO1Y6_VxjfFNoyjpzvADns+2ixkawVRyX9NJ991vwAaaFfKvoQ@mail.gmail.com>

Thank you Pawel, good to know you can reproduce the weakref error in two
Ironpython releases as well.

Just for your reference, I add -X:ShowClrExceptions -X:ExceptionDetail and
got the reports for each exception (txt atached).

Any clue?

Regards, Andres

>>> Rest of the email thread in:
https://mail.python.org/pipermail/ironpython-users/2015-April/017447.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150414/e747067e/attachment.html>
-------------- next part --------------

################################################
Case 1: Random Exception "SystemError" in WeakSet
            Tested on IronPython 2.7.4   32bits Windows 7 64
################################################
Traceback (most recent call last):
  File "<string>", line 29, in <module>
  File "D:\IronPython\Lib\_weakrefset.py", line 73, in __contains__
SystemError: Handle is not initialized.
--------------------------

Handle is not initialized.
   at System.Runtime.InteropServices.GCHandle.get_Target()
   at IronPython.Modules.PythonWeakRef.ref.EqualsWorker(Object other, IEqualityComparer comparer)
   at IronPython.Modules.PythonWeakRef.ref.System.Collections.IStructuralEquatable.Equals(Object other, IEqualityComparer comparer)
   at IronPython.Runtime.Operations.InstanceOps.StructuralEqualityMethod[T](CodeContext context, T x, T y)
   at CallSite.Target(Closure , CallSite , Object , Object )
   at IronPython.Runtime.SetStorage.<>c__DisplayClassd.<AssignSiteDelegates>b__c(Object o0, Object o1)
   at IronPython.Runtime.SetStorage.ContainsWorker(Bucket[] buckets, Object item, Int32 hashCode, Func`3 eqFunc)
   at IronPython.Runtime.SetStorage.ContainsAlwaysHash(Object item)
   at IronPython.Runtime.SetCollection.__contains__(Object item)
   at IronPython.Runtime.Binding.PythonOperationBinder.SetContains(CallSite site, Object other, Object value)
   at __contains__$11(Closure , PythonFunction , Object , Object )
   at IronPython.Runtime.FunctionCaller`2.Call2(CallSite site, CodeContext context, Object func, T0 arg0, T1 arg1)
   at IronPython.Runtime.Method.MethodBinding`1.SelfTarget(CallSite site, CodeContext context, Object target, T0 arg0)
   at CallSite.Target(Closure , CallSite , Object , Object )
   at __main__$15.__main__(CodeContext $globalContext, FunctionCode $functionCode)
   at IronPython.Compiler.PythonScriptCode.RunWorker(CodeContext ctx)
   at IronPython.Compiler.PythonScriptCode.Run(Scope scope)
   at IronPython.Compiler.RuntimeScriptCode.InvokeTarget(Scope scope)
   at IronPython.Compiler.RuntimeScriptCode.Run(Scope scope)
   at IronPython.Hosting.PythonCommandLine.RunFileWorker(String fileName)
   at IronPython.Hosting.PythonCommandLine.RunFile(String fileName)
SystemError: Handle is not initialized.
CLR Exception:
    InvalidOperationException: Handle is not initialized.
-------------- next part --------------
################################################
Case 2: Random Exception "ValueError" in WeakSet
            Tested on IronPython 2.7.4   32bits Windows 7 64
################################################
Traceback (most recent call last):
  File "<string>", line 29, in <module>
  File "D:\IronPython\Lib\_weakrefset.py", line 70, in __contains__
ValueError: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
---------------------------
Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
ThrowArgumentOutOfRangeException at offset 72 in file:line:column <filename unknown>:0:0

__new__ at offset 306 in file:line:column <filename unknown>:0:0

CallSite.Target at offset 117 in file:line:column <filename unknown>:0:0

__contains__$11 at offset 169 in file:line:column <filename unknown>:0:0

   at Microsoft.Scripting.Runtime.LightExceptions.CheckAndThrow(Object value)
   at __contains__$11(Closure , PythonFunction , Object , Object )
   at IronPython.Runtime.FunctionCaller`2.Call2(CallSite site, CodeContext context, Object func, T0 arg0, T1 arg1)
   at IronPython.Runtime.Method.MethodBinding`1.SelfTarget(CallSite site, CodeContext context, Object target, T0 arg0)
   at CallSite.Target(Closure , CallSite , Object , Object )
   at lambda_method(Closure , Object[] , StrongBox`1[] , InterpretedFrame )
   at Microsoft.Scripting.Interpreter.CompiledLoopInstruction.Run(InterpretedFrame frame)
   at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame)
   at Microsoft.Scripting.Interpreter.LightLambda.Run1[T0,TRet](T0 arg0)
   at IronPython.Compiler.RuntimeScriptCode.InvokeTarget(Scope scope)
   at IronPython.Compiler.RuntimeScriptCode.Run(Scope scope)
   at IronPython.Hosting.PythonCommandLine.RunFileWorker(String fileName)
   at IronPython.Hosting.PythonCommandLine.RunFile(String fileName)
ValueError: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
CLR Exception:
    ArgumentOutOfRangeException:Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index

From hemanth at broadcom.com  Wed Apr 15 08:32:08 2015
From: hemanth at broadcom.com (Hemanth M B)
Date: Wed, 15 Apr 2015 06:32:08 +0000
Subject: [Ironpython-users] Fail to load setupapi.dll library in ironpython
Message-ID: <650E8E7A30AA6E4697EAF063DB83FB8801405B28@SJEXCHMB05.corp.ad.broadcom.com>

Hi All,

I tried to load setupapi.dll library in my code using import clr and addreference. But it throws error while adding reference.
Error:
SystemError: The module was expected to contain an assembly manifest. (Exception from HRESULT: 0x80131018)

Reference: https://msdn.microsoft.com/en-us/library/windows/hardware/ff550855(v=vs.85).aspx



Thanks and Regards,
Hemanth M B

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150415/db85515f/attachment.html>

From andy at agraham.demon.co.uk  Wed Apr 15 09:40:45 2015
From: andy at agraham.demon.co.uk (Andrew Graham)
Date: Wed, 15 Apr 2015 08:40:45 +0100
Subject: [Ironpython-users] Fail to load setupapi.dll library in
	ironpython
In-Reply-To: <650E8E7A30AA6E4697EAF063DB83FB8801405B28@SJEXCHMB05.corp.ad.broadcom.com>
References: <650E8E7A30AA6E4697EAF063DB83FB8801405B28@SJEXCHMB05.corp.ad.broadcom.com>
Message-ID: <4257DAC507B044D6A63351E3FA6A942E@AndyDesktop>

setupapi.dll is an unmanaged library and is not directly callable from IronPython. If you really need it you will need to write a managed C# (or VB) wrapper assembly that accesses the required functions in the dll using P/Invoke (DllImport) and call into your wrapper from IronPython.

Regards

Andy Graham


From: Hemanth M B 
Sent: Wednesday, April 15, 2015 7:32 AM
To: ironpython-users at python.org 
Subject: [Ironpython-users] Fail to load setupapi.dll library in ironpython

Hi All,

 

I tried to load setupapi.dll library in my code using import clr and addreference. But it throws error while adding reference.

Error:

SystemError: The module was expected to contain an assembly manifest. (Exception from HRESULT: 0x80131018)

 

Reference: https://msdn.microsoft.com/en-us/library/windows/hardware/ff550855(v=vs.85).aspx

 

 

 

Thanks and Regards,

Hemanth M B

 



--------------------------------------------------------------------------------
_______________________________________________
Ironpython-users mailing list
Ironpython-users at python.org
https://mail.python.org/mailman/listinfo/ironpython-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150415/cf165048/attachment.html>

From no_reply at codeplex.com  Wed Apr 22 13:18:08 2015
From: no_reply at codeplex.com (CodePlex)
Date: 22 Apr 2015 04:18:08 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 4/21/2015
Message-ID: <CO1MSDNADMCDS2kyAWt00045aba@discussions.codeplex.com>

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New issue] Intermediate First Year Results 2015
2. [New issue] IronPython console, run py file, change dir

----------------------------------------------

ISSUES

1. [New issue] Intermediate First Year Results 2015
http://ironpython.codeplex.com/workitem/43093
User srinivasvarma173 has proposed the issue:

"Telangana intermediate 1st year results 2015 College wise: Today  TS Inter 1st Year Result 2015 Declared BIE Telangana Inter First Year Result 2015 Namasthe Name Wise  bie.telangana.gov.in , Telangana Inter 1st Year Result Download 2015 Name Wise Roll No. Wise School Wise Marks Subject wise Score card (Junior General,Vocational ) :-Result Date :- April 2015 ( Indiaresults.com , Schools9.com , results.manabadi.co.in )check results on april 23rd is here also, ts intermediate first year results 2015 also published at schools9, manabadi, eenadu, sakshi, goresults, indiaresults, interresultsz.com?etc. Check Telangana Junior Inter 1st Year Results 2015 From Below servers.

Telangana-intermediate-first-year-results-2015-announced

Telangana inter Results 2015 Declared by offical website
Board of  intermediate Education Telangana announce results online now 
Telangana State intermediate Examination Results 2015


Click here to download Telangana 1st Year Intermediate Results 2015 
Board of Intermediate Education, Telangana State will announce the result of Intermediate 1st Year March Exam . Those students who have given Telangana Intermediate 1st Year Annual examination can check their result online by entering Hall ticket No ( Roll No. ) printed on Admit card so students are advised please keep your Hall ticket of Inter ( 1st year) handy . The BIE TS/TG was scheduled the Telangana Board Inter 1st Year exam in the March 2015 . After the First year Intermediate Examination all the students now searching for Telangana Inter 1st year Result date 2015 on the internet . BIE Telangana Junior Inter / 1st Year Result 2015 with Photo ( General,Vocational stream) will be live soon .
Telangana TS Intermediate 1st Year Exam Result 2015 Declaration Time:

Board Name :- Board of Intermediate Education, Telangana State (BIETS)

Class :- Telangana Intermediate 1st Year
official website :- bie.telangana.gov.in Schools9.com , Manabadi , Indiaresults
Result date :- 22 April 2015
Telangana Intermediate 1st Year Exam Result 2015:- 
The BIETS will soon announced the Telangana Board Intermediate 1st Year Result 2015  after successfully finished the Exam . The Telangana Intermediate 1st Year Result expected date of declaration is April 2015 . So we are advised keep patience and bookmark our website for latest info about Telangana Intermediate 1st Year Result 2015 .

Telangana Intermediate First  year results 2015
The BIE Telangana was successfully held the Telangana 1st Inter final exams results for all MPC, BIPC and CEC fresh and reappear government, private college general, vocation courses students from March at all centers and more than 4 lac of boy?s and girls? are attended to the final exams and they are all waiting and searched for what is the Telangana Jr Inter 2015 result date and when will announced the BIE 2nd year Inter results 2015.

Department Name: ? Board of Intermediate Education (BIE), Telangana
Exam Name: ? Intermediate 1st Year Exam
Category: ? Telangana Inter 1st Year Result 2015
Expected date :- 3rd week of April 2015
Telangana Inter second year results 2015

The board of Inter Education in Telangana was established in 2014 after formation of New Telangana state. It regulates and supervises the system of Intermediate education in Telangana state.

How To check Telangana Intermediate 1st Year Result 2015 Online ?
go to bie.telangana.gov.in website 
find result section , click on Results 
now the result page will open 
You will see Board Exam Result 2014 2015
click on BIETS Telangana 1st Year Intermediate results 2015 
.gl/ Telangana Intermediate 1st Year Result

.gl/ Telangana Intermediate first Year Result

BIE Telangana Inter First Year Result 2015 Name Wise bie.telangana.gov.in

Official website

Incoming Search terms Telangana Inter  First Year Results:

First Year Results date
Intermediate results 2015 .
Inter First Year Regular date in 2015.
The first year, 2015, the date of declaration of results.
Online First Year Results.
Inter Results 2015 by the name.
The intermediate results of the 2015 college.
Inter Results 2015 Results Marks.
The results of the inter-MPC.
Inter Results 2015
Inter BiPC Results 2015 Results 2015
Inter Results 2015 Results 
{**Ts / Telangana Inter 1st year result 2015 Declared Check ...
www.techgames.org/2015/.../telangana-inter-1st-year-results-2015-declar...
2 hours ago - Telangana intermediate 1st year results 2015 College wise: Today TS Inter 1st Year Result 2015 Declared BIE Telangana Inter First Year ...
Telangana TS/TG Inter 1st Year jr IPE Result 2015 Online ...
govtjobslatest.in/2015/04/.../telangana-ts-tg-inter-1st-year-ipe-result-201...
6 hours ago - check out the IPE Telangana Inter First year results 2015, BIE Inter first year results 2015, TS Intermediate 2015 results, Telangana intermediate ...
Telangana Inter 1st Year Results Released at [www.Bie ...
www.gate2015resultsz.com/2015/04/telangana-inter-1st-year-results.html
19 hours ago - Telangana & AP Inter 1st Year 2nd Year Hall Tickets Download ... Now every student Telangana Inter 1st Year Results 2015 is waiting for.
Telangana Intermediate Results 2015 1st year/2nd year
telanganaintermediateresults2015.in/
Telangana inter 1st year improvement results 2014-2015 with marks: The results of state board Telangana inter test that was conducted within the month of Feb ...
Welcome to Board of Intermediate Education,AP
bieap.gov.in/
IPE March 2015 (GENERAL & VOCATIONAL) Time Table ... Permission to Intermediate Sanskrit and Arabic first year students to write the examination in the ...
Welcome to Board of Intermediate Education,AP
bie.telangana.gov.in/
Intermediate Public Examinations March, 2015 ?Grant of Exemption from attendance ... IPE MARCH 2014 - FIRST YEAR COLLEGE WISE RESULT ANALYSIS.
Telangana Inter 1st year Results 2015 - Telangana Results
www.telanganateachers.in/telangana-inter-1st-year-results-2015/
4 hours ago - Telangana Inter 1st year Results 2015 will be announced on 22nd April 2015. TS/Telangana Intermediate First Year Results 2015 will likely be ...
TS / Telangana Inter 1st Year Results 2015 Manabadi ...
www.dailyindia.org/ts-telangana-inter-first-1st-year-results-2015-released/
4 hours ago - Telangana State Intermediate First Year results 2015 are going to declare on April 22th (Wednesday). Students are eagerly waiting for the ...
AP Inter First year result 2015 - Gjobnews.in
gjobnews.in ? University Results
6 hours ago - AP Inter First year result 2015 / Andhra Pradesh Intermediate I Year Results 2015 expected to be released soon ? Check results ...
:: Board of Intermediate Education :: Login Form
bietelangana.cgg.gov.in/
Click here to Get I.P.E. March 2015 Hall Tickets First Year Second Year. Login. Please Enter User & Password. User Id : Password : Please Wait while Login.
Searches related to intermediate first year results 2015
manabadi intermediate first year results
intermediate first year results 2014 date
intermediate first year results 2013 name wise
intermediate first year improvement results 2013
ap intermediate first year results 2012
intermediate first year results 2011 with marks
board of intermediate first year results 2012
intermediate first year results 2012 with photo"-----------------

2. [New issue] IronPython console, run py file, change dir
http://ironpython.codeplex.com/workitem/43094
User dr43058 has proposed the issue:

"What does ">>>" mean in the IronPython console? And for that matter, can anyone point me to a decent link on the web that would "primer" me on this tool? 

I am trying to run the harness.py file from the IronPython command prompt. The file is found in this MSDN MAG written by James McCaffrey titled Request-Response Testing using IronPython. 

How do you change directories?

https://msdn.microsoft.com/en-us/magazine/ff955768.aspx

BTW, I cannot edit my own PATH variable, I am locked down by an admin, that is why I am not running it from CMD-PROMPT."
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150422/941587e6/attachment.html>

From dannyrosales at live.com  Wed Apr 22 22:23:30 2015
From: dannyrosales at live.com (daniel rosales)
Date: Wed, 22 Apr 2015 15:23:30 -0500
Subject: [Ironpython-users] harness.py to test request response in ASP.NET
Message-ID: <BAY180-W337F5132FD71212B8E36BAAEE0@phx.gbl>

James McCaffrey wrote an article in MSDN Mag  
https://msdn.microsoft.com/en-us/magazine/ff955768.aspx
It demonstrates how to use automate the testing of an ASP.NET WebForms MiniCalculate page. 
The specific issue is parsing out the hidden viewstate field. The article is from 2010 and I believe the viewstate field size has changed, causing later webforms pages with the greater viewstatew field size to be incompatible with the original McCaffrey code. fd
Please, can someone help me get the code to work? 
Here is the IRONPYTHON harness.py code...
# harness.py
import sysimport Systemimport clr
from System import *from System.IO import *from System.Text import *from System.Net import *from HTMLParser import HTMLParser
clr.AddReference('System.Web')from System.Web import *
class MyParser(HTMLParser):   def __init__(self):     #super().__init__(self)     HTMLParser.__init__(self)     #self.seen = {}
#d = dict([('two', 2), ('one', 1), ('three', 3)])	    def handle_starttag(self, tag, attributes):     if tag != 'input': return     a = dict(attributes)          if a['type'] == 'hidden':        print a['value']        return
def getVS(url):  wc = WebClient()  bytes = wc.DownloadData(url)  html = Encoding.ASCII.GetString(bytes)    print html  print 'starttag begin'  parser = MyParser()  return parser.feed(html)
  #start = html.IndexOf('id="__VIEWSTATE"', 0) + 24  #end = html.IndexOf('"', start)  #vs = html.Substring(start, end-start)  #return vs
def getEV(url):  wc = WebClient()  bytes = wc.DownloadData(url)  html = Encoding.ASCII.GetString(bytes)       start = html.IndexOf('id="__EVENTVALIDATION"', 0) + 30  end = html.IndexOf('"', start)  ev = html.Substring(start, end-start)  return ev
try:    print '\nBegin IronPython Request-Response testing'  print sys.argv[0]  url = 'http://localhost:64725/Default.aspx'  print '\nURL under test = ' + url + '\n'  testCases = 'testCases.txt'
  numPass = numFail = 0    filePath = 'C:\\Users\\daniel\\Downloads\\McCaffrey\\TestRun\\testCases.txt'   fin = open(filePath, 'r')    for line in fin:    print '======================================================================'    (caseid,value1,value2,operation,decimals,action,expected) = line.split('|')        expected = 'value="' + expected.Trim() + '" id="TextBox3"'    data = 'TextBox1=' + value1 + '&TextBox2=' + value2 + '&Operation=' + operation + '&DropDownList1=' + decimals + '&Button1=' + action      print 'Test case: ' + caseid    print 'Input    : ' + data    print 'Expected : ' + expected
    vs = getVS(url)    ev = getEV(url)    vs = HttpUtility.UrlEncode(vs)    ev = HttpUtility.UrlEncode(ev)    data = data + "&__VIEWSTATE=" + vs + "&__EVENTVALIDATION=" + ev     buffer = Encoding.ASCII.GetBytes(data)    req = HttpWebRequest.Create(url)	    #print '^^^^^^^^^^^^^^^^^^^^^^^^'    #print req.GetResponse().Headers	    req.Method = 'POST'    req.ContentType = 'application/x-www-form-urlencoded'	    print "**********************************"    print "buffer.Length = ",  buffer.Length	    req.ContentLength = buffer.Length
    reqst = req.GetRequestStream()    reqst.Write(buffer, 0, buffer.Length)    #reqst.Flush()    reqst.Close()        res = req.GetResponse()    resst = res.GetResponseStream()    sr = StreamReader(resst)
    html = sr.ReadToEnd()    sr.Close()    resst.Close()      if html.IndexOf(expected) >= 0:      print 'Pass'      numPass = numPass + 1    else:      print '**FAIL**'      numFail = numFail + 1
    print '======================================================================\n'
    # end main processing loop
  fin.close()
  print '\nNumber pass = ' + str(numPass)  print 'Number fail = ' + str(numFail)    print '\nEnd test run\n'
except System.Exception, e:  #type, value, traceback = sys.exc_info()  print e.Message
Thanks,
Danny Rosales
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150422/030c917e/attachment.html>

From sebasmagri at gmail.com  Fri Apr 24 20:46:34 2015
From: sebasmagri at gmail.com (=?UTF-8?B?U2ViYXN0acOhbiBNYWdyw60=?=)
Date: Fri, 24 Apr 2015 14:16:34 -0430
Subject: [Ironpython-users] Error running standalone exe using clrtype.py if
	IronPython is not installed
Message-ID: <CADmKEd6341P2D7v-biCNP3pOz8zAgTSDHSJA1ASp=oL3WukOOg@mail.gmail.com>

Hi!

I'm using clrtype.py to do some user32.dll integration and I'm creating a
standalone .exe which uses this integration.

When I run the .exe on a machine with IronPython installed, it works
flawlesly. However, If I run the .exe on a machine without IronPython, then
the I get a ValueError. The traceback of the error takes me to clrtype's
ClrClass.set_python_type_field() method:

---
Traceback (most recent call last):
  ...snip...
  File "clrtype", line 555, in __clrtype__
  File "clrtype", line 176, in create_type
  File "clrtype", line 536, in map_members
  File "clrtype", line 504, in set_python_type_field
ValueError: Object of type
'IronPython.NewTypes.IronPython.Runtime.Types.PythonType_3$3' cannot be
converted to type 'IronPython.Runtime.Types.PythonType'.
---

The class using the ClrClass metaclass is implemented as follows:

---
class NativeMethods(object):
    __metaclass__ = clrtype.ClrClass
    _clrnamespace = 'my.custom.namespace'

    dll_import = clrtype.attribute(DllImportAttribute)
    preserve_sig = clrtype.attribute(PreserveSigAttribute)

    @staticmethod
    @dll_import('user32.dll')
    @preserve_sig()
    @clrtype.accepts(int, int)
    @clrtype.returns(bool)
    def ShowWindow(hwnd, flag):
        raise RuntimeError('what are you doing here')

    @staticmethod
    @dll_import('user32.dll')
    @preserve_sig()
    @clrtype.accepts(int, int, int, int, int, int, int)
    @clrtype.returns(bool)
    def SetWindowPos(hwnd, insert_after_hwnd, x, y, w, h, flags):
        raise RuntimeError('what are you doing here')
---

I've been digging into this error and even looking at
IronPython.Runtime.Types but I've not found the possible cause of the issue.

Is there anything I'm missing here?

Best Regards,

-- 
Sebasti?n Ram?rez Magr?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150424/1aec308a/attachment.html>

From slide.o.mix at gmail.com  Fri Apr 24 20:59:10 2015
From: slide.o.mix at gmail.com (Slide)
Date: Fri, 24 Apr 2015 18:59:10 +0000
Subject: [Ironpython-users] Error running standalone exe using
 clrtype.py if IronPython is not installed
In-Reply-To: <CADmKEd6341P2D7v-biCNP3pOz8zAgTSDHSJA1ASp=oL3WukOOg@mail.gmail.com>
References: <CADmKEd6341P2D7v-biCNP3pOz8zAgTSDHSJA1ASp=oL3WukOOg@mail.gmail.com>
Message-ID: <CAPiUgVfy3SQW+M2CUx9-rResaQ6aOp_NOffgRux4YLzbsQ7TTA@mail.gmail.com>

How are you creating your exe?

On Fri, Apr 24, 2015, 11:55 Sebasti?n Magr? <sebasmagri at gmail.com> wrote:

> Hi!
>
> I'm using clrtype.py to do some user32.dll integration and I'm creating a
> standalone .exe which uses this integration.
>
> When I run the .exe on a machine with IronPython installed, it works
> flawlesly. However, If I run the .exe on a machine without IronPython, then
> the I get a ValueError. The traceback of the error takes me to clrtype's
> ClrClass.set_python_type_field() method:
>
> ---
> Traceback (most recent call last):
>   ...snip...
>   File "clrtype", line 555, in __clrtype__
>   File "clrtype", line 176, in create_type
>   File "clrtype", line 536, in map_members
>   File "clrtype", line 504, in set_python_type_field
> ValueError: Object of type
> 'IronPython.NewTypes.IronPython.Runtime.Types.PythonType_3$3' cannot be
> converted to type 'IronPython.Runtime.Types.PythonType'.
> ---
>
> The class using the ClrClass metaclass is implemented as follows:
>
> ---
> class NativeMethods(object):
>     __metaclass__ = clrtype.ClrClass
>     _clrnamespace = 'my.custom.namespace'
>
>     dll_import = clrtype.attribute(DllImportAttribute)
>     preserve_sig = clrtype.attribute(PreserveSigAttribute)
>
>     @staticmethod
>     @dll_import('user32.dll')
>     @preserve_sig()
>     @clrtype.accepts(int, int)
>     @clrtype.returns(bool)
>     def ShowWindow(hwnd, flag):
>         raise RuntimeError('what are you doing here')
>
>     @staticmethod
>     @dll_import('user32.dll')
>     @preserve_sig()
>     @clrtype.accepts(int, int, int, int, int, int, int)
>     @clrtype.returns(bool)
>     def SetWindowPos(hwnd, insert_after_hwnd, x, y, w, h, flags):
>         raise RuntimeError('what are you doing here')
> ---
>
> I've been digging into this error and even looking at
> IronPython.Runtime.Types but I've not found the possible cause of the issue.
>
> Is there anything I'm missing here?
>
> Best Regards,
>
> --
> Sebasti?n Ram?rez Magr?
>  _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150424/b72646e1/attachment.html>

From sebasmagri at gmail.com  Fri Apr 24 21:24:20 2015
From: sebasmagri at gmail.com (=?UTF-8?B?U2ViYXN0acOhbiBNYWdyw60=?=)
Date: Fri, 24 Apr 2015 14:54:20 -0430
Subject: [Ironpython-users] Error running standalone exe using
 clrtype.py if IronPython is not installed
In-Reply-To: <CAPiUgVfy3SQW+M2CUx9-rResaQ6aOp_NOffgRux4YLzbsQ7TTA@mail.gmail.com>
References: <CADmKEd6341P2D7v-biCNP3pOz8zAgTSDHSJA1ASp=oL3WukOOg@mail.gmail.com>
 <CAPiUgVfy3SQW+M2CUx9-rResaQ6aOp_NOffgRux4YLzbsQ7TTA@mail.gmail.com>
Message-ID: <CADmKEd6cGXB9x8WbpPRwwy=r81AiLDkJ2Z2jPJPvx_EZrf4LZQ@mail.gmail.com>

I'm using pyc.py with and a StdLib.dll, and other DLL dependencies. The
clrtype.py file is passed as an extra file to the pyc command.

   $ ipy pyc.py /standalone /target:winexe /out:myapp /main:app.py ...
clrtype.py

Regards,

2015-04-24 14:29 GMT-04:30 Slide <slide.o.mix at gmail.com>:

> How are you creating your exe?
>
> On Fri, Apr 24, 2015, 11:55 Sebasti?n Magr? <sebasmagri at gmail.com> wrote:
>
>> Hi!
>>
>> I'm using clrtype.py to do some user32.dll integration and I'm creating a
>> standalone .exe which uses this integration.
>>
>> When I run the .exe on a machine with IronPython installed, it works
>> flawlesly. However, If I run the .exe on a machine without IronPython, then
>> the I get a ValueError. The traceback of the error takes me to clrtype's
>> ClrClass.set_python_type_field() method:
>>
>> ---
>> Traceback (most recent call last):
>>   ...snip...
>>   File "clrtype", line 555, in __clrtype__
>>   File "clrtype", line 176, in create_type
>>   File "clrtype", line 536, in map_members
>>   File "clrtype", line 504, in set_python_type_field
>> ValueError: Object of type
>> 'IronPython.NewTypes.IronPython.Runtime.Types.PythonType_3$3' cannot be
>> converted to type 'IronPython.Runtime.Types.PythonType'.
>> ---
>>
>> The class using the ClrClass metaclass is implemented as follows:
>>
>> ---
>> class NativeMethods(object):
>>     __metaclass__ = clrtype.ClrClass
>>     _clrnamespace = 'my.custom.namespace'
>>
>>     dll_import = clrtype.attribute(DllImportAttribute)
>>     preserve_sig = clrtype.attribute(PreserveSigAttribute)
>>
>>     @staticmethod
>>     @dll_import('user32.dll')
>>     @preserve_sig()
>>     @clrtype.accepts(int, int)
>>     @clrtype.returns(bool)
>>     def ShowWindow(hwnd, flag):
>>         raise RuntimeError('what are you doing here')
>>
>>     @staticmethod
>>     @dll_import('user32.dll')
>>     @preserve_sig()
>>     @clrtype.accepts(int, int, int, int, int, int, int)
>>     @clrtype.returns(bool)
>>     def SetWindowPos(hwnd, insert_after_hwnd, x, y, w, h, flags):
>>         raise RuntimeError('what are you doing here')
>> ---
>>
>> I've been digging into this error and even looking at
>> IronPython.Runtime.Types but I've not found the possible cause of the issue.
>>
>> Is there anything I'm missing here?
>>
>> Best Regards,
>>
>> --
>> Sebasti?n Ram?rez Magr?
>>  _______________________________________________
>> Ironpython-users mailing list
>> Ironpython-users at python.org
>> https://mail.python.org/mailman/listinfo/ironpython-users
>>
>


-- 
Sebasti?n Ram?rez Magr?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150424/a1b7620f/attachment.html>

From jdhardy at gmail.com  Sun Apr 26 00:33:26 2015
From: jdhardy at gmail.com (Jeff Hardy)
Date: Sat, 25 Apr 2015 23:33:26 +0100
Subject: [Ironpython-users] import error: scapy on ironpython (windows)
In-Reply-To: <650E8E7A30AA6E4697EAF063DB83FB88014049B4@SJEXCHMB05.corp.ad.broadcom.com>
References: <650E8E7A30AA6E4697EAF063DB83FB88014049B4@SJEXCHMB05.corp.ad.broadcom.com>
Message-ID: <CAF7AXFHuNDH-pWDQexetM7k7Xq+m6f9Oeb5E=bftAP4Es+6oTg@mail.gmail.com>

On Mon, Apr 6, 2015 at 6:07 PM, Hemanth M B <hemanth at broadcom.com> wrote:
> Hi All,
>
>
>
> I am facing problem to import scapy.all in ironpython shell. It is throwing
> an error mentioned below:
>
>
>
>>>> from scapy.all import *
>
> Traceback (most recent call last):
>
>   File "<stdin>", line 1, in <module>
>
>   File "C:\Program Files (x86)\IronPython
> 2.7\lib\site-packages\scapy\all.py", line 16, in <module>
>
>   File "C:\Program Files (x86)\IronPython
> 2.7\lib\site-packages\scapy\arch\__init__.py", line 54, in <module>
>
> AttributeError: 'module' object has no attribute 'uname'
>
>
>
> Note:
>
> I have installed scapy using command ?ipy -X:Frames -m pip install scapy?
> and it got installed. As I verified with the scapy official website, one of
> the prerequisite is pywin32. At par to my knowledge ironpython doesn?t
> support pywin32.

Hi Hemanth,
Apologies for the delay, April has been ... interesting? ... for me.

You're right that IronPython does not support pywin32, because
IronPython doesn't support C extensions in general. In this specific
case it's probably because scapy checks for Windows using sys.platform
== 'win32' instead of os.name == 'nt' and it's trying to run a Unix
codepath (uname is the giveaway, it's part of os on Unix but not
Windows).

It might be possible to replace the calls into pywin32 with ctypes
calls but it would require changing scapy.

- Jeff

From jdhardy at gmail.com  Sun Apr 26 00:39:24 2015
From: jdhardy at gmail.com (Jeff Hardy)
Date: Sat, 25 Apr 2015 23:39:24 +0100
Subject: [Ironpython-users] Failing to read the standard output
In-Reply-To: <650E8E7A30AA6E4697EAF063DB83FB880140506F@SJEXCHMB05.corp.ad.broadcom.com>
References: <650E8E7A30AA6E4697EAF063DB83FB880140506F@SJEXCHMB05.corp.ad.broadcom.com>
Message-ID: <CAF7AXFGV9_p1nDF3hWs2FT8g3STZcvi4+7c5grWJb-xD1n8DHQ@mail.gmail.com>

On Thu, Apr 9, 2015 at 5:58 AM, Hemanth M B <hemanth at broadcom.com> wrote:
>
>
> Hi All,
>
>
>
> I am using System.Diagnostics namespace to spawn a console application. I
> want use asynchronous read and synchronous write, since the application is
> interactive. If I use synchronous read as mentioned below code, I need to
> close the stream writer before reading to end. Please help me to make code
> interactive.

Hi Hemanth,
This isn't really IronPython specific, so finding a similar solution
in C# you should be able to translate it fairly easily. In this case I
think you need to use the OutputDataReceived event and call
BeginOutputReadLine to start the process, then handle the output
events from the event handler.

Alternatively, call ReadLine in a separate thread so that it doesn't
block. This is a bit tricky to get right, so the event approach is
probably better depending on what you need to do with the output.

- Jeff

From jdhardy at gmail.com  Sun Apr 26 00:44:47 2015
From: jdhardy at gmail.com (Jeff Hardy)
Date: Sat, 25 Apr 2015 23:44:47 +0100
Subject: [Ironpython-users] AttributeError when using methods from a
 DirectShowLib Interface
In-Reply-To: <CADmKEd7WhgBOQM3oEK+fF9x3mLArmc1tzNUUh5T5_RwdpSm1QA@mail.gmail.com>
References: <CADmKEd7WhgBOQM3oEK+fF9x3mLArmc1tzNUUh5T5_RwdpSm1QA@mail.gmail.com>
Message-ID: <CAF7AXFEL23wskGpgsOAKGdZ+mnRnFMvWEx=F8d5=F_zpVZEdtA@mail.gmail.com>

On Wed, Apr 8, 2015 at 2:04 PM, Sebasti?n Magr? <sebasmagri at gmail.com> wrote:
> Hi!
>
> I'm trying to use DirectShowLib for some basic media detection with the
> `IMediaDet` interface. However, trying to use methods of the interface from
> the instance throws `AttributeError` every time.

Hi Sebasti?n,
Apologies for the delayed response, it's been a busy month.

I'm not sure which DirectShowLib you're using (Google has a few
options) so I'm basing this on code from
https://github.com/larrybeall/DirectShowLib/blob/master/DirectShowLib/DES.cs.

>
> This is the script I'm using to test:
>
> ---
>     import clr
>
>     clr.AddReference('DirectShowLib')
>
>     from DirectShowLib.DES import IMediaDet, DESError
>
>
>     class Detector(IMediaDet):
>         def __init__(self, *args, **kwargs):
>             super(Detector, self).__init__(*args, **kwargs)
>
>
>     mdet = Detector()
>
>     print('Detector: {}\n'.format(mdet))
>     print('Detector dir: {}\n'.format(dir(mdet)))
>     print('Detector.put_Filename: {}\n'.format(mdet.put_Filename))
>     print('Detector.put_Filename dir: {}\n'.format(dir(mdet.put_Filename)))
>     print('Detector.put_Filename.Overloads: {}\n'.format(
>         mdet.put_Filename.Overloads
>     ))
>     print('Detector.put_Filename.Overloads dir: {}\n'.format(
>         dir(mdet.put_Filename.Overloads)
>     ))
>     print('Detector object is instance of IMediaDet: {}\n'.format(
>         isinstance(mdet, IMediaDet)
>     ))
>     mdet.put_Filename('VID_20150207_133726.mp4')
> ---
>
> And it prints the following information, finally throwing an error when I
> try to use the method:
>

I don't know how smart IronPython's COM integration is (DinoV wrote
it) but it's possible its converting the put_/get_ methods to a
property? Try just calling Detector.Filename and see if that works.

- Jeff

From jdhardy at gmail.com  Sun Apr 26 01:09:29 2015
From: jdhardy at gmail.com (Jeff Hardy)
Date: Sun, 26 Apr 2015 00:09:29 +0100
Subject: [Ironpython-users] Example for using AppDomain
In-Reply-To: <A8744B73D4D1664F908F7BC00A278981194443@IRVEXCHMB15.corp.ad.broadcom.com>
References: <A8744B73D4D1664F908F7BC00A278981194443@IRVEXCHMB15.corp.ad.broadcom.com>
Message-ID: <CAF7AXFGZZkxgU3W77wFUQ2Q8_EqA7DPKgUDj-KOhwutxtiuQfw@mail.gmail.com>

On Thu, Apr 9, 2015 at 7:06 PM, Vinh Ton <tvinh at broadcom.com> wrote:
> Hi,
>
>
>
> Can someone post an example for running IronPython in a separate AddDomain.

This StackOverflow question has some example code:
http://stackoverflow.com/questions/1362757/how-to-host-an-ironpython-engine-in-a-separate-appdomain.

- Jeff

From jdhardy at gmail.com  Sun Apr 26 01:14:51 2015
From: jdhardy at gmail.com (Jeff Hardy)
Date: Sun, 26 Apr 2015 00:14:51 +0100
Subject: [Ironpython-users] Error running standalone exe using
 clrtype.py if IronPython is not installed
In-Reply-To: <CADmKEd6cGXB9x8WbpPRwwy=r81AiLDkJ2Z2jPJPvx_EZrf4LZQ@mail.gmail.com>
References: <CADmKEd6341P2D7v-biCNP3pOz8zAgTSDHSJA1ASp=oL3WukOOg@mail.gmail.com>
 <CAPiUgVfy3SQW+M2CUx9-rResaQ6aOp_NOffgRux4YLzbsQ7TTA@mail.gmail.com>
 <CADmKEd6cGXB9x8WbpPRwwy=r81AiLDkJ2Z2jPJPvx_EZrf4LZQ@mail.gmail.com>
Message-ID: <CAF7AXFEpji=07dVLLVhuvf7AeDxSqY3BmtD5N4+i_4ZA2i51wg@mail.gmail.com>

It's the sort of error I would expect if there was an assembly version
mismatch, but that usually goes the other way - installed IronPython
breaking embedded/hosted IronPython. Maybe break out fuslogvw and see
which assemblies are being loaded?

As an aside: I'm impressed clrtypes.py works *at all*. I don't think
there are any tests covering it :(

- Jeff

On Fri, Apr 24, 2015 at 8:24 PM, Sebasti?n Magr? <sebasmagri at gmail.com> wrote:
> I'm using pyc.py with and a StdLib.dll, and other DLL dependencies. The
> clrtype.py file is passed as an extra file to the pyc command.
>
>    $ ipy pyc.py /standalone /target:winexe /out:myapp /main:app.py ...
> clrtype.py
>
> Regards,
>
> 2015-04-24 14:29 GMT-04:30 Slide <slide.o.mix at gmail.com>:
>
>> How are you creating your exe?
>>
>>
>> On Fri, Apr 24, 2015, 11:55 Sebasti?n Magr? <sebasmagri at gmail.com> wrote:
>>>
>>> Hi!
>>>
>>> I'm using clrtype.py to do some user32.dll integration and I'm creating a
>>> standalone .exe which uses this integration.
>>>
>>> When I run the .exe on a machine with IronPython installed, it works
>>> flawlesly. However, If I run the .exe on a machine without IronPython, then
>>> the I get a ValueError. The traceback of the error takes me to clrtype's
>>> ClrClass.set_python_type_field() method:
>>>
>>> ---
>>> Traceback (most recent call last):
>>>   ...snip...
>>>   File "clrtype", line 555, in __clrtype__
>>>   File "clrtype", line 176, in create_type
>>>   File "clrtype", line 536, in map_members
>>>   File "clrtype", line 504, in set_python_type_field
>>> ValueError: Object of type
>>> 'IronPython.NewTypes.IronPython.Runtime.Types.PythonType_3$3' cannot be
>>> converted to type 'IronPython.Runtime.Types.PythonType'.
>>> ---
>>>
>>> The class using the ClrClass metaclass is implemented as follows:
>>>
>>> ---
>>> class NativeMethods(object):
>>>     __metaclass__ = clrtype.ClrClass
>>>     _clrnamespace = 'my.custom.namespace'
>>>
>>>     dll_import = clrtype.attribute(DllImportAttribute)
>>>     preserve_sig = clrtype.attribute(PreserveSigAttribute)
>>>
>>>     @staticmethod
>>>     @dll_import('user32.dll')
>>>     @preserve_sig()
>>>     @clrtype.accepts(int, int)
>>>     @clrtype.returns(bool)
>>>     def ShowWindow(hwnd, flag):
>>>         raise RuntimeError('what are you doing here')
>>>
>>>     @staticmethod
>>>     @dll_import('user32.dll')
>>>     @preserve_sig()
>>>     @clrtype.accepts(int, int, int, int, int, int, int)
>>>     @clrtype.returns(bool)
>>>     def SetWindowPos(hwnd, insert_after_hwnd, x, y, w, h, flags):
>>>         raise RuntimeError('what are you doing here')
>>> ---
>>>
>>> I've been digging into this error and even looking at
>>> IronPython.Runtime.Types but I've not found the possible cause of the issue.
>>>
>>> Is there anything I'm missing here?
>>>
>>> Best Regards,
>>>
>>> --
>>> Sebasti?n Ram?rez Magr?
>>> _______________________________________________
>>> Ironpython-users mailing list
>>> Ironpython-users at python.org
>>> https://mail.python.org/mailman/listinfo/ironpython-users
>
>
>
>
> --
> Sebasti?n Ram?rez Magr?
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>

From hemanth at broadcom.com  Mon Apr 27 13:26:27 2015
From: hemanth at broadcom.com (Hemanth M B)
Date: Mon, 27 Apr 2015 11:26:27 +0000
Subject: [Ironpython-users] Error while using setupapi.dll (windll) ctypes
Message-ID: <650E8E7A30AA6E4697EAF063DB83FB880283710D@SJEXCHMB05.corp.ad.broadcom.com>

Hi All,

I am getting error when I execute the code below:

Code:

from ctypes import *
#from ctypes import create_string_buffer
from ctypes import WINFUNCTYPE
from ctypes.wintypes import HWND, DWORD, LPCSTR
pcc = windll.LoadLibrary(r"C:\Windows\System32\setupapi.dll")
prototype =WINFUNCTYPE(c_int, c_char, LPCSTR, HWND, DWORD)
paramflags = (1, "_ClassGuid", None), (1, "_Enumerator", None), (1, "_hwndParent", None), (1, "_Flags", 0)
setupapis = prototype(("SetupDiGetClassDevsA", pcc), paramflags)
print setupapis

Error:

C:\Users\Administrator\git\localrepo>"C:\Program Files (x86)\IronPython 2.7\ipy.exe" NX1_Setuptools\getdevclass.py
Traceback (most recent call last):
  File "NX1_Setuptools\getdevclass.py", line 9, in <module>
TypeError: expected int, got tuple

I got to know that it is expecting int data types but it got tuple.

Note:
I followed the documentation in https://ironpython-test.readthedocs.org/en/latest/library/ctypes.html ,section 15.18.2.4. Function prototypes

I am trying to install device drivers for network adapter, so I need HDEVINFO. Please help me resolve this.

Thanks and Regards,
Hemanth M B
@9010054054

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150427/d4cac57b/attachment.html>

From alain at mcneel.com  Wed Apr 29 11:13:51 2015
From: alain at mcneel.com (Alain Cormier)
Date: Wed, 29 Apr 2015 11:13:51 +0200
Subject: [Ironpython-users] PTVS "attach to process" can't see IP in
	embedded process
Message-ID: <CALrd2BUJvx5CBwz7NZSb5JCby_+Ws+q7wVVrqfWAy533=gCbjg@mail.gmail.com>

Hi everyone,

I'm trying to get PTVS to a native app that embeds IP.

My script starts with
   import ptvsd
   ptvsd.enable_attach(None)

I have no problems attaching to ipy.exe if I run the script from there but
what do I need to do to make VS detect the embedded IP (Frames and Tracing
enabled) from my (native, c++) hosting app?

Thanks,
Alain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150429/57375392/attachment.html>

From kerray.cz at gmail.com  Wed Apr 29 17:31:28 2015
From: kerray.cz at gmail.com (Kerray)
Date: Wed, 29 Apr 2015 17:31:28 +0200
Subject: [Ironpython-users] WDB web debugger for IronPython
In-Reply-To: <CAM5UpT46qjmuEmAsg0y6grQ=LUWBRpjy7A9H9jx3V2H4EciYpw@mail.gmail.com>
References: <CAM5UpT4gmnrGYOW09fOV8dstJgFAqTzTozFQFnKbaTxfFdDUEA@mail.gmail.com>
 <CA+7connFNByOA3UQb4TP829+OmxLC-HL4Zaq=pcbfuKocaXXNg@mail.gmail.com>
 <CAM5UpT4zXWrqVM3CnvNG3reXREpXaP1RKrbGupBgg21mQ-Z0jA@mail.gmail.com>
 <CAF7AXFFEP+JXzmJ+KX34e=wKAcYOp9vfO1Tz08xujC17UE89qg@mail.gmail.com>
 <CAM5UpT46qjmuEmAsg0y6grQ=LUWBRpjy7A9H9jx3V2H4EciYpw@mail.gmail.com>
Message-ID: <CAM5UpT5fTX3W2x3gxbuaEYOcjg4cb7wxYOb05VfBciKWGXBxqQ@mail.gmail.com>

Hi,
it's been a while, but I've now again tried running the remote debugger
https://github.com/Kozea/wdb client under IronPython.

As J.Hardy wrote earlier, based on the stack trace I included:
> Looks like one of the generator rewriters has a bug. I can't come up with
a simple case to reproduce this, though. It's failing when switching from
interpreted to compiled (LambdaExpression.Compile) but I'm not sure how to
trip that right now, for if it's specific to the code it's compiling.

I've now found that the function it's attempting to compile when it crashes
is findlinestarts(code) in dis.py, which is a generator - and even if I
delete its body and let it yield a tuple with two const ints, it still
fails the same way (!).

When I replace the call to the function in wdb/__init__.py 608 with the
tuple I made up ((111, 222), (333, 444)) the debugger client successfully
connects to the server, shows the file source etc.

Nevertheless it seems there's nothing wrong with findlinestarts(code)
itself, it only fails in this specific context...

The InvalidCastException gets thrown in the VisitAssign when there's
a ($tuple.Item008).Value on the left side

I've pasted the the DebugView contents for the expression which goes
into LambdaExpression.Compile
to http://pastebin.com/TNX6UUPe
The part for which the InvalidCast is thrown is 146-148

But I'm still stuck.


It's easy to replicate this whole thing
- download wdb
- install wdb.client in IPy using setup.py
- run wdb/server/wdb.server.py in regular Python
- then ipy.exe -X:FullFrames -c "import wdb; wdb.set_trace(); raw_input();
print 1"

I use the raw_input so that I can connect the VS debugger to ipy.exe


Thanks for any pointers - I'm prepared to spend more time on this issue,
but I'm out of ideas about what to try next.

Is there anything more I can try to look at?

How do I isolate this issue?


But anyway, thank you guys


kerray

On Wed, Dec 3, 2014 at 3:31 PM, Kerray <kerray.cz at gmail.com> wrote:

> Hi Jeff,
> I've opened the issue with IPV6_V6ONLY -
> https://github.com/IronLanguages/main/issues/238
> And I'll open one for the Tornado socket problem also.
>
> Other than that, I can successfuly run
> import wdb
> w = wdb.set_trace()
> in console and examine the contents of the resulting Wdb object (it seems
> allright, I can print most attributes etc.) but it doesn't matter what code
> I run after that - it fails with a variable assignment, with print etc.
>
> The code object that gets passed at that moment into the
> dis.findlinestarts() call which results in crash has these attributes:
> co_argcount: 1
> co_cellvars: ()
> co_code:
> co_consts: (None,)
> co_filename: IronPython\27\Lib\threading.py
> co_firstlineno: 774
> co_flags: 0
> co_freevars: ()
> co_lnotab:
> co_name: _exitfunc
> co_names: ('_pickSomeNonDaemonThread', '__debug__')
> co_nlocals: 2
> co_stacksize:
> co_varnames: ('self', 't')
>
> When the VS debugger is attached, first it comes up with a "call stack is
> not deep enough" exception
>    at IronPython.Modules.SysModule._getframeImpl(CodeContext context,
> Int32 depth, List`1 stack) in
> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Modules\sys.cs:line
> 212
>    at IronPython.Modules.SysModule._getframeImpl(CodeContext context,
> Int32 depth) in
> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Modules\sys.cs:line
> 183
>    at
> Microsoft.Scripting.Interpreter.FuncCallInstruction`3.Run(InterpretedFrame
> frame)
>    at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame
> frame)
>
> the context parameter of the _getFrameImpl call is the logging module,
> depth 3
>
> And only after continuing through this exception several times do I get to
> the point where the original "Unable to cast object of type
> 'System.Linq.Expressions.FieldExpression' to type
> 'System.Linq.Expressions.BlockExpression'." exception comes up.
>
> But it's fairly easy to get the same results running the wdb server in
> Python and the client in IronPython with X:FullFrames.
>
> I can't think of any other way I could be of help, but I'm open to
> suggestions :)
>
> Thanks anyway!
>
> JM
>
>
> On Wed, Nov 26, 2014 at 12:03 AM, Jeff Hardy <jdhardy at gmail.com> wrote:
>
>> On Tue, Nov 25, 2014 at 12:32 PM, Kerray <kerray.cz at gmail.com> wrote:
>>
>>> Hi,
>>> very good point, I've been on beta3. But the upgrade didn't help. I've
>>> figured out how to debug the internals in VS, but there's nothing I could
>>> be able to fix (or even understand) myself at this point.
>>>
>>> ad 1) after running wdb.server, Tornado at first says
>>> \tornado\netutil.py", line 88, in bind_sockets
>>> AttributeError: 'module' object has no attribute 'IPV6_V6ONLY'
>>> When I comment the whole if section out, it starts the loop and waits
>>> for connections.
>>>
>>
>> Can you open an issue for this? Should be straightforward, if .NET
>> supports IPv6 only connections. Might have to wait to 2.7.6 though. In the
>> meantime you can add `hasatter(socket, 'IPV6_V6ONLY')` to the if.
>>
>>
>>>
>>> Running the client, the server reports this and continues listening:
>>> Connection received from ('127.0.0.1', 1518)
>>> [E 141125 11:51:35 stack_context:1] Exception in I/O handler for fd 1616
>>>     Traceback (most recent call last):
>>>       File "-\tornado\stack_context.py", line 304, in wrapped
>>>         ret = fn(*args, **kwargs)
>>>       File "-\tornado\netutil.py", line 154, in accept_handler
>>>         callback(connection, address)
>>>       File "-\wdb_server\streams.py", line 95, in handle_connection
>>>         stream.read_bytes(4, partial(read_uuid_size, stream))
>>>       File "-\tornado\iostream.py", line 168, in read_bytes
>>>         self._try_inline_read()
>>>       File "-\tornado\iostream.py", line 424, in _try_inline_read
>>>         if self._read_to_buffer() == 0:
>>>       File "-\tornado\iostream.py", line 447, in _read_to_buffer
>>>         chunk = self.read_from_fd()
>>>       File "-\tornado\iostream.py", line 686, in read_from_fd
>>>         chunk = self.socket.recv(self.read_chunk_size)
>>>     error: [Errno 10022] A request to send or receive data was
>>> disallowed because the socket is not connected and (when sending on a
>>> datagram socket using a sendto call) no address was supplied
>>>
>>> And the client crashes with
>>> wdb\client\wdb\_compat.py", line 165, in send_bytes
>>> socket.error: [Errno 10053] An established connection was aborted by the
>>> software in your host machine
>>>
>>> When trying to debug this in VS, I came to the conclusion that the
>>> Tornado server's socket handling (or my commenting out a piece, or
>>> something else inside Tornado running under IronPython-) is at fault, since
>>> it's not true what I've written previously (that a message gets
>>> communicated and then coms fail) - in fact nothing gets communicated, it
>>> crashes in the client on trying to send the first message using socket.cs
>>> sendallWorker(byte[] buffer, int flags).
>>>
>>
>> Not sure why it would not be connected, but I presume Tornado tries to
>> configure the sockets as non-blocking; it's possible that gets IronPython
>> confused.
>>
>>
>>>
>>>
>>> ad 2) running the server in Python and client in IronPython, I get a bit
>>> further, but the error is the same - the client in IronPython reports
>>> Launching browser and wait for connection
>>> Exception Traceback (most recent call last):
>>>   File "-\wdb\client\wdb\__init__.py", line 291, in trace_debug_dispatch
>>>   File "-\wdb\client\wdb\__init__.py", line 250, in trace_dispatch
>>>   File "-\wdb\client\wdb\__init__.py", line 686, in handle_call
>>>   File "-\wdb\client\wdb\__init__.py", line 660, in interaction
>>>   File "-\wdb\client\wdb\ui.py", line 80, in __init__
>>>   File "-\wdb\client\wdb\__init__.py", line 575, in get_trace
>>> TypeError: Unable to cast object of type
>>> 'System.Linq.Expressions.FieldExpression' to type
>>> 'System.Linq.Expressions.BlockExpression'.
>>>
>>> It's the same place and line of code I mentioned in my previous mail:
>>> > startlnos = dis.findlinestarts(code)
>>>
>>> Debugging in VS yields an impressive stack trace, but I don't have any
>>> idea where to start with this, so again - I'll be very grateful for any
>>> pointers.
>>>
>>
>> Looks like one of the generator rewriters has a bug. I can't come up with
>> a simple case to reproduce this, though. It's failing when switching from
>> interpreted to compiled (LambdaExpression.Compile) but I'm not sure how to
>> trip that right now, for if it's specific to the code it's compiling.
>>
>> - Jeff
>>
>>
>>> Thanks - for even reading this far.
>>>
>>>
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitAssign(BinaryExpression
>>> node) in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 831
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBinary(BinaryExpression
>>> node) in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 876
>>>    at System.Linq.Expressions.BinaryExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at
>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>> in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 595
>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at
>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>> in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 595
>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at
>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>> in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 595
>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at
>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>> in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 595
>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at
>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>> in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 595
>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at Microsoft.Scripting.Ast.GeneratorRewriter.VisitTry(TryExpression
>>> node) in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 297
>>>    at System.Linq.Expressions.TryExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at
>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>> in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 595
>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at
>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>> in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 595
>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at
>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>> in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 595
>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at
>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>> in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 595
>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at
>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>> in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 595
>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at
>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>> in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 595
>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at
>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>> in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 595
>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at
>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>> in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 595
>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitAssign(BinaryExpression
>>> node) in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 789
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBinary(BinaryExpression
>>> node) in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 876
>>>    at System.Linq.Expressions.BinaryExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at
>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>> in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 595
>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at
>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>    at
>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>> in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 595
>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>> visitor)
>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>    at Microsoft.Scripting.Ast.GeneratorRewriter.Reduce() in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>> 100
>>>    at Microsoft.Scripting.Ast.GeneratorExpression.Reduce() in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorExpression.cs:line
>>> 94
>>>    at System.Linq.Expressions.Expression.ReduceAndCheck()
>>>    at System.Linq.Expressions.Expression.ReduceExtensions()
>>>    at
>>> System.Linq.Expressions.Compiler.StackSpiller.RewriteExtensionExpression(Expression
>>> expr, Stack stack)
>>>    at
>>> System.Linq.Expressions.Compiler.StackSpiller.RewriteExpression(Expression
>>> node, Stack stack)
>>>    at
>>> System.Linq.Expressions.Compiler.StackSpiller.RewriteExpressionFreeTemps(Expression
>>> expression, Stack stack)
>>>    at
>>> System.Linq.Expressions.Compiler.StackSpiller.Rewrite[T](Expression`1
>>> lambda)
>>>    at System.Linq.Expressions.Expression`1.Accept(StackSpiller spiller)
>>>    at
>>> System.Linq.Expressions.Compiler.LambdaCompiler.Compile(LambdaExpression
>>> lambda, DebugInfoGenerator debugInfoGenerator)
>>>    at System.Linq.Expressions.LambdaExpression.Compile()
>>>    at
>>> Microsoft.Scripting.Debugging.DebuggableLambdaBuilder.CreateFunctionInfo(LambdaExpression
>>> generatorFactoryLambda) in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Debugging\DebuggableLambdaBuilder.cs:line
>>> 386
>>>    at
>>> Microsoft.Scripting.Debugging.DebuggableLambdaBuilder.TransformLambda(LambdaExpression
>>> lambda) in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Debugging\DebuggableLambdaBuilder.cs:line
>>> 171
>>>    at
>>> Microsoft.Scripting.Debugging.DebuggableLambdaBuilder.Transform(LambdaExpression
>>> lambda) in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Debugging\DebuggableLambdaBuilder.cs:line
>>> 111
>>>    at
>>> Microsoft.Scripting.Debugging.CompilerServices.DebugContext.TransformLambda(LambdaExpression
>>> lambda, DebugLambdaInfo lambdaInfo) in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Debugging\DebugContext.cs:line
>>> 68
>>>    at
>>> IronPython.Runtime.FunctionCode.<>c__DisplayClass1a.<GetGeneratorOrNormalLambdaTracing>b__19(Expression`1
>>> x) in
>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Runtime\FunctionCode.cs:line
>>> 787
>>>    at IronPython.Compiler.GeneratorRewriter.Reduce(Boolean
>>> shouldInterpret, Boolean emitDebugSymbols, Int32 compilationThreshold,
>>> IList`1 parameters, Func`2 bodyConverter) in
>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Compiler\GeneratorRewriter.cs:line
>>> 147
>>>    at
>>> IronPython.Runtime.FunctionCode.GetGeneratorOrNormalLambdaTracing(PythonContext
>>> context) in
>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Runtime\FunctionCode.cs:line
>>> 777
>>>    at IronPython.Runtime.FunctionCode.UpdateDelegate(PythonContext
>>> context, Boolean forceCreation) in
>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Runtime\FunctionCode.cs:line
>>> 717
>>>    at
>>> IronPython.Runtime.FunctionCode.LazyCompileFirstTarget(PythonFunction
>>> function) in
>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Runtime\FunctionCode.cs:line
>>> 697
>>>    at
>>> IronPython.Compiler.PythonCallTargets.OriginalCallTarget1(PythonFunction
>>> function, Object arg0) in
>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Compiler\PythonCallTargets.cs:line
>>> 42
>>>    at IronPython.Runtime.FunctionCaller`1.Call1(CallSite site,
>>> CodeContext context, Object func, T0 arg0) in
>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Runtime\PythonFunction.Generated.cs:line
>>> 420
>>>    at
>>> System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite
>>> site, T0 arg0, T1 arg1, T2 arg2)
>>>    at get_trace$495(Closure , PythonFunction , Object , Object , Object )
>>>    at
>>> IronPython.Compiler.PythonFunctionRecursionCheck3.CallTarget(PythonFunction
>>> function, Object arg0, Object arg1, Object arg2) in
>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Compiler\PythonCallTargets.cs:line
>>> 273
>>>    at
>>> IronPython.Compiler.PythonCallTargets.OriginalCallTarget3(PythonFunction
>>> function, Object arg0, Object arg1, Object arg2) in
>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Compiler\PythonCallTargets.cs:line
>>> 53
>>>    at IronPython.Runtime.FunctionCaller`3.Call3(CallSite site,
>>> CodeContext context, Object func, T0 arg0, T1 arg1, T2 arg2) in
>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Runtime\PythonFunction.Generated.cs:line
>>> 676
>>>    at
>>> System.Dynamic.UpdateDelegates.UpdateAndExecute5[T0,T1,T2,T3,T4,TRet](CallSite
>>> site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
>>>    at CallSite.Target(Closure , CallSite , CodeContext , Object , Object
>>> , Object , Object )
>>>    at IronPython.Runtime.Method.MethodBinding`2.SelfTarget(CallSite
>>> site, CodeContext context, Object target, T0 arg0, T1 arg1) in
>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Runtime\Method.Generated.cs:line
>>> 195
>>>    at
>>> System.Dynamic.UpdateDelegates.UpdateAndExecute4[T0,T1,T2,T3,TRet](CallSite
>>> site, T0 arg0, T1 arg1, T2 arg2, T3 arg3)
>>>    at
>>> Microsoft.Scripting.Interpreter.DynamicInstruction`5.Run(InterpretedFrame
>>> frame) in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Interpreter\Instructions\DynamicInstructions.Generated.cs:line
>>> 218
>>>    at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame
>>> frame) in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Interpreter\Interpreter.cs:line
>>> 132
>>>    at
>>> Microsoft.Scripting.Interpreter.LightLambda.Run10[T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,TRet](T0
>>> arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6, T7 arg7, T8
>>> arg8, T9 arg9) in
>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Interpreter\LightLambda.Generated.cs:line
>>> 417
>>>    at
>>> IronPython.Compiler.PythonFunctionRecursionCheck9.CallTarget(PythonFunction
>>> function, Object arg0, Object arg1, Object arg2, Object arg3, Object arg4,
>>> Object arg5, Object arg6, Object arg7, Object arg8) in
>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Compiler\PythonCallTargets.cs:line
>>> 375
>>>    at
>>> IronPython.Compiler.PythonCallTargets.OriginalCallTarget9(PythonFunction
>>> function, Object arg0, Object arg1, Object arg2, Object arg3, Object arg4,
>>> Object arg5, Object arg6, Object arg7, Object arg8) in
>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Compiler\PythonCallTargets.cs:line
>>> 83
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150429/e896af96/attachment.html>

From kerray.cz at gmail.com  Thu Apr 30 10:55:56 2015
From: kerray.cz at gmail.com (Kerray)
Date: Thu, 30 Apr 2015 10:55:56 +0200
Subject: [Ironpython-users] WDB web debugger for IronPython
In-Reply-To: <CAM5UpT5fTX3W2x3gxbuaEYOcjg4cb7wxYOb05VfBciKWGXBxqQ@mail.gmail.com>
References: <CAM5UpT4gmnrGYOW09fOV8dstJgFAqTzTozFQFnKbaTxfFdDUEA@mail.gmail.com>
 <CA+7connFNByOA3UQb4TP829+OmxLC-HL4Zaq=pcbfuKocaXXNg@mail.gmail.com>
 <CAM5UpT4zXWrqVM3CnvNG3reXREpXaP1RKrbGupBgg21mQ-Z0jA@mail.gmail.com>
 <CAF7AXFFEP+JXzmJ+KX34e=wKAcYOp9vfO1Tz08xujC17UE89qg@mail.gmail.com>
 <CAM5UpT46qjmuEmAsg0y6grQ=LUWBRpjy7A9H9jx3V2H4EciYpw@mail.gmail.com>
 <CAM5UpT5fTX3W2x3gxbuaEYOcjg4cb7wxYOb05VfBciKWGXBxqQ@mail.gmail.com>
Message-ID: <CAM5UpT49aYG1D9V06iRm=H=fPbH2PNHW+9fA8OaY6YGEgDwJGg@mail.gmail.com>

In other news, I've been trying to isolate the issue and finally found out
that dis.py findlinestarts(code) is throwing a NotImplemented when trying
to access code.co_lnotab, which is not implemented in IronPython -
http://www.nudoq.org/#!/Packages/IronPython/IronPython/FunctionCode/P/co_lnotab

So that's probably it, and now it's only a question why instead of
reporting this error it spins off into trying to compile and optimize this
function.

And I'm off trying to find out if I can make the debugger work.

Thanks for reading :)

On Wed, Apr 29, 2015 at 5:31 PM, Kerray <kerray.cz at gmail.com> wrote:

> Hi,
> it's been a while, but I've now again tried running the remote debugger
> https://github.com/Kozea/wdb client under IronPython.
>
> As J.Hardy wrote earlier, based on the stack trace I included:
> > Looks like one of the generator rewriters has a bug. I can't come up
> with a simple case to reproduce this, though. It's failing when switching
> from interpreted to compiled (LambdaExpression.Compile) but I'm not sure
> how to trip that right now, for if it's specific to the code it's compiling.
>
> I've now found that the function it's attempting to compile when it
> crashes is findlinestarts(code) in dis.py, which is a generator - and even
> if I delete its body and let it yield a tuple with two const ints, it still
> fails the same way (!).
>
> When I replace the call to the function in wdb/__init__.py 608 with the
> tuple I made up ((111, 222), (333, 444)) the debugger client successfully
> connects to the server, shows the file source etc.
>
> Nevertheless it seems there's nothing wrong with findlinestarts(code)
> itself, it only fails in this specific context...
>
> The InvalidCastException gets thrown in the VisitAssign when there's
> a ($tuple.Item008).Value on the left side
>
> I've pasted the the DebugView contents for the expression which goes into LambdaExpression.Compile
> to http://pastebin.com/TNX6UUPe
> The part for which the InvalidCast is thrown is 146-148
>
> But I'm still stuck.
>
>
> It's easy to replicate this whole thing
> - download wdb
> - install wdb.client in IPy using setup.py
> - run wdb/server/wdb.server.py in regular Python
> - then ipy.exe -X:FullFrames -c "import wdb; wdb.set_trace(); raw_input();
> print 1"
>
> I use the raw_input so that I can connect the VS debugger to ipy.exe
>
>
> Thanks for any pointers - I'm prepared to spend more time on this issue,
> but I'm out of ideas about what to try next.
>
> Is there anything more I can try to look at?
>
> How do I isolate this issue?
>
>
> But anyway, thank you guys
>
>
> kerray
>
> On Wed, Dec 3, 2014 at 3:31 PM, Kerray <kerray.cz at gmail.com> wrote:
>
>> Hi Jeff,
>> I've opened the issue with IPV6_V6ONLY -
>> https://github.com/IronLanguages/main/issues/238
>> And I'll open one for the Tornado socket problem also.
>>
>> Other than that, I can successfuly run
>> import wdb
>> w = wdb.set_trace()
>> in console and examine the contents of the resulting Wdb object (it seems
>> allright, I can print most attributes etc.) but it doesn't matter what code
>> I run after that - it fails with a variable assignment, with print etc.
>>
>> The code object that gets passed at that moment into the
>> dis.findlinestarts() call which results in crash has these attributes:
>> co_argcount: 1
>> co_cellvars: ()
>> co_code:
>> co_consts: (None,)
>> co_filename: IronPython\27\Lib\threading.py
>> co_firstlineno: 774
>> co_flags: 0
>> co_freevars: ()
>> co_lnotab:
>> co_name: _exitfunc
>> co_names: ('_pickSomeNonDaemonThread', '__debug__')
>> co_nlocals: 2
>> co_stacksize:
>> co_varnames: ('self', 't')
>>
>> When the VS debugger is attached, first it comes up with a "call stack is
>> not deep enough" exception
>>    at IronPython.Modules.SysModule._getframeImpl(CodeContext context,
>> Int32 depth, List`1 stack) in
>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Modules\sys.cs:line
>> 212
>>    at IronPython.Modules.SysModule._getframeImpl(CodeContext context,
>> Int32 depth) in
>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Modules\sys.cs:line
>> 183
>>    at
>> Microsoft.Scripting.Interpreter.FuncCallInstruction`3.Run(InterpretedFrame
>> frame)
>>    at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame
>> frame)
>>
>> the context parameter of the _getFrameImpl call is the logging module,
>> depth 3
>>
>> And only after continuing through this exception several times do I get
>> to the point where the original "Unable to cast object of type
>> 'System.Linq.Expressions.FieldExpression' to type
>> 'System.Linq.Expressions.BlockExpression'." exception comes up.
>>
>> But it's fairly easy to get the same results running the wdb server in
>> Python and the client in IronPython with X:FullFrames.
>>
>> I can't think of any other way I could be of help, but I'm open to
>> suggestions :)
>>
>> Thanks anyway!
>>
>> JM
>>
>>
>> On Wed, Nov 26, 2014 at 12:03 AM, Jeff Hardy <jdhardy at gmail.com> wrote:
>>
>>> On Tue, Nov 25, 2014 at 12:32 PM, Kerray <kerray.cz at gmail.com> wrote:
>>>
>>>> Hi,
>>>> very good point, I've been on beta3. But the upgrade didn't help. I've
>>>> figured out how to debug the internals in VS, but there's nothing I could
>>>> be able to fix (or even understand) myself at this point.
>>>>
>>>> ad 1) after running wdb.server, Tornado at first says
>>>> \tornado\netutil.py", line 88, in bind_sockets
>>>> AttributeError: 'module' object has no attribute 'IPV6_V6ONLY'
>>>> When I comment the whole if section out, it starts the loop and waits
>>>> for connections.
>>>>
>>>
>>> Can you open an issue for this? Should be straightforward, if .NET
>>> supports IPv6 only connections. Might have to wait to 2.7.6 though. In the
>>> meantime you can add `hasatter(socket, 'IPV6_V6ONLY')` to the if.
>>>
>>>
>>>>
>>>> Running the client, the server reports this and continues listening:
>>>> Connection received from ('127.0.0.1', 1518)
>>>> [E 141125 11:51:35 stack_context:1] Exception in I/O handler for fd 1616
>>>>     Traceback (most recent call last):
>>>>       File "-\tornado\stack_context.py", line 304, in wrapped
>>>>         ret = fn(*args, **kwargs)
>>>>       File "-\tornado\netutil.py", line 154, in accept_handler
>>>>         callback(connection, address)
>>>>       File "-\wdb_server\streams.py", line 95, in handle_connection
>>>>         stream.read_bytes(4, partial(read_uuid_size, stream))
>>>>       File "-\tornado\iostream.py", line 168, in read_bytes
>>>>         self._try_inline_read()
>>>>       File "-\tornado\iostream.py", line 424, in _try_inline_read
>>>>         if self._read_to_buffer() == 0:
>>>>       File "-\tornado\iostream.py", line 447, in _read_to_buffer
>>>>         chunk = self.read_from_fd()
>>>>       File "-\tornado\iostream.py", line 686, in read_from_fd
>>>>         chunk = self.socket.recv(self.read_chunk_size)
>>>>     error: [Errno 10022] A request to send or receive data was
>>>> disallowed because the socket is not connected and (when sending on a
>>>> datagram socket using a sendto call) no address was supplied
>>>>
>>>> And the client crashes with
>>>> wdb\client\wdb\_compat.py", line 165, in send_bytes
>>>> socket.error: [Errno 10053] An established connection was aborted by
>>>> the software in your host machine
>>>>
>>>> When trying to debug this in VS, I came to the conclusion that the
>>>> Tornado server's socket handling (or my commenting out a piece, or
>>>> something else inside Tornado running under IronPython-) is at fault, since
>>>> it's not true what I've written previously (that a message gets
>>>> communicated and then coms fail) - in fact nothing gets communicated, it
>>>> crashes in the client on trying to send the first message using socket.cs
>>>> sendallWorker(byte[] buffer, int flags).
>>>>
>>>
>>> Not sure why it would not be connected, but I presume Tornado tries to
>>> configure the sockets as non-blocking; it's possible that gets IronPython
>>> confused.
>>>
>>>
>>>>
>>>>
>>>> ad 2) running the server in Python and client in IronPython, I get a
>>>> bit further, but the error is the same - the client in IronPython reports
>>>> Launching browser and wait for connection
>>>> Exception Traceback (most recent call last):
>>>>   File "-\wdb\client\wdb\__init__.py", line 291, in trace_debug_dispatch
>>>>   File "-\wdb\client\wdb\__init__.py", line 250, in trace_dispatch
>>>>   File "-\wdb\client\wdb\__init__.py", line 686, in handle_call
>>>>   File "-\wdb\client\wdb\__init__.py", line 660, in interaction
>>>>   File "-\wdb\client\wdb\ui.py", line 80, in __init__
>>>>   File "-\wdb\client\wdb\__init__.py", line 575, in get_trace
>>>> TypeError: Unable to cast object of type
>>>> 'System.Linq.Expressions.FieldExpression' to type
>>>> 'System.Linq.Expressions.BlockExpression'.
>>>>
>>>> It's the same place and line of code I mentioned in my previous mail:
>>>> > startlnos = dis.findlinestarts(code)
>>>>
>>>> Debugging in VS yields an impressive stack trace, but I don't have any
>>>> idea where to start with this, so again - I'll be very grateful for any
>>>> pointers.
>>>>
>>>
>>> Looks like one of the generator rewriters has a bug. I can't come up
>>> with a simple case to reproduce this, though. It's failing when switching
>>> from interpreted to compiled (LambdaExpression.Compile) but I'm not sure
>>> how to trip that right now, for if it's specific to the code it's compiling.
>>>
>>> - Jeff
>>>
>>>
>>>> Thanks - for even reading this far.
>>>>
>>>>
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitAssign(BinaryExpression
>>>> node) in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 831
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBinary(BinaryExpression
>>>> node) in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 876
>>>>    at System.Linq.Expressions.BinaryExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at
>>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>>> in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 595
>>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at
>>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>>> in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 595
>>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at
>>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>>> in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 595
>>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at
>>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>>> in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 595
>>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at
>>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>>> in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 595
>>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at Microsoft.Scripting.Ast.GeneratorRewriter.VisitTry(TryExpression
>>>> node) in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 297
>>>>    at System.Linq.Expressions.TryExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at
>>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>>> in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 595
>>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at
>>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>>> in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 595
>>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at
>>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>>> in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 595
>>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at
>>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>>> in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 595
>>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at
>>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>>> in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 595
>>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at
>>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>>> in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 595
>>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at
>>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>>> in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 595
>>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at
>>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>>> in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 595
>>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitAssign(BinaryExpression
>>>> node) in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 789
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBinary(BinaryExpression
>>>> node) in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 876
>>>>    at System.Linq.Expressions.BinaryExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at
>>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>>> in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 595
>>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at
>>>> System.Linq.Expressions.ExpressionVisitor.Visit(ReadOnlyCollection`1 nodes)
>>>>    at
>>>> Microsoft.Scripting.Ast.GeneratorRewriter.VisitBlock(BlockExpression node)
>>>> in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 595
>>>>    at System.Linq.Expressions.BlockExpression.Accept(ExpressionVisitor
>>>> visitor)
>>>>    at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
>>>>    at Microsoft.Scripting.Ast.GeneratorRewriter.Reduce() in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorRewriter.cs:line
>>>> 100
>>>>    at Microsoft.Scripting.Ast.GeneratorExpression.Reduce() in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Ast\GeneratorExpression.cs:line
>>>> 94
>>>>    at System.Linq.Expressions.Expression.ReduceAndCheck()
>>>>    at System.Linq.Expressions.Expression.ReduceExtensions()
>>>>    at
>>>> System.Linq.Expressions.Compiler.StackSpiller.RewriteExtensionExpression(Expression
>>>> expr, Stack stack)
>>>>    at
>>>> System.Linq.Expressions.Compiler.StackSpiller.RewriteExpression(Expression
>>>> node, Stack stack)
>>>>    at
>>>> System.Linq.Expressions.Compiler.StackSpiller.RewriteExpressionFreeTemps(Expression
>>>> expression, Stack stack)
>>>>    at
>>>> System.Linq.Expressions.Compiler.StackSpiller.Rewrite[T](Expression`1
>>>> lambda)
>>>>    at System.Linq.Expressions.Expression`1.Accept(StackSpiller spiller)
>>>>    at
>>>> System.Linq.Expressions.Compiler.LambdaCompiler.Compile(LambdaExpression
>>>> lambda, DebugInfoGenerator debugInfoGenerator)
>>>>    at System.Linq.Expressions.LambdaExpression.Compile()
>>>>    at
>>>> Microsoft.Scripting.Debugging.DebuggableLambdaBuilder.CreateFunctionInfo(LambdaExpression
>>>> generatorFactoryLambda) in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Debugging\DebuggableLambdaBuilder.cs:line
>>>> 386
>>>>    at
>>>> Microsoft.Scripting.Debugging.DebuggableLambdaBuilder.TransformLambda(LambdaExpression
>>>> lambda) in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Debugging\DebuggableLambdaBuilder.cs:line
>>>> 171
>>>>    at
>>>> Microsoft.Scripting.Debugging.DebuggableLambdaBuilder.Transform(LambdaExpression
>>>> lambda) in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Debugging\DebuggableLambdaBuilder.cs:line
>>>> 111
>>>>    at
>>>> Microsoft.Scripting.Debugging.CompilerServices.DebugContext.TransformLambda(LambdaExpression
>>>> lambda, DebugLambdaInfo lambdaInfo) in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Debugging\DebugContext.cs:line
>>>> 68
>>>>    at
>>>> IronPython.Runtime.FunctionCode.<>c__DisplayClass1a.<GetGeneratorOrNormalLambdaTracing>b__19(Expression`1
>>>> x) in
>>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Runtime\FunctionCode.cs:line
>>>> 787
>>>>    at IronPython.Compiler.GeneratorRewriter.Reduce(Boolean
>>>> shouldInterpret, Boolean emitDebugSymbols, Int32 compilationThreshold,
>>>> IList`1 parameters, Func`2 bodyConverter) in
>>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Compiler\GeneratorRewriter.cs:line
>>>> 147
>>>>    at
>>>> IronPython.Runtime.FunctionCode.GetGeneratorOrNormalLambdaTracing(PythonContext
>>>> context) in
>>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Runtime\FunctionCode.cs:line
>>>> 777
>>>>    at IronPython.Runtime.FunctionCode.UpdateDelegate(PythonContext
>>>> context, Boolean forceCreation) in
>>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Runtime\FunctionCode.cs:line
>>>> 717
>>>>    at
>>>> IronPython.Runtime.FunctionCode.LazyCompileFirstTarget(PythonFunction
>>>> function) in
>>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Runtime\FunctionCode.cs:line
>>>> 697
>>>>    at
>>>> IronPython.Compiler.PythonCallTargets.OriginalCallTarget1(PythonFunction
>>>> function, Object arg0) in
>>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Compiler\PythonCallTargets.cs:line
>>>> 42
>>>>    at IronPython.Runtime.FunctionCaller`1.Call1(CallSite site,
>>>> CodeContext context, Object func, T0 arg0) in
>>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Runtime\PythonFunction.Generated.cs:line
>>>> 420
>>>>    at
>>>> System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite
>>>> site, T0 arg0, T1 arg1, T2 arg2)
>>>>    at get_trace$495(Closure , PythonFunction , Object , Object , Object
>>>> )
>>>>    at
>>>> IronPython.Compiler.PythonFunctionRecursionCheck3.CallTarget(PythonFunction
>>>> function, Object arg0, Object arg1, Object arg2) in
>>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Compiler\PythonCallTargets.cs:line
>>>> 273
>>>>    at
>>>> IronPython.Compiler.PythonCallTargets.OriginalCallTarget3(PythonFunction
>>>> function, Object arg0, Object arg1, Object arg2) in
>>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Compiler\PythonCallTargets.cs:line
>>>> 53
>>>>    at IronPython.Runtime.FunctionCaller`3.Call3(CallSite site,
>>>> CodeContext context, Object func, T0 arg0, T1 arg1, T2 arg2) in
>>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Runtime\PythonFunction.Generated.cs:line
>>>> 676
>>>>    at
>>>> System.Dynamic.UpdateDelegates.UpdateAndExecute5[T0,T1,T2,T3,T4,TRet](CallSite
>>>> site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
>>>>    at CallSite.Target(Closure , CallSite , CodeContext , Object ,
>>>> Object , Object , Object )
>>>>    at IronPython.Runtime.Method.MethodBinding`2.SelfTarget(CallSite
>>>> site, CodeContext context, Object target, T0 arg0, T1 arg1) in
>>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Runtime\Method.Generated.cs:line
>>>> 195
>>>>    at
>>>> System.Dynamic.UpdateDelegates.UpdateAndExecute4[T0,T1,T2,T3,TRet](CallSite
>>>> site, T0 arg0, T1 arg1, T2 arg2, T3 arg3)
>>>>    at
>>>> Microsoft.Scripting.Interpreter.DynamicInstruction`5.Run(InterpretedFrame
>>>> frame) in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Interpreter\Instructions\DynamicInstructions.Generated.cs:line
>>>> 218
>>>>    at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame
>>>> frame) in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Interpreter\Interpreter.cs:line
>>>> 132
>>>>    at
>>>> Microsoft.Scripting.Interpreter.LightLambda.Run10[T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,TRet](T0
>>>> arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6, T7 arg7, T8
>>>> arg8, T9 arg9) in
>>>> c:\Users\jmatysek\Documents\main\Runtime\Microsoft.Dynamic\Interpreter\LightLambda.Generated.cs:line
>>>> 417
>>>>    at
>>>> IronPython.Compiler.PythonFunctionRecursionCheck9.CallTarget(PythonFunction
>>>> function, Object arg0, Object arg1, Object arg2, Object arg3, Object arg4,
>>>> Object arg5, Object arg6, Object arg7, Object arg8) in
>>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Compiler\PythonCallTargets.cs:line
>>>> 375
>>>>    at
>>>> IronPython.Compiler.PythonCallTargets.OriginalCallTarget9(PythonFunction
>>>> function, Object arg0, Object arg1, Object arg2, Object arg3, Object arg4,
>>>> Object arg5, Object arg6, Object arg7, Object arg8) in
>>>> c:\Users\jmatysek\Documents\main\Languages\IronPython\IronPython\Compiler\PythonCallTargets.cs:line
>>>> 83
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150430/dad6b235/attachment.html>