Needs work

Patch 0001-Add-hasheq-based-fallback-to-Util.compare.patch dated Apr 17 2013 applies cleanly to latest master, but causes several unit tests in data_structures.clj to fail. These are the kinds of things you would expect to fail with the change made in the patch, because the failing tests expect an exception to be thrown when comparing objects that don't implement Comparable, and with this patch's changes they no longer do. If this patch's change is desired, those tests should probably be removed.

Thanks Andy, I can't believe I've forgotten to re-run the tests.

Anyway, I'm attaching a new version of the patch that deletes the few sorted-set and sorted-set-by invocations that check that an exception is thrown when creating sorted sets containing non-Comparables.

New version of the patch.

Tassilo, you say that one of your use cases is sorted collections. Note that any compare function that returns 0 for two values will cause sorted sets and maps to treat the two compared values as equal, and at most one of them will get into the ordered set/map, the second treated as a duplicate, even though the values are not equal. See https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/comparators.md#comparators-for-sorted-sets-and-maps-are-easy-to-get-wrong for an example (not based on your modified compare, but on a comparator that returns 0 for non-equal items).

With your proposed change to compare, this occurrence would become very dependent upon the hash function used. Probably quite rare, but it would crop up from time to time, and could potentially be very difficult to detect and track down the source.

Hi Andy, you are right. It's possible to add an explicit equals()-check in cases the hashcodes are the same, but I think there's nothing you can do in the hashcodes-equal-but-objects-are-not case. That is, there's no way to ensure the rule sgn(compare(x, y)) == -sgn(compare(y, x)), the transitivity rule, and the compare(x, y)==0 ==> sgn(compare(x, z))==sgn(compare(y, z)) for all z rule.

I'm closing that ticket.

I guess you didn't try to actually use the function to see if it is actually broken...

m is not a argument vector, those are below in the function clauses.

I did, but as it turns out the error was somewhere else and I can't reproduce it within a "clean" environment. Sorry for this hasty ticket.

Dmitry, do you think it is OK to close this ticket as declined, meaning no change will be made in response to it? I can do that for you, if you wish.

Andy, I'll close it myself if you don't mind. I would done it earlier, but didn't have sufficient rights in JIRA.

Attached the straightforward patch which solves this issue.

The example shows valid Clojure code.

Irakli, it is an explicitly documented feature that conj puts new items in different places for lists (at the beginning) and vectors (at the end). rest is explicitly documented to call seq on its argument. See their doc strings.

I don't know if it is explicitly documented, or just long-standing practice, that vectors and seqs with the the same sequence of values in them are equal. I think that a lot of existing code would break if Clojure changed so those were not equal.

=> (last (range 0.0 10000000.0 0.1))
9999999.98112945
=> (last (range' 0.0 10000000.0 0.1))
9999999.9

Range is incremental by design, and that is how floats work. Something with the desired behavior would need to be a different fn with a different name.

"Returns a lazy seq of nums from start (inclusive) to end (exclusive), by step"

What specifically about that wording specifically suggests that the implementation will use naive increment-and-recurse behaviour? My reading is that the function will return a lazy sequence of numbers from start to end separated by step, not separated by 'almost step'.

This implementation leads to unexpected behaviour with bounds:

=> (count (range 0 100 1))
100
=> (count (range 0 10 0.1))
101

http://www.ima.umn.edu/~arnold/455.f96/disasters.html

range could avoid this issue cleanly by converting floats to bigdecimals (let me know if you think this is a good idea?)

I ran into this problem recently, and have to say it was pretty ugly. This is how I avoided the issue:

(defn rangef
"Returns a sequence of n numbers from start to end inclusive."
[start end n]
(for [i (range 0 n)]
(+ start (* i (/ (- end start) (dec n))))))

Hope that helps any disillusioned float users out there, or just pass in BigDecimals to range instead of floats... I would go so far as to say using floats with range as it stands is almost always going to end in tears (or worse as Stephen describes ).

[and just to be clear if it is considered an error, it would be nice if range explicitly forbade it]

It appears from the doc string that this function does exactly what it claims it will do, without any changes.

You're right.
Somehow I parsed the doc string wrongly. My sincere apologies! Can be marked invalid.

Closing as declined, since submitter agrees that code behavior and documentation match.

It is easy for tools that consume Clojure to hide stack traces for those who do not want to see them. If Clojure itself eats stack traces, it is impossible for those of us who do want to see them to get them back.

Please do this kind of work in tool (if at all) and make it optional for users.

It's worth noting that there was a breakin to rubygems.org over the weekend that was caused by what amounts to this same issue, but with YAML: https://news.ycombinator.com/item?id=5141138

The current default is both dangerous and undocumented; this needs to change.

Seconded!

Thirded.

For what it's worth, on the topic of breaking changes I'd much rather my old code break than continue to work with an unnoticed security hole.

Fourthed. I hope folks will pitch in and help deal with any breakage.

New patch attached, {{CLJ-1185.patch}}.

This patch eliminates the use of *print-dup* in the compiler entirely. read-string continues to be used to support values that can only be represented via tagged reader literals; I don't think there's any way around that, since the mapping between particular data readers and values' types are buried in individual print-method implementations.

All tests pass (including cases like (eval (list + 1 2 3)) as discussed in the ML thread referenced in the issue description), and a variety of sanity checks around evaluation and compilation tooling (e.g. AOT, nREPL, introspection utilities in Leiningen/Reply/Counterclockwise) all work as expected.

Of course, if this is applied, then any usage of read over trusted content containing #= forms will need to be done with *read-eval* bound to true.

To aid in testing, a Clojure build (1.5.0-RC4) + this patch is available here:

[com.cemerick/clojure "1.5.0-SNAPSHOT"]

Note that you'll have to exclude the standard Clojure dependency from your project in order for this one to take precedence; you can do this by adding

:exclusions [org.clojure/clojure]

to your project.clj.

I ran the Sonian test base against this patch. I wouldn't say our test cases are comprehensive, but they're not trivial. We talk to databases through JDBC, and we deal with lots of different data types (BigInts, Strings, Dates, and such).

I had to make a few small changes to our code base, because we rely pretty heavily on print-dup to serialize non-user originated data. We have to add corresponding binding blocks when reading to set read-eval to true. Other than that, the tests all passed.

+1

Thanks to all that have tested the patch! Looks like we've made some progress. I'm going to post to the main Clojure ML now and hopefully get more yay/nay votes.

clj-1153-patch-v2.txt dated Feb 2 2013 is functionally identical to Chas Emerick's CLJ-1185.patch dated Feb 1 2013, and no retesting is needed by anyone because of it.

The only change I have made to his patch is: the doc string for read-eval now says its default value is false.

Also removed my original didn't-fix-enough-things patch from Jan 30 2013.

I'm bumping the Priority field from its default value to "Major" to reflect recent events. (I personally feel "blocker" would be more appropriate, or at least "critical", but I don't want to step on any toes.)

https://github.com/clojure/clojure/commit/974a64c06917861b7557fd73154254195b2de548

This ticket is an excellent example of a terrible ticket.

1) It does not lead with a problem statement. The title takes the form akin to "I want X". It proposes a tactic.

