Re: Idiomatic way to return a single value from an async function

2014-11-11 Thread Daniel Kersten
You could do both:

Make the channel optional. If it's provided, use that and return it. If
it's not provided, create a new one and use and return that.

This way the caller gets to decide which they wish to use based on who the
owner of the channel should be or if the channel should be reused elsewhere.

For example, for a once-off call, creating s new channel may make more
sense but if the function is called frequently it might make more sense to
reuse one channel, especially if this channel is used with other plumbing
like pub/sub or mult which you would otherwise need to set up every time.

On Mon, 10 Nov 2014 17:42 Mike Haney txmikes...@gmail.com wrote:

 Eric Normand has an interesting article on this here:
 http://www.lispcast.com/core-async-code-style

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Idiomatic way to return a single value from an async function

2014-11-11 Thread László Török
+1, this is mostly what we resort to.

(defn some-async-func [param-a param-b  [out-chan]]
  (let [ch (or out-chan (chan)]
 ...
  )

2014-11-11 8:53 GMT+00:00 Daniel Kersten dkers...@gmail.com:

 You could do both:

 Make the channel optional. If it's provided, use that and return it. If
 it's not provided, create a new one and use and return that.

 This way the caller gets to decide which they wish to use based on who the
 owner of the channel should be or if the channel should be reused elsewhere.

 For example, for a once-off call, creating s new channel may make more
 sense but if the function is called frequently it might make more sense to
 reuse one channel, especially if this channel is used with other plumbing
 like pub/sub or mult which you would otherwise need to set up every time.


 On Mon, 10 Nov 2014 17:42 Mike Haney txmikes...@gmail.com wrote:

 Eric Normand has an interesting article on this here:
 http://www.lispcast.com/core-async-code-style

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.




-- 
László Török
Checkout justonemorepoint.com - Know your true value

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Idiomatic way to return a single value from an async function

2014-11-11 Thread Thomas Heller
Hey,

what is your definition of an async function in Clojure? I imagine 
something something that starts a (go ...), if appropriate you can use the 
result of (go ...) as the result of the function since that is a channel 
that will receive the return value of the go block when it dies.

(defn start-async []
  (go (! (async/timeout 1000))
  :done))

(let [c (start-async)]
  (prn (!! c)))

Other than it is highly dependent on the function you are writing. 
Sometimes it will be required to take an external channel, sometimes it 
will be useless. Usually depends on the types of coordination required 
between the different parts. There is no universally correct way.

Just my 2 cents,
/thomas

On Monday, November 10, 2014 5:30:41 PM UTC+1, Alexander Kiel wrote:

 Hi,

 what is the most idiomatic way to return a single value from an async 
 function in Clojure?

 A: return a channel which conveys the result later; also closes the channel

 (defn f [x]
   (let [c (chan)]
 ; put result onto c and close c later
 c))

 B: take a channel onto which the result is put later; do not close that 
 channel; return nil immediately

 (defn f [x c]
   ; put result onto and close c later
   nil)

 Variant A has the advantage that it needs one function argument less than 
 variant B. It's also better usable in higher order functions like map. 
 Variant A is also more easy to use if you need to create a channel anyway.

 Variant A has the disadvantage of creating a new channel each time the 
 async function is called. According my measurements using criterium 
 0.4.3, clojure 1.6.0 and core.async 0.1.346.0-17112a-alpha, the runtime 
 cost of creating a channel is about 8 times more expensive as creating a 
 single object.

 Variant B has the advantage to not create a channel on every call. You can 
 supply the same channel many times to the function. On the other hand, the 
 results of multiple calls to f are not likely to arrive on that single 
 channel in call order. If you have such an ordering requirement, you have 
 to create a single channel for each function call anyway.

 Variant B has the disadvantage that it requires one function argument more 
 than variant A. As a consequence, you can't simply map such a function over 
 a list of inputs.

 Variant A seems to be the winner. But I ask specially because 
 pipeline-async 
 https://clojure.github.io/core.async/#clojure.core.async/pipeline-async 
 uses 
 variant B.

 What do you think?

 Alex




-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[ANN] cljs-start 1.0.4

2014-11-11 Thread Mimmo Cosenza
Hi all,
I just deployed the 0.1.4 release of cljs-start lein-template to create 
ClojureScript libs with batteries included.

https://github.com/magomimmo/cljs-start 
https://github.com/magomimmo/cljs-start

It update all dependencies and plugins to the latest available releases:

- clojure 1.6.0
- clojurescript 0.0-2371
- lein-cljsbuild 1.0.3
- clojurescript-test 0.3.1
- ring 1.3.1
- compojure 1.2.1
- austin 0.1.5

HIH

My best

mimmo



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: multimethod, record, type, and protocol pitfalls?

2014-11-11 Thread Justin Smith
Helping newcomers to the language on #clojure, I often find the need to use 
a protocol in reference to it's namespace rather than the namespace of the 
datatype extending it is a counter-intuitive one for people learning the 
language. Similar with dispatch methods.

Speculatively, I think it has to do with a bad mental model of the primary 
ownership of the method - often the method is thought of as belonging to 
the datatype, where it actually belongs to the multimethod / protocol 
interface.

A good example of this in practice: people who think they need circular 
namespace dependencies or forward declaration in order for two records / 
types to interact often have a hard time realizing that if they code to a 
set of multimethods or a defprotocol and not a concrete datatype, the 
circularity / forward reference is usually trivial to eliminate. And more 
fundamentally that the agency doesn't belong to the record or type, it 
belongs to the method functions being called, and to abstract that away 
from a concrete datatype is precisely the point of these polymorphic 
constructs.

On Monday, October 27, 2014 3:59:43 AM UTC-7, Gary Verhaegen wrote:

 As recently mentioned on another thread, this also means that you cannot 
 have two different protocols with the same method names in the same 
 namespace. This may be surprising, especially from an OO background, where 
 it is very natural to have two types with the same operations.

 On Monday, 27 October 2014, Sven Richter sve...@googlemail.com 
 javascript: wrote:

 Hi Daniel,

 When running through tutorials and blog posts it did not occur to me that 
 the functions of a defprotocol are namespaced to where they are defined. 
 Meaning, calling these functions I have to use their original namespace.
 It is obvious when one reads the official documentation, but one does not 
 always do this first, so that wsa one pitfall I ran into.

 Best Regards,
 Sven

 Am Sonntag, 26. Oktober 2014 16:48:29 UTC+1 schrieb Daniel Higginbotham:

 What's difficult when it comes to understanding multimethods, records, 
 types, and protocols? I'm writing a chapter on multimethods, records, 
 types, and protocols for the book Clojure for the Brave and True, and I'd 
 love to hear about what kinds of pitfalls I should be sure to cover :)

 Thanks!
 Daniel

  -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.



-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Clojure CLR Experiences

2014-11-11 Thread Adrian Mowat
Hi All,

We are using Clojure on the JVM but one of our .Net developers has asked me 
whether I have considered using it on the CLR.  I haven't tried doing it so 
I wondered if anyone can share any experiences using Clojure on the CLR?  A 
quick google search suggests the project is still active but not especially 
vibrant (current version 1.4, last commit 24 days ago) but maybe that's 
unfair.

I'm broadly interested in the following...

* Is Clojure CLR production ready?
* Do its version numbers correspond to the core Clojure version numbers? 
 (would it be fair to say the Java version is the core version)
* Is it sensible to think in terms of writing platform independent code in 
the same way as we do with cljx files in ClojureScript?
* How good is the Visual Studio support for Clojure?
* Does Leiningen work?
* Are there any significant pitfalls to be aware of?

Any other comments would be greatly appreciated.

Many Thanks

Adrian





-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Idiomatic way to return a single value from an async function

2014-11-11 Thread Stuart Sierra
Similarly, but I would be explicit about the different arities, to avoid 
the intermediate sequence created by [arg  [option]] and to get errors if 
there are too many arguments.

(defn foo
  ([input] (foo input (chan 1))
  ([input ch]
 ... do something and put to ch ...))

If your function can produce multiple outputs, you can `close!` the channel 
to signal it is finished, which is what `pipeline-async` expects.

–S

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Clojure CLR Experiences

2014-11-11 Thread Shantanu Kumar
Not sure why you say that 1.4 is the current version. ClojureCLR releases 
are here: https://www.nuget.org/packages/Clojure - as of today 1.6.0.1 is 
the current stable version.

Leiningen plugin is here: https://github.com/kumarshantanu/lein-clr

Shantanu

On Tuesday, 11 November 2014 21:08:58 UTC+5:30, Adrian Mowat wrote:

 Hi All,

 We are using Clojure on the JVM but one of our .Net developers has asked 
 me whether I have considered using it on the CLR.  I haven't tried doing it 
 so I wondered if anyone can share any experiences using Clojure on the CLR? 
  A quick google search suggests the project is still active but not 
 especially vibrant (current version 1.4, last commit 24 days ago) but maybe 
 that's unfair.

 I'm broadly interested in the following...

 * Is Clojure CLR production ready?
 * Do its version numbers correspond to the core Clojure version numbers? 
  (would it be fair to say the Java version is the core version)
 * Is it sensible to think in terms of writing platform independent code in 
 the same way as we do with cljx files in ClojureScript?
 * How good is the Visual Studio support for Clojure?
 * Does Leiningen work?
 * Are there any significant pitfalls to be aware of?

 Any other comments would be greatly appreciated.

 Many Thanks

 Adrian







-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Map holds on to element being processed

2014-11-11 Thread 'Matt Bossenbroek' via Clojure
Thanks! I was playing around with similar variants last night  came up with 
some that seem to work for one element, but not many.

I was seeing a similar result from your version:

= (map2 count [(repeat 1e8 stuff) (repeat 1e8 stuff) (repeat 1e8 
stuff)]) 
OutOfMemoryError GC overhead limit exceeded
java.lang.Double.valueOf (Double.java:521)
clojure.lang.Numbers$DoubleOps.dec (Numbers.java:628)
clojure.lang.Numbers.dec (Numbers.java:118)
clojure.core/take/fn--4270 (core.clj:2627)
clojure.lang.LazySeq.sval (LazySeq.java:40)
clojure.lang.LazySeq.seq (LazySeq.java:49)
clojure.lang.Cons.next (Cons.java:39)
clojure.lang.RT.countFrom (RT.java:540)
clojure.lang.RT.count (RT.java:530)
clojure.core/count (core.clj:839)
pigpen.runtime/map2/fn--1344 (NO_SOURCE_FILE:5)
clojure.lang.LazySeq.sval (LazySeq.java:40)

But then it dawned on us to try a list instead of a vector for the main seq:

= (map2 count (list (repeat 1e8 stuff) (repeat 1e8 stuff) (repeat 1e8 
stuff))) 
(1 1 1)


It does end up thrashing with GCs a bit, but in the end it does the job. It 
seems like the vector was holding on to something that the list doesn't.

It's unfortunate that I would need a custom map implementation to make this 
work. Elsewhere in the code I (somewhat accidentally) ended up using async 
channels to solve the same problem. Instead of modeling the large collection as 
a lazy seq, I have a producer put items into a collection and a consumer read 
from the collection and transform them (count in this example).

In general, would it be better to use channels instead of lazy seqs for very 
large sequences? Lazy seqs seem to have a couple of disadvantages at scale: you 
have to be really careful not to hold on to the head (frequently this is hidden 
anyway), and the evaluation of the lazy seq seems to stress out the GC.

Are there other alternatives for large seqs that are better than either of 
these options?

Thanks,
Matt




On Monday, November 10, 2014 at 10:47 PM, Andy Fingerhut wrote:

 At least in your particular case, replacing map with map2, defined below as a 
 small modification to a subset of map, seems to do the trick:
 
 (defn map2 [f coll]
   (lazy-seq
(when-let [s (seq coll)]
  (let [r (rest s)]
(cons (f (first s)) (map2 f r))
 
 
 (map2 count [(repeat 1e8 stuff)])
 
 I believe this is because the original definition of map, or the subset of it 
 below:
 
 (defn map [f coll]
   (lazy-seq
(when-let [s (seq coll)]
  (cons (f (first s)) (map f (rest s))
 
 
 holds onto the head via needing to keep the value of s around throughout 
 the entire call to (f (first s)) in order to later make the call (map f (rest 
 s)).  In map2, the value of s is no longer needed by the time f is called.
 
 Andy
 
 On Mon, Nov 10, 2014 at 7:48 PM, 'Matt Bossenbroek' via Clojure 
 clojure@googlegroups.com (mailto:clojure@googlegroups.com) wrote:
  Ran into an interesting problem today. In short, this works: 
  
  (count (repeat 1e8 stuff)) 
  
  But this doesn't:
  
  (map count [(repeat 1e8 stuff)])
  
  To be fair, given sufficient memory, it would eventually complete. (If the 
  second example does work for you, change it to 1e10 or something higher).
  
  The first one works because nothing is holding on to the head of the seq. 
  My assumption is that the second is eating memory because map still has a 
  reference to the item being processed, while the call to count is causing 
  it to be evaluated. Thus the whole seq is retained and we run out of memory.
  
  Is my guess correct? If so, is there a workaround for this?
  
  Thanks,
  Matt
  
  -- 
  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 
  (mailto: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 
  (mailto:clojure%2bunsubscr...@googlegroups.com)
  For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en
  --- 
  You received this message because you are subscribed to the Google Groups 
  Clojure group.
  To unsubscribe from this group and stop receiving emails from it, send an 
  email to clojure+unsubscr...@googlegroups.com 
  (mailto:clojure+unsubscr...@googlegroups.com).
  For more options, visit https://groups.google.com/d/optout.
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com 
 (mailto: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 
 (mailto:clojure+unsubscr...@googlegroups.com)
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 

Announcing Smeagol, a very simple wiki engine inspired by Gollum

2014-11-11 Thread Simon Brooke
For a project recently I needed a wiki engine which was simple and easily 
backed up, but which had authentication. I very much liked Gollum 
https://github.com/gollum/gollum/wiki, but it does not have 
authentication, and I thought it would be simpler for me to write a wiki 
engine from scratch in Clojure than to modify Gollum. So here is Smeagol 
https://github.com/simon-brooke/smeagol.

It works now, but the security is pretty crude at this stage and the Git 
integration which I plan does not yet exist. Feel free to fork or adapt, or 
just use; any fixes or feedback welcome.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


test.check slow shrinking

2014-11-11 Thread Brian Craft
Using test.check, I'm finding the shrinking to be very, very slow. Running 
a hundred cases takes a few seconds, unless it hits an error, in which case 
it takes 40-60 minutes to shrink, and the shrinking is not very effective 
(resulting test case is much larger than necessary). Sometimes the 
shrinking is much faster. It behaves a bit like it's occasionally getting 
into a pathological state, or a difficult shrinking scenario.

Are there any docs on generators or the shrinking algorithm that would help 
build tests that shrink more effectively?

The problematic generator builds a randomly-sized matrix of integers, with 
randomly assigned names for the rows and columns. The failure case is when 
either a column or row name is repeated. I expect the slow shrinking has 
something to do with it being rare for the generator to emit the same name 
twice.

; Generator of randomly sized matrices of random numbers.
(def gen-matrix
  (gen/bind
gen/s-pos-int
(fn [x] (gen/bind
  gen/s-pos-int
  (fn [y] (gen/vector (gen/vector gen/int x) y))

; Generator of matrix with probe and sample ids.
(def gen-tsv
  (gen/bind
gen-matrix
(fn [m]
  (gen/hash-map
:probes (gen/vector 
  (gen/such-that not-empty gen/string-alpha-numeric)
  (count m))
:samples (gen/vector 
   (gen/such-that not-empty gen/string-alpha-numeric)
   (count (first m)))
:matrix (gen/return m)

Shrinking will result in a case like

{:matrix [[1 4 -3] [-4 -3 -5] [-5 2 3] [4 -5 -5] [1 -2 3] [1 4 1]], 
:samples [0 0 0], :probes [0 0 0 0 0 0]}

where :samples [0 0] :probes[0] would do.

The following test will exhibit the behavior, sometimes succeeding, 
sometimes failing quickly, sometimes shrinking for a very long time:

(tc/quick-check 100 (prop/for-all [tsv gen-tsv] (= (count (set (:probes 
tsv))) (count (:probes tsv)

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Clojure CLR Experiences

2014-11-11 Thread Adrian Mowat
Hi,


Thanks for the info and the link to the lein plugin.




I checked git hub and the latest branch was 1.4.1. That coupled with this blog 
http://clojureclr.blogspot.co.uk suggested the latest version was 1.4. Looks 
like I missed the crucial link :-)




Cheers




Adrian


—
Sent from Mailbox

On Tue, Nov 11, 2014 at 5:00 PM, Shantanu Kumar kumar.shant...@gmail.com
wrote:

 Not sure why you say that 1.4 is the current version. ClojureCLR releases 
 are here: https://www.nuget.org/packages/Clojure - as of today 1.6.0.1 is 
 the current stable version.
 Leiningen plugin is here: https://github.com/kumarshantanu/lein-clr
 Shantanu
 On Tuesday, 11 November 2014 21:08:58 UTC+5:30, Adrian Mowat wrote:

 Hi All,

 We are using Clojure on the JVM but one of our .Net developers has asked 
 me whether I have considered using it on the CLR.  I haven't tried doing it 
 so I wondered if anyone can share any experiences using Clojure on the CLR? 
  A quick google search suggests the project is still active but not 
 especially vibrant (current version 1.4, last commit 24 days ago) but maybe 
 that's unfair.

 I'm broadly interested in the following...

 * Is Clojure CLR production ready?
 * Do its version numbers correspond to the core Clojure version numbers? 
  (would it be fair to say the Java version is the core version)
 * Is it sensible to think in terms of writing platform independent code in 
 the same way as we do with cljx files in ClojureScript?
 * How good is the Visual Studio support for Clojure?
 * Does Leiningen work?
 * Are there any significant pitfalls to be aware of?

 Any other comments would be greatly appreciated.

 Many Thanks

 Adrian






 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to a topic in the Google 
 Groups Clojure group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/clojure/Vz6C9rMeu8Q/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: ClojureScript and development workflow

2014-11-11 Thread Erlis Vidal
Any update on how to do this from LightTable?

On Tue, Sep 11, 2012 at 7:48 PM, Chris Granger ibdk...@gmail.com wrote:

 FWIW, I'm working on this with Light Table, which removes a lot of the
 difficulties here - it will be include this script tag and you're ready to
 go. There's no reason that we need to jump through a bunch of hoops here.
 My plan is that the next release (sometime after strange loop) will include
 a nice way to work with CLJS such that a very nice getting started video
 could be created. :)

 Cheers,
 Chris.

 On Tuesday, September 11, 2012 6:10:29 AM UTC-7, Chas Emerick wrote:

 On Sep 11, 2012, at 4:00 AM, Laurent PETIT wrote:

 2012/9/10 Chas Emerick ch...@cemerick.com

 I've been using a combination of lein-cljsbuild to keep the on-disk
 generated code fresh and piggieback[1] for all of my cljs REPL needs.


 Hello Chas,

 I've tried to use piggieback. My current stack for playing with the
 concepts is leiningen2 on the command line (to start the server), with
 clsjbuild to compile the browser_repl.cljs to bootstrap the REPL
 machinery (lein cljsbuild once), regular lein repl once project.clj has
 been configured with the proper options) and a regular CCW 0.10.0 nrepl
 client.

 It works OK with the out of the box Rhino-backed evaluator, but as you
 might guess, I have no interest in this and then I quickly jump to try 
 get a Browser-based REPL running.

 That's where things broke.
 I did not manage to get things compiled correctly.

 As it stands, it seems that I'll have to read  understand wiki pages
 from ClojureScript project, nrepl documentation, piggieback documentation,
 cljsbuild documentation, to really grasp the whole thing.
 Seems a little bit daunting just to be able to play with it. Is there
 an easier way ? A resource somewhere which already explains step-by-step
 how to get started with a new project, cljsbuild for compiling from time to
 time, and piggieback ?

 Just asking before starting digging :-)


 There is a how-to in piggieback's README for using a browser-repl
 environment rather than Rhino.  Nelson Morris was actually the first one to
 get that working, and I'm using it regularly, so it *does* work, though
 there's no doubt there's a lot of pieces you need to put together (for my
 part, I blew nearly an hour tearing my hair out before re-reading the
 browser-repl tutorial,[1] and seeing near the bottom that loading the HTML
 page from disk wouldn't work; once I served the page from localhost,
 everything fell together).

 FWIW, I've found ClojureScript itself to be very solid so far; there are
 some unfortunate (IMO unnecessary) incompatibilities between it and
 Clojure, but [2] is the only thing I've really tripped up on from a
 technical standpoint.

 I think your assessment that the learning curve is daunting is just
 about right, but that largely lays with the state of tooling, and the
 disjointed nature of the development process.  With Clojure, you always
 have a single environment (the JVM or CLR), into which you can load code
 all day from nearly anywhere without having to think much about the
 logistics of it.  ClojureScript necessarily implies a more complicated
 setup: there's your REPL environment, probably a browser, and maybe a
 connection between the two; you *must* have your code on disk and in the
 right place in order for Google Closure / lein-cljsbuild to get at it (not
 strictly true, but driving the compiler from a Clojure REPL isn't any
 easier outside of simple cases); your Ring webapp needs to be configured to
 be serving the gclosure output; and, you'd obviously like to be able to
 control and monitor all of this from your editor/environment of choice.

 (I'd like to eventually do a 'Starting ClojureScript' screencast similar
 to [3], but the logistics of going from zero to hero with ClojureScript
 are IMO far too hard and nuanced still in order to present them well in
 that sort of medium.)

 I think the contrast is so stark in part because of how good we've had it
 on the Clojure side.  I suspect that CoffeeScript programming must be
 similarly disjointed, since all the same moving pieces are necessary (and
 perhaps without the benefit of upsides like a browser-connected REPL and so
 on).  Welcome to the wonderful world of modern web development! :-P

 I think that's all a long way of saying: start digging!

 Cheers,

 - Chas

 [1] https://github.com/clojure/clojurescript/wiki/The-REPL-
 and-Evaluation-Environments
 [2] http://dev.clojure.org/jira/browse/CLJS-358
 [3] http://cemerick.com/2012/05/02/starting-clojure/

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

Re: Clojure CLR Experiences

2014-11-11 Thread Aaron
Hi Adrian,

I'll share some of my experiences.

* Is Clojure CLR production ready?
Yes, I have been using it in production for about 2 years now.

* Do its version numbers correspond to the core Clojure version numbers? 
 (would it be fair to say the Java version is the core version)
It's fair to say that the Java is the core version, but Dave Miller (the 
ClojureCLR maintainer) does a pretty good job of keeping it up to date with 
the Java version.

* Is it sensible to think in terms of writing platform independent code in 
the same way as we do with cljx files in ClojureScript?
It is feasible if you put the effort into testing and writing the code 
correctly, but currently I don't think cljx supports ClojureCLR - you'd 
probably need to add that functionality yourself.

* How good is the Visual Studio support for Clojure?
I use emacs and *inferior-lisp* and am pretty happy with them so I can't 
comment on the Visual Studio workflow.

* Does Leiningen work?
There is Shantanu's lein plugin and I've tried to do a proof of concept 
nlein, but there really isn't the equivalent thing in ClojureCLR. I 
mostly deploy my .clj files as embedded resources in C# DLL's and have C# 
call into Clojure to bootstrap things. I'm sure other people use other 
strategies.

* Are there any significant pitfalls to be aware of?
Not as many libraries are available and you'll have to do a fair amount of 
groundwork yourself. Startup time is similar to the JVM verison.

Overall, once I got past the initial hurdles, I found the environment to be 
quite stable and a huge productivity boost. I would definitely recommend 
ClojureCLR for projects with a big existing .NET code base. For new 
projects, I do usually go with JVM Clojure mainly for access to more 
libraries and IDE's. At the time when I started using ClojureCLR our team 
was heavily invested in .NET so it made a lot of sense and was definitely 
well worth it...

Be sure to check out the ClojureCLR google group: 
https://groups.google.com/forum/#!forum/clojure-clr


On Tuesday, November 11, 2014 10:38:58 AM UTC-5, Adrian Mowat wrote:

 Hi All,

 We are using Clojure on the JVM but one of our .Net developers has asked 
 me whether I have considered using it on the CLR.  I haven't tried doing it 
 so I wondered if anyone can share any experiences using Clojure on the CLR? 
  A quick google search suggests the project is still active but not 
 especially vibrant (current version 1.4, last commit 24 days ago) but maybe 
 that's unfair.

 I'm broadly interested in the following...

 * Is Clojure CLR production ready?
 * Do its version numbers correspond to the core Clojure version numbers? 
  (would it be fair to say the Java version is the core version)
 * Is it sensible to think in terms of writing platform independent code in 
 the same way as we do with cljx files in ClojureScript?
 * How good is the Visual Studio support for Clojure?
 * Does Leiningen work?
 * Are there any significant pitfalls to be aware of?

 Any other comments would be greatly appreciated.

 Many Thanks

 Adrian







-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(ANN) simple-brepl 0.1.2 released

2014-11-11 Thread James Henderson
Hi all - just a quick note to announce the release of *simple-brepl* 0.1.2.

'simple-brepl', as the name suggests, is a really simple way to connect to 
ClojureScript browser REPLs. It's built atop Tom Jakubowski's excellent 
Weasel library, which uses Websockets to communicate with the browser.

Full docs and a sample project are on GitHub 
at https://github.com/james-henderson/simple-brepl

Any problems, let me know!

James

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Announcing Smeagol, a very simple wiki engine inspired by Gollum

2014-11-11 Thread Simon Brooke
And now the Git integration does exist and does work. Clojure is such a joy 
- a complete functional Wiki engine in less than eight hours actual coding! 
Obviously it's alpha quality, and could definitely be improved, but it 
works now.

On Tuesday, 11 November 2014 18:00:18 UTC, Simon Brooke wrote:

 For a project recently I needed a wiki engine which was simple and easily 
 backed up, but which had authentication. I very much liked Gollum 
 https://github.com/gollum/gollum/wiki, but it does not have 
 authentication, and I thought it would be simpler for me to write a wiki 
 engine from scratch in Clojure than to modify Gollum. So here is Smeagol 
 https://github.com/simon-brooke/smeagol.

 It works now, but the security is pretty crude at this stage and the Git 
 integration which I plan does not yet exist. Feel free to fork or adapt, or 
 just use; any fixes or feedback welcome.


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Clojure CLR Experiences

2014-11-11 Thread Alex Miller


On Tuesday, November 11, 2014 9:38:58 AM UTC-6, Adrian Mowat wrote:


 * Is it sensible to think in terms of writing platform independent code in 
 the same way as we do with cljx files in ClojureScript?


With the feature expressions work we hope to include in 1.7, this will 
become possible. Our primary goal is Clojure/ClojureScript portability as 
that is significantly more common, but I think with the corresponding 
changes in ClojureCLR, this should become possible. One issue in particular 
that I know is the pipe-delimited symbol extension in ClojureCLR which 
would not be parseable in Clojure or ClojureScript even with feature 
expressions so that would be a limit. There may be other issues as well. We 
would like this to work though eventually.

Alex

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Clojure CLR Experiences

2014-11-11 Thread dmiller
Re versions: look at the tags, not the branches.  The 1.4.1 branch was 
anomalous, due to needing to get out a bug fix.


On Tuesday, November 11, 2014 2:17:29 PM UTC-6, Aaron wrote:

 Hi Adrian,

 I'll share some of my experiences.

 * Is Clojure CLR production ready?
 Yes, I have been using it in production for about 2 years now.

 * Do its version numbers correspond to the core Clojure version numbers? 
  (would it be fair to say the Java version is the core version)
 It's fair to say that the Java is the core version, but Dave Miller (the 
 ClojureCLR maintainer) does a pretty good job of keeping it up to date with 
 the Java version.

 * Is it sensible to think in terms of writing platform independent code in 
 the same way as we do with cljx files in ClojureScript?
 It is feasible if you put the effort into testing and writing the code 
 correctly, but currently I don't think cljx supports ClojureCLR - you'd 
 probably need to add that functionality yourself.

 * How good is the Visual Studio support for Clojure?
 I use emacs and *inferior-lisp* and am pretty happy with them so I can't 
 comment on the Visual Studio workflow.

 * Does Leiningen work?
 There is Shantanu's lein plugin and I've tried to do a proof of concept 
 nlein, but there really isn't the equivalent thing in ClojureCLR. I 
 mostly deploy my .clj files as embedded resources in C# DLL's and have C# 
 call into Clojure to bootstrap things. I'm sure other people use other 
 strategies.

 * Are there any significant pitfalls to be aware of?
 Not as many libraries are available and you'll have to do a fair amount of 
 groundwork yourself. Startup time is similar to the JVM verison.

 Overall, once I got past the initial hurdles, I found the environment to 
 be quite stable and a huge productivity boost. I would definitely recommend 
 ClojureCLR for projects with a big existing .NET code base. For new 
 projects, I do usually go with JVM Clojure mainly for access to more 
 libraries and IDE's. At the time when I started using ClojureCLR our team 
 was heavily invested in .NET so it made a lot of sense and was definitely 
 well worth it...

 Be sure to check out the ClojureCLR google group: 
 https://groups.google.com/forum/#!forum/clojure-clr


 On Tuesday, November 11, 2014 10:38:58 AM UTC-5, Adrian Mowat wrote:

 Hi All,

 We are using Clojure on the JVM but one of our .Net developers has asked 
 me whether I have considered using it on the CLR.  I haven't tried doing it 
 so I wondered if anyone can share any experiences using Clojure on the CLR? 
  A quick google search suggests the project is still active but not 
 especially vibrant (current version 1.4, last commit 24 days ago) but maybe 
 that's unfair.

 I'm broadly interested in the following...

 * Is Clojure CLR production ready?
 * Do its version numbers correspond to the core Clojure version numbers? 
  (would it be fair to say the Java version is the core version)
 * Is it sensible to think in terms of writing platform independent code 
 in the same way as we do with cljx files in ClojureScript?
 * How good is the Visual Studio support for Clojure?
 * Does Leiningen work?
 * Are there any significant pitfalls to be aware of?

 Any other comments would be greatly appreciated.

 Many Thanks

 Adrian







-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.