Re: About a networked REPL...

[blais]

On Mar 20, 10:48 pm, blais  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

Re: About a networked REPL...

[blais]

On Mar 20, 12:16 pm, Chas Emerick  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 numbe

Re: Not quite getting for (newb question)

[Andreas Kostler]

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 
>  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: Not quite getting for (newb question)

[Brett Morgan]

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)

[Andreas Kostler]

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

Not quite getting for (newb question)

[Brett Morgan]

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: About a networked REPL...

[James Reeves]

On 21 March 2011 00:18, Chas Emerick  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

Re: About a networked REPL...

[Chas Emerick]

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  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...

[Chas Emerick]

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: Beginning Clojure

[Andreas Kostler]

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: Dynamic scoping issue

[Meikel Brandmeyer]

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

Beginning Clojure

[Ent SaaS]

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: Throwing an Exception with get

[Andreas Kostler]

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
>  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

Re: Throwing an Exception with get

[Daniel Werner]

On 20 March 2011 22:02, Andreas Kostler
 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: Dynamic scoping issue

[Ken Wesson]

On Sun, Mar 20, 2011 at 5:41 PM, Tassilo Horn  wrote:
> Ken Wesson  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: Dynamic scoping issue

[Tassilo Horn]

Ken Wesson  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: About a networked REPL...

[Kevin Downey]

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  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]

On Sun, Mar 20, 2011 at 5:17 PM, Tassilo Horn  wrote:
> Ken Wesson  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: Dynamic scoping issue

[Tassilo Horn]

Ken Wesson  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: How to Sum a Sequence?

[Andreas Kostler]

>> 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: Throwing an Exception with get

[Andreas Kostler]

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
>  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: Dynamic scoping issue

[Ken Wesson]

On Sun, Mar 20, 2011 at 4:16 PM, Tassilo Horn  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

Dynamic scoping issue

[Tassilo Horn]

Hi all,

I have a problem with a var that I want to be dynamically scoped.  In my
DSL, I state types using symbols like 'localities.Locality, and at some
point some function resolves these types in some Java lib.

