I understand Leon, but all that only applies on Java world... The issue here is because I depend on async stuff, in Java you always have options to do it sync, you don't need any of those callbacks at all, this is a JS API issue. So in my case I really need the async factor here, I can't avoid it.
Given that, would be possible to make transducers async? I think the big deal of transducers is exactly don't having to re-write map, filter, etc... That's why I'm really trying to get then to work on this situation, unless someone knows for sure that its not possible, than I can accept the limitations and keep all my custom versions that can handle async processing... Thanks. --- Wilker Lúcio http://about.me/wilkerlucio/bio Woboinc Consultant +55 81 82556600 On Mon, Sep 22, 2014 at 4:22 PM, Leon Grapenthin <grapenthinl...@gmail.com> wrote: > The steps of your transducer composition are depending on each other. They > can only produce a result from an input if they process it synchronously. > If you had <!! available and would use it as you have described, you would > reenforce synchronous input processing: Once you would consume an item, the > code would have the exact same blocking characteristics as if the functions > were returning values instead of channels. You would have gained nothing > for the cost of creating overhead. > > > On Monday, September 22, 2014 1:53:52 AM UTC+2, Wilker 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 <grapent...@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 clo...@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+u...@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+u...@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. > -- 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.
