Re: Crazy Need: Embed JavaScript Structure in Clojure

[Gary Verhaegen]

On 28 April 2015 at 07:39, Atamert Ölçgen  wrote:
> Perhaps you can write a function that builds a function somewhere and then
> outputs a string containing JavaScript code that invokes it.
>
> (defn js [& body]
>   (eval `(defn fn-name# [] ~@body))
>   (str "function() { your.ns." fn-name# "(); }"))

If the goal is to send this code to a database to be evaluated there,
I do not think this would work, as the function is only defined within
Clojure.

@OP: as you admit that this is a crazy need, here is a crazy solution:
use the ClojureScript compiler directly within your Clojure code. I'm
not familiar with it at all; after a quick glance at the Himera source
code, here is a "proof of concept":

--

$ lein try org.clojure/clojurescript "0.0-3211"
nREPL server started on port 52299 on host 127.0.0.1 - nrepl://127.0.0.1:52299
REPL-y 0.3.5, nREPL 0.2.6
Clojure 1.6.0
Java HotSpot(TM) 64-Bit Server VM 1.8.0_25-b17
Docs: (doc function-name-here)
  (find-doc "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
 Results: Stored in vars *1, *2, *3, an exception in *e

user=> (require '[cljs.compiler :as comp])
nil
user=> (require '[cljs.analyzer :as ana])
nil
user=> (comp/emit-str (ana/analyze {:uses #{'cljs.core}} '(fn []
(js/alert "hello"
"(function (){\nreturn alert(\"hello\");\n});\n"
user=>

--

The first argument to analyze is the environment; you'll probably have
to dig a little deeper into the ClojureScript compiler to decide what
to pass there. This should allow you to create a macro that let you
write ClojureScript code directly:

{:some-key :some-value,
 :action  (js-macro (fn []
  (js/console.log "pretty crappy transaction")
  (js/console.log "another line")))}

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

Re: Performance of defmulti in both ClojureScript and Clojure

[Timur Sungur]

Thanks everyone for their answers and extra efforts. They are really
helpful.

On Mon, Apr 27, 2015, 18:56 Alex Miller  wrote:

> I fleshed out some of this a bit more in a blog post with perf numbers in
> case anyone's interested:
>
> http://insideclojure.org/2015/04/27/poly-perf/
>
>
> On Saturday, April 25, 2015 at 9:39:06 PM UTC-5, Alex Miller wrote:
>
>> On Saturday, April 25, 2015 at 9:33:18 AM UTC-5, Timur wrote:
>>>
>>> Hi everyone,
>>>
>>> There are situations where I want to dispatch functions using based on
>>> their certain properties. I can also use case statements instead but it
>>> looks more coupled and more change is required if I want to add new types.
>>>
>>
>> case is useful for the particular situation where you have a finite set
>> of compile-time constants that you are looking for (integers, characters,
>> etc). Then case will leverage a special JVM bytecode that performs a
>> *constant-time* look-up (not linear-time like checking a series of cond
>> conditions, etc). This is one of the two bytecode options (tableswitch,
>> rather than lookupswitch) underlying the Java switch/case feature.
>>
>> What I want to ask is if I need to avoid using multi-methods for
>>> performance reasons? I read somewhere that they are not really fast but the
>>> posts were old and the performance might have been improved in between.
>>> Should I favor case and cond branches instead of defmulti when I need
>>> performance?
>>>
>>
>> multimethods are slower than protocols - they must effectively invoke the
>> dispatch function, perform a linear search for a match across the cases,
>> and then invoke the actual implementation function. Protocols leverage JVM
>> internals to select the right implementation, then invoke it. However, the
>> search part of multimethods is cached, making that step fast after the
>> initial call. The last time I benchmarked multimethods with class dispatch
>> vs protocols on Java 1.8 + Clojure 1.7 alphas (can't remember which one), I
>> found multimethods were about 5x slower.
>>
>> If you want fastest type-based dispatch with open extension, then
>> protocols are the best.
>> If you want any other type of dispatch with open extension, then
>> multimethods are the best.
>> If you want a closed system of constant choices, then case is best
>> (constant-time lookup!)
>> If you want a closed system of arbitrary conditions, then cond is best.
>>
>> I have never compared the performance of cond vs multimethods for
>> something like this. My guess is that multimethods are faster as they
>> evaluate a single condition, then do a table lookup once cached vs
>> evaluating a series of conditions every time.
>>
>> Alex
>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/7oROqb6dGSU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Crazy Need: Embed JavaScript Structure in Clojure

[Atamert Ölçgen]

On Tue, Apr 28, 2015 at 10:44 AM, Gary Verhaegen 
wrote:

> On 28 April 2015 at 07:39, Atamert Ölçgen  wrote:
> > Perhaps you can write a function that builds a function somewhere and
> then
> > outputs a string containing JavaScript code that invokes it.
> >
> > (defn js [& body]
> >   (eval `(defn fn-name# [] ~@body))
> >   (str "function() { your.ns." fn-name# "(); }"))
>
> If the goal is to send this code to a database to be evaluated there,
> I do not think this would work, as the function is only defined within
> Clojure.
>

You are right. Now that I've read OP more carefully; I think exploring your
idea is really worth it, since it would allow the consumers of this library
to
write their transactions in ClojureScript instead of JavaScript.


>
> @OP: as you admit that this is a crazy need, here is a crazy solution:
> use the ClojureScript compiler directly within your Clojure code. I'm
> not familiar with it at all; after a quick glance at the Himera source
> code, here is a "proof of concept":
>
> --
>
> $ lein try org.clojure/clojurescript "0.0-3211"
> nREPL server started on port 52299 on host 127.0.0.1 - nrepl://
> 127.0.0.1:52299
> REPL-y 0.3.5, nREPL 0.2.6
> Clojure 1.6.0
> Java HotSpot(TM) 64-Bit Server VM 1.8.0_25-b17
> Docs: (doc function-name-here)
>   (find-doc "part-of-name-here")
>   Source: (source function-name-here)
>  Javadoc: (javadoc java-object-or-class-here)
> Exit: Control+D or (exit) or (quit)
>  Results: Stored in vars *1, *2, *3, an exception in *e
>
> user=> (require '[cljs.compiler :as comp])
> nil
> user=> (require '[cljs.analyzer :as ana])
> nil
> user=> (comp/emit-str (ana/analyze {:uses #{'cljs.core}} '(fn []
> (js/alert "hello"
> "(function (){\nreturn alert(\"hello\");\n});\n"
> user=>
>
> --
>
> The first argument to analyze is the environment; you'll probably have
> to dig a little deeper into the ClojureScript compiler to decide what
> to pass there. This should allow you to create a macro that let you
> write ClojureScript code directly:
>
> {:some-key :some-value,
>  :action  (js-macro (fn []
>   (js/console.log "pretty crappy transaction")
>   (js/console.log "another line")))}
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Kind Regards,
Atamert Ölçgen

◻◼◻
◻◻◼
◼◼◼

www.muhuk.com
www.olcgen.com

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

[ANN] Bolth: a humane, parallelized test runner for clojure.test

[tcrayford]

Hi there,

I've written a new test runner for clojure.test. It does 2 main new things: 
parallelization, and *much* better output, error reporting, and some 
surrounding formatting/running features.

All the features were extracted from stuff I've accumulated in my app's 
user namespace over the last year or so in an effort to improve my own 
development experience.

1. Much improved output

bolth uses the same output format as humane-test-output: it diff's data 
structures passed to = and reports the difference when reporting failing 
tests. This is a huge win for testing things in larger data structures 
(especially maps), it just tells you "yo, this key is different", not "yo 
this 30 line data structure isn't equal to the other one".

It uses aviso/pretty to pretty print exception stacktraces, removing a 
bunch of the noise, making them the right way up (i.e. latest frame at the 
bottom so you don't have to scroll up all the time to find the error 
message/causing frame). There's also a tiny tools.namespace wrapper that 
lets you invoke tools.namespace and get pretty exceptions printed out 
rather than the usual garbage from the compiler.

It can report the slowest N tests in the test suite, so you can debug why 
your test suite is slow easily (suites I've tried it on usually have test 
runtime dominated by a few tests, that can often be improved without too 
much effort).

It reports the number of tests run, and the runtime per test, which can 
give you a goal (I typically get about 0.25ms or so per test in my app).

It can clear the screen, which is useful for outputting to a repl, because 
you remove the noise from other test failures (see the gifs in the post for 
what that looks like).

It can call `System/exit` with an good exit code based on if the tests 
passed or not (this is off by default, because you'll only really want it 
in CI, definitely not in a repl). This stops you writing that wrapper once 
again.

2. Parallelization of test runs

Bolth parallelizes test runs. This means it's only suitable for test suites 
where each test is completely isolated from the others (the easiest way to 
achieve this is having a test suite that's purely in memory, but it's 
possible to isolate databases as well, just not a thing I've done).

You can read more about it 
here: http://yellerapp.com/posts/2015-04-23-bolth.html

Enjoy!

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

Re: complex numbers in clojure

[Nik]

It does seem as though there is no way to meet all the criteria, unless the 
support for it comes from Java/Oracle. That said, I feel like having a 
complex type with reasonable performance is better than having nothing at 
all. 

What I would like is a complex type that plays well with Clojure's generic 
abstractions and functional style (much like Ratio), and is 
indistinguishable from other types - for example, the ability to work with 
(map/reduce/filter), the ability to be a part of seqs and use Clojure core 
functions on it, and so on. It might not as efficient as the complex type 
in, say C++, but depending on your definition of reasonable, it might be 
acceptable. I am willing to explore this further. 

Alex, would opening up the type system as you pointed be a way to go?

Also, I am not sure is this is possible for us to accomplish, but some 
academic work has been done where a Java complex class has been created, 
and through the use of semantic expansion, it has very high performance.
PDF 
Link: 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.42.7264&rep=rep1&type=pdf






On Tuesday, April 28, 2015 at 12:22:08 AM UTC-4, Mikera wrote:
>
> Complex numbers are tricky because:
> - They need to be fast in order to be useful for numerical computing. The 
> "obvious" implementations that you might create with boxed values, 
> vectors/maps, multimethods and protocols are likely to be unacceptable for 
> many use cases
> - You still want to be able to use them in a generic way, with operations 
> that play nicely with other values (Doubles etc.)
>
> I have thought about this a lot w.r.t. core.matrix and have come to the 
> conclusion that there is no simple, elegant answer that meets all use cases.
>
> What I'd like to suggest is:
> a) The community converge on a single, minimal, lightweight representation 
> for a boxed complex scalar value. This is probably best as a Java class 
> (for easy interop with Java libraries). I think 
> http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/complex/Complex.html
>  
> is a good candidate
> b) A lightweight wrapper library that provides nice complex functions in 
> Clojure, using the above type. Nothing fancy. But can make extensive use of 
> type hints etc. for performance so should be pretty fast
> c) A library using core.matrix that implements complex vectors, complex 
> matrices etc but also uses a) for complex scalar values. This should use a 
> underlying double-array backed implementation for performance, probably 
> vectorz-clj would be best (though that could be hidden as an implementation 
> detail). This library would also implement all the core.matrix protocols 
> for the chosen complex number type, mostly just by calling b) directly
>
>
> On Monday, 27 April 2015 23:39:34 UTC+8, Nik wrote:
>>
>> I have been thinking along the lines of mikera and Maik - and it seems 
>> like there is no further progress here? I would like to take a crack at 
>> creating a complex number type, but implemented as a library to Clojure. I 
>> am not sure where to start, and if anyone here has suggestions, I'd be 
>> happy to hear them. 
>>
>> A complex number could simply be a vector of two elements, or a map with 
>> :real and :imag keys (or something lightweight) - and I am not sure what it 
>> would require to make this type work happily with code arithmetic functions 
>> in Clojure and Java Math. 
>>
>> It would also have to work with seq operations in Clojure - for instance: 
>> If I have a complex number c = {:real 3 :imag 4}, and a vector v = [1 -2 
>> c], it would be nice to have the call 'map #(Math/abs %) v' produce (1 2 
>> 5). 
>>
>> I am having trouble figuring out all the pieces that need to be 
>> implemented. Is it even possible to implement this as a library, or does 
>> this need to be a part of clojure.core?
>>
>

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

Re: complex numbers in clojure

[Gary Verhaegen]

Your messages are a bit confusing. Playing nice with collection functions
would depend on the collection, not on its contents.

Maybe you could elaborate a bit more on what you're trying to accomplish?

If you do not care about performance, you need to decide whether you want
your type to work with clojure.core arithmetic operators, which from Alex's
comments would seem to require modifying Clojure itself, or if it would be
acceptable to you to define your own operators in your own namespace (which
could check the type and default to the clojure.core versions, providing
some transparency in exchange for some performance). Of course, you then
have to worry about other functions that maybe call clojure.core operators
indirectly, and the bahavior of functions such as min and max.

On Tuesday, 28 April 2015, Nik  wrote:

> It does seem as though there is no way to meet all the criteria, unless
> the support for it comes from Java/Oracle. That said, I feel like having a
> complex type with reasonable performance is better than having nothing at
> all.
>
> What I would like is a complex type that plays well with Clojure's generic
> abstractions and functional style (much like Ratio), and is
> indistinguishable from other types - for example, the ability to work with
> (map/reduce/filter), the ability to be a part of seqs and use Clojure core
> functions on it, and so on. It might not as efficient as the complex type
> in, say C++, but depending on your definition of reasonable, it might be
> acceptable. I am willing to explore this further.
>
> Alex, would opening up the type system as you pointed be a way to go?
>
> Also, I am not sure is this is possible for us to accomplish, but some
> academic work has been done where a Java complex class has been created,
> and through the use of semantic expansion, it has very high performance.
> PDF Link:
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.42.7264&rep=rep1&type=pdf
>
>
>
>
>
>
> On Tuesday, April 28, 2015 at 12:22:08 AM UTC-4, Mikera wrote:
>>
>> Complex numbers are tricky because:
>> - They need to be fast in order to be useful for numerical computing. The
>> "obvious" implementations that you might create with boxed values,
>> vectors/maps, multimethods and protocols are likely to be unacceptable for
>> many use cases
>> - You still want to be able to use them in a generic way, with operations
>> that play nicely with other values (Doubles etc.)
>>
>> I have thought about this a lot w.r.t. core.matrix and have come to the
>> conclusion that there is no simple, elegant answer that meets all use cases.
>>
>> What I'd like to suggest is:
>> a) The community converge on a single, minimal, lightweight
>> representation for a boxed complex scalar value. This is probably best as a
>> Java class (for easy interop with Java libraries). I think
>> http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/complex/Complex.html
>> is a good candidate
>> b) A lightweight wrapper library that provides nice complex functions in
>> Clojure, using the above type. Nothing fancy. But can make extensive use of
>> type hints etc. for performance so should be pretty fast
>> c) A library using core.matrix that implements complex vectors, complex
>> matrices etc but also uses a) for complex scalar values. This should use a
>> underlying double-array backed implementation for performance, probably
>> vectorz-clj would be best (though that could be hidden as an implementation
>> detail). This library would also implement all the core.matrix protocols
>> for the chosen complex number type, mostly just by calling b) directly
>>
>>
>> On Monday, 27 April 2015 23:39:34 UTC+8, Nik wrote:
>>>
>>> I have been thinking along the lines of mikera and Maik - and it seems
>>> like there is no further progress here? I would like to take a crack at
>>> creating a complex number type, but implemented as a library to Clojure. I
>>> am not sure where to start, and if anyone here has suggestions, I'd be
>>> happy to hear them.
>>>
>>> A complex number could simply be a vector of two elements, or a map with
>>> :real and :imag keys (or something lightweight) - and I am not sure what it
>>> would require to make this type work happily with code arithmetic functions
>>> in Clojure and Java Math.
>>>
>>> It would also have to work with seq operations in Clojure - for
>>> instance:
>>> If I have a complex number c = {:real 3 :imag 4}, and a vector v = [1 -2
>>> c], it would be nice to have the call 'map #(Math/abs %) v' produce (1 2
>>> 5).
>>>
>>> I am having trouble figuring out all the pieces that need to be
>>> implemented. Is it even possible to implement this as a library, or does
>>> this need to be a part of clojure.core?
>>>
>>  --
> 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
> 

Re: complex numbers in clojure

[Plínio Balduino]

My two cents:

I started to develop some support to complex numbers in Clojure, but I
don't know if the Core Team/Rich Hickey has any intererest in this subject.

Even it's an unfinished work, I didn't notice any lost of performance so
far.

Regards

Plínio Balduino

On Tue, Apr 28, 2015 at 9:35 AM, Gary Verhaegen 
wrote:

> Your messages are a bit confusing. Playing nice with collection functions
> would depend on the collection, not on its contents.
>
> Maybe you could elaborate a bit more on what you're trying to accomplish?
>
> If you do not care about performance, you need to decide whether you want
> your type to work with clojure.core arithmetic operators, which from Alex's
> comments would seem to require modifying Clojure itself, or if it would be
> acceptable to you to define your own operators in your own namespace (which
> could check the type and default to the clojure.core versions, providing
> some transparency in exchange for some performance). Of course, you then
> have to worry about other functions that maybe call clojure.core operators
> indirectly, and the bahavior of functions such as min and max.
>
>
> On Tuesday, 28 April 2015, Nik  wrote:
>
>> It does seem as though there is no way to meet all the criteria, unless
>> the support for it comes from Java/Oracle. That said, I feel like having a
>> complex type with reasonable performance is better than having nothing at
>> all.
>>
>> What I would like is a complex type that plays well with Clojure's
>> generic abstractions and functional style (much like Ratio), and is
>> indistinguishable from other types - for example, the ability to work with
>> (map/reduce/filter), the ability to be a part of seqs and use Clojure core
>> functions on it, and so on. It might not as efficient as the complex type
>> in, say C++, but depending on your definition of reasonable, it might be
>> acceptable. I am willing to explore this further.
>>
>> Alex, would opening up the type system as you pointed be a way to go?
>>
>> Also, I am not sure is this is possible for us to accomplish, but some
>> academic work has been done where a Java complex class has been created,
>> and through the use of semantic expansion, it has very high performance.
>> PDF Link:
>> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.42.7264&rep=rep1&type=pdf
>>
>>
>>
>>
>>
>>
>> On Tuesday, April 28, 2015 at 12:22:08 AM UTC-4, Mikera wrote:
>>>
>>> Complex numbers are tricky because:
>>> - They need to be fast in order to be useful for numerical computing.
>>> The "obvious" implementations that you might create with boxed values,
>>> vectors/maps, multimethods and protocols are likely to be unacceptable for
>>> many use cases
>>> - You still want to be able to use them in a generic way, with
>>> operations that play nicely with other values (Doubles etc.)
>>>
>>> I have thought about this a lot w.r.t. core.matrix and have come to the
>>> conclusion that there is no simple, elegant answer that meets all use cases.
>>>
>>> What I'd like to suggest is:
>>> a) The community converge on a single, minimal, lightweight
>>> representation for a boxed complex scalar value. This is probably best as a
>>> Java class (for easy interop with Java libraries). I think
>>> http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/complex/Complex.html
>>> is a good candidate
>>> b) A lightweight wrapper library that provides nice complex functions in
>>> Clojure, using the above type. Nothing fancy. But can make extensive use of
>>> type hints etc. for performance so should be pretty fast
>>> c) A library using core.matrix that implements complex vectors, complex
>>> matrices etc but also uses a) for complex scalar values. This should use a
>>> underlying double-array backed implementation for performance, probably
>>> vectorz-clj would be best (though that could be hidden as an implementation
>>> detail). This library would also implement all the core.matrix protocols
>>> for the chosen complex number type, mostly just by calling b) directly
>>>
>>>
>>> On Monday, 27 April 2015 23:39:34 UTC+8, Nik wrote:

 I have been thinking along the lines of mikera and Maik - and it seems
 like there is no further progress here? I would like to take a crack at
 creating a complex number type, but implemented as a library to Clojure. I
 am not sure where to start, and if anyone here has suggestions, I'd be
 happy to hear them.

 A complex number could simply be a vector of two elements, or a map
 with :real and :imag keys (or something lightweight) - and I am not sure
 what it would require to make this type work happily with code arithmetic
 functions in Clojure and Java Math.

 It would also have to work with seq operations in Clojure - for
 instance:
 If I have a complex number c = {:real 3 :imag 4}, and a vector v = [1
 -2 c], it would be nice to have the call 'map #(Math/abs %) v' produce (1 2
 5).

 I a

