2024年Clojure状态调查中分享您的想法!

欢迎!请查看关于页面,了解更多对此如何运作的信息。

0
Clojure

它应该按预期工作,例如

{{(Integer. 1N)}}

很可能对{{BigInt}}、{{BigInteger}}和{{BigDecimal}}有效。

根据Rich在irc中的要求,要查看的方法是{{c.l.Reflector.paramArgTypeMatch}}。

11 个答案

0

评论者:trptcolin

关于此影响bit-shift-left的问题在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类型的大小,所以方法的选择是错误的,因此补丁已经损坏。
建议“简单地”修改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.


考虑到把这个问题从Release.next中移除 - 正在征求Chas的评论。

0

Comment made by: redinger

正在考虑将这个问题从Release.next中移除 - 征求Chas的评论。

0
_Comment made by: cemerick_

恐怕我对此问题涉及的任何问题没有特别深刻的见解。 我最初在一段时间前遇到了这个问题,并按照Rich的建议打开了问题追踪。 如果问题追踪文本导致任何人走了没有结果的路线,我感到抱歉...
0

Comment made by: lvanderhart

关于位移动的问题不具有实际意义,因为已经决定位移动仅适用于32/64位值。

这是一个有效的问题,但按照Rich的意思降低了优先级。

0

Comment made by: alexott

原始补丁的修改版本

0

Comment made by: jafingerhut

Alex,你介意上传一个唯一的文件名吗?我知道JIRA允许我们上传具有相同文件名的多个附件,也知道我们可以通过日期和上传附件的人的账户来区分它们,但给它们相同的名字似乎只会引起混淆。

0

Comment made by: alexott

将更新补丁重命名为唯一名称

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