在人人对话中分享您的想法吧!2024 Clojure状态调查

欢迎!请参阅关于页面以了解有关此工作的更多信息。

0
Clojure

它应该按预期工作,例如

{{(Integer. 1N)}}

可能适用于{{BigInt}}、{{BigInteger}}和{{BigDecimal}}。

参照Rich在irc中的建议,查看的方法是{{c.l.Reflector.paramArgTypeMatch}}。

11 个答案

0

评论由:trptcolin

有关如何影响左移位的clojure-dev列表中的问题:http://groups.google.com/group/clojure-dev/browse_thread/thread/2191cbf0048d8ca6

0

评论由:ataggart

CLJ-445补丁也修复了此问题。

0

评论由:trptcolin

此补丁失败了一个关于左移BigInt的测试:(bit-shift-left 1N 10000)。原因是补丁更改了(BigInt, Long)的分配从(Object, Object)到(long, int)。

显然这不能应用(除非另一个更改使其成为可能),但我会提出作为对话的开始。

0

评论由:ataggart

邮件列表中的我的评论

如果测试失败,这很可能意味着选择了 Numbers.shiftLeft(long,int),而不是 Numbers.shiftLeft(Object,Object)。
鉴于1N是一个Object(其大小可以超过long的大小),选择的方法是不正确的,因此补丁是 broke.
由于编译器内部没有足够智能来做出这些决定,因此仅仅修改paramArgTypeMatch的提议是不够的。
The suggestion of "simply" modifying paramArgTypeMatch is not sufficient since the mechanism for preferring one method over another lives in Compiler, and isn't smart enough to make these sorts of decisions.


由于编译器内部没有足够智能来做出这些决定,因此仅仅修改paramArgTypeMatch的提议是不够的。

0

评论者:redinger

考虑将此移出Release.next - 向Chas征求意见。

0
_评论者:cemerick_

目前我对涉及的问题还没有特别的见解。我最初遇到了这个问题,是按照Rich的建议打开的。很抱歉,如果票据的文本将任何人引向了不成功的路径...
0

评论者:lvanderhart

关于位操作的问题不再重要,因为决定仅对32/64位值进行位操作。

仍然是一个有效的问题,但按Rich的建议降低优先级。

0

评论者:alexott

原始补丁的修改版本

0

评论者:jafingerhut

亚历克斯,您可以附上一个独一无二的文件名吗?我知道JIRA允许我们使用同一文件名创建多个附件,并且我们知道可以通过日期和上传附件账户的个人信息来区分它们,但给它们相同的名称似乎只会引发混淆。

0

评论者:alexott

将更新的补丁重命名为独一无二的名称

0
参考: https://clojure.atlassian.net/browse/CLJ-666(由cemerick报告)
...