Re: [ANN] Bolth: a humane, parallelized test runner for clojure.test

[James Reeves]

This library is pretty interesting, but you might want to change the
single-segment namespace you have. A single-part namespace is compiled as a
bare class without an associated package, and this can result in issues
around Java interop and AOT compilation. While a single-segment namespace
is likely to be okay in most circumstances, the edge cases that crop up
mean it's use is generally discouraged. A `bolth.test` namespace might be
more suitable.

- James

On 28 April 2015 at 09:38, tcrayford  wrote:

> Hi there,
>
> I've written a new test runner for clojure.test. It does 2 main new
> things: parallelization, and *much* better output, error reporting, and
> some surrounding formatting/running features.
>
> All the features were extracted from stuff I've accumulated in my app's
> user namespace over the last year or so in an effort to improve my own
> development experience.
>
> 1. Much improved output
>
> bolth uses the same output format as humane-test-output: it diff's data
> structures passed to = and reports the difference when reporting failing
> tests. This is a huge win for testing things in larger data structures
> (especially maps), it just tells you "yo, this key is different", not "yo
> this 30 line data structure isn't equal to the other one".
>
> It uses aviso/pretty to pretty print exception stacktraces, removing a
> bunch of the noise, making them the right way up (i.e. latest frame at the
> bottom so you don't have to scroll up all the time to find the error
> message/causing frame). There's also a tiny tools.namespace wrapper that
> lets you invoke tools.namespace and get pretty exceptions printed out
> rather than the usual garbage from the compiler.
>
> It can report the slowest N tests in the test suite, so you can debug why
> your test suite is slow easily (suites I've tried it on usually have test
> runtime dominated by a few tests, that can often be improved without too
> much effort).
>
> It reports the number of tests run, and the runtime per test, which can
> give you a goal (I typically get about 0.25ms or so per test in my app).
>
> It can clear the screen, which is useful for outputting to a repl, because
> you remove the noise from other test failures (see the gifs in the post for
> what that looks like).
>
> It can call `System/exit` with an good exit code based on if the tests
> passed or not (this is off by default, because you'll only really want it
> in CI, definitely not in a repl). This stops you writing that wrapper once
> again.
>
> 2. Parallelization of test runs
>
> Bolth parallelizes test runs. This means it's only suitable for test
> suites where each test is completely isolated from the others (the easiest
> way to achieve this is having a test suite that's purely in memory, but
> it's possible to isolate databases as well, just not a thing I've done).
>
> You can read more about it here:
> http://yellerapp.com/posts/2015-04-23-bolth.html
>
> Enjoy!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: complex numbers in clojure

