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.

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.

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

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/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/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/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/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/395

stu said: Duplicates #382.

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/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/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/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

budu said: [file:bEnEvg-I4r3OA7eJe5afGb]: Add :only-keys destructuring option

richhickey said: Could someone please review this patch? I'm ok with the idea in general, but it seems strange that the :only test would only be available for (non-renaming) :keys destructuring

chouser@n01se.net said: One drawback to any such checking is it may prevent code written for a future version of the function that takes more named args from working at all with a previous version of the function. For example 'ref' now accepts :min-history. Code that uses that now would probably work fine with versions of ref that didn't support that knob, but if they checked to prevent extra args they would fail unnecessarily.

budu said: Good point, didn't think about that! We could recommend the use of :keys in early development and :only-keys when APIs become very stable.

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

Declined. There has been limited support for this ticket. It changes the concept of destructuring to include something more like validation, which it was not intended to support.

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

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

stu said: This is not going to be fixed in the short or medium term. Please ping me if you have a compelling use case though.

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

chouser@n01se.net said: Parent association with ticket #142 was added

This duplicate of #142 has been resolved.

Latest from head:

user=> (set! (.foo "fred") 47)
IllegalArgumentException No matching field found: foo for class java.lang.String clojure.lang.Reflector.setInstanceField (Reflector.java:257)
user=>

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

stu said: I don't think this is a bug – there is no "correct value for the agent" as seen from the calling thread. There is a race condition when viewing agents at the REPL, and this is by design.

fogus said: I understand why it happens, but it might be worthwhile to at least document this condition and/or consider removing the print of the value. In some cases reporting nothing is better than potentially incorrect information. Or is it enough to just say, "it's correct eventually or at least most of the time"?

-m

Converted from http://www.assembla.com/spaces/clojure/tickets/122
Attachments:
clojure.diff - https://www.assembla.com/spaces/clojure/documents/dXnrtCw4qr3RbzeJe5afGb/download/dXnrtCw4qr3RbzeJe5afGb

oranenj said: [file:dXnrtCw4qr3RbzeJe5afGb]

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

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

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

Can I move the FAQ over the Confluence, and then change the old Google code page to link over?

Yes, thanks

Converted from http://www.assembla.com/spaces/clojure/tickets/120
Attachments:
partition-with-pad.patch - https://www.assembla.com/spaces/clojure/documents/ctfCdww4qr3RbzeJe5afGb/download/ctfCdww4qr3RbzeJe5afGb
part.clj - https://www.assembla.com/spaces/clojure/documents/ckiilEyzqr3PTqeJe5afGb/download/ckiilEyzqr3PTqeJe5afGb
part.clj - https://www.assembla.com/spaces/clojure/documents/dmo9mEyzWr3QuceJe5aVNr/download/dmo9mEyzWr3QuceJe5aVNr
partition-with-pad-2.diff - https://www.assembla.com/spaces/clojure/documents/bolonky_8r3RY8eJe5afGb/download/bolonky_8r3RY8eJe5afGb
ticket-120.patch - https://www.assembla.com/spaces/clojure/documents/bnWYoqzBKr3RKeeJe5afGb/download/bnWYoqzBKr3RKeeJe5afGb

oranenj said: [file:ctfCdww4qr3RbzeJe5afGb]

chouser@n01se.net said: It looks to me like the 3- and 4-arg bodies could be combined resulting in less code and no significant loss of performance. A pad of nil could be treated the same as no pad supplied, which would be different from a numeric pad (including 0).

scgilardi said: By "combined" do you mean that the 3 argument version should call the 4 argument version with an explicit pad of nil?

Currently, the 3 argument version does no padding. Instead it stops as soon as there are less than n args left:

user=> (partition 3 [1 2 3 4])
((1 2 3))
</code></pre>

In contrast, the 4 argument version with a pad of nil produces (untested):
<pre><code>user=> (partition 3 nil [1 2 3 4])
((1 2 3) (4 nil nil))

Interpreting nil passed to the 4 argument version as a request to get the behavior of the 3 argument version looks wrong to me. There would be no way to express both a desire for padding and that the padding value should be nil.