For convenience, I wanted to add a macro that binds simple names to
qualified names, so that you can use the simple name in the body of the
macro:

  (with-schema-imports [localities.Locality]
(code-using 'Locality ...))

This is my code:

--8<---cut here---start->8---
(def
  ^{:dynamic true ;; should be needed with only Clojure 1.3
:doc "A dynamically scoped map from simple names to qualified names."}
  *schema-imports* (hash-map))

(defn- keyval
  "Given a qualified name qn as string, symbol, or keyword, returns a vector of
the form [Bar foo.baz.Bar]."
  [qn]
  (let [qstr (name qn)
sn (subs qstr (inc (.lastIndexOf qstr ".")))]
[sn qstr]))

(defmacro with-schema-imports
  "Executes body with schema elems (given as vector of symbol, keywords, or
strings) imported and thus referrable by their simple name in body and its
dynamic scope."
  [elems & body]
  (let [keyvals (mapcat keyval elems)]
`(binding [*schema-imports* (assoc *schema-imports* ~@keyvals)]
   ~@body)))
--8<---cut here---end--->8---

But when I write something like that

--8<---cut here---start->8---
(with-schema-imports [localities.Locality]
  (println *schema-imports*)
  (vseq (rg) :cls 'Locality))
--8<---cut here---end--->8---

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 {}.

So it seems that my *schema-imports* var has only lexical scope, but
why?

The macroexpansion looks good to me:

--8<---cut here---start->8---
(clojure.core/binding [funql.core/*schema-imports*
   (clojure.core/assoc
funql.core/*schema-imports*
"Locality" "localities.Locality")]
  (println *schema-imports*)
  (vseq (rg) :cls (quote Locality)))
--8<---cut here---end--->8---

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...

[Stuart Sierra]

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 Sierra
clojure.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?

[Tassilo Horn]

Christian  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: How to Sum a Sequence?

[Michael Wood]

Hi

On 20 March 2011 17:47, Christian  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 

-- 
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...

[Kevin Downey]

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.

I thought you were just advocating for ditching slime because it's not
clojure centric enough, how does python fit into this?

On Sun, Mar 20, 2011 at 9:27 AM, Chas Emerick  wrote:
>
> 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



-- 
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: About a networked REPL...

[Chas Emerick]

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: clojure.string/replace-first return nil when not matched

[Takahiro Hozumi]

Hi,
Please bump up my JIRA membership level to make edits and I will fix
this bug.
I have an account named Takahiro Hozumi on dev.clojure.org already.
CA is also already sent.
Thanks.

On 3月11日, 午後10:55, Stuart Sierra  wrote:
> > (require '[clojure.string :as str])
> > (str/replace-first "abc def" #"ghi" (fn [a] (str a a)))
> > => nil
>
> That's a bug.  Createdhttp://dev.clojure.org/jira/browse/CLJ-753
>
> Thanks for the report.
>
> -Stuart Sierra
> clojure.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: About a networked REPL...

[Chas Emerick]

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 a

Re: How to Sum a Sequence?

[Christian]

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  wrote:
> Christian  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: How to Sum a Sequence?

[Daniel Werner]

On Mar 20, 10:22 am, Christian  wrote:
> 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.)

For this there is #'take-while:

(take-while #(< % 400) ...)

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

[Paul Dorman]

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  wrote:
> On Mar 16, 9:30 am, Ray Miller  wrote:
>
> > On 15 March 2011 08:46, Saul Hazledine  wrote:
>
> > > On Mar 15, 1:30 am, Paul Dorman  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

[Daniel Werner]

On Mar 20, 10:50 am, Andreas Kostler
 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

Re: Throwing an Exception with get

[Ambrose Bonnaire-Sergeant]

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

[Andreas Kostler]

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

Re: Throwing an Exception with get

[Ambrose Bonnaire-Sergeant]

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: How to Sum a Sequence?

[Andreas Kostler]

On 20/03/2011, at 8:25 PM, Christian wrote:

> Hello Andreas!
> 
> Thanks for your swift reply. I'll try to explain the reasoning behind
> my code.
> 
> In the Clojure Reference I found the function into, which is described
> like so:
> 
> Usage: (into to from)
> "Returns a new coll consisting of to-coll with all of the items of
> from-coll conjoined."
This is exactly what's happening:
(def v [1 2 3])
(into v (pop v))
=> [1 2 3 1 2]

However, 
v
=> [1 2 3]

It does not mutate the original vector. The same applies for conj.


> I'm currently reading the book "Programming Clojure". In it, the
> author has a chapter on binding which states that vectors are indeed
> immutable. I'm not sure if this is a problem of scope, but I thought
> that I could coerce fib-vec into receiving a new vec and throwing the
> old one away (making the old one available for deletion from the GC).
> That is why I used 'into fib-vec'. I thought it would re-bind fib-vec
> to itself, but with one element less. I used the same idea with
> ansVec.
See above. into doesn't rebind it's arguments. Rather it returns a sequence 
which contain the second argument added to the elements of the  first.
It doesn't physically alter the first argument.
> 
> Could you perhaps tell me why it cannot do that? Rather, is this
> behavior possible in Clojure?
> 
> PS:  Thanks for the book-tipp! I'll be sure to check it out.
> 
All this is intrinsic Clojure behaviour. Clojure is unique in this way. You 
will find that other flavours of Lisp allow mutable data (e.g. setf in common 
lisp).

Thassilo provided a more idiomatic solution to your problem.

Andreas

> On Mar 20, 10:48 am, Andreas Kostler
>  wrote:
>> 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 enviro

Re: clj-ldap - Clojure LDAP client

[Saul Hazledine]

On Mar 16, 9:30 am, Ray Miller  wrote:
> On 15 March 2011 08:46, Saul Hazledine  wrote:
>
> > On Mar 15, 1:30 am, Paul Dorman  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?

[Christian]

Hello Andreas!

Thanks for your swift reply. I'll try to explain the reasoning behind
my code.

In the Clojure Reference I found the function into, which is described
like so:

Usage: (into to from)
"Returns a new coll consisting of to-coll with all of the items of
from-coll conjoined."

I'm currently reading the book "Programming Clojure". In it, the
author has a chapter on binding which states that vectors are indeed
immutable. I'm not sure if this is a problem of scope, but I thought
that I could coerce fib-vec into receiving a new vec and throwing the
old one away (making the old one available for deletion from the GC).
That is why I used 'into fib-vec'. I thought it would re-bind fib-vec
to itself, but with one element less. I used the same idea with
ansVec.

Could you perhaps tell me why it cannot do that? Rather, is this
behavior possible in Clojure?

PS:  Thanks for the book-tipp! I'll be sure to check it out.

On Mar 20, 10:48 am, Andreas Kostler
 wrote:
> 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

Re: How to Sum a Sequence?

[Tassilo Horn]

Christian  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

Throwing an Exception with get

[Andreas Kostler]

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?

[Andreas Kostler]

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

How to Sum a Sequence?

[Christian]

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: About a networked REPL...

[Kevin Downey]

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  wrote:
> On Sat, Mar 19, 2011 at 7:36 PM, Sean Corfield  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

Re: About a networked REPL...

[Gary Schiltz]

On Mar 19, 7:30 pm, Martin Blais  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