[Nik]

To put is simply, it would be nice to have a complex type in Clojure, not 
as a separate namespace, but something that is part of the language. It 
should interoperate with other Clojure types (like adding a double to a 
complex), as well as clojure.core.arithmetic. That's what I meant about 
playing nicely with collections - it should not matter that there is a 
complex type in a collection. The arithmetic operations on collections 
should work regardless. Sorry for the confusion. I will spend some time 
looking into the modifications needed to clojure.core to accomplish this.

I could be wrong but it seemed to me that Alex was suggesting there might 
be a way to open up the type system so that others can add types "easily". 

Also, I didn't mean to imply that I don't care about performance. It does 
matter, but if Clojure doesn't have Fortran-like speeds, then that is fine 
with me. Unfortunately, at this point I can't be more specific about 
performance - in either absolute or relative terms.


On Tuesday, April 28, 2015 at 8:35:39 AM UTC-4, Gary Verhaegen wrote:
>
> Your messages are a bit confusing. Playing nice with collection functions 
> would depend on the collection, not on its contents.
>
> Maybe you could elaborate a bit more on what you're trying to accomplish?
>
> If you do not care about performance, you need to decide whether you want 
> your type to work with clojure.core arithmetic operators, which from Alex's 
> comments would seem to require modifying Clojure itself, or if it would be 
> acceptable to you to define your own operators in your own namespace (which 
> could check the type and default to the clojure.core versions, providing 
> some transparency in exchange for some performance). Of course, you then 
> have to worry about other functions that maybe call clojure.core operators 
> indirectly, and the bahavior of functions such as min and max.
>
>>
>>  

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

