<< Back to previous view

[TRDR-1] read-char returns nil for some input types, on first attempt to read a char Created: 12/Feb/13  Updated: 01/Aug/13  Resolved: 12/Feb/13

Status: Closed
Project: tools.reader
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Andy Fingerhut Assignee: Andy Fingerhut
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File trdr-1-correct-read-char-v1.txt    
Patch: Code

 Description   

The return value from Java's .read method is -1 for EOF. A couple of condition checks in the code appear to be reversed. See the patch.



 Comments   
Comment by Nicola Mometto [ 12/Feb/13 4:47 PM ]

Thanks, tests for reader-types are now on the TODO list





[TRDR-7] Anonymous variadic fn arg not read properly Created: 12/Aug/13  Updated: 14/Aug/13  Resolved: 14/Aug/13

Status: Closed
Project: tools.reader
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Chas Emerick Assignee: Nicola Mometto
Resolution: Completed Votes: 0
Labels: None

Patch: Code and Test

 Description   

Compare clojure.core/read-string:

user=> (read-string "#(last %&)")
(fn* [& rest__461#] (last rest__461#))

vs. clojure.tools.reader/read-string:

user=> (reader/read-string "#(last %&)")
(fn* nil (last rest__458#))

The most immediate manifestation of this is that anonymous function forms in ClojureScript >= 0.0-1853 will not compile. I'm filing an issue to track this there as well.



 Comments   
Comment by Nicola Mometto [ 14/Aug/13 9:44 AM ]

Sorry for the delay, fixed with https://github.com/clojure/tools.reader/commit/8f48f83a5ad0dbd7f4c8e612c4ab764d418feb93

I'm releasing 0.7.6 ASAP





[TRDR-8] Fix for parsing of tagged literals Created: 12/Sep/13  Updated: 13/Sep/13  Resolved: 13/Sep/13

Status: Closed
Project: tools.reader
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Alex Coventry Assignee: Nicola Mometto
Resolution: Completed Votes: 0
Labels: bug, patch

Attachments: Text File 0001-Fix-for-ctor-reading.patch     Text File reader.patch    
Patch: Code
Approval: Ok

 Description   

Parsing of tagged literals fails at the moment, e.g.

user> (require '[clojure.tools.reader :as r] :reload) (r/read-string "#java.lang.String[\"Hi\"]")
nil
ArrayIndexOutOfBoundsException 15 clojure.lang.RT.aget (RT.java:2239)

Attached patch corrects this problem, and brings the clojure logic in line with what's in LispReader.java



 Comments   
Comment by Nicola Mometto [ 13/Sep/13 7:18 AM ]

Thanks for the patch, can you post a patch that is the result of git format-patch so that we can keep your authorship on the commit?
(apply the patch, git add <path/to/reader.clj>, git commit -m "Fix ctor reading", git format-patch origin/master)

Also, can you please put the result of (count entries) in the let so that we compute it only once?

Thanks

Comment by Alex Coventry [ 13/Sep/13 12:06 PM ]

No worries, Nicola. I've attached a revised patch.

Best regards,
Alex

Comment by Nicola Mometto [ 13/Sep/13 12:38 PM ]

fixed https://github.com/clojure/tools.reader/commit/d9374f90448a4ff52ad83a2b75be2fa520a24db8





[TRDR-11] Stack overflow on whitespace in reader/read and edn/read Created: 05/Dec/13  Updated: 05/Dec/13  Resolved: 05/Dec/13

Status: Closed
Project: tools.reader
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Paul Michael Bauer Assignee: Nicola Mometto
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File fix_stack_overflow_in_reader.patch    
Patch: Code

 Description   

reader/read and edn/read call themselves recursively for several encountered character classes - whitespace, comments.
This is high-risk for stack overflow, especially for machine-generated data.

Motivating Use Case: cljs files generated via cljx are particularly prone to trigger tools.reader stack overflow errors. Cljx replaces un-included forms with homomorphic whitespace blocks to preserve line number and column errors on compilation.



 Comments   
Comment by Nicola Mometto [ 05/Dec/13 3:50 PM ]

Fixed: https://github.com/clojure/tools.reader/commit/01b53cb61b586e78cf3f70f12ba2adbbdb7abb25

Thanks, I took the liberty of changing the commit description.

Comment by Paul Michael Bauer [ 05/Dec/13 3:53 PM ]

Thanks for changing the commit message. facepalm
Missed that when I generated the patch





[TRDR-15] tools.reader 0.8.4 causes clojurescript to stop working in mysterious ways Created: 03/Jun/14  Updated: 04/Jun/14  Resolved: 04/Jun/14

Status: Closed
Project: tools.reader
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: James Cash Assignee: Nicola Mometto
Resolution: Declined Votes: 0
Labels: bug, cljs
Environment:

OS X 10.9.3, Java 1.8, Clojure 1.6.0



 Description   

If tools.reader 0.8.4 is included in a project's dependencies, then clojurescript fails to work in a browser, with the error that cljs.core.PersistentArrayMap is undefined. I have created a sample project demonstrating this at https://github.com/jamesnvc/cljs-toolreader-debugging.

I also apologize that I'm not sure if this is a problem in tools.reader or clojurescript. If there is a better place for me to report this issue, please let me know!



 Comments   
Comment by Nicola Mometto [ 04/Jun/14 3:33 AM ]

This is a bootstrap issue in clojurescript.
tools.reader 0.8.4 introduced :file metadata, clojurescript needs to dissoc it here https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/analyzer.clj#L1490 to work with this version.

I suggest you open a ticket in che clojurescript jira making that change if you want to make clojurescript work with 0.8.4

Comment by James Cash [ 04/Jun/14 9:04 AM ]

Thank you very much Nicola, I opened the issue on the clojurescript JIRA





[TRDR-16] Reading Anonymous fns without arguments throws NPE Created: 20/Jun/14  Updated: 20/Jun/14  Resolved: 20/Jun/14

Status: Closed
Project: tools.reader
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Jozef Wagner Assignee: Nicola Mometto
Resolution: Declined Votes: 0
Labels: None


 Description   

This throws:

(clojure.tools.reader/read-string "#()")


 Comments   
Comment by Jozef Wagner [ 20/Jun/14 3:31 PM ]

It works when I used most recent master from repo. My bad, you can close this ticket. Sorry.





[TRDR-5] Additional "Differences from LispReader.java" for README Created: 08/Apr/13  Updated: 10/Apr/13  Resolved: 10/Apr/13

Status: Closed
Project: tools.reader
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Andy Fingerhut Assignee: Nicola Mometto
Resolution: Completed Votes: 0
Labels: None


 Description   

Suggested addition to "Differences from LispReader.java" section of README.md:

read is capable of reading the symbol / with an explicit namespace, e.g. foo//, whereas clojure.lang.LispReader/read throws an exception. Refer to CLJ-873. Except for this special case, read throws an exception if a symbol contains more than one / character, whereas clojure.lang.LispReader/read allows them, returning a symbol with one or more / characters in its namespace name.



 Comments   
Comment by Nicola Mometto [ 10/Apr/13 5:20 AM ]

Thanks, fixed https://github.com/clojure/tools.reader/commit/f689cb283d1fb539a6cabbefd4036f620dabe693





[TRDR-6] Some uses of reflection in tools.reader code slow it down unnecessarily Created: 13/Apr/13  Updated: 13/Apr/13  Resolved: 13/Apr/13

Status: Closed
Project: tools.reader
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Andy Fingerhut Assignee: Nicola Mometto
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File trdr-6-eliminate-reflection-with-type-hints-patch-v1.txt    
Patch: Code

 Description   

Attached patch uses type hints to eliminate several instances of reflection in the tools.reader code.

FYI, you can run 'lein check' to cause Leiningen to compile the code with warn-on-reflection true, I believe for every source file (not sure about the tests, but reflection isn't such a big deal in them anyway).



 Comments   
Comment by Nicola Mometto [ 13/Apr/13 12:13 PM ]

Andy, I don't see any patch attached to this ticket, I think you forgot to attach it.

(P.S. thanks, I didn't know about 'lein check')

Comment by Andy Fingerhut [ 13/Apr/13 12:19 PM ]

Patch trdr-6-eliminate-reflection-with-type-hints-patch-v1.txt dated Apr 13 2013 eliminates all occurrences of reflection found in latest version of tools.reader. Please check them carefully before committing them, especially the ones in default_data_readers.clj.

And I know the reflection warnings in default_data_readers.clj exist in Clojure's code, too, where you copied those from. CLJ-1080 has a patch addressing those and many other reflections within Clojure's code.

Comment by Nicola Mometto [ 13/Apr/13 12:59 PM ]

Andy, casting to char makes tools.reader crash under clojure-1.3, apparently casting to char is possible only from clojure 1.4.

Could you please submit a patch removing reflection in default_data_readers.clj and the docstring fixes only while I try to figure out a way to maintain clojure 1.3 compatibility and remove the reflection? (or if you have an idea on how to do it, you're more than welcome )

EDIT:
I edited your patch manually, and pushed a commit to type hint to char only for >clojure-1.3.0
I don't know if there is a way to avoid the reflection from clojure 1.3.0, but for the all the other versions of clojure all reflection is gone, thanks!

Comment by Andy Fingerhut [ 13/Apr/13 2:43 PM ]

Great. I was off-line there for a while, but glad you noticed the 1.3 compatibility issue where I didn't, and glad you found a different way to eliminate reflection with 1.4 and later.





[TRDR-3] Make read-line available in clojure.tools.reader and/or clojure.tools.reader.edn namespace? Created: 15/Mar/13  Updated: 15/Mar/13  Resolved: 15/Mar/13

Status: Closed
Project: tools.reader
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Andy Fingerhut Assignee: Nicola Mometto
Resolution: Completed Votes: 0
Labels: None


 Description   

You mention the enhanced version of read-line that takes a reader argument in the README, but it seems like it is only available in the clojure.tools.reader.reader-types namespace. Is that intentional? Perhaps making it available in the clojure.tools.reader and/or clojure.tools.reader.edn namespace might be more convenient for the user of the library? I understand that the current implementation of read-line is Java-specific, so maybe this is the only reasonable way to expose it.

In any case, documenting the namespace in which this enhanced read-line is available in the README would be good.



 Comments   
Comment by Nicola Mometto [ 15/Mar/13 10:26 AM ]

I added more documentation on the readme, making it clear in which namespace read-line is defined.
(https://github.com/clojure/tools.reader#public-api, https://github.com/clojure/tools.reader#differences-from-lispreaderjava)

read-line definitely belongs in the c.t.r.reader-types namespace, since it works on reader-types and returns a string, so it's not a reader function.

I hope this addresses this ticket, I'm closing it, feel free to reopen it you think the doc needs to be more clear.

Comment by Andy Fingerhut [ 15/Mar/13 7:04 PM ]

Looks thoroughly documented to me – above and beyond what I would have asked for. Thanks.





[TRDR-2] Fix a few README typos Created: 14/Feb/13  Updated: 01/Aug/13  Resolved: 15/Feb/13

Status: Closed
Project: tools.reader
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Andy Fingerhut Assignee: Nicola Mometto
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File trdr-2-fix-readme-typos-patch-v1.txt    
Patch: Code

 Description   

There are a few typos in the README



 Comments   
Comment by Andy Fingerhut [ 14/Feb/13 3:16 PM ]

Nothing major here. Just a few typo fixes for the README that I found.

Comment by Nicola Mometto [ 15/Feb/13 4:19 AM ]

Thanks, applied





[TRDR-10] Add end-line and end-column metadata to read objects Created: 25/Oct/13  Updated: 08/Nov/13  Resolved: 06/Nov/13

Status: Closed
Project: tools.reader
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Alexander Redington Assignee: Alexander Redington
Resolution: Completed Votes: 0
Labels: None

Attachments: File TRDR-10-line-numbering.diff    
Patch: Code and Test

 Description   

Per TRDR-9, add end-line and end-column metadata information to every form read, when the underlying reader implements the IndexingReader protocol.



 Comments   
Comment by Alexander Redington [ 25/Oct/13 12:03 PM ]

Patch to include end-line and end-column numbers on all forms read, with tests.

Comment by Nicola Mometto [ 06/Nov/13 3:26 PM ]

Applied to master: https://github.com/clojure/tools.reader/commit/a7251e87c5530e04c3c7c4a983f30030f38730df

I'm sorry I didn't apply this earlier but JIRA didn't send me an email notifying me that you updated the patch even though I am watching the issue.

Comment by Alexander Redington [ 08/Nov/13 7:31 AM ]

I've only been working on this in Friday time, and even that has been sporadic, so nothing to worry about!

Working with you on this has been excellent, thanks for accepting the suggestions and patches!





[TRDR-9] Add more source metadata to read objects Created: 27/Sep/13  Updated: 02/Sep/14  Resolved: 20/Nov/13

Status: Closed
Project: tools.reader
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Alexander Redington Assignee: Alexander Redington
Resolution: Completed Votes: 0
Labels: None

Attachments: File TRDR-9-source-logging.diff    
Patch: Code and Test

 Description   

I'm working on a static analyzer for Clojure, where I'd like to have a reader which provides precise form coordinates and source representations.

Specifically this enables analyses where it's straightforward to bind an object like:

(fn* [p1__3615#] (inc (conj p1__3615#)))

to the source form which it was read from:

"#(inc (conj %))"

Would this kind of functionality be considered appropriate to tools.reader? Specifically I'd like to make a change such that

  • Read data is unchanged
  • When an IMeta is read, additional information is embedded in the metadata, but no existing metadata is changed
  • The additional metadata would include the source character string, the ending column, and the ending line from the source stream

As an example, reading a stream that contained the following on the first line:

#(inc (conj %))

Would return a list as follows:

(fn* [p1__3615#] (inc (conj p1__3615#)))

And would change the metadata from:

{:line 1, :column 1}

to augment it with more metadata, as follows:

{:line 1, :column 1, :end-line 1, :end-column 15, :source "#(inc (conj %))"}

I'd happily contribute a patch to include this behavior if you'd be inclined to accept it. I'd like to first see if it would be considered appropriate, and also discuss any other concerns you might have (such as having this behavior be optionally enabled, etc)



 Comments   
Comment by Nicola Mometto [ 28/Sep/13 1:48 PM ]

I would definitely take a patch to add such a behaviour, with the condition that this should not degrade the performances too much (a 2x slowdown would be acceptable though).

I don't feel like this needs to be optional behaviour, we already provide column/line info by default, if it's not needed the user might just ignore it.

Comment by Alexander Redington [ 18/Oct/13 12:49 PM ]

Just like to touch base as I've been quiet for a little while, but haven't forgotten about this. It's been my primary goal on Friday time.

I currently have a naive implementation that works, but blows our performance goal by a 5x factor. I think this is solvable with a little more finesse in source logging.

It appears that end-line and end-column information can be obtained for almost no additional computational cost. (less than 2% additional processor time).

I've committed my WIP to: https://github.com/aredington/tools.reader/tree/metadata-logging

Also worth discussing at some point in time: some tests around syntax quoting and metadata reading start failing. For syntax quote, the forms returned are significantly more verbose, including metadata assertions with the source attribution. For metadata, the metadata values read now have an additional :source key included that specifies the source string the forms were read from. In both cases, the expectations of the tests are violated, but I'm not inclined to say that the end result is incorrect without discussion.

Comment by Nicola Mometto [ 22/Oct/13 11:57 AM ]

Awesome, I haven't had a chance to read through the implementation but I'll do so as soon as possible.
If I'm reading the last commit message correctly, it looks like since your comment here you were able to reduce performance loss to 2x, that's cool.

Can you please make the end-line/end-column modifications into another ticket? I can merge that as soon as you upload the patch.

Regarding the failing tests – looks like those are inevitable, it's definitely not a bug and those tests should be fixed to match the new behaviour (fixing those should be just a matter of manually attatching the :source metadata to the forms to be read by the clojure reader)

Comment by Nicola Mometto [ 24/Oct/13 11:39 AM ]

After some more thoughts, I think it should be better to have a "InfoPushBackReader" (not sure if it's the best name) wrapping an IndexingPushBackReader that provides source data, this way we only get the performance hit when we effectively need the :source info instead of making every Reader collect source data even when we don't want/need it.

Would this approach work for your use case?

Comment by Alexander Redington [ 25/Oct/13 8:04 AM ]

Absolutely. I'll make two patches and we will have two paths for metadata:

  • Default case; if line numbering information is available, end-line and end-column will be captured. The performance hit from this is marginal (2-3% slower), but it does provide sufficient information for, e.g. editors, IDEs to precisely indicate what portions of a source file originate what forms. This patch will be submitted in a new ticket.
  • Enhanced case; using a new InfoPushbackReader (SourceInfoPushbackReader? SourceLoggingPushbackReader?) we'll log precise source information on each form read. The performance hit from this will be substantial (100% slower), but it isolates the performance impacts to those users who deliberately want more information and are willing to pay the performance cost. This patch will be attached to this issue (TRDR-9)
Comment by Alexander Redington [ 25/Oct/13 8:27 AM ]

Created TRDR-10 for end-line and end-column info.

Comment by Nicola Mometto [ 06/Nov/13 4:04 PM ]

Looks like CLJS will also beenfit from this, see http://dev.clojure.org/jira/browse/CLJS-658

+1 for SourceLoggingPushbackReader

Comment by Alexander Redington [ 15/Nov/13 1:35 PM ]

On https://github.com/aredington/tools.reader I have it nearly working save that nested collections (e.g. [1 2 [3 4 5]]) fail to read correctly.

The top collection will read correctly with the following as the source string: "[1 2 [3 4 5]]", the nested vector reads as "3 4 5]".

I tried taking the macro dispatching char and prepending it to the source log at the appropriate source logging frame, and that resolves nested collections, but causes metadata to read erroneously, e.g. {:foo :baz} 'zot will read with source string "^{:foo :baz} 'zot".

Gonna keep digging to try and resolve this because source logging is very close, but just wanted to update on current status as I'd been quiet for a while.

Comment by Nicola Mometto [ 15/Nov/13 8:02 PM ]

I'll take a look at your current implementation and see if I can help you spot what's going wrong, thanks again for the effort you're putting into this.

Comment by Nicola Mometto [ 16/Nov/13 8:49 AM ]

I opened a pull request https://github.cam/aredington/tools.reader/pull/1 that should fix all the issues you were having, as well as fixing another minor bug.

If you find my edits reasonable please merge it and then squash the commits and I'll merge the patch upstream

Comment by Alexander Redington [ 20/Nov/13 1:23 PM ]

Squashed commit with working source logging

Comment by Nicola Mometto [ 20/Nov/13 3:17 PM ]

Fixed: https://github.com/clojure/tools.reader/commit/f9e55071d82a443db3fac1c2feda059d0215bb90

Thanks

Comment by Nikita Beloglazov [ 02/Sep/14 3:40 PM ]

As I see current tools.reader still not able to return position info (line, column numbers) for strings, numbers, booleans and other primitives that don't implement IMeta interface. Is there plans to fix it somehow? I was thinking how it can be fixed and only idea I came up with was to read input data into intermediate datastructure like:

{:type :vector
:children [{:type :string
:value "hello"
:line 1
:column 2}]
:line 1
:column 4}

And then convert it to clojure datastructures: ["hello"] so changes are invisible from outside. Additionally you can pass additional option like :raw-format true and it will return those internal datastructure.

Would it be the change that will be accepted or is it too drastic? I can start working it. I think this functionality is really needed for libraries linter-like libraris that checks whether code is formatted correctly and need to know position of each lexem.

Comment by Nicola Mometto [ 02/Sep/14 4:21 PM ]

I thought about this issue a while ago and I'd be definitely more than happy to take a patch for this.
What I'd like to see is a tools.reader.parser namespace with a parse function that returns a parse tree, and then tools.reader be just a compiler from that parse tree back to clojure, however I'm worried about the performance implications of that; I've deliberately avoided writting tools.reader with multimethods in favour of direct dispatch via `case` for performance reasons, this would probably involve an unacceptable performance hit.

So probably keeping the parser and the reader separated, even at the cost of having to copy&paste most of the current implementation is the way to go; obviously if you want to try to unify the two feel free to do so.

Can you open a new enhancement ticket for this?





[TRDR-17] tools.reader bug demonstrated when syntax quote contains map with key :val Created: 02/Nov/14  Updated: 03/Nov/14  Resolved: 03/Nov/14

Status: Closed
Project: tools.reader
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Andy Fingerhut Assignee: Nicola Mometto
Resolution: Completed Votes: 0
Labels: None


 Description   

Steps to reproduce with latest tools.reader 0.8.11:

user=> (require '[clojure.tools.reader :as tr])
nil
user=> (tr/read-string "(defn foo [x] `{:val x})")
UnsupportedOperationException count not supported on this type: Symbol  clojure.lang.RT.countFrom (RT.java:602)

From the partial investigation I've done so far, it appears this happens if a map inside of a syntax quote expression has a key :val. It looks like the wrong map is being passed to map-func, or even higher up the call stack, or perhaps map-func should be using coll in place of (:val coll).



 Comments   
Comment by Nicola Mometto [ 03/Nov/14 7:00 AM ]

Thanks, fixed: https://github.com/clojure/tools.reader/commit/c8758b958c3683a2e66cc6537448276082b2191e





[TRDR-4] Typo: Change 'end' to 'edn' in 'clojure.tools.reader.end/read-string' in README Created: 15/Mar/13  Updated: 15/Mar/13  Resolved: 15/Mar/13

Status: Closed
Project: tools.reader
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Trivial
Reporter: Andy Fingerhut Assignee: Nicola Mometto
Resolution: Completed Votes: 0
Labels: None


 Description   

Just a miniscule typo



 Comments   
Comment by Nicola Mometto [ 15/Mar/13 9:50 AM ]

Fixed, thanks





[TRDR-12] Misplaced doc string for function newline? Created: 23/Dec/13  Updated: 23/Dec/13  Resolved: 23/Dec/13

Status: Closed
Project: tools.reader
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Trivial
Reporter: Andy Fingerhut Assignee: Nicola Mometto
Resolution: Completed Votes: 0
Labels: None

Attachments: File trdr-12-v1.diff    

 Description   

Found using Eastwood



 Comments   
Comment by Nicola Mometto [ 23/Dec/13 7:06 PM ]

Fixed: https://github.com/clojure/tools.reader/commit/1c9633400fdfdf6852d355edd9c44a721b0938ae





[TRDR-18] A couple of typos in doc strings Created: 21/Nov/14  Updated: 22/Nov/14  Resolved: 22/Nov/14

Status: Closed
Project: tools.reader
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Trivial
Reporter: Andy Fingerhut Assignee: Nicola Mometto
Resolution: Completed Votes: 0
Labels: None


 Description   

Two occurrences of SourceLoggingReader should probably be replaced with SourceLoggingPushbackReader ?



 Comments   
Comment by Nicola Mometto [ 22/Nov/14 11:56 AM ]

Fixed thanks https://github.com/clojure/tools.reader/commit/ececc05cd8d505cc5f4ff9cee408e202b6cbf402





Generated at Mon Nov 24 20:00:10 CST 2014 using JIRA 4.4#649-r158309.