More on my playing around here, I was trying to implement async versions
for the transducers, for example:
(defn filter-async [pred]
(fn [f1]
(fn
([] (f1))
([result] (f1 result))
([result input]
(if (<!! (pred input))
(f1 result input)
result)))))
This works fine, but doesn't gives me anything new (since I could use the
(comp <!! pred)), so, trying to convert the previous code into:
(defn filter-async [pred]
(fn [f1]
(fn
([] (f1))
([result] (f1 result))
([result input]
(go
(if (<! (pred input))
(f1 result input)
result))))))
This code would solve my issue, if it worked, but it doesn't (and I really
don't understand why not...).
But that gives this feeling of having to have extra implementations, which
feels backwards of what transducers are trying to accomplish...
I don't really have a solution here, that's why I would like to know if
other people have got into this situation, and how you are handling it.
---
Wilker Lúcio
http://about.me/wilkerlucio/bio
Woboinc Consultant
+55 81 82556600
On Sun, Sep 21, 2014 at 8:53 PM, Wilker <wilkerlu...@gmail.com> wrote:
> Because it's Node-JS environment, and that can be the same for any async
> Javascript, you never wanna call sync operations (like sync ajax) because
> they block everything...
>
> I was noticing that is a non-issue at all in Java world, since you can
> always read blocking into the predicate, for example: (filter (comp <!!
> my-chan-pred))
>
> But in Javascript that's not possible since it can't support read blocking.
>
> ---
> Wilker Lúcio
> http://about.me/wilkerlucio/bio
> Woboinc Consultant
> +55 81 82556600
>
> On Sun, Sep 21, 2014 at 8:50 PM, Leon Grapenthin <grapenthinl...@gmail.com
> > wrote:
>
>> Why would you want the the predicates and readdir to return channels?
>>
>> On Monday, September 22, 2014 12:14:27 AM UTC+2, Wilker wrote:
>>>
>>> Just an add,
>>>
>>> I was thinking if we could have something like a "deref" running during
>>> the transducers, in order to enable value unwrapping (that way we could
>>> handle channels/values in same fashion). I understand that is complicated
>>> maybe because overhead, and also more tricky into JS world were you can't
>>> deref a channel into a sync fashion.
>>>
>>> But the point remains, there is way to seamlessly handle async and sync
>>> operations using the same transducers? Or something like it.
>>>
>>> Best regards.
>>>
>>> ---
>>> Wilker Lúcio
>>> http://about.me/wilkerlucio/bio
>>> Woboinc Consultant
>>> +55 81 82556600
>>>
>>> On Sun, Sep 21, 2014 at 7:01 PM, Wilker <wilke...@gmail.com> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> I'm playing with transducers here, and trying out stuff just for fun,
>>>> there is something that I'm kind stuck on how to approach. I understand the
>>>> great abstraction that transducers provide over don't carrying about the
>>>> input source type, but I'm struggling to deal with async operations into my
>>>> pipeline.
>>>>
>>>> For example, I'm working with Node.JS async API's for file system
>>>> operations, I want to stick with the async versions since I don't wanna
>>>> block the event loop of Node.
>>>>
>>>> So, let's say I have a source with ["dir", "other"] and I wanna create
>>>> an operation that will simple filter which paths exists, are directories,
>>>> and then list the `ls` of each remaining entry.
>>>>
>>>> So, I first created "channel returning" functions for the Node
>>>> operations, I'll not put the code here because I don't think it's really
>>>> relevant here, just consider that I have them.
>>>>
>>>> So, my pipeline would start looking something like this:
>>>>
>>>> (comp (filter exists?)
>>>> (filter is-dir?)
>>>> (mapcat readdir))
>>>>
>>>> Of course, this doesn't works... Because `exists?`, `is-dir?` and
>>>> `readdir`, all of them return channels, so the filter would always pass
>>>> since a channel is always a valid value... The same applies to mapcat, it
>>>> would try to concat into a channel...
>>>>
>>>> This is making me notice some barrier to be able to compose async
>>>> operations with regular operations.
>>>>
>>>> Maybe would be possible to "sign" somehow operations to make then run
>>>> async?
>>>>
>>>> The only viable option that I've found is with pipeline-async, which
>>>> accepts an async function, but that doesn't composes with the other
>>>> operations (map, filter, drop-while...)
>>>>
>>>> Is there already a solution to that? Or maybe I'm just doing it wrong
>>>> and there is a better way to handle those cases?
>>>>
>>>> I would love to know how you guys are handling those kind of situations.
>>>>
>>>> Thanks.
>>>>
>>>> ---
>>>> Wilker Lúcio
>>>> http://about.me/wilkerlucio/bio
>>>> Woboinc Consultant
>>>> +55 81 82556600
>>>>
>>>
>>> --
>> 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 unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