2) The description is woefully inadequate. Here too, no problem statement. Descriptions should point to any discussions, but discussions are long and rambling, and no substitute for a succinct problem statement in the description. Descriptions need to be maintained, with the current strategy and name of best patch.

3) No resolution strategy. Just patches attached. How is a reviewer supposed to assess your patch if you don't even bother stating what the problem is and what your approach will be in fixing it, how that approach does fix it, and what if any tradeoffs are being made?

4) The change being requested would be a breaking change. That should be made extremely clear in the description, and doubles the threshold for quality of motivation and implementation.

5) Any breaking change would have to carefully enumerate what would break and when, what the migration strategy would be etc.

6) The patch breaks the compiler. If you don't understand how the compiler works, and why features are there, you shouldn't submit patches that alter it. The only assessments made in comments are 'it works for me', which, while useful anecdotes, are insufficient.

While the ticket itself was bad, the uncritical rallying behind it was more troubling. This is not how Clojure was built, and will not be how it is maintained.

In the end, the ticket proposed a tactic, and that tactic has been rejected. Read safety has been addressed by other means.

• Clojure: 1.5.0-RC1
• Java: Java 1.7.0_05 Java HotSpot(TM) 64-Bit Server VM
• Leiningen: 2.0.0-preview10
• lein-swank: 1.4.4
• lein-ritz: 0.6.0

I suppose I should add that I'm using Mac OS X 10.8.2

Have you noticed that swank-clojure [1] is deprecated, i.e. no longer under active development, and the developer recommends that you use nrepl.el [2] instead?

[1] https://github.com/technomancy/swank-clojure
[2] https://github.com/kingtim/nrepl.el

It also appears that someone has created an update to lein-swank (to version 1.4.5) that works with Clojure 1.5.0-RC1:

https://groups.google.com/forum/#!topic/clojure/CAiajyDWJJg

