From kuno.meyer at gmx.ch  Mon May  4 13:13:17 2015
From: kuno.meyer at gmx.ch (Kuno Meyer)
Date: Mon, 4 May 2015 11:13:17 +0000 (UTC)
Subject: [Ironpython-users] =?utf-8?q?=5Fweakref=2Ecs_fixes?=
Message-ID: <loom.20150504T125049-609@post.gmane.org>

Dear all

I'd like to propose https://github.com/kunom/ipy-weakref (the ipy-27-maint
branch) to be included into the main IronPython code base. It fixes for me
various random SystemError and ValueError exceptions in the _weakref.cs module.

Please note that while my patch changes (and hopefully improves) some
aspects in _weakref.cs, I still do think that _weakref.cs has several
critical issues:

- There is absolutely no locking on the internal data structures, which
makes me think that there could be various runtime issues in a multithreaded
environment. (However, this does not directly apply to the Finalizer thread
since to my knowledge all user threads are suspended during finalization.)

- The weakref collection callback is invoked on the .NET finalizer thread. I
am not sure whether this is what user code expects. At least there is a high
potential of dead-locking the finalizer thread, which is not the nicest
thing to do. (Maybe we should issue a warning on direct calls to
GC.WaitForPendingFinalizers(), similar to what is printed when calling
Thread.Sleep().)

Other remarks:

- The weakref/weakrefset test case brought up in the mailing list on Apr 13
passes with my changes.

- The standard library weakref tests pass with the same number of failures
as before

- Please note that I am unexperienced with git/GitHub as well as with the
IronPython code base, so please show some patience...

Thanks!
Kuno


From sebasmagri at gmail.com  Mon May  4 15:48:40 2015
From: sebasmagri at gmail.com (=?UTF-8?B?U2ViYXN0acOhbiBNYWdyw60=?=)
Date: Mon, 4 May 2015 09:18:40 -0430
Subject: [Ironpython-users] Error running standalone exe using
 clrtype.py if IronPython is not installed
In-Reply-To: <CAF7AXFEpji=07dVLLVhuvf7AeDxSqY3BmtD5N4+i_4ZA2i51wg@mail.gmail.com>
References: <CADmKEd6341P2D7v-biCNP3pOz8zAgTSDHSJA1ASp=oL3WukOOg@mail.gmail.com>
 <CAPiUgVfy3SQW+M2CUx9-rResaQ6aOp_NOffgRux4YLzbsQ7TTA@mail.gmail.com>
 <CADmKEd6cGXB9x8WbpPRwwy=r81AiLDkJ2Z2jPJPvx_EZrf4LZQ@mail.gmail.com>
 <CAF7AXFEpji=07dVLLVhuvf7AeDxSqY3BmtD5N4+i_4ZA2i51wg@mail.gmail.com>
Message-ID: <CADmKEd7ycLLpdw7Om_ktTtX+L4TNgMN3F0ih2UOR2vFpp7C_gA@mail.gmail.com>

Well that's actually my fault for not checking out that first (wrt
clrtype). Is there any other well tested/standard option to do what clrtype
does nowadays?

I've actually opted for installing IronPython in the client machines, but I
will look at fuslogvw to check this out.

Best Regards,

2015-04-25 18:44 GMT-04:30 Jeff Hardy <jdhardy at 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
> >
>



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

From m.schaber at codesys.com  Mon May  4 17:10:02 2015
From: m.schaber at codesys.com (Markus Schaber)
Date: Mon, 4 May 2015 15:10:02 +0000
Subject: [Ironpython-users] Error running standalone exe using
 clrtype.py if IronPython is not installed
In-Reply-To: <CADmKEd7ycLLpdw7Om_ktTtX+L4TNgMN3F0ih2UOR2vFpp7C_gA@mail.gmail.com>
References: <CADmKEd6341P2D7v-biCNP3pOz8zAgTSDHSJA1ASp=oL3WukOOg@mail.gmail.com>
 <CAPiUgVfy3SQW+M2CUx9-rResaQ6aOp_NOffgRux4YLzbsQ7TTA@mail.gmail.com>
 <CADmKEd6cGXB9x8WbpPRwwy=r81AiLDkJ2Z2jPJPvx_EZrf4LZQ@mail.gmail.com>
 <CAF7AXFEpji=07dVLLVhuvf7AeDxSqY3BmtD5N4+i_4ZA2i51wg@mail.gmail.com>
 <CADmKEd7ycLLpdw7Om_ktTtX+L4TNgMN3F0ih2UOR2vFpp7C_gA@mail.gmail.com>
Message-ID: <727D8E16AE957149B447FE368139F2B55497B780@SERVER10>

Hi,

Von: Sebasti?n Magr?
> Well that's actually my fault for not checking out that first (wrt clrtype). Is there any other well tested/standard option to do what clrtype does nowadays?
> I've actually opted for installing IronPython in the client machines, but I will look at fuslogvw to check this out.

One way which usually works well is to use C++/CLI (or maybe C# and p/invoke) to create a nice managed API wrapper around the native library.

C++/CLI has the drawback that it doesn't work on non-Windows platforms (e. G. Mono on Linux) currently.


Best Regards,

One possible way 

Best regards

Markus Schaber

CODESYS? a trademark of 3S-Smart Software Solutions GmbH 

Inspiring Automation Solutions 
________________________________________
3S-Smart Software Solutions GmbH 
Dipl.-Inf. Markus Schaber | Product Development Core Technology 
Memminger Str. 151 | 87439 Kempten | Germany 
Tel. +49-831-54031-979 | Fax +49-831-54031-50 

E-Mail: m.schaber at codesys.com | Web: codesys.com | CODESYS store: store.codesys.com 
CODESYS forum: forum.codesys.com 

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 
________________________________________
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received 
this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure 
or distribution of the material in this e-mail is strictly forbidden. 


From slide.o.mix at gmail.com  Mon May  4 17:30:17 2015
From: slide.o.mix at gmail.com (Slide)
Date: Mon, 04 May 2015 15:30:17 +0000
Subject: [Ironpython-users] Error running standalone exe using
 clrtype.py if IronPython is not installed
In-Reply-To: <727D8E16AE957149B447FE368139F2B55497B780@SERVER10>
References: <CADmKEd6341P2D7v-biCNP3pOz8zAgTSDHSJA1ASp=oL3WukOOg@mail.gmail.com>
 <CAPiUgVfy3SQW+M2CUx9-rResaQ6aOp_NOffgRux4YLzbsQ7TTA@mail.gmail.com>
 <CADmKEd6cGXB9x8WbpPRwwy=r81AiLDkJ2Z2jPJPvx_EZrf4LZQ@mail.gmail.com>
 <CAF7AXFEpji=07dVLLVhuvf7AeDxSqY3BmtD5N4+i_4ZA2i51wg@mail.gmail.com>
 <CADmKEd7ycLLpdw7Om_ktTtX+L4TNgMN3F0ih2UOR2vFpp7C_gA@mail.gmail.com>
 <727D8E16AE957149B447FE368139F2B55497B780@SERVER10>
Message-ID: <CAPiUgVe=-UND=Vn934M5r+fnp=fxkuVaKm3e50e34K63hgrThQ@mail.gmail.com>

The other option is to use ctypes. This is more like CPython.

On Mon, May 4, 2015 at 8:15 AM Markus Schaber <m.schaber at codesys.com> wrote:

> Hi,
>
> Von: Sebasti?n Magr?
> > Well that's actually my fault for not checking out that first (wrt
> clrtype). Is there any other well tested/standard option to do what clrtype
> does nowadays?
> > I've actually opted for installing IronPython in the client machines,
> but I will look at fuslogvw to check this out.
>
> One way which usually works well is to use C++/CLI (or maybe C# and
> p/invoke) to create a nice managed API wrapper around the native library.
>
> C++/CLI has the drawback that it doesn't work on non-Windows platforms (e.
> G. Mono on Linux) currently.
>
>
> Best Regards,
>
> One possible way
>
> Best regards
>
> Markus Schaber
>
> CODESYS? a trademark of 3S-Smart Software Solutions GmbH
>
> Inspiring Automation Solutions
> ________________________________________
> 3S-Smart Software Solutions GmbH
> Dipl.-Inf. Markus Schaber | Product Development Core Technology
> Memminger Str. 151 | 87439 Kempten | Germany
> Tel. +49-831-54031-979 | Fax +49-831-54031-50
>
> E-Mail: m.schaber at codesys.com | Web: codesys.com | CODESYS store:
> store.codesys.com
> CODESYS forum: forum.codesys.com
>
> Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
> Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
> ________________________________________
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received
> this e-mail in error) please notify the sender immediately and destroy
> this e-mail. Any unauthorised copying, disclosure
> or distribution of the material in this e-mail is strictly forbidden.
>
> _______________________________________________
> 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/20150504/720cd1a9/attachment.html>

