Interrupting the Repl
Is there a way to interrupt the Repl when I've set to some kind of infinite loop without also shutting down the JVM entirely? -- 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
Re: Problem with Destructuring in A Function Call
What may confuse is that map destructuring swaps the positions of keys
and values as compared to map literals:
user (let [{x :body} {:body 42}]
x)
42
It does conform to the pattern that the bound variable precedes the
value to bind in forms like let. A benefit of this ordering is that
destructuring patterns like {:keys [a b c]} are unambiguous.
Your posted example performs two levels of destructuring. It first
extracts the value associated with the key :body in the map passed to
the function as the first argument. It then extracts the head and the
tail of this value (which is therefore assumed to be a sequence) and
binds them to the local variables 'head' and 'body'.
-Per
On Fri, Apr 16, 2010 at 3:59 PM, Bytesource stefan.rohlf...@gmail.com wrote:
Hi,
I am currently reading Programming Clojure but got stuck at the
destructuring done in the head-overlaps-body? function call that is
part of the snake game:
(defn head-overlaps-body? [{[head body] :body}]
(includes? body head))
;; page 200 of the pdf version
I can not figure out what {[head body] :body} actually means here.
head-overlaps-body? is called inside lose? which is called with a
snake object:
(def lose? head-overlaps-body?)
(defn create-snake []
{:body (list [1 1])
:dir [1 0]
:type :snake
:color (Color. 15 160 70)})
I read the the information about the let binding form on clojure.org/
special_forms but still have no clue how the above destructuring is
done.
Hope someone can give me a hint.
Stefan
--
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 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
Re: Problem with Destructuring in A Function Call
Bytesource wrote:
I am currently reading Programming Clojure but got stuck at the
destructuring done in the head-overlaps-body? function call that is
part of the snake game:
(defn head-overlaps-body? [{[head body] :body}]
(includes? body head))
;; page 200 of the pdf version
I can not figure out what {[head body] :body} actually means here.
Some simple examples might help -
(def snake {:body [[1 2] [2 3] [4 5] [6 4]]})
So snake is a map which has the key :body whose value is a vector of
vectors.
user (def body-vals (:body snake))
[[1 2] [2 3] [4 5] [6 4]]
The first vector in body-vals is the actual head and the rest is the body.
user (def head (first body-vals)
[1 2]
user (def body (rest body-vals)
[2 3] [4 5] [6 4]
Now that we have separated out the data, we can proceed and use them in
our functions.
But then, that's a bit too much of code, since we can destructure the
snake very easily in the function args part like this -
[{[head body] :body}]
What it does is that it first extracts the value of the :body key in the
map which is passed to the function.
Since the value of :body is supposed to be a vector, we can destructure
it further into head and body.
You can do the same kind of destructuring in a let form too.
I hope I was able to explain it to you. I agree, the examples were
pretty lame :)
Regards,
BG
--
Baishampayan Ghose b.gh...@ocricket.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Problem with Destructuring in A Function Call
On Apr 16, 11:59 am, Bytesource stefan.rohlf...@gmail.com wrote:
Hi,
I am currently reading Programming Clojure but got stuck at the
destructuring done in the head-overlaps-body? function call that is
part of the snake game:
(defn head-overlaps-body? [{[head body] :body}]
(includes? body head))
;; page 200 of the pdf version
I can not figure out what {[head body] :body} actually means here.
head-overlaps-body? is called inside lose? which is called with a
snake object:
(def lose? head-overlaps-body?)
(defn create-snake []
{:body (list [1 1])
:dir [1 0]
:type :snake
:color (Color. 15 160 70)})
I read the the information about the let binding form on clojure.org/
special_forms but still have no clue how the above destructuring is
done.
Hope someone can give me a hint.
As it is a nested destructuring form, there are two kinds of
destructuring happening: First, there is map destructuring that takes
the value for the key :body from the argument map. That is, ([1 1]),
which is a list.
Normally the value would then be bound to a name on the left-hand
side, but in this case there's the destructuring form [head body]
instead, which means sequential destructuring is applied to that list.
Thus, in this particular example, head gets bound to [1 1] and body to
nil.
--
Jarkko
--
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
Re: Problem with Destructuring in A Function Call
On Fri, Apr 16, 2010 at 2:29 PM, Bytesource stefan.rohlf...@gmail.com wrote:
Hi,
I am currently reading Programming Clojure but got stuck at the
destructuring done in the head-overlaps-body? function call that is
part of the snake game:
(defn head-overlaps-body? [{[head body] :body}]
(includes? body head))
;; page 200 of the pdf version
I can not figure out what {[head body] :body} actually means here.
The :body on the map returns something like this:
[[1 1] [1 2] [1 3] [1 4] [1 5]]
i.e. each co-ordinate is a vector and the whole set of vectors are
inside another vector. By the destructuring binding {[head body]
:body}, you are separating out the head and the rest of the body.
(def snake-body {:body [[1 1] [1 2] [1 3]]})
(:body snake-body)
= [[1 1] [1 2] [1 3]]
(let [[head body] (:body snake-body)]
head)
= [1 1]
(let [[head body] (:body snake-body)]
body)
= ([1 2] [1 3])
Hope this helps.
--
Ramakrishnan
--
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
Re: Clojure Concurrency Screencast Available
One final update: all six parts are now available, including the mobile downloads for offline viewing. http://link.pluralsight.com/clojure On Tue, Apr 13, 2010 at 9:40 AM, Craig Andera craig.and...@gmail.comwrote: Glad you've enjoyed them! 2010/4/13 Pelayo Ramón pela...@gmail.com I have seen the first 2, and as a clojure noobie I have to say that they are great. Thanks a lot. On Tue, Apr 13, 2010 at 3:10 PM, Craig Andera craig.and...@gmail.com wrote: If you mean downloading and viewing on my computers and mobile devices, then sure. There's no DRM. There's not even any registration required. But if by copying you mean distributing to other people, then no. If you have some other scenario in mind, contact me off-list and I'll hook you up with the right people for that conversation. On Tue, Apr 13, 2010 at 4:30 AM, Hasan Hasan mailsu...@gmail.com wrote: Hi, Is downloading and copying the videos free? On Tue, Apr 13, 2010 at 1:10 AM, Craig Andera craig.and...@gmail.com wrote: That's typing-speed-mode. I wrote it. :) Available here [1]. You'll probably also want this [2] in your .emacs. [1] http://www.pluralsight-training.net/community/blogs/craig/archive/2008/10/07/typing-speed-mode-emacs-minor-mode.aspx [2] (load /path/to//typing-speed.el) (add-hook 'text-mode-hook 'turn-on-typing-speed-mode) On Mon, Apr 12, 2010 at 10:52 AM, Baishampayan Ghose b.gh...@ocricket.com wrote: Craig Andera wrote: I've recorded a screencast on Clojure concurrency primitives. It's available at http://link.pluralsight.com/clojure. Thought some here might find it useful. It's in six parts, the first four of which are up now. The last two will be up by the middle of next week. Feedback welcome! Nice work! By the way, which Emacs mode do you have installed which shows the WPM count? Regards, BG -- Baishampayan Ghose b.gh...@ocricket.com oCricket.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe, reply using remove me as the subject. -- 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.comclojure%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 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.comclojure%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 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.comclojure%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 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.comclojure%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 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
Re: Events vs Threads paper
I've put up the code those guys eventually worked on (and then abandoned) while at UCBerkley: http://github.com/wlangstroth/capriccio On Apr 15, 4:16 pm, TimDaly d...@axiom-developer.org wrote: This might be interesting when the discussion of events vs threads comes up:http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbe... Essentially they argue that thread programming can scale (100k threads?) -- 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
Clojure-based query language for Hadoop
I've recently released Cascalog, a Clojure DSL for querying Hadoop, as open-source. Here's the canonical word count query in Cascalog: (?- (stdout) [?word ?count] (sentence ?s) (split ?s : ?word) (c/ count ?count)) Introductory blog post: http://nathanmarz.com/blog/introducing-cascalog/ Project page: http://github.com/nathanmarz/cascalog -- 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
Re: Erlang like environment
At Runa, we've (mostly Amit Rathore) developed a framework somewhat along these lines that we are using called swarmiji. We've open sourced it at http://github.com/amitrathore/swarmiji To quote from the readme: swarmiji is a framework that helps in writing distributed programs using the clojure programming language. We wrote it because our startup (Runa) needed computations to span not just clojure agents within single JVMs but across machines. This especially became the case as our load grew. swarmiji uses the fantastic RabbitMQ as its central nervous system to communicate between service requesters and (possibly multiple) workers. It provides simple constructs to create these distributed services and makes it very easy to use them in your code. It has support for additional things like – automatic time-outs (if a worker fails), and a simple metrics collection system (to see how long services are taking, and where time is being spent). It also uses a very simple web-framework that allows clojure functions (that might use swarmiji) to be exposed as web-services. Contributions are welcome, as are recommendations for how to improve things. On Apr 14, 5:42 pm, gary ng garyng2...@gmail.com wrote: Hi, I just start to learn about clojure and is wondering if there is any erlang like environment for clojure ? By that, I mean not just the messaging passing(which as far as I can tell for clojure is within the same process) but its live update and sending symbols(and as far as I know functions as well) across process/vm instances(which can be on the same machine or another machine within a private network). -- 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
wrong number of args with nested map
I feel like I'm probably doing something dumb, but here's my problem.
Below is a function that could take two maps, and return a list of all
the values in the second map for each key of the first:
(defn foo [map1 map2] (map (fn [k v] (map2 k)) map1))
(foo {:a 1 :b 2} {:a 5 :b 6 :c 7})
I would expect this to evaluate to:
[5 6]
When trying this code in clojure, I receive this error:
java.lang.IllegalArgumentException: Wrong number of args passed to:
user$foo--19$fn
It seems as if the compiler hasn't generated an anonymous function
with appropriate arity, but I'm not sure what I'm doing wrong. Any
tips would be appreciated.
Derek
--
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
Re: Translation from CL - On Lisp program
Sorry, I shoulda been clearer. By similar functionality, i meant a 20- q game with 1) the network implemented as closures and 2) code that doesn't have to hold state in a global datastructure The question wasn't about the easiest way to implement the game. State is unavoidable in many circumstances I suppose. Thanks for the response. -- 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
Re: wrong number of args with nested map
On 2010 Apr 15, at 11:53 PM, Derek wrote:
(defn foo [map1 map2] (map (fn [k v] (map2 k)) map1))
(foo {:a 1 :b 2} {:a 5 :b 6 :c 7})
When you turn a map into a sequence, you get a sequence of two-element
sequences(1),
so if you change your anonymous function to destructure that, it will
work:
user= (defn foo [map1 map2] (map (fn [[k v]] (map2 k)) map1))
#'user/foo
user= (foo {:a 1 :b 2} {:a 5 :b 6 :c 7})
(5 6)
--Doug
(1) http://clojure.org/data_structures says:
... seq returns a sequence of map entries, which are key/value
pairs. ...
I haven't yet found where in the docs a pair is defined, so I am
guessing that the concrete type (list, vector,...) for a pair is not
relevant/important.
--
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
Re: Bug - Clojure -e disables stdin
This is actually a fairly good bug report, I think. If you look in clojure.main, the eval-opt fuction uses with-in-str, which unnecessarily interferes with using *in* within the expression you are trying to evaluate. I was actually running into this while trying to make a lein repl in clojure rather than in the shell script. One way to fix it would be to replace it like in this gist: http://gist.github.com/368018. -- Aaron On Sun, Mar 28, 2010 at 9:35 PM, Asim Jalis asimja...@gmail.com wrote: Is this a bug? echo hi | java -cp $HOME/jars/clojure.jar clojure.main -e '(println (line-seq (java.io.BufferedReader. *in*)))' The output is nil. This works fine if argument to -e is saved to a file and then the file name is specified on the command line. -- Asim -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- 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
Re: Translation from CL - On Lisp program
On Fri, Apr 16, 2010 at 12:41 PM, Aravindh Johendran
ajohend...@gmail.com wrote:
Sorry, I shoulda been clearer. By similar functionality, i meant a 20-
q game with
1) the network implemented as closures and
There are various ways you can do this while separating concerns. If
you don't mind specifying the question nodes in
definition-precedes-use order, here is one (untested) way that closely
follows the structure of Graham's code but does not use mutable state:
(defn prompt [s]
(print s)
(flush)
(read))
(defn add-node [nodes node question yes-node no-node]
(assoc nodes node
#((nodes (if (= 'yes (prompt (format %s\n question)))
yes-node
no-node)
((:people (reduce #(apply add-node %1 %2) {} [[:people Is the person
a man? :male :female], ...])))
State is unavoidable in many circumstances I suppose.
Fewer than you would think. Even then, a good design will cleanly
separate the pure from the impure.
-Per
--
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
Re: Problem with Destructuring in A Function Call
Your explanations from different angles of the problem were really helpful. I now have a much better picture of what is going on during destruturing. Thank you very much! Stefan -- 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
sorted-set-by drops elements
Hi,
Is this the intended behavior?
(sorted-set-by (constantly 0) 1 2 3 4) returns #{1}.
I would expect the set to contain all the elements, and the comparator
to only affect sort order.
Razvan
--
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
Re: Problem with Destructuring in A Function Call
You will have to ask Rich. The two reasons I mentioned in my post were
my own guesses. I don't find either of them very persuasive myself. My
preference would be that patterns and literals should reflect each
other directly as much as possible. Features like :keys and :or have
no counterpart in the literal syntax and so impose no symmetry
constraints.
-Per
On Fri, Apr 16, 2010 at 9:25 PM, Asim Jalis asimja...@gmail.com wrote:
On Fri, Apr 16, 2010 at 2:15 AM, Per Vognsen per.vogn...@gmail.com wrote:
What may confuse is that map destructuring swaps the positions of keys
and values as compared to map literals:
user (let [{x :body} {:body 42}]
x)
42
It does conform to the pattern that the bound variable precedes the
value to bind in forms like let. A benefit of this ordering is that
destructuring patterns like {:keys [a b c]} are unambiguous.
Hi Per,
Could you explain the rationale for this swapping? Intuitively it
seems to me that (let [{ :body x } { :body 42 }] x) should bind x
to 42 -- it seems intuitive because it is binding :body to :body
and 42 to x.
I realize that this doesn't work. I want to understand why. Why
is (let [{ x :body } { :body 42 }] x) the correct way?
Asim
--
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
Re: sorted-set-by drops elements
Here's the source for sorted-set-by:
(defn sorted-set-by
Returns a new sorted set with supplied keys, using the supplied
comparator.
([comparator keys]
(clojure.lang.PersistentTreeSet/create comparator keys)))
This is because your comparator is saying that everything is equal.
PersistentTreeSet delegates a lot of work to PersistentTreeMap, so the
object is happily replacing every element when the comparator is zero.
I'm not sure if this is a bug or the intended behavior... I'm leaning
toward the latter, even though it's confusing.
Sean
On Apr 16, 8:25 am, Razvan gigi.clan...@gmail.com wrote:
Hi,
Is this the intended behavior?
(sorted-set-by (constantly 0) 1 2 3 4) returns #{1}.
I would expect the set to contain all the elements, and the comparator
to only affect sort order.
Razvan
--
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
athttp://groups.google.com/group/clojure?hl=en
--
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
Re: sorted-set-by drops elements
It doesn't seem confusing to me. You are taking complete control of
the set's local notion of ordering and equality. This is what I'd
expect.
Here's an example. First, a handy little function from Haskell:
(defn on [key f]
#(apply f (map key %)))
Then:
user (sorted-set-by (on :id compare)
{:id 42 :name Per :age 28}
{:id 0 :name Methuselah :age 9000}
{:id 42 :name Rep :age 82})
#{{:id 0, :name Methuselah, :age 9000} {:id 42, :name Per, :age 28}}
That is, it's eliminating entries with duplicate primary keys in favor
of earlier occurrences.
-Per
On Fri, Apr 16, 2010 at 9:38 PM, Sean Devlin francoisdev...@gmail.com wrote:
Here's the source for sorted-set-by:
(defn sorted-set-by
Returns a new sorted set with supplied keys, using the supplied
comparator.
([comparator keys]
(clojure.lang.PersistentTreeSet/create comparator keys)))
This is because your comparator is saying that everything is equal.
PersistentTreeSet delegates a lot of work to PersistentTreeMap, so the
object is happily replacing every element when the comparator is zero.
I'm not sure if this is a bug or the intended behavior... I'm leaning
toward the latter, even though it's confusing.
Sean
On Apr 16, 8:25 am, Razvan gigi.clan...@gmail.com wrote:
Hi,
Is this the intended behavior?
(sorted-set-by (constantly 0) 1 2 3 4) returns #{1}.
I would expect the set to contain all the elements, and the comparator
to only affect sort order.
Razvan
--
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
athttp://groups.google.com/group/clojure?hl=en
--
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 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
Re: Problem with Destructuring in A Function Call
On Fri, Apr 16, 2010 at 2:15 AM, Per Vognsen per.vogn...@gmail.com wrote:
What may confuse is that map destructuring swaps the positions of keys
and values as compared to map literals:
user (let [{x :body} {:body 42}]
x)
42
It does conform to the pattern that the bound variable precedes the
value to bind in forms like let. A benefit of this ordering is that
destructuring patterns like {:keys [a b c]} are unambiguous.
Hi Per,
Could you explain the rationale for this swapping? Intuitively it
seems to me that (let [{ :body x } { :body 42 }] x) should bind x
to 42 -- it seems intuitive because it is binding :body to :body
and 42 to x.
I realize that this doesn't work. I want to understand why. Why
is (let [{ x :body } { :body 42 }] x) the correct way?
Asim
--
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
Re: sorted-set-by drops elements
Why should sorting be related to the primary key? You should be able to sort on any attribute. If you wanted to sort a set of people by age would it make sense to only retain one person of each age? Sort order and identity should be orthogonal. Besides, if you need a collection based on primary keys then a map or a sorted map is more appropriate, and if you chose a set instead you probably expect operations on that set to take into account the entire element. Raz -- 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
Re: sorted-set-by drops elements
Maybe the example was poorly picked but the point stands: if you're asking for a sorted set based on a comparator, you should expect duplicate elements as dictated by comparator to be eliminated. If you wanted to sort a set of people by age, you wouldn't use a sorted set but a sorted sequence. That is what sort/sort-by provides. -Per On Fri, Apr 16, 2010 at 10:45 PM, Razvan gigi.clan...@gmail.com wrote: Why should sorting be related to the primary key? You should be able to sort on any attribute. If you wanted to sort a set of people by age would it make sense to only retain one person of each age? Sort order and identity should be orthogonal. Besides, if you need a collection based on primary keys then a map or a sorted map is more appropriate, and if you chose a set instead you probably expect operations on that set to take into account the entire element. Raz -- 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 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
Re: sorted-set-by drops elements
I think the fns you're interested in are sort and sort-by, not sorted- set-by. I know you might not like it, but there is a convention in JavaLand that a comparator value of 0 is identical in a sorted collection. This causes orthogonal concepts of order identity to be entwined. Sean On Apr 16, 11:45 am, Razvan gigi.clan...@gmail.com wrote: Why should sorting be related to the primary key? You should be able to sort on any attribute. If you wanted to sort a set of people by age would it make sense to only retain one person of each age? Sort order and identity should be orthogonal. Besides, if you need a collection based on primary keys then a map or a sorted map is more appropriate, and if you chose a set instead you probably expect operations on that set to take into account the entire element. Raz -- 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 athttp://groups.google.com/group/clojure?hl=en -- 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
Re: sorted-set-by drops elements
CORRECTION, DON'T SHOOT!! I should have order value, not order identity. On Apr 16, 1:01 pm, Sean Devlin francoisdev...@gmail.com wrote: I think the fns you're interested in are sort and sort-by, not sorted- set-by. I know you might not like it, but there is a convention in JavaLand that a comparator value of 0 is identical in a sorted collection. This causes orthogonal concepts of order identity to be entwined. Sean On Apr 16, 11:45 am, Razvan gigi.clan...@gmail.com wrote: Why should sorting be related to the primary key? You should be able to sort on any attribute. If you wanted to sort a set of people by age would it make sense to only retain one person of each age? Sort order and identity should be orthogonal. Besides, if you need a collection based on primary keys then a map or a sorted map is more appropriate, and if you chose a set instead you probably expect operations on that set to take into account the entire element. Raz -- 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 athttp://groups.google.com/group/clojure?hl=en -- 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 athttp://groups.google.com/group/clojure?hl=en -- 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
Re: sorted-set-by drops elements
On Sat, Apr 17, 2010 at 12:01 AM, Sean Devlin francoisdev...@gmail.com wrote: I know you might not like it, but there is a convention in JavaLand that a comparator value of 0 is identical in a sorted collection. It's not a Java convention. It's intrinsic to the business of sorting. For sorting to give well-defined results, it must be based on an ordering that respects the trichotomy law, which says that, for all x and y, exactly one of the following three conditions must hold: x y, x = y, x y. If you define the and based on a custom comparator but use the default equality implementation for the = then you cannot expect this to hold. Packaging all three relations together lets the implementor of the comparator guarantee trichotomy. -Per -- 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
Re: wrong number of args with nested map
The function you give to map needs to accept the same number of args
as there are collections. You're passing one map, thus the function
will be called with one arg. In the case of maps the element is a
key/value pair, which can then be destructured in the function.
On Apr 15, 8:53 pm, Derek dere...@gmail.com wrote:
I feel like I'm probably doing something dumb, but here's my problem.
Below is a function that could take two maps, and return a list of all
the values in the second map for each key of the first:
(defn foo [map1 map2] (map (fn [k v] (map2 k)) map1))
(foo {:a 1 :b 2} {:a 5 :b 6 :c 7})
I would expect this to evaluate to:
[5 6]
When trying this code in clojure, I receive this error:
java.lang.IllegalArgumentException: Wrong number of args passed to:
user$foo--19$fn
It seems as if the compiler hasn't generated an anonymous function
with appropriate arity, but I'm not sure what I'm doing wrong. Any
tips would be appreciated.
Derek
--
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
athttp://groups.google.com/group/clojure?hl=en
--
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
Re: Problem with Destructuring in A Function Call
On Apr 16, 5:25 pm, Asim Jalis asimja...@gmail.com wrote:
It does conform to the pattern that the bound variable precedes the
value to bind in forms like let. A benefit of this ordering is that
destructuring patterns like {:keys [a b c]} are unambiguous.
Hi Per,
Could you explain the rationale for this swapping? Intuitively it
seems to me that (let [{ :body x } { :body 42 }] x) should bind x
to 42 -- it seems intuitive because it is binding :body to :body
and 42 to x.
I realize that this doesn't work. I want to understand why. Why
is (let [{ x :body } { :body 42 }] x) the correct way?
Asim
I think the paragraph you replied to *is* the rationale: it allows for
features like :keys and :or, and maintains the general ordering of
bindings. It may feel a bit unintuitive at first, but I think that's
only because you're associating the map binding form more closely to a
map (a collection of key–value pairs) than a binding form.
--
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
Re: sorted-set-by drops elements
The problem is you're unnecessarily conflating the value by which to base a sort (x and y in your example) with the elements of the set. Equality and ordinality are not the same thing. It should be perfectly reasonable to hand someone a set of unique objects sorted by some non-unique attribute of the elements of the set. On Apr 16, 10:13 am, Per Vognsen per.vogn...@gmail.com wrote: On Sat, Apr 17, 2010 at 12:01 AM, Sean Devlin francoisdev...@gmail.com wrote: I know you might not like it, but there is a convention in JavaLand that a comparator value of 0 is identical in a sorted collection. It's not a Java convention. It's intrinsic to the business of sorting. For sorting to give well-defined results, it must be based on an ordering that respects the trichotomy law, which says that, for all x and y, exactly one of the following three conditions must hold: x y, x = y, x y. If you define the and based on a custom comparator but use the default equality implementation for the = then you cannot expect this to hold. Packaging all three relations together lets the implementor of the comparator guarantee trichotomy. -Per -- 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 athttp://groups.google.com/group/clojure?hl=en -- 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
platform-specific unit test failures in cc.test-complex-numbers
I'm building af2a730 some tests for c.c.io byte-level support of clojure-contrib. I'm seeing clojure.contrib.test-complex-numbers error out the maven build with 4 failures and 253 errors on two of the five platforms at my disposal. Only my linux-based netbooks fail the build. JDK version does not seem to explain the failures. (Apologies to those not reading this in a mono-spaced font.) |---++---++---| | |Mvn | JDK | OS/Kernel | Build | |---++---++---| | W | 2.2.1 | 1.6.0_16 | Ubuntu 9.10, 2.6.31-20 | FAIL | | P | 2.2.1 | 1.6.0_15 | Ubuntu 9.10, 2.6.31-20 | FAIL | | P | 2.2.1 | 1.6.0_19 | Ubuntu 9.10, 2.6.31-20 | FAIL | | P | 2.2.1 | OpenJDK 1.6.0 | Ubuntu 9.10, 2.6.31-20 | FAIL | |---++---++---| | O | 2.2.1 | 1.6.0_10 | Ubuntu 9.04, 2.6.28-18 | PASS | | M | 2.2.1 | 1.6.0_17 | Mac OS X 10.6.3 x86_64 | PASS | | G | 2.0.10 | 1.5.0_13 | Mac OS X 10.6.3 x86_64 | PASS | |---++---++---| |---+---++---+---| | | Model | Processor | RAM | Build | |---+---++---+---| | W | Dell Mini 9 | Atom, 1.66 GHz | 2 GiB | FAIL | | P | Eee PC 1005HA | Atom, 1.6 GHz | 2 GiB | FAIL | | O | Desktop | Core2Duo Quad, 2.5 GHz | 4 GiB | PASS | | M | MacBook | Core2Duo, 2.2 GHz | 4 GiB | PASS | | G | PowerBook | PowerPC G4, 1 GHz | 1 GiB | PASS | |---+---++---+---| Commonalities of the Failing platforms: - Ubuntu 9.10 - Linux Kernel 2.6.31-20-generic - Intel Atom processor (though different models: Wesley runs at 1.66GHz while Pepper uses a slightly newer model at 1.6 GHz) These failures don't appear related to the underlying clojure version. M (which passes) and P (which fails) were both using clojure-1.2.0-master-20100415.170113-27.jar (md5:43db78bcc5461156c80fee9434f2ff28) A few representative examples of the failures I'm seeing ERROR in (complex-sqrt) (run-test1347341999632195512.clj:44) Uncaught exception, not in assertion. expected: nil actual: java.lang.IllegalArgumentException: No method in multimethod 'sqrt' for dispatch value: :clojure.contrib.complex-numbers/complex ... FAIL in (complex-conjugate) (run-test1347341999632195512.clj:44) expected: (= (conjugate (complex 1 2)) (complex 1 -2)) actual: false ERROR in (complex-subtraction) (run-test1347341999632195512.clj:44) expected: (= (- -1 (complex -3 -7)) (complex 2 7)) actual: java.lang.IllegalArgumentException: No method in multimethod '-' for dispatch value: :clojure.contrib.complex-numbers/complex ... ERROR in (complex-division) (run-test1347341999632195512.clj:44) expected: (= (/ (imaginary 5) (imaginary 5)) 1) actual: java.lang.IllegalArgumentException: No method in multimethod '/' for dispatch value: :clojure.contrib.complex-numbers/pure-imaginary ... ERROR in (complex-abs) (run-test5245007338919107779.clj:44) expected: (approx= (* c (conjugate c)) (sqr (abs c)) 1.0E-14) actual: java.lang.IllegalArgumentException: No method in multimethod '*' for dispatch value: [:clojure.contrib.complex-numbers/complex :clojure.contrib.complex-numbers/complex] at clojure.lang.MultiFn.getFn (MultiFn.java:115) clojure.lang.MultiFn.invoke (MultiFn.java:161) clojure.contrib.test_complex_numbers$fn__10168$fn__10173.invoke (test_complex_numbers.clj:284) clojure.contrib.test_complex_numbers/fn (test_complex_numbers.clj:284) clojure.test$test_var__6644$fn__6645.invoke (test.clj:644) clojure.test/test_var (test.clj:644) clojure.test$test_all_vars__6649$fn__6650$fn__6657.invoke (test.clj:659) clojure.test/default_fixture (test.clj:617) clojure.test$test_all_vars__6649$fn__6650.invoke (test.clj:659) clojure.test/default_fixture (test.clj:617) clojure.test/test_all_vars (test.clj:655) clojure.test/test_ns (test.clj:677) clojure.core$map__3989$fn__3990.invoke (core.clj:1885) clojure.lang.LazySeq.sval (LazySeq.java:42) clojure.lang.LazySeq.seq (LazySeq.java:56) clojure.lang.Cons.next (Cons.java:37) clojure.lang.RT.next (RT.java:566) clojure.core/next (core.clj:54) clojure.core/reduce (core.clj:715) clojure.core/reduce (core.clj:706) clojure.core$merge_with__4079.doInvoke (core.clj:2061) clojure.lang.RestFn.applyTo (RestFn.java:140) clojure.core/apply (core.clj:480) clojure.test$run_tests__.doInvoke (test.clj:691) clojure.lang.RestFn.invoke (RestFn.java:1261) user$eval__12082$fn__12085.invoke (run-test5245007338919107779.clj:46) user/eval (run-test5245007338919107779.clj:44) clojure.lang.Compiler.eval (Compiler.java:5363)
Re: wrong number of args with nested map
Tangent:
On Fri, Apr 16, 2010 at 7:41 PM, Douglas Philips d...@mac.com wrote:
(1) http://clojure.org/data_structures says:
... seq returns a sequence of map entries, which are key/value pairs. ...
I haven't yet found where in the docs a pair is defined, so I am guessing
that the concrete type (list, vector,...) for a pair is not
relevant/important.
That's right. But what is surprising is that when you try to go in the
other direction by converting a sequence of two-element sequences into
a map then the concrete type of those two-element sequences matters a
great deal:
user (conj {} [:foo 1])
{:foo 1}
user (conj {} (list :foo 1))
; Evaluation aborted.
What's happening is that APersistentMap.cons() has a hard-coded type
check for IPersistentVector. There doesn't seem to be any good for why
it shouldn't work with any ISeq. Maybe performance? If that is a valid
concern, you could retain the current branch for IPersistentVector and
append an else-if for ISeqs.
This isn't a big problem in practice, though I've been bitten by it
unexpectedly once or twice. But it's a surprising violation of the
principle that one kind of sequence should be as good as any other
when the context calls for no particular performance characteristics
(e.g. O(1) random access).
-Per
--
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
Re: sorted-set-by drops elements
Equality and ordinality are not the same thing. It should be perfectly reasonable to hand someone a set of unique objects sorted by some non-unique attribute of the elements of the set. Sure, it's perfectly reasonable but it implies a different data structure. It sounds like you want a data structure that is both a set with respect to its default notion of equality (and hashing) and a sorted sequence with respect to some custom ordering. That implies two data structures, not one. If your tree is constructed based on the custom ordering, then you cannot use the same tree for fast lookups based on the default notion of equality. You can only do slow linear-time lookups by traversing the tree's nodes exhaustively. -Per -- 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
Re: sorted-set-by drops elements
On Sat, Apr 17, 2010 at 1:05 AM, Per Vognsen per.vogn...@gmail.com wrote: You can only do slow linear-time lookups by traversing the tree's nodes exhaustively. Correction: You do not have to do a linear search on the whole tree but only on the subset of the tree for which the comparator returns 0 with your queried value. That is the whole tree in the worst case and a significant fraction of the whole tree in many practical cases. Let's say the tree is constructed based on age and you're searching a university database for some specific person aged 18. The span of ages among university students is small, so a logarithmic search of the age-based tree probably only reduces the total search space by a fourth. Even with the help of the tree, you're still left to linear search n/4 elements. -Per -- 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
Re: sorted-set-by drops elements
On Apr 16, 8:25 am, Razvan gigi.clan...@gmail.com wrote:
Hi,
Is this the intended behavior?
(sorted-set-by (constantly 0) 1 2 3 4) returns #{1}.
I would expect the set to contain all the elements, and the comparator
to only affect sort order.
I expected the same thing at first, but the behavior appears to be
consistent with Java collections, so it's probably intended:
user= (def s (java.util.TreeSet. (proxy [java.util.Comparator] []
(compare [a b] 0
#'user/s
user= s
#TreeSet []
user= (seq s)
nil
user= (.add s 1)
true
user= s
#TreeSet [1]
user= (.add s 2)
false
user= s
#TreeSet [1]
- Chris Perkins
--
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
noob: call multimethod in a map?
Hi, Is it possible to call a multimethod in a map? In this simplified
example, I just want to increment every element of the array when the
multimethod is called (my real application is operating on sets of
hash tables ie database )
(defmulti cc (fn [c v] [(:category c) ]))
(defmethod cc [:toys] [category v ]] ( inc v))
can I do something like this? ( this doesn't work)
(map (cc{:category :toys} ) [1 2])
Thanks, Brian
--
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
Re: noob: call multimethod in a map?
On Fri, Apr 16, 2010 at 3:46 PM, Brian Wolf brw...@gmail.com wrote:
Hi, Is it possible to call a multimethod in a map? In this simplified
example, I just want to increment every element of the array when the
multimethod is called (my real application is operating on sets of
hash tables ie database )
(defmulti cc (fn [c v] [(:category c) ]))
(defmethod cc [:toys] [category v ]] ( inc v))
can I do something like this? ( this doesn't work)
(map (cc{:category :toys} ) [1 2])
Thanks, Brian
(map #(cc {:category :toys} %) [1 2])
or
(map (fn [x] (cc {:category :toys} x)) [1 2])
is what you want. Untested.
David
--
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
Re: noob: call multimethod in a map?
ok, I tested it, it works thanks Brian -- 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
Re: Erlang like environment
Actually I've got to disagree here, it is really easy to do. Here is one example of something esessoms did: http://github.com/esessoms/clj-interface And here is an example of the rewrite I did when I decided that his version didn't quite do what I wanted. http://gist.github.com/369114 On Apr 15, 12:11 am, Brian Troutwine br...@troutwine.us wrote: One could always piggy back Clojure onto Erlang's distributed environment via Java interop, though that would require a bit of legwork. On Wed, Apr 14, 2010 at 8:17 PM, Wilson MacGyver wmacgy...@gmail.com wrote: the closest thing I know is the remote REPL for clojure. but if you are looking for erlang's style of distributed environment, it doesn't exist as far as I know. clojure was designed to solve single machine many-core problems. while erlang is designed to solved distributed system problems. On Wed, Apr 14, 2010 at 8:42 PM, gary ng garyng2...@gmail.com wrote: Hi, I just start to learn about clojure and is wondering if there is any erlang like environment for clojure ? By that, I mean not just the messaging passing(which as far as I can tell for clojure is within the same process) but its live update and sending symbols(and as far as I know functions as well) across process/vm instances(which can be on the same machine or another machine within a private network). -- 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 -- Omnem crede diem tibi diluxisse supremum. -- 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 To unsubscribe, reply using remove me as the subject. -- 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
Re: Java interop question: proxy or gen-class?
Many thanks to Meikel Brandmeyer, whose code (after a one-character typo correction) worked the first time. As soon as I saw it, I understood every line of it; the problem was, it wouldn't have occurred to me to put all those elements (which, individually, I understood) together in just that way. Meikel, thanks again for contributing to a frustrated newcomer's education. By the way, I recommend comparing the original Java source code to the final version (at http://gist.github.com/369239) to any newcomer who wants to learn how to write Java code within a Clojure program--you don't even have to be interested in Piccolo2D to learn from this. (May you have) Good coding! -- 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
Re: Bug - Clojure -e disables stdin
On Fri, Apr 16, 2010 at 7:00 AM, Aaron Cohen remled...@gmail.com wrote: This is actually a fairly good bug report, I think. If you look in clojure.main, the eval-opt fuction uses with-in-str, which unnecessarily interferes with using *in* within the expression you are trying to evaluate. I was actually running into this while trying to make a lein repl in clojure rather than in the shell script. One way to fix it would be to replace it like in this gist: http://gist.github.com/368018. I tested out this fix and it seems to work great. We've actually had a bug in Leiningen with a fairly tacky workaround that was caused by this bug, so I'd love to see it fixed in Clojure. I've created a ticket and patch: http://www.assembla.com/spaces/clojure/tickets/299-clojure-main--e-disables-stdin thanks, 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