(in particular Toby Crawley's post on Dec 26 2012)

Yes, this can be closed.

Submitter agrees this issue was resolved by changes in other software outside of Clojure.

Attached patch changes do-copy methods to test for -1

Herwig, can you elaborate on "the specification is pretty clear in that InputStream implementations are allowed to return reads of zero bytes before returning more bytes"?

I ask because in the very InputStream documentation page you link to, it seems to explicitly say the opposite of what you claim: "If no byte is available because the stream is at the end of the file, the value -1 is returned; otherwise, at least one byte is read and stored into b."

I reread the spec for InputStream.read and it clearly says

"If no byte is available because the stream is at the end of the file, the value -1 is returned; otherwise, at least one byte is read and stored into b."

The reason I originally thought of this as an issue was a misbehaving ServletInputStream from Jetty.

I closed the issue as declined. Sorry for the noise!

At first glance, it appears that there could be some code sharing here. But the attached patch changes the semantics of run, which is a non-starter.

The only thing that changes is the type of thrown exception.

Current call tree:

Keyword.run() -> throw new UnsupportedOperationException()

Call tree with patch applied:

Keyword.run() -> AFn.run() -> AFn.invoke() -> AFn.throwArity(0) -> throw new ArityException(...)

(I.e. Keyword.run() always throws an exception, with and without my patch.)

It is unusual in Clojure to expect/rely on concrete list? checks, particularly given the prevalence of seq?

If the behavior documented here is causing problems, please discuss use case on mailing list, and then we can open a ticket.

OSX

this is not a bug in clojure.

declare creates an unbound var then your def tries to use the value of the var before you have given it a value.

declare does not let you use a value of a var before you have given it one (via def or whatever).

meta comment:
I would close this as "Declined", but I am not sure if that is kosher for me to do.

Thanks for looking into this.

Just want to point out that as far as the declare and the use of expr as a forward reference, the second scenario I've presented (with factor*) uses (declare) the same way, yet it works: the var "expr" in (factor*) ends up pointing to the root value set later, but before it runs.

Seems to me similar to this case, where f is defined in terms of itself and it works fine, having the var "f" obtained its root binding after the def form runs:

user=> (def f (fn [n] (if (< n 1) 1 (* n (f (- n 1))))))
#'user/f
user=> (f 6)
720

Given that I've got a usage that works, I would suspect that there's something about the first case that prevents the root binding to be visible to the declared var.

the formatting of the second case makes it hard to read, but it looks like expr is referenced inside a function, so the var #'expr will not be derefed until the function is run.

Though the difference isn't quite apparent to me, I kind of grasp the idea that the var may be in one case deref'ed earlier in one case than the other because calls to (bind) are eager and in the case of the additional call to (between) the var is inside the function. I'll ask the board for advice on this and this ticket can be closed. Thanks.

Closed based on discussion in comments.

Please close and reject. The patch is not working if val has non final fields.

Ian, thanks for the patch. It is Rich Hickey's policy only to consider applying patches to Clojure from those who have signed a Clojure contributor agreement: http://clojure.org/contributing

Were you interested in doing so, or perhaps it is already in progress?

I wasn't aware that this was necessary. I'm mailing the form in.

Patch clj-1042-negative-subs-patch2.txt dated Aug 27 2012 is identical to Ian Eure's negative-subs.patch, except it is in the desired git format.

Ian, for future reference on creating patches in the desired format, see the instructions under the heading "Development" on this page: http://dev.clojure.org/display/design/JIRA+workflow

Thanks, will do.

If Clojure decides to support Python-style negative indices, you should also consider adding support to subvec.

Patch extended to support negative indices on (subvec) as well.

The arg to rindex should probably be tagged with ^clojure.lang.Counted instead of ^String now.

Regarding the previous comment, String is a Java class so it isn't a clojure.lang.Counted. Is the type hint necessary? Maybe it should be on the call rather than the defn.

Ignoring the type hinting, I'll suggest a slightly simpler way to implement the rindex logic:

(defn rindex [coll i]
(if (neg? i) (+ (count coll) i) i))

In any case, I'm not sure rindex should be public even if you want the subs and subvec enhancements. Someone needs to make the case for adding a new function to core.

The Pythonic negative index is a debatable feature since it's pretty easy to implement for yourself if you want it.

Sorry, the type hint on rindex args isn't necessary at all. Just looked up in the source, calling count should never be reflective, since (count ..) emits calls to clojure.lang.RT/count.

Your solution looks good.

Negative indices were considered and rejected a long time ago. (I am merely conveying information--I have no strong opinion on this one.)

Note: If some people really like negative index behavior as in Perl or Python, it is straightforward to create a library of functions in a different namespace, perhaps with different names, that can do it. Perhaps a "pythonisms" library?

Would this be accepted as part of clojure.string instead? I considered putting it there, but thought it would be confusing to have multiple substring functions in different namespaces.

This is very helpful in practice, and I'd really like to see at least the (subs) stuff in Clojure.

Disclaimer: I'm no Clojure/core member, so can't speak authoritatively on whether something would or would not be accepted into clojure.string.

However, given that clojure.string is distributed with clojure.core, my guess is it would not be accepted. You'd be able to get things like this out for you and others as a separate library distributed on Clojars. That would also make it easy to include other Python-like things that you don't find in Clojure already.

This isn't about "python-like things," this is about a useful feature. Lots of languages support this: Perl, PHP, Ruby, Python, JavaScript, to name a few. Are you really suggesting that I should create a whole package for a version of a function in clojure.core with slightly different semantics? That's insane.

Anyway, I'm done wasting my time trying to navigate this hopelessly broken process. Maybe it would have been accepted if I included yet another way to interoperate with Java types.

Stuart, do you remember why specifically negative indexes were rejected? Developing a separate library for a minor improvement to an existing function sounds unreasonable.

some explanation about this topic was given by Rich Hickey himself here: http://news.ycombinator.com/item?id=2053908

citation:
"...Yes, there is a backlog from when it was just me, and it will take a while to whittle down. We have finite resources and have to prioritize. I can assure you we have more important things to concentrate on than your negative index substring enhancement, and are doing so. You'll just have to be patient. Or, if you insist, I'll just reject it now because a) IMO it's goofy, b) you can make your own function that works that way c) we don't get a free ride from j.l.String, d) it begs the question of negative indices elsewhere..."

i've been following this thread hoping this feature would be included. but whatever the reason was for the rejection, i'm sure it was thoughtful. great thanks for this wonderful language, and thanks Ian Eure for his effort.

That HN link eventually leads back to CLJ-688 which was rejected.

Michael: A proposal for negative indexes would need to be systematic in considering implications for all functions that have index arguments.

Ian: Clojure is driven by design, not incremental piling of features.

All: clojure.string is incomplete in more important and fundamental ways than negative indexes. This sucks now, and will suck worse as more code is written in different dialects. I find myself wishing string was a contrib, so we could iterate faster.

Stuart: Any specific proposals for how you'd like to see clojure.string improve? If it can be made a contrib, that would be cool, but understood if that would be considered too breaking of a change. Even if it isn't made a contrib, having tickets for improvement ideas you are willing to see means patches might get written, and they'll get in some time.

Hi Warren,

Importing a Java class and using a record are two logically distinct ideas, hence two separate steps in your code. Note that using a namespace makes the defrecord constructor fns (e.g. >MyRecord and map>MyRecord) available without a second step.

Please discuss ideas on the mailing list before using JIRA to make suggestions.

Cheers

Thanks for giving it a thought.

I think it is conceptually simple/consistent to say "if you use a namespace, then all the public symbols in that namespace is available without namespace qualification". It is unnecessary to remind people "Hey, record is an actually a Java class so the rules do not apply". I think it is the right choice for Clojure to integrate closely with the host language, but it is not the objective to expose the host details when not needed. If you say "this is a compromise due to some implementation consideration", then I can understand. But I disagree with the rationale you mentioned.

Linux, OpenJDK 1.6.0 64bit

If you add (:refer-clojure :exclude [load]) to the (ns), it works fine:

(ns ca.ancilla.kessler.core (:refer-clojure :exclude [load]) (:gen-class))
(defn load [x] x)
(defn -main [& args] 0)

Thanks to llasram on IRC for discovering this.

You should not replace functions in clojure.core. This is left legal (with a loud CONSOLE warning) for compatibility, but programs that do it are in error.

So, just to make sure that I have this right, then...

If I want to create a namespace with a public function that shares a name with a function in clojure.core, the only supported way of doing this is to (:refer-clojure :exclude [list of all such functions])?

If so, it would be nice if the warning were replaced with an error, rather than having the compiler emit an error and then crash.

All

Thanks for the patch, Dave. It is Rich Hickey's policy only to include code in Clojure written by those who have signed a Contributor Agreement (CA). See here for more details: http://clojure.org/contributing Have you signed one, or were considering it?

Can someone find some documentation or spec somewhere that defines this \x.. format?

It is definitely different than the \x{...} syntax that exists in Perl, which permits one to insert an arbitrary Unicode character code point into a string (note: even supplementary ones that don't fit into a single UTF-16 code unit, as Java's and Clojure's \u.... is restricted to). http://perldoc.perl.org/perlunicode.html#Effects-of-Character-Semantics

http://es5.github.com/x7.html#x7.8.4

I am happy to sign the CA in principle. Just need to read and understand any implications for me.

CA will be with you shortly.

Can this go into 1.5?

I'm hitting this now as well. But, adding support for JavaScript's flavour of \x.. escapes to the Clojure reader makes no sense to me. If escapes are to be used, then the \u.... format seems preferable (it supersets \x..).

However, all of the readers in play (Clojure reader, ClojureScript reader, edn) all play nice with Unicode, so there's no reason to be escaping anything except for \t, \n, and so on.

It looks like tweaking cljs' string implementations of IPrintWithWriter and IPrintable so that only those characters are escaped would be fairly easy. Right now, they're using goog.string.escape, which "encloses a string in double quotes and escapes characters so that the string is a valid JS string"; whatever escaping is appropriate for a "valid JavaScript string" seems irrelevant to what e.g. pr-str should produce.

I propose closing this ticket and moving the party to CLJS.

Following Chas's lead and closing this one. \x doesn't appear in the JSON spec, and a quick search of StackOverflow shows people stumbling over it from a bunch of other language platforms. I think we should root it out of ClojureScript.

Great, I'll open a CLJS ticket with a patch tonight or tomorrow.

Re: "no reason to be escaping anything except for \t, \n": sometimes it is difficult or impossible to transmit all of Unicode (e.g. sending non-Character codepoints through XDomainRequest, or sending U+0000/U+FFFE/U+FFFF through many XHR implementations), so it might be nice to have an ASCII-only printing mode. Probably for another ticket, though.

Here's the new ticket: http://dev.clojure.org/jira/browse/CLJS-400

@Ivan: I agree that options in this area would be good. There are a lot of edge cases where the defaults aren't right (e.g. I think escaping all nonprintables is a no-brainer for readably-printed strings).

I suspect planning out such details should probably happen [here](http://dev.clojure.org/pages/viewpage.action?pageId=4063586) or [here](https://github.com/edn-format/edn/issues).

First of all, clojure.lang.IFn is no protocol but an interface. And it does not declare a

  public Object invoke(Object... obs)

method. It has an `invoke` method with 20 Object parameters followed by an Object... parameter, but to give an implementation for that, you have to specify every parameter separately, and the last Object... arg is just a normal argument that must be an Object[]. That's because Java-varags Type... parameters are just Java syntax sugar, but in the byte-code its simply a Type-array.

What your example does is provide an `invoke` implementation for the 2-args version, where the first parameter happens to be named `&`, which has no special meaning here. Take that example:

(deftype MyFoo []
  clojure.lang.IFn
  (invoke [this & xs]
    [& xs]))

((MyFoo.) 1 2)
=> [1 2]

But you are right in that `deftype`, `defrecord`, `defprotocol`, and `definferface` probably should error if user's seem to try to use varargs or destructuring.

Cheers for a most clarifying response.

The fact that the meaning of & gets 'subverted' makes the issue only (slightly) worse, in my opinion.

Just for the record, destructuring seems to work, at least for interface impls.

> The fact that the meaning of & gets 'subverted' makes the issue only (slightly) worse, in my opinion.

I agree. I'll attach a patch which checks for those invalid usages soon.

> Just for the record, destructuring seems to work, at least for interface impls.

Could you please provide a complete example demonstrating your statement?

I'm rather sure that varargs and destructuring don't work for any of defprotocol, definterface, deftype, defrecord, and reify. But you can use varargs and destructuring when providing dynamic implementations via `extend` (or `extend-protocol`, `extend-type`), because those impls are real functions in contrast to methods.

I attached a patch. Here's the commit message:

Check for invalid varags/destrucuring uses.

Protocol, interface method declarations and implementations don't allow for
varags and destructuring support. Currently, for example

(defprotocol FooBar
(foo [this & more]))

compiles just fine, and & is interpreted as a usual argument that happens to be
named & without special meaning. But clearly, the user wanted to specify a
varags parameter here. The same applies to definterface.

Similarly, providing method implementations via defrecord, deftype, and reify
don't allow for destructuring and varags (but dynamic extenions via extend do).

So this patch makes defprotocol, definterface, defrecord, deftype, and reify
throw an IllegalArgumentException if any argument vector contains a
destructuring form or varargs argument.

Glad you've considered my request.

As for destructuring, I was speaking after this example, which may or may not work like it looks like - I don't know.

(deftype foo []
clojure.lang.IFn
(invoke [this [a b] c] (println a b c)))

((foo.) [1 2] 3)

Indeed, descructuring seems to work for method implementations. I'll adapt my patch...

Revamped patch. Here's the commit message:

Protocol, interface method declarations don't allow for varags and
destructuring support. Currently, for example

  (defprotocol FooBar
    (foo [this & more]))

compiles just fine, and & is interpreted as a usual argument that happens to be
named & without special meaning. But clearly, the user wanted to specify a
varags parameter here. The same applies to definterface.

Similarly, providing method implementations via defrecord, deftype, and reify
don't allow for varags (but dynamic extenions via extend do).

So this patch makes defprotocol and definterface throw an
IllegalArgumentException if a user tries to use varargs and destructuring in
method signatures.

Similarly, defrecord, deftype, and reify throw an IllegalArgumentException if
any method implementation arglist contains a varargs argument.

Tassilo, with your patch 0001-CLJ-1024-Check-for-invalid-varags-destrucuring-uses.patch dated July 12, 2012, I get the following error message while testing, apparently because some metadata is missing on the new functions your patch adds to core:

[java] Testing clojure.test-clojure.metadata
[java]
[java] FAIL in (public-vars-with-docstrings-have-added) (metadata.clj:45)
[java] expected: (= [] (remove (comp :added meta) public-vars-with-docstrin
gs-not-generated))
[java] actual: (not (= [] (#'clojure.core/throw-on-varargs-and-destr #'cl
ojure.core/throw-on-varargs)))

Hi Andy, this updated patch declares the two new checking fns private which makes the tests pass again.

Stupid mistake by me: Of course, I've tested the last version, too, but afterwards I decided it wouldn't be bad to add some docstrings, and of course, adding docstrings cannot break anything.

Patch applies cleanly against 4004d267e124f12b65b0d7fb6522f32a75e3c4fb. Submitter confirmed as a CA signer.

This looks ok to me, but it seems like a fair amount of duplication to accomplish the task. It seems like we should just be able to ask if it is ok to proceed, instead of having to pick which function needs to be called in what case.

Aaron, can you please elaborate? I don't get what you mean with duplication and asking if it is ok to proceed.

Rebased to apply cleanly on master again.

Pardon the silly contribution, but the added methods' usage of double-negations (when-not ...) seems unnecessary.

Hi Victor, this revamped patch removes the double-negation and is more concise and clearer as a result. So your comment wasn't as silly as you thought.

Hey Stu, do you mind to explain why you've declined the patch?

@Tassilo: https://groups.google.com/forum/#!topic/clojure-dev/qjkW-cv8nog

@Marek, Stu: Thanks, I've left a reply there: https://groups.google.com/d/msg/clojure-dev/qjkW-cv8nog/rMNFqbjNj-EJ

I looked at this. The problem is that non-tail try blocks turn into closures, and thus the field gets propagated as a constant. IOW this can't work:

(deftype Foo4 [^:unsynchronized-mutable x]
  MutableX
  (set-x [this v]
    ((fn [] (set! x v)))
    v))

I'm not going to re-evaluate the try/closure approach right now, so I recommend you make a helper method that just does the assignment and then call that in the bigger context, as a workaround.

Closing this as it requires more than a simple bug fix. If you feel that Rich's work-around is unsatisfactory please create a clojure-dev discussion about rewriting try-catch.

Ubuntu 10.10 Maverick
Java 1.6.0_20m OpenJDK (IcedTea6 1.9.13)

What command did you use?

From the error message, my guess is that you ran "ant" without first running "./antsetup.sh". If that is the case, run "./antsetup.sh" first. This is a new step added to readme.txt on May 7, 2012, because of the jsr166y.ForkJoinPool class used within Clojure to implement the new parallel reducers feature.

Yep, that's exactly it. Can we setup ant to warn people if antsetup.sh hasn't been run?

I don't know. I suspect if it could be done and it were a straightforward modification, a patch for that would be accepted. I suspect those who created antsetup.sh would have simply modified the build.xml file for ant, and not created antsetup.sh at all, if it were easy to do so.

It can be done with just the build.xml but requires the Maven Ant Tasks jar to be in the local ant's classpath, which is not ideal.

Because a local maven install is anyway required by antsetup.sh, IMHO it would be best to remove the ant build all together and stick with solely with a maven build, no?

I can't find the email right now, but I believe in the past Rich Hickey has expressed a preference for continuing to have a way to build Clojure using ant.

Ant is there for the convenience of various dinosaurs, myself included. In general you should use the maven build, as that is what the CI and release process do.

Linux 3.2.0-24-generic #39-Ubuntu SMP i686 GNU/Linux

I can reproduce the bug when using BigDecimal constructor on String.
See attached file for a test class.

More infos :
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.1) (6b24-1.11.1-4ubuntu3)
OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)

A simple test file, that you can drop in Clojure sources and execute to reproduce the bug on BigDecimal constructor using String as argument.

Seems to be a general precision problem. Note that in

user> (quot 1.4411518807585587E17 2) ;; correct with doubles
7.2057594037927936E16
user> (quot 1.4411518807585587E+17M 2) ;; wrong with BigDecs
72057594037927935M

the double result is actually wrong and the bigdec one is correct. The problem which lead to the wrong conclusion is that in your calculation the input number is already wrong.

So the moral is: don't use any floating points (neither doubles nor bigdecs) for computations involving divisibility tests.

For bigdecs, you can set the math context for making computations throw exceptions if they lose precision, though:

user> (binding [*math-context* (java.math.MathContext. 1 java.math.RoundingMode/UNNECESSARY)]
	       (quot (bigdec (Math/pow 2 58)) 2))
;Division impossible
;  [Thrown class java.lang.ArithmeticException]

Not a bug. Just floating-point arithmetic.

Is this bug a fairly well-constructed joke? I guess so.

But this is what I think happens: You change the value of #'assoc to the function returned by apply-foo. The alter-var-root call executes (apply-foo assoc) because assoc is the current value of #'assoc, thus the new value of #'assoc is {{(fn [& args] (foo (apply assoc args)))}}. However, fn is a macro that expands to fn* and calls destructure which uses assoc!!! So now foo gets called, and probably there's another assoc call during protocol dispatch, and there you have your non-terminating recursion.

So the lesson is: Don't alter core functions unless you're exactly knowing what you do.

Not a bug. You can't alter core functions and expect things not to break.

Actually, on further reflection, I was too hasty in opening this. first combined with seq or rseq is good enough. If I could close this I would, but I don't see a way to do so.

Closing this since submitter wishes it to be.

Any

I would prefer to see this, and other interop/reflective items, in a separate contrib lib.

Thanks for the feedback, Stu. Is there an existing contrib lib for stuff like this? Or should I create one?

At least Linux + IBM JDK 1.5, and Linux + IBM JDK 1.6

clj-886-improved-fix-for-ibm-jdks-patch2.txt dated Apr 7 2012 makes the tests pass with Linux + IBM JDK 1.5, as well as these other combos tested:

Linux + Oracle JDK 1.7
Linux + IBM JDK 1.5
Mac OS X 10.6.8 + Oracle/Apple JDK 1.6

There are still failing tests for Linux + IBM JDK 1.6. This patch currently skips the failing tests whenever the java.vendor is "IBM Corporation" and java.version is "1.6.0", so that "ant" succeeds. It is easy enough to modify the patch so that the failing tests are kept as a bright shining reminder. Let me know if that would be preferred – it just involves removing the function ibm-jdk16, and simplifying where it is called after replacing it with false.

Not sure if we should be in the business of building JDK-specific workarounds into our IO library, but marking this as screened.

Option B is to leave the code as-is and only disable the tests. Rich?

Please disable the tests. We shouldn't be doing such workarounds.

clj-967-disable-failing-io-copy-tests-on-ibm-jdk-16-patch1.txt dated May 19, 2012 disables tests of clojure.java.io/copy that fail with IBM JDK 1.6.0. It makes minor changes to the clojure.java.io code file, but these are only to eliminate uses of reflection, and to make a few of the versions of do-copy share more of their implementation code.

Tested that all results are good on Mac OS X 10.6.8 + Oracle/Apple JDK 1.6.0 and Ubuntu 11.10 + Oracle JDK 1.7.0, including that the number of tests run are identical to before this patch. Only 2 tests are disabled on IBM JDK 1.6.0, and all of the rest pass before and after these changes.

Hoping that I'm not out of line changing approval from Incomplete to None after attaching a patch that should address the reason it was marked incomplete. The only other way to get a ticket out of Incomplete state is for a core team member to do it for me, which seems like busy-work.

Any comments from Rich or other screeners on the status of this one? Just curious, since it seemed to have been screened, and then quietly tossed back into the unscreened pile. Is it considered undesirable to disable selected tests for a particular JDK as the patch clj-967-disable-failing-io-copy-tests-on-ibm-jdk-16-patch1.txt does? My motivation was to selectively disable only the tests that fail, and only on the JDK where they fail, leaving all passing tests to continue to run wherever possible.

$ java -version
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-11M3527)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)

