Re: concat primitive arrays
Java's System.arraycopy is the fastest you can get, since it delegates execution to a function implemented in C inside JVM. Simply, this is the fastest that your computer hardware can get. All in all Java arrays meet the same difficulties and implications as C arrays and that is why concationation of raw arrays is so complex, in contrast to higher-level collections which use objects and pointers (e.g. LinkedList). In other words, difficulties you experience are natural outcome of how computer's memory management is made and there is no way around them. You get the most of the speed from arrays because they are solid (not fragmented) chunks of bytes allocated in memory in the moment of their creation. For that very reason you cannot extend an existing array (the size cannot be changed after creation) and you can't concatenate it with another array since first it would have to be concatenated. The natural outcome also is that only arrays of same types can be concatenated with System.arraycopy since only array pointers store type data, and the contents are simply untyped bytes. And this is why it is byte-level and no type-checks are ever done besiedes the initial type-check. Again, higher-level pointer-based data structures like LinkedList or Queue can introduce boxed typed values, but that'd be waaay slower. Considering that only arrays of same type are concatenateable, creating a polymorphic function is easy - simply check the argument type like: ; first save types to use them later (def arr-type-int (class (ints 3))) ; ... same for other primitives... ; then in your func: (cond (= (class arr) arr-type-int) (do-int-concat) ...) For more reference: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/arrays.html http://docstore.mik.ua/orelly/java-ent/jnut/ch02_09.htm As an alternative, try looking into Java NIO buffers - they too are fast and too have some limits. But maybe you could make good of them, depends on your use case. Although somewhat in another vein, but still relating fast data management is https://groups.google.com/forum/?hl=en#!topic/clojure/BayfuaqMzvs which brings in C-like structs in. On Sunday, July 21, 2013 2:39:38 AM UTC+4, Brian Craft wrote: Here are some experiments that aren't polymorphic. The System/arraycopy version is fastest, by far. Is there any good way to make the other versions faster, or make them handle any array type? (defn bconcat [ arrays] (let [sizes (map count arrays) sizes_r (vec (reductions + sizes)) offsets (cons 0 (drop-last sizes_r)) total (last sizes_r) out (float-array total)] (dorun (map #(System/arraycopy %2 0 out %1 %3) offsets arrays sizes)) out)) (defn cconcat [ arrays] (let [vs (map vec arrays) cc (apply concat vs)] (float-array cc))) (defn dconcat [ arrays] (let [vs (map vec arrays) cc (reduce into [] vs)] (float-array cc))) (defn econcat [ arrays] (let [cc (reduce into [] arrays)] (float-array cc))) On Saturday, July 20, 2013 2:24:14 PM UTC-7, Brian Craft wrote: Is there an easy, fast way to concat primitive arrays? I was hoping java arrays had some common interface for this, but I haven't found much of use. I mostly see code like this: byte[] c = new byte[a.length + b.length]; System.arraycopy(a, 0, c, 0, a.length); System.arraycopy(b, 0, c, a.length, b.length); which only works for bytes (in this case). -- -- 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: Making RPCs with Shoreleave
Considering the severity of the bug that i found, i want to ask if someone is using Shoreleave's rpc without any problems? Maybe it's me missing something? Or maybe someone run into the same problem too? On Saturday, July 20, 2013 2:16:02 PM UTC+4, Alex Fowler wrote: That wasn't hte case either. After some buzz with ddellacosta and others on #clojure, it was found that the RPC call is unable to find that very remote procedure I was requesting. Then I have verified that all is properly stored in the remote procedures registry on backend and that the front end makes proper calls. The problem was that the backend was expecting edn while the frontend was sending it in html-form format in request body. I am just a beginner with Clojure's web stack, so I think that maybe I missed some wrappers with Noir or Ring, but I was doing all according to the tutorial and it failed to work. So I had to manually override several functions from Shoreleave back-end and front-end to behave coherently and send and receive data in edn format. I think this makes a patch for the library since the RPC functionality is broken out-of-the-box. Unless I am missing something crucial, but examples I found miss that either... четверг, 18 июля 2013 г., 15:42:35 UTC+4 пользователь terjesb написал: The default /_shoreleave endpoint should work if you're running using lein ring server. Are you running a WAR in a container? If so, I don't think Shoreleave currently picks up the context. If you have only one client app, you could proxy this using nginx in front on your container. For multiple client apps (also standalone, without a container), you may need to do what I did: override default /_shoreleave in your app: (wrap-rpc /your-context/_shoreleave) and then (binding [shoreleave.remotes.http-rpc/*remote-uri* /your-context/_shoreleave] ) around your client calls. Terje. kl. 10:50:17 UTC+2 mandag 15. juli 2013 skrev Alex Fowler følgende: Did not work.. all that is strange since I've been following the manual step-by-step.. looks like the shoreleave's wrapper does not even create a http route for itself... any other ideas? On Friday, July 12, 2013 7:14:42 AM UTC+4, Samrat Man Singh wrote: I think you need to (use projectname.ajax) in your projectname.handler page. If I remember correctly, there's also a way to specify which namespace your remote function is in. On Thursday, July 11, 2013 10:42:15 PM UTC+5:45, Alex Fowler wrote: Hi all, this is my first experience with Shoreleave and I'm trying to use it's RPC mechanism to perform AJAX tasks. However, on a call to a remote procedure, I get this: ` 1. POST http://localhost:8080/_shoreleave 404 (Not Found) cljs.js:25223 http://localhost:8080/js/cljs.js 1. goog.net.XhrIo.sendcljs.js:25223http://localhost:8080/js/cljs.js 2. xhr__delegatecljs.js:31416 http://localhost:8080/js/cljs.js 3. xhrcljs.js:31423 http://localhost:8080/js/cljs.js 4. remote_callback__delegatecljs.js:32504http://localhost:8080/js/cljs.js 5. remote_callbackcljs.js:32515http://localhost:8080/js/cljs.js 6. load_storecljs.js:32745 http://localhost:8080/js/cljs.js 7. mk__AMPERSAND__load_store__delegatecljs.js:32755http://localhost:8080/js/cljs.js 8. mk__AMPERSAND__load_storecljs.js:32763http://localhost:8080/js/cljs.js 9. example_storecljs.js:33341 http://localhost:8080/js/cljs.js 10. simplecljs.js:33361 http://localhost:8080/js/cljs.js 11. setup_guicljs.js:33962 http://localhost:8080/js/cljs.js 12. setup_allcljs.js:33982 http://localhost:8080/js/cljs.js 13. startupcljs.js:41166 http://localhost:8080/js/cljs.js 14. onloadapp:2 http://localhost:8080/app XHR ERROR: Not Found ` What is wrong and how do I fix it? I have been following this tutorial: Shoreleave Tutorial 10 - Introducing Ajaxhttps://github.com/magomimmo/modern-cljs/blob/master/doc/tutorial-10.md my code (relevant parts) is this: Project.clj: ` (defproject projectname 0.1.0-SNAPSHOT :description FIXME: write description :url http://example.com/FIXME; :dependencies [[org.clojure/clojure 1.5.1] [lib-noir 0.6.3] [compojure 1.2.0-SNAPSHOT] [ring-server 0.2.8] [clabango 0.5] [hiccup 1.0.3] [com.taoensso/timbre 2.1.2] [com.taoensso/tower 1.7.1] [markdown-clj 0.9.26] ; -- ajax [shoreleave 0.3.0] [shoreleave/shoreleave-remote-ring 0.3.0] [shoreleave/shoreleave-remote 0.3.0] ; -- cljs [com.keminglabs/singult 0.1.6] [enfocus 1.0.1] [jayq 2.3.0] ] :plugins [[lein-ring 0.8.5] [lein-cljsbuild 0.3.2]]
using httpkit + core.async to build a simple WebSocket-based chat demo
Hi folks, More core.async fun. Would love to hear comments, criticisms, etc., especially on how to better integrate core.async into this. Otherwise, maybe it can be inspiration to someone else to do something grander. Granted, it's pretty stupidly simple. https://github.com/ddellacosta/cljs-core-async-chat Really enjoying playing with core.async, especially with ClojureScript! Cheers, DD -- -- 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: using httpkit + core.async to build a simple WebSocket-based chat demo
Thanks for sharing this! I'm in a similar mindset right now, working on a cljs port of a JS WebSocket library (AutoBahnJS) for clj-wamphttp://cljwamp.us . Examples like these have been very helpful for getting up to speed on ClojureScript and core.async. Cheers, ~Christopher Martin On Sunday, July 21, 2013 11:43:25 AM UTC-4, David Della Costa wrote: Hi folks, More core.async fun. Would love to hear comments, criticisms, etc., especially on how to better integrate core.async into this. Otherwise, maybe it can be inspiration to someone else to do something grander. Granted, it's pretty stupidly simple. https://github.com/ddellacosta/cljs-core-async-chat Really enjoying playing with core.async, especially with ClojureScript! Cheers, DD -- -- 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: concat primitive arrays
Is there a way to create an array with the type of another array? (type arr) returns the array type, but make-array wants the element type not the array type, so (make-array (type arr) n) doesn't work as one might hope. On Sunday, July 21, 2013 8:36:22 AM UTC-7, Alex Fowler wrote: Java's System.arraycopy is the fastest you can get, since it delegates execution to a function implemented in C inside JVM. Simply, this is the fastest that your computer hardware can get. All in all Java arrays meet the same difficulties and implications as C arrays and that is why concationation of raw arrays is so complex, in contrast to higher-level collections which use objects and pointers (e.g. LinkedList). In other words, difficulties you experience are natural outcome of how computer's memory management is made and there is no way around them. You get the most of the speed from arrays because they are solid (not fragmented) chunks of bytes allocated in memory in the moment of their creation. For that very reason you cannot extend an existing array (the size cannot be changed after creation) and you can't concatenate it with another array since first it would have to be concatenated. The natural outcome also is that only arrays of same types can be concatenated with System.arraycopy since only array pointers store type data, and the contents are simply untyped bytes. And this is why it is byte-level and no type-checks are ever done besiedes the initial type-check. Again, higher-level pointer-based data structures like LinkedList or Queue can introduce boxed typed values, but that'd be waaay slower. Considering that only arrays of same type are concatenateable, creating a polymorphic function is easy - simply check the argument type like: ; first save types to use them later (def arr-type-int (class (ints 3))) ; ... same for other primitives... ; then in your func: (cond (= (class arr) arr-type-int) (do-int-concat) ...) For more reference: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/arrays.html http://docstore.mik.ua/orelly/java-ent/jnut/ch02_09.htm As an alternative, try looking into Java NIO buffers - they too are fast and too have some limits. But maybe you could make good of them, depends on your use case. Although somewhat in another vein, but still relating fast data management is https://groups.google.com/forum/?hl=en#!topic/clojure/BayfuaqMzvs which brings in C-like structs in. On Sunday, July 21, 2013 2:39:38 AM UTC+4, Brian Craft wrote: Here are some experiments that aren't polymorphic. The System/arraycopy version is fastest, by far. Is there any good way to make the other versions faster, or make them handle any array type? (defn bconcat [ arrays] (let [sizes (map count arrays) sizes_r (vec (reductions + sizes)) offsets (cons 0 (drop-last sizes_r)) total (last sizes_r) out (float-array total)] (dorun (map #(System/arraycopy %2 0 out %1 %3) offsets arrays sizes)) out)) (defn cconcat [ arrays] (let [vs (map vec arrays) cc (apply concat vs)] (float-array cc))) (defn dconcat [ arrays] (let [vs (map vec arrays) cc (reduce into [] vs)] (float-array cc))) (defn econcat [ arrays] (let [cc (reduce into [] arrays)] (float-array cc))) On Saturday, July 20, 2013 2:24:14 PM UTC-7, Brian Craft wrote: Is there an easy, fast way to concat primitive arrays? I was hoping java arrays had some common interface for this, but I haven't found much of use. I mostly see code like this: byte[] c = new byte[a.length + b.length]; System.arraycopy(a, 0, c, 0, a.length); System.arraycopy(b, 0, c, a.length, b.length); which only works for bytes (in this case). -- -- 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: java interop: passing int[]
Hmmm, true about proxies.. as for hiphip - I did not use it yet, but I thought that it may be useful for fast array operations, sorry confused the posts :) I gonna try it sometime I think.. and I think that it has no built-in matrix ops, but there was a library somewhere that did matrix ops.. On Saturday, July 20, 2013 10:05:30 PM UTC+4, Brian Craft wrote: I've been looking at hiphip, though it's not clear to me how it's related to h2 user functions. ;) It wasn't immediately clear to me if hiphip handles multidimensional matix operations. On Saturday, July 20, 2013 9:32:50 AM UTC-7, Alex Fowler wrote: BTW, take a look http://blog.getprismatic.com/blog/2013/7/10/introducing-hiphip-array-fast-and-flexible-numerical-computation-in-clojure суббота, 20 июля 2013 г., 17:42:36 UTC+4 пользователь Brian Craft написал: I'm trying to write a user function for h2. I think that means I need gen-class, but I'm extremely fuzzy on how java class loading works. Perhaps my question is moot, because I just ran across this obscure note in a gen-class example: ;; declare only new methods, not superclass methods If I'm implementing an interface in h2, does that mean I shouldn't declare the methods? I also found a stackoverflow answer that suggested something like [[Ljava.lang.Integer;] which looks like black magic, and I can't find this in the docs anywhere. On Saturday, July 20, 2013 2:39:06 AM UTC-7, Alex Fowler wrote: Some questions to clarify things up: Do you mean - how do you create that type of value or how do you generatte a method that accepts that very type? Are you sure you need to use gen-class and not proxy or reify? суббота, 20 июля 2013 г., 7:28:03 UTC+4 пользователь Brian Craft написал: For implementing a method with this signature int getType(int[] inputTypes) How would I declare inputTypes in gen-class? -- -- 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: concat primitive arrays
Using getComponentType, it appears to be handling different primitive array types ok: (defn fconcat [ arrays] (let [sizes (map count arrays) sizes_r (vec (reductions + sizes)) offsets (cons 0 (drop-last sizes_r)) total (last sizes_r) out (make-array (.getComponentType (class (first arrays))) total)] (dorun (map #(System/arraycopy %2 0 out %1 %3) offsets arrays sizes)) out)) On Sunday, July 21, 2013 12:26:26 PM UTC-7, Brian Craft wrote: (make-array (.getComponentType (class arr)) n) seems to work. On Sunday, July 21, 2013 12:22:41 PM UTC-7, Brian Craft wrote: Is there a way to create an array with the type of another array? (type arr) returns the array type, but make-array wants the element type not the array type, so (make-array (type arr) n) doesn't work as one might hope. On Sunday, July 21, 2013 8:36:22 AM UTC-7, Alex Fowler wrote: Java's System.arraycopy is the fastest you can get, since it delegates execution to a function implemented in C inside JVM. Simply, this is the fastest that your computer hardware can get. All in all Java arrays meet the same difficulties and implications as C arrays and that is why concationation of raw arrays is so complex, in contrast to higher-level collections which use objects and pointers (e.g. LinkedList). In other words, difficulties you experience are natural outcome of how computer's memory management is made and there is no way around them. You get the most of the speed from arrays because they are solid (not fragmented) chunks of bytes allocated in memory in the moment of their creation. For that very reason you cannot extend an existing array (the size cannot be changed after creation) and you can't concatenate it with another array since first it would have to be concatenated. The natural outcome also is that only arrays of same types can be concatenated with System.arraycopy since only array pointers store type data, and the contents are simply untyped bytes. And this is why it is byte-level and no type-checks are ever done besiedes the initial type-check. Again, higher-level pointer-based data structures like LinkedList or Queue can introduce boxed typed values, but that'd be waaay slower. Considering that only arrays of same type are concatenateable, creating a polymorphic function is easy - simply check the argument type like: ; first save types to use them later (def arr-type-int (class (ints 3))) ; ... same for other primitives... ; then in your func: (cond (= (class arr) arr-type-int) (do-int-concat) ...) For more reference: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/arrays.html http://docstore.mik.ua/orelly/java-ent/jnut/ch02_09.htm As an alternative, try looking into Java NIO buffers - they too are fast and too have some limits. But maybe you could make good of them, depends on your use case. Although somewhat in another vein, but still relating fast data management is https://groups.google.com/forum/?hl=en#!topic/clojure/BayfuaqMzvs which brings in C-like structs in. On Sunday, July 21, 2013 2:39:38 AM UTC+4, Brian Craft wrote: Here are some experiments that aren't polymorphic. The System/arraycopy version is fastest, by far. Is there any good way to make the other versions faster, or make them handle any array type? (defn bconcat [ arrays] (let [sizes (map count arrays) sizes_r (vec (reductions + sizes)) offsets (cons 0 (drop-last sizes_r)) total (last sizes_r) out (float-array total)] (dorun (map #(System/arraycopy %2 0 out %1 %3) offsets arrays sizes)) out)) (defn cconcat [ arrays] (let [vs (map vec arrays) cc (apply concat vs)] (float-array cc))) (defn dconcat [ arrays] (let [vs (map vec arrays) cc (reduce into [] vs)] (float-array cc))) (defn econcat [ arrays] (let [cc (reduce into [] arrays)] (float-array cc))) On Saturday, July 20, 2013 2:24:14 PM UTC-7, Brian Craft wrote: Is there an easy, fast way to concat primitive arrays? I was hoping java arrays had some common interface for this, but I haven't found much of use. I mostly see code like this: byte[] c = new byte[a.length + b.length]; System.arraycopy(a, 0, c, 0, a.length); System.arraycopy(b, 0, c, a.length, b.length); which only works for bytes (in this case). -- -- 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
Re: concat primitive arrays
(make-array (.getComponentType (class arr)) n) seems to work. On Sunday, July 21, 2013 12:22:41 PM UTC-7, Brian Craft wrote: Is there a way to create an array with the type of another array? (type arr) returns the array type, but make-array wants the element type not the array type, so (make-array (type arr) n) doesn't work as one might hope. On Sunday, July 21, 2013 8:36:22 AM UTC-7, Alex Fowler wrote: Java's System.arraycopy is the fastest you can get, since it delegates execution to a function implemented in C inside JVM. Simply, this is the fastest that your computer hardware can get. All in all Java arrays meet the same difficulties and implications as C arrays and that is why concationation of raw arrays is so complex, in contrast to higher-level collections which use objects and pointers (e.g. LinkedList). In other words, difficulties you experience are natural outcome of how computer's memory management is made and there is no way around them. You get the most of the speed from arrays because they are solid (not fragmented) chunks of bytes allocated in memory in the moment of their creation. For that very reason you cannot extend an existing array (the size cannot be changed after creation) and you can't concatenate it with another array since first it would have to be concatenated. The natural outcome also is that only arrays of same types can be concatenated with System.arraycopy since only array pointers store type data, and the contents are simply untyped bytes. And this is why it is byte-level and no type-checks are ever done besiedes the initial type-check. Again, higher-level pointer-based data structures like LinkedList or Queue can introduce boxed typed values, but that'd be waaay slower. Considering that only arrays of same type are concatenateable, creating a polymorphic function is easy - simply check the argument type like: ; first save types to use them later (def arr-type-int (class (ints 3))) ; ... same for other primitives... ; then in your func: (cond (= (class arr) arr-type-int) (do-int-concat) ...) For more reference: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/arrays.html http://docstore.mik.ua/orelly/java-ent/jnut/ch02_09.htm As an alternative, try looking into Java NIO buffers - they too are fast and too have some limits. But maybe you could make good of them, depends on your use case. Although somewhat in another vein, but still relating fast data management is https://groups.google.com/forum/?hl=en#!topic/clojure/BayfuaqMzvs which brings in C-like structs in. On Sunday, July 21, 2013 2:39:38 AM UTC+4, Brian Craft wrote: Here are some experiments that aren't polymorphic. The System/arraycopy version is fastest, by far. Is there any good way to make the other versions faster, or make them handle any array type? (defn bconcat [ arrays] (let [sizes (map count arrays) sizes_r (vec (reductions + sizes)) offsets (cons 0 (drop-last sizes_r)) total (last sizes_r) out (float-array total)] (dorun (map #(System/arraycopy %2 0 out %1 %3) offsets arrays sizes)) out)) (defn cconcat [ arrays] (let [vs (map vec arrays) cc (apply concat vs)] (float-array cc))) (defn dconcat [ arrays] (let [vs (map vec arrays) cc (reduce into [] vs)] (float-array cc))) (defn econcat [ arrays] (let [cc (reduce into [] arrays)] (float-array cc))) On Saturday, July 20, 2013 2:24:14 PM UTC-7, Brian Craft wrote: Is there an easy, fast way to concat primitive arrays? I was hoping java arrays had some common interface for this, but I haven't found much of use. I mostly see code like this: byte[] c = new byte[a.length + b.length]; System.arraycopy(a, 0, c, 0, a.length); System.arraycopy(b, 0, c, a.length, b.length); which only works for bytes (in this case). -- -- 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: Interest in a Full Featured Clojure Blog Engine
Ooh. Ok, lemme check it out. On Sat, Jul 20, 2013 at 10:34 PM, Chris Allen callen.2...@gmail.com wrote: http://github.com/bitemyapp/neubite/ Could probably use a WYSIWYG editor, beyond that, pretty serviceable. -- -- 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: concat primitive arrays
Cool, thanks. On Sunday, July 21, 2013 12:59:16 PM UTC-7, Alex Fowler wrote: Glad you've found it! :D As an off-topic side-note: please, use no underscores in naming, use hyphens instead, this is lisp's style... like sizes_r become sizes-r. Many ppl will thank you later :) On Sunday, July 21, 2013 11:39:17 PM UTC+4, Brian Craft wrote: Using getComponentType, it appears to be handling different primitive array types ok: (defn fconcat [ arrays] (let [sizes (map count arrays) sizes_r (vec (reductions + sizes)) offsets (cons 0 (drop-last sizes_r)) total (last sizes_r) out (make-array (.getComponentType (class (first arrays))) total)] (dorun (map #(System/arraycopy %2 0 out %1 %3) offsets arrays sizes)) out)) On Sunday, July 21, 2013 12:26:26 PM UTC-7, Brian Craft wrote: (make-array (.getComponentType (class arr)) n) seems to work. On Sunday, July 21, 2013 12:22:41 PM UTC-7, Brian Craft wrote: Is there a way to create an array with the type of another array? (type arr) returns the array type, but make-array wants the element type not the array type, so (make-array (type arr) n) doesn't work as one might hope. On Sunday, July 21, 2013 8:36:22 AM UTC-7, Alex Fowler wrote: Java's System.arraycopy is the fastest you can get, since it delegates execution to a function implemented in C inside JVM. Simply, this is the fastest that your computer hardware can get. All in all Java arrays meet the same difficulties and implications as C arrays and that is why concationation of raw arrays is so complex, in contrast to higher-level collections which use objects and pointers (e.g. LinkedList). In other words, difficulties you experience are natural outcome of how computer's memory management is made and there is no way around them. You get the most of the speed from arrays because they are solid (not fragmented) chunks of bytes allocated in memory in the moment of their creation. For that very reason you cannot extend an existing array (the size cannot be changed after creation) and you can't concatenate it with another array since first it would have to be concatenated. The natural outcome also is that only arrays of same types can be concatenated with System.arraycopy since only array pointers store type data, and the contents are simply untyped bytes. And this is why it is byte-level and no type-checks are ever done besiedes the initial type-check. Again, higher-level pointer-based data structures like LinkedList or Queue can introduce boxed typed values, but that'd be waaay slower. Considering that only arrays of same type are concatenateable, creating a polymorphic function is easy - simply check the argument type like: ; first save types to use them later (def arr-type-int (class (ints 3))) ; ... same for other primitives... ; then in your func: (cond (= (class arr) arr-type-int) (do-int-concat) ...) For more reference: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/arrays.html http://docstore.mik.ua/orelly/java-ent/jnut/ch02_09.htm As an alternative, try looking into Java NIO buffers - they too are fast and too have some limits. But maybe you could make good of them, depends on your use case. Although somewhat in another vein, but still relating fast data management is https://groups.google.com/forum/?hl=en#!topic/clojure/BayfuaqMzvs which brings in C-like structs in. On Sunday, July 21, 2013 2:39:38 AM UTC+4, Brian Craft wrote: Here are some experiments that aren't polymorphic. The System/arraycopy version is fastest, by far. Is there any good way to make the other versions faster, or make them handle any array type? (defn bconcat [ arrays] (let [sizes (map count arrays) sizes_r (vec (reductions + sizes)) offsets (cons 0 (drop-last sizes_r)) total (last sizes_r) out (float-array total)] (dorun (map #(System/arraycopy %2 0 out %1 %3) offsets arrays sizes)) out)) (defn cconcat [ arrays] (let [vs (map vec arrays) cc (apply concat vs)] (float-array cc))) (defn dconcat [ arrays] (let [vs (map vec arrays) cc (reduce into [] vs)] (float-array cc))) (defn econcat [ arrays] (let [cc (reduce into [] arrays)] (float-array cc))) On Saturday, July 20, 2013 2:24:14 PM UTC-7, Brian Craft wrote: Is there an easy, fast way to concat primitive arrays? I was hoping java arrays had some common interface for this, but I haven't found much of use. I mostly see code like this: byte[] c = new byte[a.length + b.length]; System.arraycopy(a, 0, c, 0, a.length); System.arraycopy(b, 0, c, a.length, b.length); which only works for bytes (in this case). -- -- 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 -
Re: Interest in a Full Featured Clojure Blog Engine
Il giorno domenica 21 luglio 2013 01:09:48 UTC+2, frye ha scritto: Cool. I'm very open to any help you can offer. Right now, I'm working through: - if / how to attach assets (images, etc) to .rtf or .md file formats (see herehttp://stackoverflow.com/questions/17758621/howto-attach-image-audio-video-pdf-to-rtf-md ) As far as I know, in Markdown you can show images inline but that's all. Anyway, it's possible to write HTML code inside a Markdown text and that's how I approach this problem. If I have to embed for example a video, I just use the video HTML element. There is a more comprehensive text markup language called AsciiDochttp://powerman.name/doc/asciidoc(used by O'Reilly for their books if I recall correctly, Chas is much more authoritative than me in this ;) And it should be possible to use it in the JVM using asciidoctor-java-integrationhttps://github.com/asciidoctor/asciidoctor-java-integration. Maybe it can be an additional option. - what I should use to model workflow; possibly laminahttps://github.com/ztellman/lamina ? I'm not sure Lamina is the right tool for this job. What are your ideas for modeling and executing workflows? - - what's the best interface messages to pass between the core service and plug-ins; I'm thinking of the nreplhttps://github.com/clojure/tools.nreplprotocol, but I need to work out: 1. communication between plug-ins 2. way to list possible actions (namespace qualify action names) 3. way to publish actions 4. way for core service to listen for messages from a plug-in 5. way to pass binary data (asset(s)) between stefon and plug-in I've not investigated this in depth, but why not a simple HTTP interface that talks EDN? I think the next week or so will be investigating this list. It represents most of the hurdles I see in getting a successful core / plug-in architecture running. Insight or expertise on any of these points is very welcome. I don't know if you have read thishttp://www.chris-granger.com/2013/01/24/the-ide-as-data/, but maybe it could give you some ideas about the plugin architecture. The blog engine as data. The plugin system could be the kernel, and maybe most features could be implemented as plugins. Just dreaming out loud :) Cheers Tim Washington Interruptsoftware.ca / Bkeeping.com On Sat, Jul 20, 2013 at 1:31 PM, Manuel Paccagnella manuel.pa...@gmail.com javascript: wrote: Interesting +1 I've slammed together some quick and dirty Clojure code and wrote my own little blog engine (I'll not link the repo, the code is... well quickdirty: I needed something running quickly). But it has the bare minimum and I didn't find any real feature complete blog engine as the one you are proposing. An engine designed with a clojuresque vision behind its architecture (simple, modular, extensible, and made of composable pieces) would be very interesting to see come to life. I'll read through the comments and hopefully add something when this headache will give me a break. I'm about to begin writing a prototype system for my dayjob, but I'd like to help you in this endeavour (I hope I'll have the time to do that). Cheers, Manuel -- -- 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: Interest in a Full Featured Clojure Blog Engine
Lately, a lot of people are moving away from dynamic blog engines like Wordpress, and starting to use static blog generators like Jekyll. You may want to consider this route instead. I'm sure a plugin system would still be relevant and useful for a static blog generator. -Steven On Thu, Jul 18, 2013 at 9:24 AM, Timothy Washington twash...@gmail.comwrote: Hello, I'm thinking of how to build a composable blogging engine in Clojure. There have been a few attempts at this, with cow-bloghttps://github.com/briancarper/cow-blogand my-blog https://github.com/georgerogers42/my-blog. But these seem to be abandoned, and not heavily used. Vijay Kiran, last year, even wrote a series of blog posts (see herehttp://www.vijaykiran.com/2012/01/17/web-application-development-with-clojure-part-2/) about building a blog engine. As far as a list of posts goes, the data structure for each record was simple: - title - content - status - created-date - published-date - author I think this is the most basic thing you could do, to get running. But I'm thinking of approaching the feature set of Wordpresshttp://codex.wordpress.org/WordPress_Features. So I'm thinking of the Data Structure(s) of features like: - Web UI component; wyswyg editor, themes - Server component; embeddable in Compojure or Pedestal - Database component; - raw data structures, txt, rtf, images, audio, videos, documents - adapters for Datomic, SQL(Postgres, etc), NoSQL (Mongo, etc) - tags / categories for content - Authentication Authorization; OpenID - Workflow component; preview, collaboration editor review - Commenting component; default or an external comments service, like disqus http://disqus.com or discourse http://www.discourse.org - Administration Console - Plug-in support - Import / Export - Multi-lang / Internationalization I know that I currently wish I had a Clojure weblog engine that I could stick into a site I'm building. If there's already something available, I'll obviously just use that. But otherwise, is this something that would be interesting to people? Thanks Tim Washington Interruptsoftware.ca / Bkeeping.com 416.843.9060 -- -- 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: Interest in a Full Featured Clojure Blog Engine
The more I think about the static blog generator idea, the more I think it's different enough to be a separate project. But anyway, I already wrote this list of pros/cons to why I think static blog generators are better, so might as well post it: Pros: - Runs anywhere you can host HTML, such as Github Pages (which is free btw) - No need for authentication/authorization code - No need for WYSWYG editor - No need for server component - No need for a database - No need for an admin console (probably replaced by config files) - Import/export is probably easier, since blog entries are just files Cons: - Can't make middleware plugins (but I can't think of a need for one) - Probably would need ugly/tedious user-editable config files - Can't remember the last one, but (or thus?) it probably wasn't important -Steven On Sun, Jul 21, 2013 at 5:23 PM, Steven Degutis sbdegu...@gmail.com wrote: Lately, a lot of people are moving away from dynamic blog engines like Wordpress, and starting to use static blog generators like Jekyll. You may want to consider this route instead. I'm sure a plugin system would still be relevant and useful for a static blog generator. -Steven On Thu, Jul 18, 2013 at 9:24 AM, Timothy Washington twash...@gmail.comwrote: Hello, I'm thinking of how to build a composable blogging engine in Clojure. There have been a few attempts at this, with cow-bloghttps://github.com/briancarper/cow-blogand my-blog https://github.com/georgerogers42/my-blog. But these seem to be abandoned, and not heavily used. Vijay Kiran, last year, even wrote a series of blog posts (see herehttp://www.vijaykiran.com/2012/01/17/web-application-development-with-clojure-part-2/) about building a blog engine. As far as a list of posts goes, the data structure for each record was simple: - title - content - status - created-date - published-date - author I think this is the most basic thing you could do, to get running. But I'm thinking of approaching the feature set of Wordpresshttp://codex.wordpress.org/WordPress_Features. So I'm thinking of the Data Structure(s) of features like: - Web UI component; wyswyg editor, themes - Server component; embeddable in Compojure or Pedestal - Database component; - raw data structures, txt, rtf, images, audio, videos, documents - adapters for Datomic, SQL(Postgres, etc), NoSQL (Mongo, etc) - tags / categories for content - Authentication Authorization; OpenID - Workflow component; preview, collaboration editor review - Commenting component; default or an external comments service, like disqus http://disqus.com or discourse http://www.discourse.org - Administration Console - Plug-in support - Import / Export - Multi-lang / Internationalization I know that I currently wish I had a Clojure weblog engine that I could stick into a site I'm building. If there's already something available, I'll obviously just use that. But otherwise, is this something that would be interesting to people? Thanks Tim Washington Interruptsoftware.ca / Bkeeping.com 416.843.9060 -- -- 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: concat primitive arrays
Glad you've found it! :D As an off-topic side-note: please, use no underscores in naming, use hyphens instead, this is lisp's style... like sizes_r become sizes-r. Many ppl will thank you later :) On Sunday, July 21, 2013 11:39:17 PM UTC+4, Brian Craft wrote: Using getComponentType, it appears to be handling different primitive array types ok: (defn fconcat [ arrays] (let [sizes (map count arrays) sizes_r (vec (reductions + sizes)) offsets (cons 0 (drop-last sizes_r)) total (last sizes_r) out (make-array (.getComponentType (class (first arrays))) total)] (dorun (map #(System/arraycopy %2 0 out %1 %3) offsets arrays sizes)) out)) On Sunday, July 21, 2013 12:26:26 PM UTC-7, Brian Craft wrote: (make-array (.getComponentType (class arr)) n) seems to work. On Sunday, July 21, 2013 12:22:41 PM UTC-7, Brian Craft wrote: Is there a way to create an array with the type of another array? (type arr) returns the array type, but make-array wants the element type not the array type, so (make-array (type arr) n) doesn't work as one might hope. On Sunday, July 21, 2013 8:36:22 AM UTC-7, Alex Fowler wrote: Java's System.arraycopy is the fastest you can get, since it delegates execution to a function implemented in C inside JVM. Simply, this is the fastest that your computer hardware can get. All in all Java arrays meet the same difficulties and implications as C arrays and that is why concationation of raw arrays is so complex, in contrast to higher-level collections which use objects and pointers (e.g. LinkedList). In other words, difficulties you experience are natural outcome of how computer's memory management is made and there is no way around them. You get the most of the speed from arrays because they are solid (not fragmented) chunks of bytes allocated in memory in the moment of their creation. For that very reason you cannot extend an existing array (the size cannot be changed after creation) and you can't concatenate it with another array since first it would have to be concatenated. The natural outcome also is that only arrays of same types can be concatenated with System.arraycopy since only array pointers store type data, and the contents are simply untyped bytes. And this is why it is byte-level and no type-checks are ever done besiedes the initial type-check. Again, higher-level pointer-based data structures like LinkedList or Queue can introduce boxed typed values, but that'd be waaay slower. Considering that only arrays of same type are concatenateable, creating a polymorphic function is easy - simply check the argument type like: ; first save types to use them later (def arr-type-int (class (ints 3))) ; ... same for other primitives... ; then in your func: (cond (= (class arr) arr-type-int) (do-int-concat) ...) For more reference: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/arrays.html http://docstore.mik.ua/orelly/java-ent/jnut/ch02_09.htm As an alternative, try looking into Java NIO buffers - they too are fast and too have some limits. But maybe you could make good of them, depends on your use case. Although somewhat in another vein, but still relating fast data management is https://groups.google.com/forum/?hl=en#!topic/clojure/BayfuaqMzvs which brings in C-like structs in. On Sunday, July 21, 2013 2:39:38 AM UTC+4, Brian Craft wrote: Here are some experiments that aren't polymorphic. The System/arraycopy version is fastest, by far. Is there any good way to make the other versions faster, or make them handle any array type? (defn bconcat [ arrays] (let [sizes (map count arrays) sizes_r (vec (reductions + sizes)) offsets (cons 0 (drop-last sizes_r)) total (last sizes_r) out (float-array total)] (dorun (map #(System/arraycopy %2 0 out %1 %3) offsets arrays sizes)) out)) (defn cconcat [ arrays] (let [vs (map vec arrays) cc (apply concat vs)] (float-array cc))) (defn dconcat [ arrays] (let [vs (map vec arrays) cc (reduce into [] vs)] (float-array cc))) (defn econcat [ arrays] (let [cc (reduce into [] arrays)] (float-array cc))) On Saturday, July 20, 2013 2:24:14 PM UTC-7, Brian Craft wrote: Is there an easy, fast way to concat primitive arrays? I was hoping java arrays had some common interface for this, but I haven't found much of use. I mostly see code like this: byte[] c = new byte[a.length + b.length]; System.arraycopy(a, 0, c, 0, a.length); System.arraycopy(b, 0, c, a.length, b.length); which only works for bytes (in this case). -- -- 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
Re: using httpkit + core.async to build a simple WebSocket-based chat demo
Excellent, glad to hear it. And I'd love to hear more about how porting AutobahnJS goes for you! Seems like a perfect application of core.async on the client-side. (2013/07/22 3:10), Christopher Martin wrote: Thanks for sharing this! I'm in a similar mindset right now, working on a cljs port of a JS WebSocket library (AutoBahnJS) for clj-wamp http://cljwamp.us. Examples like these have been very helpful for getting up to speed on ClojureScript and core.async. Cheers, ~Christopher Martin On Sunday, July 21, 2013 11:43:25 AM UTC-4, David Della Costa wrote: Hi folks, More core.async fun. Would love to hear comments, criticisms, etc., especially on how to better integrate core.async into this. Otherwise, maybe it can be inspiration to someone else to do something grander. Granted, it's pretty stupidly simple. https://github.com/ddellacosta/cljs-core-async-chat https://github.com/ddellacosta/cljs-core-async-chat Really enjoying playing with core.async, especially with ClojureScript! Cheers, DD -- -- 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: Interest in a Full Featured Clojure Blog Engine
I'm a fan of static generators too, but one large con for a lot of people is lack of commenting. Personally I like the article-with-no-comments format, but it's not for everyone. You can use Disqus or similar, but it has its own issues starting with the fact that you give all your data to someone else. More pros for static generators are that you can use whichever editor you want and you get version control easily too. On 22 July 2013 10:33, Steven Degutis sbdegu...@gmail.com wrote: The more I think about the static blog generator idea, the more I think it's different enough to be a separate project. But anyway, I already wrote this list of pros/cons to why I think static blog generators are better, so might as well post it: Pros: - Runs anywhere you can host HTML, such as Github Pages (which is free btw) - No need for authentication/authorization code - No need for WYSWYG editor - No need for server component - No need for a database - No need for an admin console (probably replaced by config files) - Import/export is probably easier, since blog entries are just files Cons: - Can't make middleware plugins (but I can't think of a need for one) - Probably would need ugly/tedious user-editable config files - Can't remember the last one, but (or thus?) it probably wasn't important -Steven On Sun, Jul 21, 2013 at 5:23 PM, Steven Degutis sbdegu...@gmail.comwrote: Lately, a lot of people are moving away from dynamic blog engines like Wordpress, and starting to use static blog generators like Jekyll. You may want to consider this route instead. I'm sure a plugin system would still be relevant and useful for a static blog generator. -Steven On Thu, Jul 18, 2013 at 9:24 AM, Timothy Washington twash...@gmail.comwrote: Hello, I'm thinking of how to build a composable blogging engine in Clojure. There have been a few attempts at this, with cow-bloghttps://github.com/briancarper/cow-blogand my-blog https://github.com/georgerogers42/my-blog. But these seem to be abandoned, and not heavily used. Vijay Kiran, last year, even wrote a series of blog posts (see herehttp://www.vijaykiran.com/2012/01/17/web-application-development-with-clojure-part-2/) about building a blog engine. As far as a list of posts goes, the data structure for each record was simple: - title - content - status - created-date - published-date - author I think this is the most basic thing you could do, to get running. But I'm thinking of approaching the feature set of Wordpresshttp://codex.wordpress.org/WordPress_Features. So I'm thinking of the Data Structure(s) of features like: - Web UI component; wyswyg editor, themes - Server component; embeddable in Compojure or Pedestal - Database component; - raw data structures, txt, rtf, images, audio, videos, documents - adapters for Datomic, SQL(Postgres, etc), NoSQL (Mongo, etc) - tags / categories for content - Authentication Authorization; OpenID - Workflow component; preview, collaboration editor review - Commenting component; default or an external comments service, like disqus http://disqus.com or discoursehttp://www.discourse.org - Administration Console - Plug-in support - Import / Export - Multi-lang / Internationalization I know that I currently wish I had a Clojure weblog engine that I could stick into a site I'm building. If there's already something available, I'll obviously just use that. But otherwise, is this something that would be interesting to people? Thanks Tim Washington Interruptsoftware.ca / Bkeeping.com 416.843.9060 -- -- 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
Re: Interest in a Full Featured Clojure Blog Engine
On Jul 21, 2013, at 10:01 PM, Colin Fleming colin.mailingl...@gmail.com wrote: I'm a fan of static generators too, but one large con for a lot of people is lack of commenting. Personally I like the article-with-no-comments format, but it's not for everyone. You can use Disqus or similar, but it has its own issues starting with the fact that you give all your data to someone else. More pros for static generators are that you can use whichever editor you want and you get version control easily too. A static-site generator, Clojure-style (which I think ends up being Leiningen style), would be a great value add over the well-trodden dynamic-website world. An extra cool thing would be a great local web-app that you run yourself that lets you interact with the config files and markdown content (or whatever). Gives you ease-of-use, but allows you to NOT use it if you're into Emacs, hand-editing hiccup templates (say) and a Leinigen-like site.clj file. I could imagine such an app being generalized to handle numerous sites for those folks who might want to create a blogging github kind of thing. K On 22 July 2013 10:33, Steven Degutis sbdegu...@gmail.com wrote: The more I think about the static blog generator idea, the more I think it's different enough to be a separate project. But anyway, I already wrote this list of pros/cons to why I think static blog generators are better, so might as well post it: Pros: Runs anywhere you can host HTML, such as Github Pages (which is free btw) No need for authentication/authorization code No need for WYSWYG editor No need for server component No need for a database No need for an admin console (probably replaced by config files) Import/export is probably easier, since blog entries are just files Cons: Can't make middleware plugins (but I can't think of a need for one) Probably would need ugly/tedious user-editable config files Can't remember the last one, but (or thus?) it probably wasn't important -Steven On Sun, Jul 21, 2013 at 5:23 PM, Steven Degutis sbdegu...@gmail.com wrote: Lately, a lot of people are moving away from dynamic blog engines like Wordpress, and starting to use static blog generators like Jekyll. You may want to consider this route instead. I'm sure a plugin system would still be relevant and useful for a static blog generator. -Steven On Thu, Jul 18, 2013 at 9:24 AM, Timothy Washington twash...@gmail.com wrote: Hello, I'm thinking of how to build a composable blogging engine in Clojure. There have been a few attempts at this, with cow-blog and my-blog. But these seem to be abandoned, and not heavily used. Vijay Kiran, last year, even wrote a series of blog posts (see here) about building a blog engine. As far as a list of posts goes, the data structure for each record was simple: title content status created-date published-date author I think this is the most basic thing you could do, to get running. But I'm thinking of approaching the feature set of Wordpress. So I'm thinking of the Data Structure(s) of features like: Web UI component; wyswyg editor, themes Server component; embeddable in Compojure or Pedestal Database component; raw data structures, txt, rtf, images, audio, videos, documents adapters for Datomic, SQL(Postgres, etc), NoSQL (Mongo, etc) tags / categories for content Authentication Authorization; OpenID Workflow component; preview, collaboration editor review Commenting component; default or an external comments service, like disqus or discourse Administration Console Plug-in support Import / Export Multi-lang / Internationalization I know that I currently wish I had a Clojure weblog engine that I could stick into a site I'm building. If there's already something available, I'll obviously just use that. But otherwise, is this something that would be interesting to people? Thanks Tim Washington Interruptsoftware.ca / Bkeeping.com 416.843.9060 -- -- 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