Re: complex numbers in clojure

[Andy Fingerhut]

Most of Clojure's collections already can hold arbitrary type values inside
of them, with no additional work required, whether those types are built
into Clojure or not.  That is because most collections treat all contained
items as Java Object references.

The only exceptions I can think of are the few Clojure data structures that
were developed to save memory, and perhaps also improve performance, by
avoiding the Object references and holding Java primitive types directly,
e.g. (vector-of :int 1 2 3)

The tricky part is not that, but getting a new number type to be operated
upon by existing Clojure math operators like + - * /

Andy

On Tue, Apr 28, 2015 at 7:20 AM, Nik  wrote:

> To put is simply, it would be nice to have a complex type in Clojure, not
> as a separate namespace, but something that is part of the language. It
> should interoperate with other Clojure types (like adding a double to a
> complex), as well as clojure.core.arithmetic. That's what I meant about
> playing nicely with collections - it should not matter that there is a
> complex type in a collection. The arithmetic operations on collections
> should work regardless. Sorry for the confusion. I will spend some time
> looking into the modifications needed to clojure.core to accomplish this.
>
> I could be wrong but it seemed to me that Alex was suggesting there might
> be a way to open up the type system so that others can add types "easily".
>
> Also, I didn't mean to imply that I don't care about performance. It does
> matter, but if Clojure doesn't have Fortran-like speeds, then that is fine
> with me. Unfortunately, at this point I can't be more specific about
> performance - in either absolute or relative terms.
>
>
> On Tuesday, April 28, 2015 at 8:35:39 AM UTC-4, Gary Verhaegen wrote:
>>
>> Your messages are a bit confusing. Playing nice with collection functions
>> would depend on the collection, not on its contents.
>>
>> Maybe you could elaborate a bit more on what you're trying to accomplish?
>>
>> If you do not care about performance, you need to decide whether you want
>> your type to work with clojure.core arithmetic operators, which from Alex's
>> comments would seem to require modifying Clojure itself, or if it would be
>> acceptable to you to define your own operators in your own namespace (which
>> could check the type and default to the clojure.core versions, providing
>> some transparency in exchange for some performance). Of course, you then
>> have to worry about other functions that maybe call clojure.core operators
>> indirectly, and the bahavior of functions such as min and max.
>>
>>>
>>>   --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: complex numbers in clojure

