Re: About a networked REPL...
On Mar 19, 7:30 pm, Martin Blais bl...@furius.ca wrote: (*) Please note: I am aware that only Emacs supports the Swank protocol right now but I don't see why other IDEs couldn't support it too--it's just made up of LISP forms after all; in other words, if someone wants to replace the swank protocol by an equivalent one with a different encoding I don't really see the point. Anyway, for this discussion I'll assume emacs-rex is a suitable enough protocol; in fact, I think it probably is, because it has already proved itself with a large number of LISP environments, it has history. In any case, that's a separate discussion. I think of emacs-rex as just the protocol and that other IDEs could implement it to talk with swank-clojure. One IDE that uses swank is CUSP, an Eclipse plugin for SBCL - see www.bitfauna.com/projects/cusp. It appears to have no activity since 2009, and was forked off to lispdef - see bitbucket.org/skolos/lispdev. That project also seems rather abandoned, or at least no activity for six months. Looking at the source could be helpful in trying to adapt swank. -- 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: About a networked REPL...
nrepl's protocol is also very line reader centric, which is a drag, and the integer that prefixes messages is really just a variable length string and is not useful for allocating buffers to receive data in a client because it is a lines / 2 instead of a byte count. this makes writing a client that uses anything but a BufferedReader challenging. I am not advocating the slime protocol, but at least the slime protocol prefixes message with a fixed width representation of the count of bytes in the rest of the message. I have been toying with a slime-nrepl and using nio and polling to make it all run in single thread, the slime protocol is very easy to process like this, while I haven't been able to figure out a good way to parse the nrepl protocol without having a thread continuously loop around reading lines from the socket. On Sat, Mar 19, 2011 at 7:40 PM, Sean Corfield seancorfi...@gmail.com wrote: On Sat, Mar 19, 2011 at 7:36 PM, Sean Corfield seancorfi...@gmail.com wrote: I guess I would need to be persuaded that either a) Slime/Swank is so unassailably good that all IDEs should implement it or b) there are inherent problems with nREPL and no IDEs should use it? As a follow on, the Why another REPL implementation? section of https://github.com/clojure/tools.nrepl is good reading (and confirms my suspicions about non-Emacs IDEs and Slime/Swank). -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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
How to Sum a Sequence?
I've tried Project Euler 2 now. For those unfamiliar, Project Euler Problem 2 states: find the sum of all even-valued fibonacci terms that are less than four million. Let's assume that I have the code to fill the vector: (def fib-seq ((fn rfib [a b] (lazy-seq (cons a (rfib b (+ a b) 0 1)) (def fib-vec (into [] (filter even? (take 35 fib-seq Many people reading the Clojure Samples will be familiar with the first sample. My own implementation did not want the 'take' function to work. However, that is a question for another day. Assume that the magic number 35 in the second function does indeed give me all even- valued fibonacci terms under four million. (I did not know how to specify a predicate depending on the value of (fib-seq) to check if the value is under 4 million.) With the function '(reduce + (fib-vec))' I effortlessly summed up all values in the vector. This is peculiar, because I first wanted to write a function that does this for me, but to no avail. (defn answer [] (let [ansVec [0]] (while (not-empty fib-vec) (conj ansVec (+ (last ansVec) (last fib-vec))) (into fib-vec (pop fib-vec) This function never terminates. Why not? Where am I thinking wrong? -- 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: How to Sum a Sequence?
Hi Christian, What you're trying to do is to build up a vector with the last element of the vector being the answer to your problem: (last answer) = 4613732 You're trying to use cons (conj) to build up that list. Now, your function below never terminates because you're: a) Not actually building up the ans-vec b) Not actually changing fib-vec to be closer to termination Clojure datastructures are immutable. conj returns a new seq with the second argument conj(s)ed onto the old sequence without changing the old seq e.g.: (def v [1 2 3]) (conj v 4) = [1 2 3 4] but: v = [1 2 3] The same applies to into. The closest I can think of you're trying to achieve is: (defn answer [] (loop [ans-vec [0] fib-v fib-vec] (if (empty? fib-v) ans-vec (recur (conj ans-vec (+ (last ans-vec) (last fib-v))) (pop fib-v) Now you're actually building up ans-vec in a tail-recursive fashion while changing fib-v to be closer to termination. Having said that, what you really want is (reduce + fib-vec) ;) Andreas P.S. To get your head around basic recursion dig into The little Schemer by Friedman and Felleisen On 20/03/2011, at 7:22 PM, Christian wrote: I've tried Project Euler 2 now. For those unfamiliar, Project Euler Problem 2 states: find the sum of all even-valued fibonacci terms that are less than four million. Let's assume that I have the code to fill the vector: (def fib-seq ((fn rfib [a b] (lazy-seq (cons a (rfib b (+ a b) 0 1)) (def fib-vec (into [] (filter even? (take 35 fib-seq Many people reading the Clojure Samples will be familiar with the first sample. My own implementation did not want the 'take' function to work. However, that is a question for another day. Assume that the magic number 35 in the second function does indeed give me all even- valued fibonacci terms under four million. (I did not know how to specify a predicate depending on the value of (fib-seq) to check if the value is under 4 million.) With the function '(reduce + (fib-vec))' I effortlessly summed up all values in the vector. This is peculiar, because I first wanted to write a function that does this for me, but to no avail. (defn answer [] (let [ansVec [0]] (while (not-empty fib-vec) (conj ansVec (+ (last ansVec) (last fib-vec))) (into fib-vec (pop fib-vec) This function never terminates. Why not? Where am I thinking wrong? -- 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 www.leica-geosystems.com* when it has to be right, Leica Geosystems Please consider the environment before printing this email. -- 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
Throwing an Exception with get
Hi all,
I would like to throw an exception when I'm trying to retrieve a value in a map
for a key that doesn't exist.
The obvious first shot was:
(get {:foo bar} :foo (throw (new Exception Oh no!)))
However, this doesn't work because the exception always throws since get
apparently eagerly evaluates it's arguments.
One way to work around this could be:
(defn get-with-exception [map key]
(let [res (get map key (new Exception my-exception))]
(if (= (class res) java.lang.Exception)
(throw res)
res)))
I was wondering, is there another more concise/idiomatic way?
Cheers
Andreas
--
Test-driven Dentistry (TDD!) - Not everything should be test driven
- Michael Fogus
--
**
Andreas Koestler, Software Engineer
Leica Geosystems Pty Ltd
270 Gladstone Road, Dutton Park QLD 4102
Main: +61 7 3891 9772 Direct: +61 7 3117 8808
Fax: +61 7 3891 9336
Email: andreas.koest...@leica-geosystems.com
www.leica-geosystems.com*
when it has to be right, Leica Geosystems
Please consider the environment before printing this email.
--
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: How to Sum a Sequence?
Christian soulbea...@gmail.com writes: Hi Christian, For those unfamiliar, Project Euler Problem 2 states: find the sum of all Sounds like (reduce + ...). even-valued fibonacci terms Sounds like (filter even? ...) that are less than four million. Hm, that's a bit more challenging. I think, you could go with (for [fib (fib-seq) :while ( fib 400)] fib) Of course, this is all completely untested. :-) Bye, Tassilo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clj-ldap - Clojure LDAP client
On Mar 16, 9:30 am, Ray Miller r...@1729.org.uk wrote: On 15 March 2011 08:46, Saul Hazledine shaz...@gmail.com wrote: On Mar 15, 1:30 am, Paul Dorman paul.dor...@gmail.com wrote: One thought though is that it may be quicker simply do a lookup on the directory server, obtain the password and then do a compare. In OpenLDAP, posixUser uids are indexed by default. Java libraries are available for most password encryption algorithms. This is the approach I use - do you know of any problems with my method? Certainly when I was running LDAP servers we did not allow passwords to be retrieved from the server, as they are then susceptible to an offline dictionary attack. To authenticate users, you had to send a bind request to the server. This is a very good point which I have added to the documentation. I have made the bind functionality public and released version 0.0.4 of clj-ldap. Saul -- 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: Throwing an Exception with get
This is slower but is a bit clearer.
(defn get-with-exception [map key]
(if (contains? map key)
(get map key)
(throw (Exception. oops
Curious, why do you want to do this? Are you working with Java interop?
Ambrose
On Sun, Mar 20, 2011 at 5:50 PM, Andreas Kostler
andreas.koestler.le...@gmail.com wrote:
Hi all,
I would like to throw an exception when I'm trying to retrieve a value in a
map for a key that doesn't exist.
The obvious first shot was:
(get {:foo bar} :foo (throw (new Exception Oh no!)))
However, this doesn't work because the exception always throws since get
apparently eagerly evaluates it's arguments.
One way to work around this could be:
(defn get-with-exception [map key]
(let [res (get map key (new Exception my-exception))]
(if (= (class res) java.lang.Exception)
(throw res)
res)))
I was wondering, is there another more concise/idiomatic way?
Cheers
Andreas
--
Test-driven Dentistry (TDD!) - Not everything should be test driven
- Michael Fogus
--
**
Andreas Koestler, Software Engineer
Leica Geosystems Pty Ltd
270 Gladstone Road, Dutton Park QLD 4102
Main: +61 7 3891 9772 Direct: +61 7 3117 8808
Fax: +61 7 3891 9336
Email: andreas.koest...@leica-geosystems.com
www.leica-geosystems.com*
when it has to be right, Leica Geosystems
Please consider the environment before printing this email.
--
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: Throwing an Exception with get
Maybe something along these lines:
(def ^{:private true} EMPTY (reify))
(defn get-with-empty-check [map key]
(get map key EMPTY))
(defn key-exists? [value]
(not= EMPTY value))
= (def res (get-with-empty-check {:asdf 1} :ss))
EMPTY
= (key-exists? res)
false
The basic idea being that it's guaranteed nothing will ever equal EMPTY
other than itself, making it easy to determine if a key is missing.
Ambrose
On Sun, Mar 20, 2011 at 7:22 PM, Andreas Kostler
andreas.koestler.le...@gmail.com wrote:
Hi Ambrose,
No java interop. I do a selection based on map keys. Suppose I have a set
of maps:
(def rel #{{:a a :b b}{:a c :b d}{:a e :b f}})
And I do a select-like query
(select rel [[:a :eq a]])
= #{{:a a :b b}}
Now, I want to distinguish between a value that doesn't match and a
non-existing key.
Hence,
(select rel [[:bogus b]]) should not return an empty set but somehow
signal that the key does not exist.
In relational terms, the key is not an attribute of the relation.
Does that make sense?
Andreas
On 20/03/2011, at 9:10 PM, Ambrose Bonnaire-Sergeant wrote:
curious, why do you want to do this? Are you working with Java interop
--
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: Throwing an Exception with get
On Mar 20, 10:50 am, Andreas Kostler andreas.koestler.le...@gmail.com wrote: I would like to throw an exception when I'm trying to retrieve a value in a map for a key that doesn't exist. Another concise solution (thanks, Conj Labs): (defn get-or-exc [map key] (if-let [[_ v] (find map key)] v (throw (Exception. missing I'm not too fond of using exceptions for flow control, though. Daniel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clj-ldap - Clojure LDAP client
Thanks for the latest changes, Saul. Your implementation is a little
different from mine:
(defn bind-connection
Change the identity of an existing connection.
[connection bind-dn password]
(let [bind-result (.bind connection (bind-request {:bind-dn bind-
dn :password password}))]
(if (= ResultCode/SUCCESS (.getResultCode bind-result))
connection
(throw (LDAPException. bind-result)
This enables the application code to handle the exception
appropriately (was the return value false because of invalid
credentials, or because of some other reason?). It also (I hope)
provides the capability to take a connection from the pool, change its
identity and perform some subsequent action(s) such as changing
attribute values.
I haven't yet confirmed if what I have above will work in the way I
describe, but I'm pretty confident that you'll want a connection
returned by bind/bind-connection function. A naive authentication
scheme could be implemented by the application like so:
(defn can-bind?
[attribute value password]
(def search-result (ldap/search conn base-dn {:filter (
(~{attribute}=~{value})) :attributes [:dn]}))
(try
(ldap/bind-connection conn (:dn (first search-result)) password)
true
(catch Exception _ false)))
i.e. (can-bind? uid joe supersecretpassword)
I'm a complete beginner at Clojure (and LDAP for that matter), and
there's a number of things that I'm wondering about, such as binding
to a server-set, where failure to bind due to the unavailability of
one or more members causes a bind request to be sent to the next. The
thing I'm struggling with at the moment is how to manage connection
state as its identity is changed for each new bind. In particular, I
want to use getConnection() to retrieve the bind connection from the
pool so it can be reused (which isn't currently happening), before
calling the releaseConnection() method.
Sorry for not getting the above to you earlier - I've been spending a
lot of time in the REPL trying to get this right. 1:50 on Monday
morning now though, so I think I'll have to reluctantly step away from
the computer.
Regards,
Paul
On Mar 20, 11:34 pm, Saul Hazledine shaz...@gmail.com wrote:
On Mar 16, 9:30 am, Ray Miller r...@1729.org.uk wrote:
On 15 March 2011 08:46, Saul Hazledine shaz...@gmail.com wrote:
On Mar 15, 1:30 am, Paul Dorman paul.dor...@gmail.com wrote:
One thought though is that it may be quicker simply do a lookup on the
directory server, obtain the password and then do a compare. In
OpenLDAP, posixUser uids are indexed by default. Java libraries are
available for most password encryption algorithms. This is the
approach I use - do you know of any problems with my method?
Certainly when I was running LDAP servers we did not allow passwords
to be retrieved from the server, as they are then susceptible to an
offline dictionary attack. To authenticate users, you had to send a
bind request to the server.
This is a very good point which I have added to the documentation.
I have made the bind functionality public and released version 0.0.4
of clj-ldap.
Saul
--
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: How to Sum a Sequence?
Hello Tassilo! I've tested your code and looked at the Clojure Documentation for 'for'. Given that, I have written (reduce +(filter even? (for [fib (fib-seq) :while ( fib 400)] fib))) This gives me the error 'clojure.lang.LazySeq cannot be cast to clojure.lang.IFn'. I think this is because fib-seq is a var, not a function (although I was hard-pressed finding out what IFn stood for.) When I omit the () with [fib (fib-seq)...], the program works just as expected. I would like to thank you for this suggestion and the way you translated the problem statement into code! Do you have any resources or books that help with such things? (Taking a problem and solving it the way you did) On Mar 20, 11:18 am, Tassilo Horn tass...@member.fsf.org wrote: Christian soulbea...@gmail.com writes: Hi Christian, For those unfamiliar, Project Euler Problem 2 states: find the sum of all Sounds like (reduce + ...). even-valued fibonacci terms Sounds like (filter even? ...) that are less than four million. Hm, that's a bit more challenging. I think, you could go with (for [fib (fib-seq) :while ( fib 400)] fib) Of course, this is all completely untested. :-) Bye, Tassilo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: About a networked REPL...
Martin, Thank you for the pushback. :-) On Mar 19, 2011, at 8:30 PM, Martin Blais wrote: Hi, After Rich's suggestion at the recent NYC meetup, I had a detailed look at inferior-lisp vs. Slime, and nREPL, read Chas' document, wrote a bit of code, tried to figure out the issues for myself; here are my conclusions on nREPL: - In the Slime/Swank model, there is a single IDE that connections to N possible types of LISPs via a rich protocol (and a lot of corresponding work on the workflow/GUI side in Emacs in the various fancy Slime functions I discussed at the meetup). Emacs/Slime - Clojure, sbcl, clisp, Allegro, etc. My understanding of nREPL is that it inverts the problem by making M different IDEs able to connect to one type of LISP VM (Clojure). Emacs, Eclipse, NetBeans, whatever, etc. - Clojure One of the assumptions is that by keeping nREPL simple the various clients will send whatever necessary Clojure code they want in order to perform the same common tasks that the Swank protocol already describes. I think that this is touted to be powerful because you can eval anything you like, i.e., just send it some clojure expression you want. But from my POV, it only serves to move the complexity from the server/VM (currently in swank-clojure and the protocol) to the client/IDE. I think this is wrong, because every single IDE client will have to adapt itself to the various changes occurring in the Clojure VM as it evolves. This is just creating M times the amount of porting problems (for each client). By keeping the complexity on the server, every IDE that speaks a common protocol (*) works between versions. There's no reason why the server couldn't provide a standard set of introspection / tooling utilities available -- it would be as easy as adding a proper dependency e.g. in your web project's pom/project.clj. A few people have been discussing the desired capabilities, and have started documenting desired semantics, and where each capability has already been implemented. One could argue that a rich client library could be included that provides similar functionality that is currently provided by swank-clojure, i.e. the problem is lessened, because all the clients now share the same client library, so you port over the client lib and recompile and that should be enouhg. But what language do you do this in? Clojure itself? Pure Java? What about the Emacs-LISP client? Then you have a problem of having multiple client libraries that need be ported. If you want to load in the aforementioned standard set of utilities from the client side (perhaps if the nREPL server doesn't have them available already), doing so from any client should be straightforward. It's just loading Clojure code, after all. No porting. - I take another issue at nREPL: if someone is going to implement a request/response protocol that supports only generic requests (because the complexity should live in the client), why bother at all, why not instead just make it a really, really simple network REPL, without any protocol at all? e.g. all input means eval, output is just output, no ids no nothing just a socket that you could connect to with telnet and have a repl right there, no protocol. telnet localhost 4005, type (+ 2 2) at the terminal, see 4 appear. That's it. I think it would be pretty straightforward to extend Emacs' inferior-lisp-mode to support talking to a socket like that instead of having to start a subprocess. This would give you vanilla communication with a live Clojure VM without having to start the VM from a parent process. I rather like this idea; it's the simplicity you currently enjoy with inferior-lisp, but over a socket; simple, can't break. Because a synchronous client is unsuitable for REPL tasks that require or desire asynchronous evaluation of expressions. IMHO if people will bother implementing a request/response protocol, why not just stick with a rich protocol like Swank's? It'll just be reinventing the wheel otherwise. Swank is fundamentally emacs-only, and is defined outside of the Clojure community. I discuss the issues with swank in the readme here: https://github.com/clojure/tools.nrepl - Another problem with Slime that turns people off is the weirdness in where the output goes. To detail the weirdness: How SLIME works (or its problems) is entirely orthogonal to network REPL design IMO. nREPL breaks up *err*, *out*, and a printed representation of expression results into separate slots in its responses, so clients can display response data however is appropriate for their environment. Note that I'm planning on adding optional multiplexing of System/out and System/err (much like is done in Cake) to nREPL so that clients can subscribe to those streams as desired. (*) Please note: I am aware that only Emacs supports the Swank
Re: About a networked REPL...
On Mar 20, 2011, at 3:13 AM, Kevin Downey wrote: nrepl's protocol is also very line reader centric, which is a drag, and the integer that prefixes messages is really just a variable length string and is not useful for allocating buffers to receive data in a client because it is a lines / 2 instead of a byte count. this makes writing a client that uses anything but a BufferedReader challenging. I am not advocating the slime protocol, but at least the slime protocol prefixes message with a fixed width representation of the count of bytes in the rest of the message. I have been toying with a slime-nrepl and using nio and polling to make it all run in single thread, the slime protocol is very easy to process like this, while I haven't been able to figure out a good way to parse the nrepl protocol without having a thread continuously loop around reading lines from the socket. My apologies for not getting back to you privately about this earlier. It's been a hell of a week. When I was designing the protocol, my aim was to make it simple enough to implement from, e.g., Python, and able to be hoisted up onto something like STOMP with relative ease. Thus, line orientation and all-strings made a lot of sense. I would not pretend to be an expert at designing network protocols. My question would be: in what context is allocating response buffers efficiently a must-have? - Chas -- 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: How to Sum a Sequence?
Hi
On 20 March 2011 17:47, Christian soulbea...@gmail.com wrote:
Hello Tassilo!
I've tested your code and looked at the Clojure Documentation for
'for'. Given that, I have written
(reduce +(filter even? (for [fib (fib-seq) :while ( fib 400)]
fib)))
Or using Daniel's suggestion:
(reduce + (filter even? (take-while #( % 400) fib-seq)))
This gives me the error 'clojure.lang.LazySeq cannot be cast to
clojure.lang.IFn'.
I think this is because fib-seq is a var, not a function (although I
was hard-pressed finding out what IFn stood for.) When I omit the ()
with [fib (fib-seq)...], the program works just as expected.
Yes, that's correct. IFn means something that implements the Fn
interface, i.e. it acts like a function. There are things in Clojure
which are not really functions, but can be used like functions.
e.g.: ({:foo bar} :foo)
or: (:foo {:foo bar})
--
Michael Wood esiot...@gmail.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: How to Sum a Sequence?
Christian soulbea...@gmail.com writes: Hi Christian, I would like to thank you for this suggestion and the way you translated the problem statement into code! Thanks for the compliment. :-) Do you have any resources or books that help with such things? (Taking a problem and solving it the way you did) I think, my suggestions are not specific to clojure, but they apply to any functional language. All of them have functions for filtering sequences, applying a function to each item, reducing, and so on. Once you know these basic functions, most computation can be expressed by composing these in some way. Bye, Tassilo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Dynamic scoping issue
On Sun, Mar 20, 2011 at 4:16 PM, Tassilo Horn tass...@member.fsf.org wrote:
the println prints {Locality localities.Locality}, which is correct.
However, my resolving function errors because there is no class
Locality. In the error message, I also print the value of
*schema-imports*, and in fact, it is {}.
Does the resolving function run on, or use, another thread?
--
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: Throwing an Exception with get
Would that be flow control though? I see this exception as a rather exceptional circumstance for this application... On 20/03/2011, at 10:53 PM, Daniel Werner wrote: On Mar 20, 10:50 am, Andreas Kostler andreas.koestler.le...@gmail.com wrote: I would like to throw an exception when I'm trying to retrieve a value in a map for a key that doesn't exist. Another concise solution (thanks, Conj Labs): (defn get-o r-exc [map key] (if-l et [[_ v] (find map key)] v (thro w (Exce ption. miss ing I'm not too fond of using exceptions for flow control, though. Daniel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To 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: How to Sum a Sequence?
Do you have any resources or books that help with such things? (Taking a problem and solving it the way you did) I think, my suggestions are not specific to clojure, but they apply to any functional language. All of them have functions for filtering sequences, applying a function to each item, reducing, and so on. Once you know these basic functions, most computation can be expressed by composing these in some way. I can only speak for me personally, but I found it useful going through the excellent books the CLisp and Scheme community provide. Peter Seibels Practical Common Lisp and The Little Schemer, The Seasoned Schemer, and of course SICP not only teach you how to use a Lisp which is 'simpler' than Clojure (not in terms of syntax) - this is especially true for Scheme (not so much CLisp) but they also teach you how to recognise certain patterns that occur in functional programs. Once you know how those patterns match to the sequence functions you can start replacing them and writing more concise code. That was my path anyway and I'm still learning :) It's fun though, don't get frustrated :) This community is very helpful so don't hesitate and ask. There's no dumb questions, you know the saying. Andreas -- 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: Dynamic scoping issue
Ken Wesson kwess...@gmail.com writes:
the println prints {Locality localities.Locality}, which is correct.
However, my resolving function errors because there is no class
Locality. In the error message, I also print the value of
*schema-imports*, and in fact, it is {}.
Does the resolving function run on, or use, another thread?
No, it runs in the same thread. But some functions like `vseq' in the
example produce LazySeqs. So if LazySeq-realization computations are
run in a different thread by default, that would explain things. But
then, dynamic scoping would be impossible at all...
If you want, you can clone the project from my hg repository:
https://anonymous:sec...@hg.uni-koblenz.de/horn/funql
In the test core.clj, the last test has a TODO. As it is, it works
fine, but as soon as you replace the qualified names with simple names,
it'll break as described.
Bye,
Tassilo
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Dynamic scoping issue
On Sun, Mar 20, 2011 at 5:17 PM, Tassilo Horn tass...@member.fsf.org wrote:
Ken Wesson kwess...@gmail.com writes:
the println prints {Locality localities.Locality}, which is correct.
However, my resolving function errors because there is no class
Locality. In the error message, I also print the value of
*schema-imports*, and in fact, it is {}.
Does the resolving function run on, or use, another thread?
No, it runs in the same thread. But some functions like `vseq' in the
example produce LazySeqs. So if LazySeq-realization computations are
run in a different thread by default, that would explain things.
They're not, but if the LazySeq realization is not happening until
after the scope of your with-schema-imports is exited, it would
explain a thing or two. You may need to sprinkle some doalls about.
--
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: About a networked REPL...
My objection has nothing to do with string vs. byte. Messages used in wire protocols exist on a continuum between fixed width and variable width. The happy medium there, which almost all protocols follow is a fixed width header that also provides the bye count of the following variable width body. The nrepl protocol appears to have aimed at that, but missed. Fixed width messages have the advantage of being extractable from the byte stream without having to do any parsing, while with a variable width message format you must parse and extract messages from the stream in the same step. After trying to write a nrepl client it is fairly obvious to me that in the creation of the protocol similar protocols were examined and because they were prefixed by numbers, the nrepl messages were, without a clear understanding of why and what the purpose of the number is. As implemented the number may as well be replaced with some kind of START and END tag. On Sunday, March 20, 2011, Stuart Sierra the.stuart.sie...@gmail.com wrote: Yes, as a heavy Emacs/SLIME user who does not work with Common Lisp any more, I'd rather have a Clojure-specific Emacs environment, especially something that can do more introspection of the JVM, e.g., look up JavaDocs and examine classes through reflection. In my not-terribly-well-informed opinion, string-oriented protocols are easier to parse in string-oriented languages like Perl and Emacs Lisp, whereas byte-oriented protocols help avoid mixups with character encoding and line-endings. Pick your poison. -Stuart Sierraclojure.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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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: Dynamic scoping issue
Ken Wesson kwess...@gmail.com writes: Hi Ken, Does the resolving function run on, or use, another thread? No, it runs in the same thread. But some functions like `vseq' in the example produce LazySeqs. So if LazySeq-realization computations are run in a different thread by default, that would explain things. They're not, but if the LazySeq realization is not happening until after the scope of your with-schema-imports is exited, it would explain a thing or two. You may need to sprinkle some doalls about. Oh, yes. That was the exact issue. But clearly forcing realization is not a good solution. Is there some better way to do what I want? Maybe my macro should expand to something like that? ((fn [] (binding [...as before...] body))) Bye, Tassilo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Dynamic scoping issue
On Sun, Mar 20, 2011 at 5:41 PM, Tassilo Horn tass...@member.fsf.org wrote: Ken Wesson kwess...@gmail.com writes: Hi Ken, Does the resolving function run on, or use, another thread? No, it runs in the same thread. But some functions like `vseq' in the example produce LazySeqs. So if LazySeq-realization computations are run in a different thread by default, that would explain things. They're not, but if the LazySeq realization is not happening until after the scope of your with-schema-imports is exited, it would explain a thing or two. You may need to sprinkle some doalls about. Oh, yes. That was the exact issue. But clearly forcing realization is not a good solution. Is there some better way to do what I want? Maybe my macro should expand to something like that? ((fn [] (binding [...as before...] body))) Still won't work if unrealized lazy seqs are returned from the function. I think what you want is to pass a kind of resolution-context object as far as the resolve calls. The lazy seq elements will close over this object and the resolver will use it. The macro would become sugar for making the object without a lot of messy quoting, something like (let-schema-imports [sis [localities.Locality]] (do-something parm1 parm2 sis) ...) (defn do-something [parm1 parm2 sis] (make-lazy-seq-of-some-sort ...)) ... (defn something-else [x y z sis] (act-on x (resolver-macro-of-some-sort sis Locality) y z) ...) Of course, explicitly passing sis around everywhere might also get annoying. The only alternative to that and eagerly realizing your seqs is a static set of name imports with either global or lexical scope. Actually, you might want to try writing a macro that will take localities.Locality and emit a defmacro that will cause (Locality) to expand to localities.Locality, then use (Locality) wherever you presently use Locality. This gives you namespace scoped imports, in effect: you use the defmacro-emitting import macro at the top of a sourcefile and (Locality) elsewhere in it, and (Locality) refers to localities.Locality throughout that source file (and nowhere else if you don't want it to). And there's no run-time overhead for any of it either. -- 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: Throwing an Exception with get
On 20 March 2011 22:02, Andreas Kostler andreas.koestler.le...@gmail.com wrote: Would that be flow control though? I see this exception as a rather exceptional circumstance for this application... If a missing key signifies an error, then yes, it should probably throw an exception. It seems reading your code wrongly reminded me of how in Python, it is idiomatic to catch KeyError if a key isn't present, which can lead to unneccessarily nested and hard-to-read logic. (Of course, there's also .get() in Python, with an identical signature to Clojure's get) -- 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: Throwing an Exception with get
Well, get-with-exception attempts to model a restriction on a relation (e.g. select in sql) so I believe a missing key indeed indicates an error. On 21/03/2011, at 9:25 AM, Daniel Werner wrote: On 20 March 2011 22:02, Andreas Kostler andreas.koestler.le...@gmail.com wrote: Would that be flow control though? I see this exception as a rather exceptional circumstance for this application... If a missing key signifies an error, then yes, it should probably throw an exception. It seems reading your code wrongly reminded me of how in Python, it is idiomatic to catch KeyError if a key isn't present, which can lead to unneccessarily nested and hard-to-read logic. (Of course, there's also .get() in Python, with an identical signature to Clojure's get) -- 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 -- Test-driven Dentistry (TDD!) - Not everything should be test driven - Michael Fogus -- ** Andreas Koestler, Software Engineer Leica Geosystems Pty Ltd 270 Gladstone Road, Dutton Park QLD 4102 Main: +61 7 3891 9772 Direct: +61 7 3117 8808 Fax: +61 7 3891 9336 Email: andreas.koest...@leica-geosystems.com www.leica-geosystems.com* when it has to be right, Leica Geosystems Please consider the environment before printing this email. -- 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
Beginning Clojure
Hi, I would like to learn Clojure from a practical project approach. Where can I find resources? Thanks. -- 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: Dynamic scoping issue
Hi, Am 20.03.2011 um 22:41 schrieb Tassilo Horn: Oh, yes. That was the exact issue. But clearly forcing realization is not a good solution. Is there some better way to do what I want? Maybe my macro should expand to something like that? ((fn [] (binding [...as before...] body))) Shameless self-promotion: http://kotka.de/blog/2009/11/Taming_the_Bound_Seq.html It's not perfect, but maybe it helps. Sincerely Meikel -- 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: Beginning Clojure
Hi, Depending on your level of Lisp expertise, I'd suggest digging into Clojure frameworks like Ring or Compojure. You might find the books on Clojure interesting (Practical Clojure, Programming Clojure, The Joy of Clojure, Clojure in Action). The latter two are work in progress (however, The Joy of Clojure is complete and will be shipped end of March). The classic Lisp texts (I love Practical Common Lisp) are pretty good value. There's blogs as well with tutorial material: (http://www.bestinclass.dk/index.clj/2011/01/building-a-social-media-site.html) Hope that helps :) Andreas On 21/03/2011, at 9:08 AM, Ent SaaS wrote: Hi, I would like to learn Clojure from a practical project approach. Where can I find resources? Thanks. -- 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: About a networked REPL...
On Mar 20, 2011, at 12:47 PM, Kevin Downey wrote: I am no python programmer, but if you look at http://docs.python.org/library/socket.html you see it passes in the number of bytes you wish to receive on a call to the receiv method on a socket. With that in mind parsing nrepl messages becomes a huge pain. At no time when parsing a nrepl message do you know how many bytes you need. The messages start with a string representation of a number (variable width) and the rest of the message is some set of new delimited strings. FWIW, a hello-world-level interaction with an nREPL server from python: https://gist.github.com/de3b8d0ecdccf6655a63 You don't need to know how many bytes you need when parsing an nrepl message, which would seem to be an advantage to me. I thought you were just advocating for ditching slime because it's not clojure centric enough, how does python fit into this? I've never advocated ditching slime, I've been advocating for a network REPL suitable for use by any and all Clojure tooling. My mentioning python was just an example of a non-Clojure runtime from which one might want to talk to a Clojure/JVM process running a network REPL server. - Chas -- 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: About a networked REPL...
The number indicates the number of entries in the following message; and yes, you're right that a sentinel would have been sufficient to terminate each message, though I wasn't attempting to follow in other protocols' footsteps. I'm sure the protocol is lacking in a variety of ways; as I said, I'm no expert in that department. In the end though, it *seems* to be easy enough to implement a client for in various environments/languages (see my prior msg). In any case, my objective with nREPL was to get something working well that had what I thought were the right semantics for the use cases I was concerned with (i.e. point-to-point Clojure tooling backends). Lifting those semantics onto other transports in the future shouldn't be difficult (I think Rich was pretty unhappy with the protocol as well -- IIRC, he would have preferred using STOMP directly, but it's important to some users of nREPL that external dependencies be minimal/nonexistent, and a Clojure STOMP broker has yet to come along). Is the protocol as-is a blocker for your attempt to build a SLIME client for nREPL? - Chas On Mar 20, 2011, at 5:39 PM, Kevin Downey wrote: My objection has nothing to do with string vs. byte. Messages used in wire protocols exist on a continuum between fixed width and variable width. The happy medium there, which almost all protocols follow is a fixed width header that also provides the bye count of the following variable width body. The nrepl protocol appears to have aimed at that, but missed. Fixed width messages have the advantage of being extractable from the byte stream without having to do any parsing, while with a variable width message format you must parse and extract messages from the stream in the same step. After trying to write a nrepl client it is fairly obvious to me that in the creation of the protocol similar protocols were examined and because they were prefixed by numbers, the nrepl messages were, without a clear understanding of why and what the purpose of the number is. As implemented the number may as well be replaced with some kind of START and END tag. On Sunday, March 20, 2011, Stuart Sierra the.stuart.sie...@gmail.com wrote: Yes, as a heavy Emacs/SLIME user who does not work with Common Lisp any more, I'd rather have a Clojure-specific Emacs environment, especially something that can do more introspection of the JVM, e.g., look up JavaDocs and examine classes through reflection. In my not-terribly-well-informed opinion, string-oriented protocols are easier to parse in string-oriented languages like Perl and Emacs Lisp, whereas byte-oriented protocols help avoid mixups with character encoding and line-endings. Pick your poison. -Stuart Sierraclojure.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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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: About a networked REPL...
On 21 March 2011 00:18, Chas Emerick cemer...@snowtide.com wrote:
In any case, my objective with nREPL was to get something working well that
had what I thought were the right semantics for the use cases I was concerned
with (i.e. point-to-point Clojure tooling backends). Lifting those semantics
onto other transports in the future shouldn't be difficult (I think Rich was
pretty unhappy with the protocol as well -- IIRC, he would have preferred
using STOMP directly, but it's important to some users of nREPL that external
dependencies be minimal/nonexistent, and a Clojure STOMP broker has yet to
come along).
FWIW, my personal preference would be construct a protocol for passing
around Clojure data-structures securely over a socket, and then build
your REPL protocol on top of that.
For instance, you could print your data structure to a string, then
encode it as a netstring (http://cr.yp.to/proto/netstrings.txt):
12:{:foo \bar\},
= {:foo bar}
I'm not sure we need a protocol like STOMP, because there doesn't seem
to be much streaming involved in a REPL.
- James
--
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
Not quite getting for (newb question)
Hey all, I'm not understanding why the following examples don't line up. In my mind they should be identical. What am i not getting? (user= (filter (fn [[x y]] ( x y)) (for [x (range 10) y (range 10)] [x y])) ([0 1] [0 2] [0 3] [0 4] [0 5] [0 6] [0 7] [0 8] [0 9] [1 2] [1 3] [1 4] [1 5] [1 6] [1 7] [1 8] [1 9] [2 3] [2 4] [2 5] [2 6] [2 7] [2 8] [2 9] [3 4] [3 5] [3 6] [3 7] [3 8] [3 9] [4 5] [4 6] [4 7] [4 8] [4 9] [5 6] [5 7] [5 8] [5 9] [6 7] [6 8] [6 9] [7 8] [7 9] [8 9]) user= (for [x (range 10) y (range 10) :while ( x y)] [x y]) () user= (filter (fn [[x y]] ( x y)) (for [x (range 10) y (range 10)] [x y])) ([1 0] [2 0] [2 1] [3 0] [3 1] [3 2] [4 0] [4 1] [4 2] [4 3] [5 0] [5 1] [5 2] [5 3] [5 4] [6 0] [6 1] [6 2] [6 3] [6 4] [6 5] [7 0] [7 1] [7 2] [7 3] [7 4] [7 5] [7 6] [8 0] [8 1] [8 2] [8 3] [8 4] [8 5] [8 6] [8 7] [9 0] [9 1] [9 2] [9 3] [9 4] [9 5] [9 6] [9 7] [9 8]) user= (for [x (range 10) y (range 10) :while ( x y)] [x y]) ([1 0] [2 0] [2 1] [3 0] [3 1] [3 2] [4 0] [4 1] [4 2] [4 3] [5 0] [5 1] [5 2] [5 3] [5 4] [6 0] [6 1] [6 2] [6 3] [6 4] [6 5] [7 0] [7 1] [7 2] [7 3] [7 4] [7 5] [7 6] [8 0] [8 1] [8 2] [8 3] [8 4] [8 5] [8 6] [8 7] [9 0] [9 1] [9 2] [9 3] [9 4] [9 5] [9 6] [9 7] [9 8]) user= -- 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: Not quite getting for (newb question)
Hi Brett, A :while clause continues the evaluation ONLY while it's expression is true (for [x (range 10) y (range 10) :while ( x y)] [x y]) will terminate as soon as ( x y) is false. Since ( 0 0) is the first expr to evaluate, evaluation stops right there. What you want is (for [x (range 10) y (range 10) :when ( x y)] [x y]) Cheers Andreas what you want is for ... :when On 21/03/2011, at 11:43 AM, Brett Morgan wrote: Hey all, I'm not understanding why the following examples don't line up. In my mind they should be identical. What am i not getting? (user= (filter (fn [[x y]] ( x y)) (for [x (range 10) y (range 10)] [x y])) ([0 1] [0 2] [0 3] [0 4] [0 5] [0 6] [0 7] [0 8] [0 9] [1 2] [1 3] [1 4] [1 5] [1 6] [1 7] [1 8] [1 9] [2 3] [2 4] [2 5] [2 6] [2 7] [2 8] [2 9] [3 4] [3 5] [3 6] [3 7] [3 8] [3 9] [4 5] [4 6] [4 7] [4 8] [4 9] [5 6] [5 7] [5 8] [5 9] [6 7] [6 8] [6 9] [7 8] [7 9] [8 9]) user= (for [x (range 10) y (range 10) :while ( x y)] [x y]) () user= (filter (fn [[x y]] ( x y)) (for [x (range 10) y (range 10)] [x y])) ([1 0] [2 0] [2 1] [3 0] [3 1] [3 2] [4 0] [4 1] [4 2] [4 3] [5 0] [5 1] [5 2] [5 3] [5 4] [6 0] [6 1] [6 2] [6 3] [6 4] [6 5] [7 0] [7 1] [7 2] [7 3] [7 4] [7 5] [7 6] [8 0] [8 1] [8 2] [8 3] [8 4] [8 5] [8 6] [8 7] [9 0] [9 1] [9 2] [9 3] [9 4] [9 5] [9 6] [9 7] [9 8]) user= (for [x (range 10) y (range 10) :while ( x y)] [x y]) ([1 0] [2 0] [2 1] [3 0] [3 1] [3 2] [4 0] [4 1] [4 2] [4 3] [5 0] [5 1] [5 2] [5 3] [5 4] [6 0] [6 1] [6 2] [6 3] [6 4] [6 5] [7 0] [7 1] [7 2] [7 3] [7 4] [7 5] [7 6] [8 0] [8 1] [8 2] [8 3] [8 4] [8 5] [8 6] [8 7] [9 0] [9 1] [9 2] [9 3] [9 4] [9 5] [9 6] [9 7] [9 8]) user= -- 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 -- Test-driven Dentistry (TDD!) - Not everything should be test driven - Michael Fogus -- ** Andreas Koestler, Software Engineer Leica Geosystems Pty Ltd 270 Gladstone Road, Dutton Park QLD 4102 Main: +61 7 3891 9772 Direct: +61 7 3117 8808 Fax: +61 7 3891 9336 Email: andreas.koest...@leica-geosystems.com www.leica-geosystems.com* when it has to be right, Leica Geosystems Please consider the environment before printing this email. -- 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: Not quite getting for (newb question)
Ahh, got it. Thank you Andreas. On Sun, Mar 20, 2011 at 6:55 PM, Andreas Kostler andreas.koestler.le...@gmail.com wrote: Hi Brett, A :while clause continues the evaluation ONLY while it's expression is true (for [x (range 10) y (range 10) :while ( x y)] [x y]) will terminate as soon as ( x y) is false. Since ( 0 0) is the first expr to evaluate, evaluation stops right there. What you want is (for [x (range 10) y (range 10) :when ( x y)] [x y]) Cheers Andreas what you want is for ... :when On 21/03/2011, at 11:43 AM, Brett Morgan wrote: Hey all, I'm not understanding why the following examples don't line up. In my mind they should be identical. What am i not getting? (user= (filter (fn [[x y]] ( x y)) (for [x (range 10) y (range 10)] [x y])) ([0 1] [0 2] [0 3] [0 4] [0 5] [0 6] [0 7] [0 8] [0 9] [1 2] [1 3] [1 4] [1 5] [1 6] [1 7] [1 8] [1 9] [2 3] [2 4] [2 5] [2 6] [2 7] [2 8] [2 9] [3 4] [3 5] [3 6] [3 7] [3 8] [3 9] [4 5] [4 6] [4 7] [4 8] [4 9] [5 6] [5 7] [5 8] [5 9] [6 7] [6 8] [6 9] [7 8] [7 9] [8 9]) user= (for [x (range 10) y (range 10) :while ( x y)] [x y]) () user= (filter (fn [[x y]] ( x y)) (for [x (range 10) y (range 10)] [x y])) ([1 0] [2 0] [2 1] [3 0] [3 1] [3 2] [4 0] [4 1] [4 2] [4 3] [5 0] [5 1] [5 2] [5 3] [5 4] [6 0] [6 1] [6 2] [6 3] [6 4] [6 5] [7 0] [7 1] [7 2] [7 3] [7 4] [7 5] [7 6] [8 0] [8 1] [8 2] [8 3] [8 4] [8 5] [8 6] [8 7] [9 0] [9 1] [9 2] [9 3] [9 4] [9 5] [9 6] [9 7] [9 8]) user= (for [x (range 10) y (range 10) :while ( x y)] [x y]) ([1 0] [2 0] [2 1] [3 0] [3 1] [3 2] [4 0] [4 1] [4 2] [4 3] [5 0] [5 1] [5 2] [5 3] [5 4] [6 0] [6 1] [6 2] [6 3] [6 4] [6 5] [7 0] [7 1] [7 2] [7 3] [7 4] [7 5] [7 6] [8 0] [8 1] [8 2] [8 3] [8 4] [8 5] [8 6] [8 7] [9 0] [9 1] [9 2] [9 3] [9 4] [9 5] [9 6] [9 7] [9 8]) user= -- 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 -- Test-driven Dentistry (TDD!) - Not everything should be test driven - Michael Fogus -- ** Andreas Koestler, Software Engineer Leica Geosystems Pty Ltd 270 Gladstone Road, Dutton Park QLD 4102 Main: +61 7 3891 9772 Direct: +61 7 3117 8808 Fax: +61 7 3891 9336 Email: andreas.koest...@leica-geosystems.com www.leica-geosystems.com* when it has to be right, Leica Geosystems Please consider the environment before printing this email. -- 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: Not quite getting for (newb question)
No worries, always a pleasure :) On 21/03/2011, at 12:43 PM, Brett Morgan wrote: Ahh, got it. Thank you Andreas. On Sun, Mar 20, 2011 at 6:55 PM, Andreas Kostler andreas.koestler.le...@gmail.com wrote: Hi Brett, A :while clause continues the evaluation ONLY while it's expression is true (for [x (range 10) y (range 10) :while ( x y)] [x y]) will terminate as soon as ( x y) is false. Since ( 0 0) is the first expr to evaluate, evaluation stops right there. What you want is (for [x (range 10) y (range 10) :when ( x y)] [x y]) Cheers Andreas what you want is for ... :when On 21/03/2011, at 11:43 AM, Brett Morgan wrote: Hey all, I'm not understanding why the following examples don't line up. In my mind they should be identical. What am i not getting? (user= (filter (fn [[x y]] ( x y)) (for [x (range 10) y (range 10)] [x y])) ([0 1] [0 2] [0 3] [0 4] [0 5] [0 6] [0 7] [0 8] [0 9] [1 2] [1 3] [1 4] [1 5] [1 6] [1 7] [1 8] [1 9] [2 3] [2 4] [2 5] [2 6] [2 7] [2 8] [2 9] [3 4] [3 5] [3 6] [3 7] [3 8] [3 9] [4 5] [4 6] [4 7] [4 8] [4 9] [5 6] [5 7] [5 8] [5 9] [6 7] [6 8] [6 9] [7 8] [7 9] [8 9]) user= (for [x (range 10) y (range 10) :while ( x y)] [x y]) () user= (filter (fn [[x y]] ( x y)) (for [x (range 10) y (range 10)] [x y])) ([1 0] [2 0] [2 1] [3 0] [3 1] [3 2] [4 0] [4 1] [4 2] [4 3] [5 0] [5 1] [5 2] [5 3] [5 4] [6 0] [6 1] [6 2] [6 3] [6 4] [6 5] [7 0] [7 1] [7 2] [7 3] [7 4] [7 5] [7 6] [8 0] [8 1] [8 2] [8 3] [8 4] [8 5] [8 6] [8 7] [9 0] [9 1] [9 2] [9 3] [9 4] [9 5] [9 6] [9 7] [9 8]) user= (for [x (range 10) y (range 10) :while ( x y)] [x y]) ([1 0] [2 0] [2 1] [3 0] [3 1] [3 2] [4 0] [4 1] [4 2] [4 3] [5 0] [5 1] [5 2] [5 3] [5 4] [6 0] [6 1] [6 2] [6 3] [6 4] [6 5] [7 0] [7 1] [7 2] [7 3] [7 4] [7 5] [7 6] [8 0] [8 1] [8 2] [8 3] [8 4] [8 5] [8 6] [8 7] [9 0] [9 1] [9 2] [9 3] [9 4] [9 5] [9 6] [9 7] [9 8]) user= -- 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 -- Test-driven Dentistry (TDD!) - Not everything should be test driven - Michael Fogus -- ** Andreas Koestler, Software Engineer Leica Geosystems Pty Ltd 270 Gladstone Road, Dutton Park QLD 4102 Main: +61 7 3891 9772 Direct: +61 7 3117 8808 Fax: +61 7 3891 9336 Email: andreas.koest...@leica-geosystems.com www.leica-geosystems.com* when it has to be right, Leica Geosystems Please consider the environment before printing this email. -- 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 -- Test-driven Dentistry (TDD!) - Not everything should be test driven - Michael Fogus -- ** Andreas Koestler, Software Engineer Leica Geosystems Pty Ltd 270 Gladstone Road, Dutton Park QLD 4102 Main: +61 7 3891 9772 Direct: +61 7 3117 8808 Fax: +61 7 3891 9336 Email: andreas.koest...@leica-geosystems.com www.leica-geosystems.com* when it has to be right, Leica Geosystems Please consider the environment before printing this email. -- 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: About a networked REPL...
On Mar 20, 12:16 pm, Chas Emerick cemer...@snowtide.com wrote: Martin, Thank you for the pushback. :-) I'm not pushing back, I'm really just trying to understand... On Mar 19, 2011, at 8:30 PM, Martin Blais wrote: I think this is wrong, because every single IDE client will have to adapt itself to the various changes occurring in the Clojure VM as it evolves. This is just creating M times the amount of porting problems (for each client). By keeping the complexity on the server, every IDE that speaks a common protocol (*) works between versions. There's no reason why the server couldn't provide a standard set of introspection / tooling utilities available -- it would be as easy as adding a proper dependency e.g. in your web project's pom/project.clj. Then you'd just be redoing Swank all over again. You'd be redesigning a different protocol to support the same kinds of operations. I don't really see the point, unless the current protocol is unsuitable somehow. A few people have been discussing the desired capabilities, and have started documenting desired semantics, and where each capability has already been implemented. Where is this information? - I take another issue at nREPL: if someone is going to implement a request/response protocol that supports only generic requests (because the complexity should live in the client), why bother at all, why not instead just make it a really, really simple network REPL, without any protocol at all? e.g. all input means eval, output is just output, no ids no nothing just a socket that you could connect to with telnet and have a repl right there, no protocol. telnet localhost 4005, type (+ 2 2) at the terminal, see 4 appear. That's it. I think it would be pretty straightforward to extend Emacs' inferior-lisp-mode to support talking to a socket like that instead of having to start a subprocess. This would give you vanilla communication with a live Clojure VM without having to start the VM from a parent process. I rather like this idea; it's the simplicity you currently enjoy with inferior-lisp, but over a socket; simple, can't break. Because a synchronous client is unsuitable for REPL tasks that require or desire asynchronous evaluation of expressions. I think you're missing my point; I understand that request/response is necessary for rich interaction and I understand why. What I'm saying above is that a dead simple option with no async support is also really valuable, because it is unlikely to break between versions, and it's already good enough for a lot of users via stdin/stdout pipes (i.e., inferior lisp). IMHO if people will bother implementing a request/response protocol, why not just stick with a rich protocol like Swank's? It'll just be reinventing the wheel otherwise. Swank is fundamentally emacs-only, and is defined outside of the Clojure community. I discuss the issues with swank in the readme here:https://github.com/clojure/tools.nrepl You don't. I have read both the nREPL readme and the document you link to; they state that swank is unsuitable somehow, but it doesn't say why. Why is swank an unsuitable protocol? What are its shortcomings? What features that it doesn't support require redesigning another protocol? (Keep in mind: Swank != Emacs.) - Another problem with Slime that turns people off is the weirdness in where the output goes. To detail the weirdness: How SLIME works (or its problems) is entirely orthogonal to network REPL design IMO. Sure; Note that fixing a couple of warts in Slime will make it good enough for a section of folks which may think that it's broken right now. The problem is not that Slime/Swank is broken, the problem is that it has a few warts that make it look radically different from a simple REPL with pipes, which I think is why some people dislike it. It probably just needs a bit more polishing. nREPL breaks up *err*, *out*, and a printed representation of expression results into separate slots in its responses, so clients can display response data however is appropriate for their environment. Note that I'm planning on adding optional multiplexing of System/out and System/err (much like is done in Cake) to nREPL so that clients can subscribe to those streams as desired. (*) Please note: I am aware that only Emacs supports the Swank protocol right now but I don't see why other IDEs couldn't support it too--it's just made up of LISP forms after all; in other words, if someone wants to replace the swank protocol by an equivalent one with a different encoding I don't really see the point. Anyway, for this discussion I'll assume emacs-rex is a suitable enough protocol; in fact, I think it probably is, because it has already proved itself with a large number of LISP environments, it has history. In any case, that's a separate discussion. I
Re: About a networked REPL...
On Mar 20, 10:48 pm, blais martin.bl...@gmail.com wrote: really valuable, because it is unlikely to break between versions, and it's already good enough for a lot of users via stdin/stdout pipes (i.e., inferior lisp). Like being able to just telnet to a running VM and type (+ 2 2) and see 4 printed on stdout. Not good enough for an IDE, but still useful. -- 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