From sebasmagri at gmail.com  Mon May  4 19:20:30 2015
From: sebasmagri at gmail.com (=?UTF-8?B?U2ViYXN0acOhbiBNYWdyw60=?=)
Date: Mon, 4 May 2015 12:50:30 -0430
Subject: [Ironpython-users] Error running standalone exe using
 clrtype.py if IronPython is not installed
In-Reply-To: <CAPiUgVe=-UND=Vn934M5r+fnp=fxkuVaKm3e50e34K63hgrThQ@mail.gmail.com>
References: <CADmKEd6341P2D7v-biCNP3pOz8zAgTSDHSJA1ASp=oL3WukOOg@mail.gmail.com>
 <CAPiUgVfy3SQW+M2CUx9-rResaQ6aOp_NOffgRux4YLzbsQ7TTA@mail.gmail.com>
 <CADmKEd6cGXB9x8WbpPRwwy=r81AiLDkJ2Z2jPJPvx_EZrf4LZQ@mail.gmail.com>
 <CAF7AXFEpji=07dVLLVhuvf7AeDxSqY3BmtD5N4+i_4ZA2i51wg@mail.gmail.com>
 <CADmKEd7ycLLpdw7Om_ktTtX+L4TNgMN3F0ih2UOR2vFpp7C_gA@mail.gmail.com>
 <727D8E16AE957149B447FE368139F2B55497B780@SERVER10>
 <CAPiUgVe=-UND=Vn934M5r+fnp=fxkuVaKm3e50e34K63hgrThQ@mail.gmail.com>
Message-ID: <CADmKEd57L-jBg7oQ2WMiRcHffASLGRQbUdhVkr0BLzKxY15CfA@mail.gmail.com>

On the other hand, would clrtype be something good enough to be developed
as a part of `clr`?

2015-05-04 11:00 GMT-04:30 Slide <slide.o.mix at gmail.com>:

> The other option is to use ctypes. This is more like CPython.
>
> On Mon, May 4, 2015 at 8:15 AM Markus Schaber <m.schaber at codesys.com>
> wrote:
>
>> Hi,
>>
>> Von: Sebasti?n Magr?
>> > Well that's actually my fault for not checking out that first (wrt
>> clrtype). Is there any other well tested/standard option to do what clrtype
>> does nowadays?
>> > I've actually opted for installing IronPython in the client machines,
>> but I will look at fuslogvw to check this out.
>>
>> One way which usually works well is to use C++/CLI (or maybe C# and
>> p/invoke) to create a nice managed API wrapper around the native library.
>>
>> C++/CLI has the drawback that it doesn't work on non-Windows platforms
>> (e. G. Mono on Linux) currently.
>>
>>
>> Best Regards,
>>
>> One possible way
>>
>> Best regards
>>
>> Markus Schaber
>>
>> CODESYS? a trademark of 3S-Smart Software Solutions GmbH
>>
>> Inspiring Automation Solutions
>> ________________________________________
>> 3S-Smart Software Solutions GmbH
>> Dipl.-Inf. Markus Schaber | Product Development Core Technology
>> Memminger Str. 151 | 87439 Kempten | Germany
>> Tel. +49-831-54031-979 | Fax +49-831-54031-50
>>
>> E-Mail: m.schaber at codesys.com | Web: codesys.com | CODESYS store:
>> store.codesys.com
>> CODESYS forum: forum.codesys.com
>>
>> Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
>> Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
>> ________________________________________
>> This e-mail may contain confidential and/or privileged information. If
>> you are not the intended recipient (or have received
>> this e-mail in error) please notify the sender immediately and destroy
>> this e-mail. Any unauthorised copying, disclosure
>> or distribution of the material in this e-mail is strictly forbidden.
>>
>> _______________________________________________
>> 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/20150504/b50d36c5/attachment.html>

From jdhardy at gmail.com  Tue May  5 18:39:49 2015
From: jdhardy at gmail.com (Jeff Hardy)
Date: Tue, 5 May 2015 17:39:49 +0100
Subject: [Ironpython-users] _weakref.cs fixes
In-Reply-To: <loom.20150504T125049-609@post.gmane.org>
References: <loom.20150504T125049-609@post.gmane.org>
Message-ID: <CAF7AXFFcCsXCvvNnYJD6W7BUeXDU_fLSkodo28d=biaocW=Tng@mail.gmail.com>

Hi Kuno,
Thanks for looking into it! The usual workflow is to send a pull
request (PR) [1], which creates a single spot for discussion, with
nice commenting abilities. If you don't mind doing that, I'll take a
look at the changes [2] in the meantime.

- Jeff

[1] https://help.github.com/articles/creating-a-pull-request/
[2] https://github.com/kunom/ipy-weakref/commit/3efacde8b3408fa92ddd4185a4774a0c284c4301

On Mon, May 4, 2015 at 12:13 PM, Kuno Meyer <kuno.meyer at gmx.ch> wrote:
> Dear all
>
> I'd like to propose https://github.com/kunom/ipy-weakref (the ipy-27-maint
> branch) to be included into the main IronPython code base. It fixes for me
> various random SystemError and ValueError exceptions in the _weakref.cs module.
>
> Please note that while my patch changes (and hopefully improves) some
> aspects in _weakref.cs, I still do think that _weakref.cs has several
> critical issues:
>
> - There is absolutely no locking on the internal data structures, which
> makes me think that there could be various runtime issues in a multithreaded
> environment. (However, this does not directly apply to the Finalizer thread
> since to my knowledge all user threads are suspended during finalization.)
>
> - The weakref collection callback is invoked on the .NET finalizer thread. I
> am not sure whether this is what user code expects. At least there is a high
> potential of dead-locking the finalizer thread, which is not the nicest
> thing to do. (Maybe we should issue a warning on direct calls to
> GC.WaitForPendingFinalizers(), similar to what is printed when calling
> Thread.Sleep().)
>
> Other remarks:
>
> - The weakref/weakrefset test case brought up in the mailing list on Apr 13
> passes with my changes.
>
> - The standard library weakref tests pass with the same number of failures
> as before
>
> - Please note that I am unexperienced with git/GitHub as well as with the
> IronPython code base, so please show some patience...
>
> Thanks!
> Kuno
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users

