OK, so you get a fully realized sequence back from that so there’s no question
of “losing the database context”: query is self-contained. However, you _do_
get a LazySeq even tho’ it is fully realized – that actually surprised me but I
tried it on a simple example:
boot.user=> (type (map
really alive."
> -- Margaret Atwood
>
>
>
> *From: *lawrence...@gmail.com
> *Sent: *Tuesday, July 11, 2017 1:18 PM
> *To: *Clojure
> *Subject: *Re: I can only get the first item of a lazyseq via a Manifold
> stream, and I can't get/find an Exception
>
>
>
>
t: Tuesday, July 11, 2017 1:18 PM
To: Clojure<mailto:clojure@googlegroups.com>
Subject: Re: I can only get the first item of a lazyseq via a Manifold stream,
and I can't get/find an Exception
Justin, thanks. I'd like to ask a follow up question. To be clear, if I go into
(doseq) then t
;>>>> ;; 2017-07-10 -- we want a thread pool. I'm arbitrarily choosing 200
>>>>>> threads.
>>>>>> ;; query_database/start will pull data from the database and dump it
>>>>>> onto a
>>>>>> ;; stream below, at which point ea
t;> threads.
>>>>> ;; query_database/start will pull data from the database and dump it
>>>>> onto a
>>>>> ;; stream below, at which point each row should be assigned to one of
>>>>> the rows
>>>>> ;; on our thread pool.
&g
nce-from-database]
>>>> (slingshot/try+
>>>>(println "the type of the object from the database: " (type
>>>> sequence-from-database))
>>>>(->> (ms/->source sequence-from-database)
>>>> (ms/onto executor)
&
>>> [sequence-from-database]
>>> (slingshot/try+
>>>(println "the type of the object from the database: " (type
>>> sequence-from-database))
>>>(->> (ms/->source sequence-from-database)
>>> (ms/onto executor
e object from the database: " (type
>> sequence-from-database))
>>(->> (ms/->source sequence-from-database)
>> (ms/onto executor)
>> (ms/map api/query))
>>(catch Object o
>> (println " message queue is not happy about
> given")
> (errors/error o "" " we tried to put something on the message queue,
> but we got an error "
>
> The line where I print out the type assures that I'm dealing with a
> LazySeq.
>
> The code prints out the type and the first row:
happy about the message we were given")
(errors/error o "" " we tried to put something on the message queue,
but we got an error "
The line where I print out the type assures that I'm dealing with a LazySeq.
The code prints out the type and the first
n what you’re doing, you might get by with just counted? which is
true for literal lists and vectors, but false for conses and lazy collections.
> On Oct 18, 2015, at 5:55 PM, Brian Marick <mar...@exampler.com> wrote:
>
> Is there a way to tell if `v` is a lazyseq
expect a seq to be a lazy seq. Also, there are some really weird rules
around chunked seqs, lazy seqs, and cons cells. Overall testing for a
LazySeq is probably more trouble than it's worth.
--
You received this message because you are subscribed to the Google
Groups "Clojure" grou
Is there a way to tell if `v` is a lazyseq other than `(instance?
clojure.lang.LazySeq v)`? Seems like there should be, but I'm not seeing it.
[Preparing to say "duh!"]
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post
realized? throws when passed something that's not IPending. Lazy seqs (but not
all seqs) implement IPending, thus the vast majority of realized? users already
have an if check prior to making the call. Any code of that form continues to
work. I think it would be a better idea if realized? did
On Friday, July 31, 2015 at 9:04:45 AM UTC-4, Alex Miller wrote:
We're focusing on defects right now for 1.8 but eventually we'll roll back
around to enhancements too.
On Fri, Jul 31, 2015 at 5:04 AM, Marc O'Morain ma...@circleci.com
javascript: wrote:
This caught us out at Circle when
On Sunday, August 2, 2015 at 2:40:55 PM UTC-4, Alex Miller wrote:
realized? throws when passed something that's not IPending. Lazy seqs (but
not all seqs) implement IPending, thus the vast majority of realized? users
already have an if check prior to making the call. Any code of that form
By the way, -- When is it useful to know whether a lazy sequence has been
realized?
--
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
On Sunday, August 2, 2015 at 4:05:02 PM UTC-5, Matching Socks wrote:
By the way, -- When is it useful to know whether a lazy sequence has been
realized?
I don't know what people do with it in production code, but one reason you
might want to know would be that you have a lazy sequence that
We're focusing on defects right now for 1.8 but eventually we'll roll back
around to enhancements too.
On Fri, Jul 31, 2015 at 5:04 AM, Marc O'Morain m...@circleci.com wrote:
This caught us out at Circle when preparing the code-base for Clojure 1.7
– which reminds me of
This caught us out at Circle when preparing the code-base for Clojure 1.7 –
which reminds me of http://dev.clojure.org/jira/browse/CLJ-1752
It would be very nice if `reliased?` returned true for values that are not
instances of IPending
On 31 July 2015 at 03:51, Mars0i marsh...@logical.net
Yes, this behavior has changed.
--
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
OK, thanks.
(I didn't have a real use case. It's useful for experimenting at the
prompt.)
On Thursday, July 30, 2015 at 7:30:46 PM UTC-5, Alex Miller wrote:
Yes, this behavior has changed.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post
Also, (realized? (range)) is true in 1.7.0, but false in 1.6.0.
(realized? (rest (range))) is false in 1.7.0 but throws an exception in
1.6.0, fwiw.
On Thursday, July 30, 2015 at 11:16:03 AM UTC-5, Mars0i wrote:
In Clojure 1.6.0, *range* returned a LazySeq, which could be tested
In Clojure 1.6.0, *range* returned a LazySeq, which could be tested with
*realized?*. In Clojure 1.7.0 and 1.8.0-alpha3, it returns an Iterate, a
Range, or a LongRange*. * realized? only works with the first of these
three. For example:
Clojure 1.6.0:
user= (class (range 5
It was a bug in kerodon that happens when a ring response has a :body
that is a not a string (in this case a lazyseq). Reported and fixed by
Travis Vachon at https://github.com/xeqi/kerodon/pull/6, I just had
lost track of making a release for it.
Fixed as part of [kerodon 0.1.0
groups lawrencecloj...@gmail.com
wrote:
It was a bug in kerodon that happens when a ring response has a :body
that is a not a string (in this case a lazyseq). Reported and fixed by
Travis Vachon athttps://github.com/xeqi/kerodon/pull/6, I just had
lost track of making a release for it.
Fixed
I was trying to follow this video, which adds some nice tests for
Friend:
http://www.clojurewebdevelopment.com/videos/friend-interactive-form
But Kerodon gives me an error, and points to line 13 of my test code:
ERROR in (anyone-can-view-frontpage) (impl.clj:73)
Uncaught exception, not in
Hmm, even stranger. If I wrap app in doall in an attempt to make the
lazyseq error go away, I get:
ERROR in (anyone-can-view-frontpage) (RT.java:494)
Uncaught exception, not in assertion.
expected: nil
actual: java.lang.IllegalArgumentException: Don't know how to create
ISeq from
)
clojure.core/seq (core.clj:133)
clojure.core/dorun (core.clj:2780)
random.learning.backtick.backtick1/eval2879 (NO_SOURCE_FILE:1)
On Tue, Feb 19, 2013 at 11:30 PM, larry google groups
lawrencecloj...@gmail.com wrote:
Hmm, even stranger. If I wrap app in doall in an attempt to make the
lazyseq
:
Hmm, even stranger. If I wrap app in doall in an attempt to make the
lazyseq error go away, I get:
ERROR in (anyone-can-view-frontpage) (RT.java:494)
Uncaught exception, not in assertion.
expected: nil
actual: java.lang.IllegalArgumentException: Don't know how to create
ISeq from
It was a bug in kerodon that happens when a ring response has a :body
that is a not a string (in this case a lazyseq). Reported and fixed by
Travis Vachon at https://github.com/xeqi/kerodon/pull/6, I just had
lost track of making a release for it.
Fixed as part of [kerodon 0.1.0].
On Tue, Feb
LazySeq is wrapping my InterruptedExceptions in several layers of
RuntimeException, which is a
bit awkward, because then my top level code spews pages of exceptions, rather
than just reporting
that the process was cancelled.
Is there anything better that could be done?
+ Change
Hi,
On Nov 19, 1:42 pm, David Powell djpow...@djpowell.net wrote:
LazySeq is wrapping my InterruptedExceptions in several layers of
RuntimeException, which is a
bit awkward, because then my top level code spews pages of exceptions, rather
than just reporting
that the process was cancelled
On Mar 21, 2009, at 1:44 PM, Mark Triggs wrote:
user= (str (filter even? (range 1 10)))
clojure.lang.lazy...@f1005
Previously this would readably print the contents of the seq and some
of my code was relying on this. Obviously it's not difficult to call
`prn-str' myself, but I just
Hi David,
On Mar 22, 5:01 pm, David Sletten da...@bosatsu.net wrote:
On Mar 21, 2009, at 1:44 PM, Mark Triggs wrote:
user= (str (filter even? (range 1 10)))
clojure.lang.lazy...@f1005
Previously this would readably print the contents of the seq and some
of my code was relying on
On Mar 21, 2009, at 11:30 PM, Mark Triggs wrote:
Yep, that's fine. In my case I was actually relying on the fact that
`str' was effectively doing a `prn-str' because I would later read it
back using `read-string' elsewhere. Calling `prn-str' explicitly
isn't a problem--I just thought I'd
36 matches
Mail list logo
