Default implementation for defprotocol
Is there a way to provide a default (fallback) implementation for a method defined in a defprotocol directive? I do realize that I could extend the protocol for type java.lang.Object, but this raises the question about how protocol implementations with extend are sorted, i.e. how specializations of types of the same hierarchy are resolved. Is the most specialized implementation used if I implement a protocol for a class as well as its parent class and if yes, is this independent of the order of definition for the protocol extensions? -- 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: Default implementation for defprotocol
That's correct, the most specialized implementation is used. In the case where more there is no implementation more specialized than another (two interfaces are extended to a protocol and a class implements both) then an arbitrary implementation from the available ones will be selected. Extending a Object and nil to a protocol is a good way to provide a default impl. Another option is to wrap the protocol functions in another function and testing for satisfies?. Il giorno 17/nov/2014 10.49, pmf phil.fr...@gmx.de ha scritto: Is there a way to provide a default (fallback) implementation for a method defined in a defprotocol directive? I do realize that I could extend the protocol for type java.lang.Object, but this raises the question about how protocol implementations with extend are sorted, i.e. how specializations of types of the same hierarchy are resolved. Is the most specialized implementation used if I implement a protocol for a class as well as its parent class and if yes, is this independent of the order of definition for the protocol extensions? -- 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.
Weird performance issue with reduce
Hi all, I understand that the following question is a long shot without any proper proof/tests from my side but it's a little bit difficult to make a test case from the specific part of my app so I will just ask anyway in case anyone knows anything. The situation is like this: - I have a hashmap with *3386* items that I pass through few functions in order to append new keys or update existing ones to each hashmap entry. - Each hashmap item has 20 keys with various data types (mostly strings) - All my transformation functions use `reduce`. The problem: I have a top level function which I inside it I call 7 other functions (all written by me) and for some reason I haven't discovered is that it needs around 2 seconds to return a result even though the items aren't many. Now, i used `time` to benchmark each function and when I found which one is taking a lot of time to return, after I removed it, I discovered that the problem still existed but now moved on to a different function. I did a bunch of tests with those 3386 on the REPL and reduce but I didn't notice anything weird/slow so it must be a combination of things. Also, i doubt that this is a RAM problem, i have allocated 4GB for the JVM. So, my question is, has anyone every seen a situation like this with a bunch of `reduce` calls? Is there anything at all that I should check and maybe missed it? Regards Alex -- 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: Weird performance issue with reduce
I would look for unncessary object creation inside reduction function (use transients) and lazy seq realization (realize only what you really need). Calling reduce inside reduce (inside reduce...) may easily make the complexity of your code exponential. Consider caching of intermediate results if that's the case. You can also consider switching to reducers/transducers, which may clean your design. In that case, the call to reduce should be as high in hierarchy as possible, ideally in your top level function, with other functions dealing with the transformation of 'step' values. Jozef On Mon, Nov 17, 2014 at 11:28 AM, Alexander L. alexander.lo...@gmail.com wrote: Hi all, I understand that the following question is a long shot without any proper proof/tests from my side but it's a little bit difficult to make a test case from the specific part of my app so I will just ask anyway in case anyone knows anything. The situation is like this: - I have a hashmap with *3386* items that I pass through few functions in order to append new keys or update existing ones to each hashmap entry. - Each hashmap item has 20 keys with various data types (mostly strings) - All my transformation functions use `reduce`. The problem: I have a top level function which I inside it I call 7 other functions (all written by me) and for some reason I haven't discovered is that it needs around 2 seconds to return a result even though the items aren't many. Now, i used `time` to benchmark each function and when I found which one is taking a lot of time to return, after I removed it, I discovered that the problem still existed but now moved on to a different function. I did a bunch of tests with those 3386 on the REPL and reduce but I didn't notice anything weird/slow so it must be a combination of things. Also, i doubt that this is a RAM problem, i have allocated 4GB for the JVM. So, my question is, has anyone every seen a situation like this with a bunch of `reduce` calls? Is there anything at all that I should check and maybe missed it? Regards Alex -- 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: Weird performance issue with reduce
Thanks for the input Jozef. I just want to clarify that I am not doing any nested reduce calls within my code. Alex On Monday, November 17, 2014 1:00:43 PM UTC+2, Jozef Wagner wrote: I would look for unncessary object creation inside reduction function (use transients) and lazy seq realization (realize only what you really need). Calling reduce inside reduce (inside reduce...) may easily make the complexity of your code exponential. Consider caching of intermediate results if that's the case. You can also consider switching to reducers/transducers, which may clean your design. In that case, the call to reduce should be as high in hierarchy as possible, ideally in your top level function, with other functions dealing with the transformation of 'step' values. Jozef On Mon, Nov 17, 2014 at 11:28 AM, Alexander L. alexand...@gmail.com javascript: wrote: Hi all, I understand that the following question is a long shot without any proper proof/tests from my side but it's a little bit difficult to make a test case from the specific part of my app so I will just ask anyway in case anyone knows anything. The situation is like this: - I have a hashmap with *3386* items that I pass through few functions in order to append new keys or update existing ones to each hashmap entry. - Each hashmap item has 20 keys with various data types (mostly strings) - All my transformation functions use `reduce`. The problem: I have a top level function which I inside it I call 7 other functions (all written by me) and for some reason I haven't discovered is that it needs around 2 seconds to return a result even though the items aren't many. Now, i used `time` to benchmark each function and when I found which one is taking a lot of time to return, after I removed it, I discovered that the problem still existed but now moved on to a different function. I did a bunch of tests with those 3386 on the REPL and reduce but I didn't notice anything weird/slow so it must be a combination of things. Also, i doubt that this is a RAM problem, i have allocated 4GB for the JVM. So, my question is, has anyone every seen a situation like this with a bunch of `reduce` calls? Is there anything at all that I should check and maybe missed it? Regards Alex -- 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: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library
Wow! I've awaited the moment of pure cljs solution as kontrapunkt in symphony of declarative DOM which has begun with React overture ;-) Do I correctly understand, that freactive does not care about tag names, and I can use any ones (potentially injecting polymer or smth like pieces)? понедельник, 17 ноября 2014 г., 5:20:40 UTC+3 пользователь Aaron написал: freactive (pronounced f reactive for functional reactive) is a new high performance, pure Clojurescript, declarative DOM library: https://github.com/aaronc/freactive It has a syntax very similar to that of Reagent and was in fact inspired by Reagent, Om, and others. I came up with it when I was doing some DOM programming after having spending a fair amount of time working with JavaFX (see my soon to be announced library fx-clj: https://github.com/aaronc/fx-clj). I thought Om and Reagent were very nice to work with (and actually inspired some what I did with fx-clj), but I felt from my desktop GUI experience, that I could take things a few steps further. freactive's main advantages over existing solutions are probably built-in animations support and slightly higher performance. Here are it's goals from the README: - Provide a *simple, intuitive API https://github.com/aaronc/freactive/#hello-world* that should be almost obvious to those familiar with Clojure (inspiration from reagent https://github.com/reagent-project/reagent) - Allow for *high-performance https://github.com/aaronc/freactive/#performance* rendering *good enough for animated graphics http://aaronc.github.io/freactive/dom-perf* based on a purely declarative syntax - Allow for *reactive binding of any attribute, style property or child node* - Allow for *coordinated management of state via cursors https://github.com/aaronc/freactive/#cursors* (inspiration from om https://github.com/swannodette/om) - Provide *deeply-integrated animation https://github.com/aaronc/freactive/#animations* support - Allow for cursors based on paths as well as *lenses* - Provide a generic items view component https://github.com/aaronc/freactive/#items-view for *efficient viewing of large data sets* - *Minimize unnecessary triggering of update events* - Coordinate all updates via *requestAnimationFrame* wherever possible - Be easy to debug https://github.com/aaronc/freactive/#debugging-reactive-expressions - Be written in *pure Clojurescript* - Provide support for older browsers via polyfills (not yet implemented) Any feedback is welcome!! I'm not sure I like the name freactive - but it was the best I could think of at the time. Suggestions for alternative names are welcome. -- 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 1.7.0-alpha4 now available
Hi, Thumbs up from my side. The compilation issues with too long filenames in my projects on my system are gone now (CLJ-1330). No perf degradation either :-). Thanks Stefan -- 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] freactive - high performance, pure Clojurescript, declarative DOM library
Wow! Amazing! I see some ClojureCLR code in this repository, but from brief look it's not clear why is it there. Are you also experimenting on CLR support? Anyway, great that it finally happened! On Monday, November 17, 2014 3:20:29 AM UTC+1, Aaron Craelius wrote: freactive (pronounced f reactive for functional reactive) is a new high performance, pure Clojurescript, declarative DOM library: https://github.com/aaronc/freactive It has a syntax very similar to that of Reagent and was in fact inspired by Reagent, Om, and others. I came up with it when I was doing some DOM programming after having spending a fair amount of time working with JavaFX (see my soon to be announced library fx-clj: https://github.com/aaronc/fx-clj). I thought Om and Reagent were very nice to work with (and actually inspired some what I did with fx-clj), but I felt from my desktop GUI experience, that I could take things a few steps further. freactive's main advantages over existing solutions are probably built-in animations support and slightly higher performance. Here are it's goals from the README: Provide a simple, intuitive API that should be almost obvious to those familiar with Clojure (inspiration from reagent)Allow for high-performance rendering good enough for animated graphics based on a purely declarative syntaxAllow for reactive binding of any attribute, style property or child node Allow for coordinated management of state via cursors (inspiration from om)Provide deeply-integrated animation supportAllow for cursors based on paths as well as lenses Provide a generic items view component for efficient viewing of large data sets Minimize unnecessary triggering of update eventsCoordinate all updates via requestAnimationFrame wherever possibleBe easy to debug Be written in pure Clojurescript Provide support for older browsers via polyfills (not yet implemented) Any feedback is welcome!! I'm not sure I like the name freactive - but it was the best I could think of at the time. Suggestions for alternative names are welcome. -- 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: [JOBS] Remote Clojure Developers Wanted
Hi Eric I have been doing Clojure for about a year ,please find my Resume. Thanks a lot Best Regards Shahrdad On Fri, Sep 5, 2014 at 1:12 PM, Eric Normand ericwnorm...@gmail.com wrote: Hi there! BuyHappy is growing and we need more Clojure developers! Our stack is Clojure and ClojureScript. We've got some great projects lined up, including an Om-based site. We use core.async, test.check, and lots of other amazing tools. Our dev team is 50% remote. US only. Very flexible work environment. A team that will push you to learn new techniques and solve new problems. There's much more information here: http://buyhappy.co/jobs.html Please contact me at my work email: e...@buyhappy.co Thanks Eric -- 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. -- Best Regards Shahrdad Shadab Senior Software Developer -- 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. Resume.doc Description: MS-Word document
Re: Weird performance issue with reduce
Your description doesn't raise any particular issues in my mind, other than a suggestion to try a JVM profiler to see if it helps you find anything, e.g. free trial of YourKit. Andy On Mon, Nov 17, 2014 at 2:28 AM, Alexander L. alexander.lo...@gmail.com wrote: Hi all, I understand that the following question is a long shot without any proper proof/tests from my side but it's a little bit difficult to make a test case from the specific part of my app so I will just ask anyway in case anyone knows anything. The situation is like this: - I have a hashmap with *3386* items that I pass through few functions in order to append new keys or update existing ones to each hashmap entry. - Each hashmap item has 20 keys with various data types (mostly strings) - All my transformation functions use `reduce`. The problem: I have a top level function which I inside it I call 7 other functions (all written by me) and for some reason I haven't discovered is that it needs around 2 seconds to return a result even though the items aren't many. Now, i used `time` to benchmark each function and when I found which one is taking a lot of time to return, after I removed it, I discovered that the problem still existed but now moved on to a different function. I did a bunch of tests with those 3386 on the REPL and reduce but I didn't notice anything weird/slow so it must be a combination of things. Also, i doubt that this is a RAM problem, i have allocated 4GB for the JVM. So, my question is, has anyone every seen a situation like this with a bunch of `reduce` calls? Is there anything at all that I should check and maybe missed it? Regards Alex -- 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: Clojure meetup in Rochester, NY?
Hi Tom, it may not be much consolation. But I run the functional programming meetup over here in Buffalo. http://www.meetup.com/Definitely-Fun-Buffalo-Functional-Programming-Meetup/ Not huge, but we're a small group of FP enthusiasts in the area and not that far away from you if you can't get anything going in Rochester. We're currently trying to find a new interim spot to host our meetups well our parent organization(The Buffalo Game Space), gets its own space back. Feel free to hit me up! On Thursday, November 13, 2014 9:08:00 PM UTC-5, Tom George wrote: Hi everyone, I wonder if there are any people in the Rochester, NY area that are on this mailing list that would like to set up a meetup to talk about cool Clojure stuff. I did some digging and I see that RocLisp was a thing a couple years ago. Their twitter has been dead since 2012 and their website no longer exists. Anyway, if theres any interest in the Greater Rochester area, I'd love to get something going. Drop me an email or reply to this if you are interested! Tom tg8...@gmail.com javascript: tge...@paychex.com javascript: -- 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: [JOBS] Remote Clojure Developers Wanted
My Apologies to the group. Please disregard my last email. Thanks a lot Best Regards Shahrdad On Mon, Nov 17, 2014 at 11:17 AM, shahrdad shadab clojure.langu...@gmail.com wrote: Hi Eric I have been doing Clojure for about a year ,please find my Resume. Thanks a lot Best Regards Shahrdad On Fri, Sep 5, 2014 at 1:12 PM, Eric Normand ericwnorm...@gmail.com wrote: Hi there! BuyHappy is growing and we need more Clojure developers! Our stack is Clojure and ClojureScript. We've got some great projects lined up, including an Om-based site. We use core.async, test.check, and lots of other amazing tools. Our dev team is 50% remote. US only. Very flexible work environment. A team that will push you to learn new techniques and solve new problems. There's much more information here: http://buyhappy.co/jobs.html Please contact me at my work email: e...@buyhappy.co Thanks Eric -- 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. -- Best Regards Shahrdad Shadab Senior Software Developer -- Best Regards Shahrdad Shadab Senior Software Developer -- 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] freactive - high performance, pure Clojurescript, declarative DOM library
This is really cool (especially if what Ruslan said is the case). What would the best practice be for stateful effects? Do you have any plans of adding the equivalent of React's lifecycle methods? Also, the reagent comparison doesn't work over https, because you use the http version of React.js. -- 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.
[ANN] s3-journal, a library for high-throughput log journaling
Today Factual is open sourcing two libraries, the first of which is a relatively simple library that journals data to Amazon's S3 service [1], and buffers data on disk using durable-queue [2], making it much more robust than most S3 clients to process failure, network issues, and a host of other issues. We have used it to write over a trillion entries this year, and expect it will become equally indispensable for others in the Clojure community. A blog post describing it in more detail can be found at http://blog.factual.com/how-factual-uses-persistent-storage-for-its-real-time-services. The library itself can be found at https://github.com/factual/s3-journal. Zach [1] http://aws.amazon.com/s3/ [2] https://github.com/factual/durable-queue -- 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.
[ANN] riffle, a high-performance write-once key/value storage engine
The second of the libraries Factual is open sourcing today is Riffle, which is a write-once key/value storage engine. By disallowing random writes, it allows for O(1) on-disk reads, and a read throughput is both faster and significantly more stable than LevelDB and other, similar databases. Of course, any changes to the database require merging two existing databases or writing another one from scratch, which can be done either in-process or using Hadoop. A blog post describing the library can be found at http://blog.factual.com/how-factual-uses-persistent-storage-for-its-real-time-services, and the library itself can be found at https://github.com/factual/riffle. We look forward to see how it's used by others. Zach -- 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: Weird performance issue with reduce
What version of Clojure are you using? This seems like a use case where transducers could help significantly in avoiding lazy effects and intermediate objects. On Monday, November 17, 2014 4:28:12 AM UTC-6, Alexander L. wrote: Hi all, I understand that the following question is a long shot without any proper proof/tests from my side but it's a little bit difficult to make a test case from the specific part of my app so I will just ask anyway in case anyone knows anything. The situation is like this: - I have a hashmap with *3386* items that I pass through few functions in order to append new keys or update existing ones to each hashmap entry. - Each hashmap item has 20 keys with various data types (mostly strings) - All my transformation functions use `reduce`. The problem: I have a top level function which I inside it I call 7 other functions (all written by me) and for some reason I haven't discovered is that it needs around 2 seconds to return a result even though the items aren't many. Now, i used `time` to benchmark each function and when I found which one is taking a lot of time to return, after I removed it, I discovered that the problem still existed but now moved on to a different function. I did a bunch of tests with those 3386 on the REPL and reduce but I didn't notice anything weird/slow so it must be a combination of things. Also, i doubt that this is a RAM problem, i have allocated 4GB for the JVM. So, my question is, has anyone every seen a situation like this with a bunch of `reduce` calls? Is there anything at all that I should check and maybe missed it? Regards Alex -- 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: If code is data why do we use text editors?
Hi Phil, thanks for your reply. The source data structure doesn't have to contain only bare source code. It could contain everything that is in a text file, but just saved in a structured way. The data needs to be compiled to bytecode anyway. I'm not sure if diffing is a huge problem. You can still pretty print you source data and save it into a text file. Diffing these files should be enough to get an idea what was changed. And if not a special diffing tool would have other advantages to I think. Finally, source code is often wrong, or a work in progress. Okay, with paredit, Clojure can be mostly kept correct (syntactically) most of the time, but lisp is the oddity, and you need all the brackets to enable this. Even with paredit, for me, editing in this way fails often enough for me, that I wrote something to switch paredit off rapidly, and then back on again when I've fixed it. You can still save your programm as a data structure even if its wrong. Or am I missing your point? Thomas Am Freitag, 14. November 2014 18:05:47 UTC+1 schrieb Phillip Lord: I can think of several reasons. First and most important, code is data, but source files are not code. They are source and include many things a lot of which do not obey the syntactic rules of the language. Comments and indentation are the most obvious ones. Second, reason is that not only do you need a special tool for editing, you need a special tool for diffing as well. And version control. Maybe you will have to rewrite these for every language now, rather than using the lowest common denominator line-orientated syntax. Also, you will have to update your editing environment for every new version of the language. Finally, source code is often wrong, or a work in progress. Okay, with paredit, Clojure can be mostly kept correct (syntactically) most of the time, but lisp is the oddity, and you need all the brackets to enable this. Even with paredit, for me, editing in this way fails often enough for me, that I wrote something to switch paredit off rapidly, and then back on again when I've fixed it. It sounds like a nice idea, but I think it's not. In fact, one of the motivations behind my clojure library (Tawny-OWL) was to move away from manipulating a program (well, not a program, but a complex, formal data structure, but it's the same thing) by changing an live data structure, and move toward a flat file that has to be parsed. Sounds like a backwards step, but isn't. Phil Thomas Huber th0mas...@googlemail.com javascript: writes: Hi, here is an idea that has been in my mind for a while. I wonder what you think about it. In Clojure code is data, right? But when we program we manipulate flat text files, not the data directly. Imagine your source code where a data structure (in memory). And programming is done by manipulating this data structure. No text editor and text files involved. Your editor directly manipulates the source data and later saves it on disk (maybe as a text file). These are the benefits I can think of: - It enables you to use any Clojure function to manipulate your source „code“. Giving you hole new opportunities for refactoring.This functions can be provides as library. - Really nice auto complete. - Visual programming. Source code can be represented in many different ways (not just text) . The easiest example I can think of is color. It can be represented as text of course (#23FF02) but that’s a quite bad interface for humans. Why not display the actual color and provide a color picker? Or what about music notes? Or Math formulars? Or what about a tree view to move and rename functions like files? This could all be implemented in a way that every library can ship there own „views“. I think this „views“ are basically macros that are not limited to text. - You don’t have to worry that you text files are in the same state as your JVM (when developing interactive). You only work on your sourcedata and it gets loaded into the JVM automatically. - Answer questions about your source code. What is the most called function? Who depends on this namespace? Where is this function used? What is the biggest function? Thinks like that become easy. Again you can ship this queries as a library. The drawback is you can’t simply program using any text editor. You need a special tool. But we have that anyway (syntax highlighting, paredit etc.). Nobody programs using a bare text editor. Maybe this idea is not new? What do you think? -- Phillip Lord, Phone: +44 (0) 191 208 7827 Lecturer in Bioinformatics, Email: philli...@newcastle.ac.uk javascript: School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord
Re: If code is data why do we use text editors?
Yes that s ounds quite reasonable to me Am Freitag, 14. November 2014 18:01:04 UTC+1 schrieb Jan-Paul Bultmann: Yeah this would be awesome, but sadly representing Clojure code as data is as hard as representing Java. All the reader macros make it a nightmare, and the closest thing you'll get is tools.analyzer AST nodes. Session is certainly a step in the right direction, and I wish more people would embrace it, but it works on text as well. Same pretty much goes for codeq, if that is not dead. One could define a Clojure subset that is valid EDN though, which would make everything from serialisable functions to a nano-pass compiler a lot easier. This has to be the first step imho. Cheers Jan On 14 Nov 2014, at 17:09, atucker agjf@gmail.com javascript: wrote: re As I understand it, Session https://github.com/kovasb/session and codeq https://github.com/Datomic/codeq are tools that somehow keep your code in a database instead of plain text. On Friday, 14 November 2014 12:42:57 UTC, Thomas Huber wrote: Hi, here is an idea that has been in my mind for a while. I wonder what you think about it. In Clojure code is data, right? But when we program we manipulate flat text files, not the data directly. Imagine your source code where a data structure (in memory). And programming is done by manipulating this data structure. No text editor and text files involved. Your editor directly manipulates the source data and later saves it on disk (maybe as a text file). These are the benefits I can think of: - It enables you to use any Clojure function to manipulate your source „code“. Giving you hole new opportunities for refactoring.This functions can be provides as library. - Really nice auto complete. - Visual programming. Source code can be represented in many different ways (not just text) . The easiest example I can think of is color. It can be represented as text of course (#23FF02) but that’s a quite bad interface for humans. Why not display the actual color and provide a color picker? Or what about music notes? Or Math formulars? Or what about a tree view to move and rename functions like files? This could all be implemented in a way that every library can ship there own „views“. I think this „views“ are basically macros that are not limited to text. - You don’t have to worry that you text files are in the same state as your JVM (when developing interactive). You only work on your sourcedata and it gets loaded into the JVM automatically. - Answer questions about your source code. What is the most called function? Who depends on this namespace? Where is this function used? What is the biggest function? Thinks like that become easy. Again you can ship this queries as a library. The drawback is you can’t simply program using any text editor. You need a special tool. But we have that anyway (syntax highlighting, paredit etc.). Nobody programs using a bare text editor. Maybe this idea is not new? What do you think? -- 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: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library
Do I correctly understand, that freactive does not care about tag names, and I can use any ones (potentially injecting polymer or smth like pieces)? Yes! It tries to work with pure DOM nodes wherever possible. In freactive, Clojurescript vectors are virtual DOM - so the hiccup vectors are very close to the actual DOM. Although it may not work quite yet, you should even be able to inject DOM nodes you created outside of freactive's rendering framework and it will treat them opaquely. -- 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] freactive - high performance, pure Clojurescript, declarative DOM library
On Monday, November 17, 2014 9:19:29 AM UTC-5, Max Gonzih wrote: Wow! Amazing! I see some ClojureCLR code in this repository, but from brief look it's not clear why is it there. Are you also experimenting on CLR support? Yes, I'm not sure if it's in a working state right now, but I was experimenting with it - I should add that to the docs. The way this started actually is I wanted some reactive atoms for JavaFX. I also have done a lot of work with WPF - see my ClojureWPF: https://github.com/aaronc/ClojureWpf - so I wanted to integrate it there too, but alas... I'm mostly moving away from .NET these days... but I started out as a ClojureCLR dev. -- 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] freactive - high performance, pure Clojurescript, declarative DOM library
I've played a little bit with freactive today, and investigated this idea with using polymer components — it works! I'm unsure of right usage of rx, especially on conditional rendering — (rx (if @state ... does autorerendering, but (rx (if (:key @state) ... does not. And there are some questions about how to structure app properly. I'm too tired to formulate them today, but bigger than performance demo examples and more documentation are welcome, because I'm very enthusiastic to use freactive in real projects! понедельник, 17 ноября 2014 г., 22:18:45 UTC+3 пользователь Aaron написал: Do I correctly understand, that freactive does not care about tag names, and I can use any ones (potentially injecting polymer or smth like pieces)? Yes! It tries to work with pure DOM nodes wherever possible. In freactive, Clojurescript vectors are virtual DOM - so the hiccup vectors are very close to the actual DOM. Although it may not work quite yet, you should even be able to inject DOM nodes you created outside of freactive's rendering framework and it will treat them opaquely. -- 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] freactive - high performance, pure Clojurescript, declarative DOM library
On Sunday, November 16, 2014 8:20:29 PM UTC-6, Aaron Craelius wrote: freactive (pronounced f reactive for functional reactive) is a new high performance, pure Clojurescript, declarative DOM library: https://github.com/aaronc/freactive It has a syntax very similar to that of Reagent and was in fact inspired by Reagent, Om, and others. I came up with it when I was doing some DOM programming after having spending a fair amount of time working with JavaFX (see my soon to be announced library fx-clj: https://github.com/aaronc/fx-clj). I thought Om and Reagent were very nice to work with (and actually inspired some what I did with fx-clj), but I felt from my desktop GUI experience, that I could take things a few steps further. freactive's main advantages over existing solutions are probably built-in animations support and slightly higher performance. Here are it's goals from the README: Provide a simple, intuitive API that should be almost obvious to those familiar with Clojure (inspiration from reagent)Allow for high-performance rendering good enough for animated graphics based on a purely declarative syntaxAllow for reactive binding of any attribute, style property or child node Allow for coordinated management of state via cursors (inspiration from om)Provide deeply-integrated animation supportAllow for cursors based on paths as well as lenses Provide a generic items view component for efficient viewing of large data sets Minimize unnecessary triggering of update eventsCoordinate all updates via requestAnimationFrame wherever possibleBe easy to debug Be written in pure Clojurescript Provide support for older browsers via polyfills (not yet implemented) Any feedback is welcome!! I'm not sure I like the name freactive - but it was the best I could think of at the time. Suggestions for alternative names are welcome. How does it perform its dom-diffing? -- 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] freactive - high performance, pure Clojurescript, declarative DOM library
On Monday, November 17, 2014 12:02:32 PM UTC-5, Diogo Almeida wrote: This is really cool (especially if what Ruslan said is the case). What would the best practice be for stateful effects? Do you have any plans of adding the equivalent of React's lifecycle methods? So I plan to write more about this soon as I have it all more or less worked out in my head. Briefly, :on-show and :on-hide are lifecycle callbacks - I intend to rename them to something like :did-mount and :will-unmount respectively. The only other lifecycle callbacks make sense in freactive's update cycle are :will-mount and :did-unmount - but I'm not even sure there is a use case or it's a good idea. freactive tries to manage state in a different way that is fundamentally tied to IDeref watches (and invalidation watches which aren't yet documented). Input definitely welcome as these facilities are developed. As for state transitions, they will be based on the data-state attribute and have :on-state and :after-state callbacks. The recommended way will be to use a state-machine ref bound to :data-state - I also have this more or less worked out in my head... more details soon. Also, the reagent comparison doesn't work over https, because you use the http version of React.js. Fixed! http://aaronc.github.io/freactive-reagent-comparison/ -- 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] freactive - high performance, pure Clojurescript, declarative DOM library
On Monday, November 17, 2014 2:32:18 PM UTC-5, Shaun LeBron wrote: How does it perform its dom-diffing? So, it does not actually do diffing. It is very close to being able to, but if this is added it will be sort of an extra optimization as opposed to a core algorithm. Instead of diffing, changes are bound directly to the site they are to be applied using rx's and atoms directly on attributes, style properties, text nodes and DOM nodes. So, changes are detected and applied more locally so there is in most cases very little to diff. The only case where it might be needed is for large collections, but that's where the items-view or collections-view comes in (more on this coming soon I hope) - which will be much more scalable than diffing. All this is how any serious desktop GUI framework does it (like Qt/QML, JavaFX, WPF) and freactive is just trying to emulate that. Does that make it clear? -- 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] freactive - high performance, pure Clojurescript, declarative DOM library
On Monday, November 17, 2014 2:27:17 PM UTC-5, Ruslan Prokopchuk wrote: I've played a little bit with freactive today, and investigated this idea with using polymer components — it works! I'm unsure of right usage of rx, especially on conditional rendering — (rx (if @state ... does autorerendering, but (rx (if (:key @state) ... does not. And there are some questions about how to structure app properly. I'm too tired to formulate them today, but bigger than performance demo examples and more documentation are welcome, because I'm very enthusiastic to use freactive in real projects! Hope I can make the intended usage and specifics about update/invalidation behavior more clear - but probably another day as well. Structuring large apps is something we're figuring out as we go... -- 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.
[ANN] differ v0.1.0, a tool for creating, and applying, diffs on clojure(script) datastructures
https://github.com/Skinney/differ I needed a way to send diffs of data from a cljs web-app to a clj backend, and I found clojure.data/diff to be a pain to work with, so i created my own solution. It currently only supports maps (and nested maps...), but support for lists, vectors and sets is on the roadmap for the next version. This version is mostly for me to test with my own app, which currently only uses maps. -- 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.
Nginx filter module in java
Hi Xfeep Thank you for writing such a handy nginx module (nginx-clojure). I need to write a nginx filter which can log the response header in DB. Please tell me is it possible using nginx-clojure module. Regards Khan -- 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] freactive - high performance, pure Clojurescript, declarative DOM library
On Monday, November 17, 2014 2:42:38 PM UTC-5, Aaron wrote: On Monday, November 17, 2014 2:27:17 PM UTC-5, Ruslan Prokopchuk wrote: I've played a little bit with freactive today, and investigated this idea with using polymer components — it works! I'm unsure of right usage of rx, especially on conditional rendering — (rx (if @state ... does autorerendering, but (rx (if (:key @state) ... does not. And there are some questions about how to structure app properly. I'm too tired to formulate them today, but bigger than performance demo examples and more documentation are welcome, because I'm very enthusiastic to use freactive in real projects! Hope I can make the intended usage and specifics about update/invalidation behavior more clear - but probably another day as well. Structuring large apps is something we're figuring out as we go... Okay, this is what I want to say about structuring an app - I think the ideal way would be to have a single (rx (dispatch-state @state)) at the root of the app where dispatch-state is something like a multi-method. -- 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.
[ANN] seqspert-1.7.0-alpha4-1.0-SNAPSHOT now on Clojars - Merge big hash-maps, FAST !
Back in February, I posted about some prototype code I had put together that attempted an alternative approach to map-merging that promised to be faster and generate less churn than the standard approach. Glen Mailer suggested that I put it in a standalone library. At the time, I thought that this would not be possible because of its necessarily tight coupling to clojure.lang.PersistentHashMap, but then I found some more time, went away and had a go. Here it is: https://github.com/JulesGosnell/seqspert along with some other hash-set, vector and array related stuff that I have been playing with, instructions to set it up in Lein and example code to paste straight into the repl to see how well it performs in your test environment. Some simple testing indicates that the larger the map and the greater the number of threads that you can run in parallel, the better results you will see. I have seen 30x speedups on a 16-way box merging two hash-maps of 10M entries each. Please take a look at it and let me know about any issues, improvements, results etc - I'd be very interested to hear from you. I'll put out a stable release in a while, once interested parties have kicked the tyres a bit. regards, Jules -- 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: If code is data why do we use text editors?
To be honest I think that all the whitespace retaining approaches kinda miss the point. The reason code is mannually formatted is only because it consists of characters in a grid aka text. To me manual formatting is a chore, most of the time I rely on paredits or codemirrors auto formatting capabilities anyways. The ability to have a consistent idiomatic visual source structure enforced is a feature to me not a bug. cheers Jan On 17.11.2014, at 20:19, Thomas Huber th0mas.hu...@googlemail.com wrote: Yes that s ounds quite reasonable to me Am Freitag, 14. November 2014 18:01:04 UTC+1 schrieb Jan-Paul Bultmann: Yeah this would be awesome, but sadly representing Clojure code as data is as hard as representing Java. All the reader macros make it a nightmare, and the closest thing you'll get is tools.analyzer AST nodes. Session is certainly a step in the right direction, and I wish more people would embrace it, but it works on text as well. Same pretty much goes for codeq, if that is not dead. One could define a Clojure subset that is valid EDN though, which would make everything from serialisable functions to a nano-pass compiler a lot easier. This has to be the first step imho. Cheers Jan On 14 Nov 2014, at 17:09, atucker agjf@gmail.com wrote: re As I understand it, Session and codeq are tools that somehow keep your code in a database instead of plain text. On Friday, 14 November 2014 12:42:57 UTC, Thomas Huber wrote: Hi, here is an idea that has been in my mind for a while. I wonder what you think about it. In Clojure code is data, right? But when we program we manipulate flat text files, not the data directly. Imagine your source code where a data structure (in memory). And programming is done by manipulating this data structure. No text editor and text files involved. Your editor directly manipulates the source data and later saves it on disk (maybe as a text file). These are the benefits I can think of: - It enables you to use any Clojure function to manipulate your source „code“. Giving you hole new opportunities for refactoring.This functions can be provides as library. - Really nice auto complete. - Visual programming. Source code can be represented in many different ways (not just text) . The easiest example I can think of is color. It can be represented as text of course (#23FF02) but that’s a quite bad interface for humans. Why not display the actual color and provide a color picker? Or what about music notes? Or Math formulars? Or what about a tree view to move and rename functions like files? This could all be implemented in a way that every library can ship there own „views“. I think this „views“ are basically macros that are not limited to text. - You don’t have to worry that you text files are in the same state as your JVM (when developing interactive). You only work on your sourcedata and it gets loaded into the JVM automatically. - Answer questions about your source code. What is the most called function? Who depends on this namespace? Where is this function used? What is the biggest function? Thinks like that become easy. Again you can ship this queries as a library. The drawback is you can’t simply program using any text editor. You need a special tool. But we have that anyway (syntax highlighting, paredit etc.). Nobody programs using a bare text editor. Maybe this idea is not new? What do you think? -- 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
Re: If code is data why do we use text editors?
On Monday, November 17, 2014 5:20:36 PM UTC-5, Jan-Paul Bultmann wrote:
To be honest I think that all the whitespace retaining approaches kinda
miss the point.
The reason code is mannually formatted is only because it consists of
characters in a grid aka text. To me manual formatting is a chore, most of
the time I rely on paredits or codemirrors auto formatting capabilities
anyways.
The ability to have a consistent idiomatic visual source structure
enforced is a feature to me not a bug.
Disagree. There are lots of times when I use whitespace to enhance
readability in a way that would be destroyed by round-tripping through
read/pprint.
Example 1:
(reduce f1 #{}
(map f2
(some lengthy collection expr here)))
Most clojure tools and editor autoindents would like to indent that like
this instead:
(reduce f1 #{}
(map f2
(some lengthy collection expr here)))
but that's unaesthetic and wastes horizontal space. And
(reduce
f1
#{}
(map
f2
(some lengthy collection expr here)))
is unaesthetic and wastes vertical space. The original puts the smaller
arguments with the operator, and the big argument (the thing being
processed, rather than details of how it's being processed) onto the next
line, and strikes me as more readable. If it was nested a lot more deeply,
it might be better to use a threading macro, but
(- (some lengthy collection expr here)
(map f2)
(reduce f1 #{}))
seems like overkill for only two nesting levels of expressions. I'd like
the choice of using either threading macros OR indenting as if reduce f1
#{} was the operator and not just reduce. Giving the machine full
control of the whitespace would take away that choice.
Example 2:
[[(dec x) y wh ]
[x(dec y)wh ]
[xy (inc w) h ]
[xy w(inc h)]]
Sometimes I want tabular literal data, or a tabular expression, with
aligned columns. On the other hand, not every nest of vectors in vectors
(or other data structures) is actually tabular data. Consider
(let [[x y] (transform-pt x1 y1)
[a b c] (some-fn x y some-other-arg)
...]
...)
That probably should not be formatted with an attempt to align columns.
Other cases where I don't want alignment are not as easy to automatically
detect as exclude all binding vectors containing destructuring forms,
however. And not every case where I want columns involves vectors, either:
(cond
(pred1) (consequence1)
(pred2 x z) (consequence2))
When the preds and consequences are mostly not very long, this is often
nicely compact and readable. Of course, most autoindents also screw up
(cond
(pred1)
(consequence1)
(pred2 x z)
(consequence2))
preferring to eliminate the additional indentation of the consequences
which helps them to stand out from the conditions that decide which to
apply.
All of this, of course, is to say nothing of the minor issues of preserving
comments; preserving comment column alignments where desired; and
preserving commas where useful in literal data (though I personally tend to
eschew them).
Code is data, and sometimes the best way to format that data for human
readability is sufficiently ad-hoc that no autoindent/pprinter could do a
fully general good job.
--
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] seqspert-1.7.0-alpha4-1.0-SNAPSHOT now on Clojars - Merge big hash-maps, FAST !
On Monday, November 17, 2014 5:00:23 PM UTC-5, Jules wrote:
Back in February, I posted about some prototype code I had put together
that attempted an alternative approach to map-merging that promised to be
faster and generate less churn than the standard approach.
Glen Mailer suggested that I put it in a standalone library. At the time,
I thought that this would not be possible because of its necessarily tight
coupling to clojure.lang.PersistentHashMap, but then I found some more
time, went away and had a go.
Here it is:
https://github.com/JulesGosnell/seqspert
along with some other hash-set, vector and array related stuff that I have
been playing with, instructions to set it up in Lein and example code to
paste straight into the repl to see how well it performs in your test
environment.
Some simple testing indicates that the larger the map and the greater the
number of threads that you can run in parallel, the better results you will
see. I have seen 30x speedups on a 16-way box merging two hash-maps of 10M
entries each.
Please take a look at it and let me know about any issues, improvements,
results etc - I'd be very interested to hear from you.
I'll put out a stable release in a while, once interested parties have
kicked the tyres a bit.
regards,
Jules
Looks like you're seeing a general 2x speedup, and an orthogonal
${num_cores} speedup from parallelization. What's the source of the general
2x speedup? Algorithmic improvement? Use of transients?
--
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: If code is data why do we use text editors?
Code is data, and sometimes the best way to format that data for human readability is sufficiently ad-hoc that no autoindent/pprinter could do a fully general good job. +1 there should therefore be a region annotation that tells IDEs to leave it the hell alone when the user invokes reindent the whole file type commands :-) -- 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] seqspert-1.7.0-alpha4-1.0-SNAPSHOT now on Clojars - Merge big hash-maps, FAST !
all is explained in the README on github :-)
and here is an example Splicer:
https://github.com/JulesGosnell/seqspert/blob/master/src/java/clojure/lang/ArrayNodeAndArrayNodeSplicer.java
Jules
On Monday, 17 November 2014 23:01:44 UTC, Fluid Dynamics wrote:
On Monday, November 17, 2014 5:00:23 PM UTC-5, Jules wrote:
Back in February, I posted about some prototype code I had put together
that attempted an alternative approach to map-merging that promised to be
faster and generate less churn than the standard approach.
Glen Mailer suggested that I put it in a standalone library. At the time,
I thought that this would not be possible because of its necessarily tight
coupling to clojure.lang.PersistentHashMap, but then I found some more
time, went away and had a go.
Here it is:
https://github.com/JulesGosnell/seqspert
along with some other hash-set, vector and array related stuff that I
have been playing with, instructions to set it up in Lein and example code
to paste straight into the repl to see how well it performs in your test
environment.
Some simple testing indicates that the larger the map and the greater the
number of threads that you can run in parallel, the better results you will
see. I have seen 30x speedups on a 16-way box merging two hash-maps of 10M
entries each.
Please take a look at it and let me know about any issues, improvements,
results etc - I'd be very interested to hear from you.
I'll put out a stable release in a while, once interested parties have
kicked the tyres a bit.
regards,
Jules
Looks like you're seeing a general 2x speedup, and an orthogonal
${num_cores} speedup from parallelization. What's the source of the general
2x speedup? Algorithmic improvement? Use of transients?
--
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: If code is data why do we use text editors?
Example 1:
I'm pretty sure one could create a set of rules with penalty scores, like latex
does, for rendering the prettiest, most dense code.
(- (some lengthy collection expr here)
(map f2)
(reduce f1 #{}))
But I find this to be the most readable.
[[(dec x) y wh ]
[x(dec y)wh ]
[xy (inc w) h ]
[xy w(inc h)]]
I wonder if this wouldn't be handled better by a matrix tagged literal.
I find manual column alignment to be a ridiculous time waster when refactoring
code.
Few tools help and changing a single symbol messes up the entire function.
(cond
(pred1) (consequence1)
(pred2 x z) (consequence2))
(cond
(pred1)
(consequence1)
(pred2 x z)
(consequence2))
This looks like it could be formatted with a penalty based rule system as well.
All of this, of course, is to say nothing of the minor issues of preserving
comments; preserving comment column alignments where desired; and preserving
commas where useful in literal data (though I personally tend to eschew them).
In a structural editor you would probably have no comments in the source, see
gorilla-repl or mathematica notebooks.
Code is data, and sometimes the best way to format that data for human
readability is sufficiently ad-hoc that no autoindent/pprinter could do a
fully general good job.
These ad-hoc things might make the code astheatically pleasing, but hard to
read imho.
Cheers Jan
--
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] seqspert-1.7.0-alpha4-1.0-SNAPSHOT now on Clojars - Merge big hash-maps, FAST !
I did? I have no recollection of this at all! Is this a similar concept to the Patricia trees as found in https://github.com/clojure/data.int-map ? Glen -- 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] seqspert-1.7.0-alpha4-1.0-SNAPSHOT now on Clojars - Merge big hash-maps, FAST !
Feb 17th - I was talking about the exploratory code I had written and you said : Is there a specific part of this implementation which means it needs to live in core? It would be cool to have this as a library that could be used with existing versions of clojure :-) No, this has nothing to do with int-map etc. This is for merging standard Clojure hash-maps with large amounts of data in them very quickly and with very little churn. See the examples in the README. cheers Jules On Tuesday, 18 November 2014 00:14:30 UTC, Glen Mailer wrote: I did? I have no recollection of this at all! Is this a similar concept to the Patricia trees as found in https://github.com/clojure/data.int-map ? Glen -- 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: If code is data why do we use text editors?
there should therefore be a region annotation that tells IDEs to leave it the hell alone when the user invokes reindent the whole file type commands :-) FWIW IntelliJ has had this for a while, and I'd be surprised if other systems didn't as well. I haven't gotten around to adding support for it to Cursive, though. On 18 November 2014 12:02, Raoul Duke rao...@gmail.com wrote: Code is data, and sometimes the best way to format that data for human readability is sufficiently ad-hoc that no autoindent/pprinter could do a fully general good job. +1 there should therefore be a region annotation that tells IDEs to leave it the hell alone when the user invokes reindent the whole file type commands :-) -- 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: a nicer way to write 1 - 2 + 3 - 4 ... +/- n
Thanks for all the ideas. I like cyclefn the most, a bit of investment resulting in super clean output. Andy On Sat, Nov 15, 2014 at 9:35 AM, Ben Wolfson wolf...@gmail.com wrote: or (defn enumerate [xs] (map vector (range) xs)) (defn altsum [n] (reduce (fn [acc [i f]] (f acc (inc i))) 0 (take n (enumerate (cycle [+ -]) On Fri, Nov 14, 2014 at 3:41 PM, Andrew Oberstar ajobers...@gmail.com wrote: How about this? (defn cyclefn [ fs] (let [fcycle (cycle fs) rem-fs (atom fcycle)] (fn [ args] (let [f (first @rem-fs)] (swap! rem-fs rest) (apply f args) (reduce (cyclefn + -) (range 1 100)) cyclefn could be used to cycle through any set of functions you want and the result used as if it was a normal function. Andy On Fri, Nov 14, 2014 at 7:16 AM, Henrik Lundahl henrik.lund...@gmail.com wrote: How about this? :-) (defn altsum [n] (/ (if (odd? n) (+ 1 n) (- n)) 2)) -- Henrik On Fri, Nov 14, 2014 at 1:48 PM, Gary Verhaegen gary.verhae...@gmail.com wrote: What about cheating a bit? (interleave (iterate #(+ % 2) 1) (iterate #(- % 2) -2)) Then take n, reduce +, or whatever else you might want to do with the series. -- 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. -- 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. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- 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,
Lisp Devroom at FOSDEM 2015: Call for Participation
Dear Lispers, I'm pleased to announce, for the first time, Lisp Devroom @ FOSDEM, the biggest FLOSS event in Europe, that will be held in Brussels on January 31st to February 2nd, 2015. This is a call to propose your talks for FOSDEM. The topic of the devroom includes all Lisp-inspired dialects, like Common Lisp, Scheme, Clojure, Emacs Lisp, newLISP, Racket, GCC-Melt, LFE, Shen more. Every talk is welcome: from real-world examples, research projects, unusual ideas to small pet hacks. FOSDEM is a hacker conference and we would be happy to see more practical proposals, crazy ideas and open source projects demonstrations than dry scientific papers (we will leave them for ILC and ELS :-P). Important dates --- * Submission deadlines: 2014-12-14 * Acceptance notifications: 2014-12-28 * Lisp Devroom conference: 2015-01-31 (Saturday) Submitting proposals Please use https://penta.fosdem.org/submission/FOSDEM15 to submit your proposals; you will have to create Pentabarf account unless you already have one. When submitting your talk in Pentabarf, make sure to select the 'Lisp devroom' as the 'Track'. Submission details -- Your submission should include the following information: * The title and subtitle of your talk, descriptive as possible * A short abstract of one paragraph * A longer description of the talk, if you would like so * Links to related online material, like pages, blogs, repositories and etc. Devroom mailing list Please join Lisp devroom mailing list; this will be official communication channel for the devroom and all further announcements will be sent there. * desktops-devr...@lists.fosdem.org * https://lists.fosdem.org/listinfo/desktops-devroom - mailing list and subscription form Planned schedule Two types of sessions are considered: * lighting talk - 30 minues * full presentation - 60 minues with 5 minutes for the setup between each talk. More details will be announced on devroom mailing list. Questions volunteers -- Don't hesitate to mail me at 'sanelz [at] gmail [dot] com' in case you have questions or would like to help with organization (put '[Lisp-fosdem]' in subject). Also, feel free to use official devroom mailing list for discussion. Did I said that there will be video recordings? Yes, video volunteers are welcome too :) Please forward this announcement to the relevant lists. '(Best Regards, Sanel) -- 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.
map function generator
Hi,
This is another puzzle/exercise based on a very practical need. I could not
find a built in function, hoping something like colfn already exists.
Otherwise I wonder about an idiomatic solution. This is self-explanatory
code:
user= (require '[clojure.algo.generic.functor :as fu])
user= (require '[me.raynes.fs :as fs])
user= (defn colfn[col] (fn [a] (fu/fmap #(% a) col)))
user= (map (colfn [fs/directory?,identity]) (filter fs/directory?(set
(fs/list-dir .
([true src] [true target] [true .git])
user= (map (colfn {:is-dir fs/directory?, :dir identity}) (filter
fs/directory?(set (fs/list-dir .
({:is-dir true, :dir src} {:is-dir true, :dir target} {:is-dir true,
:dir .git})
My question is, if something like colfn already exists? The idea is to
generate a function of a sequence (vector, list, map) of functions which
would used in e.g. map.
Best,
Andy
--
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] differ v0.1.0, a tool for creating, and applying, diffs on clojure(script) datastructures
Hi Robin,
Thanks for adding a README. It might contain a couple of errors though.
I can't make sense of this for example:
(def person-map {:name Robin
:age 25
:sex :male})
(def person-diff (differ/diff test-map {:name Robin Heggelund Hansen
:age 26})
;; person-diff will now be [{:name Robin Heggelund Hansen, :age
26};; {:sex 0}]
Where did test-map come from? I'm assuming it's person-map. Why is :sex 0?
Is he fat and bald? If that's a list of keys that's removed, I suggest
using a set there.
(differ/patch {:specie :dog
:sex :female}
person-diff)
;; Will return {:name Robin Heggelund Hansen;; :age
26;; :specie :dog}
Shouldn't the result contain [:sex :female] as well?
On Tue, Nov 18, 2014 at 3:51 AM, Robin Heggelund Hansen
skinney...@gmail.com wrote:
https://github.com/Skinney/differ
I needed a way to send diffs of data from a cljs web-app to a clj backend,
and I found clojure.data/diff to be a pain to work with, so i created my
own solution. It currently only supports maps (and nested maps...), but
support for lists, vectors and sets is on the roadmap for the next version.
This version is mostly for me to test with my own app, which currently only
uses maps.
--
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.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.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.
snubbed on clojurescript one
Really excited to use clojurescript one but got shot down right out of the gate. Anyone here have the answer? https://github.com/brentonashworth/one/issues/145 -- 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: snubbed on clojurescript one
Hi Kevin, my understanding is that ClojureScript One is not actively maintained and pretty out of date at this point. You're probably better suited to starting from a different place in the eco-system. What are your goals in using ClojureScript? If you want to describe a bit what you're after (i.e. just getting up and running with ClojureScript, building web clients, etc.), then I think folks on the list can give you a lot of suggestions. /cc clojurescr...@googlegroups.com DD (2014/11/18 15:39), Kevin Banjo wrote: Really excited to use clojurescript one but got shot down right out of the gate. Anyone here have the answer? https://github.com/brentonashworth/one/issues/145 -- 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 mailto: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] differ v0.1.0, a tool for creating, and applying, diffs on clojure(script) datastructures
Ahh, you're right, thats a typo and it should read person-map.
{:sex 0} is a map of keys removed. The reason I'm not using a set here is
because I need to know the type of the datastructure to diff, and because
it needs to work for nesting. For instance, this should also work.
(diff {:name Robin, :friends {:school #{Lars Jens Erika}}}) {:name
Robin, :friends {:home #{Mom}, :school #{Lars}}})
Should return
[{:friends {:home #{Mom}}}
{:friends {:school #{Jens, Erika}}}]
What I said about retaining type information becomes especially relevant
when it comes to list/seq/vector, as all those structures support the same
operations, but the result of patch should return the correct type.
kl. 07:42:30 UTC+1 tirsdag 18. november 2014 skrev Atamert Ölçgen følgende:
Hi Robin,
Thanks for adding a README. It might contain a couple of errors though.
I can't make sense of this for example:
(def person-map {:name Robin
:age 25
:sex :male})
(def person-diff (differ/diff test-map {:name Robin Heggelund Hansen
:age 26})
;; person-diff will now be [{:name Robin Heggelund Hansen, :age 26};;
{:sex 0}]
Where did test-map come from? I'm assuming it's person-map. Why is :sex 0?
Is he fat and bald? If that's a list of keys that's removed, I suggest
using a set there.
(differ/patch {:specie :dog
:sex :female}
person-diff)
;; Will return {:name Robin Heggelund Hansen;; :age 26;;
:specie :dog}
Shouldn't the result contain [:sex :female] as well?
On Tue, Nov 18, 2014 at 3:51 AM, Robin Heggelund Hansen
skinn...@gmail.com javascript: wrote:
https://github.com/Skinney/differ
I needed a way to send diffs of data from a cljs web-app to a clj
backend, and I found clojure.data/diff to be a pain to work with, so i
created my own solution. It currently only supports maps (and nested
maps...), but support for lists, vectors and sets is on the roadmap for the
next version. This version is mostly for me to test with my own app, which
currently only uses maps.
--
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.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.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: [ANN] differ v0.1.0, a tool for creating, and applying, diffs on clojure(script) datastructures
And no, the result shouldn't contain {:sex :female} because the :sex key is
listed in the removals map, so it's correct that it's not included in the
result.
kl. 07:42:30 UTC+1 tirsdag 18. november 2014 skrev Atamert Ölçgen følgende:
Hi Robin,
Thanks for adding a README. It might contain a couple of errors though.
I can't make sense of this for example:
(def person-map {:name Robin
:age 25
:sex :male})
(def person-diff (differ/diff test-map {:name Robin Heggelund Hansen
:age 26})
;; person-diff will now be [{:name Robin Heggelund Hansen, :age 26};;
{:sex 0}]
Where did test-map come from? I'm assuming it's person-map. Why is :sex 0?
Is he fat and bald? If that's a list of keys that's removed, I suggest
using a set there.
(differ/patch {:specie :dog
:sex :female}
person-diff)
;; Will return {:name Robin Heggelund Hansen;; :age 26;;
:specie :dog}
Shouldn't the result contain [:sex :female] as well?
On Tue, Nov 18, 2014 at 3:51 AM, Robin Heggelund Hansen
skinn...@gmail.com javascript: wrote:
https://github.com/Skinney/differ
I needed a way to send diffs of data from a cljs web-app to a clj
backend, and I found clojure.data/diff to be a pain to work with, so i
created my own solution. It currently only supports maps (and nested
maps...), but support for lists, vectors and sets is on the roadmap for the
next version. This version is mostly for me to test with my own app, which
currently only uses maps.
--
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.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.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.
