IronPython 与长布尔表达式相关的错误？
这里似乎发生了一些有趣的事情。使用 IronPython 2.6.2 for .NET 4.0，我得到以下行为。最简单的情况如下：
- 我启动交互式 shell
我输入以下行 5 次
假或假或假或假或假或假或\然后以下行结束
假或假或假或假或假或假
当我输入此内容时，该进程在相当好的桌面上占用了 30 个 CPU 分钟，但仍未返回。
如果我将步骤 2 减少 1 次，即该行出现 4 次，那么它会在大约一两分钟内返回。
如果我将步骤 2 减少 2，即。排队 3 次，然后大约一秒左右返回。
那么到底发生了什么，为什么呢？
当然，导致我将其隔离的现实世界的例子要复杂得多，而且看起来并不那么无聊。
谢谢 阿基尔
There seems to be something funny going on here. Using IronPython 2.6.2 for .NET 4.0, I get the following behaviour. The simplest case is as follows:
- I start the interactive shell
I type the following line 5 times
False or False or False or False or False or False or \I then end it with the following line
False or False or False or False or False or False
As I am typing this, the process has clocked up 30 CPU minutes on a fairly good desktop and still not returned.
If I reduce step 2 by 1 i.e. have the line 4 times, then it returns in about a minute or two.
If I reduce step 2 by 2 ie. have the line 3 times, then it returns in about a second or so.
So what is happening, and why?
Of course, the real world example that caused me to isolate this is much more complex and not quite as frivolous looking.
Thanks
Akil
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我建议在 CodePlex 上打开一个错误。这里发生的是 IronPython 的 OrExpression AST 节点正在尝试发现它的类型。为此，它会查看左手类型和右手类型。如果它们相同，OrExpression 将生成左侧类型的表达式 - 再次检查。第二个电话是导致这种情况不成比例增长的主要原因。只需将 OrExpression.cs 从： 更改
为：
即可解决问题。
I'd suggest opening a bug on CodePlex. What's happening here is that IronPython's OrExpression AST node is attempting to discover it's type. To do that it looks at the left hand type and the right hand type. If they're the same OrExpression will produce an expression of the type on the left hand side - which is checked again. That 2nd call is mostly what causes this to grow out of proportion. Simply changing OrExpression.cs from:
to:
fixes the problem.