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.

In Clojure, it is generally the case that redefining something replaces the original, as opposed to augmenting it by merging the old and the new. This makes it easy to reason locally about how code works. One could argue that the following snippet has the same kind of issue you describe:

(defn foo [a] 1)
(defn foo [a b] 1)
(foo 1) ; is it a bug that the first arity is gone?

I also wonder whether the current behavior might be a convenience for some macros. (Clearly it wasn't for yours!) I am changing the type and title of the ticket to better reflect the nature of the request and see what the BDFL says.

Everything in this ticket needs to be said with more precision. I don't know what exactly the problem is nor what the proposed solution is.

One thing to note is that it is necessary to accept definitions under base interfaces, so the class areas are not strict, nor expected to be complete.

Stuart: The two foo forms you give are entirely separate, and to unify the two behaviors you would have to group them together. It's not at all unreasonable to suppose the user wants to define foo once, fiddle with it, and then redefine it - clojure.core does similar stuff with let, reduce, etc.

As written, deftype/reify have a somewhat similar "look" - because there is nothing physically grouping the declaration of Map with its functions, it's not clear what should happen when a heading like Map is given twice, and it's not specified in the docs.

I think the difference is that in the reify case, the two are in the same top-level form, so the compiler can detect that you're trying to do something "weird", so a silent redefinition (reasonable for your defn example) is surprising. There are a number of solutions that would reduce this surprise:

1) Permit or require reify to group things, as in (reify (Comparable (compare [this other] 1))). Then the explicit grouping of Comparable with its methods serves two purposes: it implies that other definitions for Comparable should be included in that grouping; and it makes it easier to do that, because you can just iterate over forms until you find Comparable, and then insert another definition.

2) Throw an exception if an interface is specified twice. This is not ideal because it can be a lot of work for the user to group things together themselves, while it's easy for deftype to do given the grouping it's already doing. However, it would avoid the confusion and surprise, by saying "that's not allowed" rather than leaving the user guessing what's gone wrong.

3) Interpret my original example code as an attempt to open the Map interface, add implementations, and then later add some more implementations.

I would have liked reify to implement (1) to begin with, but at this point I don't think the syntax is backwards-compatible, so it doesn't seem like a good idea. I suppose either (2) or (3) is fine, and they both seem like an improvement over the current confusing behavior. Of course, I prefer (3), but I can understand a desire to make reify reject syntax that is not immediately obvious in intent rather than interpreting it as what I think is the most useful intent.

Duplicate of CLJ-931. (Well, basically the other way round, but CLJ-931 has a fix attached, so I close this one.)

We don't want to mess with the semantics of division at the bottom.

Requires that patch on CLJ-782 be applied first.

Applies on master as of commit 66a88de9408e93cf2b0d73382e662624a54c6c86

still considering when to incorporate this

v2 of the patch applies to master as of commit eccde24c7fb63679f00c64b3c70c03956f0ce2c3

Patch clj-771-move-unchecked-casts-patch-v3.txt dated Sep 6 2012 is the same as Alexander Taggart's patch move-unchecked-casts.patch except that it has been updated to apply cleanly to latest Clojure master.

Patch clj-771-move-unchecked-casts-patch-v4.txt dated Oct 20 2012 is the same as Alexander Taggart's patch move-unchecked-casts.patch except that it has been updated to apply cleanly to latest Clojure master.

The patch clj-771-move-unchecked-casts-patch-v4.txt applies cleanly to latest master and passes all tests. Rich marked this ticket as Incomplete on Dec 9 2011 with the comment "still considering when to incorporate this" above. Is it reasonable to change it back to Vetted or Screened so it can be considered again, perhaps after Release 1.5 is made?

Patch clj-771-move-unchecked-casts-patch-v5.txt dated Feb 12 2013 is the same as Alexander Taggart's patch move-unchecked-casts.patch except that it has been updated to apply cleanly to latest Clojure master.

33.927 hiredman ,(binding [*print-dup* true] (pr-str (first {:a 1})))
33.928 clojurebot "#=(clojure.lang.MapEntry/create [:a 1])"
33.938 hiredman yeah, well, I was busy
33.941 chouser heh
33.949 hiredman ,(clojure.lang.MapEntry/create [:a 1])

Patch that throws IllegalArgumentException would be ok for this.

After a brief review of places that call intern, it appears that this problem might never be reached in the reader, only in user code calling (keyword ...). Does it make more sense to have the patch there, and a matching change for (symbol ...)?

Please don't test for specific exception types - thanks

keys-vals-type-2.patch replaces previous. Tests check for Exception instead of IllegalArgumentException

