Yeah, I'm going to let it go, hopefully I'll find some way of handling it on future, for now keeping the extra versions is not that bad.
Thank you everyone. --- Wilker Lúcio http://about.me/wilkerlucio/bio Woboinc Consultant +55 81 82556600 On Mon, Sep 22, 2014 at 6:01 PM, Leon Grapenthin <grapenthinl...@gmail.com> wrote: > I don't see a way for a reducing function to make its return value depend > on the result of another callback. > > > On Monday, September 22, 2014 9:45:15 PM UTC+2, Wilker wrote: >> >> 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 <grapent...@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 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.
