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

Wouldn't the naive approach incur realizing lazy sequences when adding them to a list or a vector or as values in a map?

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.

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.

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

hlship said: Trickier than I thought because cond is really wired into other fundamentals, like let.

cgrand said: Howard, what do you think of http://gist.github.com/432712 ?

Patch cond-let-clauses.diff on 23/Nov/12 adds inline :let clauses to cond, implementing CLJ-200. The code is based off of code by cgrand, with some tweaks so the implementation only relies on constructs defined earlier in core.clj, since when cond is defined, things aren't yet fully bootstrapped. Also added a test to control.clj.

Some comments: the docstring is missing, I believe you don't have to modify the original cond (except the docstring maybe), just redefine it later on once most of the language is defined – a bit like what is done for let for example.

There is still the unlikely eventuality that some code uses :let as :else. What about shipping a cond which complains on keywords (in test position) other than :else?

cond-let-clauses-with-docstring.diff contains the same patches as cond-let-clauses, but includes the original docstring for cond along with an additional sentence about the :let bindings.

Cgrand, I did see your example of redefining cond after most of the language is defined, but since I was able to figure out how to do it in the proper place, that makes the :let bindings available for users of cond downstream and avoids any unforeseen complications that might come from rebinding.

As for your other point, I think it is highly improbable that someone would have used :let in the :else position. However I can imagine someone intentionally using something like :true or :default. I think the idea of warning for other keywords is actually more likely to cause complications than the unlikely problem it is meant to solve.

I did resubmit the patch with the docstring restored. Thanks for pointing out that problem. I'm excited about this patch – I use :let bindings within the cond in my own code all the time. Thanks again for the blog post that started me on that path.

True, it's :unlikely for :let to happen.
However once :let is officially blessed, it may be better to provision for future other "special" keywords and thus to warn on "unsupported" keywords. Plus it will help out-of-order typists (like myself) to catch earlier a :elt instead of a :let
This is only my point of view. Thanks for trying to get :let in cond supported.

Mark, could you remove the obsolete earlier patch now that you have added the one with the doc string? Instructions for removing patches are under the heading "Removing Patches" on this page: http://dev.clojure.org/display/design/JIRA+workflow

Done.

I haven't figured out what is going wrong yet. I can apply the patch cond-let-clauses-with-docstring.diff to the latest Clojure master just fine. I can do "ant jar" and it will build a jar. When I do "ant", it fails with the new test for cond with :let, throwing a StackOverflowException. I can enter that same form into the REPL and it evaluates just as the test says it should. I can comment out that new test and all of the rest pass. But the new test doesn't pass when inside of the control.clj file. Anyone know why?

It's because of the brutal replacement performed by test/are: the placeholders for this are form are x and y but in Mark's test there are used as local names and are tries to substitute them recursively...
If one changes the local names to a and b for example it works.

cond-let-clauses-fixed-test.diff on 02/Dec/12 contains the same patch, but with the x,y locals in the test case changed to a,b so that it works properly in the are clause which uses x and y.

On Windows, I can't get Clojure's test suite task to work, either via ant or maven, which has made it difficult for me to verify the part of the patch that applies to the test suite works as expected; I had tested it as best I could in the REPL, using a version of Clojure built with the patch applied, but using this process, I missed the subtle interaction between are and the locals in the test case. Sorry about that. If someone can double-check that the test suite task now works with the newest patch, that would be great, and then I'll go ahead and remove the obsoleted patch. Thanks.

clj-200-cond-let-clauses-fixed-test-v2-patch.txt dated Dec 2 2012 is identical to Mark Engelberg's cond-let-clauses-fixed-test.diff of the same date, except it applies cleanly to the latest Clojure master.

I've verified that it compiles and passes all tests with latest Clojure master as of this date.

Mark, I've made sure to keep your name in the patch, since you wrote it. You should be able to remove your two attachments now, so the screener won't be confused which patch should be examined.

Mark, besides general issues with Windows not being used much (or maybe not at all?) by Clojure developers, there is the issue right now filed as CLJ-1076 that not all tests pass when run on Windows due to CR-LF line ending differences that cause several Clojure tests to fail, regardless of whether you use ant or maven to run them.

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

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)

this seems like a great task for someone just starting out contributing to clojure.

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

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)

clj-99-min-key-max-key-performance-v1.txt dated Nov 15 2012 changes min-key and max-key to evaluate the function k on each of its other arguments at most once.

Converted from http://www.assembla.com/spaces/clojure/tickets/107
Attachments:
bit-count.diff - https://www.assembla.com/spaces/clojure/documents/dqone2w4er3RbzeJe5afGb/download/dqone2w4er3RbzeJe5afGb