scgilardi said: Looking into the issue further, I see I made a mistake in my previous comment. The padding is given as a sequence, not a value. However, the key difference between the 3 and 4 arg versions remains. The 3 argument version never returns a "short" sequence at the end. The 4 arg version can.

Along the lines of your suggestion, we could combine the two by changing the 4 arg version to interpret a pad value of "[]" to mean "return a short sequence at the end if necessary" and a pad value of "nil" to mean "never return a short sequence". This would involve interpreting "nil" different from "the empty sequence" where in many other contexts they're equivalent. I'm not sure whether or not saving some code is a good trade for introducing that subtle difference.

chouser@n01se.net said: I had also mistaken pad to be a number. I think you're right, producing different behavior when pad is an empty seq vs. nil is just asking for trouble. Thanks for taking a second look.

importer said: (In [[r:e0e8326871983be5615f5c0bc9dbf66140c7017f]]) add optional pad argument to partition. Fixes #120

Signed-off-by: Chouser <chouser@n01se.net>

Branch: master

digash said: The original version was using nil but Rich suggested not do it that way.
For different revisions take a look at this gist http://gist.github.com/109002

chouser@n01se.net said: Thanks for that link. Your final solution (not using nil) is already committed, but we should get those tests into clojure-test once it's location has been settled.

richhickey said: The new partition has this behavior:

user=> (partition 3 1 nil (range 10))
((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 7) (6 7 8) (7 8 9) (8 9))
user=> (partition 3 1 [42] (range 10))
((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 7) (6 7 8) (7 8 9) (8 9 42))

It seems to me that with a step of one it should never use the pad, and, more generally, once it has produced one partition containing the last element of the coll it should be done.

richhickey said: An alternative rule is that every step within the supplied coll is yielded, padding as supplied, which would mean ending with:

(7 8 9) (8 9) (9)
(7 8 9) (8 9 42) (9 42)

scgilardi said: [file:ckiilEyzqr3PTqeJe5afGb]: proposed alternative (see my comment)

scgilardi said: I've uploaded part.clj which is another possible alternative. It handles a step of 1 without using the pad. Some invariants in the partitions it produces for the 4 argument case:

• for a step size of n, if you provide n - 1 objects in the padding sequence, all output sequences will be of size n
• for a step size n, the output sequences will begin with elements at offsets 0, n, 2n, 3n, ... in the original sequence until no such element exists.

Some outputs:

user=> (part/partition 3 1 nil (range 10))
((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 7) (6 7 8) (7 8 9))
user=> (part/partition 3 1 [42] (range 10))
((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 7) (6 7 8) (7 8 9))
---
user=> (part/partition 3 2 nil (range 9))
((0 1 2) (2 3 4) (4 5 6) (6 7 8) (8))
user=>  (part/partition 3 2 [42] (range 9))
((0 1 2) (2 3 4) (4 5 6) (6 7 8) (8 42))
user=> (part/partition 3 2 [42 43] (range 9))
((0 1 2) (2 3 4) (4 5 6) (6 7 8) (8 42 43))
---
user=> (part/partition 3 4 nil (range 6))
((0 1 2) (4 5))
user=> (part/partition 3 4 nil (range 7))
((0 1 2) (4 5 6))
user=> (part/partition 3 4 nil (range 8))
((0 1 2) (4 5 6))
user=> (part/partition 3 4 nil (range 9))
((0 1 2) (4 5 6) (8))
---
user=> (part/partition 3 3 [42 43] (range 3))
((0 1 2))
user=> (part/partition 3 3 [42 43] (range 4))
((0 1 2) (3 42 43))
user=> (part/partition 3 3 [42 43] (range 5))
((0 1 2) (3 4 42))
user=> (part/partition 3 3 [42 43] (range 6))
((0 1 2) (3 4 5))
user=> (part/partition 3 3 [42 43] (range 7))
((0 1 2) (3 4 5) (6 42 43))
</code></pre>

Here's the relevant portion of the code:

<pre><code>  ([n step pad coll]
     (lazy-seq
      (when-let [s (seq coll)]
        (let [p (take n s)]
          (cond (= n (count p))
                (cons p (partition n step pad (drop step s)))
                (>= step (count p))
                (list (take n (concat p pad)))))))))

Please see part.clj for details and a test program.

