On Jan 24, 2:25 pm, Frantisek Sodomka wrote:
> Word "streams" invokes association to data-flow languages. For a
> while, I was following Project V:
>
> Simple Example of the Difference Between Imperative, Functional and
> Data
> Flow.http://my.opera.com/Vorlath/blog/2008/01/06/simple-example-of-
Word "streams" invokes association to data-flow languages. For a
while, I was following Project V:
Simple Example of the Difference Between Imperative, Functional and
Data Flow.
http://my.opera.com/Vorlath/blog/2008/01/06/simple-example-of-the-difference-between-imperative-functional-and-data-flo
I work for NVIDIA doing 3d graphics engines and editor platforms on
both PC and embedded platforms.
Konrad, the extra memory allocation is often the difference between
something fitting inside a cache line on a CPU and hitting main ram.
Last time I looked, I believe the difference is a factor of
people who love doing stream processing would attack an extra allocation.
On Fri, Jan 23, 2009 at 12:09 PM, Konrad Hinsen
wrote:
>
> On Jan 23, 2009, at 14:04, Rich Hickey wrote:
>
> >> Then why not make a pipeline using lazy sequences right from the
> >> start? I don't see anything that I could
On Jan 23, 2009, at 14:04, Rich Hickey wrote:
>> Then why not make a pipeline using lazy sequences right from the
>> start? I don't see anything that I could do better with streams than
>> with lazy sequences.
>>
>
> There are a couple of advantages. First, streams are faster, at least
> 2x faste
On Jan 23, 9:35 am, Christophe Grand wrote:
> Rich Hickey a écrit :> I think you lose the game overall.
>
> I'm sorry if I sounded provocative, I was trying to better understand
> the model you propose with streams. Thanks for your answer: it made
> thinks clearer to me.
>
> > With what you are
Rich Hickey a écrit :
> I think you lose the game overall.
I'm sorry if I sounded provocative, I was trying to better understand
the model you propose with streams. Thanks for your answer: it made
thinks clearer to me.
> With what you are proposing:
>
> (if (seq astream)
> (do-something-with
On Jan 22, 11:17 am, Konrad Hinsen wrote:
> On 22.01.2009, at 16:27, Rich Hickey wrote:
>
> >> Now it works - fine. But what happened to the seq that now owns the
> >> stream? Nothing refers to it, so it should be gone.
>
> > No, the stream must refer to it, in order to keep its promise to
> >
On Jan 23, 4:53 am, Christophe Grand wrote:
> Christophe Grand a écrit :> I relaxed the constraint saying that "a stream
> ensures that /*every call
> > to seq on a stream will return the same seq" to be */"a stream ensures
> > that /*every call to seq on a stream will return the same seq as l
On Jan 23, 3:31 am, Konrad Hinsen wrote:
> On 22.01.2009, at 19:50, Rich Hickey wrote:
>
>
>
> >> Does that mean that calling seq on a stream converts the stream into
> >> a seq for all practical purposes? That sounds a bit dangerous
> >> considering that so many operations in Clojure call seq
Christophe Grand a écrit :
> I relaxed the constraint saying that "a stream ensures that every call
> to seq on a stream will return the same seq" to be "a stream ensures
> that every call to seq on a stream will return the same seq as long as
> the stream state doesn't change".
Well currently
Christophe Grand a écrit :
> I relaxed the constraint saying that "a stream ensures that /*every call
> to seq on a stream will return the same seq" to be */"a stream ensures
> that /*every call to seq on a stream will return the same seq as long as
> the stream state doesn't change".*/
> /*Wha
Rich Hickey a écrit :
> Again, I don't see the enormous side effect. Steams form a safe,
> stateful pipeline, you'll generally only call seq on the end of the
> pipe. If you ask for a seq on a stream you are asking for a (lazy)
> reification. That reification and ownership is what makes the p
On 22.01.2009, at 19:50, Rich Hickey wrote:
>>
>> Does that mean that calling seq on a stream converts the stream into
>> a seq for all practical purposes? That sounds a bit dangerous
>> considering that so many operations in Clojure call seq implicitly.
>> One can easily have a seq "steal" a str
On Jan 21, 1:33 pm, Rich Hickey wrote:
> I've started documenting the streams work I have been doing, for those
> interested:
>
> http://clojure.org/streams
>
> Feedback welcome,
>
> Rich
This work reminds me in a general way of the old Dylan iteration
protocol.
On Jan 22, 2009, at 12:36 PM, Stuart Sierra wrote:
>
> On Jan 21, 2:33 pm, Rich Hickey wrote:
>> I've started documenting the streams work I have been doing, for
>> those
>> interested:
>
> Cool! 3 questions:
>
> 1. Can you feed things into a stream?
On Jan 22, 2009, at 11:17 AM, Konrad Hinsen wrote:
>
> On 22.01.2009, at 16:27, Rich Hickey wrote:
>
>>> Now it works - fine. But what happened to the seq that now owns the
>>> stream? Nothing refers to it, so it should be gone.
>>
>> No, the stream must refer to it, in order to keep its promise
On Jan 21, 2:33 pm, Rich Hickey wrote:
> I've started documenting the streams work I have been doing, for those
> interested:
Cool! 3 questions:
1. Can you feed things into a stream?
2. Could streams be used for I/O?
3. Can streams have clean-up/close code when they are emptied o
On 22.01.2009, at 16:27, Rich Hickey wrote:
>> Now it works - fine. But what happened to the seq that now owns the
>> stream? Nothing refers to it, so it should be gone.
>
> No, the stream must refer to it, in order to keep its promise to
> return the same seq every time.
OK.
>> Did it perhaps
On Jan 22, 9:08 am, Konrad Hinsen wrote:
> On 21.01.2009, at 20:33, Rich Hickey wrote:
>
> > I've started documenting the streams work I have been doing, for those
> > interested:
>
> >http://clojure.org/streams
>
> Nice!
>
> I have played a bi
On Thu, Jan 22, 2009 at 2:18 PM, Rich Hickey wrote:
>
> Those are important things to think about.
>
> There are, in fact, thread semantics for the streams mechanism, as for
> the rest of Clojure. Currently, I've made it such that the stream/iter/
> seq combination ensures serialized access to th
On 21.01.2009, at 20:33, Rich Hickey wrote:
> I've started documenting the streams work I have been doing, for those
> interested:
>
> http://clojure.org/streams
Nice!
I have played a bit with the stream implementation, and I came across
a behaviour that I do not understand:
>
> Now imagine two threads T1 and T2 accessing this generator at the same
> time. Suppose they reach the same node at the same time, and suppose
> that you've protected file deletion and link deletion each
> individually with a mutex (and forbade multiple deletions silently).
> T1 might delete th
On Jan 22, 12:53 am, "Mark H." wrote:
> On Jan 21, 5:21 pm, e wrote:
>
> > I would think it would be useful to have something exactly like a stream but
> > that allowed as many iterators as you like but that a mutex prevented any
> > two from consuming the same piece of information.
>
> That m
On Jan 21, 5:21 pm, e wrote:
> I would think it would be useful to have something exactly like a stream but
> that allowed as many iterators as you like but that a mutex prevented any
> two from consuming the same piece of information.
That might be useful for something, but it's hard to make
On Jan 21, 2009, at 8:58 PM, Vincent Foley wrote:
>
> I made some tests, and if I am not mistaken, if an eos is not
> specifically specified, Object is used, is that right?
>
> user=>
> (let [iter (stream-iter (range 5))]
> (def s (stream (fn [eos]
> (let [x (next! iter eos)]
I made some tests, and if I am not mistaken, if an eos is not
specifically specified, Object is used, is that right?
user=>
(let [iter (stream-iter (range 5))]
(def s (stream (fn [eos]
(let [x (next! iter eos)]
(if (= eos x)
(do (pr
>
> Well, it's the combination of a seq being persistent and a stream
> being one-pass - to realize the seq you'll need that pass.
could be implemented still doing that pass . . . and --> This may be where
you are headed in the To Be Continued, but it out to be possible to wrap a
sequence with a
On Jan 21, 8:05 pm, e wrote:
> I'm stopping to write this after the seq definition (bullet) to give you my
> exact feeling moving on. You may find that that is ok and that I will get
> it by the end of the page:
>
> What I assume at this point to be true is that if I first use an iter to *
> c
ey were suffering a
> major performance hit.
>
> ok, back to reading. This looks really neat (from this newby's vantage
> point, at least).
>
>
> On Wed, Jan 21, 2009 at 2:33 PM, Rich Hickey wrote:
>
>>
>> I've started docume
ause the unsuspecting user wouldn't know they were suffering a
major performance hit.
ok, back to reading. This looks really neat (from this newby's vantage
point, at least).
On Wed, Jan 21, 2009 at 2:33 PM, Rich Hickey wrote:
>
> I've started documenting the streams
On Jan 21, 7:40 pm, Vincent Foley wrote:
> I have a question regarding the examples, specifically map* and
> filter*
>
> (defn map* [f coll]
> (let [iter (stream-iter coll)]
> (stream
> (fn [eos]
>(let [x (next! iter eos)]
> (if (= eos x) x (f x)))
>
> (take 4 (m
Excellent!
In case anyone else has the same problem I did: if the latest swank-
clojure blows up on you, merging in the changes from the trunk will
solve it. This is fairly painless as there are only a few conflicts.
--~--~-~--~~~---~--~~
You received this messag
is eos passed to the fn inside stream and what is it?
Vince
On Jan 21, 2:33 pm, Rich Hickey wrote:
> I've started documenting the streams work I have been doing, for those
> interested:
>
> http://clojure.org/streams
>
>
Hello Rich,
Looking forward to using them! It is pleasure to see such nice
development!
Frantisek
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googleg
> Feedback welcome
Brilliant! :)
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to
clojure
I've started documenting the streams work I have been doing, for those
interested:
http://clojure.org/streams
Feedback welcome,
Rich
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
37 matches
Mail list logo