[Plínio Balduino]

Not that tricky, really. But there's a lot of repetitive work.

I changed the Clojure readers to understand the a+bi format, created a
ComplexNumber class and changed the class on charge of arithmetic to work
with complex numbers.

So it's possible to make any operation mixing Numbers, Ratios and
ComplexNumbers.

Plínio

On Tue, Apr 28, 2015 at 11:56 AM, Andy Fingerhut 
wrote:

> Most of Clojure's collections already can hold arbitrary type values
> inside of them, with no additional work required, whether those types are
> built into Clojure or not.  That is because most collections treat all
> contained items as Java Object references.
>
> The only exceptions I can think of are the few Clojure data structures
> that were developed to save memory, and perhaps also improve performance,
> by avoiding the Object references and holding Java primitive types
> directly, e.g. (vector-of :int 1 2 3)
>
> The tricky part is not that, but getting a new number type to be operated
> upon by existing Clojure math operators like + - * /
>
> Andy
>
> On Tue, Apr 28, 2015 at 7:20 AM, Nik  wrote:
>
>> To put is simply, it would be nice to have a complex type in Clojure, not
>> as a separate namespace, but something that is part of the language. It
>> should interoperate with other Clojure types (like adding a double to a
>> complex), as well as clojure.core.arithmetic. That's what I meant about
>> playing nicely with collections - it should not matter that there is a
>> complex type in a collection. The arithmetic operations on collections
>> should work regardless. Sorry for the confusion. I will spend some time
>> looking into the modifications needed to clojure.core to accomplish this.
>>
>> I could be wrong but it seemed to me that Alex was suggesting there might
>> be a way to open up the type system so that others can add types "easily".
>>
>> Also, I didn't mean to imply that I don't care about performance. It does
>> matter, but if Clojure doesn't have Fortran-like speeds, then that is fine
>> with me. Unfortunately, at this point I can't be more specific about
>> performance - in either absolute or relative terms.
>>
>>
>> On Tuesday, April 28, 2015 at 8:35:39 AM UTC-4, Gary Verhaegen wrote:
>>>
>>> Your messages are a bit confusing. Playing nice with collection
>>> functions would depend on the collection, not on its contents.
>>>
>>> Maybe you could elaborate a bit more on what you're trying to accomplish?
>>>
>>> If you do not care about performance, you need to decide whether you
>>> want your type to work with clojure.core arithmetic operators, which from
>>> Alex's comments would seem to require modifying Clojure itself, or if it
>>> would be acceptable to you to define your own operators in your own
>>> namespace (which could check the type and default to the clojure.core
>>> versions, providing some transparency in exchange for some performance). Of
>>> course, you then have to worry about other functions that maybe call
>>> clojure.core operators indirectly, and the bahavior of functions such as
>>> min and max.
>>>

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

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