From sommerhoff at gmail.com  Tue May  5 19:19:22 2015
From: sommerhoff at gmail.com (Andres Sommerhoff)
Date: Tue, 5 May 2015 14:19:22 -0300
Subject: [Ironpython-users] weakref random "SystemError" and
 "ValueError" exception (affecting _weakrefset.py and abc.py)
Message-ID: <CAO1Y6_VsN2d1hbxsnup5O1+yYuMEc6AJvCJ+nejpPfBq3GVrmQ@mail.gmail.com>

Great Kuno and Jeff! Thank you for helping with a solution for the issue
with _weakrefset.py (reported on 13th Abril). Looking forward to seeing
Kuno's changes in the next IronPython release!

Jeff, is it there a schedule for next IronPython stable release? (...not
pushing, just kindly asking if you have an estimation ;-) )

Thanks,
Andres


On Tue, May 5, 2015 at 1:39 PM, Jeff Hardy <jdhardy at gmail.com> wrote:

> Hi Kuno,
> Thanks for looking into it! The usual workflow is to send a pull
> request (PR) [1], which creates a single spot for discussion, with
> nice commenting abilities. If you don't mind doing that, I'll take a
> look at the changes [2] in the meantime.
>
> - Jeff
>
> [1] https://help.github.com/articles/creating-a-pull-request/
> [2]
> https://github.com/kunom/ipy-weakref/commit/3efacde8b3408fa92ddd4185a4774a0c284c4301
>
> On Mon, May 4, 2015 at 12:13 PM, Kuno Meyer <kuno.meyer at gmx.ch> wrote:
> > Dear all
> >
> > I'd like to propose https://github.com/kunom/ipy-weakref (the
> ipy-27-maint
> > branch) to be included into the main IronPython code base. It fixes for
> me
> > various random SystemError and ValueError exceptions in the _weakref.cs
> module.
> >
> > Please note that while my patch changes (and hopefully improves) some
> > aspects in _weakref.cs, I still do think that _weakref.cs has several
> > critical issues:
> >
> > - There is absolutely no locking on the internal data structures, which
> > makes me think that there could be various runtime issues in a
> multithreaded
> > environment. (However, this does not directly apply to the Finalizer
> thread
> > since to my knowledge all user threads are suspended during
> finalization.)
> >
> > - The weakref collection callback is invoked on the .NET finalizer
> thread. I
> > am not sure whether this is what user code expects. At least there is a
> high
> > potential of dead-locking the finalizer thread, which is not the nicest
> > thing to do. (Maybe we should issue a warning on direct calls to
> > GC.WaitForPendingFinalizers(), similar to what is printed when calling
> > Thread.Sleep().)
> >
> > Other remarks:
> >
> > - The weakref/weakrefset test case brought up in the mailing list on Apr
> 13
> > passes with my changes.
> >
> > - The standard library weakref tests pass with the same number of
> failures
> > as before
> >
> > - Please note that I am unexperienced with git/GitHub as well as with the
> > IronPython code base, so please show some patience...
> >
> > Thanks!
> > Kuno
> >
> > _______________________________________________
> > 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/20150505/89d929e6/attachment.html>

From kuno.meyer at gmx.ch  Wed May  6 08:40:52 2015
From: kuno.meyer at gmx.ch (Kuno Meyer)
Date: Wed, 6 May 2015 06:40:52 +0000 (UTC)
Subject: [Ironpython-users] =?utf-8?q?=5Fweakref=2Ecs_fixes?=
References: <loom.20150504T125049-609@post.gmane.org>
 <CAF7AXFFcCsXCvvNnYJD6W7BUeXDU_fLSkodo28d=biaocW=Tng@mail.gmail.com>
Message-ID: <loom.20150506T083506-900@post.gmane.org>

Jeff Hardy <jdhardy at ...> writes:
> Hi Kuno,
> Thanks for looking into it! The usual workflow is to send a pull
> request (PR) [1], which creates a single spot for discussion, with
> nice commenting abilities. 

Done: https://github.com/IronLanguages/main/pull/1198

Thanks for the link to [1].

Kuno



From jdhardy at gmail.com  Wed May  6 09:54:35 2015
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 6 May 2015 08:54:35 +0100
Subject: [Ironpython-users] weakref random "SystemError" and
 "ValueError" exception (affecting _weakrefset.py and abc.py)
In-Reply-To: <CAO1Y6_VsN2d1hbxsnup5O1+yYuMEc6AJvCJ+nejpPfBq3GVrmQ@mail.gmail.com>
References: <CAO1Y6_VsN2d1hbxsnup5O1+yYuMEc6AJvCJ+nejpPfBq3GVrmQ@mail.gmail.com>
Message-ID: <CAF7AXFF3rwV-gWi=8zPyu8hcq-5AY47PGbsPmwPO8b3BGPFpXw@mail.gmail.com>

On Tue, May 5, 2015 at 6:19 PM, Andres Sommerhoff <sommerhoff at gmail.com> wrote:
> Great Kuno and Jeff! Thank you for helping with a solution for the issue
> with _weakrefset.py (reported on 13th Abril). Looking forward to seeing
> Kuno's changes in the next IronPython release!
>
> Jeff, is it there a schedule for next IronPython stable release? (...not
> pushing, just kindly asking if you have an estimation ;-) )

Not right now, but these changes are impactful enough to consider
doing a quick-turnaround 2.7.6. However, I won't be able to do it
until July at the earliest (due to moving in June). I'll see if I can
review Kuno's changes and get a preview release out before the end of
May so that at least there's something for people impacted by this.

- Jeff

From jdhardy at gmail.com  Wed May  6 10:01:28 2015
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 6 May 2015 09:01:28 +0100
Subject: [Ironpython-users] Error running standalone exe using
 clrtype.py if IronPython is not installed
In-Reply-To: <CADmKEd57L-jBg7oQ2WMiRcHffASLGRQbUdhVkr0BLzKxY15CfA@mail.gmail.com>
References: <CADmKEd6341P2D7v-biCNP3pOz8zAgTSDHSJA1ASp=oL3WukOOg@mail.gmail.com>
 <CAPiUgVfy3SQW+M2CUx9-rResaQ6aOp_NOffgRux4YLzbsQ7TTA@mail.gmail.com>
 <CADmKEd6cGXB9x8WbpPRwwy=r81AiLDkJ2Z2jPJPvx_EZrf4LZQ@mail.gmail.com>
 <CAF7AXFEpji=07dVLLVhuvf7AeDxSqY3BmtD5N4+i_4ZA2i51wg@mail.gmail.com>
 <CADmKEd7ycLLpdw7Om_ktTtX+L4TNgMN3F0ih2UOR2vFpp7C_gA@mail.gmail.com>
 <727D8E16AE957149B447FE368139F2B55497B780@SERVER10>
 <CAPiUgVe=-UND=Vn934M5r+fnp=fxkuVaKm3e50e34K63hgrThQ@mail.gmail.com>
 <CADmKEd57L-jBg7oQ2WMiRcHffASLGRQbUdhVkr0BLzKxY15CfA@mail.gmail.com>
