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 colin...@gmail.com javascript: 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 colin...@gmail.com 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 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
Re: [ANN] Monroe 0.1.0 - nrepl client for Emacs
Bozhidar Batsov bozhidar.bat...@gmail.com 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! c) without consuming the value, the 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 (! c), and the producer unparks 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, adrian...@mail.yu.edu javascript: 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, adrian...@mail.yu.edu 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 a209...@trbvm.com 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 behaviors. At that point, you'd probably be better off just writing a consumer that splits off the pred-matching items into one out channel and feeds everything else into a second channel, with your original consumer taking from the first of these and the others taking from the second. That gets you the block until version of
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 colin.ya...@gmail.com 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 colin...@gmail.com 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
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 mikefike...@gmail.com 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 mikef...@gmail.com javascript: 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 javascript: 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 javascript: 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 javascript:. 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, adrian.med...@mail.yu.edu 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 mikef...@gmail.com 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.
