Re: Suggested 'server' for hosting clojure web app
I think systemd will also handle process monitoring. You could also use runit, which runs in user space so you can use it on any distro. On Jun 30, 2013 12:15 AM, Maciej Mazur mamc...@gmail.com wrote: On Sat, 29 Jun 2013 21:31:22 +0100, James Reeves wrote: On 29 June 2013 18:59, Ravindra Jaju ravindra.j...@gmail.com wrote: 1] Upstart is good - so, I will need to figure out the equivalent on Fedora (which is what I use - primarily because I'm too familiar with it and have been an RH/Fedora guy since about ~1995). Essentially, a daemon monitor which will restart in case of failures. I've been somewhat rusty with the recent releases of all Linux-es from the systems admin point of view. Since Fedora 9, Upstart has been the default on that as well, so you're in luck :) Actually Upstart has been replaced by systemd since Fedora 15 Maciej Mazur -- -- 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/groups/opt_out.
Re: Suggested 'server' for hosting clojure web app
The app server and process monitoring questions have been covered elsethread. There hasn't been much talk about the static content. I'd say there are two main strategies available here: a. set appropriate caching headers on your static pages use a caching proxy such as varnish b. precompile your assets and serve them straight from disk using nginx's try_files directive Option a is probably easier to get going with, and for a personal blog probably good enough. For option b, I'd use sprockets if I were in the ruby world, but I'm not sure what clojure libraries are in this space. Phil On Jun 29, 2013 6:59 PM, Ravindra Jaju ravindra.j...@gmail.com wrote: Thank you Daniel and James. I appreciate the detailed response and advice. I'll make myself more clear and specify what I have in mind. I don't want hot-deploys, for sure. :) I erred when I mentioned without restarting - that certainly changes quite a few things! Here's what I have in mind for my app as well as the deployment design. Its main goals are primarily to (1) Get more familiar with clojure dev since I enjoy it, (2) host my personal blog (mostly markdown, processed at runtime or pre-preprocessed), and (3) some dynamic content. | nginx | | static content - markdown, possibly preprocessed - with markdown-clj | -- | clojure app for some dynamic content | I've only started using luminus, and it serves markdown by processing it at runtime, which makes my content serving dependent on the app-server. I have the option of pre-processing markdown and serving it completely statically with nginx. Until then, I'm okay right now using the app to serve it. It is at this point where I need advice. I currently only know of running the clojure app via lein ring server (or equivalent) from the command-line - no scripts which can run it like those init scripts with start/stop/reload support. nginx runs fine as a daemon, but I need to figure out the java side. 1] Upstart is good - so, I will need to figure out the equivalent on Fedora (which is what I use - primarily because I'm too familiar with it and have been an RH/Fedora guy since about ~1995). Essentially, a daemon monitor which will restart in case of failures. I've been somewhat rusty with the recent releases of all Linux-es from the systems admin point of view. 2] Is there a suggested way to manage the java process - especially starting and stopping? I'm okay with a few seconds of downtime, and I can write scripts to do this myself, but don't want to reinvent the wheel if there are already some tools/scripts/practices which make it straightforward. I'm especially looking for current practices with folks who use clojure with jetty/http-kit like servers, and not jboss et al. :) Best regards, jaju On Sat, Jun 29, 2013 at 10:36 PM, James Reeves ja...@booleanknot.comwrote: If you just want to deploy your application, and don't particularly care about having control over your system architecture, you might want to consider a platform like Heroku. Otherwise, a common solution, and one I'd personally recommend, is to have a standalone app executed via Upstart, running behind an nginx proxy. Upstart allows you to run a process as a daemon, and it can do useful things like automatically restart a process if it unexpectedly terminates. Upstart is by no means the only program that does this, but it's the one Ubuntu uses and is therefore stable and well-tested. A HTTP proxy server like nginx is useful for buffering against restarts and application failures. You can configure nginx to buffer a request while your server restarts, or to distribute request over a cluster of processes, or to cache static content. You could create the standalone app manually, with a -main function that calls run-jetty, or use the lein-ring plugin and the lein ring uberjar command to do it for you. - James On 29 June 2013 15:47, Ravindra Jaju ravindra.j...@gmail.com wrote: I want to deploy a small web app - serving mostly static content. I'm using Luminus (http://www.luminusweb.net/) - which is quite neat in the way it builds itself from well-known components. I'm having trouble deciding how to deploy it. I want some automation while deploying upgrades, and would like it to be light-weight. Jetty, http-kit, or immutant? (I tried immutant - but it seems to be taking up too much memory for my comfort, on my modest server.) Jetty and http-kit - I would like to hear about how I can deploy them as nice system daemons, with monitoring etc. so that they can be brought up automatically if something goes wrong. I'm also unable to find out how I can do a re-deploy without restarting. Any help or pointers appreciated! Thanks, jaju -- -- 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
What the hell is this???
I'm not sure if this is a bug in clooj or in Clojure itself: Evaluating file...CompilerException java.lang.ClassFormatError: Unknown constant tag 117 in class file [redacted]/core$eval215, compiling:(NO_SOURCE_PATH:156:1034) What *is* certain is that nothing I type into the source code should be able to cause ClassFormatError. So the bug isn't mine. Now, someone tell me how to fix it. -- -- 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/groups/opt_out.
Re: What the hell is this???
Context would help. On Jun 30, 2013, at 12:46 AM, Cedric Greevey cgree...@gmail.com wrote: I'm not sure if this is a bug in clooj or in Clojure itself: Evaluating file...CompilerException java.lang.ClassFormatError: Unknown constant tag 117 in class file [redacted]/core$eval215, compiling:(NO_SOURCE_PATH:156:1034) What *is* certain is that nothing I type into the source code should be able to cause ClassFormatError. So the bug isn't mine. Now, someone tell me how to fix it. -- -- 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/groups/opt_out. -- -- 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/groups/opt_out.
Re: Help deciphering ArityException message
Just a little hint which may help you in the future. First, note the trailing $fn in reformat-headers$fn which tells you, that your problem is with an anonymous function. Second, you know that there is a second form for anonymous functions which uses fn instead of the reader macro. Third, fn can take a name for the anonymous function. That way you get a better pointer in your exception, where the problem originated. Recently, I find myself using the reader macros less, only for functions which are basically just one form which are totally self-explanatory. The usage of fn has two advantages: it can be nested and the parameters help documenting the expected input. Using fn with a name yields better exceptions plus serves a documentation purpose by naming what should happen. Just my ct. Kind regards, 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/groups/opt_out.
clojure on raspberry pi looks decent
Hi all, I'd just like to report some benchmarks of clojure (jdk1.8-ea) and clojure-py(python 2.7.3) on the raspberry pi. JVM startup time is an issue and since I don't know python I consider clojure-py a good alternative for demonstrating clojure on the pi. so here we go: lein trampoline repl needs roughly 2 minutes (!!!) when invoked inside a project with :aot :main enabled in the project.clj lein repl needs just under 1 minute to start when not inside a project clojurepy needs roughly 18 seconds to start a bare repl (1/3 of leiningen) BUT, as soon as we've got a vm up and running (reduce * (range 1N 51)) ;; (! 50) needs 17ms with python but roughly 4ms with java For the sake of completeness, the pure Java version of factorial (using exactly the same types) needs roughly 2.5ms by python is so non-existent that even though I can write factorial I can't write a proper timing function!!! (fail...) not bad at all in my opinion... :) generally, even with leiningen I find that once the vm is up and as long as I don't use concurrency, the experience is very smooth... now if only there was an editor to support clojure syntax-highlighting... Jim -- -- 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/groups/opt_out.
Re: Help deciphering ArityException message
Thanks, Stefan. That sounds like good advice. Dave On Sunday, June 30, 2013 5:09:23 AM UTC-5, Stefan Kamphausen wrote: Just a little hint which may help you in the future. First, note the trailing $fn in reformat-headers$fn which tells you, that your problem is with an anonymous function. Second, you know that there is a second form for anonymous functions which uses fn instead of the reader macro. Third, fn can take a name for the anonymous function. That way you get a better pointer in your exception, where the problem originated. Recently, I find myself using the reader macros less, only for functions which are basically just one form which are totally self-explanatory. The usage of fn has two advantages: it can be nested and the parameters help documenting the expected input. Using fn with a name yields better exceptions plus serves a documentation purpose by naming what should happen. Just my ct. Kind regards, 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/groups/opt_out.
Translating simple path finding problem from prolog to core.logic
Hello fellow logicians! I'm trying to translate the following prolog problem to core.logic: From http://tjeyamy.blogspot.com/2011/02/path-finding-in-prolog.html edge(1,2). edge(1,4). edge(2,4). edge(3,6). edge(3,7). edge(4,3). edge(4,5). edge(5,6). edge(5,7). edge(6,5). edge(7,5). edge(8,6). edge(8,7). path(X,Y,[X,Y]):- edge(X,Y). path(X,Y,[X|Xs]):- edge(X,W), path(W,Y,Xs). path(1, 7, P). %Results Z = [1, 2, 4, 3, 6, 5, 7]; Z = [1, 2, 4, 3, 6, 5, 6, 5, 7]; Here are a couple of my own attempts using core.logic: (defrel edge x y) (fact edge 1 2) (fact edge 1 4) (fact edge 2 4) (fact edge 3 6) (fact edge 3 7) (fact edge 4 3) (fact edge 4 5) (fact edge 5 6) (fact edge 5 7) (fact edge 6 5) (fact edge 7 5) (fact edge 8 6) (fact edge 8 7) (defn path2 [x y p] (conde [(fresh [] (conso x [y] p) (edge x y))] [(fresh [w r] (conso x r p) (edge x w) (path2 w y r))])) (defne path3 [x y p] ([ x y [x . [y] ] ] (edge x y)) ([ x y [x . r] ] (fresh [w] (edge x w) (path3 w y r Hopefully I've understood enough that path3 is just the pattern matching version of path2 ;-) What happens, though, is that both of these end up in an infinite loop. Any hints about what I'm doing wrong? I'm sure I'm missing something fundamental here. Is there some sort of debugging I can do to figure this out? Or some way to trace execution? Thanks for any help! Cheers, Craig -- -- 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/groups/opt_out.
core.logic: question on ordering in conjunction
I wrote this goal: (use 'clojure.core.logic) (use 'clojure.core.logic.protocols) (defn pluso [t1 t2 s] (fn goal [a] (let [args (map (partial walk a) [t1 t2 s]) fresh? (map lvar? args) ground? (map not fresh?) [t1 t2 s] args] (cond (= [true true true ] ground?) (if (= s (+ t1 t2)) a nil) (= [true true false] ground?) (unify a s (+ t1 t2)) (= [true false true ] ground?) (unify a t2 (- s t1)) (= [false true true ] ground?) (unify a t1 (- s t2)) :else a ;; Returning the substitution map will mark this goal as successful ;; while it is neither successful nor failed. The fresh variables ;; might be ground later. When I run this query I get (_0) while I'm expecting (3). The root of the problem is the returning of the substitution map if more than one variable is not ground. (run* [q] (fresh [a] (pluso q 4 a) (== a 7))) I've tried returning a choice but this leads to an endless loop. Is it at all possible to somehow adapt the goal to await the grounding of the a-variable? What if the fresh variables are never ground? -- -- 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/groups/opt_out.
Re: core.logic: question on ordering in conjunction
What you are trying to do is non-relational, and will only work when you put the non-relational pluso at the end. You can obviously use the finite domain extensions to core.logic to accomplish this: (defn fd-pluso [t1 t2 s] (fd/eq (= s (+ t1 t2 (run* [q] (fresh [a] (fd/in q a (fd/interval Integer/MAX_VALUE)) (fd-pluso q 4 a) (== a 7))) = (3) I don't know how you achieve this result in core.logic without the finite domain support. -- -- 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/groups/opt_out.
Re: core.logic: question on ordering in conjunction
How does one recognize a relational or non-relational goal? Thanks for the fd example. On Sunday, June 30, 2013 7:34:58 PM UTC+2, Norman Richards wrote: What you are trying to do is non-relational, and will only work when you put the non-relational pluso at the end. You can obviously use the finite domain extensions to core.logic to accomplish this: (defn fd-pluso [t1 t2 s] (fd/eq (= s (+ t1 t2 (run* [q] (fresh [a] (fd/in q a (fd/interval Integer/MAX_VALUE)) (fd-pluso q 4 a) (== a 7))) = (3) I don't know how you achieve this result in core.logic without the finite domain support. -- -- 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/groups/opt_out.
Re: core.logic: question on ordering in conjunction
On Sun, Jun 30, 2013 at 12:58 PM, Steven Devijver sdevij...@gmail.comwrote: How does one recognize a relational or non-relational goal? If you are using anything that doesn't decompose down to the core relational operators, like == and conde, you are likely non-relational. In this case, you are asking questions like is this value ground which is clearly a stateful question about where you are in the search. (what you are doing is very similar to core.logic's project, and if you search for that you'll probably find some discussion of the issues) As a general rule, if you can change the order of your goals and get different answers, you are probably doing something non-relational. That doesn't mean to are doing something wrong - it just means you are going beyond the pure relational model and are potentially more constrained in how you can express your problem. (in this case, being order dependant) -- -- 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/groups/opt_out.
Re: Translating simple path finding problem from prolog to core.logic
Just like the prolog, you are generating an infinite number of solutions. run* will try and give you all of them. You can use clojure's lazy seq operations (first, take, etc...) or just ask for however many you want: (run 10 [q] (path2 1 7 q)) ((1 4 3 7) (1 2 4 3 7) (1 4 5 7) (1 2 4 5 7) (1 4 3 6 5 7) (1 2 4 3 6 5 7) (1 4 5 6 5 7) (1 2 4 5 6 5 7) (1 4 3 7 5 7) (1 2 4 3 7 5 7)) -- -- 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/groups/opt_out.
ANN: faster zipper implementation
I've updated the clojure.zip implementation to use records internally. This achieves a speedup of roughly 2x. You can find the library below and on clojars: https://github.com/akhudek/fast-zip It's a drop in replacement for clojure.zip in terms of interface and usage. However, since the internal representation has changed, fast-zip locations cannot be used with the clojure.zip implementation. E.g. you cannot create a zipper with fast-zip, then use clojure.zip/next on the result. You must use fast.zip.core/next instead. In addition to the micro-benchmark provided, I've tried this in a larger project that makes extensive use of zippers and found a similar speedup. Comments and suggestions welcome. 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/groups/opt_out.
Microsoft Rx -style operations with core.async
Hi all, Today, primarily for my own edification, I've been implementing as many Microsoft Reactive Extensions operators as I can using core.async. The results have been *spectacular*. core.async is an absolute pleasure to work with. I'm so happy with how they have turned out, that I really want to share. You can find my work-in-progress here: https://github.com/brandonbloom/asyncx The primary file of interest is: https://github.com/brandonbloom/asyncx/blob/master/src/asyncx/core.clj At the time of this message, I've implemented the bulk of the relevant operators described here: http://msdn.microsoft.com/en-us/library/hh242961(v=vs.103).aspx All of my implementations utilize parking operations, so this library should be fully portable to ClojureScript. My notes describe any difference from Rx, notable omissions, and known issues: https://github.com/brandonbloom/asyncx/blob/master/notes I'll probably work more on this tonight and will update my notes as I go. Rich team: I understand that you guys will probably take a run at implementing this sort of library in the not too distant future. Please let me know if and how I can contribute to that effort. Cheers, Brandon -- -- 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/groups/opt_out.
core.async implemented on top of Pulsar
Hi. So I wanted to see how easy it would be to implement core.async on top of Pulsar. It turned out to be quite trivial, but the exercise shows the different approaches of the two projects. First, Pulsar https://github.com/puniverse/pulsar is the Clojure API to Quasar https://github.com/puniverse/quasar, which, in turn, is a new concurrency framework for the JVM (introduced herehttp://blog.paralleluniverse.co/post/49445260575/quasar-pulsar ). At its heart it is an implementation of true lightweight threads (fibers) on the JVM. Fibers are created by instrumenting the bytecode of selected methods, turning them into continuations and running them in a ForkJoinPool. Then, Quasar/Pulsar provide communication mechanism in the form of Go-like channels and dataflow variables. The last layer is Erlang-like actors, complete with selective receive plus other OTP goodies like gen-server, supervisors and more. We are currently working on version 0.2, which we will hopefully release at the end of the week, whose main feature is clustering (channels and actors can communicate over the network). Anyway, this is the core.async implementation on top of Pulsarhttps://github.com/puniverse/pulsar/blob/master/src/main/clojure/co/paralleluniverse/pulsar/async.clj. I haven't implemented alts yet, because that's the only feature that would take more than a couple of lines; I might have the time to do it tomorrow. core.async turns Clojure expressions into continuations at the Clojure level, while Pulsar works at the bytecode level, so this alone has a few consequences. First, the Pulsar implementation can't run ClojureScript. Second, several limitations put in place by core.async become unnecessary, first and foremost is the distinction between !! and !, and ! and !!. In the Pulsar implementation you can use either the bang or the double-bang form inside or outside a go block. It makes no difference. Then, we have the channels. Pulsar's channels are lock-free, and are single-consumer by default. It seems to me that channels should be single-consumer, but I'd like to hear other opinions on the matter. Making channels single-consumer not only saves a couple of CASs, it also opens the door to some operations that would require locks without this assumption (though, just to be sure, the channels in our core.async implementation are all multi-producer multi-consumer; I'm just not sure that's the right choice). Multiple consumers are also a problem when it comes to distributing channels over the network (for now, only our single-consumer channels can be distributed). Distribution brings us to alts. While easy to implement with Quasar/Pulsar on a single machine, I'm not sure how easily they can be distributed. If you have an alt possibly sending a message to one of two distributed queues, it will require quite a few roundtrips, and possibly even a consensus protocol (though maybe not) to make sure the message is sent to one, and only one channel. Not any better is the problem on waiting on several distributed channels - that requires a distributed transaction. One of the things I like most about Quasar/Pulsar is how synchronization is carried out at the fiber level. Because fibers run in a FJPool, true thread-blocking locks are a no-no (they can wreak havoc on FJ). But Quasar abstracts threads and fibers into something called strands; a strand is simply a fiber or a thread. This gives a single, identical API, for dealing with both fibers and threads. As a result, converting thread-synchronization constructs to such that can work with both fibers and threads is almost automatic. When a thread parks, it actually parks, but when a fiber parks it is simply descheduled off the FJPool, and when it unparks it is re-forked on the pool and continues right where it left off. We have big plans for Quasar/Pulsar, but I don't want to spoil all the surprises. I'd love to hear some feedback. Ron -- -- 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/groups/opt_out.
Re: Microsoft Rx -style operations with core.async
I don't know the semantics of the MS functions so maybe this mirrors them, but the implementations of take-while and drop-while remove an extra element from the argument channel, right? user (def c (chan)) #'user/c user (go (doseq [i (range 10)] (! c i))) #ManyToManyChannel clojure.core.async.impl.channels.ManyToManyChannel@13f452d user (def d (take-while even? c)) #'user/d user (!! (go (! d))) 0 user (!! (go (! c))) 2 take-while pulled down the 1 and discovered it didn't pass the predicate, and there's no way to put it back. On Sun, Jun 30, 2013 at 2:27 PM, Brandon Bloom brandon.d.bl...@gmail.comwrote: Hi all, Today, primarily for my own edification, I've been implementing as many Microsoft Reactive Extensions operators as I can using core.async. The results have been *spectacular*. core.async is an absolute pleasure to work with. I'm so happy with how they have turned out, that I really want to share. You can find my work-in-progress here: https://github.com/brandonbloom/asyncx The primary file of interest is: https://github.com/brandonbloom/asyncx/blob/master/src/asyncx/core.clj At the time of this message, I've implemented the bulk of the relevant operators described here: http://msdn.microsoft.com/en-us/library/hh242961(v=vs.103).aspx All of my implementations utilize parking operations, so this library should be fully portable to ClojureScript. My notes describe any difference from Rx, notable omissions, and known issues: https://github.com/brandonbloom/asyncx/blob/master/notes I'll probably work more on this tonight and will update my notes as I go. Rich team: I understand that you guys will probably take a run at implementing this sort of library in the not too distant future. Please let me know if and how I can contribute to that effort. Cheers, Brandon -- -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: Microsoft Rx -style operations with core.async
I don't know the semantics of the MS functions so maybe this mirrors them This code is not an attempt to replicate the semantics of Rx, just provide a comparable set of operators. the implementations of take-while and drop-while remove an extra element from the argument channel, right? Yes. All of these operations inherently consume values from channels. Your c variable is no longer usable once you've given it out to a consumer that expects exclusive access. Channels and Push Sequences are different in many ways. In particular, callback-based push sequences can have multiple subscribers. That's why there are no fan-out operations listed on that Msft reference page: All subscription can implicitly fan out. I've only thought briefly about this, but there are potentially many different strategies for fan out (eg buffering/blocking/dropping/sliding).It's not yet obvious to me what the various higher level operators should look like (or be called). I'm open to suggestions. I also haven't studied the design space from the Golang perspective yet either. Maybe that community has some good ideas... -- -- 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/groups/opt_out.
Re: core.async
On Sun, Jun 30, 2013 at 3:00 AM, Brandon Bloom brandon.d.bl...@gmail.comwrote: I don't think it's published to a maven repository yet. You can check it out, install it with `lein install`, then depend on it via [core.async 0.1.0-SNAPSHOT] Thanks! I flew over to China (from SFO) and played with core.async on the way over. OMG... it's just totally amazing... both at the conceptual level and at the execution level (okay, I haven't instrumented it, but some of the basic games I've been playing with it have been spectacular.) I've thrown a challenge to the Lift community to build something like it in Scala while I am traveling in July... but I think in a language without full macro support, it will be very difficult. The original (now dead) Scala Actor implementation tried to do continuations (which is what you need to make 'go' work without blocking a thread while waiting on channels), but failed in the execution (lots of exceptions for flow of control, lots of nasty limitations that were not compiler enforced... and when you're dealing with a statically typed language, the compiler should enforce the rules). Anyway, the core.async stuff is really, really nice. Hats off and a huge way to go, dudes! to the team that made it happen. Looking forward to it being published (even as SNAPSHOT) in a Maven repo. Rock on! On Sat, Jun 29, 2013 at 2:50 PM, David Pollak dpollak...@gmail.comwrote: What's the entry in project.clj to use the core.async stuff? Thanks! On Sat, Jun 29, 2013 at 9:44 AM, Joseph Smith j...@uwcreations.comwrote: It seems to me that the Clojure space suffers from an unusual malady: it's busy sitting here quietly advancing half of applied computer science, and no one seems to notice the full extent of its import. And it makes me sound like a broken record with my colleagues: Oh! Clojure has... --- Joseph Smith @solussd On Jun 29, 2013, at 6:07 AM, Peter Taoussanis ptaoussa...@gmail.com wrote: Oh man, how is everyone _not_ running around screaming about this right now? It seems to me that the Clojure space suffers from an unusual malady: it's busy sitting here quietly advancing half of applied computer science, and no one seems to notice the full extent of its import. Man, I'm sometimes forced to just stop for a moment and sit in awe at how lucky I've been to see this stuff develop and to get to use it. Clojure was huge. And before we're close to digesting its potential, there's protocols. And Clojurescript. Then Datomic. Reducers. Now this. And it's not about everything being necessarily _novel_, though there is often novelty. For me it's largely about the cohesiveness of the design and the consistency of the overarching vision. Everything _fits_. I feel like I'm using tools and ideas that weren't just developed with care, or cleverness, or experience, but all of those things in a kind of harmony that's vanishingly rare to find in any field. I honestly feel like I'm witnessing history being made. Thank you Rich Hickey, and everyone else in this community for making my work every day so enjoyable. - Peter Taoussanis -- -- 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/groups/opt_out. -- -- 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/groups/opt_out. -- -- 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
Re: ANN: faster zipper implementation
This is really cool, thanks for taking the time to do this. I was able to eke out another 1.8x speedup by changing the keyword equality checks with 'identical?' [1], and there might be some further room for improvement by defining inline forms for some of the smaller functions. Zach [1] https://github.com/ztellman/fast-zip/commit/ee7a64630389f36a539771658586a093369f7939 On Sunday, June 30, 2013 1:18:05 PM UTC-7, Alexander Hudek wrote: I've updated the clojure.zip implementation to use records internally. This achieves a speedup of roughly 2x. You can find the library below and on clojars: https://github.com/akhudek/fast-zip It's a drop in replacement for clojure.zip in terms of interface and usage. However, since the internal representation has changed, fast-zip locations cannot be used with the clojure.zip implementation. E.g. you cannot create a zipper with fast-zip, then use clojure.zip/next on the result. You must use fast.zip.core/next instead. In addition to the micro-benchmark provided, I've tried this in a larger project that makes extensive use of zippers and found a similar speedup. Comments and suggestions welcome. 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/groups/opt_out.
Offline Clojure docs
Folks, Is there an offline package of Clojure docs (the full core.* api docs, cheat sheets, etc.)? I'm traveling with intermittent Internet connectivity (I'm in China now and it's marginal but I'm going to the UP in Michigan where there's no Internet within 15 miles of where I'm staying). With all the travel and flying and such, it'd be great to have all the docs without having to clone all the various source repositories. Thanks for your help. David -- -- 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/groups/opt_out.
Re: Microsoft Rx -style operations with core.async
Two bits of core.async feedback: 1) The (let [c chan] (go ...) c) pattern is *extremely-common*. Might be nice to have something like (go-as c ...) that expands to that pattern. 2) It's somewhat annoying to always have to consider boolean false all the time. Since nil signifies a closed channel, if, when, if-let, and when-let are extremely convenient. Unfortunately, they are subtly bugged! You need nil? checks everywhere, cluttering up relatively nice code. On Sun, Jun 30, 2013 at 5:27 PM, Brandon Bloom brandon.d.bl...@gmail.comwrote: Hi all, Today, primarily for my own edification, I've been implementing as many Microsoft Reactive Extensions operators as I can using core.async. The results have been *spectacular*. core.async is an absolute pleasure to work with. I'm so happy with how they have turned out, that I really want to share. You can find my work-in-progress here: https://github.com/brandonbloom/asyncx The primary file of interest is: https://github.com/brandonbloom/asyncx/blob/master/src/asyncx/core.clj At the time of this message, I've implemented the bulk of the relevant operators described here: http://msdn.microsoft.com/en-us/library/hh242961(v=vs.103).aspx All of my implementations utilize parking operations, so this library should be fully portable to ClojureScript. My notes describe any difference from Rx, notable omissions, and known issues: https://github.com/brandonbloom/asyncx/blob/master/notes I'll probably work more on this tonight and will update my notes as I go. Rich team: I understand that you guys will probably take a run at implementing this sort of library in the not too distant future. Please let me know if and how I can contribute to that effort. Cheers, Brandon -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/L4nEVho555k/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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/groups/opt_out.
Re: ANN: faster zipper implementation
This is really cool, thanks for doing this. I was able to eke out another 1.8x speedup by replacing '=' with 'identical?' for the keyword comparisons [1]. There also might be further room for improvement by defining inline forms for some of the smaller functions. Zach [1] https://github.com/ztellman/fast-zip/commit/ee7a64630389f36a539771658586a093369f7939 On Sunday, June 30, 2013 1:18:05 PM UTC-7, Alexander Hudek wrote: I've updated the clojure.zip implementation to use records internally. This achieves a speedup of roughly 2x. You can find the library below and on clojars: https://github.com/akhudek/fast-zip It's a drop in replacement for clojure.zip in terms of interface and usage. However, since the internal representation has changed, fast-zip locations cannot be used with the clojure.zip implementation. E.g. you cannot create a zipper with fast-zip, then use clojure.zip/next on the result. You must use fast.zip.core/next instead. In addition to the micro-benchmark provided, I've tried this in a larger project that makes extensive use of zippers and found a similar speedup. Comments and suggestions welcome. 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/groups/opt_out.
Re: Microsoft Rx -style operations with core.async
On Mon, Jul 1, 2013 at 7:46 AM, Brandon Bloom brandon.d.bl...@gmail.comwrote: Two bits of core.async feedback: 1) The (let [c chan] (go ...) c) pattern is *extremely-common*. Might be nice to have something like (go-as c ...) that expands to that pattern. 2) It's somewhat annoying to always have to consider boolean false all the time. Since nil signifies a closed channel, if, when, if-let, and when-let are extremely convenient. Unfortunately, they are subtly bugged! You need nil? checks everywhere, cluttering up relatively nice code. It'd be really nice to have a closed token that one could construct a channel with so the token could be at the app level... although I guess this wouldn't deal with the if-let/when-let issue. On Sun, Jun 30, 2013 at 5:27 PM, Brandon Bloom brandon.d.bl...@gmail.comwrote: Hi all, Today, primarily for my own edification, I've been implementing as many Microsoft Reactive Extensions operators as I can using core.async. The results have been *spectacular*. core.async is an absolute pleasure to work with. I'm so happy with how they have turned out, that I really want to share. You can find my work-in-progress here: https://github.com/brandonbloom/asyncx The primary file of interest is: https://github.com/brandonbloom/asyncx/blob/master/src/asyncx/core.clj At the time of this message, I've implemented the bulk of the relevant operators described here: http://msdn.microsoft.com/en-us/library/hh242961(v=vs.103).aspx All of my implementations utilize parking operations, so this library should be fully portable to ClojureScript. My notes describe any difference from Rx, notable omissions, and known issues: https://github.com/brandonbloom/asyncx/blob/master/notes I'll probably work more on this tonight and will update my notes as I go. Rich team: I understand that you guys will probably take a run at implementing this sort of library in the not too distant future. Please let me know if and how I can contribute to that effort. Cheers, Brandon -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/L4nEVho555k/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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/groups/opt_out. -- -- 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/groups/opt_out.
Re: Offline Clojure docs
On Mon 1 Jul 2013 at 07:44:17AM +0800, David Pollak wrote:
Is there an offline package of Clojure docs (the full core.* api docs,
cheat sheets, etc.)?
If you work with an editor with clojure REPL integration, you can
fashion your own cheat sheet.
I have a vim command that dumps a list of all public vars with arglists
(filtered by an optional pattern) into a scratch buffer like this:
;;; clojure.core {{{1
clojure.core/*1
clojure.core/*2
clojure.core/*3
…
clojure.core/xml-seq [root]
clojure.core/zero?[x]
clojure.core/zipmap [keys vals]
;;; clojure.core.protocols {{{1
…
Then I use the REPL commands in the buffer to look up docs, source, and
search vars with the editor. It's quite handy, and always up to date.
The funny {{{1 bits are fold markers that allow code folding by
namespace. A cheat sheet in org-mode format would be pretty nice for
emacs.
My apologies if you've already considered this. If you haven't, I hope
you find the suggestion useful.
guns
--
--
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/groups/opt_out.
Re: Microsoft Rx -style operations with core.async
On Sun, Jun 30, 2013 at 4:46 PM, Brandon Bloom brandon.d.bl...@gmail.comwrote: 2) It's somewhat annoying to always have to consider boolean false all the time. Since nil signifies a closed channel, if, when, if-let, and when-let are extremely convenient. Unfortunately, they are subtly bugged! You need nil? checks everywhere, cluttering up relatively nice code. Since nil-as-closed also has the consequence that you can't send nil over channels, one way around this would be to uniformly give everything sent a wrapper indicating that there's something inside; on the receiving end, you could have a macro or function to test whether the received item was nil or wrapped and take one branch in the former case and transparently remove the wrapper and proceed with the inner value in the other branch in the latter. Er, and that relates to the beginning of the sentence because then you could also send nil over the channels, if you wanted to. -- 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/groups/opt_out.
Re: Microsoft Rx -style operations with core.async
On Sun, Jun 30, 2013 at 7:46 PM, Brandon Bloom brandon.d.bl...@gmail.comwrote: Two bits of core.async feedback: 1) The (let [c chan] (go ...) c) pattern is *extremely-common*. Might be nice to have something like (go-as c ...) that expands to that pattern. My understanding with some member of the core.async team is that most channel based APIs fns should *take* a channel and only construct one as a default. Awesome stuff by the way doing Rx over core.async David -- -- 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/groups/opt_out.
Re: core.async
On Sun, Jun 30, 2013 at 4:42 PM, David Pollak dpollak...@gmail.com wrote:
Looking forward to it
being published (even as SNAPSHOT) in a Maven repo.
It's accessible like this:
(defproject async 0.1.0-SNAPSHOT
:description FIXME: write description
:url http://example.com/FIXME;
:license {:name Eclipse Public License
:url http://www.eclipse.org/legal/epl-v10.html}
:repositories {sonatype-oss-public
https://oss.sonatype.org/content/groups/public/}
:dependencies [[org.clojure/clojure 1.5.1]
[org.clojure/core.async 0.1.0-SNAPSHOT]])
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)
--
--
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/groups/opt_out.
Re: Microsoft Rx -style operations with core.async
My understanding with some member of the core.async team is that most channel based APIs fns should *take* a channel and only construct one as a default. Could you elaborate on and motivate that? -- -- 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/groups/opt_out.
Re: Microsoft Rx -style operations with core.async
Because of blocking on read/write on unbuffered channels - users might need more flexibility. On Sun, Jun 30, 2013 at 8:13 PM, Brandon Bloom brandon.d.bl...@gmail.comwrote: My understanding with some member of the core.async team is that most channel based APIs fns should *take* a channel and only construct one as a default. Could you elaborate on and motivate that? -- -- 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/groups/opt_out. -- -- 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/groups/opt_out.
Re: Offline Clojure docs
There are a couple of iPhone apps with Clojure docs: https://itunes.apple.com/us/app/clojuredoc/id401479442?mt=8 -- free, hasn't been updated for ages, but this is what I use anyway https://itunes.apple.com/us/app/clojure-bee-api-documentation/id524862532?mt=8 -- $0.99, hasn't been updated in a year, no idea about this one Sean On Sun, Jun 30, 2013 at 4:44 PM, David Pollak dpollak...@gmail.com wrote: Folks, Is there an offline package of Clojure docs (the full core.* api docs, cheat sheets, etc.)? I'm traveling with intermittent Internet connectivity (I'm in China now and it's marginal but I'm going to the UP in Michigan where there's no Internet within 15 miles of where I'm staying). With all the travel and flying and such, it'd be great to have all the docs without having to clone all the various source repositories. Thanks for your help. David -- -- 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/groups/opt_out. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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/groups/opt_out.
Re: ANN: faster zipper implementation
Thanks Zach! I've pulled your changes to 0.3.0-SNAPSHOT. Updated benchmark: Case: :clojure.zip Evaluation count : 75480 in 60 samples of 1258 calls. Execution time mean : 805.666773 µs Execution time std-deviation : 4.815877 µs Execution time lower quantile : 797.942766 µs ( 2.5%) Execution time upper quantile : 816.578299 µs (97.5%) Found 2 outliers in 60 samples (3. %) low-severe 2 (3. %) Variance from outliers : 1.6389 % Variance is slightly inflated by outliers Case: :fast-zip Evaluation count : 297900 in 60 samples of 4965 calls. Execution time mean : 202.892179 µs Execution time std-deviation : 848.456881 ns Execution time lower quantile : 201.212286 µs ( 2.5%) Execution time upper quantile : 204.187311 µs (97.5%) Found 1 outliers in 60 samples (1.6667 %) low-severe 1 (1.6667 %) Variance from outliers : 1.6389 % Variance is slightly inflated by outliers I did try adding some inline forms, but they didn't seem to help. See this branch: https://github.com/akhudek/fast-zip/tree/no-protocol+inline On Sunday, June 30, 2013 7:46:53 PM UTC-4, Zach Tellman wrote: This is really cool, thanks for doing this. I was able to eke out another 1.8x speedup by replacing '=' with 'identical?' for the keyword comparisons [1]. There also might be further room for improvement by defining inline forms for some of the smaller functions. Zach [1] https://github.com/ztellman/fast-zip/commit/ee7a64630389f36a539771658586a093369f7939 On Sunday, June 30, 2013 1:18:05 PM UTC-7, Alexander Hudek wrote: I've updated the clojure.zip implementation to use records internally. This achieves a speedup of roughly 2x. You can find the library below and on clojars: https://github.com/akhudek/fast-zip It's a drop in replacement for clojure.zip in terms of interface and usage. However, since the internal representation has changed, fast-zip locations cannot be used with the clojure.zip implementation. E.g. you cannot create a zipper with fast-zip, then use clojure.zip/next on the result. You must use fast.zip.core/next instead. In addition to the micro-benchmark provided, I've tried this in a larger project that makes extensive use of zippers and found a similar speedup. Comments and suggestions welcome. 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/groups/opt_out.
Re: Offline Clojure docs
Download here: https://github.com/clojure/clojure/tree/gh-pages -- -- 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/groups/opt_out.
Re: Translating simple path finding problem from prolog to core.logic
Thanks Norman! Not sure how I didn't realize that was happening, but it's working exactly as you describe. Thanks much for your help! Cheers, Craig On Sunday, June 30, 2013 2:40:48 PM UTC-5, Norman Richards wrote: Just like the prolog, you are generating an infinite number of solutions. run* will try and give you all of them. You can use clojure's lazy seq operations (first, take, etc...) or just ask for however many you want: (run 10 [q] (path2 1 7 q)) ((1 4 3 7) (1 2 4 3 7) (1 4 5 7) (1 2 4 5 7) (1 4 3 6 5 7) (1 2 4 3 6 5 7) (1 4 5 6 5 7) (1 2 4 5 6 5 7) (1 4 3 7 5 7) (1 2 4 3 7 5 7)) -- -- 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/groups/opt_out.
Re: [ANN] byte-streams: a rosetta stone for all the byte representations the jvm has to offer
Very cool, I've got a couple of question: the readme references optimized
transfers, what qualifies as an optimized transfer? Also, would it be
possible for byte-streams to give an estimation of the number of memory
copies that happen in a given conversion (maybe this is as simple as the
number of steps...)? Thanks for releasing this!
-- Dan
On Saturday, June 29, 2013 1:57:58 PM UTC-4, Zach Tellman wrote:
I've recently been trying to pull out useful pieces from some of my more
monolithic libraries. The most recent result is 'byte-streams' [1], a
library that figures how how to convert between different byte
representations (including character streams), and how to efficiently
transfer bytes between various byte sources and sinks. The net result is
that you can do something like:
(byte-streams/convert (File. /tmp/foo) String {:encoding utf-8})
and get a string representation of the file's contents. Of course, this
is already possible using 'slurp', but you could also convert it to a
CharSequence, or lazy sequence of ByteBuffers, or pretty much anything else
you can imagine. This is accomplished by traversing a graph of available
conversions (don't worry, it's memoized), so simply defining a new
conversion from some custom type to (say) a ByteBuffer will transitively
allow you to convert it to any other type.
As an aside, this sort of conversion mechanism isn't limited to just byte
representations, but I'm not sure if there's another large collection of
mostly-isomorphic types out there that would benefit from this. If anyone
has ideas on where else this could be applied, I'd be interested to hear
them.
Zach
[1] https://github.com/ztellman/byte-streams
--
--
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/groups/opt_out.
Re: Microsoft Rx -style operations with core.async
Then maybe we need (go-as [c arg] ...) On Sunday, June 30, 2013 8:15:45 PM UTC-4, David Nolen wrote: Because of blocking on read/write on unbuffered channels - users might need more flexibility. On Sun, Jun 30, 2013 at 8:13 PM, Brandon Bloom brandon...@gmail.comjavascript: wrote: My understanding with some member of the core.async team is that most channel based APIs fns should *take* a channel and only construct one as a default. Could you elaborate on and motivate that? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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/groups/opt_out. -- -- 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/groups/opt_out.
Re: Offline Clojure docs
Thanks everyone for the super helpful suggestions! On Mon, Jul 1, 2013 at 9:04 AM, Mark Engelberg mark.engelb...@gmail.comwrote: Download here: https://github.com/clojure/clojure/tree/gh-pages -- -- 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/groups/opt_out. -- -- 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/groups/opt_out.
Re: core.async
Thanks!
On Mon, Jul 1, 2013 at 8:13 AM, Sean Corfield seancorfi...@gmail.comwrote:
On Sun, Jun 30, 2013 at 4:42 PM, David Pollak dpollak...@gmail.com
wrote:
Looking forward to it
being published (even as SNAPSHOT) in a Maven repo.
It's accessible like this:
(defproject async 0.1.0-SNAPSHOT
:description FIXME: write description
:url http://example.com/FIXME;
:license {:name Eclipse Public License
:url http://www.eclipse.org/legal/epl-v10.html}
:repositories {sonatype-oss-public
https://oss.sonatype.org/content/groups/public/}
:dependencies [[org.clojure/clojure 1.5.1]
[org.clojure/core.async 0.1.0-SNAPSHOT]])
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)
--
--
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/groups/opt_out.
--
--
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/groups/opt_out.