Message-ID: <CAF7AXFFW=465dCFxSG4ktiPycArmefKAqXYfFPvohFo1pAXmhg@mail.gmail.com>

On Mon, May 4, 2015 at 6:20 PM, Sebasti?n Magr? <sebasmagri at gmail.com> wrote:
> On the other hand, would clrtype be something good enough to be developed as
> a part of `clr`?

Long term, that's the plan. With function attributes in Python 3, and
the standardized type hits of PEP 484, it opens all sorts of
interesting options for feeding static type information in and
generating "real" .NET classes.

Alex already ported pyc.py to C# (as ipyc.exe) but I think it's on the
master branch, not ipy-2.7-maint. Someday that will be able to
recognize specially-annotated classes and generate "real" .NET DLLs
from them. I say "someday" because I started the work two years ago
now and haven't had a chance to finish yet. :) The prototype I wrote
doesn't work the way I would like, but PEP 484 means I can try it a
different way that should give more reliable results.

- Jeff

From jdhardy at gmail.com  Wed May  6 10:10:12 2015
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 6 May 2015 09:10:12 +0100
Subject: [Ironpython-users] WDB web debugger for IronPython
In-Reply-To: <CAM5UpT49aYG1D9V06iRm=H=fPbH2PNHW+9fA8OaY6YGEgDwJGg@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>
 <CAM5UpT49aYG1D9V06iRm=H=fPbH2PNHW+9fA8OaY6YGEgDwJGg@mail.gmail.com>
Message-ID: <CAF7AXFG=zVeeTkoy4TPbv6cuPabN9dcObD6x0zdsbhMbjPb6QA@mail.gmail.com>

Hi Kerray,
Is there a GitHub issue for this open already? There probably is for
missing co_lnotab, but about dis.findlinestarts failing strangely?
Fixing co_lnotab shouldn't be difficult, but the compile error could
be trickier. I'm assuming you haven't been able to reproduce it
without wdb?

You can easily attach the VS debugger if you have a Debug build
(you'll have to do that yourself, but just opening the
Solutions/IronPython.sln and hitting F5 should be enough, or you can
run 'make.cmd' from the checkout directory and find it
'bin/Debug/ipy.exe'). The run 'ipy.exe -X:Debug -X:Attach' and it will
prompt you for a debugger to attach immediately after launch.

- Jeff

On Thu, Apr 30, 2015 at 9:55 AM, Kerray <kerray.cz at gmail.com> wrote:
> 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
>>>>>
>>>
>>>
>>
>
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>

From jdhardy at gmail.com  Wed May  6 10:13:15 2015
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 6 May 2015 09:13:15 +0100
Subject: [Ironpython-users] PTVS "attach to process" can't see IP in
 embedded process
In-Reply-To: <CALrd2BUJvx5CBwz7NZSb5JCby_+Ws+q7wVVrqfWAy533=gCbjg@mail.gmail.com>
References: <CALrd2BUJvx5CBwz7NZSb5JCby_+Ws+q7wVVrqfWAy533=gCbjg@mail.gmail.com>
Message-ID: <CAF7AXFGF+W56n0y1bJhnDy8j6SmxGeVGwKHzSvoAcau8SUCgBw@mail.gmail.com>

On Wed, Apr 29, 2015 at 10:13 AM, Alain Cormier <alain at mcneel.com> wrote:
> 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?

Your best bet is probably to ask on the PTVS forums. I'm not sure how
the PTVS debugger detects IronPython, or if it even does anything
special (IronPython emits normal .NET debug information, so it might
just hand it off to the .NET debugger).

- Jeff

From egroups at sowray.com  Wed May  6 15:43:13 2015
From: egroups at sowray.com (egroups at sowray.com)
Date: Wed, 6 May 2015 14:43:13 +0100
Subject: [Ironpython-users] Failing to catch exception
Message-ID: <d5e08474caaf404ddf57e33f809f847c.squirrel@ssl-webmail-vh.clara.net>

I'm probably doing something extremely stupid. I'm using Selenium to parse
a web page, but can't catch the exceptions it throws:


# Add Selenium
clr.AddReference("Selenium.WebDriverBackedSelenium.dll")
clr.AddReference("ThoughtWorks.Selenium.Core.dll")
clr.AddReference("WebDriver.dll")
clr.AddReference("WebDriver.Support.dll")

from OpenQA.Selenium import *
from OpenQA.Selenium.IE import *
[...]
class MyWindow(Window):
    def __init__(self):
        [...]
        # Initialize the Selenium object and open the page to parse
        self.driver = InternetExplorerDriver()
        self.driver.Navigate().GoToUrl("http://www.parsethispage.com")
    [...]
    def ParseStoryStandardFormat(self):
        parsed_ok = 1
        try:
            flagIndicator =
self.driver.FindElementByClassName("flag-indicator")
            fiUuid = syndicationIndicator.GetAttribute("data-uuid")
        except NoSuchElementException:
            parsed_ok = 0


(The [...] in the code represents where I've edited out the irrelevant
bits.) I'm using IronPython 2.7.2.1 on .NET 4.0.30319 from VS 2010 with
the latest PTVS.

If there's no flag-indicator class on the web page, the code stops at the
first line of the try: and throws a NoSuchElementException. I've tried
explicitly importing the exception (from OpenQA.Selenium import
NoSuchElementException) and tried a catch-all "except:", but nothing seems
to catch this error.

If I run it from VS with debugging, it tells me the NoSuchElementException
was unhandled by user code. If I run it without debugging, the application
just crashes and terminates. To check other errors are handled, I added a
try: xyz = 123 / 0 except: xyz = 0 at the beginning of the function and
that was handled without any problem.

If anybody can shed some light on what I'm doing wrong, I'd be very grateful.

Thanks,
David



From alain at mcneel.com  Thu May  7 08:26:57 2015
From: alain at mcneel.com (Alain Cormier)
Date: Thu, 7 May 2015 08:26:57 +0200
Subject: [Ironpython-users] PTVS "attach to process" can't see IP in
 embedded process
In-Reply-To: <CAF7AXFGF+W56n0y1bJhnDy8j6SmxGeVGwKHzSvoAcau8SUCgBw@mail.gmail.com>
References: <CALrd2BUJvx5CBwz7NZSb5JCby_+Ws+q7wVVrqfWAy533=gCbjg@mail.gmail.com>
 <CAF7AXFGF+W56n0y1bJhnDy8j6SmxGeVGwKHzSvoAcau8SUCgBw@mail.gmail.com>
Message-ID: <CALrd2BUfpB6hnynzO-g+HTdsAU0VACsnYNopjv-nN-_ERuu-Gg@mail.gmail.com>

Hi,

I'll check the PTVS forums.

I posted here because the fact that PTVS has no problems connecting to
ipy.exe makes me think that the problem is in how IronPython is embedded in
our app.

Thanks,
Alain

On Wed, May 6, 2015 at 10:13 AM, Jeff Hardy <jdhardy at gmail.com> wrote:

