Re: iterator-seq runs over
Hi Stuart, That fixes the problem, thank you. When I ran the result-set through (type), it showed me that the instance was actually a ResultSetStream. While the Jena ResultSet interface doesn't act as a closable resource, perhaps the stream was being closed once the owning QueryExecution obj was closed via with-open. Rob On Tue, Feb 16, 2010 at 9:55 AM, Stuart Halloway wrote: > Hi Rob, > > map is lazy, count and butlast are not lazy. Does adding a doall around your > call to map fix this problem? > > Stu > >> (map handler (iterator-seq result-set)) always throws a >> NoSuchElementException >> >> (map handler (butlast (iterator-seq result-set))) always works. >> >> (count (iterator-seq result-set)) is returning the correct number of >> elements. Calls to first, second, nth, also work correctly. >> >> When I manually test a result-set of three elements, >> [(handler (.next result-set)) >> (handler (.next result-set)) >> (handler (.next result-set))] >> evaluates correctly, while adding one more .next call results in the >> same NoSuchElementException. >> >> Using butlast fixes the problem, but then I obviously lose the last >> element in the result set. This code is replacing vanilla Java code >> which used .hasNext() and .next() without problem for a couple of >> months, so I doubt it's the class (com.hp.hpl.jena.query.ResultSet) >> incorrectly implementing Iterator. >> >> Has anyone else seen this type of behavior? >> >> Rob >> >> -- >> 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 > > -- > 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 -- 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
Re: iterator-seq runs over
Hi, On Feb 16, 9:55 am, Stuart Halloway wrote: > map is lazy, count and butlast are not lazy. Does adding a doall > around your call to map fix this problem? Argh. butlast is only unlazy of degree one, so to say. Is there a reason why not to provide a lazy version: (defn butlast "Return a seq of all but the last item in coll." [coll] (lazy-seq (let [s (seq coll)] (when-let [r (next s)] (cons (first s) (butlast r)) I see, that butlast is used in the bootstraping early on. But can't there be a bootstrap version, which does not need the whole machinery, and a "production" butlast providing laziness? Or is it not worth the trouble? Sincerely Meikel -- 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
Re: iterator-seq runs over
Hi Rob, map is lazy, count and butlast are not lazy. Does adding a doall around your call to map fix this problem? Stu (map handler (iterator-seq result-set)) always throws a NoSuchElementException (map handler (butlast (iterator-seq result-set))) always works. (count (iterator-seq result-set)) is returning the correct number of elements. Calls to first, second, nth, also work correctly. When I manually test a result-set of three elements, [(handler (.next result-set)) (handler (.next result-set)) (handler (.next result-set))] evaluates correctly, while adding one more .next call results in the same NoSuchElementException. Using butlast fixes the problem, but then I obviously lose the last element in the result set. This code is replacing vanilla Java code which used .hasNext() and .next() without problem for a couple of months, so I doubt it's the class (com.hp.hpl.jena.query.ResultSet) incorrectly implementing Iterator. Has anyone else seen this type of behavior? Rob -- 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 -- 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
iterator-seq runs over
(map handler (iterator-seq result-set)) always throws a NoSuchElementException (map handler (butlast (iterator-seq result-set))) always works. (count (iterator-seq result-set)) is returning the correct number of elements. Calls to first, second, nth, also work correctly. When I manually test a result-set of three elements, [(handler (.next result-set)) (handler (.next result-set)) (handler (.next result-set))] evaluates correctly, while adding one more .next call results in the same NoSuchElementException. Using butlast fixes the problem, but then I obviously lose the last element in the result set. This code is replacing vanilla Java code which used .hasNext() and .next() without problem for a couple of months, so I doubt it's the class (com.hp.hpl.jena.query.ResultSet) incorrectly implementing Iterator. Has anyone else seen this type of behavior? Rob -- 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