scgilardi said: Ugh, the second "invariant" I listed doesn't hold for step = 1. It appears to hold for other step values. Perhaps part.clj will still be useful to someone in coming up with a better solution.

richhickey said: I don't see why step of 1 should get special treatment. If the rule is the second one (yield partitions as long as step offsets are present in original coll), then

(part/partition 3 1 nil (range 10))
should end with:
(7 8 9) (8 9) (9)

scgilardi said: This one appears to work:

([n step pad coll]
     (lazy-seq
      (when-let [s (seq coll)]
        (cons
         (take n (concat s pad))
         (partition n step pad (drop step s)))))))
</code></pre>

<pre><code>user=> (run part)
n = 3, pad = nil
:max 5 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4) (4))
:max 6 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5) (5))
:max 7 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6) (6))
:max 8 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 7) (6 7) (7))
:max 9 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 7) (6 7 8) (7 8) (8))

:max 5 :step 2 ((0 1 2) (2 3 4) (4))
:max 6 :step 2 ((0 1 2) (2 3 4) (4 5))
:max 7 :step 2 ((0 1 2) (2 3 4) (4 5 6) (6))
:max 8 :step 2 ((0 1 2) (2 3 4) (4 5 6) (6 7))
:max 9 :step 2 ((0 1 2) (2 3 4) (4 5 6) (6 7 8) (8))

:max 5 :step 3 ((0 1 2) (3 4))
:max 6 :step 3 ((0 1 2) (3 4 5))
:max 7 :step 3 ((0 1 2) (3 4 5) (6))
:max 8 :step 3 ((0 1 2) (3 4 5) (6 7))
:max 9 :step 3 ((0 1 2) (3 4 5) (6 7 8))

:max 5 :step 4 ((0 1 2) (4))
:max 6 :step 4 ((0 1 2) (4 5))
:max 7 :step 4 ((0 1 2) (4 5 6))
:max 8 :step 4 ((0 1 2) (4 5 6))
:max 9 :step 4 ((0 1 2) (4 5 6) (8))

n = 3, pad = [42 43]
:max 5 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 42) (4 42 43))
:max 6 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 42) (5 42 43))
:max 7 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 42) (6 42 43))
:max 8 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 7) (6 7 42) (7 42 43))
:max 9 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 7) (6 7 8) (7 8 42) (8 42 43))

:max 5 :step 2 ((0 1 2) (2 3 4) (4 42 43))
:max 6 :step 2 ((0 1 2) (2 3 4) (4 5 42))
:max 7 :step 2 ((0 1 2) (2 3 4) (4 5 6) (6 42 43))
:max 8 :step 2 ((0 1 2) (2 3 4) (4 5 6) (6 7 42))
:max 9 :step 2 ((0 1 2) (2 3 4) (4 5 6) (6 7 8) (8 42 43))

:max 5 :step 3 ((0 1 2) (3 4 42))
:max 6 :step 3 ((0 1 2) (3 4 5))
:max 7 :step 3 ((0 1 2) (3 4 5) (6 42 43))
:max 8 :step 3 ((0 1 2) (3 4 5) (6 7 42))
:max 9 :step 3 ((0 1 2) (3 4 5) (6 7 8))

:max 5 :step 4 ((0 1 2) (4 42 43))
:max 6 :step 4 ((0 1 2) (4 5 42))
:max 7 :step 4 ((0 1 2) (4 5 6))
:max 8 :step 4 ((0 1 2) (4 5 6))
:max 9 :step 4 ((0 1 2) (4 5 6) (8 42 43))

nil
user=>

scgilardi said: [file:dmo9mEyzWr3QuceJe5aVNr]: improved version

richhickey said: This looks fine to me, do you want to make up a patch Steve?

scgilardi said: [file:bolonky_8r3RY8eJe5afGb]: modified per comments

scgilardi said: The patch includes and updated doc string, the new 4 argument case, and a change to the whitespace in the 3 argument case for consistent indentation with the 4 argument case (current emacs clojure-mode). I can provide a patch that doesn't touch the 3 argument case whitespace if desired.

richhickey said: I think the doc should be even more explicit, something like:

... do not overlap. If no pad argument is supplied, will produce only complete partitions of size n, possibly not including items at the end if the size of coll is not a multiple of n. If the pad argument is supplied, will produce a partition at every offset present in the supplied collection, using the pad elements as necessary to pad trailing partitions up to n items each. If pad is nil or a collection containing fewer than n-1 items, ...

scgilardi said: How about this:

"Returns a lazy seq of lazy subseqs of coll, each of (nominally) n
  items. The subseqs begin at offsets 0, step, 2*step, etc. in coll. If
  step is not supplied, it defaults to n yielding adjacent, non-overlapping
  subseqs. If pad is not supplied, produces only complete subseqs of n
  items, possibly not including some items at the end of coll. If pad is
  supplied, produces a subseq at every offset present in coll, using any
  available items from pad to pad shorter subseqs up to n items. If pad is
  a seq of at least n-1 items, produces only complete padded subseqs of n
  items. If pad is shorter (or nil) trailing padded subseqs may be
  shorter."

I adopted the mathematical terminology that the partition is the operation (the division into parts) and that the individual pieces are not "partitions", but something else: part, block, chunk, or as I propose here, subseq. I like subseq because it embodies succinctly the fact that the items from coll are always kept sequential.

richhickey said: I'm now convinced we are cramming 2 functions into one, and would prefer to see this new functionality as a new function:

(take-subs n coll)
(take-subs n step coll)

'padding' isn't a necessary concept, as we have concat. take implies the possible partial subseqs. Also take-subs can yield a lazy seq of lazy seqs, but partition can't.

scgilardi said: [file:bnWYoqzBKr3RKeeJe5afGb]: take-subs + tests

scgilardi said: OK, paddiing isn't necessary because the same thing can be accomplished by using concat to append a padding sequence of exactly n-1 items to coll before processing it with partition.

partition can't return lazy subseqs because it counts them which (in the general case) will realize them.

ticket-120.patch contains modified docs for partition, removed arity 4 case from partition, take-subs implemented, tests for take-subs based on tests for partition, enhanced one sub-test for partition.

digash said: I like the new take-subs, but I cannot figure out how to use concat instead of partition without counting it and realizing the whole sequence.
The initial motivation was to use partition with destructuring and creating matrix from a sequences. I do not see an easy way to reproduce this case with the new implementation.

The old implementation:
(for [[a b c] (partition 3 3 (repeat 0) [1 2 3 4])] [a b c]) ==> ([1 2 3] [4 0 0])

The new implementation:
(take 10 (let [coll [1 2 3 4] p 3] (take (/ (count coll) p) (for [[a b c] (take-subs p (concat coll (repeat 0)))] [a b c])))) ==> ([1 2 3] [4 0 0])

scgilardi said: Here are two options for how I would write the example using the most recent patch:

user=> (for [[a b c] (partition 3 (concat [1 2 3 4] (take 3 (repeat 0))))] [a b c])
([1 2 3] [4 0 0])
user=> (for [[a b c] (partition 3 (concat [1 2 3 4] [0 0 0]))] [a b c])
([1 2 3] [4 0 0])
user=> 
</code></pre>or in the general case:
<pre><code>user=> (defn padded-partition
[n pad coll]
(partition n (concat coll (take (dec n) pad))))
#'user/padded-partition
user=> (for [[a b c] (padded-partition 3 (repeat 0) [1 2 3 4])] [a b c])
([1 2 3] [4 0 0])
user=>

scgilardi said: My first code example above was incorrect. For proper operation with all combinations of n and step, the concatenated padding seq needs to be exactly n-1 in length.

Here's the correction:

user=> (for [[a b c] (partition 3 (concat [1 2 3 4] (take 2 (repeat 0))))] [a b c])
([1 2 3] [4 0 0])
user=> (for [[a b c] (partition 3 (concat [1 2 3 4] [0 0]))] [a b c])
([1 2 3] [4 0 0])
user=>

partition has a pad argument now. Can this be closed?

partition has pad now

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

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

Converted from http://www.assembla.com/spaces/clojure/tickets/114
Attachments:
clojure-version.patch - https://www.assembla.com/spaces/clojure/documents/aKO9q2w4mr3Od2eJe5aVNr/download/aKO9q2w4mr3Od2eJe5aVNr
clojure-version2.patch - https://www.assembla.com/spaces/clojure/documents/aKO_-6w4mr3Od2eJe5aVNr/download/aKO_-6w4mr3Od2eJe5aVNr