> On Wed, Apr 29, 2015 at 10:13 AM, Alain Cormier <alain at mcneel.com> wrote:
> > 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?
>
> Your best bet is probably to ask on the PTVS forums. I'm not sure how
> the PTVS debugger detects IronPython, or if it even does anything
> special (IronPython emits normal .NET debug information, so it might
> just hand it off to the .NET debugger).
>
> - Jeff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150507/fc4ba7d2/attachment.html>

From jdhardy at gmail.com  Thu May  7 12:41:49 2015
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 7 May 2015 11:41:49 +0100
Subject: [Ironpython-users] Failing to catch exception
In-Reply-To: <d5e08474caaf404ddf57e33f809f847c.squirrel@ssl-webmail-vh.clara.net>
References: <d5e08474caaf404ddf57e33f809f847c.squirrel@ssl-webmail-vh.clara.net>
Message-ID: <CAF7AXFHY-pJHNP1iQwkfKz-P2ufEc1OyqjV_NmJTr8bKgT=OEA@mail.gmail.com>

The first thing you should try is upgrading your IronPython to 2.7.5.
I believe there's a fix for exception handling in one of the newer
versions.

If not there might be something deeper and more annoying at play
(types getting loaded into different contexts that are not
compatible).

- Jeff

On Wed, May 6, 2015 at 2:43 PM,  <egroups at sowray.com> wrote:
> I'm probably doing something extremely stupid. I'm using Selenium to parse
> a web page, but can't catch the exceptions it throws:
>
>
> # Add Selenium
> clr.AddReference("Selenium.WebDriverBackedSelenium.dll")
> clr.AddReference("ThoughtWorks.Selenium.Core.dll")
> clr.AddReference("WebDriver.dll")
> clr.AddReference("WebDriver.Support.dll")
>
> from OpenQA.Selenium import *
> from OpenQA.Selenium.IE import *
> [...]
> class MyWindow(Window):
>     def __init__(self):
>         [...]
>         # Initialize the Selenium object and open the page to parse
>         self.driver = InternetExplorerDriver()
>         self.driver.Navigate().GoToUrl("http://www.parsethispage.com")
>     [...]
>     def ParseStoryStandardFormat(self):
>         parsed_ok = 1
>         try:
>             flagIndicator =
> self.driver.FindElementByClassName("flag-indicator")
>             fiUuid = syndicationIndicator.GetAttribute("data-uuid")
>         except NoSuchElementException:
>             parsed_ok = 0
>
>
> (The [...] in the code represents where I've edited out the irrelevant
> bits.) I'm using IronPython 2.7.2.1 on .NET 4.0.30319 from VS 2010 with
> the latest PTVS.
>
> If there's no flag-indicator class on the web page, the code stops at the
> first line of the try: and throws a NoSuchElementException. I've tried
> explicitly importing the exception (from OpenQA.Selenium import
> NoSuchElementException) and tried a catch-all "except:", but nothing seems
> to catch this error.
>
> If I run it from VS with debugging, it tells me the NoSuchElementException
> was unhandled by user code. If I run it without debugging, the application
> just crashes and terminates. To check other errors are handled, I added a
> try: xyz = 123 / 0 except: xyz = 0 at the beginning of the function and
> that was handled without any problem.
>
> If anybody can shed some light on what I'm doing wrong, I'd be very grateful.
>
> Thanks,
> David
>
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users

From egroups at sowray.com  Fri May  8 08:18:55 2015
From: egroups at sowray.com (egroups at sowray.com)
Date: Fri, 8 May 2015 07:18:55 +0100
Subject: [Ironpython-users] Failing to catch exception
In-Reply-To: <CAF7AXFHY-pJHNP1iQwkfKz-P2ufEc1OyqjV_NmJTr8bKgT=OEA@mail.gmail.com>
References: <d5e08474caaf404ddf57e33f809f847c.squirrel@ssl-webmail-vh.clara.net>
 <CAF7AXFHY-pJHNP1iQwkfKz-P2ufEc1OyqjV_NmJTr8bKgT=OEA@mail.gmail.com>
Message-ID: <6f634d0a12e6c665deea0334ac2ff7ba.squirrel@ssl-webmail-vh.clara.net>

Thanks for that suggestion, Jeff.

Unfortunately after upgrading to 2.7.5, the problem remains.


> The first thing you should try is upgrading your IronPython to 2.7.5.
> I believe there's a fix for exception handling in one of the newer
> versions.
>
> If not there might be something deeper and more annoying at play
> (types getting loaded into different contexts that are not
> compatible).
>
> - Jeff



From jdhardy at gmail.com  Fri May  8 09:15:20 2015
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 8 May 2015 08:15:20 +0100
Subject: [Ironpython-users] Failing to catch exception
In-Reply-To: <6f634d0a12e6c665deea0334ac2ff7ba.squirrel@ssl-webmail-vh.clara.net>
References: <d5e08474caaf404ddf57e33f809f847c.squirrel@ssl-webmail-vh.clara.net>
 <CAF7AXFHY-pJHNP1iQwkfKz-P2ufEc1OyqjV_NmJTr8bKgT=OEA@mail.gmail.com>
 <6f634d0a12e6c665deea0334ac2ff7ba.squirrel@ssl-webmail-vh.clara.net>
Message-ID: <CAF7AXFG6_pJr91FJvyE+wk54veghRDDPTnYR9yjbLPQsL0KQXA@mail.gmail.com>

On Fri, May 8, 2015 at 7:18 AM,  <egroups at sowray.com> wrote:
> Thanks for that suggestion, Jeff.
>
> Unfortunately after upgrading to 2.7.5, the problem remains.
>

Dang, I was hoping this would be easy. :(

There are two possibilities that come to mind:
1) The exception types are coming from different versions of the same assembly
2) The exception types come from the same assembly loaded into
different contexts [1].

Both of these are a pain to debug. Your best bet is probably to set up
fuslogvw and check the logs to see if the Selenium assemblies are
being loaded twice.

What I don't get is why a bare except: doesn't catch it. Can you try
replacing the try contents with just 'raise NoSuchElementException()'
and see what happens?

- Jeff

[1] http://www.hanselman.com/blog/FusionLoaderContextsUnableToCastObjectOfTypeWhateverToTypeWhatever.aspx

From kuno.meyer at gmx.ch  Fri May  8 15:38:41 2015
From: kuno.meyer at gmx.ch (Kuno Meyer)
Date: Fri, 8 May 2015 13:38:41 +0000 (UTC)
Subject: [Ironpython-users] Failing to catch exception
References: <d5e08474caaf404ddf57e33f809f847c.squirrel@ssl-webmail-vh.clara.net>
Message-ID: <loom.20150508T152807-398@post.gmane.org>

Hi David

I cannot reproduce your issue (see below).

Since you are not able to catch the exception with a catch-all statement:

- Are you sure that the observed NoSuchElementException in the debugger
actually stems from code inside of the 'try' block?
- What does "crashing" mean? Could it be that the application crashes in
some unmanaged code portion executed in some inner 'catch' or 'final' block,
before it actually reaches your 'except' block?

Kuno

-----

import clr
import sys

sys.path.append(r"[...]")

clr.AddReference("WebDriver.dll")
from OpenQA.Selenium import *
from OpenQA.Selenium.IE import *

