Re: creating code stubs to use inside an extend-protocol form

[Meikel Brandmeyer (kotarak)]

Hi,

why don't you just use extend?

(defn default-run
  [this ^String text]
  (let [ann (edu.stanford.nlp.pipeline.Annotation. text)]
(.annotate this ann)
ann))

(extend
  POSTaggerAnnotatorIComponent {:run default-run}
  PTBTokenizerAnnotator IComponent {:run default-run}
  ...)

You don't need the inline definition of protocols. Use it only when you 
identified it as performance bottleneck.

Kind regards
Meikel

-- 
-- 
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: suggest to have defn/new/throw/etc.. allow evaluating ...maybe?

[Tim Reinke]

It's nice to see some input validation!

It seems your problem, ultimately, is the testability of macros. 

You can wrap the call to the macro in an eval (this way the error is thrown 
by eval, not the compiler):

(is (thrown? AssertionError  (eval '(dedefn (str "a" "b")

This can get a little ugly if you need the eval form to capture variables.

Alternatively, you can factor the heavy lifting out of the defmacro form 
and test your logic there:

(defn defdefn* [z]
 (assert (symbol? z))
 `(defn ~z [x#] x#]

 (defmacro dedefn [zsym]
(defdefn* (eval zsym))

On Saturday, February 23, 2013 11:24:26 PM UTC-8, AtKaaZ wrote:
>
> => *(defn (symbol (str "a" "b")) [x] x)*
> IllegalArgumentException First argument to defn must be a symbol  
> clojure.core/defn (core.clj:277)
>
> maybe allow ~ like this:
> =>* (defn ~(symbol (str "a" "b")) [x] x)*
> IllegalArgumentException First argument to defn must be a symbol  
> clojure.core/defn (core.clj:277)
>
> to act like this:
> => *(eval (backtick/template (defn ~(symbol (str "a" "b")) [x] x)))*
> #'util.funxions/ab
>
> I know you'll want to suggest something like this instead:
> => *(defmacro dedefn [zsym]
>  `(defn ~(eval zsym) [x#] x#))*
> #'util.funxions/dedefn
> => *(dedefn (symbol (str "a" "b")))*
> #'util.funxions/ab
>
> which is almost good, except if you want to place extra checks on the 
> input like so:
> => *(defmacro dedefn [zsym]
>  (let [z (eval zsym)
>_ (assert (symbol? z))
>]
>`(defn ~z [x#] x#)
>)
>  )*
> #'util.funxions/dedefn
> => *(dedefn (symbol (str "a" "b")))*
> #'util.funxions/ab
> => *(dedefn (str "a" "b"))*
> AssertionError Assert failed: (symbol? z)  util.funxions/dedefn 
> (NO_SOURCE_FILE:3)
>
> it works but you cannot test them since they happen at compile time, ie.
> => *(clojure.test/is (thrown? AssertionError (dedefn (str "a" "b"*
> CompilerException java.lang.AssertionError: Assert failed: (symbol? z), 
> compiling:(NO_SOURCE_PATH:1:42) 
> => *(clojure.test/is (thrown? AssertionError (throw (new 
> AssertionError*
> #
> => *(clojure.test/is (thrown? AssertionError 1))*
>
> FAIL in clojure.lang.PersistentList$EmptyList@1 (NO_SOURCE_FILE:1)
> expected: (thrown? AssertionError 1)
>   actual: nil
> nil
>
> I guess there's no way to get rid of that eval that's happening there 
> outside of the ` in the macro, and it kinda makes sense to be that way.
>
> I have a feeling there's a workaround to be able to catch the exception 
> but I haven't explored it yet...
>
> Any thoughts?
>
> -- 
> Please correct me if I'm wrong or incomplete,
> even if you think I'll subconsciously hate it.
>
>  

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

Re: Are symbols ending with ':' allowed or not?

[juan.facorro]

The first statement concers the Clojure *reader*, which parses source code 
according to the rules specified in the link provided. What I think the 
first quote refers to, is that all tokens that begin with a ':' will be 
parsed by the reader as Clojure keywords and not symbols. Additionally a 
colon at the end of a token is indicated as invalid so it should result in 
an error.

Here are the three cases that I can make out form the documentation, tried 
at the Clojure REPL:

*user=>* ':with-colon
:with-colon
*user=>* (class ':with-colon)
clojure.lang.Keyword
*user=>* 'sym:bol
sym:bol
*user=>* (class 'sym:bol)
clojure.lang.Symbol
*user=>* 'symbol:
RuntimeException Invalid token: symbol:  clojure.lang.Util.runtimeException 
(Util.java:170)

The document on the second link states at the beggining that* "A superset 
of edn is used by Clojure to represent programs"*,so it would make sense 
that edn takes into account the usage of ':' in symbol names.

I don't think it's an inconsistency since it doesn't concern the reader, 
but the *symbol* function that takes a string and returns a *
clojure.lang.Symbol* doesn't seem to have any issues with the trailing 
colon or other read-invalid symbols, you can basically throw any string to 
it and it'll return a *clojure.lang.Symbol*.

*user=>* (symbol "symbol:")
symbol:
*user=>* (class (symbol ":symbol"))
clojure.lang.Symbol

Hope it helps,

Juan

On Sunday, February 24, 2013 9:13:13 PM UTC-3, Alexander Krasnukhin wrote:
>
> Hi,
>
> I'm confused. Why there two different statements about ':' in symbols? 
> What do I miss?
>
> 1. http://clojure.org/reader
> "Symbols beginning or ending with ':' are reserved by Clojure."
>
> 2. https://github.com/edn-format/edn/blob/master/README.md
> "Additionally, : # are allowed as constituent characters in symbols other 
> than as the first character."
>

-- 
-- 
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: Clojure Performance For Expensive Algorithms

[Isaac Gouy]

On Sunday, February 24, 2013 1:45:33 PM UTC-8, Ben Mabey wrote:
>
> Yeah, I wish the Benchmarks allowed for idiomatic submissions and finely 
> tuned submissions.
>


So you wish the benchmarks game website would show, for example, both 
pi-digits programs that use BigInteger and pi-digits programs that use the 
highly optimised GMP library?

http://benchmarksgame.alioth.debian.org/u32/program.php?test=pidigits&lang=java&id=1

http://benchmarksgame.alioth.debian.org/u32/program.php?test=pidigits&lang=java&id=2


 

> Along those lines this older post did an interesting analysis on the 
> benchmark solutions where it explored the tension that exists between 
> expressiveness and performance across the various languages:
>
> http://blog.gmarceau.qc.ca/2009/05/speed-size-and-dependability-of.html
>


Where do you think Guillaume Marceau took the data from?

http://benchmarksgame.alioth.debian.org/u32/code-used-time-used-shapes.php

-- 
-- 
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: Clojure Performance For Expensive Algorithms

[Isaac Gouy]

On Sunday, February 24, 2013 9:33:52 AM UTC-8, Marko Topolnik wrote:

>
> For example, Scala beats Java by a wide margin on some benchmarks. Turns 
> out it's because it uses JNI to solve the problem with the C bignum 
> library. 
>


Turns out the benchmarks game website shows both Scala programs and Java 
programs that use GMP via JNI --


http://benchmarksgame.alioth.debian.org/u32/program.php?test=pidigits&lang=java&id=2

http://benchmarksgame.alioth.debian.org/u32/program.php?test=pidigits&lang=scala&id=4
 

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

Are symbols ending with ':' allowed or not?

[Alexander Krasnukhin]

Hi,

I'm confused. Why there two different statements about ':' in symbols? What 
do I miss?

1. http://clojure.org/reader
"Symbols beginning or ending with ':' are reserved by Clojure."

2. https://github.com/edn-format/edn/blob/master/README.md
"Additionally, : # are allowed as constituent characters in symbols other 
than as the first character."

-- 
-- 
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: Clojure Performance For Expensive Algorithms

[Aria Haghighi]

I have a solution (gist here https://gist.github.com/aria42/5026109, key 
bits pasted below). It's pretty short (15 lines) and readable (I think) and 
only 50% slower than the Java version on my machine (averaging over 25 runs 
of your benchmark function). 

Generally, I've found it's really easy when you just translate Java code 
like this into Clojure, the Clojure will read worse than the original Java; 
to boot it will also be  slower! And not to be insulting, but I think the 
other Clojure solutions I saw in this thread seem to have this property. 
You usually have to pull out some abstraction in order to regain on the 
readability and concentrate on performance there. Here, I think it's a 
macro you'll probably use all over the place, arr-max, which will find the 
largest value of an expression looping over an array's index and values. 
Then lcs is just nested uses of arr-max that I think is pretty reasonable. 
The thing which clutters the remaining code are the prev/cur swapping which 
I don't have a slick way of handling.   

(defmacro arr-max 
  "return maximum value of `expr` over the indices
   and values of array `arr`, where `idx-symb` and `val-symb`
   are bound to index and values of `arr`"
  [arr idx-symb val-symb expr]
  `(let [arr# ~arr
 n# (alength arr#)]
 (loop [~idx-symb 0 max-val# java.lang.Long/MIN_VALUE]
   (if (= ~idx-symb n#)
 max-val#
 (let [~val-symb (aget arr# ~idx-symb)
   val# ~expr]
   (recur (inc ~idx-symb)
  (if (> val# max-val#)
val# max-val#)))
 
(defn lcs [^objects a1 ^objects a2]
  (let [prev-ref (atom (long-array (inc (alength a2
cur-ref (atom (long-array (inc (alength a2]
(arr-max a1 i v1
   (let [^longs prev @prev-ref
 ^longs cur @cur-ref
 max-len (arr-max a2 j v2
 (let [match-len (if (.equals v1 v2)
   (inc (aget prev j))
   0)]
   (aset cur (inc j) match-len)
   match-len))]
 (reset! prev-ref cur)
 (reset! cur-ref prev)
 (long max-len)
 


On Sunday, February 24, 2013 12:45:18 PM UTC-8, Marko Topolnik wrote:
>
>
>
> On Sunday, February 24, 2013 9:15:45 PM UTC+1, puzzler wrote:
>>
>>
>> As I mentioned before, I'm generally happy with Clojure's performance, 
>> but the few times I've had performance problems, I ended up rewriting the 
>> code at least three different ways in order to try to find the magic 
>> combination that would boost performance. 
>>
>
> Lately I've leaned towards going full monty the first time out: stop 
> guessing and optimize everything past the entry point to the critical 
> section. It sounds like more work up front, but in the end it's the "smart" 
> approach that results in more total effort.
>  
>
>> Fortunately, dropping down to Java is relatively painless.  But I still 
>> wonder whether there might be some benefit to having a "low-level DSL" 
>> within Clojure, a mode that lets you choose to write your code in a way 
>> where the semantics are closer to the underlying platform.
>>
>
> Just one feature would make a huge difference: reassignable locals.
>  
>
>> I haven't used Clojurescript much, but I get the impression that 
>> Clojurescript is already a step in that direction, with a simpler story 
>> regarding how mutation, arrays, and primitives are translated to the 
>> underlying platform, arguably making it easier to get good performance when 
>> you need it.
>>
>
> The gap between Clojure and JavaScript is far less than Java because both 
> are dynamic. I think that plays a big part in why ClojureScript can be more 
> transparent.
>  
>

-- 
-- 
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: Clojure Performance For Expensive Algorithms

[Ben Mabey]

On 2/24/13 1:34 PM, Marko Topolnik wrote:


I'm no Haskell expert, but it doesn't take much Googling to give
strong evidence that the answer is "yes, you can get mutability in
Haskell".  Search through this Haskell program on the Benchmarks
Game site for occurrences of the string "unsafe".


I see; quite disgusting :)

In my experience writing Clojure programs for the Benchmarks Game,
getting within 10x is fairly easy, and doesn't require much
knowledge other than eliminating Clojure reflection, and using a
decent algorithm that doesn't throw in an extra factor of N by
accident.  It often helps to use mutable Java arrays and Clojure
loops, too.


The default Clojure idiom is lazy seqs and higher-order functions. 
That's what I have in mind when I say 100x slower. Loops, and 
especially arrays, are a clear sign of optimization; they never come 
as the most natural way to express a solution.


In languages such as Java there is just one idiom: the performant one. 
That's why idiomatic Java performs well. In languages such as Clojure, 
the most expressive idiom, the one the language is appreciated for, is 
a level of abstraction or two above the performant idiom, so the 
interesting question becomes, how much performance can be engineered 
into /that/ level of abstraction. The question of the absolute 
performance ceiling achievable within the language is also of 
interest, but only secondary.


Now, my issue with a site such as the Benchmarks Game is that it will 
never give a fair representation of that concern, and I bet it is 
exactly this that most visitors of the site come looking for. That is 
what I meant when I said that Haskell is quite performant: I've heard 
/idiomatic/ Haskell performs well. I really couldn't care less how it 
performs with those /unsafe/ monstrosities. Those features are, and 
should be, reserved for the language's entrails, like the 
implementation of the IO monad.


Yeah, I wish the Benchmarks allowed for idiomatic submissions and finely 
tuned submissions.  That would allow you to get some sort of an idea how 
performant the dominant idiom is.  Along those lines this older post did 
an interesting analysis on the benchmark solutions where it explored the 
tension that exists between expressiveness and performance across the 
various languages:


http://blog.gmarceau.qc.ca/2009/05/speed-size-and-dependability-of.html



--
--
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: Clojure Performance For Expensive Algorithms

[Marek Srank]

On Sunday, February 24, 2013 9:45:18 PM UTC+1, Marko Topolnik wrote:
>
>
>
> On Sunday, February 24, 2013 9:15:45 PM UTC+1, puzzler wrote:
>>
>>
>> As I mentioned before, I'm generally happy with Clojure's performance, 
>> but the few times I've had performance problems, I ended up rewriting the 
>> code at least three different ways in order to try to find the magic 
>> combination that would boost performance. 
>>
>
> Lately I've leaned towards going full monty the first time out: stop 
> guessing and optimize everything past the entry point to the critical 
> section. It sounds like more work up front, but in the end it's the "smart" 
> approach that results in more total effort.
>  
>
>> Fortunately, dropping down to Java is relatively painless.  But I still 
>> wonder whether there might be some benefit to having a "low-level DSL" 
>> within Clojure, a mode that lets you choose to write your code in a way 
>> where the semantics are closer to the underlying platform.
>>
>
> Just one feature would make a huge difference: reassignable locals.
>  
>
>> I haven't used Clojurescript much, but I get the impression that 
>> Clojurescript is already a step in that direction, with a simpler story 
>> regarding how mutation, arrays, and primitives are translated to the 
>> underlying platform, arguably making it easier to get good performance when 
>> you need it.
>>
>
> The gap between Clojure and JavaScript is far less than Java because both 
> are dynamic. I think that plays a big part in why ClojureScript can be more 
> transparent.
>

This might be better in the future by utilizing 'invokedynamic' present 
since Java 7. See discussion here: 
https://groups.google.com/d/topic/clojure/1mr0m-9XLoo/discussion

Marek

>  
>

-- 
-- 
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: Clojure Performance For Expensive Algorithms

[Marko Topolnik]

On Sunday, February 24, 2013 9:15:45 PM UTC+1, puzzler wrote:
>
>
> As I mentioned before, I'm generally happy with Clojure's performance, but 
> the few times I've had performance problems, I ended up rewriting the code 
> at least three different ways in order to try to find the magic combination 
> that would boost performance. 
>

Lately I've leaned towards going full monty the first time out: stop 
guessing and optimize everything past the entry point to the critical 
section. It sounds like more work up front, but in the end it's the "smart" 
approach that results in more total effort.
 

> Fortunately, dropping down to Java is relatively painless.  But I still 
> wonder whether there might be some benefit to having a "low-level DSL" 
> within Clojure, a mode that lets you choose to write your code in a way 
> where the semantics are closer to the underlying platform.
>

Just one feature would make a huge difference: reassignable locals.
 

> I haven't used Clojurescript much, but I get the impression that 
> Clojurescript is already a step in that direction, with a simpler story 
> regarding how mutation, arrays, and primitives are translated to the 
> underlying platform, arguably making it easier to get good performance when 
> you need it.
>

The gap between Clojure and JavaScript is far less than Java because both 
are dynamic. I think that plays a big part in why ClojureScript can be more 
transparent.
 

-- 
-- 
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: Clojure Performance For Expensive Algorithms

[Marko Topolnik]

> I'm no Haskell expert, but it doesn't take much Googling to give strong 
> evidence that the answer is "yes, you can get mutability in Haskell". 
>  Search through this Haskell program on the Benchmarks Game site for 
> occurrences of the string "unsafe".
>

I see; quite disgusting :)
 

> In my experience writing Clojure programs for the Benchmarks Game, getting 
> within 10x is fairly easy, and doesn't require much knowledge other than 
> eliminating Clojure reflection, and using a decent algorithm that doesn't 
> throw in an extra factor of N by accident.  It often helps to use mutable 
> Java arrays and Clojure loops, too. 
>

The default Clojure idiom is lazy seqs and higher-order functions. That's 
what I have in mind when I say 100x slower. Loops, and especially arrays, 
are a clear sign of optimization; they never come as the most natural way 
to express a solution.

In languages such as Java there is just one idiom: the performant one. 
That's why idiomatic Java performs well. In languages such as Clojure, the 
most expressive idiom, the one the language is appreciated for, is a level 
of abstraction or two above the performant idiom, so the interesting 
question becomes, how much performance can be engineered into *that* level 
of abstraction. The question of the absolute performance ceiling achievable 
within the language is also of interest, but only secondary.

Now, my issue with a site such as the Benchmarks Game is that it will never 
give a fair representation of that concern, and I bet it is exactly this 
that most visitors of the site come looking for. That is what I meant when 
I said that Haskell is quite performant: I've heard *idiomatic* Haskell 
performs well. I really couldn't care less how it performs with those *
unsafe* monstrosities. Those features are, and should be, reserved for the 
language's entrails, like the implementation of the IO monad.

-- 
-- 
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: Clojure Performance For Expensive Algorithms

[Mark Engelberg]

On Sun, Feb 24, 2013 at 5:50 AM, bernardH
wrote:

> FWIW, I, for one, am really glad that Clojure allows us to select
> precisely which nice tools we want (have to) throw away (persistent data
> structures, dynamic typing, synchronized) when the need arises. Reminds me
> of the "don't pay for what you don't use" motto of C++ except done right
> (i.e. the other way around, because you don't want to pay wrt simplicity
> rather than performance, cf. "premature optimization…")
>

I think this notion that Clojure lets you select exactly what performance
tools you want to pay for when the need arises overlooks one important
point -- in Clojure it is not obvious what tools you need to employ to
solve a given performance problem.

As I mentioned before, I'm generally happy with Clojure's performance, but
the few times I've had performance problems, I ended up rewriting the code
at least three different ways in order to try to find the magic combination
that would boost performance.  Similarly, every snippet of well-tuned
optimized code posted on this list has generally been iteratively tuned by
several performance experts, often through a process of educated guesswork
and trial and error.  On two of my own performance-bottleneck occasions, I
went through a major rewrite to use defrecords rather than hash maps, only
to find that it *hurt* my performance.  If a reasonably expert Clojure
programmer can't make good predictions about whether a given rewrite will
help or hurt performance, that's something that must be taken account in
any discussion about how well Clojure lends itself to optimization.

I also think it's not entirely true that Clojure lets you easily choose
"what nice features you want to throw away" in pursuit of performance.  In
one algorithm involving massive pointer manipulation in a tight loop, even
after much experimentation, I was never able to figure out how to jettison
enough of Clojure's mutation straitjackets to get anywhere close to Java
performance.  I had no choice but to drop down to Java for that algorithm.

Fortunately, dropping down to Java is relatively painless.  But I still
wonder whether there might be some benefit to having a "low-level DSL"
within Clojure, a mode that lets you choose to write your code in a way
where the semantics are closer to the underlying platform.  I haven't used
Clojurescript much, but I get the impression that Clojurescript is already
a step in that direction, with a simpler story regarding how mutation,
arrays, and primitives are translated to the underlying platform, arguably
making it easier to get good performance when you need it.

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

Re: attaching doc-string from macro is driving me insane!

[Jim - FooBar();]

On 24/02/13 19:44, AtKaaZ wrote:
The problem is that you cannot catch that assert if it throws, ie. 
inside a deftest - just because it happens at compile time...


 a deftest will have its own top-level assertion...this is for client 
usage


--
--
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: attaching doc-string from macro is driving me insane!

[Jim - FooBar();]

On 24/02/13 19:44, AtKaaZ wrote:
you can maybe do with just (vec components) instead of (vector 
~@components)


nice one! it works :)

Jim

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Clojure Performance For Expensive Algorithms

[Andy Fingerhut]

On Feb 24, 2013, at 9:33 AM, Marko Topolnik wrote:

> 
> Take a look at any of the Common Lisp or Haskell submissions to the Computer 
> Language Benchmarks Game web site, and you will see some programs that are 
> nowhere near what people typically write in those languages, and certainly 
> not what people would write if they weren't concerned with squeezing out the 
> last drop of performance.  Lots of mutable data structures in both, and lots 
> of type declarations in Common Lisp.
> 
> Can you really get mutability in Haskell? I thought that was impossible; 
> hence the notorious State monad.

I'm no Haskell expert, but it doesn't take much Googling to give strong 
evidence that the answer is "yes, you can get mutability in Haskell".  Search 
through this Haskell program on the Benchmarks Game site for occurrences of the 
string "unsafe".


http://benchmarksgame.alioth.debian.org/u64q/program.php?test=fannkuchredux&lang=ghc&id=4

Then check out the description of those operations on this web page:


http://hackage.haskell.org/packages/archive/array/0.3.0.2/doc/html/Data-Array-MArray.html

Similarly look for occurrences of "unsafe" in the other fastest Haskell 
programs.  I found about 4 out of 10 of them use such operations.


> Then again, even for C and Java programs on that site, people will do some 
> pretty amazing tricks they wouldn't normally do in those languages, either, 
> e.g. performing I/O in parallel with computation, even when it makes the 
> computation code more complex to give the correct answer.
> 
> Yes, I've already got frustrated with that site several times. For example, 
> Scala beats Java by a wide margin on some benchmarks. Turns out it's because 
> it uses JNI to solve the problem with the C bignum library. What relevance 
> could that have?

So ignore the results for pidigits, which is likely the one you saw that uses 
the libgmp library.  Many people who dismiss the Benchmarks Game site point 
that out, and I agree: the pidigits benchmark doesn't tell you much, other than 
whether the program uses the libgmp library or not.

Instead look at the results for other programs that don't pull those tricks, or 
ignore the site entirely.  If you worry that some people hastily draw the wrong 
conclusions from the results on that site, such people are being insufficiently 
critical in their interpretation of the data.


> For Clojure, I'd recommend doing the same thing I'd recommend in just about 
> any language: write the code that occurs to you first to get it correct.  If 
> it is fast enough for your purposes, whatever those are, you are done.  If 
> not, use a profiler to see where most of the time is spent, and then start 
> working on optimizations in the same language if they are worth your time to 
> do so.  If they get too difficult in the original language, dropping down to 
> a lower-level language (e.g. Java, C, assembler) is often a choice you can 
> make, depending upon your deployment restrictions.
> 
> The important consideration is, just how many times the idiomatic code is 
> slower? In my book it is a worthwhile goal to improve from 100x slower to 10x 
> slower, even if that outcome still means it's quite a bit slower.

In my experience writing Clojure programs for the Benchmarks Game, getting 
within 10x is fairly easy, and doesn't require much knowledge other than 
eliminating Clojure reflection, and using a decent algorithm that doesn't throw 
in an extra factor of N by accident.  It often helps to use mutable Java arrays 
and Clojure loops, too.

Getting better than 3x of a Java program that pulls out all the optimization 
tricks is tougher in Clojure.  If you're in that situation, I'd say use Java 
and simplify your life.

Andy

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

Re: attaching doc-string from macro is driving me insane!

[AtKaaZ]

you can maybe do with just (vec components) instead of (vector ~@components)
=> (defmacro x [& lst]
 (let [a (eval (vec lst))]
   `~a
   )
 )
#'util.funxions/x
=> (x 1 2 3)
[1 2 3]

I think eval is okay there, because it should only happen at compile time
(or I'm missing something).
The problem is that you cannot catch that assert if it throws, ie. inside a
deftest - just because it happens at compile time...



On Sun, Feb 24, 2013 at 8:27 PM, Jim - FooBar(); wrote:

>  ~PHEW, @~ I cracked it finally!
>
> If anyone can think of a better solution, please please please  share!!!
>
> @Atkaaz.
> It turns out you were sort of right...less back-ticking did the trick...I
> still don't like the eval-ing though
>
>
> (defmacro def-plus-doc [name & symbs]
> (let [[doc & syms :as all] (eval `(vector ~@symbs))
>cs  (if (string? doc) [syms true] [all false])
>ds  (if (second cs) doc "UNDOCUMENTED")]
>  `(def ~(with-meta name (assoc (meta name) :doc ds)) ~@(first cs
>
>
> and for the sake of completeness the actual macro I wanted to build is
> this (notice the '~ on the constructor call):
>
> (defmacro defworkflow
> "Defines a top-level Workflow with the specified name containing the given
> Components."
> [name & components]
> (let [[doc & comps :as all] (eval `(vector ~@components))
>cs  (if (string? doc) [comps true] [all false])
>ds  (if (second cs) doc "This workflow has not been documented...")]
>   (assert (every? component? (first cs)) "Can only accept IComponents")
> `(def ~(with-meta name (assoc (meta name) :doc ds)) (Workflow. '~(first
> cs) {:description ~ds} nil
>
>
> Time for a beer! :)
>
> Jim
>
>
>
>
> On 24/02/13 19:02, AtKaaZ wrote:
>
>  I don't know what to tell you... basically it should be something like
> this (working on your first example, since I i don't wanna break my brain
> trying to understand the second one xD)
>
> (defmacro def-plus-doc [name doc & syms]
>   (let [zdoc (eval doc)
> _ (assert (string? zdoc) (str "must be string, you passed " doc))
> ]
> `(def ~(with-meta name (assoc (meta name) :doc zdoc)) ~@syms)
> )
>   )
>
> => (def-plus-doc a (str "assa" "def") "b")
> #'util.funxions/a
> => (doc a)
> -
> util.funxions/a
>   assadef
> nil
> => (meta #'a)
> {:ns #, :name a, :column 1, :doc "assadef", :line
> 1, :file "NO_SOURCE_PATH"}
>
> => (def-plus-doc a "abcd" "b")
> #'util.funxions/a
> => (meta #'a)
> {:ns #, :name a, :column 1, :doc "abcd", :line 1,
> :file "NO_SOURCE_PATH"}
>
>  => (def-plus-doc a 2 "b")
> AssertionError Assert failed: must be string, you passed 2
> (string? zdoc)  util.funxions/def-plus-doc (NO_SOURCE_FILE:3)
>
>
>
> On Sun, Feb 24, 2013 at 7:49 PM, Jim - FooBar(); wrote:
>
>>  I tried with eval, tried the let inside and outside the syntax-quote -
>> I've tried everything! This is so frustrating!
>>
>> Jim
>>
>>
>>
>> On 24/02/13 18:24, AtKaaZ wrote:
>>
>> ds# inside the def is inside a ~() which means it's expected to
>> exist outside of the `
>>  like:
>>  (defmacro ...
>>(let [ds# "something]
>>  `(def ~(... ds# ) 
>> ))
>>
>>  maybe try the let block be outside of the ` ? but that means you
>> probably need to use eval
>>
>>  It's funny I tried the same thing like you like 1 day ago here:
>> https://github.com/DeMLinkS/demlinks/commit/85219208007fff6e7a11fb579d7125c73a6dc597
>>  by trying to put the let inside the ` but failed
>>
>>
>> On Sun, Feb 24, 2013 at 6:02 PM, Jim - FooBar(); wrote:
>>
>>> Hi everyone,
>>>
>>> I cannot figure out for the life of me how to pass in an optional
>>> doc-string into a 'defsomething' macro and have it to work. If I hard-code
>>> it then it works just fine...
>>>
>>> (defmacro def-plus-doc [name & syms]
>>>   `(def ~(with-meta name (assoc (meta name) :doc "HI!")) ~@syms)) ;;this
>>> will work just fine
>>>
>>> (defmacro def-plus-doc [name & syms]  ;;slightly augmented to detect
>>> doc-string
>>> `(let [[doc# & syms# :as all#] (vector ~@syms)
>>> cs#  (if (string? doc#) [syms# true] [all# false])
>>> ds#  (if (second cs#) doc# "This workflow has not been
>>> documented...")]
>>>(def ~(with-meta name (assoc (meta name) :doc ds#)) ~@syms)))
>>>
>>> ;;fails with CompilerException java.lang.RuntimeException: Unable to
>>> resolve symbol: ds# in this context, compiling:(NO_SOURCE_PATH:5:26)
>>>
>>> why is it so hard? I've been trying for almost 3 hours nothing seems
>>> to work... :(
>>>
>>> Jim
>>>
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- You received this message be

Re: attaching doc-string from macro is driving me insane!

[Jim - FooBar();]

~PHEW, @~ I cracked it finally!

If anyone can think of a better solution, please please please share!!!

@Atkaaz.
It turns out you were sort of right...less back-ticking did the 
trick...I still don't like the eval-ing though



(defmacro def-plus-doc [name & symbs]
(let [[doc & syms :as all] (eval `(vector ~@symbs))
   cs  (if (string? doc) [syms true] [all false])
   ds  (if (second cs) doc "UNDOCUMENTED")]
 `(def ~(with-meta name (assoc (meta name) :doc ds)) ~@(first cs


and for the sake of completeness the actual macro I wanted to build is 
this (notice the '~ on the constructor call):


(defmacro defworkflow
"Defines a top-level Workflow with the specified name containing the 
given Components."

[name & components]
(let [[doc & comps :as all] (eval `(vector ~@components))
   cs  (if (string? doc) [comps true] [all false])
   ds  (if (second cs) doc "This workflow has not been documented...")]
  (assert (every? component? (first cs)) "Can only accept IComponents")
`(def ~(with-meta name (assoc (meta name) :doc ds)) (Workflow. '~(first 
cs) {:description ~ds} nil



Time for a beer! :)

Jim



On 24/02/13 19:02, AtKaaZ wrote:
I don't know what to tell you... basically it should be something like 
this (working on your first example, since I i don't wanna break my 
brain trying to understand the second one xD)


(defmacro def-plus-doc [name doc & syms]
  (let [zdoc (eval doc)
_ (assert (string? zdoc) (str "must be string, you passed " doc))
]
`(def ~(with-meta name (assoc (meta name) :doc zdoc)) ~@syms)
)
  )

=> (def-plus-doc a (str "assa" "def") "b")
#'util.funxions/a
=> (doc a)
-
util.funxions/a
  assadef
nil
=> (meta #'a)
{:ns #, :name a, :column 1, :doc "assadef", 
:line 1, :file "NO_SOURCE_PATH"}


=> (def-plus-doc a "abcd" "b")
#'util.funxions/a
=> (meta #'a)
{:ns #, :name a, :column 1, :doc "abcd", 
:line 1, :file "NO_SOURCE_PATH"}


=> (def-plus-doc a 2 "b")
AssertionError Assert failed: must be string, you passed 2
(string? zdoc)  util.funxions/def-plus-doc (NO_SOURCE_FILE:3)



On Sun, Feb 24, 2013 at 7:49 PM, Jim - FooBar(); > wrote:


I tried with eval, tried the let inside and outside the
syntax-quote - I've tried everything! This is so frustrating!

Jim



On 24/02/13 18:24, AtKaaZ wrote:

ds# inside the def is inside a ~() which means it's expected to
exist outside of the `
like:
(defmacro ...
  (let [ds# "something]
`(def ~(... ds# ) 
))

maybe try the let block be outside of the ` ? but that means you
probably need to use eval

It's funny I tried the same thing like you like 1 day ago here:

https://github.com/DeMLinkS/demlinks/commit/85219208007fff6e7a11fb579d7125c73a6dc597
by trying to put the let inside the ` but failed


On Sun, Feb 24, 2013 at 6:02 PM, Jim - FooBar();
mailto:jimpil1...@gmail.com>> wrote:

Hi everyone,

I cannot figure out for the life of me how to pass in an
optional doc-string into a 'defsomething' macro and have it
to work. If I hard-code it then it works just fine...

(defmacro def-plus-doc [name & syms]
  `(def ~(with-meta name (assoc (meta name) :doc "HI!"))
~@syms)) ;;this will work just fine

(defmacro def-plus-doc [name & syms]  ;;slightly augmented to
detect doc-string
`(let [[doc# & syms# :as all#] (vector ~@syms)
cs#  (if (string? doc#) [syms# true] [all# false])
ds#  (if (second cs#) doc# "This workflow has not
been documented...")]
   (def ~(with-meta name (assoc (meta name) :doc ds#)) ~@syms)))

;;fails with CompilerException java.lang.RuntimeException:
Unable to resolve symbol: ds# in this context,
compiling:(NO_SOURCE_PATH:5:26)

why is it so hard? I've been trying for almost 3 hours
nothing seems to work... :(

Jim


-- 
-- 
You received this message because you are subscribed to the

Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com

Note that posts from new members are moderated - please be
patient with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- You received this message because you are subscribed to
the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to clojure+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.

Re: attaching doc-string from macro is driving me insane!

[AtKaaZ]

I don't know what to tell you... basically it should be something like this
(working on your first example, since I i don't wanna break my brain trying
to understand the second one xD)

(defmacro def-plus-doc [name doc & syms]
  (let [zdoc (eval doc)
_ (assert (string? zdoc) (str "must be string, you passed " doc))
]
`(def ~(with-meta name (assoc (meta name) :doc zdoc)) ~@syms)
)
  )

=> (def-plus-doc a (str "assa" "def") "b")
#'util.funxions/a
=> (doc a)
-
util.funxions/a
  assadef
nil
=> (meta #'a)
{:ns #, :name a, :column 1, :doc "assadef", :line
1, :file "NO_SOURCE_PATH"}

=> (def-plus-doc a "abcd" "b")
#'util.funxions/a
=> (meta #'a)
{:ns #, :name a, :column 1, :doc "abcd", :line 1,
:file "NO_SOURCE_PATH"}

=> (def-plus-doc a 2 "b")
AssertionError Assert failed: must be string, you passed 2
(string? zdoc)  util.funxions/def-plus-doc (NO_SOURCE_FILE:3)



On Sun, Feb 24, 2013 at 7:49 PM, Jim - FooBar(); wrote:

>  I tried with eval, tried the let inside and outside the syntax-quote -
> I've tried everything! This is so frustrating!
>
> Jim
>
>
>
> On 24/02/13 18:24, AtKaaZ wrote:
>
> ds# inside the def is inside a ~() which means it's expected to exist
> outside of the `
>  like:
>  (defmacro ...
>(let [ds# "something]
>  `(def ~(... ds# ) 
> ))
>
>  maybe try the let block be outside of the ` ? but that means you probably
> need to use eval
>
>  It's funny I tried the same thing like you like 1 day ago here:
> https://github.com/DeMLinkS/demlinks/commit/85219208007fff6e7a11fb579d7125c73a6dc597
>  by trying to put the let inside the ` but failed
>
>
> On Sun, Feb 24, 2013 at 6:02 PM, Jim - FooBar(); wrote:
>
>> Hi everyone,
>>
>> I cannot figure out for the life of me how to pass in an optional
>> doc-string into a 'defsomething' macro and have it to work. If I hard-code
>> it then it works just fine...
>>
>> (defmacro def-plus-doc [name & syms]
>>   `(def ~(with-meta name (assoc (meta name) :doc "HI!")) ~@syms)) ;;this
>> will work just fine
>>
>> (defmacro def-plus-doc [name & syms]  ;;slightly augmented to detect
>> doc-string
>> `(let [[doc# & syms# :as all#] (vector ~@syms)
>> cs#  (if (string? doc#) [syms# true] [all# false])
>> ds#  (if (second cs#) doc# "This workflow has not been
>> documented...")]
>>(def ~(with-meta name (assoc (meta name) :doc ds#)) ~@syms)))
>>
>> ;;fails with CompilerException java.lang.RuntimeException: Unable to
>> resolve symbol: ds# in this context, compiling:(NO_SOURCE_PATH:5:26)
>>
>> why is it so hard? I've been trying for almost 3 hours nothing seems
>> to work... :(
>>
>> Jim
>>
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
> --
> Please correct me if I'm wrong or incomplete,
> even if you think I'll subconsciously hate it.
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

Re: [GSoC Idea] cljs layer/dsl over express js

[Omer Iqbal]

I looked at dogfort, and discussed the possibility of extending it's
functionality as a GSOC project with Bodil, to which she agreed. Here's the
proposal we came up with:
Extending dogfort for real world use
Brief explanation:  Node.js provides a lightweight and fast server
implementation, that’s commonly used for real time applications. Although
its possible to make clojurescript applications targeting nodejs, the
current experience is far from pleasant. Partly due to node’s heavy use of
callback hell, and partly because most existing node libraries are heavily
object oriented and imperative. Dogfort (https://github.com/bodil/dogfort)
is a nice proof of concept , inspired by ring and compojure, that abstracts
out quite a few of these issues.


Expected results: An improved version of dogfort that can be put to real
world use. New features include:
- sessions
- cookies
- authentication middleware
- socket.io abstraction
- route filtering middleware

**
Knowledge prerequisites: Familiarity with nodejs
Mentor: Bodil Stokke

Can someone with confluence access add it to the Project Ideas page?
Thanks!
Omer

On Fri, Feb 15, 2013 at 7:12 AM, David Nolen  wrote:

> I responded to Omer on Twitter, it's probably worth looking into existing
> projects like Bodil Stokke's Dog Fort first -
> https://github.com/bodil/dogfort
>
> David
>
>
> On Thu, Feb 14, 2013 at 5:48 PM, Tamreen Khan  wrote:
>
>> But compojure isn't in cljs, so you have to use the jvm. A wrapper around
>> express would mean you could run it on node.
>>
>>
>> On Thu, Feb 14, 2013 at 5:35 PM, Josh Kamau wrote:
>>
>>> Clojure has compojure ... which is a sinatra like web framework  and
>>> you can create a new project using"lein new compojure"   and start
>>> creating your request handler functions from there ... Just like in
>>> express.  If you want a jade equivalent... you can use hiccup .
>>>
>>> Josh.
>>>
>>>
>>> On Fri, Feb 15, 2013 at 12:30 AM, Omer Iqbal wrote:
>>>
 Just throwing ideas. Feel free to shoot it down if you folks think its
 not worth it :).
 Also, I'm a student, and would actually be participating in GSOC, so
 this is more of a shoutout for possible mentors, if you guys think the
 project makes sense.

 The Problem:
 1. cljs doesn't yet have a library/framework of its own to facilitate
 serverside web dev over nodejs. (I might be wrong here, and please correct
 me if I am).
 2. Expressjs(http://expressjs.com/) is an awesome sinatra inspired,
 very popular, web app framework for node.
 3. Using express directly using js interop calls can get ugly
 QED: It would make sense to have a cljs layer over express

 The Solution:
 I haven't ironed this out fully, but it would probably be a good idea
 to produce a compojure like framework, so its easier to adopt. Under the
 hood you'll obviously have either interop calls, or cljs implementations
 for the same functionality.

 Would love feedback on the idea! And whether can haz mentor?

 Cheers,
 Omer
 (@olenhad)

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



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

Re: attaching doc-string from macro is driving me insane!

[Jim - FooBar();]

I tried with eval, tried the let inside and outside the syntax-quote - 
I've tried everything! This is so frustrating!


Jim


On 24/02/13 18:24, AtKaaZ wrote:
ds# inside the def is inside a ~() which means it's expected to exist 
outside of the `

like:
(defmacro ...
  (let [ds# "something]
`(def ~(... ds# ) 
))

maybe try the let block be outside of the ` ? but that means you 
probably need to use eval


It's funny I tried the same thing like you like 1 day ago here: 
https://github.com/DeMLinkS/demlinks/commit/85219208007fff6e7a11fb579d7125c73a6dc597

by trying to put the let inside the ` but failed


On Sun, Feb 24, 2013 at 6:02 PM, Jim - FooBar(); > wrote:


Hi everyone,

I cannot figure out for the life of me how to pass in an optional
doc-string into a 'defsomething' macro and have it to work. If I
hard-code it then it works just fine...

(defmacro def-plus-doc [name & syms]
  `(def ~(with-meta name (assoc (meta name) :doc "HI!")) ~@syms))
;;this will work just fine

(defmacro def-plus-doc [name & syms]  ;;slightly augmented to
detect doc-string
`(let [[doc# & syms# :as all#] (vector ~@syms)
cs#  (if (string? doc#) [syms# true] [all# false])
ds#  (if (second cs#) doc# "This workflow has not been
documented...")]
   (def ~(with-meta name (assoc (meta name) :doc ds#)) ~@syms)))

;;fails with CompilerException java.lang.RuntimeException: Unable
to resolve symbol: ds# in this context,
compiling:(NO_SOURCE_PATH:5:26)

why is it so hard? I've been trying for almost 3 hours nothing
seems to work... :(

Jim


-- 
-- 
You received this message because you are subscribed to the Google

Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com

Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- You received this message because you are subscribed to the
Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to clojure+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.





--
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate it.

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.




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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: attaching doc-string from macro is driving me insane!

[AtKaaZ]

ds# inside the def is inside a ~() which means it's expected to exist
outside of the `
like:
(defmacro ...
  (let [ds# "something]
`(def ~(... ds# ) 
))

maybe try the let block be outside of the ` ? but that means you probably
need to use eval

It's funny I tried the same thing like you like 1 day ago here:
https://github.com/DeMLinkS/demlinks/commit/85219208007fff6e7a11fb579d7125c73a6dc597
by trying to put the let inside the ` but failed


On Sun, Feb 24, 2013 at 6:02 PM, Jim - FooBar(); wrote:

> Hi everyone,
>
> I cannot figure out for the life of me how to pass in an optional
> doc-string into a 'defsomething' macro and have it to work. If I hard-code
> it then it works just fine...
>
> (defmacro def-plus-doc [name & syms]
>   `(def ~(with-meta name (assoc (meta name) :doc "HI!")) ~@syms)) ;;this
> will work just fine
>
> (defmacro def-plus-doc [name & syms]  ;;slightly augmented to detect
> doc-string
> `(let [[doc# & syms# :as all#] (vector ~@syms)
> cs#  (if (string? doc#) [syms# true] [all# false])
> ds#  (if (second cs#) doc# "This workflow has not been
> documented...")]
>(def ~(with-meta name (assoc (meta name) :doc ds#)) ~@syms)))
>
> ;;fails with CompilerException java.lang.RuntimeException: Unable to
> resolve symbol: ds# in this context, compiling:(NO_SOURCE_PATH:5:**26)
>
> why is it so hard? I've been trying for almost 3 hours nothing seems
> to work... :(
>
> Jim
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscribe@**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+unsubscribe@**googlegroups.com
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>
>
>


-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate it.

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

Re: Clojure Performance For Expensive Algorithms

[Marko Topolnik]

> > from what I hear, idiomatic Haskell is a performance devil as well 
>
> Does this mean very good, or very bad? 
>

It means the same as in "speed devil" :)
 

> On a related note, is there currently any way to get the Clojure compiler 
> to tell you where boxing is occurring, like *warn-on-reflection* does for 
> reflection?


It already does that by default, but only for loop bindings. This makes 
sense because outside tight loops boxing really can't hurt. The performance 
hit of one box-unbox roundtrip is (my guesstimate) on the order of 10 
primitive arithmetic operations. A reflective call is on the order of 1000 
ops.

-- 
-- 
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: Clojure Performance For Expensive Algorithms

[Marko Topolnik]

> Take a look at any of the Common Lisp or Haskell submissions to the 
> Computer Language Benchmarks Game web site, and you will see some programs 
> that are nowhere near what people typically write in those languages, and 
> certainly not what people would write if they weren't concerned with 
> squeezing out the last drop of performance.  Lots of mutable data 
> structures in both, and lots of type declarations in Common Lisp.
>

Can you really get mutability in Haskell? I thought that was impossible; 
hence the notorious State monad.
 

> Then again, even for C and Java programs on that site, people will do some 
> pretty amazing tricks they wouldn't normally do in those languages, either, 
> e.g. performing I/O in parallel with computation, even when it makes the 
> computation code more complex to give the correct answer.
>

Yes, I've already got frustrated with that site several times. For example, 
Scala beats Java by a wide margin on some benchmarks. Turns out it's 
because it uses JNI to solve the problem with the C bignum library. What 
relevance could that have?

For Clojure, I'd recommend doing the same thing I'd recommend in just about 
> any language: write the code that occurs to you first to get it correct. 
>  If it is fast enough for your purposes, whatever those are, you are done. 
>  If not, use a profiler to see where most of the time is spent, and then 
> start working on optimizations in the same language if they are worth your 
> time to do so.  If they get too difficult in the original language, 
> dropping down to a lower-level language (e.g. Java, C, assembler) is often 
> a choice you can make, depending upon your deployment restrictions.
>

The important consideration is, just how many times the idiomatic code is 
slower? In my book it is a worthwhile goal to improve from 100x slower to 
10x slower, even if that outcome still means it's quite a bit slower.

-- 
-- 
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: Clojure Performance For Expensive Algorithms

[Andy Fingerhut]

On Feb 24, 2013, at 8:46 AM, Marko Topolnik wrote:

> On Sunday, February 24, 2013 2:50:01 PM UTC+1, bernardH wrote:
> FWIW, I, for one, am really glad that Clojure allows us to select precisely 
> which nice tools we want (have to) throw away (persistent data structures, 
> dynamic typing, synchronized) when the need arises. Reminds me of the "don't 
> pay for what you don't use" motto of C++ except done right (i.e. the other 
> way around, because you don't want to pay wrt simplicity rather than 
> performance, cf. "premature optimization…")
> 
> Don't you think that the real goal is to have performant idiomatic code? That 
> was certainly the aim of the Common Lisp community of the '80s and, from what 
> I hear, idiomatic Haskell is a performance devil as well. Static typing isn't 
> just about type safety, after all; it's also about performance. When the 
> compiler knows everything about your code, it has a much easier time 
> producing killer machine code.

For both Common Lisp and Haskell, the most straightforward code you would 
typically write for many problems allocates more memory than code specifically 
written to avoid allocating memory, and if other things are equal (which they 
often aren't), code that allocates less memory can be faster.

At least for Common Lisp, it can often generate faster code with appropriate 
type declarations, especially for arithmetic.

Take a look at any of the Common Lisp or Haskell submissions to the Computer 
Language Benchmarks Game web site, and you will see some programs that are 
nowhere near what people typically write in those languages, and certainly not 
what people would write if they weren't concerned with squeezing out the last 
drop of performance.  Lots of mutable data structures in both, and lots of type 
declarations in Common Lisp.

Common Lisp (SBCL) vs Java   
http://benchmarksgame.alioth.debian.org/u64q/lisp.php
Haskell vs. Java   http://benchmarksgame.alioth.debian.org/u64q/haskell.php

Then again, even for C and Java programs on that site, people will do some 
pretty amazing tricks they wouldn't normally do in those languages, either, 
e.g. performing I/O in parallel with computation, even when it makes the 
computation code more complex to give the correct answer.

For Clojure, I'd recommend doing the same thing I'd recommend in just about any 
language: write the code that occurs to you first to get it correct.  If it is 
fast enough for your purposes, whatever those are, you are done.  If not, use a 
profiler to see where most of the time is spent, and then start working on 
optimizations in the same language if they are worth your time to do so.  If 
they get too difficult in the original language, dropping down to a lower-level 
language (e.g. Java, C, assembler) is often a choice you can make, depending 
upon your deployment restrictions.

Andy

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

attaching doc-string from macro is driving me insane!

[Jim - FooBar();]

Hi everyone,

I cannot figure out for the life of me how to pass in an optional 
doc-string into a 'defsomething' macro and have it to work. If I 
hard-code it then it works just fine...


(defmacro def-plus-doc [name & syms]
  `(def ~(with-meta name (assoc (meta name) :doc "HI!")) ~@syms)) 
;;this will work just fine


(defmacro def-plus-doc [name & syms]  ;;slightly augmented to detect 
doc-string

`(let [[doc# & syms# :as all#] (vector ~@syms)
cs#  (if (string? doc#) [syms# true] [all# false])
ds#  (if (second cs#) doc# "This workflow has not been 
documented...")]

   (def ~(with-meta name (assoc (meta name) :doc ds#)) ~@syms)))

;;fails with CompilerException java.lang.RuntimeException: Unable to 
resolve symbol: ds# in this context, compiling:(NO_SOURCE_PATH:5:26)


why is it so hard? I've been trying for almost 3 hours nothing seems 
to work... :(


Jim


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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Clojure Performance For Expensive Algorithms

[Michael Gardner]

On Feb 24, 2013, at 10:46 , Marko Topolnik  wrote:

> from what I hear, idiomatic Haskell is a performance devil as well

Does this mean very good, or very bad?

On a related note, is there currently any way to get the Clojure compiler to 
tell you where boxing is occurring, like *warn-on-reflection* does for 
reflection?

-- 
-- 
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: Clojure Performance For Expensive Algorithms

[Marko Topolnik]

On Sunday, February 24, 2013 4:27:34 PM UTC+1, Geo wrote:

> At the moment I don't find the Clojure solution simple, but again this may 
> simply be to lack of exposure. Have you written a lot of performance 
> optimized Clojure?
>

Yes, that's the catch, isn't it? If we had to write Clojure in the 
performant idiom all the time, Clojure wouldn't exactly be an appealing 
language. So, by definition almost, happy Clojure users are inexperienced 
in writing performant Clojure. There is also something about diminishing 
returns here: you need to learn a *lot* of minute particularities just to 
be able to write that one key function.

-- 
-- 
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: Clojure Performance For Expensive Algorithms

[Marko Topolnik]

On Sunday, February 24, 2013 2:50:01 PM UTC+1, bernardH wrote:

> FWIW, I, for one, am really glad that Clojure allows us to select 
> precisely which nice tools we want (have to) throw away (persistent data 
> structures, dynamic typing, synchronized) when the need arises. Reminds me 
> of the "don't pay for what you don't use" motto of C++ except done right 
> (i.e. the other way around, because you don't want to pay wrt simplicity 
> rather than performance, cf. "premature optimization…")


Don't you think that the real goal is to have performant idiomatic code? 
That was certainly the aim of the Common Lisp community of the '80s and, 
from what I hear, idiomatic Haskell is a performance devil as well. Static 
typing isn't just about type safety, after all; it's also about 
performance. When the compiler knows everything about your code, it has a 
much easier time producing killer machine code.

-- 
-- 
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: Clojure Performance For Expensive Algorithms

[Geo]

Well I'll just say that my opinion on this matter is not well formed at the 
moment since this is the first time I have encountered this issue. For now 
I've stuck with the Java algorithm so I can move on with my project, but I 
do plan to revisit this at some point. In fact, it may be important for my 
project to keep it all Clojure.

At the moment I don't find the Clojure solution simple, but again this may 
simply be to lack of exposure. Have you written a lot of performance 
optimized Clojure?

On Sunday, February 24, 2013 8:50:01 AM UTC-5, bernardH wrote:
>
>
>
> On Thursday, February 21, 2013 10:27:11 PM UTC+1, Geo wrote:
>>
>> Man, this is exactly how I feel after all this tinkering! It was great 
>> for learning Clojure a bit more in depth, but in the end I am going to 
>> stick with the Java solution. Especially since it's so easy to mix Java and 
>> Clojure in the same project! I just specify :java-source-paths ["src/java"] 
>> in my project.clj and I just call that one method when I need it and the 
>> rest of the project is in Clojure. I think when performance if critical 
>> idiomatic Clojure is to just drop down to Java :) 
>>
>> Christophe's second function actually achieves Java speed or very close 
>> (within 5-10%), but it's ugly and there's a bit more to my algorithm which 
>> would make it even uglier if I were to go that route.
>>
>>
> There would be no point in me to argue with you whether Chrispohe's 
> version really is "ugly" or not for you, but I'd like to rephrase it as 
> "hard on the eye". Because I find this "performance oriented Clojure" vs 
> Java fits quiet well in the "easy" vs "simple" mindeset.[*]. Adding Java 
> code in a Clojure project is certainly easy if you happen to already know 
> the language, while no amount of prior experience in idiomatic Clojure will 
> help you in writing perfomance oriented Clojure as it can be a completely 
> new idiom. But I do believe that the resulting code (as a whole, not just 
> the small performance critical bit of code) is simpler with two idioms in 
> one language than with two languages.
>
> FWIW, I, for one, am really glad that Clojure allows us to select 
> precisely which nice tools we want (have to) throw away (persistent data 
> structures, dynamic typing, synchronized) when the need arises. Reminds me 
> of the "don't pay for what you don't use" motto of C++ except done right 
> (i.e. the other way around, because you don't want to pay wrt simplicity 
> rather than performance, cf. "premature optimization…")
>
> Cheers,
>
> Bernard
>
> [*] https://www.youtube.com/watch?v=rI8tNMsozo0
>

-- 
-- 
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: Clojure Performance For Expensive Algorithms

[bernardH]

On Thursday, February 21, 2013 10:27:11 PM UTC+1, Geo wrote:
>
> Man, this is exactly how I feel after all this tinkering! It was great for 
> learning Clojure a bit more in depth, but in the end I am going to stick 
> with the Java solution. Especially since it's so easy to mix Java and 
> Clojure in the same project! I just specify :java-source-paths ["src/java"] 
> in my project.clj and I just call that one method when I need it and the 
> rest of the project is in Clojure. I think when performance if critical 
> idiomatic Clojure is to just drop down to Java :) 
>
> Christophe's second function actually achieves Java speed or very close 
> (within 5-10%), but it's ugly and there's a bit more to my algorithm which 
> would make it even uglier if I were to go that route.
>
>
There would be no point in me to argue with you whether Chrispohe's version 
really is "ugly" or not for you, but I'd like to rephrase it as "hard on 
the eye". Because I find this "performance oriented Clojure" vs Java fits 
quiet well in the "easy" vs "simple" mindeset.[*]. Adding Java code in a 
Clojure project is certainly easy if you happen to already know the 
language, while no amount of prior experience in idiomatic Clojure will 
help you in writing perfomance oriented Clojure as it can be a completely 
new idiom. But I do believe that the resulting code (as a whole, not just 
the small performance critical bit of code) is simpler with two idioms in 
one language than with two languages.

FWIW, I, for one, am really glad that Clojure allows us to select precisely 
which nice tools we want (have to) throw away (persistent data structures, 
dynamic typing, synchronized) when the need arises. Reminds me of the 
"don't pay for what you don't use" motto of C++ except done right (i.e. the 
other way around, because you don't want to pay wrt simplicity rather than 
performance, cf. "premature optimization…")

Cheers,

Bernard

[*] https://www.youtube.com/watch?v=rI8tNMsozo0

-- 
-- 
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: creating code stubs to use inside an extend-protocol form

[Jim - FooBar();]

Thanks to both Atkaaz & Tim...
you were both very helpful, albeit for different reasons! Atkaaz pointed 
me to a promising syntax-quoting library that I didn't even know existed 
and Tim essentially provided the solution I settled for. Since that 
code-snippet can be found in core, I'll just assume this is the way to 
go...I also didn't want to bring in external dependencies as I'm 
preparing an nlp-lib that acts like glue between several java nlp libs 
out there... something like U-Compare but on the API level...the less 
dependencies the better :)


Jim


On 24/02/13 09:53, Tim Reinke wrote:
Coincidentally, I just found this in clojure/core/protocols.clj 
 (not 
that this is necessarily the best way to do this):


(def arr-impl
  '(internal-reduce
   [a-seq f val]
   (let [arr (.array a-seq)]
 (loop [i (.index a-seq)
val val]
   (if (< i (alength arr))
 (let [ret (f val (aget arr i))]
(if (reduced? ret)
  @ret
  (recur (inc i) ret)))
 val)

(defn- emit-array-impls*
  [syms]
  (apply
   concat
   (map
(fn [s]
  [(symbol (str "clojure.lang.ArraySeq$ArraySeq_" s))
   arr-impl])
syms)))

(defmacro emit-array-impls
  [& syms]
  `(extend-protocol InternalReduce
 ~@(emit-array-impls* syms)))

(emit-array-impls int long float double byte char boolean)
On Saturday, February 23, 2013 4:03:02 AM UTC-8, Jim foo.bar wrote:

I seem to be unable to quote a form and then repeatedly pass it
inside
the extend-protocol macro...something like this:

(def ^:private co-stub
'(run [this ^String text]
(let [ann (edu.stanford.nlp.pipeline.Annotation. text)]
  (.annotate this ann) ann)))


(extend-protocol IComponent
edu.stanford.nlp.pipeline.POSTaggerAnnotator  co-stub
edu.stanford.nlp.pipeline.PTBTokenizerAnnotator co-stub
edu.stanford.nlp.pipeline.WordsToSentencesAnnotator co-stub
edu.stanford.nlp.pipeline.CleanXmlAnnotator co-stub
edu.stanford.nlp.pipeline.MorphaAnnotator co-stub
edu.stanford.nlp.pipeline.NERCombinerAnnotator  co-stub
edu.stanford.nlp.pipeline.RegexNERAnnotator co-stub
edu.stanford.nlp.pipeline.TrueCaseAnnotator co-stub
edu.stanford.nlp.pipeline.ParserAnnotator co-stub
edu.stanford.nlp.pipeline.DeterministicCorefAnnotator co-stub
)

neither quoted version nor the back-quoted version work...The former
throws :
ClassCastException clojure.lang.PersistentList cannot be cast to
java.lang.Class  clojure.core/implements? (core_deftype.clj:512)

and the latter throws:

ClassCastException clojure.lang.Cons cannot be cast to
java.lang.Class
clojure.core/implements? (core_deftype.clj:512)

any macro-gurus around?

Jim

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.




--
--
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: creating code stubs to use inside an extend-protocol form

[Tim Reinke]

Coincidentally, I just found this in 
clojure/core/protocols.clj
 (not 
that this is necessarily the best way to do this):

(def arr-impl
  '(internal-reduce
   [a-seq f val]
   (let [arr (.array a-seq)]
 (loop [i (.index a-seq)
val val]
   (if (< i (alength arr))
 (let [ret (f val (aget arr i))]
(if (reduced? ret)
  @ret
  (recur (inc i) ret)))
 val)

(defn- emit-array-impls*
  [syms]
  (apply
   concat
   (map
(fn [s]
  [(symbol (str "clojure.lang.ArraySeq$ArraySeq_" s))
   arr-impl])
syms)))

(defmacro emit-array-impls
  [& syms]
  `(extend-protocol InternalReduce
 ~@(emit-array-impls* syms)))

(emit-array-impls int long float double byte char boolean)
On Saturday, February 23, 2013 4:03:02 AM UTC-8, Jim foo.bar wrote:
>
> I seem to be unable to quote a form and then repeatedly pass it inside 
> the extend-protocol macro...something like this: 
>
> (def ^:private co-stub 
> '(run [this ^String text] 
> (let [ann (edu.stanford.nlp.pipeline.Annotation. text)] 
>   (.annotate this ann) ann))) 
>
>
> (extend-protocol IComponent 
> edu.stanford.nlp.pipeline.POSTaggerAnnotator  co-stub 
> edu.stanford.nlp.pipeline.PTBTokenizerAnnotator   co-stub 
> edu.stanford.nlp.pipeline.WordsToSentencesAnnotator co-stub 
> edu.stanford.nlp.pipeline.CleanXmlAnnotator   co-stub 
> edu.stanford.nlp.pipeline.MorphaAnnotator co-stub 
> edu.stanford.nlp.pipeline.NERCombinerAnnotatorco-stub 
> edu.stanford.nlp.pipeline.RegexNERAnnotator   co-stub 
> edu.stanford.nlp.pipeline.TrueCaseAnnotator   co-stub 
> edu.stanford.nlp.pipeline.ParserAnnotator co-stub 
> edu.stanford.nlp.pipeline.DeterministicCorefAnnotator co-stub 
> ) 
>
> neither quoted version nor the back-quoted version work...The former 
> throws : 
> ClassCastException clojure.lang.PersistentList cannot be cast to 
> java.lang.Class  clojure.core/implements? (core_deftype.clj:512) 
>
> and the latter throws: 
>
> ClassCastException clojure.lang.Cons cannot be cast to java.lang.Class   
> clojure.core/implements? (core_deftype.clj:512) 
>
> any macro-gurus around? 
>
> Jim 
>

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