Re: concat primitive arrays

[Alex Fowler]

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

[Alex Fowler]

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 
>   1. 
> goog.net.XhrIo.sendcljs.js:25223
>   2. xhr__delegatecljs.js:31416 
>   3. xhrcljs.js:31423 
>   4. 
> remote_callback__delegatecljs.js:32504
>   5. remote_callbackcljs.js:32515
>   6. load_storecljs.js:32745 
>   7. 
> mk__AMPERSAND__load_store__delegatecljs.js:32755
>   8. 
> mk__AMPERSAND__load_storecljs.js:32763
>   9. example_storecljs.js:33341 
>   10. simplecljs.js:33361 
>   11. setup_guicljs.js:33962 
>   12. setup_allcljs.js:33982 
>   13. startupcljs.js:41166 
>   14. onloadapp:2 
>   
> XHR ERROR: Not Found 
> `
>
> What is wrong and how do I fix it? I have been following this 
> tutorial: Shoreleave Tutorial 10 - Introducing 
> Ajax
>  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"]
>
>  

using httpkit + core.async to build a simple WebSocket-based chat demo

[Dave Della Costa]

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

[Christopher Martin]

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
. 
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

[Brian Craft]

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[]

[Alex Fowler]

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

[Brian Craft]

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 pat

Re: concat primitive arrays

[Brian Craft]

(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

[Timothy Washington]

Ooh. Ok, lemme check it out.



On Sat, Jul 20, 2013 at 10:34 PM, Chris Allen  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

[Brian Craft]

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

Re: Interest in a Full Featured Clojure Blog Engine

[Manuel Paccagnella]

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 
>
> here
>) 
>
> 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  HTML element.

There is a more comprehensive text markup language called 
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-integration.
 
Maybe it can be an additional option.


>- what I should use to model workflow; possibly 
> 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 
> 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 
this, 
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 > 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 
>> quick&dirty: 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

[Steven Degutis]

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 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-blogand
> 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 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

[Steven Degutis]

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  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 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-blogand
>> 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 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

[Alex Fowler]

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 

Re: using httpkit + core.async to build a simple WebSocket-based chat demo

[Dave Della Costa]

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
> . 
> 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.
>  
>  

-- 
-- 
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

[Colin Fleming]

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  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 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 
>> 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-blogand
>>> 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
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googl

Re: Interest in a Full Featured Clojure Blog Engine

[Keith Irwin]

On Jul 21, 2013, at 10:01 PM, Colin Fleming  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  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  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  
> 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 membe