Question about Clojure codebase

[Jonathon McKitrick]

What would you say is the most complex, hard-to-grok code in Clojure 
codebase?

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

[ANN] clj-try : Clojure Try / Error macros.

[Martin Cooper]

clj-try : Clojure Try / Error macros 0.1.0 is now available.

https://github.com/martincooper/clj-try

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

Clojure community organisation

[Daniel Solano Gómez]

Hello, all,

I've brought up the idea of some sort of Clojure community organisation
a few times on this mailing list.  The ideas is to help grow the Clojure
community by doing things like supporting GSoC students, run
infrastructure like Clojars, help run conferences, etc.  I have decided
to start moving forward and apply for fiscal sponsorship from the
Software Freedom Conservancy and Software in the Public Interest.  Those
things take time to work themselves out.  In the meantime, I appreciate
any input/feedback about what this org should do or what it should look
like.  As such, I have posted a page on the community wiki to start
braainstorming and discussing ideas
.

A big thank you to everyone.  Participating in this community has been a
very positive experience for me, and I would love to see it to continue
to flourish.  I appreciate any help or advice on how to make this
initiative succeed in supporting the community.

Sincerely,

Daniel

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

ClassNotFoundException using try inside core.async go block

[Chap Lovejoy]

I'm running into a strange exception trying to handle exceptions within a 
go block. So far this is the simplest test case I've gotten to fail:

(ns test-async
  (require [clojure.core.async :refer [go >!]
:as async]))


