Re: Unexpected performace of transducers
Thanks Gary, Alex, Didier, I learned a lot from your replies. As per iota, I assume we're talking about this library of course <https://github.com/thebusby/iota>. On Sun, Dec 17, 2017 at 2:40 PM, Gary Verhaegen wrote: The iota library implements a reducible object on top of files. It may be worth trying out for your use-case. On 17 Dec 2017, at 00:32, Alex Miller wrote: On Saturday, December 16, 2017 at 2:39:14 PM UTC-6, Matan wrote: > > Hi, > > As this thread seems to have been going down this path, I am joining it > after having spent some time fiddling the source code of some clojure.core > transducers and familiarizing with how to create, compose and use > transducers in transducing processes. By the way I think the reference > <https://clojure.org/reference/transducers> could be more explicit about > the relationship between transducers, transducing processes and contexts > for applying transducers (as is, IMO a lot of ambiguity arises, causing a > lot of confusion in getting started). So, it was noted earlier in this > thread by Alex Miller: > > You're starting from a lazy sequence, not a self-reducible collection. >> That's not wrong, but it's removing a key transduce/reduce power to work >> with reducible colls. > > > I think that's also the case with applying any transducer to a file input > (?!) and I am therefore wondering about: > >1. I didn't fully grasp the difference between self-reducible >collections v.s. other ones (in this context, and in general). >Can you please delineate? > > I'm referring primarily to collections that implement their own reduce() method (like vectors and lists) vs seqs. > >1. Roughly how much performance lag do we get when not working a >transduction from a (self) reducible collection, and moreso why exactly? > > Vectors and lists are concrete, have all their own data available, and can directly iterate through the data in a tight loop. Seqs must be realized and this entails object creation, synchronization, and object destruction overhead per element (or for chunked seqs, per chunk). Some collections can be iterated like a seq OR reduce themselves (vectors, lists, seqs on arrays, and the collection produced by range, cycle, repeat, and iterate). > >1. Should we typically choose a different vehicle for stream >processing from large files, over using transducers? My current use case is >stream-processing from large files. > > Stream processing is just another means of producing values. The question is really in how you represent the stream. Seqs have some inherent overhead. Presumably you don't want to read the entire stream and put it in a collection. The trick then is to create an object that is reducible, not a seq, and reads the stream. Probably the easiest way is to use something Iterable that can provide an iterator over the stream. The CollReduce protocol is extended to Iterable so this is already built in. Then reduce/transduce over the iterable. An eduction combines a reducible collection and a transformation (transducer) into a collection that delays its execution until the point where you reduce it (this has some of the same utility as a lazy sequence in delaying execution). How exactly you want to iterate over reading the stream depends on what you're doing (Java provides streams, readers, and channels for a variety of different use cases). In any case you want to have an Iterator implementation (hasNext() and next()) that can provide the "next" item. Things like Apache Commons IOUtils can give you line iterators over a reader for example. -- 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 a topic in th
Re: Unexpected performace of transducers
Hi, As this thread seems to have been going down this path, I am joining it after having spent some time fiddling the source code of some clojure.core transducers and familiarizing with how to create, compose and use transducers in transducing processes. By the way I think the reference <https://clojure.org/reference/transducers> could be more explicit about the relationship between transducers, transducing processes and contexts for applying transducers (as is, IMO a lot of ambiguity arises, causing a lot of confusion in getting started). So, it was noted earlier in this thread by Alex Miller: You're starting from a lazy sequence, not a self-reducible collection. > That's not wrong, but it's removing a key transduce/reduce power to work > with reducible colls. I think that's also the case with applying any transducer to a file input (?!) and I am therefore wondering about: 1. I didn't fully grasp the difference between self-reducible collections v.s. other ones (in this context, and in general). Can you please delineate? 2. Roughly how much performance lag do we get when not working a transduction from a (self) reducible collection, and moreso why exactly? 3. Should we typically choose a different vehicle for stream processing from large files, over using transducers? My current use case is stream-processing from large files. Thanks in advance for your reply, Matan On Tuesday, November 28, 2017 at 1:53:42 PM UTC+2, Renzo Borgatti wrote: > > > > On 28 Nov 2017, at 02:54, Alex Miller > wrote: > > > > I would say transducers are preferable when: > > > > 1) you have reducible collections > > 2) you have a lot of pipelined transformations (transducers handle these > in one pass with no intermediate data) > > 3) the number of elements is "large" (this amplifies the memory and perf > savings from #2) > > 4) you put to produce a concrete output collection (seqs need an extra > step to pour the seq into a collection; transducers can create it directly) > > 5) you want a reusable transformation that can be used in multiple > contexts (reduction, sequence, core.async, etc) > > I agree with the above Alex, although I think that is the kind of > checklist I'd look at if performance optimizations is my primary goal. In > any other case, I'd reach for transducers as the default. There are then > several corner cases to understand, but that's true for normal sequential > processing too. > > Renzo > > > > > On Monday, November 27, 2017 at 8:33:50 PM UTC-6, Jiacai Liu wrote: > > > Also, most of the performance boost from transducers is due to less > garbage being created, and some times the heap of the JVM is so large > you'll never see much change from switching to transducers. > > > > Thanks for this tip. I seldom use transducers in my daily work, and I > was convinced transducers are a better choice in whatever situation after > reading some articles. But the test shows it isn't an easy choice, only > when do something reducible, will transducers make more sense. > > > > On Tuesday, November 28, 2017 at 5:07:10 AM UTC+8, tbc++ wrote: > > >> Also, I think the transducer version should always be faster, no > matter the size of the source collection (no threshold). > > > > It's a bit more complicated than that, mostly because transducer > pipelines require about 2 allocations per step during creation. Also, most > of the performance boost from transducers is due to less garbage being > created, and some times the heap of the JVM is so large you'll never see > much change from switching to transducers. > > > > Don't get me wrong, transducers are great and I often default to them > over seqs, but in micro-benchmarks like this there's too much in play to > always see a 100% performance boost. > > > > On Mon, Nov 27, 2017 at 12:55 PM, David Bürgin > wrote: > > Jiacai – > > > > I saw you updated the gist. Just in case it passed you by: performance > > profits from the source collection being reducible. So pouring ‘dataset’ > > into a vector beforehand should speed up the processing quite a bit. > > > > Also, I think the transducer version should always be faster, no matter > > the size of the source collection (no threshold). > > > > > > -- > > David > > > > -- > > 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 ar
Re: How to implement a distributed and concurrent system in Clojure?
This thread is a bit old, but it's seen two year awakenings before... and still shows up high in google searches. I wonder how you folks see it now. Onyx is a bit older by now, and not much seems new out there. What would you choose for reliable and resilient distributed computing with clojure, if you had to start over at this time? in particular, for a message driven architecture not a streaming one. On Monday, July 20, 2015 at 3:52:44 AM UTC+3, Derek Troy-West wrote: > > We use Storm/Trident fairly extensively for distributed computation, it > has not been painless and the documentation is poor, however it does > perform well once you understand its peculiarities. I'm keeping an > interested eye on Onyx but my bandwidth is fairly limited at the moment. > > The only things I would add to your post are: > > * It's possible to write Storm and Trident topologies purely in Clojure, > in fact parts of Storm were originally written in Clojure. I'm not sure the > DSL were an afterthought, but I agree they are fairly impenetrable at > first. Storm has a large learning curve and lots of quirks, and the > documentation is pretty bad (in-fact, completely wrong in parts). > > * Storm is currently limited to Clojure 1.5.1, thought the latest beta > release has been updated to 1.6.0 > > * Recently the momentum of the project appears to have picked up, but > certainly for a while there (just after apache incubation) it appeared a > bit stagnant. I presume they were busy settling the project in. > > > On Monday, July 20, 2015 at 3:11:24 AM UTC+10, Christopher Small wrote: >> >> >> I'll also add that if you're interested in the Storm model (distributed >> stream processing), you may want to check out Onyx ( >> https://github.com/onyx-platform/onyx). It's newer, but I have a feeling >> that moving forward we're going to see it take a dominant position as far >> as that flavor of distributed computing goes. The reasons for this >> (briefly): >> >> * Data all the topologies: Because computational topologies are data >> structures, it's far simpler to have more dynamic computational workflows >> than with storms opaque macros. >> * It's more Clojure centric: Parts of Storm are Clojure, but the Clojure >> API seems almost an afterthought, reading the documentation. (However, >> support is on the way for other JVM languages). >> * Pace of development: Storm is now an Apache Incubator project, and >> development is slower than molasses. I was working on a project for over a >> year and many times encountered issues with stale dependencies that didn't >> play nicely with newer things. >> * Designed with batch processing in mind: Even though both are designed >> around streaming first, Onyx has a little more explicit support for batched >> computations. >> >> For a while, the biggest advantage of Storm was that it was a lot faster, >> but the gap there has closed considerably recently (perhaps entirely?). >> Storm is still more battle tested, but there are folks starting to use it >> in production. >> >> The biggest reason I see Onyx taking sway over Storm is the data centric >> approach. I see this resonating with the community's "data all the things" >> philosophy as a way of maximizing composability and productivity. >> Anecdotally, folks using Onyx are already saying this about it. >> >> My 2 c >> >> Chris >> >> >> >> On Sunday, July 19, 2015 at 9:38:09 AM UTC-7, Devin Walters (devn) wrote: >>> >>> http://docs.paralleluniverse.co/pulsar/ is out there. I can't say I've >>> used it in anger, but I did enjoy experimenting with it. >>> On Sun, Jul 19, 2015 at 11:24 AM Colin Yates wrote: >>> I don’t have anything to add at that scale, but I wanted to echo Stuart’s comment about the serialisability of EDN. Moving EDN between the front and back tiers on our app has cut down a bunch of boilerplate. That principle can scale across machines as well. On 19 Jul 2015, at 16:54, Stuart Sierra wrote: Absolutely would use again. But I'm biased towards Clojure already. :) –S On Sunday, July 19, 2015 09goral wrote: > > Thanks Stuart for your answer, it is very helpfull. Would you choose > Clojure again ? > > 2015-07-19 17:13 GMT+02:00 Stuart Sierra: > >> >> This is an old thread, but it showed up in my Google Groups so I >> figured I would give an answer. >> >> I have worked on fairly large (10-50 machines) distributed systems >> written entirely in Clojure >> > -- 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://g
Re: Java 8 Lambda Interop
Sorry to awaken this old thread. It seems like reifying a valid lambda, for the specific clojure function which you want to pass to Java code, is indeed the most sensible way, given all the surface that java's lambda api entails. To the best of my knowledge no generic interop features or libraries have emerged since this thread. On Sunday, July 26, 2015 at 11:33:17 PM UTC+3, Andrew Oberstar wrote: > > Hi, > > I'm wondering if anyone has a good approach for making calls from Clojure > to Java APIs (e.g. Stream API) that expect a @FunctionalInterface type. > > Ideally, IFn would transparently work, but I'm guessing that requires some > compiler changes. > > Right now, the best I can think of is a function or macro to reify a > wrapper around a Clojure function to implement all of the usual interfaces > from java.util.function. > > Anyone have any better ideas? > > Andrew Oberstar > -- 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.
Re: [ANN] clojure-future-spec, a backport of clojure.spec for 1.8
Cool!! Sent from my mobile Original Message From:Nikita Prokopov Sent:Sun, 25 Sep 2016 11:52:19 +0300 To:Clojure Subject:Re: [ANN] clojure-future-spec, a backport of clojure.spec for 1.8 >Matan, > > >spec is pretty isolated part of Clojure, so it’s basically a copy-paste job >with couple of gaps filled in that were introduced in 1.9. > > >Updating it is basically getting diff from clojure and applying it to my repo. >Sometimes with some manual corrections. > > >Nikita. > > >On Sat, Sep 24, 2016 at 1:40 AM Matan Safriel wrote: > >Nikita, this is cool, e.g. as lighttable does not yet fully support 1.9. > >Can you say something about how are these backports derived? so that I can get >an intuition into how much it is at par with the real thing? > >Does it involve a lot of code rewrite to backport each 1.9 alpha version? > > > >On Wednesday, June 29, 2016 at 3:16:39 PM UTC+3, Nikita Prokopov wrote: > >Hi! > > >Not sure if a good idea or bad, but if you were eager to play with latest >version of clojure.spec but don’t want to upgrade your production to alpha >version of the language, you can add clojure.spec capabilities as a library to >1.8: > > >https://github.com/tonsky/clojure-future-spec > > >:dependencies [ > > [org.clojure/clojure "1.8.0"] > > [clojure-future-spec "1.9.0-alpha8"] > >] > > >(require '[clojure.spec :as spec]) > >(require '[clojure.spec.gen :as spec.gen]) > >(require '[clojure.future :refer :all]) > > >clojure.future namespace contains all new clojure.core functions like int?, >seqable? etc > > >The version numbers will follow clojure 1.9 versions. Expect this lib upgraded >with every new Clojure alpha release until 1.9 if finally out. > > >Nikita. > >-- >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 a topic in the Google >Groups "Clojure" group. >To unsubscribe from this topic, visit >https://groups.google.com/d/topic/clojure/qZZXSzY7apA/unsubscribe. >To unsubscribe from this group and all its topics, 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 a topic in the Google >Groups "Clojure" group. >To unsubscribe from this topic, visit >https://groups.google.com/d/topic/clojure/qZZXSzY7apA/unsubscribe. >To unsubscribe from this group and all its topics, 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.
Re: [ANN] clojure-future-spec, a backport of clojure.spec for 1.8
Nikita, this is cool, e.g. as lighttable does not yet fully support 1.9. Can you say something about how are these backports derived? so that I can get an intuition into how much it is at par with the real thing? Does it involve a lot of code rewrite to backport each 1.9 alpha version? On Wednesday, June 29, 2016 at 3:16:39 PM UTC+3, Nikita Prokopov wrote: > > Hi! > > Not sure if a good idea or bad, but if you were eager to play with latest > version of clojure.spec but don’t want to upgrade your production to alpha > version of the language, you can add clojure.spec capabilities as a library > to 1.8: > > https://github.com/tonsky/clojure-future-spec > > :dependencies [ > [org.clojure/clojure "1.8.0"] > [clojure-future-spec "1.9.0-alpha8"] > ] > > (require '[clojure.spec :as spec]) > (require '[clojure.spec.gen :as spec.gen]) > (require '[clojure.future :refer :all]) > > clojure.future namespace contains all new clojure.core functions like > int?, seqable? etc > > The version numbers will follow clojure 1.9 versions. Expect this lib > upgraded with every new Clojure alpha release until 1.9 if finally out. > > Nikita. > -- 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.
Re: core.async top use cases
Actually, I am not sure clojure implements the actor model, which I can only construe as the Erlang actor model here. I am almost certain the core language explicitly does not: http://clojure.org/about/state It can be shoehorned somehow (see okku) but I would probably not venture saying clojure supports the actor model. Sent from my mobile Original Message From:Beau Fabry Sent:Wed, 21 Sep 2016 03:47:29 +0300 To:Clojure Subject:Re: core.async top use cases >I'm no expert on this, but the Actor model and the CSP model seem to be two >different ways to model a concurrent system. Clojure supports them both. >Personally I find the CSP model a simpler and easier to understand one than >Actors, and so pretty much default to it. You might find non-clojure related >sources comparing the tradeoffs between the two though? > > > >On Monday, September 19, 2016 at 11:50:53 PM UTC-7, Matan Safriel wrote: > >Thanks but I'm not entirely sure about this. I could use agents for side >effects too, or at least I thought so. Care to further clarify? > > > Original Message >From:William la Forge >Sent:Tue, 20 Sep 2016 02:37:20 +0300 >To:Clojure >Subject:Re: core.async top use cases > >The really nice thing to me is that async handles side-effects while agents do >not. > >-- >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 a topic in the Google >Groups "Clojure" group. >To unsubscribe from this topic, visit >https://groups.google.com/d/topic/clojure/peJXvE0nBZs/unsubscribe. >To unsubscribe from this group and all its topics, 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 a topic in the Google >Groups "Clojure" group. >To unsubscribe from this topic, visit >https://groups.google.com/d/topic/clojure/peJXvE0nBZs/unsubscribe. >To unsubscribe from this group and all its topics, 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.
Re: core.async top use cases
Thanks but I'm not entirely sure about this. I could use agents for side effects too, or at least I thought so. Care to further clarify? Original Message From:William la Forge Sent:Tue, 20 Sep 2016 02:37:20 +0300 To:Clojure Subject:Re: core.async top use cases >The really nice thing to me is that async handles side-effects while agents do >not. > >-- >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 a topic in the Google >Groups "Clojure" group. >To unsubscribe from this topic, visit >https://groups.google.com/d/topic/clojure/peJXvE0nBZs/unsubscribe. >To unsubscribe from this group and all its topics, 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.
Re: core.async top use cases
Right! Original Message From:Leon Grapenthin Sent:Mon, 19 Sep 2016 20:19:55 +0300 To:Clojure Subject:Re: core.async top use cases >It is not just convenience. For example agents don't provide functionality >like buffering, backpressure and select aka alts. If you send an action to an >agent you don't get to know when it's done or to choose what to do if it is >currently busy. > >On Monday, September 19, 2016 at 11:49:13 AM UTC+2, Matan Safriel wrote: > >Thanks, and I put the blog post on my reading list. > >Although I can't avoid thinking that we already have asynchronous idioms in >the core language itself, like agents. I think the crux for server-side is >more about the convenient piping, rather than the mere asynchronism itself, >but I might be wrong in any of this. > > >On Mon, Sep 19, 2016 at 9:14 AM, Mond Ray wrote: > >Pushing asynchrony further into the stack is useful for reliability and fault >tolerance. We can also use it as a basis for Complex Event Processing using >time series windows. > > >I wrote up a few examples in my blog if you have the time to check out a >longer explanation with code. > > >I recently wrote a small set of functions to enable HTML5 Server Sent Events >from any Kafka topic which also uses core.async (with an example using Aleph >and Compojure). You might like to check that repo out too. > > >Ray > > >On Sunday, 18 September 2016 08:37:38 UTC+2, Matan Safriel wrote: > >Hi, > > >It's very easy to see how core.async solves callback hell for front-end >development with clojurescript. > >In what use cases would you use it for server-side? we already have >non-blocking IO from Java, and we have clojure agents. So what's a bunch of >salient use cases? > >Are there prominent clojure http server implementations which rely on it for >transcending the threaded web service paradigm? > > >Thanks, > >Matan > > >-- >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 a topic in the Google >Groups "Clojure" group. >To unsubscribe from this topic, visit >https://groups.google.com/d/topic/clojure/peJXvE0nBZs/unsubscribe. >To unsubscribe from this group and all its topics, 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 a topic in the Google >Groups "Clojure" group. >To unsubscribe from this topic, visit >https://groups.google.com/d/topic/clojure/peJXvE0nBZs/unsubscribe. >To unsubscribe from this group and all its topics, 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.
Re: core.async top use cases
Thanks, and I put the blog post on my reading list. Although I can't avoid thinking that we already have asynchronous idioms in the core language itself, like agents. I think the crux for server-side is more about the convenient piping, rather than the mere asynchronism itself, but I might be wrong in any of this. On Mon, Sep 19, 2016 at 9:14 AM, Mond Ray wrote: > Pushing asynchrony further into the stack is useful for reliability and > fault tolerance. We can also use it as a basis for Complex Event Processing > using time series windows. > > I wrote up a few examples in my blog > <http://blog.opengrail.com/clojure/events/streams/2016/02/06/event-stream-intro.html> > if you have the time to check out a longer explanation with code. > > I recently wrote a small set of functions to enable HTML5 Server Sent > Events from any Kafka topic which also uses core.async (with an example > using Aleph and Compojure). You might like to check that repo > <https://github.com/raymcdermott/kafka-sse-clj> out too. > > Ray > > On Sunday, 18 September 2016 08:37:38 UTC+2, Matan Safriel wrote: >> >> Hi, >> >> It's very easy to see how core.async solves callback hell for front-end >> development with clojurescript. >> In what use cases would you use it for server-side? we already have >> non-blocking IO from Java, and we have clojure agents. So what's a bunch of >> salient use cases? >> Are there prominent clojure http server implementations which rely on it >> for transcending the threaded web service paradigm? >> >> Thanks, >> Matan >> >> -- > 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 a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/clojure/peJXvE0nBZs/unsubscribe. > To unsubscribe from this group and all its topics, 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.
core.async top use cases
Hi, It's very easy to see how core.async solves callback hell for front-end development with clojurescript. In what use cases would you use it for server-side? we already have non-blocking IO from Java, and we have clojure agents. So what's a bunch of salient use cases? Are there prominent clojure http server implementations which rely on it for transcending the threaded web service paradigm? Thanks, Matan -- 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.
Obtaining the call graph of a clojure project
Hi, Is it possible to get information about the call graph of a project from the clojure compiler? For example in Scala, one can use a compiler plugin, to tap into the AST. This in turn permits deriving more or less the entire call graph of the project, directly through the compiler, rather than by picking inside the byte code produced by the compiler. What can be said about this aspect in Clojure? Thanks! Matan -- 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.
Re: Handling exceptions (subject renamed)
Awesome. On Fri, Oct 5, 2012 at 8:40 PM, gaz jones wrote: > http://clojure.github.com/clojure/clojure.stacktrace-api.html > > On Fri, Oct 5, 2012 at 12:06 PM, Matt wrote: > > Hi, > > > > Sorry to anyone who read the original post. > > Apparently I had malformed the try block encompassing the create-table > in a > > very non-clojure-ish way. > > So my problem wasn't with clojure.java.jdbc's create-table. Being > 'dynamic', > > clojure could not warn me about it until it crashes in runtime. I guess I > > should also learn more about making exception printouts contain more > details > > (such as line number as one, if that's at all possible?) > > I'd appreciate knowing how to get more details when an exception is > caught > > by my code e.g. at least a line number if possible - > > > > I was using - > > (catch Exception e (println (str "Exception is: " e))) > > > > Which only yielded a general description (java.lang.ClassCastException: > > clojure.lang.ArraySeq$ArraySeq_int cannot be cast to clojure.lang.IFn) > > without indicating where my code broke. > > > > Is it possible to get the source line that made the code break? > > > > Thanks! > > > > On Friday, October 5, 2012 5:15:18 PM UTC+2, Matt wrote: > >> > >> Hi, > >> > >> I'm relatively new to Clojure. This must be easy. > >> I am trying to write a function that creates a table with a name passed > as > >> argument, and this naturally requires passing > clojure.java.jdbc/create-table > >> a value for the table name, rather than specifying the name as a > constant. > >> However I'm not insofar able to pull it off. > >> > >> When I use the form create-table passed-argument [fields] as opposed to > a > >> constant as in create-table :hard-coded-entity-name [fields], then the > table > >> gets successfully created in the database, however my code also gets an > >> exception - java.lang.ClassCastException: > clojure.lang.ArraySeq$ArraySeq_int > >> cannot be cast to clojure.lang.IFn. The exception is received even > though > >> the table had been seemingly perfectly created. I'm probably missing > >> something basic. What do you think can it be? > >> > >> Thanks, > >> Matt > >> > >> > >> > > -- > > 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 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 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