oranenj said: [file:dqone2w4er3RbzeJe5afGb]

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)

clj-107-add-bit-count-v1.txt is probably a correct updated version of the old patch linked above. Added a couple of unit tests.

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

Please see the attached patch which produces a (hopefully more clear) error message as shown below (given the broken code shown in the original bug report):

Clojure 1.4.0-master-SNAPSHOT
user=> (let [x 42 y 43] (+ x y))
85
user=> (let [[x y] {}] x)
UnsupportedOperationException left side of binding must be a symbol (found a PersistentVector instead).  clojure.lang.Compiler.checkLet (Compiler.java:6545)
user=>

In addition, this patch checks the argument of (let) as shown below:

user=> (let 42)
UnsupportedOperationException argument to (let)  must be a vector (found a Long instead).  clojure.lang.Compiler.checkLet (Compiler.java:6553)

Patch produced by doing git diff against commit ba930d95fc (master branch).

Sorry, this patch is wrong: it assumes that the left side of the binding is wrong - the [x y] in :

(let [[x y] {}] x)

because [x y] is a vector, when in fact, the left side is fine (per http://clojure.org/special_forms#let : "Clojure supports abstract structural binding, often called destructuring, in let binding lists".)

So it's the right side (the {}) that needs to be checked and flagged as erroneous, not the [x y].

Add patch better-error-for-let-vector-map-binding

This produces the following:

(let [[x y] {}] x)
Exception map binding to vector is not supported

There are other cases that are not handled by this though — like binding vector to a set

user=> (let [[x y] #{}] x)
UnsupportedOperationException nth not supported on this type: PersistentHashSet

Wondering if it might be better to try convert the map to a seq to support? Although this might be another issue.

Thoughts?

This seems too specific. Is this issue indicative of a larger problem that should be addressed? Even if this is the only case where bindings produce poor error messages, all the cases described above should be addressed in the patch.

Unfortunately, realized that this still does not cover the nested destructuring cases. Coming to the conclusion, that my approach above is not going to work for this.

File: clj-5-destructure-error.diff

Added support for nested destructuring errors

let [[[x1 y1][x2 y2]] [[1 2] {}]]
;=> UnsupportedOperationException let cannot destructure class clojure.lang.PersistentArrayMap.

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

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

Converted from http://www.assembla.com/spaces/clojure/tickets/190
Attachments:
clojure-190-with-open.patch - https://www.assembla.com/spaces/clojure/documents/ca27R6Ojur3PQ0eJe5afGb/download/ca27R6Ojur3PQ0eJe5afGb

mikehinchey said: [file:ca27R6Ojur3PQ0eJe5afGb]: fix adds close method and tests

mikehinchey said: Note, I only defined methods for :default (reflection of .close) and Closeable, not sql or the numerous other classes in java that should be Closeable but are not. Maybe clojure.contrib.sql and other such libraries should define related close methods.

richhickey said: I want to hold off on this until scopes are in

Probably better implemented using a protocol. See http://dev.clojure.org/jira/browse/CLJ-308

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

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.

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])

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.

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

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.

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.

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 ...)?

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

scgilardi said: It's saying that the symbol com.howardlewisship.cascade.test-views/write already resolves to #���clojure.contrib.pprint/write, so you can't def a new write in com.howardlewisship.cascade.test-views.

What do you propose for an alternate wording of the error message here?

I think the issue is that only one side of the conflict is reported in the error, so if you get this kind of error in the middle of a large project it can be hard to figure out which namespace is conflicting. Take a toy example:

user=> (ns foo)
foo=> (def foobar 42)
foo=> (ns bar)
bar=> (def foobar 0)
bar=> (ns problem)
problem=> (refer 'foo)
problem=> (refer 'bar)
java.lang.IllegalStateException: foobar already refers to: #'foo/foobar in namespace: problem (NO_SOURCE_FILE:0)

In this case it would be best if the error said something like:

"Conflict referring to #'bar/foobar in #<Namespace problem> because foobar already refers to: #'foo/foobar."

This way the error message clearly identifies the location of the conflict, and the locations of the two conflicting vars.

Hopefully this helps clarify. I think I see where to fix it in warnOrFailOnReplace on line 88 of src/jvm/clojure/lang/Namespace.java, and this reminds me I need to send in a CA so I can pitch in next time...

It looks like the true conflict is in test-views, not in dom. A small example of the line number breakage showing the problem on master (1.3) would be very helpful.

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.

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

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

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

richhickey said: Updating tickets (#127, #128, #129, #130)

juergenhoetzel said: This is still a issue on

Clojure 1.2.0-master-SNAPSHOT

Any progress, hints? I prefer interactive documentiation via slime/repl

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

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

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

donmullen said: Added ticket on clojure-contrib-99

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