Re: What does IOC in terms of core.async mean?
A normal function just runs naturally through its code -- it can't abort/suspend/pause/defer evaluation. (Only the JVM or kernel can suspend things for you safely.) The inversion of control macros enable such capabilities for Clojure code while preserving normal semantics. It allows code to *yield* a thread to other code when a blocking channel operation is encountered [! ! alt!]. Now the specific *mechanism* that core.async uses internally to acheive this happens to be a state machine with callbacks, but that's implementation detail. IOC just means letting something else control the evaluation of the function's code. There is an example of another simpler IOC controller in the core.async tests, called 'runner'. Others are possible... preserving semantics is the key. (ioc [Ordinary code can be written many ways, like in a haiku]) = [[Ordinary code] [can be written many ways] [like in a haiku]] On Monday, August 19, 2013 6:42:01 AM UTC-4, Michal Till wrote: I kinda understand the whole problem and I also understand that this has nothing to do with the OO IOC pattern, but I still don't exactly get what is meant by this term. What is inverting what and where? What does control refer to exactly - compared to callbacks? M. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: tools for minimizing forward declaration
On Mon, Aug 19, 2013 at 11:09 PM, Armando Blancas abm221...@gmail.com wrote: I'll point out as well that though I thought Yegge's criticisms of Clojure were a bit polemical (I guess that's his style), the single pass compiler issue was one of his biggest gripes, and I do think it still rings true. I feel like I have to babysit clojure in this regard, when I usually feel like clojure is babysitting me! :) Have you seen this? https://news.ycombinator.com/item?id=2467359 That's what I was referring to. Was there something specific about it that you wanted to call out? :) -- In Christ, Timmy V. http://blog.twonegatives.com/ http://five.sentenc.es/ -- Spend less time on mail -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: tools for minimizing forward declaration
Tim Visher tim.vis...@gmail.com writes: On Mon, Aug 19, 2013 at 11:09 PM, Armando Blancas abm221...@gmail.com wrote: I'll point out as well that though I thought Yegge's criticisms of Clojure were a bit polemical (I guess that's his style), the single pass compiler issue was one of his biggest gripes, and I do think it still rings true. I feel like I have to babysit clojure in this regard, when I usually feel like clojure is babysitting me! :) Have you seen this? https://news.ycombinator.com/item?id=2467359 That's what I was referring to. Was there something specific about it that you wanted to call out? :) Actually, that's quite interesting, and I hadn't seen it before. I can understand the reasons why forward declaration makes the implementation of clojure easy, but it does seem to be pushing the burden onto the programmer, rather than the language designer. I'm particularly not convinced by the argument that Lisps were designed to receive a set of interactions/forms via a REPL; forward declaration introduces another circumstance where the state of your REPL can get in a twist: your source might look like this... (def y) (defn x[] y) then get changed to (defn x[] y) (def y) and working quite happily *until* you restart the REPL. Re-starting just in case is a problem with most REPLs, and this doesn't help. On the whole, I think I prefer compile warnings, rather than everything breaking. I seem to have stirred up a bit of a nest. 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/groups/opt_out.
Re: Clojure Macro Tutorial
Hi Steve, this is great for us n00bs. Thank you! On Aug 19, 2013, at 9:10 AM, Steve Shogren steve.a.shog...@gmail.com wrote: http://deliberate-software.com/intro-to-macros/ I wrote this tutorial up for a friend of mine who is a Ruby programmer thinking of learning Clojure, as my defense of why Clojure is worth his time. I will welcome any advice, code reviews, or suggestions about the post or code samples. Thanks! Steve -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. MARCUS BLANKENSHIP \\\ Owner, Problem Solver, Thinker \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Immutant 1.0.0 released
Here you go, Sean: http://immutant.org/news/2013/08/20/openshift-clustering/ Feedback appreciated! Jim On Thursday, August 1, 2013 1:22:05 PM UTC-4, Sean Corfield wrote: Great news! Every conference I've been to lately, I've been bugging the OpenShift guys - I know they have been rewriting the cartridge spec so I'm glad to hear an Immutant cartridge is coming. Once that cartridge is available, I'll have a play with it (I don't have time right now to do anything that isn't standard / turn key). Sean On Thu, Aug 1, 2013 at 9:48 AM, Jim Crossley j...@crossleys.orgjavascript: wrote: Nice timing, Sean! :-) On Wednesday, I was able to finally get Immutant clustering successfully on OpenShift. Load-balanced messaging and web, failover for daemons and jobs, replication for caching, everything seems to work. This is with both HornetQ and Infinispan using JGroups so automatic peer discovery just works when I add a gear. I'm now working on the cartridge, though the quickstart will work (with a slight modification I need to push) if you want to play with it now. I'll blog about it soon. Jim On Thu, Aug 1, 2013 at 12:32 PM, Sean Corfield seanco...@gmail.comjavascript: wrote: Excellent! I look forward to trying this! Any plans for a Clojure / Immutant cartridge for OpenShift? Sean On Wed, Jul 31, 2013 at 1:49 PM, Jim Crossley jcros...@gmail.comjavascript: wrote: Today we finally released Immutant 1.0.0! Read about it here: http://bit.ly/imm100 For those unfamiliar, Immutant is an application server for Clojure. It's an integrated platform providing web, messaging, caching, scheduling, XA transactions, clustering, and daemons built on JBoss AS7 that aims to reduce the incidental complexity found in real-world applications. Have fun! Jim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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/groups/opt_out. -- 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.comjavascript: 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/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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/groups/opt_out. -- 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
Re: tools for minimizing forward declaration
REPL versus compilation in Lisp have for many decades been two different things. In the REPL, you were allowed to refer to symbols that were undefined in the current lexical scope, hoping that at runtime they would eventually exists some where on the stack. To compile such code you needed to add declarations for this stuff not in the lexical scope of the compiler to tell it that it would be defined later else where. Either later in the same file or in a different one, this did not matter. Otherwise the compiler would simply fail. Compilation was an odd thing in Lisp initially and it was sufficiently different from the REPL to require twists in your code when you wanted to compile it. It was seen as a second step, after dev had been done in the REPL. The REPL is there to swallow forms which are unrelated. The kind of compilation you would like to see requires something more (the file approach ?). If we fall too much on the compilation/optimization side, then this relative independence of forms will eventually break and create it's own set of problems at the REPL. Yes Lisps were designed mainly for REPL interaction, compiling came afterward. I was a witness of this era mainly because I am a dinosaur :) Clojure's approach is somewhere closer to the compilation side in view of the requirements of it's supporting container but I do not think that it can get much closer without breaking some of that dynamic REPL stuff that speeds up development and that we like. Luc P. Tim Visher tim.vis...@gmail.com writes: On Mon, Aug 19, 2013 at 11:09 PM, Armando Blancas abm221...@gmail.com wrote: I'll point out as well that though I thought Yegge's criticisms of Clojure were a bit polemical (I guess that's his style), the single pass compiler issue was one of his biggest gripes, and I do think it still rings true. I feel like I have to babysit clojure in this regard, when I usually feel like clojure is babysitting me! :) Have you seen this? https://news.ycombinator.com/item?id=2467359 That's what I was referring to. Was there something specific about it that you wanted to call out? :) Actually, that's quite interesting, and I hadn't seen it before. I can understand the reasons why forward declaration makes the implementation of clojure easy, but it does seem to be pushing the burden onto the programmer, rather than the language designer. I'm particularly not convinced by the argument that Lisps were designed to receive a set of interactions/forms via a REPL; forward declaration introduces another circumstance where the state of your REPL can get in a twist: your source might look like this... (def y) (defn x[] y) then get changed to (defn x[] y) (def y) and working quite happily *until* you restart the REPL. Re-starting just in case is a problem with most REPLs, and this doesn't help. On the whole, I think I prefer compile warnings, rather than everything breaking. I seem to have stirred up a bit of a nest. 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/groups/opt_out. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Immutant 1.0.0 released
Nice! Thanx. More stuff for me to read / play with in my copious free time :) Sean On Tue, Aug 20, 2013 at 9:48 AM, Jim Crossley jcrossl...@gmail.com wrote: Here you go, Sean: http://immutant.org/news/2013/08/20/openshift-clustering/ Feedback appreciated! Jim On Thursday, August 1, 2013 1:22:05 PM UTC-4, Sean Corfield wrote: Great news! Every conference I've been to lately, I've been bugging the OpenShift guys - I know they have been rewriting the cartridge spec so I'm glad to hear an Immutant cartridge is coming. Once that cartridge is available, I'll have a play with it (I don't have time right now to do anything that isn't standard / turn key). Sean On Thu, Aug 1, 2013 at 9:48 AM, Jim Crossley j...@crossleys.org wrote: Nice timing, Sean! :-) On Wednesday, I was able to finally get Immutant clustering successfully on OpenShift. Load-balanced messaging and web, failover for daemons and jobs, replication for caching, everything seems to work. This is with both HornetQ and Infinispan using JGroups so automatic peer discovery just works when I add a gear. I'm now working on the cartridge, though the quickstart will work (with a slight modification I need to push) if you want to play with it now. I'll blog about it soon. Jim On Thu, Aug 1, 2013 at 12:32 PM, Sean Corfield seanco...@gmail.com wrote: Excellent! I look forward to trying this! Any plans for a Clojure / Immutant cartridge for OpenShift? Sean On Wed, Jul 31, 2013 at 1:49 PM, Jim Crossley jcros...@gmail.com wrote: Today we finally released Immutant 1.0.0! Read about it here: http://bit.ly/imm100 For those unfamiliar, Immutant is an application server for Clojure. It's an integrated platform providing web, messaging, caching, scheduling, XA transactions, clustering, and daemons built on JBoss AS7 that aims to reduce the incidental complexity found in real-world applications. Have fun! Jim -- -- 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/groups/opt_out. -- 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 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/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to 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/groups/opt_out. -- 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
Re: tools for minimizing forward declaration
That's what I was referring to. Was there something specific about it that you wanted to call out? :) Nope; just wanted to bring it up. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
NotSerializableException clojure.core.Vec
Hi all,
I've a rather strange problem...I know that all clojure collections
implement Serializable but when I try to use standard Java serialization
on a vector of records I get this exception:
/NotSerializableException clojure.core.Vec
java.io.ObjectOutputStream.writeObject0 (ObjectOutputStream.java:1180)/
observe this:
Clondie24.games.chess= (ut/serialize! @current-chessItems DELETE)
*
**NotSerializableException clojure.core.Vec
java.io.ObjectOutputStream.writeObject0 (ObjectOutputStream.java:1180)*
Clondie24.games.chess= (class @current-chessItems)
clojure.lang.PersistentVector
Clondie24.games.chess= (ut/serialize! [:A :B :C :D] DELETE) *;;SUCCESS*
nil
Clondie24.games.chess= (first @current-chessItems)
#Clondie24.games.chess.ChessPiece{:image
#chess$starting_chessItems$fn__12387$fn__12388
Clondie24.games.chess$starting_chessItems$fn__12387$fn__12388@2a6446c9,
:position [0 0], :rank rook, :value 5, :direction 1}
Clondie24.games.chess= (ut/serialize! *1 DELETE2)
NotSerializableException clojure.core.Vec
java.io.ObjectOutputStream.writeObject0 (ObjectOutputStream.java:1180)
Clondie24.games.chess= (ut/serialize! (dissoc *1 :image) DELETE3)
;;MAYBE THE FUNCTION IS TO BLAME
NotSerializableException clojure.core.Vec
java.io.ObjectOutputStream.writeObject0 (ObjectOutputStream.java:1180)
Clondie24.games.chess= *1
#Clondie24.games.chess.ChessPiece{:image
#chess$starting_chessItems$fn__12387$fn__12388
Clondie24.games.chess$starting_chessItems$fn__12387$fn__12388@2a6446c9,
:position [0 0], :rank rook, :value 5, :direction 1}
Clondie24.games.chess= (ut/serialize! (dissoc *1 :position) DELETE3)
*;;SUCCESS*
nil
Clondie24.games.chess= (class (get *2 :position))
clojure.core.Vec
it seems to me that the [:position [0 0]] slot in the record is causing
the problems because it is a Vec and not a Vector...but then this is my
defrecord definition:
(defrecord ChessPiece [ image ;;not really an image but a fn that
fetches the image
^clojure.lang.PersistentVector position
rank ^long value direction]
core/Piece
...
... )
any ideas? should I not have type hinted the record?
thanks in advance for your time :)
Jim
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
java.lang.IndexOutOfBoundsException when calling namespaced functions inside the 'go macro in core.async
Hi, y'all. I'm having trouble with core.async in ClojureScript. Inside 'let forms in 'go blocks, making calls to namespaced functions causes the compiler to die with an IndexOutOfBoundsException. For example: (ns my-ns (:require [bar])) (go (let [foo (bar/baz 1 2 3)] (.log js/console foo))) When :refer-ing to baz without the bar/ prefix, the compiler works again and everything is fine. I haven't used core.async in Clojure yet, so I don't know if it also has that problem there. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: java.lang.IndexOutOfBoundsException when calling namespaced functions inside the 'go macro in core.async
Sorry, I meant: (go (let [foo (! (bar/baz 1 2 3))] (.log js/console foo))) I also sometimes get the following error: clojure.lang.ExceptionInfo: clojure.lang.Namespace cannot be cast to clojure.lang.Named at line 26 src/foo/bar/baz.cljs -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] iniconfig 0.2.0 released
Hi all, I've just uploaded iniconfig 0.2.0 to Clojars. iniconfig is minimal Clojure library designed to read ini files. It uses the number sign '#' as comment character and allows multi-line values. iniconfig and it's documentation can be found on github: https://github.com/brainbot-com/clj-iniconfig -- Cheers Ralf -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Multiple Clojure contexts in the same JVM
Howdy, I have an application where I need multiple independent Clojure contexts running in the same JVM. I've played around with a custom classloader, but when I try to eval code (calling RT.eval.invoke via reflection), I wind up with: java.lang.ClassCastException: clojure.core$eval1 cannot be cast to clojure.lang.IFn It seems that someplace the clojure.lang.IFn interface is being loaded around my classloader. Can someone point me to a way to run multiple Clojure contexts in the same JVM? Thanks, David PS -- Interestingly, invoking RT.loadResourceScript via reflection works just fine... so my current workaround is to do that... but it's less than optimal. -- Telegram, Simply Beautiful CMS https://telegr.am Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Multiple Clojure contexts in the same JVM
Just FYI (and you probably already know this David), most of the clojure.lang.RT class is considered an implementation detail and is subject to change without notice. I believe 1.6 will bring a new API that is intended to provide a supported way to embed Clojure into JVM-based applications. Based on posts I've seen on the mailing lists from Clojure/core folks, I've restricted my use to just RT.var() and I load source files like this: RT.var( clojure.core, load ).invoke( filepath ); RT.var( my.namespace, my-fun ).invoke( 1, 2, 3 ); // (my.namespace/my-fun 1 2 3) RT.var( my.namespace, my-var ).deref(); // access my.namespace/my-var directly // same as (deref #'my.namespace/my-var) I haven't pushed too much at the boundaries of classloaders tho' so there may well be dragons there, but the above works for me for embedding Clojure in an existing JVM-based web application. Sean On Tue, Aug 20, 2013 at 1:35 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Howdy, I have an application where I need multiple independent Clojure contexts running in the same JVM. I've played around with a custom classloader, but when I try to eval code (calling RT.eval.invoke via reflection), I wind up with: java.lang.ClassCastException: clojure.core$eval1 cannot be cast to clojure.lang.IFn It seems that someplace the clojure.lang.IFn interface is being loaded around my classloader. Can someone point me to a way to run multiple Clojure contexts in the same JVM? Thanks, David PS -- Interestingly, invoking RT.loadResourceScript via reflection works just fine... so my current workaround is to do that... but it's less than optimal. -- Telegram, Simply Beautiful CMS https://telegr.am Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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/groups/opt_out.
Re: Multiple Clojure contexts in the same JVM
Sean, Thanks for the response. The issues that I've come across using code similar to yours is that if there are two people sharing the same namespace, they will over-write each others' stuff. I guess I'll wait for 1.6 unless others have ideas. Thanks, David On Tue, Aug 20, 2013 at 1:55 PM, Sean Corfield seancorfi...@gmail.comwrote: Just FYI (and you probably already know this David), most of the clojure.lang.RT class is considered an implementation detail and is subject to change without notice. I believe 1.6 will bring a new API that is intended to provide a supported way to embed Clojure into JVM-based applications. Based on posts I've seen on the mailing lists from Clojure/core folks, I've restricted my use to just RT.var() and I load source files like this: RT.var( clojure.core, load ).invoke( filepath ); RT.var( my.namespace, my-fun ).invoke( 1, 2, 3 ); // (my.namespace/my-fun 1 2 3) RT.var( my.namespace, my-var ).deref(); // access my.namespace/my-var directly // same as (deref #'my.namespace/my-var) I haven't pushed too much at the boundaries of classloaders tho' so there may well be dragons there, but the above works for me for embedding Clojure in an existing JVM-based web application. Sean On Tue, Aug 20, 2013 at 1:35 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Howdy, I have an application where I need multiple independent Clojure contexts running in the same JVM. I've played around with a custom classloader, but when I try to eval code (calling RT.eval.invoke via reflection), I wind up with: java.lang.ClassCastException: clojure.core$eval1 cannot be cast to clojure.lang.IFn It seems that someplace the clojure.lang.IFn interface is being loaded around my classloader. Can someone point me to a way to run multiple Clojure contexts in the same JVM? Thanks, David PS -- Interestingly, invoking RT.loadResourceScript via reflection works just fine... so my current workaround is to do that... but it's less than optimal. -- Telegram, Simply Beautiful CMS https://telegr.am Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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/groups/opt_out. -- Telegram, Simply Beautiful CMS https://telegr.am Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Multiple Clojure contexts in the same JVM
David Pollak feeder.of.the.be...@gmail.com writes: I have an application where I need multiple independent Clojure contexts running in the same JVM. Classlojure [1] can do this for you, taking care of correct initialisation, and evaluation. [1] https://github.com/flatland/classlojure pgpjGCdyjK4nh.pgp Description: PGP signature
[ANN] Leiningen 2.3.2 released
Hello everybody. I'm happy to announce the release of Leiningen 2.3.2, a minor bugfix release over 2.3.1. Changes include the following: * Write `.nrepl-port` file for better tool interoperability. (Phil Hagelberg) * Support targeted upgrades in `lein.bat`. (Shantanu Kumar) * Warn when projects rely on implicit AOT of `:main`. (Phil Hagelberg) * Fix a bug where implicit AOT of `:main` was disabled. (Phil Hagelberg) * Disable profile isolation by default. Will be back in 3.x. (Phil Hagelberg) The biggest change here the disabling of profile isolation (a new by default due to incompatibilities with certain projects that hard-code paths. Profile isolation was a new feature in 2.3.0 described in the FAQ: Leiningen supports isolating different profiles by their target directory. Simply specify `:target-path target/%s` in order to have each profile set use a different directory for generated files. Then you can put your `:aot` settings in the `:uberjar` profiles, and the .class files created from the AOT process will not affect normal development use. You can specify the profile-isolated `:target-path` in your `:user` profile if you want it applied across all the projects you work on. I still recommend using profile isolation since it helps avoid a number of subtle gotchas around stale AOT files and user-level dependencies being visible with downstream consumers, but you now have to opt-in to this feature by setting :target-path as described above. We've also fixed a bug where setting :main without setting :aot would no longer implicitly compile the :main namespace. It's still recommended to be explicit about what :aot you need, (in the :uberjar profile if applicable) but the old behaviour has been restored. You'll also want to add a .gitignore entry for the new .nrepl-port file which we're using for improved cross-tool compatibility; discussion of that feature is here: https://github.com/technomancy/leiningen/issues/1296 Thanks! -Phil pgpzQjycae2m5.pgp Description: PGP signature
Re: Multiple Clojure contexts in the same JVM
David Pollak writes: I have an application where I need multiple independent Clojure contexts running in the same JVM. You can use ShimDandy[1] to load multiple Clojure runtimes in the same JVM, and call into those runtimes from Java. That's what Immutant[2] and the Clojure language module for Vert.x[3] use currently to achieve runtime isolation. One gotcha with loading multiple Clojure runtimes is memory leaks - if you intend to load and unload more than a couple of runtimes, you'll quickly exhaust permgen. The workaround there is to wait for Clojure 1.6.0 (assuming CLJ-1125[4] gets applied), or use a fork of Clojure that has the CLJ-1125 fixes in it[5]. The ShimDandy docs are completely non-existent at this point, but an example of usage is [6]. If you have interest in using it, I'm happy to help you get started, and to write some docs. [1]: https://github.com/projectodd/shimdandy [2]: http://immutant.org/ [3]: https://github.com/vert-x/mod-lang-clojure [4]: http://dev.clojure.org/jira/browse/CLJ-1125 [5]: https://clojars.org/org.clojars.tcrawley/clojure [6]: https://github.com/vert-x/mod-lang-clojure/blob/master/lang-module/src/main/java/io/vertx/lang/clojure/ClojureVerticleFactory.java -- Toby Crawley http://immutant.org | http://torquebox.org -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
send agent inside doseq
Hi there, I've got a range of values and I'd like to run agents for each value per thread. For some reason I've got only one agents being updated. Not sure what's wrong here but I suspect must be doing something terrible stupid... Thanks! (doseq [s (range 30 35)] ;(println (format _%s s)) (intern *ns* (symbol (format _%s s) ) (agent s)) ;; set initial value (send @(intern *ns* (symbol (format _%s s))) + 100) ;; send agent and update value (println @(intern *ns* (symbol (format _%s s)) ));; deref ) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Another step towards the Connection Machine in Clojure
A core.async implementation of Per Brinch Hansen, Parallel Cellular Automata (1992): https://github.com/nodename/async-plgd#cellular -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: send agent inside doseq
If on the *println* you don't see the value updated, it's probably because the operation sent to the agent wasn't applied yet. Add a *(Thread/sleep 500)* in between the *send *and *println *expressions and you'll see the expected agents'. Cheers, JF On Wednesday, August 21, 2013 12:21:59 AM UTC+1, Kuba Roth wrote: Hi there, I've got a range of values and I'd like to run agents for each value per thread. For some reason I've got only one agents being updated. Not sure what's wrong here but I suspect must be doing something terrible stupid... Thanks! (doseq [s (range 30 35)] ;(println (format _%s s)) (intern *ns* (symbol (format _%s s) ) (agent s)) ;; set initial value (send @(intern *ns* (symbol (format _%s s))) + 100) ;; send agent and update value (println @(intern *ns* (symbol (format _%s s)) ));; deref ) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: send agent inside doseq
Very likely Juan, as seen here: (let [agents (map agent (range 30 35))] (doseq [a agents] (send a + 100) (println @a)) (doseq [a agents] (println @a))) For me that prints: 30 31 32 33 34 130 131 132 133 134 but I suspect that's more luck that anything since there's no reason the agent operations need to have finished before the second println. Kuba, as a separate issue, why are you trying to intern all those symbols? It's not very idiomatic. Sean On Tue, Aug 20, 2013 at 4:49 PM, juan.facorro juan.faco...@gmail.com wrote: If on the println you don't see the value updated, it's probably because the operation sent to the agent wasn't applied yet. Add a (Thread/sleep 500) in between the send and println expressions and you'll see the expected agents'. Cheers, JF On Wednesday, August 21, 2013 12:21:59 AM UTC+1, Kuba Roth wrote: Hi there, I've got a range of values and I'd like to run agents for each value per thread. For some reason I've got only one agents being updated. Not sure what's wrong here but I suspect must be doing something terrible stupid... Thanks! (doseq [s (range 30 35)] ;(println (format _%s s)) (intern *ns* (symbol (format _%s s) ) (agent s)) ;; set initial value (send @(intern *ns* (symbol (format _%s s))) + 100) ;; send agent and update value (println @(intern *ns* (symbol (format _%s s)) ));; deref ) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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/groups/opt_out.
as- macro enhancement request?
I like the as- macro, mostly because it'd theoretically obviate the need to include the Swiss Arrows library anymore. There's one reason why I keep going back to Swiss Arrows though: the ability to include single-arg functions in the chain that do not have the explicit token. i.e. in Swiss Arrows, I can do: (- foo bar (baz quux) blah) Note, it's clean and simple, no need for a bunch of noise and 's where not needed, only when calling functions with arity 1. But with as-, I have to do: (as- foo (bar ) (baz quux) (blah )) And that just seems unnecessarily noisy to me. Would love it if as- allowed removing unnecessary characters, this way: (as- foo bar (baz quux) blah) Anyway, very minor quibble, just putting it out there. Thanks. -ken -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: as- macro enhancement request?
Second- that would be a nice, and intuitive, enhancement. --- Joseph Smith j...@uwcreations.com @solussd On Aug 20, 2013, at 8:52 PM, Ken Restivo k...@restivo.org wrote: I like the as- macro, mostly because it'd theoretically obviate the need to include the Swiss Arrows library anymore. There's one reason why I keep going back to Swiss Arrows though: the ability to include single-arg functions in the chain that do not have the explicit token. i.e. in Swiss Arrows, I can do: (- foo bar (baz quux) blah) Note, it's clean and simple, no need for a bunch of noise and 's where not needed, only when calling functions with arity 1. But with as-, I have to do: (as- foo (bar ) (baz quux) (blah )) And that just seems unnecessarily noisy to me. Would love it if as- allowed removing unnecessary characters, this way: (as- foo bar (baz quux) blah) Anyway, very minor quibble, just putting it out there. Thanks. -ken -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: tools for minimizing forward declaration
There's a way to reconcile all of this: if you treat the environment as a value then I believe you can achieve both: - Incremental REPL-style commands that work immediately in the current environment - Arbitrary declaration order in files From a technical perspective, the environment would contain deferred compilation units that get compiled only when the symbols they require are all defined. This could be managed fairly efficiently using a dependency graph maintained by the compiler. Automatic recompilation of dependency graphs would also be possible, I believe - this would potentially allow some fun/scary stuff if you redefine things at runtime but I think it would work. I wrote about this idea a while back, there wan't very much interest at the time but I still think it's a powerful approach that could be applied to Clojure: https://groups.google.com/d/topic/clojure-dev/S8BawG7nzJA/discussion On Wednesday, 21 August 2013 00:54:07 UTC+8, Luc wrote: REPL versus compilation in Lisp have for many decades been two different things. In the REPL, you were allowed to refer to symbols that were undefined in the current lexical scope, hoping that at runtime they would eventually exists some where on the stack. To compile such code you needed to add declarations for this stuff not in the lexical scope of the compiler to tell it that it would be defined later else where. Either later in the same file or in a different one, this did not matter. Otherwise the compiler would simply fail. Compilation was an odd thing in Lisp initially and it was sufficiently different from the REPL to require twists in your code when you wanted to compile it. It was seen as a second step, after dev had been done in the REPL. The REPL is there to swallow forms which are unrelated. The kind of compilation you would like to see requires something more (the file approach ?). If we fall too much on the compilation/optimization side, then this relative independence of forms will eventually break and create it's own set of problems at the REPL. Yes Lisps were designed mainly for REPL interaction, compiling came afterward. I was a witness of this era mainly because I am a dinosaur :) Clojure's approach is somewhere closer to the compilation side in view of the requirements of it's supporting container but I do not think that it can get much closer without breaking some of that dynamic REPL stuff that speeds up development and that we like. Luc P. Tim Visher tim.v...@gmail.com javascript: writes: On Mon, Aug 19, 2013 at 11:09 PM, Armando Blancas abm2...@gmail.comjavascript: wrote: I'll point out as well that though I thought Yegge's criticisms of Clojure were a bit polemical (I guess that's his style), the single pass compiler issue was one of his biggest gripes, and I do think it still rings true. I feel like I have to babysit clojure in this regard, when I usually feel like clojure is babysitting me! :) Have you seen this? https://news.ycombinator.com/item?id=2467359 That's what I was referring to. Was there something specific about it that you wanted to call out? :) Actually, that's quite interesting, and I hadn't seen it before. I can understand the reasons why forward declaration makes the implementation of clojure easy, but it does seem to be pushing the burden onto the programmer, rather than the language designer. I'm particularly not convinced by the argument that Lisps were designed to receive a set of interactions/forms via a REPL; forward declaration introduces another circumstance where the state of your REPL can get in a twist: your source might look like this... (def y) (defn x[] y) then get changed to (defn x[] y) (def y) and working quite happily *until* you restart the REPL. Re-starting just in case is a problem with most REPLs, and this doesn't help. On the whole, I think I prefer compile warnings, rather than everything breaking. I seem to have stirred up a bit of a nest. Phil -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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/groups/opt_out. -- Softaddictslprefo...@softaddicts.ca javascript: sent by ibisMail
Re: as- macro enhancement request?
Your example could be written: (- foo bar (baz quuz) blah) But I suspect you meant something like this: (- foo bar (as- (baz whiz quuz)) blah) In other words, you use as- with - for just those cases where you need something that isn't in the first or last argument position. That's why it's (as- expr name forms) with the expression in the first argument position. Sean On Tue, Aug 20, 2013 at 6:52 PM, Ken Restivo k...@restivo.org wrote: I like the as- macro, mostly because it'd theoretically obviate the need to include the Swiss Arrows library anymore. There's one reason why I keep going back to Swiss Arrows though: the ability to include single-arg functions in the chain that do not have the explicit token. i.e. in Swiss Arrows, I can do: (- foo bar (baz quux) blah) Note, it's clean and simple, no need for a bunch of noise and 's where not needed, only when calling functions with arity 1. But with as-, I have to do: (as- foo (bar ) (baz quux) (blah )) And that just seems unnecessarily noisy to me. Would love it if as- allowed removing unnecessary characters, this way: (as- foo bar (baz quux) blah) Anyway, very minor quibble, just putting it out there. Thanks. -ken -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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/groups/opt_out.
Re: send agent inside doseq
Thanks Sean, your example looks much cleaner and most important works! The reason I looked into 'intern' can only be explained by totally lack of experience in Clojure and more general functional programming. My goal was to dynamically create a var inside the 'doseq' and apparently 'intern' is used in this cases. The 'def' special form didn't work for me... (not sure why). But as I said it was rather my lame attempt to make things work then any well thought out decision :) Thanks, Kuba On Tuesday, August 20, 2013 4:56:30 PM UTC-7, Sean Corfield wrote: Very likely Juan, as seen here: (let [agents (map agent (range 30 35))] (doseq [a agents] (send a + 100) (println @a)) (doseq [a agents] (println @a))) For me that prints: 30 31 32 33 34 130 131 132 133 134 but I suspect that's more luck that anything since there's no reason the agent operations need to have finished before the second println. Kuba, as a separate issue, why are you trying to intern all those symbols? It's not very idiomatic. Sean On Tue, Aug 20, 2013 at 4:49 PM, juan.facorro juan.f...@gmail.comjavascript: wrote: If on the println you don't see the value updated, it's probably because the operation sent to the agent wasn't applied yet. Add a (Thread/sleep 500) in between the send and println expressions and you'll see the expected agents'. Cheers, JF On Wednesday, August 21, 2013 12:21:59 AM UTC+1, Kuba Roth wrote: Hi there, I've got a range of values and I'd like to run agents for each value per thread. For some reason I've got only one agents being updated. Not sure what's wrong here but I suspect must be doing something terrible stupid... Thanks! (doseq [s (range 30 35)] ;(println (format _%s s)) (intern *ns* (symbol (format _%s s) ) (agent s)) ;; set initial value (send @(intern *ns* (symbol (format _%s s))) + 100) ;; send agent and update value (println @(intern *ns* (symbol (format _%s s)) ));; deref ) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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/groups/opt_out. -- 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/groups/opt_out.
Re: [ANN] Leiningen 2.3.2 released
Upgrading on Mac/Linux was painless as usual - and everything here seems to run fine with 2.3.2 - but Windows continues to be a pain in the rear... You can't lein upgrade so I updated the version string in lein.bat and tried lein self-install: C:\Users\Seanlein self-install Downloading Leiningen now... SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc syswgetrc = C:\gow/etc/wgetrc --2013-08-20 22:01:41-- https://cloud.github.com/downloads/technomancy/leiningen/leiningen-2.3.2-standalone.jar Resolving cloud.github.com... 54.240.188.252, 54.230.71.6, 54.230.70.21, ... Connecting to cloud.github.com|54.240.188.252|:443... connected. WARNING: cannot verify cloud.github.com's certificate, issued by `/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3': Self-signed certificate encountered. WARNING: certificate common name `*.cloudfront.net' doesn't match requested host name `cloud.github.com'. HTTP request sent, awaiting response... 403 Forbidden 2013-08-20 22:01:41 ERROR 403: Forbidden. Failed to download https://cloud.github.com/downloads/technomancy/leiningen/leiningen-2.3.2-standalone.jar You can't download that file via a browser either: This XML file does not appear to have any style information associated with it. The document tree is shown below. Error CodeAccessDenied/Code MessageAccess Denied/Message RequestIdBBF8809DA1520371/RequestId HostId Laq6Bi6lZlah+zalsro6LbnHl2hKt0fDsZO1Tvu6spiEjq8CghIMHLDSwk7XTm+k /HostId /Error I have HTTP_CLIENT set to wget --no-check-certificate -O as a global environment variable. Is this just a problem upgrading from 2.1.3 that is - finally - going to be a thing of the past from now on, or is there still work to do? Sean On Tue, Aug 20, 2013 at 3:11 PM, Phil Hagelberg p...@hagelb.org wrote: Hello everybody. I'm happy to announce the release of Leiningen 2.3.2, a minor bugfix release over 2.3.1. Changes include the following: * Write `.nrepl-port` file for better tool interoperability. (Phil Hagelberg) * Support targeted upgrades in `lein.bat`. (Shantanu Kumar) * Warn when projects rely on implicit AOT of `:main`. (Phil Hagelberg) * Fix a bug where implicit AOT of `:main` was disabled. (Phil Hagelberg) * Disable profile isolation by default. Will be back in 3.x. (Phil Hagelberg) The biggest change here the disabling of profile isolation (a new by default due to incompatibilities with certain projects that hard-code paths. Profile isolation was a new feature in 2.3.0 described in the FAQ: Leiningen supports isolating different profiles by their target directory. Simply specify `:target-path target/%s` in order to have each profile set use a different directory for generated files. Then you can put your `:aot` settings in the `:uberjar` profiles, and the .class files created from the AOT process will not affect normal development use. You can specify the profile-isolated `:target-path` in your `:user` profile if you want it applied across all the projects you work on. I still recommend using profile isolation since it helps avoid a number of subtle gotchas around stale AOT files and user-level dependencies being visible with downstream consumers, but you now have to opt-in to this feature by setting :target-path as described above. We've also fixed a bug where setting :main without setting :aot would no longer implicitly compile the :main namespace. It's still recommended to be explicit about what :aot you need, (in the :uberjar profile if applicable) but the old behaviour has been restored. You'll also want to add a .gitignore entry for the new .nrepl-port file which we're using for improved cross-tool compatibility; discussion of that feature is here: https://github.com/technomancy/leiningen/issues/1296 Thanks! -Phil -- 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/groups/opt_out.
Re: send agent inside doseq
On Tue, Aug 20, 2013 at 9:31 PM, Kuba Roth kuba.r...@gmail.com wrote: The reason I looked into 'intern' can only be explained by totally lack of experience in Clojure and more general functional programming. Ah, is your background OOP? You'll find the functional world is pretty different. No variables in the traditional sense, no uncontrolled mutation, no loops in the traditional sense, no state in the OOP sense. def and defn only create top-level definitions - bindings of values to symbols - and intern is really an implementation detail that you want to keep away from. As you can see from my example, you can create a sequence of agents easily enough as a data structure, and then you can perform operations on that data structure. Agents provide controlled mutation in that they start out with an initial value and you send them a series of function invocations and they take on new values as each function invocation is applied asynchronously. I wonder what you might be trying to achieve? Or perhaps this is just initial experimentation? One thing you'll find about Clojure is how rarely you need mutation. At World Singles we have about 18,000 lines of Clojure with just two agents (used to provide measured asynchronous DB updates for a couple of very specific situations) and 27 atoms, which are nearly all just caches - only half a dozen of those are really mutable state (and we're consolidating that). Welcome to Clojure! -- 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/groups/opt_out.