Hi,

I've create this small sample project to exemplify the bug ocurring: https://github.com/danielribeiro/ClojureBugReport

Cheers,

• Daniel

Note that the name load is not special: it works with any abstract method, no matter the name.

Not a bug: I was declaring the method load, which was already defined on the abstract class. The docs do mention this:

http://clojuredocs.org/clojure_core/clojure.core/gen-class

Closed as not-a-bug.

This is actually an enhancement. The Var.java and Namespace.java code does not attempt to read the metadata on the var. Instead, the compiler handles this at compile time. If you would like to see this behavior changed, feel free to bring it up on clojure-dev, and we'll discuss it.

Closing until that time.

This is no defect. Function literals must have a function (or macro or special form) as first symbol.
So your examples should be written like so:

user> (#(do true))
true
user> (#(do))
nil
user> (some #(do %) [nil false 0 1])
0

It makes sense. However (and correct me if I'm wrong) there should be little problem in making them fully equivalent to fns, resulting in a more concise and consistent API.

Please consider re-opening the issue as a feature request.

Regards - Víctor.

The reader docs at http://www.clojure.org/reader say that #() is not a replacement for (fn [] ...). You can't make it more equivalent to fn without making it much harder to understand. Let me explain that with an example.

(defn get-time []
  (System/currentTimeMillis))

(#(get-time)) ;; What's the result?

What's the result of the funcall above? Clearly, right now, it is the current system time.

So if we decided to allow to write #(true) as an alternative to (constantly true) [which is a varargs fn] or #(do true) [which is a fn of zero args], then valid values of #(get-time) where both the current system time but also the function object for get-time. Functions are values, too.

Ok, one could say that in the case of a function, #(function) is always a call, but it would make it harder to reason about what the code does for not much benefit.

You're right - satisfying my request would require to change the average use of this feature to #((some_fn %1 %2)) rather than just #(some_fn %1 %2), if we wanted #(true) to be valid. Which indeed would be barely handy.

Thank you.

all

Isn't this a Java bug?

If using UTF-16 to encode Unicode strings, and making every UTF-16 code unit (i.e. Java char) individually indexable as a separate entity in strings, is such a bad design choice that you consider it a bug, then yes, this is a Java bug (and a bug in all the other systems that use UTF-16 in this way).

clojure.string/capitalize isn't using some Java capitalization method that has a bug, though. By calling (.toUpperCase (subs s 0 1)) it is not giving enough information to .toUpperCase for any implementation, Java or otherwise, to do the job correctly. It is analogous to calling toupper on the least significant 4 bits of the ASCII encoding of a letter and expecting it to return the correct answer.

Not quite sure how to create a repeatable test for this since the issue depends on the local timezone.

java.util.TimeZone/setDefault could be used for testing in various timezones.

Regarding the patch: SimpleDateFormat is a relatively heavy-weight object, so it seems bad to allocate one every time you print a Date. Unfortunately, SimpleDateFormat is not thread-safe, so you can't just share one. The Java world seems to agree that you should use JodaTime instead, but if you're stuck with the JDK, you need to have a ThreadLocal SimpleDateFormat. I'm working on my own patch along those lines.

Excellent analysis. I'll keep track of this case and vet any patches that come along. Please do attach a regression test if possible.

I attached a new patch using a SimpleDateFormat per thread using a thread local. I'll try to add some tests next.

A combined patch that uses a thread local SimpleDateFormat, tests round-tripping at a known daylight savings point (by overriding the default timezone) and checks round tripping at multiple points throughout the year (every hour of the first 4 weeks of every month of the year).

Steve, thanks for the suggestions on using a thread local and TimeZone/setDefault.

I filed CLJ-928 with my patch for fixing the printing of Date and Timestamp using UTC. I copied the tests from the CLJ-926 patch to make sure we're compatible.

Thanks for the regression test also. I'll vett this patch ASAP.

Seems reasonable to me.

Vetted. Will apply later.

Not Vetted. Test. That thing.

No, it's "Screened," not "Test." Somebody save me.

Superseded by CLJ-928.

OS X, java 1.6.0_29

This is no bug, but you use assoc! wrongly. Just like with assoc, you need to use the return value of the call instead of "bashing the transient map in place". I.e., in your code, replace the doto with ->, which threads the result of each assoc! call to the next one, returning the last value.

BTW: This came up on the list the last days, too. See:

https://groups.google.com/d/msg/clojure/rmLLnRx5p3U/10GYNQdTVksJ

This is no bug but a usage error.

linux

It seems this is not an error in Clojure but an error in the native implementation of FileInputStream.available(). For example, this Java code throws the same exception.

    FileInputStream fis = new FileInputStream("/home/horn/dead.letter");
    System.out.println(fis.available());  // Works fine

    fis = new FileInputStream("/proc/cpuinfo");
    System.out.println(fis.available());  // IOException is thrown

Tested with sun-jdk 1.6.0.29 and IcedTea 7.2.0.

This is not a fix, but a workaround for this issue with the JVM: call slurp on a reader that you force to be constructed as unbuffered. For example:

(slurp (java.io.InputStreamReader. (java.io.FileInputStream. "/proc/cpuinfo")))

(tested with Sun/Oracle JDK 1.7.0_02)

This is less efficient for large files, so I wouldn't recommend that the slurp code be modified to work this way for all files.

One can imagine an implementation of Clojure slurp and clojure.java.io/reader that first tried the slurp call with buffered I/O, and if an exception like this one occurs fall back to unbuffered I/O. However, that sounds like it would get very hairy very quickly, and would be difficult to write it in such a way that it did not mask I/O errors that should be visible to the caller. Also that seems like unwanted complexity in Clojure to work around what is likely a bug in the JVM. Someone (Tassilo?) filed a bug with Oracle about this exception:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132461

I contacted Romain, the submitter, and they agreed that trying to work around this JVM bug in Clojure's slurp might be a bit excessive, and that closing the ticket was reasonable.

I have added a note about Romain's workaround at http://clojuredocs.org/clojure_core/1.3.0/clojure.core/slurp in hopes that others will be able to find it more easily.

Dmitri: CLJ-896 has a patch that changes browse-url to use the command line tool xdg-open instead of Java Swing. If the command:

xdg-open http://localhost:3000

works on your system from the command line, then that patch will probably also make (browse-url "http://localhost:3000") work, too.

I tried (browse-url "http://localhost:3000") on an Ubuntu 10.04 LTS system using Sun/Oracle's JVM 1.6.0_26, and it worked. Which JVM are you using?

I tried it again and now I can't reproduce it - browse-url works as expected and Swing gui also works when launched manually. I use openjdk, so maybe it was a problem with its classes? Anyway, the issue should be closed.
Sorry for bothering you.

I'm not sure if this should be marked with a Resolution of Declined or Completed, if the issue cannot be reproduced. I'm picking Declined for this change. Feel free to change it if I've picked incorrectly.

Yeah, I also think Declined is correct.

I doubt there's any desire to change this. Records only support typehints to enable performant storage of primitive types like ints, not to provide static typing in general. An Object is stored the same way as a String, so there's no need to pay attention to that typehint.

Functions behave the same way: ((fn [^String x] x) :test) works just fine. Only if you use a member method of the hinted type (such as .substring in this example) is an exception thrown then the compiler casts to String in order to call the method.

I don't understand how you get from "this is how it is" to "this is how it is meant to be." The compiler can do a better job if the underlying field is properly typed: Type errors can be caught sooner, and cast operations can be omitted on use. This is a worthy enhancement.

Alan is correct, the reason type hints exist is to reduce reflection and to allow for the unboxing of primitives. String is not a primitive and therefore type-hinting it only reduces the amount of reflection performed.

It has always been Rich's policy that any type systems used in Clojure should not throw compile time errors, but instead should only enhance the performance of existing code. (see the implementation of Typed Clojure for more info on this).

Closing this issue, as it is by design.

By design.

The thing to remember here is that protocol functions are not (only) methods on a class, they are functions global to the namespace. So notice the subtle difference here:

user=> (defprotocol Foo (act [this]))
Foo
user=> (defrecord Fred [act] Foo (act [this] (act this)))
user.Fred
user=> (Fred. 42)
#user.Fred{:act 42}
user=> (act (Fred. 42))
ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn user.Fred (NO_SOURCE_FILE:1)

user=> (defrecord Fred [act] Foo (act [this] (user/act this)))
user.Fred
user=> (act (Fred. 42))
StackOverflowError user.Fred (NO_SOURCE_FILE:1)

So, it you want to access the data, you can use "act" directly, if you want to recursively call act (the protocol function), you can use recur, or the fully qualified name. Also, since these are records we're talking about, the following also works:

user=> (defrecord Fred [act] Foo (act [this] (:act this)))
user.Fred
user=> (act (Fred. 42))
42

Declined since this is not really a bug. There is a work-around and no obvious solution to the more general problem of defrecord name collisions. If this still bugs you, please feel free to bring it up on clojure-dev, and we'll open a new ticket once a discussion has been had.

Daniel, I'm pretty sure it is intended to be a map, not a set. The goal is to show the same documentation for try whether you ask for the documentation of try, catch, or finally. Also, to show the documentation for fn if you ask for the documentation of &, since that symbol is only useful in arg lists in fn (or let). They could have put multiple entries in special-doc-map and not had that little map inside doc, but that little map avoided the need for such duplication.

100% agree. It was an incorrect report on my part. Thanks for clearing it up.

Daniel asked me to change the state of the ticket, since he could not see how to (perhaps insufficient privileges). Not sure if it should be marked Closed or Resolved, so I'm picking Resolved.

Link to initial discussion on Clojure Dev Google Group

http://groups.google.com/group/clojure-dev/browse_frm/thread/bdab332c4e47721f?hl=en

Link to experimental implementation on GitHub:

https://github.com/mikera/clojure/tree/better-reduce

Performance testing shows approx 2x speedup for relevant operations:

Clojure 1.3.0
(def ms (zipmap (range 100) (range 100)))
#'user/ms
user=> (dotimes [i 10] (time (dotimes [i 100000] (reduce (fn [acc [k
v]] (+ acc v)) 0 ms))))
"Elapsed time: 646.512414 msecs"
"Elapsed time: 553.264593 msecs"
"Elapsed time: 544.999672 msecs"
"Elapsed time: 510.606868 msecs"
"Elapsed time: 513.192451 msecs"
"Elapsed time: 537.665664 msecs"
"Elapsed time: 524.166514 msecs"
"Elapsed time: 512.966964 msecs"
"Elapsed time: 501.677219 msecs"
"Elapsed time: 496.379194 msecs"

Clojure 1.4.0-alpha2
user=> (def ms (zipmap (range 100) (range 100)))
#'user/ms
user=> (dotimes [i 10] (time (dotimes [i 100000] (reduce (fn [acc [k
v]] (+ acc v)) 0 ms))))
"Elapsed time: 548.822683 msecs"
"Elapsed time: 469.275299 msecs"
"Elapsed time: 464.742096 msecs"
"Elapsed time: 443.500129 msecs"
"Elapsed time: 431.272138 msecs"
"Elapsed time: 430.514649 msecs"
"Elapsed time: 432.753752 msecs"
"Elapsed time: 431.195876 msecs"
"Elapsed time: 435.254274 msecs"
"Elapsed time: 433.516375 msecs"

Clojure 1.4.0 snapshot (with better reduce modifications)
(def ms (zipmap (range 100) (range 100)))
#'user/ms
user=> (dotimes [i 10] (time (dotimes [i 100000] (reduce (fn [acc [k
v]] (+ acc v)) 0 ms))))
"Elapsed time: 202.29696 msecs"
"Elapsed time: 186.589505 msecs"
"Elapsed time: 179.691805 msecs"
"Elapsed time: 184.191644 msecs"
"Elapsed time: 183.265131 msecs"
"Elapsed time: 180.162578 msecs"
"Elapsed time: 182.323219 msecs"
"Elapsed time: 181.810649 msecs"
"Elapsed time: 182.896285 msecs"
"Elapsed time: 187.30153 msecs"

better_reduce branch now updated to merge in the latest changes from the clojure/clojure master branch.

Reviewers:

To make this change easier to review (and for a cleaner history), I mashed all of the commits that make up this change together and rebased that onto the latest from clojure/clojure master.

https://github.com/netguy204/clojure/tree/better-reduce
https://github.com/netguy204/clojure/commit/b262a69c32d26bb6f3c5ba711310361d77609a22

Hope it helps.

Awesome, thanks Brian! I must admit that my git-fu is not yet good enough to do things like this, so your help is much appreciated!

clj-894-better-reduce-performance-patch1.txt was created from pulling Brian Taylor's Clojure github repo, creating a diff of it, applying it to latest master as of Feb 22, 2012, and making a properly formatted patch from it. It has only a single commit, and has Mike Anderson's name and email address in it, along with a date of 4 Dec 2011, when it appears he made his final commit of this work. It compiles and tests cleanly, and I have run Mike's timing experiments and seen similar speed improvements.

No docstrings need changing that I can think of. Mike and I have both signed CAs. I don't see Brian Taylor's name on the list of those who signed a CA, but as long as the patch contains only code that Mike wrote, it should be clean. Patch status is "Code and Test".

Correcting Mike's name and email address in patch.

The patch contains only code that Mike wrote.

Thanks guys I've reviewed the patch and can confirm that it looks like exactly the changes I intended to make. I am happy for them to be committed as per my signed CA.

Similar objective now achieved via a protocol:
https://github.com/clojure/clojure/commit/1f90942690d5395330347cb31fdb3d69cea1ec56

java 6 jdk on linux, jre 6 on windows 7

There is actually no problem with head retention in your code.
It's zust the garbage collector that doesn't collect the seq right away. If there were problems, then you would get a OutOfMemoryError pretty fast.

compare
(split-file "foo" (repeat 100000000 "blah blah blah") 100000000 0)
with
(doall (repeat 100000000 "blah blah blah"))
to see the difference

Closing due to lack of reproducible tests. On my system I actually saw memory usage not move at all when I ran the demo code, and at one point the GC kicked in and the memory usage went down a bit.

OSX Lion

This is not a bug. Check the doc – contains? refers to the keys of the collection, not the values. For a vector, the "keys" are the indices.

user=> (map #(contains? [10 20 30 40] %) (range 4))
(true true true true)

This is a (common) misusing of contains?. Perhaps it would have been better if contains? had been named contains-key?, but that ship has sailed.

Usage: (contains? coll key)

Returns true if key is present in the given collection, otherwise returns false. Note that for numerically indexed collections like vectors and Java arrays, this tests if the numeric key is within the range of indexes. 'contains?' operates constant or logarithmic time; it will not perform a linear search for a value. See also 'some'.

A vector of length 4 has four keys (indexes): 0, 1, 2, 3, which is why your example is returning (true true true false).

To get the behavior your are expecting from contains?, use some:

Usage: (some pred coll)

Returns the first logical true value of (pred x) for any x in coll, else nil. One common idiom is to use a set as pred, for example this will return :fred if :fred is in the sequence, otherwise nil: (some #{:fred} coll)

user> (map #(some #{%} [1 2 3 4]) [1 2 3 4])
(1 2 3 4) ; all of which are truthy

If you prefer booleans, you could do something like this:

user> (map (comp boolean #(some #{%} [1 2 3 4])) [1 2 3 4])
(true true true true)

The powers that be acknowledge that this is Java's fault: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6312706

This is not a bug

CLJ-851-test.patch

Provides a test to reproduce this issue, as well as a test that shows that the workaround of using ^"[J" as type hint works correctly.

OK, I see the problem here: longs plays two roles in Clojure:

1. As an unqualified symbol, it's taken to mean long[].class.
2. clojure.core/longs is a definline function which calls clojure.lang.Numbers.longs(...).

The example in the issue description is expecting the first interpretation, but what we're actually getting is the second interpretation, i.e. the :tag is not a symbol longs, but rather a function (an instance of the class clojure.core$longs, to be precise).

So, it's as if we'd written this:

(def ^{:tag clojure.core/longs} la (long-array 0))

When really, we meant this:

(def ^{:tag 'longs} la (long-array 0))

While the behavior described by this issue is confusing, it looks to me like it's not a bug.

Correct, this is not a bug. The reader will attempt to resolve symbols in the ^tag metadata form, so that it can resolve unqualified class names.

Clojure 1.3, Emacs 23, OSX Lion

Apologies, I meant to tag this as a minor issue instead of a major one!

Since vectors are associative, maybe using vectors for :or should just work?

(let [{noun 0
       verb 1
       obj 2
       :or [:n :v :o]}
      [:code :is]] obj)

Closing this until someone wants to make a principled argument for what should happen (see my previous comment)

This is actually a policy of maven.org/sonatype: https://issues.sonatype.org/browse/MVNCENTRAL-119 , not Clojure.

Attached patch for adding the methods.

I intentionally left out the {:added "_"} from the vars since I have no idea when this will be added.

This (as expected) causes this test to fail:
[java] FAIL in (public-vars-with-docstrings-have-added) (metadata.clj:42)
[java] expected: (= [] (remove (comp :added meta) public-vars-with-docstrings))
[java] actual: (not (= [] (#'clojure.string/butlast #'clojure.string/drop #'clojure.string/take)))

Which is easily remedied. If desired, let me know what version this will be added to and I'll submit a new patch with the :added metadata included.

I have attached a patch with "1.4" as the added version now that 1.3 has been released.

The algorithms, docs, and tests look good. I think the functions would be better if they used clojure.core/subs like the rest of clojure.string does, instead of .substring. This is more idiomatic Clojure and allows you to avoid hinting the String arg.

When a new patch is uploaded, please remember to set the Patch field of this ticket to "Code and Test" and the Approval field to "Test". Hopefully this will lead to faster screening.

Attached a patch that uses subs instead of .substring (clj-826-add-take-drop-butlast-v3.diff).

These fns were left out intentionally. Feel free to propose a contrib home for them, though.

Gentoo GNU/Linux

Related documentation here: http://dev.clojure.org/display/doc/Enhanced+Primitive+Support

all long-or-smaller integers are boxed as Long
You can't use primitive coercions to force specific box types
Your code was broken if you were relying on that

So, apparently (int) has the correct behavior. It's byte and short which should be also boxed into Longs

See also this topic in clojure-dev: https://groups.google.com/d/topic/clojure-dev/fXQAYv8s0tQ/discussion

So to call some Java method that requires an int you have to use Integer/valueOf?

Yes, I think so

But for what are the coercion functions now good for? I mean, http://clojure.org/java_interop#Java Interop-Coercions states:

"At times it is necessary to have a value of a particular primitive type. These coercion functions yield a value of the indicated type as long as such a coercion is possible: bigdec bigint boolean byte char double float int long num short"

That's exactly my use case which is not supported anymore.

(int) (char) etc. are not intended to return boxed types, they always return primitive types. If you want boxed types you can use (num). When you do (class (int 42)) you are casting the long 42 to a int and then boxing it into a Long to get its class.

For short and byte, I don't know, I think there is a bug, (class (short 42)) should be Short.

(int) (char) etc. are not intended to return boxed types, they always return primitive types.

Thank you, Sebastián, that made it clear and unveiled the problem at my side. When I did

(set-value! foo :position (int 17))

I got the exception "java.lang.Long cannot be cast to java.lang.Integer". set-value! is a protocol function extended on the java types of the java library I'm interacting with. Eventually, it'll call (doto foo (.setAttribute "position" (mutable <providedVal>)), where mutable is yet another protocol function that converts clojure collections to the libraries counterparts and does nothing for primitive types.

Now, although (int 17) returns an unboxed int, these two indirections box it into a Long again and the java setter is called with that leading to the error.

(set-value! foo :position (Integer/intValue 17))

circumvents the issue, because here you directly get an int boxed as Integer.

If you want boxed types you can use (num).

Well, I want a boxed value of a certain type, like Integer.

For short and byte, I don't know, I think there is a bug, (class (short 42)) should be Short.

Should or should not? Currently, for all primitive types <primType>, the call (class (<primType> <val>)) returns the wrapper class corresponding to <primType> with the exception of int where you get a Long instead of an Integer. That's totally surprising and caused me to file this bug report.

This is fixed in 1.4.0 – could one of the screeners confirm this, and maybe close the issue?

I'll pick this up on Friday if no one else has by then.

deftype print-method and print-dup pulled per CLJ-812; this is no longer relevant.

There are earlier uses of &form and &env in core.clj, but they are all in bootstrap code and none of them become visible in doc strings. There are no other occurrences of & in resolve or ns-resolve, so it seems reasonable to remove it from resolve's doc string.

Patch applies cleanly to latest master as of Feb 24, 2012.

The only way to access local environments in Clojure is with the special &env argument in a macro, so the use of &env in the ns-resolve docstring makes sense.

Declined.

All

Although this seems useful, we are not ready to commit to supporting it.

Linux, openjdk 6