Re: [clojure-rabbitmq] Re: Socket Exception thrown when trying to make a remote connection to server over adhoc network
Any idea what the possible causes of this problem are? sorry I know its not much information to work with.. On Wednesday, June 11, 2014 2:34:42 PM UTC-4, Samuel Nelson wrote: I tested via telnet: telnet 10.10.10.3 5672 and the rabbitMQ server reports in the log that it accepted the connection 10.10.10.5:46899 - 10.10.10.3:5672. Then the connection times out and an error log is written: Closing AMQP connection 10.10.10.5:46899 - 10.10.10.3:5672. However, when I run the Clojure/Langohr code, the log file accepts the connection, but does not attempt to close. Instead we have the SocketException on the client side, 10.10.10.5, which I listed in the first post. Thanks! On Wednesday, June 11, 2014 2:00:54 PM UTC-4, Michael Klishin wrote: On 11 June 2014 at 21:57:11, Samuel Nelson (snel...@ycp.edu) wrote: Caused by: SocketException Connection reset This message is very generic and does not explain much. Can you see connection entries in RabbitMQ log? Try connecting to RabbitMQ via telnet, for example (note that it will quickly close connection unless you enter a valid protocol header, AMQP091, and then due to connection negotiation timeout). -- MK Software Engineer, Pivotal/RabbitMQ This information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. -- This information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: fn and let are special forms or macros?
Hi Mark, Here's a brief doc on special forms: http://clojure-doc.org/articles/language/macros.html#special-forms-in-detail Thanks, Ambrose On Wed, Jun 18, 2014 at 12:13 PM, Mark P pierh...@gmail.com wrote: Thanks Tassilo for the explanation - much appreciated! I have been searching the web and searching clojure text books for the last two hours trying to find the answer to this same question. Finally I stumbled onto this thread! I realize that hiding the complexity of distinctions between fn / fn* and let / let* etc might make the documentation more accessible for some users, but for others (like me and presumably also Plínio) it makes it really hard to track down what is *really* going on. I wish this distinction was part of the formal documentation. Does anyone know of documentation anywhere that does include these kinds of distinction? Thanks, Mark. On Thursday, 6 March 2014 02:27:26 UTC+10:30, Tassilo Horn wrote: Plínio Balduino pbal...@gmail.com writes: Hi Plínio, Clojure.org says fn and let are special forms, but using the macro sourceshows that both are macros calling fn* and let* respectivelly. So fn and let are special special forms, or clojure.org is incorrect/outdated? Well, they are correct from a user's point of view. One never uses the real special forms fn* and let*. If fn and let are really special forms and not macros, could you explain why? fn and let (and also loop) are macros around the real special forms fn* and let* (and loop*) that add support for destructuring. For example, (let [[a b] [1 2]] (+ a b)) expands to (let* [vec__8592 [1 2] a (clojure.core/nth vec__8592 0 nil) b (clojure.core/nth vec__8592 1 nil)] (+ a b)) where the destructuring has been transformed to normal code already. Bye, Tassilo -- 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: Leiningen 2.4.2 upgrade causing problems
Hi, FWIW... On Wednesday, June 18, 2014 5:06:09 AM UTC+2, Sean Corfield wrote: works for me... Does *not* work for me. I see the same error inside and outside of projects: $ java -version java version 1.7.0_11 Java(TM) SE Runtime Environment (build 1.7.0_11-b21) Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode) $ lein -version Leiningen 2.4.2 on Java 1.7.0_11 Java HotSpot(TM) 64-Bit Server VM $ lein help new Exception in thread main java.lang.ExceptionInInitializerError at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at clojure.lang.RT.loadClassForName(RT.java:2093) at clojure.lang.RT.load(RT.java:430) at clojure.lang.RT.load(RT.java:411) at clojure.core$load$fn__5066.invoke(core.clj:5641) at clojure.core$load.doInvoke(core.clj:5640) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$load_one.invoke(core.clj:5446) at clojure.core$load_lib$fn__5015.invoke(core.clj:5486) at clojure.core$load_lib.doInvoke(core.clj:5485) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply.invoke(core.clj:626) at clojure.core$load_libs.doInvoke(core.clj:5524) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:626) at clojure.core$require.doInvoke(core.clj:5607) at clojure.lang.RestFn.invoke(RestFn.java:421) at stencil.core$loading__4958__auto__.invoke(core.clj:1) at stencil.core__init.load(Unknown Source) at stencil.core__init.clinit(Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at clojure.lang.RT.loadClassForName(RT.java:2093) at clojure.lang.RT.load(RT.java:430) at clojure.lang.RT.load(RT.java:411) at clojure.core$load$fn__5066.invoke(core.clj:5641) at clojure.core$load.doInvoke(core.clj:5640) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$load_one.invoke(core.clj:5446) at clojure.core$load_lib$fn__5015.invoke(core.clj:5486) at clojure.core$load_lib.doInvoke(core.clj:5485) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply.invoke(core.clj:626) at clojure.core$load_libs.doInvoke(core.clj:5524) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:626) at clojure.core$require.doInvoke(core.clj:5607) at clojure.lang.RestFn.invoke(RestFn.java:512) at leiningen.new.templates$loading__4958__auto__.invoke(templates.clj:11) at leiningen.new.templates__init.load(Unknown Source) at leiningen.new.templates__init.clinit(Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at clojure.lang.RT.loadClassForName(RT.java:2093) at clojure.lang.RT.load(RT.java:430) at clojure.lang.RT.load(RT.java:411) at clojure.core$load$fn__5066.invoke(core.clj:5641) at clojure.core$load.doInvoke(core.clj:5640) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$load_one.invoke(core.clj:5446) at clojure.core$load_lib$fn__5015.invoke(core.clj:5486) at clojure.core$load_lib.doInvoke(core.clj:5485) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply.invoke(core.clj:626) at clojure.core$load_libs.doInvoke(core.clj:5524) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:626) at clojure.core$require.doInvoke(core.clj:5607) at clojure.lang.RestFn.invoke(RestFn.java:457) at leiningen.new$loading__4958__auto__.invoke(new.clj:1) at leiningen.new__init.load(Unknown Source) at leiningen.new__init.clinit(Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at clojure.lang.RT.loadClassForName(RT.java:2093) at clojure.lang.RT.load(RT.java:430) at clojure.lang.RT.load(RT.java:411) at clojure.core$load$fn__5066.invoke(core.clj:5641) at clojure.core$load.doInvoke(core.clj:5640) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$load_one.invoke(core.clj:5446) at clojure.core$load_lib$fn__5015.invoke(core.clj:5486) at clojure.core$load_lib.doInvoke(core.clj:5485) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply.invoke(core.clj:626) at clojure.core$load_libs.doInvoke(core.clj:5524) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:626) at clojure.core$require.doInvoke(core.clj:5607) at clojure.lang.RestFn.invoke(RestFn.java:408) at
Re: Leiningen 2.4.2 upgrade causing problems
Someone was having the same issue, solved by upgrading Eastwood plugin to 0.1.2. Hope that helps. Thanks, Ambrose On Wed, Jun 18, 2014 at 11:05 AM, Sean Corfield s...@corfield.org wrote: works for me... Leiningen 2.4.2; Java build 1.8.0_05-b13; OS X 10.8.5 - lein help new works fine outside of a project and also inside the context of a project that depends on Clojure 1.6.0. Are you running lein inside a project or outside? What do you have in your profiles.clj file? Sean On Tue, Jun 17, 2014 at 10:45 AM, gvim gvi...@gmail.com wrote: OS X Mountain Lion / lein 2.4.2 / clojure 1.6.0 / Java(TM) SE Runtime Environment (build 1.8.0_05-b13) Running `lein help new` I'm getting an exception including this: Caused by: java.io.FileNotFoundException: Could not locate clojure/data/priority_map__init.class or clojure/data/priority_map.clj on classpath: at clojure.lang.RT.load(RT.java:443) Everything was working before the recent Leiningen upgrade. gvim -- 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. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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: Leiningen 2.4.2 upgrade causing problems
Rather upgrading *from* 0.1.2 fixes. Thanks, Ambrose On Wed, Jun 18, 2014 at 5:08 PM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: Someone was having the same issue, solved by upgrading Eastwood plugin to 0.1.2. Hope that helps. Thanks, Ambrose On Wed, Jun 18, 2014 at 11:05 AM, Sean Corfield s...@corfield.org wrote: works for me... Leiningen 2.4.2; Java build 1.8.0_05-b13; OS X 10.8.5 - lein help new works fine outside of a project and also inside the context of a project that depends on Clojure 1.6.0. Are you running lein inside a project or outside? What do you have in your profiles.clj file? Sean On Tue, Jun 17, 2014 at 10:45 AM, gvim gvi...@gmail.com wrote: OS X Mountain Lion / lein 2.4.2 / clojure 1.6.0 / Java(TM) SE Runtime Environment (build 1.8.0_05-b13) Running `lein help new` I'm getting an exception including this: Caused by: java.io.FileNotFoundException: Could not locate clojure/data/priority_map__init.class or clojure/data/priority_map.clj on classpath: at clojure.lang.RT.load(RT.java:443) Everything was working before the recent Leiningen upgrade. gvim -- 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. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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: Defs with %
thanks for the report, fixed
On Wed, Jun 18, 2014 at 1:30 AM, Mike Thompson m.l.thompson...@gmail.com
wrote:
Colin, many thanks. Issue created:
https://github.com/cgrand/sjacket/issues/19
On Wednesday, June 18, 2014 4:08:53 AM UTC+10, Colin Jones wrote:
Yeah the latter version parses as 2 symbols in sjacket, whereas the defn
version parses as a single list.
user= (p/parser top%)
#net.cgrand.parsley.Node{:tag :net.cgrand.sjacket.parser/root, :content
[#net.cgrand.parsley.Node{:tag :symbol, :content
[#net.cgrand.parsley.Node{:tag :name, :content [top]}]}
#net.cgrand.parsley.Node{:tag :symbol, :content
[#net.cgrand.parsley.Node{:tag :name, :content [%]}]}]}
REPLy uses sjacket to split input expressions and send them each off to
nREPL in sequence, IIRC so that you get all results back from stuff like:
user= 1 2 3
1
2
3
So it treats the top% input basically the same as if there were
intervening whitespace, like top %.
From http://clojure.org/reader:
-
Symbols begin with a non-numeric character and can contain alphanumeric
characters and *, +, !, -, _, and ? (other characters will be allowed
eventually, but not all macro characters have been determined). '/' has
special meaning, it can be used once in the middle of a symbol to separate
the namespace from the name, e.g. my-namespace/foo. '/' by itself names the
division function. '.' has special meaning - it can be used one or more
times in the middle of a symbol to designate a fully-qualified class name,
e.g. java.util.BitSet, or in namespace names. Symbols beginning or ending
with '.' are reserved by Clojure. Symbols containing / or . are said to be
'qualified'. Symbols beginning or ending with ':' are reserved by Clojure.
A symbol can contain one or more non-repeating ':'s.
-
So it looks to me like that function name is illegal, and it's an
implementation detail that it currently is allowed to work.
Usually parsing fixes for lein repl belong in sjacket (
https://github.com/cgrand/sjacket/issues), but I'm not 100% convinced
the parser should say top% is a legitimate symbol. But I'm also not
convinced it should ever be possible for 2 symbols to be right next to each
other with no intervening whitespace. Not sure what the right thing to do
is here. Let's discuss further in an issue on sjacket.
Short-term workaround: `(do top%)`.
On Tuesday, June 17, 2014 9:54:25 AM UTC-5, daveray wrote:
I believe this is a problem with the Leiningen REPL. It works fine from
the built-in REPL:
$ java -jar ~/.m2/repository/org/clojure/clojure/1.5.1/clojure-1.5.1.jar
Clojure 1.5.1
user= (def top% 4)
#'user/top%
user= top%
4
Dave
On Tue, Jun 17, 2014 at 1:32 AM, Mike Thompson m.l.tho...@gmail.com
wrote:
At the REPL ...
user= (def top% 4) ;; an unusually named var
#'user/top%
But later, it I try to use this var, trouble ...
user= top%
CompilerException java.lang.RuntimeException: Unable to resolve symbol:
top in this context, compiling:(Local\Temp\form-
init6773082655831127234.clj:1:734)
CompilerException java.lang.RuntimeException: Unable to resolve symbol:
% in this context, compiling:(Local\Temp\form-
init6773082655831127234.clj:1:734)
Not sure what to make if this. Obviously % is a bit special. And it is
certainly not a significant problem for me, at all. Just seemed odd that
I'm allowed to successfully do the def, if it is just going to cause
problems later.
--
Mike
--
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.
On Wednesday, June 18, 2014 4:08:53 AM UTC+10, Colin Jones wrote:
Yeah the latter version parses as 2 symbols in sjacket, whereas the defn
version parses as a single list.
user= (p/parser top%)
#net.cgrand.parsley.Node{:tag :net.cgrand.sjacket.parser/root, :content
[#net.cgrand.parsley.Node{:tag :symbol, :content
[#net.cgrand.parsley.Node{:tag :name, :content [top]}]}
#net.cgrand.parsley.Node{:tag :symbol, :content
[#net.cgrand.parsley.Node{:tag :name, :content [%]}]}]}
REPLy uses sjacket to split input expressions and send them each off to
nREPL in sequence, IIRC so that you get all results back from stuff like:
user= 1 2 3
1
2
3
So it treats the top% input basically the same as if there were
intervening whitespace, like top %.
From http://clojure.org/reader:
-
Symbols begin with a
Re: Leiningen 2.4.2 upgrade causing problems
Oh, great, yes, that helped. Unexpected. Thanks, stefan On Wednesday, June 18, 2014 11:09:52 AM UTC+2, Ambrose Bonnaire-Sergeant wrote: Rather upgrading *from* 0.1.2 fixes. Thanks, Ambrose On Wed, Jun 18, 2014 at 5:08 PM, Ambrose Bonnaire-Sergeant abonnair...@gmail.com javascript: wrote: Someone was having the same issue, solved by upgrading Eastwood plugin to 0.1.2. Hope that helps. Thanks, Ambrose On Wed, Jun 18, 2014 at 11:05 AM, Sean Corfield se...@corfield.org javascript: wrote: works for me... Leiningen 2.4.2; Java build 1.8.0_05-b13; OS X 10.8.5 - lein help new works fine outside of a project and also inside the context of a project that depends on Clojure 1.6.0. Are you running lein inside a project or outside? What do you have in your profiles.clj file? Sean On Tue, Jun 17, 2014 at 10:45 AM, gvim gvi...@gmail.com javascript: wrote: OS X Mountain Lion / lein 2.4.2 / clojure 1.6.0 / Java(TM) SE Runtime Environment (build 1.8.0_05-b13) Running `lein help new` I'm getting an exception including this: Caused by: java.io.FileNotFoundException: Could not locate clojure/data/priority_map__init.class or clojure/data/priority_map.clj on classpath: at clojure.lang.RT.load(RT.java:443) Everything was working before the recent Leiningen upgrade. gvim -- 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. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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: Leiningen 2.4.2 upgrade causing problems
On 18/06/2014 04:05, Sean Corfield wrote:
works for me...
Leiningen 2.4.2; Java build 1.8.0_05-b13; OS X 10.8.5 - lein help new
works fine outside of a project and also inside the context of a
project that depends on Clojure 1.6.0.
Are you running lein inside a project or outside? What do you have in
your profiles.clj file?
Sean
My ~/.lein/profiles.clj below. No problems if I remove it and run `lein
help new` again.
{:user
{:plugins
[[cider/cider-nrepl 0.7.0-SNAPSHOT]
[lein-ancient 0.5.5]
[lein-immutant 1.2.1]
[com.jakemccrary/lein-test-refresh 0.5.0]]
:dependencies
[[org.clojure/clojure 1.6.0]
[nrepl-inspect 0.4.1]
[org.clojure/tools.trace 0.7.8]
[co.paralleluniverse/pulsar 0.5.1]]
:repl-options
{:nrepl-middleware
[cider.nrepl.middleware.classpath/wrap-classpath
cider.nrepl.middleware.complete/wrap-complete
cider.nrepl.middleware.info/wrap-info
cider.nrepl.middleware.inspect/wrap-inspect
cider.nrepl.middleware.stacktrace/wrap-stacktrace
cider.nrepl.middleware.trace/wrap-trace]}}}
--
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: Leiningen 2.4.2 upgrade causing problems
On 18/06/2014 04:05, Sean Corfield wrote: Leiningen 2.4.2; Java build 1.8.0_05-b13; OS X 10.8.5 - lein help new works fine outside of a project and also inside the context of a project that depends on Clojure 1.6.0. Are you running lein inside a project or outside? What do you have in your profiles.clj file? Sean Running `lein help new` from ~/.lein . By process of elimination I discovered the culprit is: [co.paralleluniverse/pulsar 0.5.1] It's still weird, though, because I'm almost certain I checked this when I set about debugging my profiles.clj file yesterday. gvim -- 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: macro question
you can also use macroexpand-1 to see how your macro expands for example, having defined your macro as suggested by Gary and James above, you can write something like: (macroexpand-1 '(if-zero (- 4 2 2) (+ 1 1) (+ 2 2))) and see that it correctly to: (if (clojure.core/= (- 4 2 2) 0) (+ 1 1) (+ 2 2)) cheers, Gianluca -- 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: BeagleBone Black Continuous Analog Reads
I would say it's not so much about programming paradigm rather than system calls. It all boils down to how often you would want to read the data. If it's not more than some times per second, and it's not super important with timing, you could probably put a reading function in a SchedulingThreadPool (you can add Clojure functions as is since they are Runnable) or have a look at the at-at library spawned from overtone. https://github.com/overtone/at-at One way to react on the incoming values are to swap! or reset! them into an atom, which has a watcher-function added which could things based on the new and old values. http://clojuredocs.org/clojure_core/clojure.core/add-watch shows an example with agents, but it works for atoms as well. If you want to store an incoming series of values for further processing, either use the clojure.lang.PeristentQueue or some Java equivalent. If you want to sample in very high frequency, (kilohertz) you'll need to fetch the values in some loop close to machine an batch it into Clojure by primitive-buffers or similar (like soundcards, UARTs and network stacks do). /Linus 2014-06-18 5:08 GMT+02:00 Jeremy Wright wright...@gmail.com: The main way of reading the inputs (analog or digital) on a BeagleBone Black is through the Linux file system. http://beaglebone.cameon.net/home/reading-the-analog-inputs-adc I'm still pretty new to Clojure and come from an object oriented background. I would like to do a continuous read of the BBB's analog inputs through the file system and make decisions based on the values. There are different ways of handling this from an OOP perspective, but I'm not sure how to approach it from a functional perspective. Can someone point me in the right direction? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Clojure equivalent of 3-level enumeration in Ruby?
I have a method in Ruby that involves 3-level enumeration and would like
to rewrite it in Clojure. Without asking anyone to do the job :), what
is the best equivalent to this kind of Ruby iteration in Clojure? I
looked at prewalk and postwalk but wasn't convinced that was what's
required. Map could also get a bit messy here.
gvim
SIGNS = { ar:'Aries', ta:'Taurus', ge:'Gemini', cn:'Cancer', le:'Leo',
vi:'Virgo',
li:'Libra', sc:'Scorpio', sa:'Sagittarius', cp:'Capricorn',
aq:'Aquarius', pi:'Pisces' }
RULERS = {Aries:[:Mars], Taurus:[:Venus], Gemini:[:Mercury],
Cancer:[:Moon], Leo:[:Sun], Virgo:[:Mercury], Libra:[:Venus],
Scorpio:[:Mars, :Pluto], Sagittarius:[:Jupiter],
Capricorn:[:Saturn], Aquarius:[:Saturn, :Uranus], Pisces:[:Jupiter,
:Neptune]}
ANGLES = {cnj:{orb:7.5, deg:[0], type:'g'}, squ:{orb:6, deg:[90,270],
type:'r'},
tri:{orb:6, deg:[120,240], type:'g'}, opp:{orb:7.5,
deg:[180], type:'r'}}
PERSONALS = %i(Sun Moon Mercury Venus Mars)
ASPECTED = %i(Sun Moon Mercury Venus Mars Jupiter Saturn Uranus Neptune
Pluto)
def find_aspects(astro_data)
results = {}
PERSONALS.each_with_index do |p,i|
results[p] = {}
ASPECTED[i+1..9].each do |a|
next if p == a
ANGLES.each do |asp, data|
data[:deg].each do |d|
exact = astro_data[p][:long] + d
exact -= 360 if exact = 360
range_start = exact - data[:orb]
range_end = (exact + data[:orb] = 360) ? (exact + data[:orb]
- 360) : (exact + data[:orb])
target_long = astro_data[a][:long]
if target_long = range_start target_long = range_end
width = target_long = exact ? (exact - target_long) :
(target_long - exact)
results[p][a] = [asp,width]
end
end
end
end
end
return results
end
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Clojure equivalent of 3-level enumeration in Ruby?
Try http://clojuredocs.org/clojure_core/clojure.core/for
On Wed, Jun 18, 2014 at 11:56 AM, gvim gvi...@gmail.com wrote:
I have a method in Ruby that involves 3-level enumeration and would like
to rewrite it in Clojure. Without asking anyone to do the job :), what is
the best equivalent to this kind of Ruby iteration in Clojure? I looked at
prewalk and postwalk but wasn't convinced that was what's required. Map
could also get a bit messy here.
gvim
SIGNS = { ar:'Aries', ta:'Taurus', ge:'Gemini', cn:'Cancer', le:'Leo',
vi:'Virgo',
li:'Libra', sc:'Scorpio', sa:'Sagittarius', cp:'Capricorn',
aq:'Aquarius', pi:'Pisces' }
RULERS = {Aries:[:Mars], Taurus:[:Venus], Gemini:[:Mercury],
Cancer:[:Moon], Leo:[:Sun], Virgo:[:Mercury], Libra:[:Venus],
Scorpio:[:Mars, :Pluto], Sagittarius:[:Jupiter],
Capricorn:[:Saturn], Aquarius:[:Saturn, :Uranus], Pisces:[:Jupiter,
:Neptune]}
ANGLES = {cnj:{orb:7.5, deg:[0], type:'g'}, squ:{orb:6, deg:[90,270],
type:'r'},
tri:{orb:6, deg:[120,240], type:'g'}, opp:{orb:7.5, deg:[180],
type:'r'}}
PERSONALS = %i(Sun Moon Mercury Venus Mars)
ASPECTED = %i(Sun Moon Mercury Venus Mars Jupiter Saturn Uranus Neptune
Pluto)
def find_aspects(astro_data)
results = {}
PERSONALS.each_with_index do |p,i|
results[p] = {}
ASPECTED[i+1..9].each do |a|
next if p == a
ANGLES.each do |asp, data|
data[:deg].each do |d|
exact = astro_data[p][:long] + d
exact -= 360 if exact = 360
range_start = exact - data[:orb]
range_end = (exact + data[:orb] = 360) ? (exact + data[:orb] -
360) : (exact + data[:orb])
target_long = astro_data[a][:long]
if target_long = range_start target_long = range_end
width = target_long = exact ? (exact - target_long) :
(target_long - exact)
results[p][a] = [asp,width]
end
end
end
end
end
return results
end
--
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: Leiningen 2.4.2 upgrade causing problems
I am using Eastwood 0.1.2 without problems with Leiningen 2.4.2 but perhaps Stefan and others are seeing conflicts because of other stuff in ~/.lein/profiles.clj with Eastwood? gvim seems to have isolated it to pulsar. Nearly all of the problems I see reported with Leiningen end up being due to having a lot of stuff in the user profile... Sean On Jun 18, 2014, at 2:08 AM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: Someone was having the same issue, solved by upgrading Eastwood plugin to 0.1.2. Hope that helps. Thanks, Ambrose On Wed, Jun 18, 2014 at 11:05 AM, Sean Corfield s...@corfield.org wrote: works for me... Leiningen 2.4.2; Java build 1.8.0_05-b13; OS X 10.8.5 - lein help new works fine outside of a project and also inside the context of a project that depends on Clojure 1.6.0. Are you running lein inside a project or outside? What do you have in your profiles.clj file? Sean On Tue, Jun 17, 2014 at 10:45 AM, gvim gvi...@gmail.com wrote: OS X Mountain Lion / lein 2.4.2 / clojure 1.6.0 / Java(TM) SE Runtime Environment (build 1.8.0_05-b13) Running `lein help new` I'm getting an exception including this: Caused by: java.io.FileNotFoundException: Could not locate clojure/data/priority_map__init.class or clojure/data/priority_map.clj on classpath: at clojure.lang.RT.load(RT.java:443) Everything was working before the recent Leiningen upgrade. gvim signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Leiningen 2.4.2 upgrade causing problems
Recommendation: If you see this problem, and you have Eastwood in your
~/.lein/profiles.clj file, upgrade Eastwood to version 0.1.4, or go back to
Leiningen 2.3.4.
More details:
I have been able to reproduce an exception when running 'lein help new'
outside of any Leiningen project in these conditions:
Mac OS X 10.8.5
JVM 1.7.0_51
Leiningen 2.4.2
~/.lein/profiles.clj contains {:user {:plugins [[jonase/eastwood
0.1.2]]}} or an older Eastwood version
The exception goes away if I change to Leiningen 2.3.4, or if I upgrade to
Eastwood 0.1.3 or later.
I do not know the reason for the exception, but it makes some sense that
upgrading to Eastwood 0.1.3 or later makes a difference (0.1.4 is the
latest released version). Why? Because a change made in Eastwood version
0.1.3 was to make a copy of all Clojure contrib libraries inside of
Eastwood itself, and renaming their namespaces. This helped eliminate some
contrib library version number conflicts when using Eastwood on some
projects that also used those contrib libraries.
Thus Eastwood 0.1.2 depends on data.priority-map, but only indirectly
through tools.analyzer.jvm and its dependencies. Below is the output of
'lein deps :tree' for Eastwood 0.1.2, in case it helps anyone track down
what is going on:
% git clone https://github.com/jonase/eastwood.git
% git checkout eastwood-0.1.2
% lein deps :tree
[clojure-complete 0.2.3 :exclusions [[org.clojure/clojure]]]
[leinjacker 0.4.1]
[org.clojure/core.contracts 0.0.1]
[org.clojure/core.unify 0.5.3]
[org.clojars.brenton/google-diff-match-patch 0.1]
[org.clojure/clojure 1.6.0]
[org.clojure/tools.analyzer.jvm 0.1.0-beta10]
[org.clojure/core.memoize 0.5.6]
[org.clojure/core.cache 0.6.3]
[org.clojure/data.priority-map 0.0.2]
[org.ow2.asm/asm-all 4.1]
[org.clojure/tools.analyzer 0.1.0-beta10]
[org.clojure/tools.macro 0.1.2]
[org.clojure/tools.namespace 0.2.4]
[org.clojure/tools.nrepl 0.2.3 :exclusions [[org.clojure/clojure]]]
[org.clojure/tools.reader 0.8.3]
Andy
On Wed, Jun 18, 2014 at 9:12 AM, Sean Corfield s...@corfield.org wrote:
I am using Eastwood 0.1.2 without problems with Leiningen 2.4.2 but
perhaps Stefan and others are seeing conflicts because of other stuff in
~/.lein/profiles.clj with Eastwood?
gvim seems to have isolated it to pulsar.
Nearly all of the problems I see reported with Leiningen end up being due
to having a lot of stuff in the user profile...
Sean
On Jun 18, 2014, at 2:08 AM, Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com wrote:
Someone was having the same issue, solved by upgrading Eastwood plugin to
0.1.2.
Hope that helps.
Thanks,
Ambrose
On Wed, Jun 18, 2014 at 11:05 AM, Sean Corfield s...@corfield.org wrote:
works for me...
Leiningen 2.4.2; Java build 1.8.0_05-b13; OS X 10.8.5 - lein help new
works fine outside of a project and also inside the context of a
project that depends on Clojure 1.6.0.
Are you running lein inside a project or outside? What do you have in
your profiles.clj file?
Sean
On Tue, Jun 17, 2014 at 10:45 AM, gvim gvi...@gmail.com wrote:
OS X Mountain Lion / lein 2.4.2 / clojure 1.6.0 / Java(TM) SE
Runtime
Environment (build 1.8.0_05-b13)
Running `lein help new` I'm getting an exception including this:
Caused by: java.io.FileNotFoundException: Could not locate
clojure/data/priority_map__init.class or clojure/data/priority_map.clj
on
classpath:
at clojure.lang.RT.load(RT.java:443)
Everything was working before the recent Leiningen upgrade.
gvim
--
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: Leiningen 2.4.2 upgrade causing problems
A little more data:
I can reproduce the same thing on Ubuntu 12.04.3 LInux running OpenJDK
1.6.0_31, so there is nothing OS or JVM-specific about this that I can tell.
Also, it happens with the following being the complete contents of my
~/.lein/profiles.clj file:
{:user {:plugins [[co.paralleluniverse/pulsar 0.5.0]]}}
The common denominator seems to be a dependence on data.priority-map, even
if only indirectly. core.cache and core.typed both depend on it, and I am
sure there are other projects that depend on it directly or indirectly, too.
Andy
On Wed, Jun 18, 2014 at 9:49 AM, Andy Fingerhut andy.finger...@gmail.com
wrote:
Recommendation: If you see this problem, and you have Eastwood in your
~/.lein/profiles.clj file, upgrade Eastwood to version 0.1.4, or go back to
Leiningen 2.3.4.
More details:
I have been able to reproduce an exception when running 'lein help new'
outside of any Leiningen project in these conditions:
Mac OS X 10.8.5
JVM 1.7.0_51
Leiningen 2.4.2
~/.lein/profiles.clj contains {:user {:plugins [[jonase/eastwood
0.1.2]]}} or an older Eastwood version
The exception goes away if I change to Leiningen 2.3.4, or if I upgrade to
Eastwood 0.1.3 or later.
I do not know the reason for the exception, but it makes some sense that
upgrading to Eastwood 0.1.3 or later makes a difference (0.1.4 is the
latest released version). Why? Because a change made in Eastwood version
0.1.3 was to make a copy of all Clojure contrib libraries inside of
Eastwood itself, and renaming their namespaces. This helped eliminate some
contrib library version number conflicts when using Eastwood on some
projects that also used those contrib libraries.
Thus Eastwood 0.1.2 depends on data.priority-map, but only indirectly
through tools.analyzer.jvm and its dependencies. Below is the output of
'lein deps :tree' for Eastwood 0.1.2, in case it helps anyone track down
what is going on:
% git clone https://github.com/jonase/eastwood.git
% git checkout eastwood-0.1.2
% lein deps :tree
[clojure-complete 0.2.3 :exclusions [[org.clojure/clojure]]]
[leinjacker 0.4.1]
[org.clojure/core.contracts 0.0.1]
[org.clojure/core.unify 0.5.3]
[org.clojars.brenton/google-diff-match-patch 0.1]
[org.clojure/clojure 1.6.0]
[org.clojure/tools.analyzer.jvm 0.1.0-beta10]
[org.clojure/core.memoize 0.5.6]
[org.clojure/core.cache 0.6.3]
[org.clojure/data.priority-map 0.0.2]
[org.ow2.asm/asm-all 4.1]
[org.clojure/tools.analyzer 0.1.0-beta10]
[org.clojure/tools.macro 0.1.2]
[org.clojure/tools.namespace 0.2.4]
[org.clojure/tools.nrepl 0.2.3 :exclusions [[org.clojure/clojure]]]
[org.clojure/tools.reader 0.8.3]
Andy
On Wed, Jun 18, 2014 at 9:12 AM, Sean Corfield s...@corfield.org wrote:
I am using Eastwood 0.1.2 without problems with Leiningen 2.4.2 but
perhaps Stefan and others are seeing conflicts because of other stuff in
~/.lein/profiles.clj with Eastwood?
gvim seems to have isolated it to pulsar.
Nearly all of the problems I see reported with Leiningen end up being due
to having a lot of stuff in the user profile...
Sean
On Jun 18, 2014, at 2:08 AM, Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com wrote:
Someone was having the same issue, solved by upgrading Eastwood plugin to
0.1.2.
Hope that helps.
Thanks,
Ambrose
On Wed, Jun 18, 2014 at 11:05 AM, Sean Corfield s...@corfield.org
wrote:
works for me...
Leiningen 2.4.2; Java build 1.8.0_05-b13; OS X 10.8.5 - lein help new
works fine outside of a project and also inside the context of a
project that depends on Clojure 1.6.0.
Are you running lein inside a project or outside? What do you have in
your profiles.clj file?
Sean
On Tue, Jun 17, 2014 at 10:45 AM, gvim gvi...@gmail.com wrote:
OS X Mountain Lion / lein 2.4.2 / clojure 1.6.0 / Java(TM) SE
Runtime
Environment (build 1.8.0_05-b13)
Running `lein help new` I'm getting an exception including this:
Caused by: java.io.FileNotFoundException: Could not locate
clojure/data/priority_map__init.class or clojure/data/priority_map.clj
on
classpath:
at clojure.lang.RT.load(RT.java:443)
Everything was working before the recent Leiningen upgrade.
gvim
--
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.
ClojureScript ^:export defprotocol
Is there a way to indicate that a (ClojureScript) protocol is intended to be used from the host? Details: I can define a protocol and an implementation of it in ClojureScript using defprotocol and reify. I can also successfully call methods on reified instances returned to the host (Obj-C embedding JavaScriptCore on iOS). The method names are mangled: In addition to the expected and usual conversion of hyphens to underscores, the mangled names incorporate dollar signs ($) and arity encoding, an example of which is: my$full$ns$MyProtocol$a_method_defined_in_this_protocol$arity$1 This can be called, passing this mangled string in as the method name of JSValue -invokeMethod:withArguments:. All cool (so long as this mangling is stable from one ClojureScript release to the next—but it smells like the mangling could be an implementation detail, subject to change). The killer is if I turn on Google Closure advanced optimizations; these mangled names get renamed. Is there a way to indicate the protocol names should be preserved? (Analogous to the way ^:export can be used on function definitions.) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ClojureScript ^:export defprotocol
On iOS is advanced compilation really necessary? :simple + :static-fns true should suffice. On Wednesday, June 18, 2014, Mike Fikes mikefi...@me.com wrote: Is there a way to indicate that a (ClojureScript) protocol is intended to be used from the host? Details: I can define a protocol and an implementation of it in ClojureScript using defprotocol and reify. I can also successfully call methods on reified instances returned to the host (Obj-C embedding JavaScriptCore on iOS). The method names are mangled: In addition to the expected and usual conversion of hyphens to underscores, the mangled names incorporate dollar signs ($) and arity encoding, an example of which is: my$full$ns$MyProtocol$a_method_defined_in_this_protocol$arity$1 This can be called, passing this mangled string in as the method name of JSValue -invokeMethod:withArguments:. All cool (so long as this mangling is stable from one ClojureScript release to the next—but it smells like the mangling could be an implementation detail, subject to change). The killer is if I turn on Google Closure advanced optimizations; these mangled names get renamed. Is there a way to indicate the protocol names should be preserved? (Analogous to the way ^:export can be used on function definitions.) -- 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: ClojureScript ^:export defprotocol
'any problem.. fixed.. by another layer of indirection' You could also just make exportable functions that call the protocols, keeping them more as impl-details, core.cljs does this, and you gain things like varargs (hmm, do protocol-varargs work on cljs? nope: http://dev.clojure.org/jira/browse/CLJS-362 ) On Wed, Jun 18, 2014 at 2:34 PM, David Nolen dnolen.li...@gmail.com wrote: On iOS is advanced compilation really necessary? :simple + :static-fns true should suffice. On Wednesday, June 18, 2014, Mike Fikes mikefi...@me.com wrote: Is there a way to indicate that a (ClojureScript) protocol is intended to be used from the host? Details: I can define a protocol and an implementation of it in ClojureScript using defprotocol and reify. I can also successfully call methods on reified instances returned to the host (Obj-C embedding JavaScriptCore on iOS). The method names are mangled: In addition to the expected and usual conversion of hyphens to underscores, the mangled names incorporate dollar signs ($) and arity encoding, an example of which is: my$full$ns$MyProtocol$a_method_defined_in_this_protocol$arity$1 This can be called, passing this mangled string in as the method name of JSValue -invokeMethod:withArguments:. All cool (so long as this mangling is stable from one ClojureScript release to the next—but it smells like the mangling could be an implementation detail, subject to change). The killer is if I turn on Google Closure advanced optimizations; these mangled names get renamed. Is there a way to indicate the protocol names should be preserved? (Analogous to the way ^:export can be used on function definitions.) -- 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 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: 56 second GC on Heroku - seems a bit long
On Monday, June 16, 2014 1:47:14 PM UTC-4, Brian Marick wrote: We have a small Clojure app on Heroku that performs backend tasks for a Rails app. Low traffic (like a request a minute). Heap is 400M. We've been having long (10 sec) GC pauses using both the default and G1 GC (both untuned). Browsing our logs today, I found: [GC pause (young) 156M-36M(400M), 56.0281380 secs] A minute for GC seems… excessive. Our other Clojure apps also have GC problems. 1. Is this something peculiar to Heroku? Clojure in small-memory environments? I have very little experience with non-Clojure java apps, but a coworker says: I've run JVMs with +20g heaps, and *never* seen 10s pauses, let alone a whole f%#^$ing minute. 2. Is there lore about appropriate GC tweaks for Clojure backend server apps? If it's feasible, I would attempt to run the same Clojure application in a 400MB-constrained JVM on a developer workstation and see what kind of garbage collection times you get. Hopefully that gives you a useful point of comparison. Obviously if you see the same long pauses the problem is related to your application code or Clojure, period. If you get fast garbage collections, then it's a Heroku-specific problem. Good luck. -Mike -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ClojureScript ^:export defprotocol
Even without JIT available in JavaScriptCore, I have been unable to notice a difference in the on-device performance of the “view controller” code I have been writing when turning on :advanced. Thanks for the suggestion, I'll go with :simple and :static-fns. The reified protocol instance works with those optimizations. On Wednesday, June 18, 2014 2:34:45 PM UTC-4, David Nolen wrote: On iOS is advanced compilation really necessary? :simple + :static-fns true should suffice. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ClojureScript ^:export defprotocol
Right, Gary, Initially I simply wrote exported functions. The motivation for experimenting with protocols is so that I can write a ClojureScript protocol that mimics, say the iOS UITableViewDataSource Objective-C @protocol. Then, with that in place, I can write ClojureScript reifications of that protocol to be passed back to Objective-C. It is then a simple matter on the Objective-C side to make that reification *be* a UITableView's dataSource delegate (with the help of a little reusable wrapper Obj-C object around the JSValue.) In addition to perhaps keeping things tidy (keeping like methods together), it makes it easier to pass multiple @protocol instances back to iOS. (Imagine the case of two or more table views on one iOS screen, each with their own distinct ClojureScriipt implementation.) Also, a lot of this ends up being boilerplate that needs to only be written once, and then, I recoup the costs of fleshing out this plumbing by simply spitting out a (reify ... ) form whenever needed. Arguably, none of this is required because all of the UITableViewDataSource methods have the tableView as the first argument, which could be used by straightforward exported functions to dispatch or otherwise switch to the right implementation, which could in turn be a reified protocol. It just seems that, since Objective-C *wants* an object as a dataSource, that it would be interesting to try to satisfy that need (more or less directly) using the facilities available in ClojureScript. I'll ditch all of this when Apple introduces FunctionalSwift along with functional APIs, and the Clojure(Swift) compiler targets that new language. :) - Mike On Wednesday, June 18, 2014 2:48:33 PM UTC-4, Gary Trakhman wrote: 'any problem.. fixed.. by another layer of indirection' You could also just make exportable functions that call the protocols, keeping them more as impl-details, core.cljs does this, and you gain things like varargs (hmm, do protocol-varargs work on cljs? nope: http://dev.clojure.org/jira/browse/CLJS-362 ) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ClojureScript ^:export defprotocol
I was just telling a local ios dev there's like five guys using clojure + objective-c. To me it's impressive. To them, well, I don't know what they'd think :-). On Wednesday, June 18, 2014, Mike Fikes mikefi...@me.com wrote: Right, Gary, Initially I simply wrote exported functions. The motivation for experimenting with protocols is so that I can write a ClojureScript protocol that mimics, say the iOS UITableViewDataSource Objective-C @protocol. Then, with that in place, I can write ClojureScript reifications of that protocol to be passed back to Objective-C. It is then a simple matter on the Objective-C side to make that reification *be* a UITableView's dataSource delegate (with the help of a little reusable wrapper Obj-C object around the JSValue.) In addition to perhaps keeping things tidy (keeping like methods together), it makes it easier to pass multiple @protocol instances back to iOS. (Imagine the case of two or more table views on one iOS screen, each with their own distinct ClojureScriipt implementation.) Also, a lot of this ends up being boilerplate that needs to only be written once, and then, I recoup the costs of fleshing out this plumbing by simply spitting out a (reify ... ) form whenever needed. Arguably, none of this is required because all of the UITableViewDataSource methods have the tableView as the first argument, which could be used by straightforward exported functions to dispatch or otherwise switch to the right implementation, which could in turn be a reified protocol. It just seems that, since Objective-C *wants* an object as a dataSource, that it would be interesting to try to satisfy that need (more or less directly) using the facilities available in ClojureScript. I'll ditch all of this when Apple introduces FunctionalSwift along with functional APIs, and the Clojure(Swift) compiler targets that new language. :) - Mike On Wednesday, June 18, 2014 2:48:33 PM UTC-4, Gary Trakhman wrote: 'any problem.. fixed.. by another layer of indirection' You could also just make exportable functions that call the protocols, keeping them more as impl-details, core.cljs does this, and you gain things like varargs (hmm, do protocol-varargs work on cljs? nope: http://dev.clojure.org/jira/browse/CLJS-362 ) -- 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: ClojureScript ^:export defprotocol
That's cool. I see no reason why Clojure / ClojureScript's “reach” can't extend significantly into iOS. On Wednesday, June 18, 2014 3:58:18 PM UTC-4, Gary Trakhman wrote: I was just telling a local ios dev there's like five guys using clojure + objective-c. To me it's impressive. To them, well, I don't know what they'd think :-). -- 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: fn and let are special forms or macros?
Interesting - thanks! Looks like doing `symbol is a good way of telling whether something is a special symbol or not. If syntax-quote results in namespace-qualification it then it *is not* special (with the exception of import*); if it does not namespace qualify it, then it *is* special. Previously I've been using the fact that (source symbol) comes up with Source not found to indicate that a symbol might be special. But not sure how reliable this method is. I imagine there might be other situations where the source code cannot be found. Cheers, Mark. On Wednesday, June 18, 2014 6:26:04 PM UTC+9:30, Ambrose Bonnaire-Sergeant wrote: Hi Mark, Here's a brief doc on special forms: http://clojure-doc.org/articles/language/macros.html#special-forms-in-detail Thanks, Ambrose On Wed, Jun 18, 2014 at 12:13 PM, Mark P pier...@gmail.com javascript: wrote: Thanks Tassilo for the explanation - much appreciated! I have been searching the web and searching clojure text books for the last two hours trying to find the answer to this same question. Finally I stumbled onto this thread! I realize that hiding the complexity of distinctions between fn / fn* and let / let* etc might make the documentation more accessible for some users, but for others (like me and presumably also Plínio) it makes it really hard to track down what is *really* going on. I wish this distinction was part of the formal documentation. Does anyone know of documentation anywhere that does include these kinds of distinction? Thanks, Mark. On Thursday, 6 March 2014 02:27:26 UTC+10:30, Tassilo Horn wrote: Plínio Balduino pbal...@gmail.com writes: Hi Plínio, Clojure.org says fn and let are special forms, but using the macro sourceshows that both are macros calling fn* and let* respectivelly. So fn and let are special special forms, or clojure.org is incorrect/outdated? Well, they are correct from a user's point of view. One never uses the real special forms fn* and let*. If fn and let are really special forms and not macros, could you explain why? fn and let (and also loop) are macros around the real special forms fn* and let* (and loop*) that add support for destructuring. For example, (let [[a b] [1 2]] (+ a b)) expands to (let* [vec__8592 [1 2] a (clojure.core/nth vec__8592 0 nil) b (clojure.core/nth vec__8592 1 nil)] (+ a b)) where the destructuring has been transformed to normal code already. Bye, Tassilo -- 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: fn and let are special forms or macros?
user= (source special-symbol?)
(defn special-symbol?
Returns true if s names a special form
{:added 1.0
:static true}
[s]
(contains? (. clojure.lang.Compiler specials) s))
nil
user= (keys (. clojure.lang.Compiler specials))
( monitor-exit case* try reify* finally loop* do letfn* if
clojure.core/import* new deftype* let* fn* recur set! . var quote catch
throw monitor-enter def)
On Wed, Jun 18, 2014 at 8:02 PM, Mark P pierh...@gmail.com wrote:
Interesting - thanks!
Looks like doing `symbol is a good way of telling whether something is a
special symbol or not. If syntax-quote results in namespace-qualification
it then it *is not* special (with the exception of import*); if it does
not namespace qualify it, then it *is* special.
Previously I've been using the fact that (source symbol) comes up with
Source not found to indicate that a symbol might be special. But not
sure how reliable this method is. I imagine there might be other
situations where the source code cannot be found.
Cheers,
Mark.
On Wednesday, June 18, 2014 6:26:04 PM UTC+9:30, Ambrose Bonnaire-Sergeant
wrote:
Hi Mark,
Here's a brief doc on special forms: http://clojure-doc.org/
articles/language/macros.html#special-forms-in-detail
Thanks,
Ambrose
On Wed, Jun 18, 2014 at 12:13 PM, Mark P pier...@gmail.com wrote:
Thanks Tassilo for the explanation - much appreciated!
I have been searching the web and searching clojure text books for the
last two hours trying to find the answer to this same question. Finally I
stumbled onto this thread!
I realize that hiding the complexity of distinctions between fn / fn*
and let / let* etc might make the documentation more accessible for some
users, but for others (like me and presumably also Plínio) it makes it
really hard to track down what is *really* going on. I wish this
distinction was part of the formal documentation.
Does anyone know of documentation anywhere that does include these kinds
of distinction?
Thanks,
Mark.
On Thursday, 6 March 2014 02:27:26 UTC+10:30, Tassilo Horn wrote:
Plínio Balduino pbal...@gmail.com writes:
Hi Plínio,
Clojure.org says fn and let are special forms, but using the macro
sourceshows that both are macros calling fn* and let* respectivelly.
So fn and let are special special forms, or clojure.org is
incorrect/outdated?
Well, they are correct from a user's point of view. One never uses the
real special forms fn* and let*.
If fn and let are really special forms and not macros, could you
explain why?
fn and let (and also loop) are macros around the real special forms fn*
and let* (and loop*) that add support for destructuring. For example,
(let [[a b] [1 2]]
(+ a b))
expands to
(let*
[vec__8592 [1 2]
a (clojure.core/nth vec__8592 0 nil)
b (clojure.core/nth vec__8592 1 nil)]
(+ a b))
where the destructuring has been transformed to normal code already.
Bye,
Tassilo
--
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 email
to clojure+unsubscr...@googlegroups.com.
For more
Re: fn and let are special forms or macros?
Wonderful - thanks Andy!
On Thursday, June 19, 2014 12:40:24 PM UTC+9:30, Andy Fingerhut wrote:
user= (source special-symbol?)
(defn special-symbol?
Returns true if s names a special form
{:added 1.0
:static true}
[s]
(contains? (. clojure.lang.Compiler specials) s))
nil
user= (keys (. clojure.lang.Compiler specials))
( monitor-exit case* try reify* finally loop* do letfn* if
clojure.core/import* new deftype* let* fn* recur set! . var quote catch
throw monitor-enter def)
--
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.