The problem occurs in 1.2 but is fixed on master. Leaving in backlog in case we ever cut another 1.2 release--if not, then mark as fixed.

Converted from http://www.assembla.com/spaces/clojure/tickets/466

ataggart said: Simpler example of the problem.

ataggart said: Fixed via patch at ticket #445.

See #445

Converted from http://www.assembla.com/spaces/clojure/tickets/464

It has been run. Unfortunately, it has reports numerous spurious errors (i.e. non-problems), so will never be clean.

Converted from http://www.assembla.com/spaces/clojure/tickets/463
Attachments:
463-strip-keyword-colons.diff - https://www.assembla.com/spaces/clojure/documents/bKmJCu2_Wr36meeJe5cbLA/download/bKmJCu2_Wr36meeJe5cbLA

cemerick said: [file:bKmJCu2_Wr36meeJe5cbLA]

I am uncomfortable with this. If I say (keyword "::foo"), what am I asking for? I almost wonder if this should throw an exception.

I think (keyword "::foo") (and any more leading colons) should fail, and this patch should only strip one colon.

Updated patch forthcoming.

After thinking about this for a while, I've now reversed my position, and am in favor or retaining the current functionality. Thanks for the pushback.

As for throwing exceptions on colon-prefixed, un-namespaced keywords, I'm not certain that that's a good idea. People use keywords to hold all sorts of data, use them as map keys and lookup fns, etc.

Converted from http://www.assembla.com/spaces/clojure/tickets/461
Attachments:
mh-461-require.patch - https://www.assembla.com/spaces/clojure/documents/cQSfQ22L8r37zxeJe5cbCb/download/cQSfQ22L8r37zxeJe5cbCb

mikehinchey said: [file:cQSfQ22L8r37zxeJe5cbCb]: patch to fix #461

mikehinchey said: The discussion shows some people want this, other's aren't sure. Attached the patch so people can try it out.

One problem I see: With this change, it becomes harder for code-reading tools to determine all the dependencies of a namespace without evaluating it. Right now, I can parse the "ns" declaration of any file and know its dependencies. (Obviously, this breaks if the file loads code outside of the "ns" declaration, but then static analysis is virtually impossible.)

With this change, the "ns" declaration no longer represents the complete set of dependencies for the namespace. I can try to read the whole file, but I have no way of knowing if "foo.bar.baz/quux" represents a namespace-qualified symbol or a static Java member, unless I evaluate it.

I think loading Java classes and loading Clojure namespaces are fundamentally different operations because classes, unlike namespaces, cannot change after they are loaded.

