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

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

Re: suggest to have defn/new/throw/etc.. allow evaluating ...maybe?

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

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

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 col

Re: Clojure Performance For Expensive Algorithms

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 progra

Re: Clojure Performance For Expensive Algorithms

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 program

Are symbols ending with ':' allowed or not?

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 charac

Re: Clojure Performance For Expensive Algorithms

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 w

Re: Clojure Performance For Expensive Algorithms

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 "

Re: Clojure Performance For Expensive Algorithms

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

Re: Clojure Performance For Expensive Algorithms

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 combinati

Re: Clojure Performance For Expensive Algorithms

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

Re: Clojure Performance For Expensive Algorithms

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

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

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 subscr

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

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

Re: Clojure Performance For Expensive Algorithms

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 w

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

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

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

~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] (ev

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

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 s

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

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 c

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

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] `(

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

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 li

Re: Clojure Performance For Expensive Algorithms

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

Re: Clojure Performance For Expensive Algorithms

> 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

Re: Clojure Performance For Expensive Algorithms

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

attaching doc-string from macro is driving me insane!

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)) ;;thi

Re: Clojure Performance For Expensive Algorithms

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

Re: Clojure Performance For Expensive Algorithms

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

Re: Clojure Performance For Expensive Algorithms

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

Re: Clojure Performance For Expensive Algorithms

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 fo

Re: Clojure Performance For Expensive Algorithms

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

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

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 assum

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

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