class MyWindow(object):
    def __init__(self):

        # Initialize the Selenium object and open the page to parse
        self.driver = InternetExplorerDriver()
        self.driver.Navigate().GoToUrl("http://www.google.com")

    def ParseStoryStandardFormat(self):
        try:
            flagIndicator = self.driver.FindElementByClassName("flag-indicator")
        except NoSuchElementException as ex:
            print ex

w = MyWindow()
w.ParseStoryStandardFormat();

-----

D:\mytemp>"c:\Program Files (x86)\IronPython 2.7\ipy.exe" selenium.py
Started InternetExplorerDriver server (32-bit)
2.41.0.0
Listening on port 49736
OpenQA.Selenium.NoSuchElementException: Unable to find element with class
name == flag-indicator
   at OpenQA.Selenium.Remote.RemoteWebDriver.UnpackAndThrowOnError(Response
errorResponse)
   at OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String
driverCommandToExecute, Dictionary`2 parameters)
   at OpenQA.Selenium.Remote.RemoteWebDriver.FindElement(String mechanism,
String value)
   at OpenQA.Selenium.Remote.RemoteWebDriver.FindElementByClassName(String
className)
   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
Microsoft.Scripting.Interpreter.DynamicInstruction`4.Run(InterpretedFrame frame)
   at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame)


From no_reply at codeplex.com  Sat May 16 15:44:26 2015
From: no_reply at codeplex.com (CodePlex)
Date: 16 May 2015 06:44:26 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/15/2015
Message-ID: <CO1MSDNADMCDS2R9Odu00029e00@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [New issue] Error while using Ironpython rpyc.classic.upload_file()

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

ISSUES

1. [New issue] Error while using Ironpython rpyc.classic.upload_file()
http://ironpython.codeplex.com/workitem/43125
User arjunna has proposed the issue:

"I am trying to upload a .gz file from my local Windows machine (with iron python installed) to remote Linux machine.Using IronPython as python interpreter.

Python code works great with normal python (cpython) interpreter can upload .gz files. Initially I thought because of the size of my .gz it failed but I have tried uploading a large text file (45MB) that copies well with IronPython but .gz(400kb) fails. Am i missing something ?

Iron Python version 2.7

Thanks

Python code
r= "10.xx.xx.130" #change this
conn = rpyc.classic.connect(r)
localfile= "C:\Drivers\ixgbe-3.23.2.1.tar.gz"
remotepath= "/home/admin/Desktop/myfolder/ixgbe-3.23.2.1.tar.gz"
rpyc.classic.upload_file(conn, localfile, remotepath)

Traceback (most recent call last): File
> "/usr/lib/python2.7/site-packages/rpyc-3.3.0-py2.7.egg/rpyc/core/protocol.py",
> line 305, in _dispatch_request
> res = self._HANDLERShandler File "/usr/lib/python2.7/site-packages/rpyc-3.3.0-py2.7.egg/rpyc/core/protocol.py",
> line 535, in _handle_call
> return self._local_objectsoid UnicodeEncodeError: 'ascii' codec can't encode character u'\x8b' in
> position 1: ordinal not in range(128)
"
----------------------------------------------



----------------------------------------------
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/20150516/816b9287/attachment.html>

From no_reply at codeplex.com  Sun May 17 11:25:15 2015
From: no_reply at codeplex.com (CodePlex)
Date: 17 May 2015 02:25:15 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 5/16/2015
Message-ID: <CO1MSDNADMCDS2N7miR0002a6b5@discussions.codeplex.com>

Hi ironpython,

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

In today's digest:ISSUES

1. [Status update] Error while using Ironpython rpyc.classic.upload_file()

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

ISSUES

1. [Status update] Error while using Ironpython rpyc.classic.upload_file()
http://ironpython.codeplex.com/workitem/43125
User slide_o_mix has updated the issue:
Status has changed from Proposed to Closed with the following comment, 

"Please use github for all issues"
----------------------------------------------



----------------------------------------------
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/20150517/b6abef8a/attachment.html>

From kerray.cz at gmail.com  Thu May 21 14:03:33 2015
From: kerray.cz at gmail.com (Kerray)
Date: Thu, 21 May 2015 14:03:33 +0200
Subject: [Ironpython-users] IronPython running WDB client
Message-ID: <CAM5UpT4yrVNbKJ7ow3LHn-qbQJ5CYxwwGG5DqfztdivmwDm8Zw@mail.gmail.com>

Hi,
https://github.com/Kozea/wdb is a slick remote debugger with web interface
which I've been eyeing for quite some time, and I think I'm not the only
one to whom this would be useful :)