Stuart,
On the first point: it is already hard for code-reading tools. One can (require 'something) outside of the ns form. There are also uses of eval, direct references to fully qualified classes, and other nefarious ways. You seem to have admitted this already, so I'm not quite sure what you are objecting to? Objection 1: OVERRULED.

On the second point: you already admitted above that the ns declaration doesn't represent the complete set of dependencies, so there is no "no longer" about it. It was just never the case. Secondly, "foo.bar.baz/quux" could be a static Java member, or a Clojure Var, but that is irrelevant to this patch. That was always the case, and the patch is about autoloading, not about interpreting to what "foo.bar.baz/quux" is referring. Objection 2: OVERRULED.

On the third point: again, I don't see the relevance of the fact that a namespace can be changed after it has been loaded but a class cannot. Again, the patch is about autoloading, and the immutability/mutability of namespaces vs. classes is orthogonal. Objection 3: OVERRULED.

Finally, the original ML thread that spawned this had a +1 from the following persons: myself, Christophe Grand, Phil Hagelberg, Laurent Petit, Steve Gilardi, Cosmin Stejerean, and Chas Emerick.

It had a -1 only from: you, Dimitry Gashinsky.

A negative comment from Stu Halloway, and a positive-ish comment from Chris Houser.

I say we move forward with this.

I have serious reservations about the complexity this will add to the compiler. the current patch is no good, it will break for aot compilation.

So I've been told that my tongue-in-cheek may not have translated well, but that was the intent. I apologize if that was the case.

My point is just to draw attention to this ticket again. It was discussed on the ML with several +1's and has been mentioned again in chat. I don't think any of the objections that Stuart Sierra raised are particularly relevant to the question of autoloading the namespace of a fully qualified var.

Has anyone tried the patch? Kevin Downey seems to think it will not work in the context of AOT.

Do we need a new patch?

the patch doesn't actually cause code to load the required namespaces to be generated. it only loads the required namespaces during compilation, which is why it breaks aot. once you get into code generation for aot it gets complicated, where does the generated code go? do we want to try and emit it separately like the requires from an ns form or does it get emitted in the middle of the particular function being compiled. I think the first approach is desirable from a stand point of correctness, but carries with it a load of complexity.

I think it gets emitted in the middle of a function, just like would happen now if you do (require 'clojure.set) (clojure.set/union ...)

Is there a benefit to having it emit separately like an ns form? Isn't the ns form just a macro that turns into calls to (require ...) which happen to be at the top of a file because that's where the ns form is?

This is not a good idea, for many reasons, the simplest of which is: it makes loading a side effect of calling a function in a module. Since loading can have arbitrary effects, it shouldn't be implicit. This isn't warranted by the meager benefits it might provide.

Converted from http://www.assembla.com/spaces/clojure/tickets/459

Converted from http://www.assembla.com/spaces/clojure/tickets/455

ataggart said: This is correct behavior with respect to 1.3.0 (yes, it's a breaking change).

If one wants to allow numbers larger than what fits in a long to flow out of math ops, one needs to explicitly start with a BigInt:

user=> (type 1N)
clojure.lang.BigInt
user=> (class (* 1000N 1000N 1000N 1000N 1000N 1000N 1000N))
clojure.lang.BigInt</code></pre>
If one wants to allow autopromotion, one can use the new "tick" math ops:
<pre><code>user=> (class (*' 1000 1000 1000 1000 1000 1000 1000))
clojure.lang.BigInt

NB: Rich suspects almost no one should need these ops, and if you think you do, you're probably wrong.

Converted from http://www.assembla.com/spaces/clojure/tickets/451

Converted from http://www.assembla.com/spaces/clojure/tickets/450

I independently wanted this. Here's a patch for: some, not-any?, every?, not-every?. If this is roughly what's wanted I'll be happy to add filter, remove, take-while, drop-while.

Note that there are a few cases of (every? identity ...) and (some identity ...) in core.clj itself; the patch removes "identity" from those.

clj-450-add-default-pred-arg-to-core-fns-patch.txt dated Apr 26 2012 is identical to Jason Orendorff's, except it is in git format. Jason is not on the list of Clojure contributors as of today. I have sent him an email asking if he has done so, or is planning to.

Of course I'd be happy to send in a contributor agreement. ...Is there actually any interest in taking this patch or something like it?

I don't know if there is any interest in taking this patch. Perhaps a Clojure screener will take a look at it and comment, but I am not a screener and can't promise anything.

Converted from http://www.assembla.com/spaces/clojure/tickets/449
Attachments:
fix-stacktrace2.diff - https://www.assembla.com/spaces/clojure/documents/c_8vnCZyyr37CfeJe5cbLA/download/c_8vnCZyyr37CfeJe5cbLA

stuart.sierra said: [file:c_8vnCZyyr37CfeJe5cbLA]: patch with ticket ref #

This may be moot given the work being done to unify all the different stacktraces, but as long as this code is still out there, it seems worth preventing occasional cryptic failures!

Converted from http://www.assembla.com/spaces/clojure/tickets/446
Attachments:
nbody.clj - https://www.assembla.com/spaces/clojure/documents/auzfxEY2Or35j2eJe5cbCb/download/auzfxEY2Or35j2eJe5cbCb

ataggart said: Fix available via #445.

Marking "Incomplete" because no patch is included.

Furthermore, I cannot reproduce the problem described using Clojure 1.3.0.

Converted from http://www.assembla.com/spaces/clojure/tickets/440

Patch adds support for varargs. Builds on top of patch in CLJ-445.

Patch updated to current CLJ-445 patch.

Is this ticket on hold? I find myself typing (.someCall arg1 arg2 (into-array SomeType nil)) alot just to get the right method to be called. This ticket sounds like it would address that extraneous into-array arg that I use alot.

fixbug445.diff uploaded on Oct 29 2012 was written Oct 23 2010 by Alexander Taggart. I am simply copying it from the old Assembla ticket tracking system to here to make it more easily accessible. Not surprisingy, it doesn't apply cleanly to latest master. I don't know how much effort it would be to update it, but only a few hunks do not apply cleanly according to 'patch'. See the "Updating stale patches" section on the JIRA workflow page here: http://dev.clojure.org/display/design/JIRA+workflow

Ugh. Deleted the attachment because it was for CLJ-445, or at least it was named that way. CLJ-445 definitely has a long comment history, so if one or more of its patches address this issue, then you can read the discussion there to see the history.

I don't know of any "on hold" status for tickets, except for one or two where Rich Hickey has explicitly said in a comment that he wants to wait a while before making the change. There are just tickets that contributors choose to work on and ones that screeners choose to screen.

Converted from http://www.assembla.com/spaces/clojure/tickets/438

A post-order traversal for macroexpand-all seems more reliable here than pre-order, and does fix the issue.

The attached patch adds tests around this and updates macroexpand-all to use postwalk rather than prewalk.

This has been fixed in the patch on CLJ-426.

The CaseExpr parser now just treats the map value as a tuple by calling RT.first/second, rather than casting it to a MapEntry.

Confirming Alex's fix - this ticket can just get closed, I think.

Converted from http://www.assembla.com/spaces/clojure/tickets/436

donmullen said: Added ticket on clojure-contrib-99

Converted from http://www.assembla.com/spaces/clojure/tickets/434

Converted from http://www.assembla.com/spaces/clojure/tickets/431
Attachments:
fix431-1.diff - https://www.assembla.com/spaces/clojure/documents/a04XQYZzKr36OdeJe5cbCb/download/a04XQYZzKr36OdeJe5cbCb

stuart.sierra said: [file:a04XQYZzKr36OdeJe5cbCb]: fix

Converted from http://www.assembla.com/spaces/clojure/tickets/424
Attachments:
instance-test.tar.gz - https://www.assembla.com/spaces/clojure/documents/dZGCvGPH4r37YjeJe5cbCb/download/dZGCvGPH4r37YjeJe5cbCb

hugoduncan said: Removing :reload-all from the tests, causes the unexpected behaviour to disappear

I can confirm the described behavior with Clojure 1.2.0 and Leiningen 1.3.1.

But it shouldn't work at all, because "instance-test.core" is not a valid Java package name. This was fixed in CLJ-432.

With Clojure 1.3.0-alpha5, MyType's package name is correctly munged to "instance_test.core". Loading the test namespaces fails (as it should) with java.lang.ClassNotFoundException: instance-test.core.MyType.

Converted from http://www.assembla.com/spaces/clojure/tickets/419

stu said: Phil,

Please add an example and nag me to bump the priority if this is causing real and present pain.

technomancy said: Eh; it's not causing real pain.

I would be OK with a WONTFIX if that's what is decided. Just thought it wouldn't hurt to have a record of it somewhere (even as a closed-as-invalid ticket), and I was in a particularly pedantic mood last night for some reason.

I ran across it because of an escaping bug in Wine where I wanted to treat "(use 'foo)(-main)" as a single token in bash but two still be valid Clojure code. But luckily I found a better workaround. I am OK with leaving it at lowest priority.

djpowell said: Hmm, I'm not sure isSpaceChar is right - it doesn't seem to allow things like tabs and newlines. If you really wanted to support non-break-space, then it would probably be best to just use isWhitespace and add them as a special case.

Actually... I would quite like to see \ufeff treated as whitespace. It is the Unicode BOM. Some editors including Windows Notepad include the BOM at the start of UTF-8 files. The latest Unicode docs seem to recognise the UTF-8 BOM. By treating it as whitespace we can avoid any problems with it.

technomancy said: Sounds like I had this not quite right; probably not worth worrying about.

Converted from http://www.assembla.com/spaces/clojure/tickets/416

Closing as "completed" as most of these requests are handled in 1.5 via the new send-via, and set executor functions.

Converted from http://www.assembla.com/spaces/clojure/tickets/414

bpsm said: You've confused true? and false? with boolean.

Clojure 1.0.1-alpha-SNAPSHOT
user=> (false? '())
false
user=> (true? '())
false
user=> (boolean '())
true
</code></pre>
<pre><code>Clojure 1.1.0
user=> (false? '())
false
user=> (true? '())
false
user=> (boolean '())
true
</code></pre>
<pre><code>Clojure 1.2.0-beta1
user=> (false? '())
false
user=> (true? '())
false
user=> (boolean '())
true

boolean converts its argument to either true or false. nil and false yield false, everything else yields true.
true? and false? do no such conversion, nor should they. Only true is true?. Only false is false?.

Converted from http://www.assembla.com/spaces/clojure/tickets/412

stu said: If a var is (a) public (b) has a docstring and (c) has :added metadata, then the Clojure team is committed to supporting it. These vars don't meet the criteria. In the context of a broader overhaul of XML support these might become official APIs.

bpsm said: That makes sense. I wasn't aware of those conventions. Perhaps the library should advertise itself as being only for XML reading:

--- a/src/clj/clojure/xml.clj
+++ b/src/clj/clojure/xml.clj
@@ -6,7 +6,7 @@
 ;   the terms of this license.
 ;   You must not remove this notice, or any other, from this software.
 
-(ns ^{:doc "XML reading/writing."
+(ns ^{:doc "XML reading."
        :author "Rich Hickey"}
   clojure.xml
   (:import (org.xml.sax ContentHandler Attributes SAXException)

Converted from http://www.assembla.com/spaces/clojure/tickets/411

stu said: APIs without docstrings (like emit) are not supported.

We would welcome a redesign of the XML support that made this good enough to publicize and support.

Converted from http://www.assembla.com/spaces/clojure/tickets/409
Attachments:
show-409-on-oberon.txt - https://www.assembla.com/spaces/clojure/documents/aSijYaMmCr35jQeJe5cbLr/download/aSijYaMmCr35jQeJe5cbLr

bpsm said: Provide link to my '409show' branch, which does what it says on the tin.

stu said: This code works fine for me locally (Mac OS X). I would investigate a busted Ant setup, or getting a different version of Java, on your end.

I'll be looking through the rest of the XML tickets your filed this morning – thanks for taking the time!

bpsm said: Thanks. I've seen this both on my Mac and Linux netbook (JDK 1.6.0_20), but I'm sitting in front of a machine I haven't tried to reproduce this on yet, so I'll give it a whirl here and report what I find.

bpsm said: [file:aSijYaMmCr35jQeJe5cbLr]: demonstrates #409 on x64, Java1.6.0_20, ant 1.7.1

bpsm said: I see the failure on my workstation as well, alas. I've attached a transcript including ant -diagnostics output. If it is my local setup at fault, I'm not sure what it could be. Perhaps something there will catch your eye.

Converted from http://www.assembla.com/spaces/clojure/tickets/408
Attachments:
408-escape-and-in-content-and-attribute-value.patch - https://www.assembla.com/spaces/clojure/documents/aBCHT2LZer34ioeJe5cbLr/download/aBCHT2LZer34ioeJe5cbLr

bpsm said: Tests that demonstrate #408 are available at http://github.com/bpsm/test-clojure-xml.

bpsm said: [file:aBCHT2LZer34ioeJe5cbLr]: see also http://github.com/bpsm/clojure/commits/fix408,410,277

bpsm said: I saw rich's message about marking issues "ready for test" to get patches noticed. This was in connection with marking #410 as ready for test. This issue is joined at the hip with 410 and also has a patch ready.

emit is not part of Clojure's public API, and we don't want to grow a public API via an issue-driven random walk. If you are interested in this issue, please chime in on the design page for a new data.xml library: http://dev.clojure.org/display/DXML/Home

Converted from http://www.assembla.com/spaces/clojure/tickets/406

stu said: Already discussed as a subset of #382.

Converted from http://www.assembla.com/spaces/clojure/tickets/405

stu said: This could be fixed with an assert-valid-defrecord call in core_deftype, similar to assert-valid-fdecl in core.clj. Such a function would also be a place to hang other defrecord error messages.

Converted from http://www.assembla.com/spaces/clojure/tickets/401

Converted from http://www.assembla.com/spaces/clojure/tickets/400
Attachments:
flatten-enhancement.diff - https://www.assembla.com/spaces/clojure/documents/c5chtAJQir353NeJe5cbLr/download/c5chtAJQir353NeJe5cbLr

Converted from http://www.assembla.com/spaces/clojure/tickets/396

Converted from http://www.assembla.com/spaces/clojure/tickets/395

stu said: Duplicates #382.

Converted from http://www.assembla.com/spaces/clojure/tickets/379
Attachments:
ticket-379-fix.diff - https://www.assembla.com/spaces/clojure/documents/c5XWHcD4yr34HveJe5ccaP/download/c5XWHcD4yr34HveJe5ccaP

alexott said: possible fix is attached

alexott said: [file:c5XWHcD4yr34HveJe5ccaP]

Converted from http://www.assembla.com/spaces/clojure/tickets/375
Attachments:
0001-read-foo-bar-as-foo-true-bar-and-merge-existing-meta.patch - https://www.assembla.com/spaces/clojure/documents/dWhNbgCWKr34aBeJe5cbCb/download/dWhNbgCWKr34aBeJe5cbCb

cgrand said: [file:dWhNbgCWKr34aBeJe5cbCb]: patch + test

Converted from http://www.assembla.com/spaces/clojure/tickets/363

cgrand said: Parent association with ticket #270 was added

cgrand said: duplicate of #270

Converted from http://www.assembla.com/spaces/clojure/tickets/354
Attachments:
nan-comparison.clj - https://www.assembla.com/spaces/clojure/documents/bSK-9AzyGr35jbeJe5cbLr/download/bSK-9AzyGr35jbeJe5cbLr
nan.java - https://www.assembla.com/spaces/clojure/documents/bSLbjAzyGr35jbeJe5cbLr/download/bSLbjAzyGr35jbeJe5cbLr
c-nan.txt - https://www.assembla.com/spaces/clojure/documents/bSLdpEzyGr35jbeJe5cbLr/download/bSLdpEzyGr35jbeJe5cbLr
j-nan.txt - https://www.assembla.com/spaces/clojure/documents/bSLft0zyGr35jbeJe5cbLr/download/bSLft0zyGr35jbeJe5cbLr

stu said: This appears to be fixed in 1.3 master.

Not fixed on current git master: the test program still prints e.g. <= 0 NaN true. Interestingly, (<= (float 0.0) Float/NaN) returns false, while (let [op <=] (op (float 0.0) Float/NaN)) returns true.

See CLJ-738.

Converted from http://www.assembla.com/spaces/clojure/tickets/350

david-mcneil said: This issue was addressed indirectly by ticket 334. Now the code behaves like this for keywords that reference non-existent namespaces:

(namespace ::x/y)

;=> java.lang.Exception: Invalid token: ::x/y

Seems that is fine, at least it is not an NPE.

-David

donmullen said: This is fixed, as David indicated - ::x/y is an invalid token.

Current message is:

Exception Invalid token: ::x/y clojure.lang.LispReader.interpretToken (LispReader.java:286)

Exception Unmatched delimiter: ) clojure.lang.LispReader$UnmatchedDelimiterReader.invoke (LispReader.java:1039)

Converted from http://www.assembla.com/spaces/clojure/tickets/346
Attachments:
0347-pprint-update-2.diff - https://www.assembla.com/spaces/clojure/documents/diLxv6y4Sr35GVeJe5cbLr/download/diLxv6y4Sr35GVeJe5cbLr

stu said: [file:diLxv6y4Sr35GVeJe5cbLr]

stu said: The second patch includes the first, and adds another test.

tomfaulhaber said: This patch was attached to the wrong bug. It should be attached to bug #347. There is no fix for this bug yet.

Is this current?

Tom, this patch doesn't apply, and I am not sure why. Can you take a look?

Converted from http://www.assembla.com/spaces/clojure/tickets/345

stu said: I evaluated this agains the latest version of the fn in clojre (e.g. clojure.string/replace).

The documentation string correctly lists legal parameters for replace as string, char, or fn, so an NPE is expected behavior.

Note also: the contrib versions of most string fns are deprecated.

Converted from http://www.assembla.com/spaces/clojure/tickets/339

devlinsf said: Also, some more cases

user=> (- Integer/MAX_VALUE Integer/MAX_VALUE Integer/MAX_VALUE)
-2147483647

user=> (- Integer/MIN_VALUE Integer/MIN_VALUE)
0
user=> (- Integer/MAX_VALUE Integer/MIN_VALUE)
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)

user=> (- Integer/MAX_VALUE Integer/MIN_VALUE)
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)

user=> (- Integer/MIN_VALUE Integer/MAX_VALUE)
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)

user=> (* Integer/MIN_VALUE Integer/MAX_VALUE)
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)

user=> (* Integer/MAX_VALUE Integer/MAX_VALUE)
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)

user=> (* Integer/MAX_VALUE Integer/MAX_VALUE Integer/MAX_VALUE)
9903520300447984150353281023

aredington said: When testing with ints, this behavior no longer happens as all arithmetic happens in longs.

When testing with longs, the overflow behavior occurs consistently, regardless of the involvement of vars or let bindings.

Converted from http://www.assembla.com/spaces/clojure/tickets/319
Attachments:
TransactionalHashMap.java.patch - https://www.assembla.com/spaces/clojure/documents/cuuZnsuuWr36H0eJe5dVir/download/cuuZnsuuWr36H0eJe5dVir

megabyte2021 said: [file:cuuZnsuuWr36H0eJe5dVir]: The patch file

stu said: Please add a test case.

Converted from http://www.assembla.com/spaces/clojure/tickets/308

Added a CloseableResource protocol and extended it on java.io.Closeable (implemented by all Readers, Writers, Streams, Channels, Sockets). Use it in with-open.

All tests pass.

Seems to be related to Scopes (http://dev.clojure.org/jira/browse/CLJ-2).

Updated patch.

Patch 0001-Added-ClosableResource-protocol-for-with-open.patch dated 08/Mar/12 applies, builds, and tests cleanly on latest master as of Apr 2 2012. Tassilo has signed a CA.

Updated patch to apply cleanly against master again.

Converted from http://www.assembla.com/spaces/clojure/tickets/304

chouser@n01se.net said: That's a great question. get-source just needs a file name and line number.

If IMeta were a protocol, it could be extended to Class. That implementation could look for a "well-known" static field, perhaps? __clojure_meta or something? Then deftype would just have to populate that field, and get-source would be all set.

Does that plan have any merit? Is there a better place to store a file name and line number?

stu said: Seems like a reasonable idea, but this is going to get back-burnered for now, unless there is a dire use case we have missed.

Converted from http://www.assembla.com/spaces/clojure/tickets/293
Attachments:
dotodoc.diff - https://www.assembla.com/spaces/clojure/documents/a_SYzart8r37u3eJe5aVNr/download/a_SYzart8r37u3eJe5aVNr

Converted from http://www.assembla.com/spaces/clojure/tickets/288
Attachments:
merge-with-enhancements.diff - https://www.assembla.com/spaces/clojure/documents/cIq-tspyur375WeJe5avMc/download/cIq-tspyur375WeJe5avMc

CLJ-288 patch dated 2010-05-27, from Konrad Hinsen, applied before Clojure 1.3.0 was released

Converted from http://www.assembla.com/spaces/clojure/tickets/287
Attachments:
take-nth.diff - https://www.assembla.com/spaces/clojure/documents/awDmNUpz4r34FheJe5aVNr/download/awDmNUpz4r34FheJe5aVNr

bhurt said: [file:awDmNUpz4r34FheJe5aVNr]: Proposed patch to fix this ticket

stu said: Hi Simon,

If you set the print-length you can prevent runaway sequences from trying to print. Try the following, and if still blows up please re-open or file a new bug:

(set! *print-length* 10)
 (take-nth 0 (range 5))

Cheers,
Stu

bhurt said: I think the real problem is that (take-nth 0 some-list) is invalid. It's nonsensical in a deep way- take every 0th element? If you glanced at my patch, all I did was validate the arguments and throw an exception if the n argument is not positive, rather than returning an infinite list. I mean, a similar problem shows up if you do (count (take-nth 0 (range 5))).

Converted from http://www.assembla.com/spaces/clojure/tickets/284
Attachments:
ubyte.diff - https://www.assembla.com/spaces/clojure/documents/b_MyyAn4mr34xSeJe5avMc/download/b_MyyAn4mr34xSeJe5avMc

ataggart said: [file:b_MyyAn4mr34xSeJe5avMc]: Adds a ubyte coercion when the resulting byte should be considered unsigned, thus inputs of 0-255 are acceptable

ataggart said: Patch provided to add a ubyte coercion:

<pre>user=> 0xFF
255
user=> (Integer/toBinaryString 0xFF)
"11111111"
user=> (byte 0xFF)
java.lang.IllegalArgumentException: Value out of range for byte: 255 (NO_SOURCE_FILE:0)
user=> (ubyte 0xFF)
-1
user=> (ubyte 256)
java.lang.IllegalArgumentException: Value out of range for unsigned byte: 256 (NO_SOURCE_FILE:0)
</pre>

richhickey said: This is really a subset of #441

ataggart said: Agreed.

Converted from http://www.assembla.com/spaces/clojure/tickets/283

stu said: Recur doesn't re-enter the function, it just goes back to the top (the vararging doesn't happen again). Since b is a collection coming in, recur with a collection and you will be fine.

(defn weird [& b]
  (println b)
  (when (< (first b) 2)
    (recur (cons (inc (first b)) (rest b)))))

I find this intuitive, but when I launch the Assembla FAQ feel free to add an item for this if you like.

technomancy said: > I find this intuitive, but when I launch the Assembla FAQ feel free to add an item for this if you like.

OK. Anecdotally I asked four other seasoned Clojure users what they thought was going on here and only one had an explanation, so most folks are going to think this is an unintended result when they see it. I don't know if it's FA enough to qualify this for a FAQ, but even having this closed issue show up in search results is an improvement.

I know internally there's a difference between calling a function and executing the body of a function, but up till this point I considered that an implementation detail.

Converted from http://www.assembla.com/spaces/clojure/tickets/279

Converted from http://www.assembla.com/spaces/clojure/tickets/277

bpsm said: I've attached a patch to #410, which also fixes this issue. (In fact, it turns out that it's the same patch tlj previously attached here.)

stu said: Duplicated association with ticket #410 was added

Converted from http://www.assembla.com/spaces/clojure/tickets/274

donmullen said: Updated each run to [_] for new syntax.

Now gives exception listed.

richhickey said: We're not going to allow closing over mutable fields. Instead we'll have to generate something other than fn for loops et al used as expressions. Not going to come before cinc

Converted from http://www.assembla.com/spaces/clojure/tickets/273

Converted from http://www.assembla.com/spaces/clojure/tickets/272

stu said: Suggestions from Volkan Yazici:

Hi,

I saw your "load/ns/require/use overhaul" ticket[1] and would like to
ask for a few extra overhaulings. I have a project called retop, and
here is its file hiearachy:

tr/edu/bilkent/cs/retop.clj
tr/edu/bilkent/cs/retop/km.clj
tr/edu/bilkent/cs/retop/graph.clj
tr/edu/bilkent/cs/retop/main.clj
tr/edu/bilkent/cs/retop/util.clj

In retop.clj, I have below ns definition.

(ns tr.edu.bilkent.cs.retop
(:gen-class)
(:import
(com.sun.jna
Function
Pointer)
(com.sun.jna.ptr
IntByReference)
(tr.edu.bilkent.cs.patoh
HyperGraph
HyperGraphException
Parititoning
ParititoningParameters))
(:load
"retop/util"
"retop/km"
"retop/graph"
"retop/main"))

And in every .clj file in retop/ directory I have below in-ns in the
very first line.

(in-ns 'tr.edu.bilkent.cs.retop)

The problems with the ns decleration are:

1) Most of the :import's in retop.clj only belong to a single .clj file.
For instance,

(tr.edu.bilkent.cs.patoh
HyperGraph
HyperGraphException
Parititoning
ParititoningParameters)

imports are only used by graph.clj. Yep, I can add an (import ...)
line just after the (in-ns ...), but wouldn't it be better if I can
specify that in (in-ns ...) form?

2) See (:load ...) clause in (ns ...) form. There are lots of
unnecessary directory prefixes. I'd be prefer something ala Common
Lisp's defpackage:

(:load
"packages" ; packages.clj
("retop"
"util" ; retop/util.clj
"km" ; retop/km.clj
"graph" ; retop/graph.clj
("graph"
"foo" ; retop/graph/foo.clj
"bar) ; retop/graph/bar.clj
"main")) ; retop/main.clj

Also, being able to use wildcards would be awesome.

3) There are inconsistencies between macros and functions. For instance,
consider:

(ns foo.bar.baz (:use mov))
(in-ns 'foo.bar.baz)
(use 'mov)

I'd like to get rid of quotations in both cases.

I'm not sure if I'm using the right tools and doing the right approach
for such a project. But if you agree with the above overhauling
requirements, I'd like to see them appear in the same assembla ticket as
well.

stuart.sierra said: My requests:

1. If writing macros that do not evaluate their arguments, provide function versions that do evaluate their arguments.

2. Do not support prefix lists for loading Clojure namespaces. It's hard to parse with external tools.

3. Do not conflate importing Java classes with loading Clojure namespaces. They are fundamentally different operations with different semantics.

I have implemented some ideas in a macro called "need" at http://github.com/stuartsierra/need

Further requests:

Permit tools to read the "ns" declaration and statically determine the dependencies of a namespace, without evaluating any code.

Permit tools to read the "ns" declaration and statically determine the dependencies of a namespace, without evaluating any code.

This would be great for building OSGi bundles where Bnd is currently not much help.

Converted from http://www.assembla.com/spaces/clojure/tickets/255
Attachments:
ratio-fns.diff - https://www.assembla.com/spaces/clojure/documents/cyO2hUdrir3749eJe5aVNr/download/cyO2hUdrir3749eJe5aVNr

hiredman said: [file:cyO2hUdrir3749eJe5aVNr]: add denominator and numerator fns

hiredman said: Duplicated association with ticket #254 was added

hiredman said: (In [[r:5772be9fc5ac9ddf92b727908c20b9aab971224a]]) numerator and denominator fns for Ratios, refs #255

Signed-off-by: Rich Hickey <richhickey@gmail.com>

Branch: master

Converted from http://www.assembla.com/spaces/clojure/tickets/251

Converted from http://www.assembla.com/spaces/clojure/tickets/238
Attachments:
0001-Changed-re-pattern-to-accept-multiple-arguments-to-c.patch - https://www.assembla.com/spaces/clojure/documents/barzR2-Jyr3OGheJe5aVNr/download/barzR2-Jyr3OGheJe5aVNr

richhickey said: Could you please put an example of what the enhancement would let you do, in the description? Thanks.

richhickey said: I don't see the need for this

Converted from http://www.assembla.com/spaces/clojure/tickets/237
Attachments:
0001-Added-only-keys-destructuring-option-like-keys-but-t.patch - https://www.assembla.com/spaces/clojure/documents/bEnEvg-I4r3OA7eJe5afGb/download/bEnEvg-I4r3OA7eJe5afGb