oranenj said: [file:aKO9q2w4mr3Od2eJe5aVNr]

oranenj said: [file:aKO_-6w4mr3Od2eJe5aVNr]: on comment 2

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

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

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

stu said: On the latest master I see what I think is the expected error:

(:arglists (meta (defn arglists broken-arglist ([a] a) ([a b] b))))
java.lang.IllegalArgumentException: Don't know how to create ISeq from: clojure.lang.Symbol

Converted from http://www.assembla.com/spaces/clojure/tickets/87
Attachments:
map-literals-error.diff - https://www.assembla.com/spaces/clojure/documents/cJ9rlAc4Gr36CjeJe5aVNr/download/cJ9rlAc4Gr36CjeJe5aVNr

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

hiredman said: [file:cJ9rlAc4Gr36CjeJe5aVNr]: add error detect to reader

hiredman said: patch adds some error detection to the map literal reader. covers the above case and also {:a}

devlinsf said: Could this issue be promoted to "Release - Bug Fix"?

richhickey said: (In [[r:e6e39d5931fbdf3dfa68cd2d059b8e26ce45c965]]) catch duplicate map keys for literals and hash- and array-map calls. Fixes #87

Branch: master

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

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

stu said: The code appears to run correctly against current master.

Converted from http://www.assembla.com/spaces/clojure/tickets/50
Attachments:
structmap-def-extends-restfn.patch - https://www.assembla.com/spaces/clojure/documents/aFFlyCw3qr3R14eJe5aVNr/download/aFFlyCw3qr3R14eJe5aVNr

cemerick said: [file:aFFlyCw3qr3R14eJe5aVNr]

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

richhickey said: I'm not sure I want to touch structmaps prior to implements

This ticket has survived almost two years, two bug tracker migrations[1] and now who uses structs anymore? Records have essentially this syntax for their ctors. I nominate this ticket be closed as "wontfix" or equivalent.

[1]: http://code.google.com/p/clojure/issues/detail?id=46

Converted from http://www.assembla.com/spaces/clojure/tickets/17
Attachments:
0001-Test-invalid-symbol-keyword-names-raise-exceptions.patch - https://www.assembla.com/spaces/clojure/documents/cpC-Qow3ar3P8LeJe5afGb/download/cpC-Qow3ar3P8LeJe5afGb
validate-symbol-keyword-names.patch - https://www.assembla.com/spaces/clojure/documents/cpDbtWw3ar3P8LeJe5afGb/download/cpDbtWw3ar3P8LeJe5afGb
17-validate-keywords-symbols.diff - https://www.assembla.com/spaces/clojure/documents/d61sHuVFer3OGKeJe5afGb/download/d61sHuVFer3OGKeJe5afGb

cemerick said: [file:cpC-Qow3ar3P8LeJe5afGb]

cemerick said: [file:cpDbtWw3ar3P8LeJe5afGb]

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

technomancy said: These patches no longer cleanly apply. Working on an updated version.

technomancy said: [file:d61sHuVFer3OGKeJe5afGb]: test and implementation

richhickey said: I just wonder if we can afford the overhead of this validation all the time

richhickey said: Anyone have any bright ideas on how to avoid the overhead?

cemerick said: I'm sure this was brought up a long time ago in prior discussions, but: should validity of symbols and keywords even be defined? Insofar as libraries use them for naming things, especially as read from external representations (e.g. XML, RDF, SGML, etc), it seems like any validation would be an entirely artificial limitation.

For my money, having keywords and symbols print in a failsafe-readable way, e.g. #|symbol with whitespace| (maybe checking at print-time to see if the more common printing is suitable, as would be most common) would:

• guarantee that symbols and keywords are readably printable
• not limit libraries from using keywords and such in very convenient ways
• provide a pleasant shortcut for using symbols and keywords that might not be "valid", but still somehow necessary

Runtime validation off the table for perf reasons. cemerick's suggestion that arbitrary symbol support will render them valid is sound, but arbitrary symbol support is a different ticket/idea.