Recently I've been able to run the client part of it in IronPython 2.7.6a0
with minor modifications (
https://github.com/kerray/wdb/commit/72019a080df8252c663e8e630d4fd104976ceff8).
The server part runs in CPython and for my purposes, this doesn't matter as
far as the code I'm debugging is IronPython.

There's a problem however that while I can now walk through IronPython
source in a browser window, WDB ignores the code in baseline module, and
only steps into the code when the module is executing a function. It steps
through the function, I can inspect variables etc, but when that function
ends, it doesn't step back into the module.

I've been asking and posting logs in WDB
https://github.com/Kozea/wdb/issues/51/ however it seems to be more of a
IronPython matter.

So please, any ideas? For example, does IronPython have the correct info in
frame.f_lineno?

Thanks for anything


Jarom?r "Kerray" Mat??ek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150521/1b9e7a21/attachment.html>

From m.schaber at codesys.com  Thu May 21 15:33:07 2015
From: m.schaber at codesys.com (Markus Schaber)
Date: Thu, 21 May 2015 13:33:07 +0000
Subject: [Ironpython-users] IronPython running WDB client
In-Reply-To: <CAM5UpT4yrVNbKJ7ow3LHn-qbQJ5CYxwwGG5DqfztdivmwDm8Zw@mail.gmail.com>
References: <CAM5UpT4yrVNbKJ7ow3LHn-qbQJ5CYxwwGG5DqfztdivmwDm8Zw@mail.gmail.com>
Message-ID: <727D8E16AE957149B447FE368139F2B55EC91381@SERVER10>

Hi,

As far as I know, the IronPython dynamic code generation does not generate Python frames by default, for optimization purposes (to leverage the .NET Just in Time compiler).

When the IronPython compiler parses your main module, sys.settrace() was not called yet, so the code generated there will work the optimized way.

IronPython has the options -X:Frames and -X:FullFrames which you can set either on the command line, or (in hosted environments) when you create the executor instance, then sys.settrace() should work for the top level frame, too.


Best regards

Markus Schaber

CODESYS? a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions
________________________________
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.schaber at codesys.com<mailto:m.schaber at codesys.com> | Web: codesys.com<http://www.codesys.com> | CODESYS store: store.codesys.com<http://store.codesys.com>
CODESYS forum: forum.codesys.com<http://forum.codesys.com>

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
________________________________
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received
this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure
or distribution of the material in this e-mail is strictly forbidden.
Von: Ironpython-users [mailto:ironpython-users-bounces+m.schaber=codesys.com at python.org] Im Auftrag von Kerray
Gesendet: Donnerstag, 21. Mai 2015 14:04
An: ironpython-users at python.org
Betreff: [Ironpython-users] IronPython running WDB client

Hi,
https://github.com/Kozea/wdb is a slick remote debugger with web interface which I've been eyeing for quite some time, and I think I'm not the only one to whom this would be useful :)

Recently I've been able to run the client part of it in IronPython 2.7.6a0 with minor modifications (https://github.com/kerray/wdb/commit/72019a080df8252c663e8e630d4fd104976ceff8). The server part runs in CPython and for my purposes, this doesn't matter as far as the code I'm debugging is IronPython.

There's a problem however that while I can now walk through IronPython source in a browser window, WDB ignores the code in baseline module, and only steps into the code when the module is executing a function. It steps through the function, I can inspect variables etc, but when that function ends, it doesn't step back into the module.

I've been asking and posting logs in WDB https://github.com/Kozea/wdb/issues/51/ however it seems to be more of a IronPython matter.

So please, any ideas? For example, does IronPython have the correct info in frame.f_lineno?

Thanks for anything


Jarom?r "Kerray" Mat??ek




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

From kerray.cz at gmail.com  Fri May 22 11:37:07 2015
From: kerray.cz at gmail.com (Kerray)
Date: Fri, 22 May 2015 11:37:07 +0200
Subject: [Ironpython-users] IronPython running WDB client
In-Reply-To: <727D8E16AE957149B447FE368139F2B55EC91381@SERVER10>
References: <CAM5UpT4yrVNbKJ7ow3LHn-qbQJ5CYxwwGG5DqfztdivmwDm8Zw@mail.gmail.com>
 <727D8E16AE957149B447FE368139F2B55EC91381@SERVER10>
Message-ID: <CAM5UpT6M6jDysty=53SEF866U0K4=k-_i+3TD43t8fiMEqM+bA@mail.gmail.com>

Hi Markus,
thanks for the tip, but I already do run it with -X:FullFrames :/

J

On Thu, May 21, 2015 at 3:33 PM, Markus Schaber <m.schaber at codesys.com>
wrote:

>  Hi,
>
>
>
> As far as I know, the IronPython dynamic code generation does not generate
> Python frames by default, for optimization purposes (to leverage the .NET
> Just in Time compiler).
>
>
>
> When the IronPython compiler parses your main module, sys.settrace() was
> not called yet, so the code generated there will work the optimized way.
>
>
>
> IronPython has the options -X:Frames and -X:FullFrames which you can set
> either on the command line, or (in hosted environments) when you create the
> executor instance, then sys.settrace() should work for the top level frame,
> too.
>
>
>
>
>
> Best regards
>
> Markus Schaber
>
> *CODESYS?* a trademark of 3S-Smart Software Solutions GmbH
>
> *Inspiring Automation Solutions *
>  ------------------------------
>
> 3S-Smart Software Solutions GmbH
> Dipl.-Inf. Markus Schaber | Product Development Core Technology
> Memminger Str. 151 | 87439 Kempten | Germany
> Tel. +49-831-54031-979 | Fax +49-831-54031-50
>
> E-Mail: m.schaber at codesys.com | Web: codesys.com <http://www.codesys.com>
> | CODESYS store: store.codesys.com
> CODESYS forum: forum.codesys.com
>
> *Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner* | *Trade
> register: Kempten HRB 6186* | *Tax ID No.: DE 167014915*
> * ------------------------------ *
>
>
>
> *This e-mail may contain confidential and/or privileged information. If
> you are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorised copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.*
>
> *Von:* Ironpython-users [mailto:ironpython-users-bounces+m.schaber=
> codesys.com at python.org] *Im Auftrag von *Kerray
> *Gesendet:* Donnerstag, 21. Mai 2015 14:04
> *An:* ironpython-users at python.org
> *Betreff:* [Ironpython-users] IronPython running WDB client
>
>
>
> Hi,
>
> https://github.com/Kozea/wdb is a slick remote debugger with web
> interface which I've been eyeing for quite some time, and I think I'm not
> the only one to whom this would be useful :)
>
>
>
> Recently I've been able to run the client part of it in IronPython 2.7.6a0
> with minor modifications (
> https://github.com/kerray/wdb/commit/72019a080df8252c663e8e630d4fd104976ceff8).
> The server part runs in CPython and for my purposes, this doesn't matter as
> far as the code I'm debugging is IronPython.
>
>
>
> There's a problem however that while I can now walk through IronPython
> source in a browser window, WDB ignores the code in baseline module, and
> only steps into the code when the module is executing a function. It steps
> through the function, I can inspect variables etc, but when that function
> ends, it doesn't step back into the module.
>
>
>
> I've been asking and posting logs in WDB
> https://github.com/Kozea/wdb/issues/51/ however it seems to be more of a
> IronPython matter.
>
>
>
> So please, any ideas? For example, does IronPython have the correct info
> in frame.f_lineno?
>
>
>
> Thanks for anything
>
>
>
>
>
> Jarom?r "Kerray" Mat??ek
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150522/f76195bf/attachment.html>

From fernandez_dan2 at hotmail.com  Sun May 24 17:17:54 2015
From: fernandez_dan2 at hotmail.com (Daniel Fernandez)
Date: Sun, 24 May 2015 09:17:54 -0600
Subject: [Ironpython-users] IronPython running WDB client
In-Reply-To: <CAM5UpT6M6jDysty=53SEF866U0K4=k-_i+3TD43t8fiMEqM+bA@mail.gmail.com>
References: <CAM5UpT4yrVNbKJ7ow3LHn-qbQJ5CYxwwGG5DqfztdivmwDm8Zw@mail.gmail.com>,
 <727D8E16AE957149B447FE368139F2B55EC91381@SERVER10>,
 <CAM5UpT6M6jDysty=53SEF866U0K4=k-_i+3TD43t8fiMEqM+bA@mail.gmail.com>
Message-ID: <BLU184-W94BE08ACDA062FCC66A7F7A2CE0@phx.gbl>

Hi All,
 
It looks like one is always returned for f_lineno. Here is the output for a simple example output IronPython vs CPython. I used -X:FullFrames for ipy.exe.
 
IronPython 2.7.5 (2.7.5.0) on .NET 4.0.30319.0 (32-bit)
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> def fun():
...     a = 2
...     b = 3
...     c = 4
...     print(sys._getframe().f_lineno)
...
>>> fun()
1
 
Python 2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> def fun():
...     a = 2
...     b = 3
...     c = 4
...     print(sys._getframe().f_lineno)
...
>>> fun()
5
 
I also created a script with the same simple code and ran the script instead of creating the function in the interactive console and it had the same result as above. 
 
Danny
 
 

 
From: kerray.cz at gmail.com
Date: Fri, 22 May 2015 11:37:07 +0200
To: m.schaber at codesys.com; ironpython-users at python.org
Subject: Re: [Ironpython-users] IronPython running WDB client

Hi Markus,thanks for the tip, but I already do run it with -X:FullFrames :/
J
On Thu, May 21, 2015 at 3:33 PM, Markus Schaber <m.schaber at codesys.com> wrote:








Hi,
 
As far as I know, the IronPython dynamic code generation does not generate Python frames by default, for optimization purposes (to leverage the .NET Just in Time
 compiler).
 
When the IronPython compiler parses your main module, sys.settrace() was not called yet, so the code generated there will work the optimized way.
 
IronPython has the options -X:Frames and -X:FullFrames which you can set either on the command line, or (in hosted environments) when you create the executor instance,
 then sys.settrace() should work for the top level frame, too. 
 
 
Best regards



Markus Schaber



CODESYS?
a trademark of 3S-Smart Software Solutions GmbH




Inspiring Automation Solutions




3S-Smart Software Solutions GmbH


Dipl.-Inf. Markus Schaber | Product Development Core Technology 

Memminger Str. 151 | 87439 Kempten | Germany 

Tel. +49-831-54031-979 | Fax +49-831-54031-50 



E-Mail: m.schaber at codesys.com
 | Web: codesys.com
 | CODESYS store: store.codesys.com


CODESYS forum: forum.codesys.com




Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner
 | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915




This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received


this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure


or distribution of the material in this e-mail is strictly forbidden.




Von: Ironpython-users [mailto:ironpython-users-bounces+m.schaber=codesys.com at python.org]
Im Auftrag von Kerray

Gesendet: Donnerstag, 21. Mai 2015 14:04

An: ironpython-users at python.org

Betreff: [Ironpython-users] IronPython running WDB client


 

Hi,

https://github.com/Kozea/wdb is a slick remote debugger with web interface which I've been eyeing for quite some time, and I think I'm not the only one to whom this would be useful :)


 


Recently I've been able to run the client part of it in IronPython 2.7.6a0 with minor modifications (https://github.com/kerray/wdb/commit/72019a080df8252c663e8e630d4fd104976ceff8).
 The server part runs in CPython and for my purposes, this doesn't matter as far as the code I'm debugging is IronPython.


 


There's a problem however that while I can now walk through IronPython source in a browser window, WDB ignores the code in baseline module, and only steps into the code when the module is executing a function. It steps through the function,
 I can inspect variables etc, but when that function ends, it doesn't step back into the module.


 


I've been asking and posting logs in WDB 
https://github.com/Kozea/wdb/issues/51/ however it seems to be more of a IronPython matter.


 


So please, any ideas? For example, does IronPython have the correct info in frame.f_lineno?


 


Thanks for anything


 


 


Jarom?r "Kerray" Mat??ek



 


 


 


 










_______________________________________________
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/20150524/f2b027ad/attachment.html>

From fernandez_dan2 at hotmail.com  Sun May 24 21:51:33 2015
From: fernandez_dan2 at hotmail.com (Daniel Fernandez)
Date: Sun, 24 May 2015 13:51:33 -0600
Subject: [Ironpython-users] IronPython running WDB client
In-Reply-To: <BLU184-W94BE08ACDA062FCC66A7F7A2CE0@phx.gbl>
References: <CAM5UpT4yrVNbKJ7ow3LHn-qbQJ5CYxwwGG5DqfztdivmwDm8Zw@mail.gmail.com>, ,
 <727D8E16AE957149B447FE368139F2B55EC91381@SERVER10>, ,
 <CAM5UpT6M6jDysty=53SEF866U0K4=k-_i+3TD43t8fiMEqM+bA@mail.gmail.com>,
 <BLU184-W94BE08ACDA062FCC66A7F7A2CE0@phx.gbl>
Message-ID: <BLU184-W378876C863876EF0EAA463A2CE0@phx.gbl>

Hi All,
 
I was mistaken I needed to add -X:Tracing which enable the correct f_lineno
 
Danny
 
From: fernandez_dan2 at hotmail.com
To: kerray.cz at gmail.com; m.schaber at codesys.com; ironpython-users at python.org
Date: Sun, 24 May 2015 09:17:54 -0600
Subject: Re: [Ironpython-users] IronPython running WDB client




Hi All,
 
It looks like one is always returned for f_lineno. Here is the output for a simple example output IronPython vs CPython. I used -X:FullFrames for ipy.exe.
 
IronPython 2.7.5 (2.7.5.0) on .NET 4.0.30319.0 (32-bit)
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> def fun():
...     a = 2
...     b = 3
...     c = 4
...     print(sys._getframe().f_lineno)
...
>>> fun()
1
 
Python 2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> def fun():
...     a = 2
...     b = 3
...     c = 4
...     print(sys._getframe().f_lineno)
...
>>> fun()
5
 
I also created a script with the same simple code and ran the script instead of creating the function in the interactive console and it had the same result as above. 
 
Danny
 
 

 
From: kerray.cz at gmail.com
Date: Fri, 22 May 2015 11:37:07 +0200
To: m.schaber at codesys.com; ironpython-users at python.org
Subject: Re: [Ironpython-users] IronPython running WDB client

Hi Markus,thanks for the tip, but I already do run it with -X:FullFrames :/
J
On Thu, May 21, 2015 at 3:33 PM, Markus Schaber <m.schaber at codesys.com> wrote:








Hi,
 
As far as I know, the IronPython dynamic code generation does not generate Python frames by default, for optimization purposes (to leverage the .NET Just in Time
 compiler).
 
When the IronPython compiler parses your main module, sys.settrace() was not called yet, so the code generated there will work the optimized way.
 
IronPython has the options -X:Frames and -X:FullFrames which you can set either on the command line, or (in hosted environments) when you create the executor instance,
 then sys.settrace() should work for the top level frame, too. 
 
 
Best regards



Markus Schaber



CODESYS?
a trademark of 3S-Smart Software Solutions GmbH




Inspiring Automation Solutions




3S-Smart Software Solutions GmbH


Dipl.-Inf. Markus Schaber | Product Development Core Technology 

Memminger Str. 151 | 87439 Kempten | Germany 

Tel. +49-831-54031-979 | Fax +49-831-54031-50 



E-Mail: m.schaber at codesys.com
 | Web: codesys.com
 | CODESYS store: store.codesys.com


CODESYS forum: forum.codesys.com




Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner
 | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915




This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received


this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure


or distribution of the material in this e-mail is strictly forbidden.




Von: Ironpython-users [mailto:ironpython-users-bounces+m.schaber=codesys.com at python.org]
Im Auftrag von Kerray

Gesendet: Donnerstag, 21. Mai 2015 14:04

An: ironpython-users at python.org

Betreff: [Ironpython-users] IronPython running WDB client


 

Hi,

https://github.com/Kozea/wdb is a slick remote debugger with web interface which I've been eyeing for quite some time, and I think I'm not the only one to whom this would be useful :)


 


Recently I've been able to run the client part of it in IronPython 2.7.6a0 with minor modifications (https://github.com/kerray/wdb/commit/72019a080df8252c663e8e630d4fd104976ceff8).
 The server part runs in CPython and for my purposes, this doesn't matter as far as the code I'm debugging is IronPython.


 


There's a problem however that while I can now walk through IronPython source in a browser window, WDB ignores the code in baseline module, and only steps into the code when the module is executing a function. It steps through the function,
 I can inspect variables etc, but when that function ends, it doesn't step back into the module.


 


I've been asking and posting logs in WDB 
https://github.com/Kozea/wdb/issues/51/ however it seems to be more of a IronPython matter.


 


So please, any ideas? For example, does IronPython have the correct info in frame.f_lineno?


 


Thanks for anything


 


 


Jarom?r "Kerray" Mat??ek



 


 


 


 










_______________________________________________
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 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150524/6d9fd0ff/attachment.html>