Re: [ANN] rmap - define lazy, recursive maps
Thank you for your kind responses! I will look into writing a post that shows what the motivation was (i.e. how I use it), how it works, and how it compares to Prismatic's Graph. Cheers, Arnout -- 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: Advice for building backend REST services from scratch using clojure
Just FYI - I got a new laptop and thought I would give it another look-see. Consider me impressed. I maybe didn't spend enough time with it, but a lot of the rough edges have been smoothed out, the performance seems to have increased, it is just a really nice place to be. To be clear, emacs rocks, it can do anything, it just doesn't do everything out of the box. Emacs Prelude goes a long long way, and the paredit (or smart-parens now?), tight repl integration, undo-tree and magit are still the best implementations I have seen anywhere, but sad to say, when viewed under a "no time, got to get things done" coupled with "consistency across developers", it didn't hold up too well. To put it another way, I am admitting defeat - emacs is sufficient, the time I have to learn and teach emacs is insufficient. Cursive still requires some pampering (setting up keymaps etc.) and there are still some rough edges (being able to delete delimiters and not be able to add them back for example), but for the 80/20 rule, it rocks. And IntelliJ is also a very nice place to be. Consider my words firmly eaten :). (Oh, and according to my team you still wouldn't want to work with me :). Off to find some horrible backlog work for them now!). On Friday, 11 April 2014 12:34:04 UTC+1, Colin Fleming wrote: > > No worries, I didn't think what you wrote was inflammatory and it's > undeniable that Emacs has the largest mindshare in the Clojure world. But > the alternatives are getting better and better and I think I could make a > reasonable case that Cursive is better than Emacs for some circumstances > and/or projects. I personally didn't like the initial versions of > LightTable (it felt like a bit of a one-trick pony and the trick didn't > really work for me) but the guys working on it are smart and I'm sure it's > getting a lot of plugin love now it's open source, so I'm sure that'll be a > real contender soon if it isn't already. > > Emacs clearly works for the OP so there's no issue there, but I think it's > less and less a foregone conclusion that everyone will end up there. I > personally wouldn't work for you if you forced me to use it, but that's > just me :-) > > > On 11 April 2014 22:04, Colin Yates > > wrote: > >> Colin - you are right - I shouldn't throw out such inflammatory marks, >> particularly when they do a disservice to the excellent work done in >> Cursive Clojure, Lighttable and Counter Clockwise (and others that I am not >> aware off). >> >> For me personally, after years of using Eclipse then IntelliJ and (to a >> much lesser degree) Sublime I am forcing my team to use emacs. And yes, >> forcing is the word as they are utterly sold on sublime and really don't >> like me much at the moment :). >> >> It is the classical short term/long term win, and emacs is worth the >> investment for us. But it absolutely is an investment. >> >> Disclaimer - I haven't looked at any of the other editors for months if >> not years. >> >> >> On Friday, April 11, 2014 10:20:37 AM UTC+1, Colin Fleming wrote: >> >>> you can fight it as hard as you like but you will eventually end up using emacs, clojure-mode, cider, paredit and magit and then wonder how you ever lived without it, but not without spending at least a month or two cursing anything to do with emacs :). >>> >>> As the developer of Cursive, I'd like to politely disagree with this >>> point. I think that Cursive provides a very competitive feature set but >>> without the swearing :-). Of course I'm totally biased, so take with a >>> grain of salt, but I think particularly for Clojure newbies it's worth a >>> look - learning Emacs at the same time as Clojure can be a recipe for >>> frustration. >>> >>> Of course, it doesn't have to be Cursive, there are other options in >>> case Emacs gives you hives. >>> >>> >>> On 11 April 2014 20:17, Colin Yates wrote: >>> As others have said - a more focused question would help. Our back end runs on ring + compojure using https://github.com/jkk/ honeysql for querying and straight https://github.com/clojure/java.jdbc for writes. We use https://github.com/marick/Midje/wiki rather than clojure.test and https://github.com/gdeer81/marginalia for documentation. This is the first major Clojure app, so lots of lessons have been learnt. Things I wish I knew: - read the ring spec - it is all just a map, phenomenally powerful. Now read it again - consider using https://github.com/zcaudate/lein-midje-doc as well as/instead of marginalia - consider using https://github.com/jaycfields/expectations instead of midje. Midje is fantastic, but expectations, particularly the 'diffing' looks like a real win - consider using something like https://github.com/prismatic/schema to document your API from day one. - you can fight it as
Re: [ANN] Monroe 0.1.0 - nrepl client for Emacs
Bozhidar Batsov writes: > Yeah, they should definitely remove nrepl.el support from > ob-clojure.el. Done in the master branch of org-mode, thanks. -- Bastien -- 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: peek the next value from a channel without consuming it
Add one more chan, "external ready". Put :ok there to let producer generate new value. producer: - read from "external ready" - generate value - put into "outgoing" chan client: - contact external server, put in "external ready" if ok - read from "outgoing" chan - send to external Handle exceptions and loop where you need. On Sunday, October 5, 2014 7:40:25 PM UTC+3, Nahuel Greco wrote: > > previous example with the peek operation: > > 1- The producer puts a value to a unbuffered (chan) by doing (>! c v) > 2- The go-loop unparks from (peek producer keeps parked > 3- The go-loop contacts the external-service > 4-A If the external-service answer is ok, the go-loop consume (and > discard) the value by doing a normal ( 4-B If the external-service answers it cannot process the value, the > go-loop waits until a timeout to retry step 3 > > The producer only unparks when the value is effectively consumed by the > external service. That's my objective. > > I think your pub proposal replaces the take-if proposal given before, but > I think take-if (and pub) doesn't work for this scenario. > > > Saludos, > Nahuel Greco. > > On Sun, Oct 5, 2014 at 1:20 PM, > > wrote: > >> Then how would peeking at the value help? >> >> On Sunday, October 5, 2014 12:14:32 PM UTC-4, Nahuel Greco wrote: >>> >>> Adrian: I don't see how a pub can help here, in the previous example to >>> consume or not the value was decided not on some property intrinsic to the >>> value (one you can create a topic from), but on the result of sending it to >>> an external service. >>> >>> >>> Saludos, >>> Nahuel Greco. >>> >>> On Sun, Oct 5, 2014 at 12:59 PM, wrote: >>> I think you can achieve an effect similar to what you want by using a pub with an appropriate topic function that classifies the input in some way, and then subscribing to the topic whose value you want to see. This also has the benefit of automatically 'mult'ing the channel input, so you can have multiple consumers looking for the same value. On Sunday, October 5, 2014 11:33:16 AM UTC-4, Nahuel Greco wrote: > > Picture the following: > > producer ---> go-loop ---> external service > > 1- The producer puts a value to a unbuffered (chan) by doing (>! c v) > 2- The go-loop consumes the value with a take operation, > **unblocking** the producer > 3- The go-loop contacts the external-service but the external service > answers it can't process the value yet > 4- The go-loop waits some timeout to retry the request to the external > service > > After step 2 the producer continues to compute (suppose an expensive > computing) a new value but the previous one wasn't effectively consumed > by > the external service. > I don't want that, I want to enforce an end-to-end flow-control setup > where the producer blocks on (>! c v) (the step 1) until the value is > consumed by all parties, > > Sure, this flow control can be solved adding an ack channel and > sending an ack from the go-loop to the producer when the external service > effectively consumes the value, previously blocking the producer after > step > 1 waiting that ack. > But I think a peek operation in step 2 will be more elegant. Also, I > was curious if the implementation of core.async channels limits in some > way > adding a peek operation. > > A take-if with a pure predicate can't solve this, because you need to > contact the external service to decide to consume the value or not. > > > Saludos, > Nahuel Greco. > > On Sun, Oct 5, 2014 at 9:52 AM, Fluid Dynamics > wrote: > >> On Sunday, October 5, 2014 12:51:04 AM UTC-4, Nahuel Greco wrote: >>> >>> I was thinking in a single-consumer scenario with a buffered chan, >>> in which you want to check if you can consume the value before >>> effectively >>> consuming it. As you said, a peek operation has no sense if the channel >>> has >>> multiple consumers. >>> >> >> And if you can't consume the value, then what? Nothing ever does, and >> that channel becomes useless? >> >> Actually the only "peek" operation that to me makes much sense would >> be a (take-if pred chan) or something similar, which atomically tests >> the >> next value with pred and consumes it or not, so, it can't be consumed >> elsewhere between the pred test and optional consumption here. And if >> not >> consumed, two behaviors both occur to me as possible -- return nil or >> some >> other sentinel value for "do not want" or block until the unwanted >> object >> is consumed by someone else and then test the next item, etc.; at which >> point you've got four versions of take-if you'd want, the inside-go and >> outside-go versions cross product with the two when-not-wanted
New Functional Programming Job Opportunities
Here are some functional programming job opportunities that were posted recently: Senior Developer at Lyminal, Inc. http://functionaljobs.com/jobs/8748-senior-developer-at-lyminal-inc Full Stack Functional Web Engineer at Front Row Education http://functionaljobs.com/jobs/8745-full-stack-functional-web-engineer-at-front-row-education Senior Software Engineer at McGraw-Hill Education http://functionaljobs.com/jobs/8744-senior-software-engineer-at-mcgraw-hill-education Cheers, Sean Murphy FunctionalJobs.com -- 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: Advice for building backend REST services from scratch using clojure
Hey Colin - thanks for the kind words! And I must apologise for my last previous comment too - I actually meant to come back and do so but didn't for whatever reason. It was one of those comments that sounded better in my head than when I saw it written down later - I'm sorry about that. I'm sure your team are very happy with you, even with the backlog work :-) Anyway, I'm glad you're liking Cursive, thanks for taking the time to come back and say so! It almost definitely has had a lot of the rough edges filed off since you tried it last. I actually used Emacs for years when I was writing C++ - it's a long time ago now but I have memories of a huge amount of yak-shaving on an ongoing basis. I suspect it's a much better experience when writing Clojure though, and the various Emacs packages have come a long way since then too. But I'm really glad you're finding Cursive a compelling alternative. Now that I have a good infrastructure written I'm starting to add functionality that plays to IntelliJ's strengths too, which is pretty exciting. BTW the latest release actually finally fixes the keybinding issue too: https://cursiveclojure.com/userguide/keybindings.html. People have been complaining about that for far too long! On 7 October 2014 00:04, Colin Yates wrote: > Just FYI - I got a new laptop and thought I would give it another > look-see. Consider me impressed. I maybe didn't spend enough time with it, > but a lot of the rough edges have been smoothed out, the performance seems > to have increased, it is just a really nice place to be. > > To be clear, emacs rocks, it can do anything, it just doesn't do > everything out of the box. Emacs Prelude goes a long long way, and the > paredit (or smart-parens now?), tight repl integration, undo-tree and magit > are still the best implementations I have seen anywhere, but sad to say, > when viewed under a "no time, got to get things done" coupled with > "consistency across developers", it didn't hold up too well. To put it > another way, I am admitting defeat - emacs is sufficient, the time I have > to learn and teach emacs is insufficient. Cursive still requires some > pampering (setting up keymaps etc.) and there are still some rough edges > (being able to delete delimiters and not be able to add them back for > example), but for the 80/20 rule, it rocks. > > And IntelliJ is also a very nice place to be. > > Consider my words firmly eaten :). > > (Oh, and according to my team you still wouldn't want to work with me :). > Off to find some horrible backlog work for them now!). > > On Friday, 11 April 2014 12:34:04 UTC+1, Colin Fleming wrote: >> >> No worries, I didn't think what you wrote was inflammatory and it's >> undeniable that Emacs has the largest mindshare in the Clojure world. But >> the alternatives are getting better and better and I think I could make a >> reasonable case that Cursive is better than Emacs for some circumstances >> and/or projects. I personally didn't like the initial versions of >> LightTable (it felt like a bit of a one-trick pony and the trick didn't >> really work for me) but the guys working on it are smart and I'm sure it's >> getting a lot of plugin love now it's open source, so I'm sure that'll be a >> real contender soon if it isn't already. >> >> Emacs clearly works for the OP so there's no issue there, but I think >> it's less and less a foregone conclusion that everyone will end up there. I >> personally wouldn't work for you if you forced me to use it, but that's >> just me :-) >> >> >> On 11 April 2014 22:04, Colin Yates wrote: >> >>> Colin - you are right - I shouldn't throw out such inflammatory marks, >>> particularly when they do a disservice to the excellent work done in >>> Cursive Clojure, Lighttable and Counter Clockwise (and others that I am not >>> aware off). >>> >>> For me personally, after years of using Eclipse then IntelliJ and (to a >>> much lesser degree) Sublime I am forcing my team to use emacs. And yes, >>> forcing is the word as they are utterly sold on sublime and really don't >>> like me much at the moment :). >>> >>> It is the classical short term/long term win, and emacs is worth the >>> investment for us. But it absolutely is an investment. >>> >>> Disclaimer - I haven't looked at any of the other editors for months if >>> not years. >>> >>> >>> On Friday, April 11, 2014 10:20:37 AM UTC+1, Colin Fleming wrote: >>> you can fight it as hard as you like but you will eventually end up > using emacs, clojure-mode, cider, paredit and magit and then wonder how > you > ever lived without it, but not without spending at least a month or two > cursing anything to do with emacs :). > As the developer of Cursive, I'd like to politely disagree with this point. I think that Cursive provides a very competitive feature set but without the swearing :-). Of course I'm totally biased, so take with a grain of salt, but I think particularly for Clojure newbies
Do this or that
Here's a style question: If you have to conditionally do one set of side effects or another set, is your preference to use when and when-not, or an if containing do blocks? Or perhaps some other construct? In terms of a concrete example: (let [boolean-value (some-predicate?)] (when boolean-value (do-alpha) (do-beta)) (when-not boolean-value (do-gamma) (do-delta))) or: (if (some-predicate?) (do (do-alpha) (do-beta)) (do (do-gamma) (do-delta))) -- 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] async-sockets - work with sockets using core.async channels
Could you please expand on this, Zach? > Please note that if you use core.async with java.nio, you need to make > sure backpressure is properly propagated (this happens automatically with > java.io, assuming you have a thread per connection) > Thanks! -- 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: Do this or that
The latter is what I'd consider to be the correct approach. If the do blocks become unwieldy, you can factor them out into functions. - James On 7 October 2014 02:16, Mike Fikes wrote: > Here's a style question: If you have to conditionally do one set of side > effects or another set, is your preference to use when and when-not, or > an if containing do blocks? Or perhaps some other construct? > > In terms of a concrete example: > > (let [boolean-value (some-predicate?)] > (when boolean-value > (do-alpha) > (do-beta)) > (when-not boolean-value > (do-gamma) > (do-delta))) > > or: > > (if (some-predicate?) > (do > (do-alpha) > (do-beta)) > (do > (do-gamma) > (do-delta))) > > -- > 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.
Re: Do this or that
I agree with James. The first can be tempting when you're doing side effect heavy code (which should probably cause you to take a double take on how you got to this point anyhow) but the most glaring issue that is all too easy to overlook is that they aren't actually equivalent expressions. Even with side effecting expressions, using an if here reinforces the notion that you are conditionally returning one of two values, not conditionally executing two different blocks of statements. On Monday, October 6, 2014 9:49:33 PM UTC-4, James Reeves wrote: > > The latter is what I'd consider to be the correct approach. > > If the do blocks become unwieldy, you can factor them out into functions. > > - James > > On 7 October 2014 02:16, Mike Fikes > > wrote: > >> Here's a style question: If you have to conditionally do one set of side >> effects or another set, is your preference to use when and when-not, or >> an if containing do blocks? Or perhaps some other construct? >> >> In terms of a concrete example: >> >> (let [boolean-value (some-predicate?)] >> (when boolean-value >> (do-alpha) >> (do-beta)) >> (when-not boolean-value >> (do-gamma) >> (do-delta))) >> >> or: >> >> (if (some-predicate?) >> (do >> (do-alpha) >> (do-beta)) >> (do >> (do-gamma) >> (do-delta))) >> >> -- >> 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.
Re: Do this or that
I agree - I always use the second form. Generally I find that I often need a let-block for each branch of the if, so I nearly always avoid the need for an explicit 'do'. On 7 October 2014 14:54, wrote: > I agree with James. The first can be tempting when you're doing side > effect heavy code (which should probably cause you to take a double take on > how you got to this point anyhow) but the most glaring issue that is all > too easy to overlook is that they aren't actually equivalent expressions. > Even with side effecting expressions, using an if here reinforces the > notion that you are conditionally returning one of two values, not > conditionally executing two different blocks of statements. > > On Monday, October 6, 2014 9:49:33 PM UTC-4, James Reeves wrote: >> >> The latter is what I'd consider to be the correct approach. >> >> If the do blocks become unwieldy, you can factor them out into functions. >> >> - James >> >> On 7 October 2014 02:16, Mike Fikes wrote: >> >>> Here's a style question: If you have to conditionally do one set of side >>> effects or another set, is your preference to use when and when-not, or >>> an if containing do blocks? Or perhaps some other construct? >>> >>> In terms of a concrete example: >>> >>> (let [boolean-value (some-predicate?)] >>> (when boolean-value >>> (do-alpha) >>> (do-beta)) >>> (when-not boolean-value >>> (do-gamma) >>> (do-delta))) >>> >>> or: >>> >>> (if (some-predicate?) >>> (do >>> (do-alpha) >>> (do-beta)) >>> (do >>> (do-gamma) >>> (do-delta))) >>> >>> -- >>> 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.
