Hi ironpython,
Here's your Daily Digest of new issues for project "IronPython".
In today's digest:ISSUES
1. [New comment] Importing .NET types causes ImportExceptions (zipimport
handler)
2. [New issue] help() commands from StdLib fail/hang
----------------------------------------------
ISSUES
1. [New comment] Importing .NET types causes ImportExceptions (zipimport
handler)
http://ironpython.codeplex.com/workitem/34602
User sopelt has commented on the issue:
"<p>Thank you for the quick response.</p><p>> this behavior needs to be
maintained for compatibility</p><p>So the importer architecture and
implementation is specified to that detail?</p><p><br>> just tell the
debugger to ignore those exceptions</p><p>I know that Visual Studio's
"Just my Code" will help for many situations but we often run into
the scenario that we want to see "significant" exceptions occuring in
third party libraries.</p><p>> lightweight exceptions</p><p>What do you mean
by lightweight exceptions in the context of .NET/DLR/IronPython? Is there a
concept for that or do you mean using something like return codes? I don't
expect this to be super-easy because the exception seems to be thrown by the
zipimporter constructor.</p><p>I am not quite sure why the zipimporter needs to
be consulted at all for non-zipfile situations but I must admit that I haven't
looked into the spec and the code with too much detail...</p>"-----------------
2. [New issue] help() commands from StdLib fail/hang
http://ironpython.codeplex.com/workitem/34606
User owlmonkey has proposed the issue:
"We incorporate IronPython into our app as a console and it's super handy for
reflection of our objects. Some folks like using the stdlib pydoc help commands
to get a summary of object methods and usage. This started failing and/or
hanging our process when we upgraded to IronPython 2.6.2 and now 2.7.4 so I
finally dug into it.
Looks like the problem is in the StdLib, in that it doesn't recognize the "cli"
returned from sys.platform in the pydoc module. As a result it chooses a
pipedpager which then fails or hangs based on the output length.
Specifically it's in the code that determines what kind of pager to use, for
long outputs. It checks for sys.platform to see if it should use a pipe (on
unix presumably) or a temporary file or just stream the output directly. What's
happening in our system on Windows or on Mono is that sys.platform returns
"cli" and the code tries to use a pager that's not really supported. And then
the IO.StreamWriter it uses can hang if it buffer overflows. My workaround for
now is to add some code to check for a "cli" response to that file and have it
return a plainpager instead of a pipedpager. This worked around the problem
fully for us.
So when including the StdLib code into the IronPython project, would be super
helpful to incorporate some diffs wherever it uses sys.platform based logic to
also recognize "cli""
----------------------------------------------
----------------------------------------------
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.
_______________________________________________
Ironpython-users mailing list
Ironpython-users@python.org
https://mail.python.org/mailman/listinfo/ironpython-users