(defn test-chan
  [chan]
  (go
(try
  (>! chan)
  (catch Throwable ex
ex


Requiring the namespace results in the following error:
user=> (require 'test-async :reload)
CompilerException java.lang.RuntimeException: Unable to resolve symbol: 
test-async in this context, compiling:(test_async.clj:7:3)


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

Re: Question about Clojure codebase

[Renzo Borgatti]

Many choices….

We can start from BitmapIndexedNode assoc:

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/PersistentHashMap.java#L686

although you might argue that if you read 
http://lampwww.epfl.ch/papers/idealhashtrees.pdf you know what’s in there. So 
maybe a classic FnExpr.parse():

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L3860

with all the complexity of parsing a function expression. Or maybe more some 
hardcore concurrency stuff from the STM:

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LockingTransaction.java#L256

that also according to blame is basically untouched since 2009. Impression of 
complexity is subjective though, someone else could give different answers.

Renzo


> On 28 Apr 2015, at 17:57, Jonathon McKitrick  wrote:
> 
> What would you say is the most complex, hard-to-grok code in Clojure codebase?
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: Question about Clojure codebase

[Alex Miller]

Persistent collections, STM, and the compiler are all deep veins. One may 
also muse on how these were also some of the earliest things in Clojure.

On Tuesday, April 28, 2015 at 6:04:48 PM UTC-5, Renzo Borgatti wrote:
>
> Many choices…. 
>
> We can start from BitmapIndexedNode assoc: 
>
>
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/PersistentHashMap.java#L686
>  
>
> although you might argue that if you read 
> http://lampwww.epfl.ch/papers/idealhashtrees.pdf you know what’s in 
> there. So maybe a classic FnExpr.parse(): 
>
>
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L3860
>  
>
> with all the complexity of parsing a function expression. Or maybe more 
> some hardcore concurrency stuff from the STM: 
>
>
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LockingTransaction.java#L256
>  
>
> that also according to blame is basically untouched since 2009. Impression 
> of complexity is subjective though, someone else could give different 
> answers. 
>
> Renzo 
>
>
> > On 28 Apr 2015, at 17:57, Jonathon McKitrick  > wrote: 
> > 
> > What would you say is the most complex, hard-to-grok code in Clojure 
> codebase? 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

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

Re: ClassNotFoundException using try inside core.async go block

[Alex Miller]

I think this is a bug in the fairly old tools.analyzer version used in the 
latest released version. That's actually been updated for the next release 
and does not seem reproducible to me there. 


On Tuesday, April 28, 2015 at 6:04:19 PM UTC-5, Chap Lovejoy wrote:
>
> I'm running into a strange exception trying to handle exceptions within a 
> go block. So far this is the simplest test case I've gotten to fail:
>
> (ns test-async
>   (require [clojure.core.async :refer [go >!]
> :as async]))
>
>
> (defn test-chan
>   [chan]
>   (go
> (try
>   (>! chan)
>   (catch Throwable ex
> ex
>
>
> Requiring the namespace results in the following error:
> user=> (require 'test-async :reload)
> CompilerException java.lang.RuntimeException: Unable to resolve symbol: 
> test-async in this context, compiling:(test_async.clj:7:3)
>
>
> Using either >! or  it go away. Is there something I'm missing here? I'm using the latest 
> (0.1.346.0-17112a-alpha) version of core.async and have tried on both 1.6.0 
> and 1.7.0-beta1.
>
> Thanks,
> Chap
>
>
>
>

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

Re: complex numbers in clojure

[Mikera]

You can do virtually all of that already with the Apache commons Complex 
class. Any Java object can be just fine used with map / reduce / filter / 
seqs etc.

If you want to avoid Java interop and make things more "Clojure-like" then 
a lightweight wrapper library is all that is needed (my suggestion b) ). 
You could probably also support tagged reader literals for complex numbers 
pretty easily.

The only problem would be supporting complex types in numerical 
clojure.core/+. That is very unlikely to happen - I doubt Rich and co want 
to start adding complexity to the core functions which would hurt 
performance and break the assumptions that people have about the numerical 
functions in clojure.core. But that isn't ultimately a big problem, you can 
just use a specialised addition operator like clojure.complex/+ or 
clojure.core.matrix.operators/+ instead when you write complex-using code. 
That's part of my suggestions b) and c), basically to have separate APIs 
that understand complex types.



On Tuesday, 28 April 2015 19:42:23 UTC+8, Nik wrote:
>
> 
> What I would like is a complex type that plays well with Clojure's generic 
> abstractions and functional style (much like Ratio), and is 
> indistinguishable from other types - for example, the ability to work with 
> (map/reduce/filter), the ability to be a part of seqs and use Clojure core 
> functions on it, and so on. It might not as efficient as the complex type 
> in, say C++, but depending on your definition of reasonable, it might be 
> acceptable. I am willing to explore this further. 
> .
>
>
>
>
>
>
> On Tuesday, April 28, 2015 at 12:22:08 AM UTC-4, Mikera wrote:
>>
>> Complex numbers are tricky because:
>> - They need to be fast in order to be useful for numerical computing. The 
>> "obvious" implementations that you might create with boxed values, 
>> vectors/maps, multimethods and protocols are likely to be unacceptable for 
>> many use cases
>> - You still want to be able to use them in a generic way, with operations 
>> that play nicely with other values (Doubles etc.)
>>
>> I have thought about this a lot w.r.t. core.matrix and have come to the 
>> conclusion that there is no simple, elegant answer that meets all use cases.
>>
>> What I'd like to suggest is:
>> a) The community converge on a single, minimal, lightweight 
>> representation for a boxed complex scalar value. This is probably best as a 
>> Java class (for easy interop with Java libraries). I think 
>> http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/complex/Complex.html
>>  
>> is a good candidate
>> b) A lightweight wrapper library that provides nice complex functions in 
>> Clojure, using the above type. Nothing fancy. But can make extensive use of 
>> type hints etc. for performance so should be pretty fast
>> c) A library using core.matrix that implements complex vectors, complex 
>> matrices etc but also uses a) for complex scalar values. This should use a 
>> underlying double-array backed implementation for performance, probably 
>> vectorz-clj would be best (though that could be hidden as an implementation 
>> detail). This library would also implement all the core.matrix protocols 
>> for the chosen complex number type, mostly just by calling b) directly
>>
>>
>> On Monday, 27 April 2015 23:39:34 UTC+8, Nik wrote:
>>>
>>> I have been thinking along the lines of mikera and Maik - and it seems 
>>> like there is no further progress here? I would like to take a crack at 
>>> creating a complex number type, but implemented as a library to Clojure. I 
>>> am not sure where to start, and if anyone here has suggestions, I'd be 
>>> happy to hear them. 
>>>
>>> A complex number could simply be a vector of two elements, or a map with 
>>> :real and :imag keys (or something lightweight) - and I am not sure what it 
>>> would require to make this type work happily with code arithmetic functions 
>>> in Clojure and Java Math. 
>>>
>>> It would also have to work with seq operations in Clojure - for 
>>> instance: 
>>> If I have a complex number c = {:real 3 :imag 4}, and a vector v = [1 -2 
>>> c], it would be nice to have the call 'map #(Math/abs %) v' produce (1 2 
>>> 5). 
>>>
>>> I am having trouble figuring out all the pieces that need to be 
>>> implemented. Is it even possible to implement this as a library, or does 
>>> this need to be a part of clojure.core?
>>>
>>

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

Re: [ClojureScript] Re: [reagent] Re: [ANN] SF Reagent Meetup TODAY 6:30pm @Loyal3 @Meerkat

[simon lomax]

On Friday, 17 April 2015 16:25:34 UTC+1, Jamie Orchard-Hays  wrote:
> Excellent. I tried to watch on periscope, but it never showed up.
> 
> Jamie
> On Apr 17, 2015, at 10:20 AM, Marc Fawzi  wrote:
> 
> > yes, will post link here sometime next week
> > 
> > all 3 presentations were screen captured too so it will be very easy to 
> > follow 
> > 
> > Sent from my iPhone
> > 
> >> On Apr 17, 2015, at 7:12 AM, Jeremy Vuillermet 
> >>  wrote:
> >> 
> >> Will the event video be uploaded somewhere ? 
> >> If yes, where !? Missed the live stream unfortunately. Living in France 
> >> doesn't help ...
> >> 
> >> 
> >>> On Thursday, April 16, 2015 at 4:35:38 PM UTC+2, marc fawzi wrote:
> >>> Thursday, April 16, 2015
> >>> 6:30 PM
> >>> 
> >>> 
> >>> Loyal3
> >>> 150 California St Ste 400, San Francisco, CA (edit map)
> >>> two blocks from the Embarcadero BART on California and Front
> >>> 
> >>> SF Reagent Meetup Agenda: 
> >>> IMPORTANT: We will be streaming the event live MEERKAT @ 7:00PM PDT (GMT 
> >>> time -7 hours) today! -- Follow @marcfawzi on Twitter for live updates.
> >>> To watch on the web (non-interactive mode)
> >>> http://meerkatapp.co/marcfawzi/sch-1a612560-df50-4d13-a00c-c828eee742c9
> >>> Meerkat is available on iOS and viewers are encouraged to download the 
> >>> app (interactive mode)
> >>> https://itunes.apple.com/us/app/meerkat-tweet-live-video/id954105918?mt=8 
> >>> 
> >>> Unofficial Meerkat app for Android - made with love by Meerkat's 
> >>> engineers (interactive mode)
> >>> https://play.google.com/store/apps/details?id=co.getair.meerkat&hl=en 
> >>> 
> >>> 1. 6:30pm - 7:00pm:  
> >>> meet & greet, food and drinks, social 
> >>> 2. 7:00pm - 7:30pm: (LIVE STREAM via Meerkat)
> >>> Intro to Reagent-Template (repo: 
> >>> https://github.com/reagent-project/reagent-template) --- by its author 
> >>> Dmitri Sotnikov(also author of Luminus.) Dmitri will be presenting via 
> >>> Google hangout on a big screen and you will be able to ask him questions 
> >>> live. This should be interesting.
> >>> 
> >>> 
> >>> 3. 7:30pm - 7:45pm:  (LIVE STREAM via Meerkat)
> >>> Re-frame and Reagent port of Angular's phonecat 
> >>> (repo:https://github.com/dhruvp/angular-phonecat-re-frame) -- by its 
> >>> author Dhruv Parthasarathy (MIT) 
> >>> 
> >>> 
> >>> 
> >>> 4. 7:45-8:00pm  (LIVE STREAM via Meerkat, updated description): 
> >>> Reusable Reagent Components with App-State Driven CSS Transitions  
> >>> (watch: http://imgur.com/04OaRw3) -- by Marc Fawzi -- this live demo will 
> >>> include Learning Outcomes for smooth animations, component styling, and 
> >>> sharing the components via internal maven repo Artifactory and our 
> >>> TeamCity deploy pipeline, among other things.
> >>> 
> >>> 
> >>> A professionally produced video of the event that includes screen 
> >>> captures of on-stage and Google Hangout presentations will be shared 
> >>> within a week of the event.
> >>> 
> >>> 
> >>> SF FOLKS, HOPE TO SEE YOU IN PERSON! 
> >>> LOCAL BEER CHOICES AND SAME AWESOME PIZZAS (w/ GF/DF options)
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google Groups 
> >> "Reagent-Project" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an 
> >> email to reagent-project+unsubscr...@googlegroups.com.
> >> To post to this group, send email to reagent-proj...@googlegroups.com.
> >> Visit this group at http://groups.google.com/group/reagent-project.
> >> For more options, visit https://groups.google.com/d/optout.
> > 
> > -- 
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > --- 
> > You received this message because you are subscribed to the Google Groups 
> > "ClojureScript" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to clojurescript+unsubscr...@googlegroups.com.
> > To post to this group, send email to clojurescr...@googlegroups.com.
> > Visit this group at http://groups.google.com/group/clojurescript.

Hi,

Did the videos ever get released?

Regards,
Simon

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

How do we use a container class with a proxy?

[Elric Erkose]

How do we use a container class with a proxy?

Given the following class signature, how would we write the proxy?

```java
public abstract class FooInitializer
```

```clojure
(proxy [FooInitializer ???] []
```

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