Fork me on GitHub

is it expected? (i am fairly sure it used to work, the <type>Range optimisations probably broke this)


I guess it should work as the docstring for range says "Returns a lazy seq of ..." even tho it's not really a lazyseq anymore

Alex Miller (Clojure team)12:09:20

range automatically realizes the first chunk so it's answering truthfully

Alex Miller (Clojure team)12:09:56

Oh sorry, I'm not awake yet :)

Alex Miller (Clojure team)12:09:21

You're right in that it's not lazy


yeah, both docstrings mention lazy-seqs, sounds/looks like a bug caused by optimisations

Alex Miller (Clojure team)12:09:30

Or at least not like it was


or one of the docstrings should be updated

Alex Miller (Clojure team)12:09:08

It's not a bug as much as realized? Not being as useful as it could be imo

Alex Miller (Clojure team)12:09:44

It would be better if realized? returned true if not lazy

Alex Miller (Clojure team)12:09:02

There is a ticket for this I think


that too, but something lazy as a (range ...) should work like it used to imho, the end user don't care that it's was optimised at some point

Alex Miller (Clojure team)12:09:16

I don't find that using realized? on lazy seqs is particularly helpful ever


me neither, I just used it to test something (see in #clojure the issue with c.c.jdbc)


something else I am trying to update a large'ish project to 1.9 from 1.8 and I get this weird error when I try to launch a repl: Exception in thread "main" java.lang.NoClassDefFoundError: clojure/core$second__4347, compiling:(controller.clj:1:1) I have no clue why so far. really odd (I tried alpha 1, 12, 13, same result)


same if I lein run


depending on the alpha I include it breaks on "second" or "seq?" ... wtf


ok, for posterity: that was caused by "direct-linked" dependency, if anyone ever encounters the same pb. Now I ll shut up troll


FWIW I have a similar issue that occasionally is thrown from a shutdown hook when my project is aot-compiled using direct linking: java.lang.NoClassDefFoundError: com/stuartsierra/component$update_system_reverse$fn__1373


I have had no luck reproducing a simple test case, alas