On Jan 24, 2:25 pm, Frantisek Sodomka fsodo...@gmail.com 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
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-flow
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 stream and not
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
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.*/
/*What did I
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 it's
On Jan 23, 3:31 am, Konrad Hinsen konrad.hin...@laposte.net 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
On Jan 23, 4:53 am, Christophe Grand christo...@cgrand.net 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
On Jan 22, 11:17 am, Konrad Hinsen konrad.hin...@laposte.net 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
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
people who love doing stream processing would attack an extra allocation.
On Fri, Jan 23, 2009 at 12:09 PM, Konrad Hinsen
konrad.hin...@laposte.netwrote:
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
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
On Jan 22, 12:53 am, Mark H. mark.hoem...@gmail.com wrote:
On Jan 21, 5:21 pm, e evier...@gmail.com 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
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 the
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:
First, define
On Thu, Jan 22, 2009 at 2:18 PM, Rich Hickey richhic...@gmail.com 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
On Jan 22, 9:08 am, Konrad Hinsen konrad.hin...@laposte.net 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 bit with the stream implementation
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 21, 2:33 pm, Rich Hickey richhic...@gmail.com 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
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 to
return
On Jan 22, 2009, at 12:36 PM, Stuart Sierra wrote:
On Jan 21, 2:33 pm, Rich Hickey richhic...@gmail.com 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?
Yes, you can put a generator
On Jan 21, 1:33 pm, Rich Hickey richhic...@gmail.com 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. They're
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.
To post
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
is eos passed to the fn inside stream and what is it?
Vince
On Jan 21, 2:33 pm, Rich Hickey richhic...@gmail.com wrote:
I've started documenting the streams work I have been doing, for those
interested:
http://clojure.org/streams
Feedback welcome,
Rich
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
On Jan 21, 7:40 pm, Vincent Foley vfo...@gmail.com 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)))
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 richhic...@gmail.com wrote:
I've started documenting the streams work I have been doing, for those
interested
(from this newby's vantage
point, at least).
On Wed, Jan 21, 2009 at 2:33 PM, Rich Hickey richhic...@gmail.com wrote:
I've started documenting the streams work I have been doing, for those
interested:
http://clojure.org/streams
Feedback welcome,
Rich
On Jan 21, 8:05 pm, e evier...@gmail.com 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
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
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
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)]
On Jan 21, 5:21 pm, e evier...@gmail.com 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
34 matches
Mail list logo
