Thanks, Jürgen. I think you are saying that there is no difference with respect to laziness between my approach and Ken's literal, so I can remove that from consideration as the cause of my problem. I have looked at my repl session pretty closely and do not think that I clobbered any of the variables in any way as I was experimenting, but now that seems like the most likely explanation.
On Oct 25, 2:42 pm, Jürgen Hötzel <juer...@hoetzel.info> wrote: > 2010/10/25 Tim Webster <timothy.webs...@gmail.com>: > > > I thought that the issue might be that the concrete data still was not > > populated in my list-of-lists, unlike your literal, so I started with > > a clean environment and re-ran my repl session line by line from the > > jline history file. I could not reproduce the error. (Which troubles > > me even more...the error had to come from somewhere.) > > > For the record, here is how I build the table: > > > (def data (slurp "data.txt")) > > (def lines (. data split "\n")) > > (def my-table (map #(. % split "\t") lines)) > > You don't leverage laziness here: The whole file is read into the > java String "data" and "line" is just a primitive Java Array of > Strings realized all at once: This may cause OutOfMemoryError on > large files and is not required in your use case. Consider to use of > "line-seq": > > (with-open [f (reader "data.txt")] > (->> (line-seq f) > (map #(split % #"\t")) > (map second) > frequencies)) > > Jürgen -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
