Silence WARNING: Long already refers to: class java.lang.Long in namespace: ... in aot compile compatible way
I have a simplified scenario here: https://github.com/scizo/unmap-failure The problem is I am using ns-unmap to prevent a WARNING from being printed when shadowing java.lang.Long in a namespace. When this code is aot compiled, the namespace var referenced by 'Long is being created before the ns-unmap is being executed causing the ns-unmap to unmap the desired 'Long and not java.lang.Long. Is there a way to silence the warning in a way that will work with both aot and non-aot compiled code? Thanks for any help in advance, Scott -- 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.
Crazy Need: Embed JavaScript Structure in Clojure
Hello,
So just to get it out: I do not want to evaluate the JavaScript, simply
preserve it.
I'm working on an ArangoDB driver. Part of the wonder that is ArangoDB is
its ability to support transactions. This is done using JSON. Part of the
REST object for a transaction is what I want to do in the transaction. This
is encapsulated in the action attribute of the posted JSON object.
Here's an example
{...JSON configuration
action: function (){many lines of stuff here,
More JSON configuration}
Now the way that this works in node is by converting the function into a
String. I didn't know that String(function () {..valid JavaScript...})
would kick out a string version of the function. Pretty neat.
I want to do the same thing with Clojure. I presently take a map with one
of the attributes of :action. I want something like this.
{:some-key :some-value,
:action (js-macro function(){
console.log(pretty crappy transaction);
console.log(another line);
})}
On the other side of the macro I want to get function() {\t\t\t\n
console.log(\pretty crappy transaction\;\n\t\t\tconsole.log(\another
line\);\n} or there about.
I've got
(defmacro js [ js-fun]
(let [body (str js-fun)]
(subs body 1 (- (count body) 1
That gets the idea. Unfortunately, I loose the ; as well as the new lines.
I'm pretty sure I don't *need* this macro. I can probably get away with
function () {
console.log('println');
}, but I feel like this would make the code nicer.
Thanks,
JPD
--
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
I think it's unlikely that Clojure would add a complex number type.
However, it might be possible to open up the system enough that new types
could be created and integrated by others. I think this discussion and
implementation from clojure-dev (about unsigned numbers) is pertinent:
https://groups.google.com/d/msg/clojure-dev/QF8P7_DK0rc/p8JOlF3Zs44J
In my last posts on that thread, I suggested some of the design and testing
work that I would expect Rich to ask about. I did not get the impression
that anyone cared enough to contribute further. If there was enough
interest, I'd be happy to ask Rich about it.
Alex
On Monday, April 27, 2015 at 1:46:48 PM UTC-5, Lee wrote:
Just cheerleading: I, for one, would love for Clojure to have complex
number support, however it can be arranged (built-in or through a library).
I sometimes do quantum computing work and this issue has prevented
progress on a couple of projects. I haven't tried to solve the problem
myself, and I'm not sure exactly what the difficulties are in detail, but a
couple of strong students have worked on this for me and been stymied.
I started my quantum computing work in Common Lisp, where complex numbers
are free and easy... and it's frustrating that this (and only this) has
prevented us from continuing that work now that we've switched to Clojure
for almost everything else.
-Lee
On Apr 27, 2015, at 1:52 PM, Andy Fingerhut andy.fi...@gmail.com
javascript: wrote:
People frequently make their own modified versions of Clojure without
having their changes made part of the core Clojure distribution. That is
why I said depending upon your goals. If your goal is to try it out and
learn from it, and you don't care whether it becomes part of the standard
Clojure distribution, then it does not matter what the Clojure core team's
priorities are, because they are not involved.
Andy
On Mon, Apr 27, 2015 at 10:46 AM, endbegin nkri...@gmail.com
javascript: wrote:
As far as I know, Java Math does not have a complex number type. Some
implementations of a complex number exist (such as Apache Commons Math),
but they create a Complex class that implements Serializeable and a Commons
specific interface.
Modifying clojure.core itself is a bit daunting, and like you said, it
would need to be a priority for the core team.
On Monday, April 27, 2015 at 12:45:46 PM UTC-4, Andy Fingerhut wrote:
Unless the Java Math library handles complex types already, I don't know
of any way to extend it in a way that would let you get the answer you want
from (Math/abs my-complex-number) in Clojure.
If you want code that gives the correct answers, a library using vectors
or maps for complex numbers can get you there. Memory footprint and
performance should be better with Clojure records or a new class written
directly in Java. With a library, I don't know of any way to be able to
mix Clojure's arithmetic operations like + - * / etc. with its existing
numeric types, and your new library-implemented complex types.
Support of Clojure's arithmetic operations on complex numbers might only
be achievable by modifying Clojure itself. Depending upon your goals, the
down side of that approach is that it will not become part of the normal
Clojure distribution unless the Clojure core team wants that addition,
which I would guess would be very low on their priority list (just a guess
-- I have no inside knowledge there).
Andy
On Mon, Apr 27, 2015 at 8:39 AM, endbegin nkri...@gmail.com 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 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
---
[ANN] Ring-swagger 0.20.0, Compojure-api 0.20.0 other schema/web libs
Hi all, We here at Metosin have been developing some open source libs, mostly stuff related to web. Most of the libs have got big new releases lately, so though of promoting them here too. Here goes: * *Ring-Swagger 0.20.0* (https://github.com/metosin/ring-swagger) - support lib for generating Swagger 1.2 2.0 specs out of clojure web apps - build on top of Prismatic Schema with enhanced coercion, serialization middlewares - extracts Swagger JSON Schemas out of deeply nested Prismatic Schemas - external routing lib adapters using ring-swagger: - Compojure-api - Fnhouse-swagger (https://github.com/metosin/fnhouse-swagger) - Pedestal-swagger (https://github.com/frankiesardo/pedestal-swagger) - just hit the 20k download mark, thanks for all the contributors! * *Compojure-api 0.20.0* (https://github.com/metosin/compojure-api) - started out as a macro learning experiment, but turned into a feature-rich api lib on top of Compojure - schema-based validation, doc-generation extension points for adding your own stuff in - latest version now with naked Swagger 2.0 support, all known bugs fixed * *Ring-http-response 0.6.1* (https://github.com/metosin/ring-http-response) - complete set of http response functions and predicates, now partially also for ClojureScript * *Schema-tools 0.4.0* (https://github.com/metosin/schema-tools) - helpers for manipulating the Prismatic Schemas (schema-aware map-operations, walkers etc.) * *scjsv 0.2.0* (https://github.com/metosin/scjsv) - Simple Clojure JSON Schema Validator, tiny wrapper for https://github.com/fge/json-schema-validator * *Ring-swagger-ui* 2.1.1-M2 - just a jar-packaged and preconfigured (for ring-swagger) latest version of the Swagger-UI - all props to Reverb technologies for the awesomeness We are currently developing a macro-free Swagger-enabled CQRS lib and for that, abstracting extracting stuff from our real projects compojure-api back to ring-swagger to maybe to new web-related schema-libs. Trying to go with the one library does one thing good -approach with small and extendable libraries. One target is to clean up a pluggable symmetric serialization coercion for all common data types with out-of-the-box coverage the common wire-formats (json, edn, transit, (s/maybe xml)). Contributions welcome and we are happy to help others to adapt the stuff we have been doing, so feel free to ping us - firstname @metosin.fi or ikitommi / Deraen at freenode. Tommi Juho -- 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
You're right. I didn't check it enough. I did check out the source (and btw, was very impressed with the result) but it looks like the function call ended up doing nothing. I just put in a side effect and I got the following results: [a :one], (multi-test), 100 runs, 2933 msecs [a :one], (fn-test), 100 runs, 500 msecs Much more reasonable and I'm willing to pay for that for using multimethods. I removed the jsperf and updated the repo. Sorry for spreading FUD. Cheers On Monday, April 27, 2015 at 10:07:07 AM UTC-4, David Nolen wrote: A quick glance at your benchmarking setup, it's not clear that you are benchmarking what you think you are benchmarking, and jsperf is not a suitable benchmarking harness (irrespective of it's popularity). Benchmarking is hard, benchmarking JavaScript is harder, and benchmarking JavaScript that went through Google Closure is even more challenging than that. It's for this reason we have our own simple benchmarking suite that we run in the project repo itself against 4 JavaScript engines (V8, JavaScriptCore, SpiderMonkey, Nashorn) at the command line. For people that want to see accurate benchmarking information posted to some public location, this is a great place to get involved contributing to ClojureScript without needing to dig into the compiler. My earlier points about the general performance expectations of multimethods in ClojureScript still stands :) David On Mon, Apr 27, 2015 at 9:44 AM, Andy- andre...@gmail.com javascript: wrote: Looks like they're pretty slow compared to a simple case: http://jsperf.com/cljs-multimethods https://github.com/rauhs/cljs-perf On Saturday, April 25, 2015 at 10:33:18 AM UTC-4, 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. 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? Thanks for your help!!! Regards. Timur -- 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 javascript: 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 javascript: 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 javascript:. 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: Performance of defmulti in both ClojureScript and Clojure
A quick glance at your benchmarking setup, it's not clear that you are benchmarking what you think you are benchmarking, and jsperf is not a suitable benchmarking harness (irrespective of it's popularity). Benchmarking is hard, benchmarking JavaScript is harder, and benchmarking JavaScript that went through Google Closure is even more challenging than that. It's for this reason we have our own simple benchmarking suite that we run in the project repo itself against 4 JavaScript engines (V8, JavaScriptCore, SpiderMonkey, Nashorn) at the command line. For people that want to see accurate benchmarking information posted to some public location, this is a great place to get involved contributing to ClojureScript without needing to dig into the compiler. My earlier points about the general performance expectations of multimethods in ClojureScript still stands :) David On Mon, Apr 27, 2015 at 9:44 AM, Andy- andre.r...@gmail.com wrote: Looks like they're pretty slow compared to a simple case: http://jsperf.com/cljs-multimethods https://github.com/rauhs/cljs-perf On Saturday, April 25, 2015 at 10:33:18 AM UTC-4, 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. 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? Thanks for your help!!! Regards. Timur -- 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: Performance of defmulti in both ClojureScript and Clojure
Looks like they're pretty slow compared to a simple case: http://jsperf.com/cljs-multimethods https://github.com/rauhs/cljs-perf On Saturday, April 25, 2015 at 10:33:18 AM UTC-4, 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. 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? Thanks for your help!!! Regards. Timur -- 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
I think that the answer is, it depends, and, there might be some surprises in store. In my own use, I found multimethods collapse in performance as a result of changes to the interface hierarchy in the library I was using (my tests cases went from 45s to over 4mins). I circumvented this by fiddling with the dispatch function, so that it returned ONLY classes that exactly matched one of the ones in the multi-method, and memoizing the look up of these classes. In effect, this closes down the multi-method, so it can no longer be freely extended. This dropped the time of my test cases dramatically. How widely applicable these results are, I do not know, as I never got down to the mechanistics underneath. Still, my conclusion is, you might want to test things out first! My full set of experiments are here... http://www.russet.org.uk/blog/3007 Timur timurha...@gmail.com writes: 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. 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? Thanks for your help!!! -- 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
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
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: Performance of defmulti in both ClojureScript and Clojure
Alex Miller a...@puredanger.com writes: Sounds like you might have been running into the absence of multimethod caching for the default case (http://dev.clojure.org/jira/browse/CLJ-1429), which has been fixed in 1.7. No, I don't think; my default case was and is throw an exception. Just on a side note, that repo does not change the default lein :jvm-opts, which are bad for benchmarking. I recommend at least: :jvm-opts ^:replace [-server] Criterium now yells at you if you haven't done this. I know. My use case, though, involves using Clojure through the REPL, so I tested in that way, since this is how it runs in lein. Phil -- 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
Sounds like you might have been running into the absence of multimethod caching for the default case (http://dev.clojure.org/jira/browse/CLJ-1429), which has been fixed in 1.7. Just on a side note, that repo does not change the default lein :jvm-opts, which are bad for benchmarking. I recommend at least: :jvm-opts ^:replace [-server] Criterium now yells at you if you haven't done this. On Monday, April 27, 2015 at 9:43:11 AM UTC-5, Phillip Lord wrote: I think that the answer is, it depends, and, there might be some surprises in store. In my own use, I found multimethods collapse in performance as a result of changes to the interface hierarchy in the library I was using (my tests cases went from 45s to over 4mins). I circumvented this by fiddling with the dispatch function, so that it returned ONLY classes that exactly matched one of the ones in the multi-method, and memoizing the look up of these classes. In effect, this closes down the multi-method, so it can no longer be freely extended. This dropped the time of my test cases dramatically. How widely applicable these results are, I do not know, as I never got down to the mechanistics underneath. Still, my conclusion is, you might want to test things out first! My full set of experiments are here... http://www.russet.org.uk/blog/3007 http://www.google.com/url?q=http%3A%2F%2Fwww.russet.org.uk%2Fblog%2F3007sa=Dsntz=1usg=AFQjCNFnegld_FgM0oFf4JgU9a1UvAAFaQ Timur timur...@gmail.com javascript: writes: 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. 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? Thanks for your help!!! -- 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
Unless the Java Math library handles complex types already, I don't know of
any way to extend it in a way that would let you get the answer you want
from (Math/abs my-complex-number) in Clojure.
If you want code that gives the correct answers, a library using vectors or
maps for complex numbers can get you there. Memory footprint and
performance should be better with Clojure records or a new class written
directly in Java. With a library, I don't know of any way to be able to
mix Clojure's arithmetic operations like + - * / etc. with its existing
numeric types, and your new library-implemented complex types.
Support of Clojure's arithmetic operations on complex numbers might only be
achievable by modifying Clojure itself. Depending upon your goals, the
down side of that approach is that it will not become part of the normal
Clojure distribution unless the Clojure core team wants that addition,
which I would guess would be very low on their priority list (just a guess
-- I have no inside knowledge there).
Andy
On Mon, Apr 27, 2015 at 8:39 AM, endbegin nkripl...@gmail.com 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.
--
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
As far as I understand, your example with Math/abs would need to be part of
Java.
You cannot extend the arithmetic operators in Java, and you will not be
able to extend static Java methods like Math/abs.
What you may be able to do is make your custom type play nice with Clojure
operators, like Clojure's rationals and bignums.
I'd suggest looking at the code for these, and considering a Java class
with two primitive attributes rather than a Clojure vector or map (which
have a big overhead compared to a simple number). Depending on what you
want to do, you may also want to consider implementing a vector of
complex type, which could be a single object with two primitive arrays.
If you're targeting a performant implementation, you should probably cross
post to numerical-clojure; people over there have a lot of experience about
numerical optimizations in Clojure.
On Monday, 27 April 2015, endbegin nkripl...@gmail.com 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
javascript:_e(%7B%7D,'cvml','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
javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com
javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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: Performance of defmulti in both ClojureScript and Clojure
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 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.
with-redefs does not work for macros
In one of my tests, I was trying to mock something (`clojure.tools.logging/warn`) that happened to be a macro. It had me puzzled for a while until I discovered that `with-redefs` resets the value of the vars after the body is executed, but does not reset the flag that says that the var is a macro: $ lein repl Clojure 1.6.0 … user= (defmacro foo [] `(prn I am a macro)) #'user/foo user= (clojure.test/function? 'foo) false user= (with-redefs [foo (fn [] 42)]) nil user= (clojure.test/function? foo) true user= (foo) ArityException Wrong number of args (0) passed to: user/foo clojure.lang.AFn.throwArity (AFn.java:429) user= (foo 42 42) (clojure.core/prn I am a macro) Is this a bug? I looked at the source for `with-redefs-fn`, and the fix appears simple: record for each val whether it's a macro or not, and then call the `(setMacro)` method on the vars that should be macros after resetting their values. Vebjorn -- 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
This is what I suspected. Of course, this is not just for abs, but really
for any mathematical operation. Sqrt, Trig operations etc.
I will study the Ratio type more closely, but note that something like
(Math/abs (/ 22 7)) does not work.
On Monday, April 27, 2015 at 12:45:32 PM UTC-4, Gary Verhaegen wrote:
As far as I understand, your example with Math/abs would need to be part
of Java.
You cannot extend the arithmetic operators in Java, and you will not be
able to extend static Java methods like Math/abs.
What you may be able to do is make your custom type play nice with Clojure
operators, like Clojure's rationals and bignums.
I'd suggest looking at the code for these, and considering a Java class
with two primitive attributes rather than a Clojure vector or map (which
have a big overhead compared to a simple number). Depending on what you
want to do, you may also want to consider implementing a vector of
complex type, which could be a single object with two primitive arrays.
If you're targeting a performant implementation, you should probably cross
post to numerical-clojure; people over there have a lot of experience about
numerical optimizations in Clojure.
On Monday, 27 April 2015, endbegin nkri...@gmail.com javascript:
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.
--
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
As far as I know, Java Math does not have a complex number type. Some
implementations of a complex number exist (such as Apache Commons Math),
but they create a Complex class that implements Serializeable and a Commons
specific interface.
Modifying clojure.core itself is a bit daunting, and like you said, it
would need to be a priority for the core team.
On Monday, April 27, 2015 at 12:45:46 PM UTC-4, Andy Fingerhut wrote:
Unless the Java Math library handles complex types already, I don't know
of any way to extend it in a way that would let you get the answer you want
from (Math/abs my-complex-number) in Clojure.
If you want code that gives the correct answers, a library using vectors
or maps for complex numbers can get you there. Memory footprint and
performance should be better with Clojure records or a new class written
directly in Java. With a library, I don't know of any way to be able to
mix Clojure's arithmetic operations like + - * / etc. with its existing
numeric types, and your new library-implemented complex types.
Support of Clojure's arithmetic operations on complex numbers might only
be achievable by modifying Clojure itself. Depending upon your goals, the
down side of that approach is that it will not become part of the normal
Clojure distribution unless the Clojure core team wants that addition,
which I would guess would be very low on their priority list (just a guess
-- I have no inside knowledge there).
Andy
On Mon, Apr 27, 2015 at 8:39 AM, endbegin nkri...@gmail.com javascript:
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 clo...@googlegroups.com
javascript:
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 javascript:
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 javascript:.
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
People frequently make their own modified versions of Clojure without
having their changes made part of the core Clojure distribution. That is
why I said depending upon your goals. If your goal is to try it out and
learn from it, and you don't care whether it becomes part of the standard
Clojure distribution, then it does not matter what the Clojure core team's
priorities are, because they are not involved.
Andy
On Mon, Apr 27, 2015 at 10:46 AM, endbegin nkripl...@gmail.com wrote:
As far as I know, Java Math does not have a complex number type. Some
implementations of a complex number exist (such as Apache Commons Math),
but they create a Complex class that implements Serializeable and a Commons
specific interface.
Modifying clojure.core itself is a bit daunting, and like you said, it
would need to be a priority for the core team.
On Monday, April 27, 2015 at 12:45:46 PM UTC-4, Andy Fingerhut wrote:
Unless the Java Math library handles complex types already, I don't know
of any way to extend it in a way that would let you get the answer you want
from (Math/abs my-complex-number) in Clojure.
If you want code that gives the correct answers, a library using vectors
or maps for complex numbers can get you there. Memory footprint and
performance should be better with Clojure records or a new class written
directly in Java. With a library, I don't know of any way to be able to
mix Clojure's arithmetic operations like + - * / etc. with its existing
numeric types, and your new library-implemented complex types.
Support of Clojure's arithmetic operations on complex numbers might only
be achievable by modifying Clojure itself. Depending upon your goals, the
down side of that approach is that it will not become part of the normal
Clojure distribution unless the Clojure core team wants that addition,
which I would guess would be very low on their priority list (just a guess
-- I have no inside knowledge there).
Andy
On Mon, Apr 27, 2015 at 8:39 AM, endbegin nkri...@gmail.com 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 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.
--
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
Re: with-redefs does not work for macros
On Monday, April 27, 2015 at 12:34:14 PM UTC-4, Vebjorn Ljosa wrote: In one of my tests, I was trying to mock something (`clojure.tools.logging/warn`) that happened to be a macro. It had me puzzled for a while until I discovered that `with-redefs` resets the value of the vars after the body is executed, but does not reset the flag that says that the var is a macro: Granted, using `with-redefs` with a macro rarely makes sense because macroexpansion has to occur within the extent of `with-redefs` for the redefinition to have any effect. (I can't even think of an example where I would want to do that, so maybe `with-redefs` should emit a warning when it's being asked to redefine a macro.) But in any case, an attempt to use `with-redefs` on something that happens to be a macro should not mess up the root binding permanently. -- 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
Just cheerleading: I, for one, would love for Clojure to have complex number
support, however it can be arranged (built-in or through a library).
I sometimes do quantum computing work and this issue has prevented progress on
a couple of projects. I haven't tried to solve the problem myself, and I'm not
sure exactly what the difficulties are in detail, but a couple of strong
students have worked on this for me and been stymied.
I started my quantum computing work in Common Lisp, where complex numbers are
free and easy... and it's frustrating that this (and only this) has prevented
us from continuing that work now that we've switched to Clojure for almost
everything else.
-Lee
On Apr 27, 2015, at 1:52 PM, Andy Fingerhut andy.finger...@gmail.com wrote:
People frequently make their own modified versions of Clojure without having
their changes made part of the core Clojure distribution. That is why I said
depending upon your goals. If your goal is to try it out and learn from
it, and you don't care whether it becomes part of the standard Clojure
distribution, then it does not matter what the Clojure core team's priorities
are, because they are not involved.
Andy
On Mon, Apr 27, 2015 at 10:46 AM, endbegin nkripl...@gmail.com
mailto:nkripl...@gmail.com wrote:
As far as I know, Java Math does not have a complex number type. Some
implementations of a complex number exist (such as Apache Commons Math), but
they create a Complex class that implements Serializeable and a Commons
specific interface.
Modifying clojure.core itself is a bit daunting, and like you said, it would
need to be a priority for the core team.
On Monday, April 27, 2015 at 12:45:46 PM UTC-4, Andy Fingerhut wrote:
Unless the Java Math library handles complex types already, I don't know of
any way to extend it in a way that would let you get the answer you want from
(Math/abs my-complex-number) in Clojure.
If you want code that gives the correct answers, a library using vectors or
maps for complex numbers can get you there. Memory footprint and performance
should be better with Clojure records or a new class written directly in
Java. With a library, I don't know of any way to be able to mix Clojure's
arithmetic operations like + - * / etc. with its existing numeric types, and
your new library-implemented complex types.
Support of Clojure's arithmetic operations on complex numbers might only be
achievable by modifying Clojure itself. Depending upon your goals, the down
side of that approach is that it will not become part of the normal Clojure
distribution unless the Clojure core team wants that addition, which I would
guess would be very low on their priority list (just a guess -- I have no
inside knowledge there).
Andy
On Mon, Apr 27, 2015 at 8:39 AM, endbegin nkri...@gmail.com 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 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
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
https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
mailto:clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send
Re: Crazy Need: Embed JavaScript Structure in Clojure
Hi JPatrick,
On Mon, Apr 27, 2015 at 11:50 PM, JPatrick Davenport virmu...@gmail.com
wrote:
Hello,
So just to get it out: I do not want to evaluate the JavaScript, simply
preserve it.
I'm working on an ArangoDB driver. Part of the wonder that is ArangoDB is
its ability to support transactions. This is done using JSON. Part of the
REST object for a transaction is what I want to do in the transaction. This
is encapsulated in the action attribute of the posted JSON object.
Here's an example
{...JSON configuration
action: function (){many lines of stuff here,
More JSON configuration}
Now the way that this works in node is by converting the function into a
String. I didn't know that String(function () {..valid JavaScript...})
would kick out a string version of the function. Pretty neat.
I want to do the same thing with Clojure. I presently take a map with one
of the attributes of :action. I want something like this.
{:some-key :some-value,
:action (js-macro function(){
console.log(pretty crappy transaction);
console.log(another line);
})}
On the other side of the macro I want to get function() {\t\t\t\n
console.log(\pretty crappy transaction\;\n\t\t\tconsole.log(\another
line\);\n} or there about.
I've got
(defmacro js [ js-fun]
(let [body (str js-fun)]
(subs body 1 (- (count body) 1
That gets the idea. Unfortunately, I loose the ; as well as the new
lines.
Your macro thinks it receives the code as a string, but Clojure macros
receive their parameters as s-expressions. Just like functions, with the
only difference functions' params are evaluated.
I'm pretty sure I don't *need* this macro. I can probably get away with
function () {
console.log('println');
}, but I feel like this would make the code nicer.
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# (); }))
(I didn't test the code, it's just to give you an idea.)
Thanks,
JPD
--
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.
Re: [ANN] Clojure Applied: From Practice to Practitioner
The second beta of Clojure Applied is now available. This version adds Chapter 8 (Clojure Testing) as well as a foreword by Russ Olsen, and fixes for many of the reported errata. https://pragprog.com/book/vmclojeco/clojure-applied If you've already bought the book, you should get an email to download the new version. Alex On Monday, April 13, 2015 at 12:00:58 PM UTC-5, Alex Miller wrote: On Monday, April 13, 2015 at 9:40:39 AM UTC-5, Jonathon McKitrick wrote: Will we be notified as new content is added so we can update our electronic versions? Yes, you should be notified when it's updated. Also, if you visit the Pragmatic web site and log in, they will notify you if any books on your bookshelf have been updated. We will probably have another update next week with chapter 8 and any errata fixes since the first release. Alex -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
