Step by step debugging

[Bastien]

I'm a big fan of edebug, the Emacs debugger, which allows step through
debugging (and breakpoints, and some more fun.)

Is there anything similar for Clojure?

For example, from an Emacs (cider) REPL, I'd evaluate some Clojure
expression, then a window would let me go through a buffer containing
a copy of the function being evaluated, while allowing me to stop at
any step, and to show the result of each step in the minibuffer.

(I'm aware of LightTable "live" REPL, but this is not exactly what
I describe above.)

Thanks for any hints/pointers,

-- 
 Bastien

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[juan.facorro]

Hi Bastien,

I think Ritz  [1] might be what you are 
looking for. Although I haven't tried it myself yet, I recently saw 
the presentation "Ritz, The Missing Clojure Tooling" and really liked what 
I saw.

HTH,

J  

[1]: https://github.com/pallet/ritz
[2]: http://www.infoq.com/presentations/ritz-clojure

On Thursday, November 7, 2013 5:16:17 PM UTC+8, Bastien Guerry wrote:
>
> I'm a big fan of edebug, the Emacs debugger, which allows step through 
> debugging (and breakpoints, and some more fun.) 
>
> Is there anything similar for Clojure? 
>
> For example, from an Emacs (cider) REPL, I'd evaluate some Clojure 
> expression, then a window would let me go through a buffer containing 
> a copy of the function being evaluated, while allowing me to stop at 
> any step, and to show the result of each step in the minibuffer. 
>
> (I'm aware of LightTable "live" REPL, but this is not exactly what 
> I describe above.) 
>
> Thanks for any hints/pointers, 
>
> -- 
>  Bastien 
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Bastien]

Hi Juan,

"juan.facorro"  writes:

> I think Ritz [1] might be what you are looking for. Although I
> haven't tried it myself yet, I recently saw the presentation "Ritz,
> The Missing Clojure Tooling" and really liked what I saw.

This seems great indeed, I'll watch the presentation carefully.

Thanks!

-- 
 Bastien

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Phillip Lord]

Ritz does some things, but it doesn't do step through like edebug.

I've never found anything as nice as edebug in any language; I guess,
it's the big advantage of running your editor and whatever you are
debugging in the environment.

Phil

Bastien  writes:
> I'm a big fan of edebug, the Emacs debugger, which allows step through
> debugging (and breakpoints, and some more fun.)
>
> Is there anything similar for Clojure?
>
> For example, from an Emacs (cider) REPL, I'd evaluate some Clojure
> expression, then a window would let me go through a buffer containing
> a copy of the function being evaluated, while allowing me to stop at
> any step, and to show the result of each step in the minibuffer.
>
> (I'm aware of LightTable "live" REPL, but this is not exactly what
> I describe above.)
>
> Thanks for any hints/pointers,
>
> -- 
>  Bastien
>
> -- 

-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[ANN] friend-oauth2 0.1.0

[Dave Della Costa]

Hi folks,

friend-oauth2 0.1.0 is out.

https://github.com/ddellacosta/friend-oauth2

Changes:

- adds credential-fn for injecting your own functionality in the
post-3rd-party-authentication stage. Thanks go to Kevin Lynagh
(https://github.com/lynaghk) for this feature.

- More refactoring of entire codebase. Tests and code re-written to be
more idiomatic Clojure.

Examples have been updated to reflect these changes:

https://github.com/ddellacosta/friend-oauth2-examples

...with additional thanks to Ken Restivo (https://github.com/kenrestivo)
for code improvements which were incorporated both into the
friend-oauth2 lib and the examples.

Please feel free to drop me a line if you have questions or comments.
And of course bug reports/feature requests/patches/etc. welcome.

Cheers,
Dave

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Bastien]

phillip.l...@newcastle.ac.uk (Phillip Lord) writes:

> Ritz does some things, but it doesn't do step through like edebug.
>
> I've never found anything as nice as edebug in any language; I guess,
> it's the big advantage of running your editor and whatever you are
> debugging in the environment.

Well, I suspect this -- but I'll see what comes close enough.

Best,

-- 
 Bastien

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: What font is used for Clojure on clojure.org?

[Erlis Vidal]

Is there any screen cast that shows how to use Cider? I would like to see
it in action.

I really liked this logo
https://github.com/clojure-emacs/cider/issues/399#issuecomment-27805491 I
think it blends the Cider concept with the clojure characters ... the other
are more colorful but really it looks like a coffee mug.

Great Job!

Erlis


On Wed, Nov 6, 2013 at 12:32 PM, Tim Visher  wrote:

> Thanks, Tom!
>
> Here's what I did with it:
> https://github.com/clojure-emacs/cider/issues/399#issuecomment-27878950
>
>
> On Wed, Nov 6, 2013 at 11:56 AM, Tom Hickey  wrote:
> > Hi Tim,
> >
> > That is Avenir 65 Medium.
> >
> > Cheers,
> > Tom Hickey
> >
> >
> > On Wednesday, November 6, 2013 11:06:24 AM UTC-5, Tim Visher wrote:
> >>
> >> I'm looking for it to incorporate it into a cIDEr logo I'm playing with.
> >>
> >> --
> >>
> >> In Christ,
> >>
> >> Timmy V.
> >>
> >> http://blog.twonegatives.com/
> >> http://five.sentenc.es/ -- Spend less time on mail
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: What font is used for Clojure on clojure.org?

[Tim Visher]

It's funny that in the comments bbatsov and I have already explored
this space a bit. :)

It seems like everyone has a different experience of drinking cider.
I've never drank cider in anything but cups or mugs, and hot cider is
always served in a mug in my circles. While it seems like other people
have only ever drank it from champagne glasses. I wonder if this'll be
a consistent source of confusion. :)

On Thu, Nov 7, 2013 at 8:04 AM, Erlis Vidal  wrote:
> Is there any screen cast that shows how to use Cider? I would like to see it
> in action.
>
> I really liked this logo
> https://github.com/clojure-emacs/cider/issues/399#issuecomment-27805491 I
> think it blends the Cider concept with the clojure characters ... the other
> are more colorful but really it looks like a coffee mug.
>
> Great Job!
>
> Erlis
>
>
> On Wed, Nov 6, 2013 at 12:32 PM, Tim Visher  wrote:
>>
>> Thanks, Tom!
>>
>> Here's what I did with it:
>> https://github.com/clojure-emacs/cider/issues/399#issuecomment-27878950
>>
>>
>> On Wed, Nov 6, 2013 at 11:56 AM, Tom Hickey  wrote:
>> > Hi Tim,
>> >
>> > That is Avenir 65 Medium.
>> >
>> > Cheers,
>> > Tom Hickey
>> >
>> >
>> > On Wednesday, November 6, 2013 11:06:24 AM UTC-5, Tim Visher wrote:
>> >>
>> >> I'm looking for it to incorporate it into a cIDEr logo I'm playing
>> >> with.
>> >>
>> >> --
>> >>
>> >> In Christ,
>> >>
>> >> Timmy V.
>> >>
>> >> http://blog.twonegatives.com/
>> >> http://five.sentenc.es/ -- Spend less time on mail
>> >
>> > --
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with
>> > your
>> > first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Clojure" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to clojure+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Newbie questions: include external libraries from lein REPL

[Starry SHI]

Hi. I am new to clojure, and I find leiningen REPL is a convenient tool for 
clojure code testing. However, I find I cannot include external java 
libraries and call functions defined in those libraries from lein REPL.

For example, my clojure code needs to compute square root, which is defined 
in clojure-contrib (clojure.contrib.math). I don't know how to include 
clojure-contrib jar file into lein REPL, such that I can call sqrt 
functions from my own clojure code.

Can anyone share your experience on how to do it?

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

newbie question: how to include external libraries from Leiningen REPL

[Starry SHI]

Hi, I am new to clojure and I find lein REPL very convenient to use. But I 
have one question: in REPL, how to include functions defined in other 
libraries and call them in my clojure code?

For example, my code need to call square root function defined in 
clojure.contrib.math (included in clojure-contrib.jar). Can anyone tell me 
how to include this jar file from lein repl, so that my code can call sqrt 
function?

Thank you! 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: introducing CloServe, a view first web framework in Clojure

[jiawei . zhao]

If anyone of you is trying this, I have update my html editor software 
http://www.mkrrf-it.com/cloedit ,
with it you can get HTML snippets in Hickory or Hiccup form, which can then 
be copy/paste to use in 
Clojure code.

Best Regards,
Jiawei

On Tuesday, November 5, 2013 1:29:14 PM UTC-5, jiawe...@mkrrf-it.com wrote:
>
> Hi Folks,
>
> Inspired by the Lift framework, I have started a project to bring similar 
> view first web framework to Clojure.
>
> Currently it has implemented some features like surround, embed, ajax 
> form, comet, rest. The code is available at:
>
> https://github.com/zhaojw/closerve
>
> Live demo:
>
> http://closerve.mkrrf-it.com/lazyload
>
> Still in very primitive stage. Any contributions and comments are welcome!
>
> Best Regards,
> Jiawei
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: What font is used for Clojure on clojure.org?

[Erlis Vidal]

And what about the screencasts?
On Nov 7, 2013 8:34 AM, "Tim Visher"  wrote:

> It's funny that in the comments bbatsov and I have already explored
> this space a bit. :)
>
> It seems like everyone has a different experience of drinking cider.
> I've never drank cider in anything but cups or mugs, and hot cider is
> always served in a mug in my circles. While it seems like other people
> have only ever drank it from champagne glasses. I wonder if this'll be
> a consistent source of confusion. :)
>
> On Thu, Nov 7, 2013 at 8:04 AM, Erlis Vidal  wrote:
> > Is there any screen cast that shows how to use Cider? I would like to
> see it
> > in action.
> >
> > I really liked this logo
> > https://github.com/clojure-emacs/cider/issues/399#issuecomment-27805491I
> > think it blends the Cider concept with the clojure characters ... the
> other
> > are more colorful but really it looks like a coffee mug.
> >
> > Great Job!
> >
> > Erlis
> >
> >
> > On Wed, Nov 6, 2013 at 12:32 PM, Tim Visher 
> wrote:
> >>
> >> Thanks, Tom!
> >>
> >> Here's what I did with it:
> >> https://github.com/clojure-emacs/cider/issues/399#issuecomment-27878950
> >>
> >>
> >> On Wed, Nov 6, 2013 at 11:56 AM, Tom Hickey  wrote:
> >> > Hi Tim,
> >> >
> >> > That is Avenir 65 Medium.
> >> >
> >> > Cheers,
> >> > Tom Hickey
> >> >
> >> >
> >> > On Wednesday, November 6, 2013 11:06:24 AM UTC-5, Tim Visher wrote:
> >> >>
> >> >> I'm looking for it to incorporate it into a cIDEr logo I'm playing
> >> >> with.
> >> >>
> >> >> --
> >> >>
> >> >> In Christ,
> >> >>
> >> >> Timmy V.
> >> >>
> >> >> http://blog.twonegatives.com/
> >> >> http://five.sentenc.es/ -- Spend less time on mail
> >> >
> >> > --
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups "Clojure" group.
> >> > To post to this group, send email to clojure@googlegroups.com
> >> > Note that posts from new members are moderated - please be patient
> with
> >> > your
> >> > first post.
> >> > To unsubscribe from this group, send email to
> >> > clojure+unsubscr...@googlegroups.com
> >> > For more options, visit this group at
> >> > http://groups.google.com/group/clojure?hl=en
> >> > ---
> >> > You received this message because you are subscribed to the Google
> >> > Groups
> >> > "Clojure" group.
> >> > To unsubscribe from this group and stop receiving emails from it, send
> >> > an
> >> > email to clojure+unsubscr...@googlegroups.com.
> >> > For more options, visit https://groups.google.com/groups/opt_out.
> >>
> >> --
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> ---
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to clojure+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new m

Re: Newbie questions: include external libraries from lein REPL

[Cedric Greevey]

Assuming the Java or Clojure library is on your classpath, it *should* be
usable from the REPL.

(import '[java.library SomeClass])

(.foo (SomeClass. 42))

(require '[clojure.contrib.math :as m])

(m/sqrt 42.0)

or whatever



On Thu, Nov 7, 2013 at 8:00 AM, Starry SHI  wrote:

> Hi. I am new to clojure, and I find leiningen REPL is a convenient tool
> for clojure code testing. However, I find I cannot include external java
> libraries and call functions defined in those libraries from lein REPL.
>
> For example, my clojure code needs to compute square root, which is
> defined in clojure-contrib (clojure.contrib.math). I don't know how to
> include clojure-contrib jar file into lein REPL, such that I can call sqrt
> functions from my own clojure code.
>
> Can anyone share your experience on how to do it?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: newbie question: how to include external libraries from Leiningen REPL

[Cedric Greevey]

Assuming the Java or Clojure library is on your classpath, it *should* be
usable from the REPL.

(import '[java.library SomeClass])

(.foo (SomeClass. 42))

(require '[clojure.contrib.math :as m])

(m/sqrt 42.0)

or whatever.

(Didn't this exact question just get asked by someone five minutes ago?
Even looking for the same math function.)



On Thu, Nov 7, 2013 at 8:18 AM, Starry SHI  wrote:

> Hi, I am new to clojure and I find lein REPL very convenient to use. But I
> have one question: in REPL, how to include functions defined in other
> libraries and call them in my clojure code?
>
> For example, my code need to call square root function defined in
> clojure.contrib.math (included in clojure-contrib.jar). Can anyone tell me
> how to include this jar file from lein repl, so that my code can call sqrt
> function?
>
> Thank you!
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: What font is used for Clojure on clojure.org?

[Tim Visher]

Cider _is_ nrepl.el at this point, essentially, so any screencast
documenting nrepl.el would get you most of the way there.

Also, Cider is _unstable_ at this point. I'm still using nrepl 0.2.0
and it's working fine. I would _not_ recommend upgrading to Cider at
this point.

On Thu, Nov 7, 2013 at 9:10 AM, Erlis Vidal  wrote:
> And what about the screencasts?
>
> On Nov 7, 2013 8:34 AM, "Tim Visher"  wrote:
>>
>> It's funny that in the comments bbatsov and I have already explored
>> this space a bit. :)
>>
>> It seems like everyone has a different experience of drinking cider.
>> I've never drank cider in anything but cups or mugs, and hot cider is
>> always served in a mug in my circles. While it seems like other people
>> have only ever drank it from champagne glasses. I wonder if this'll be
>> a consistent source of confusion. :)
>>
>> On Thu, Nov 7, 2013 at 8:04 AM, Erlis Vidal  wrote:
>> > Is there any screen cast that shows how to use Cider? I would like to
>> > see it
>> > in action.
>> >
>> > I really liked this logo
>> > https://github.com/clojure-emacs/cider/issues/399#issuecomment-27805491
>> > I
>> > think it blends the Cider concept with the clojure characters ... the
>> > other
>> > are more colorful but really it looks like a coffee mug.
>> >
>> > Great Job!
>> >
>> > Erlis
>> >
>> >
>> > On Wed, Nov 6, 2013 at 12:32 PM, Tim Visher 
>> > wrote:
>> >>
>> >> Thanks, Tom!
>> >>
>> >> Here's what I did with it:
>> >> https://github.com/clojure-emacs/cider/issues/399#issuecomment-27878950
>> >>
>> >>
>> >> On Wed, Nov 6, 2013 at 11:56 AM, Tom Hickey  wrote:
>> >> > Hi Tim,
>> >> >
>> >> > That is Avenir 65 Medium.
>> >> >
>> >> > Cheers,
>> >> > Tom Hickey
>> >> >
>> >> >
>> >> > On Wednesday, November 6, 2013 11:06:24 AM UTC-5, Tim Visher wrote:
>> >> >>
>> >> >> I'm looking for it to incorporate it into a cIDEr logo I'm playing
>> >> >> with.
>> >> >>
>> >> >> --
>> >> >>
>> >> >> In Christ,
>> >> >>
>> >> >> Timmy V.
>> >> >>
>> >> >> http://blog.twonegatives.com/
>> >> >> http://five.sentenc.es/ -- Spend less time on mail
>> >> >
>> >> > --
>> >> > --
>> >> > You received this message because you are subscribed to the Google
>> >> > Groups "Clojure" group.
>> >> > To post to this group, send email to clojure@googlegroups.com
>> >> > Note that posts from new members are moderated - please be patient
>> >> > with
>> >> > your
>> >> > first post.
>> >> > To unsubscribe from this group, send email to
>> >> > clojure+unsubscr...@googlegroups.com
>> >> > For more options, visit this group at
>> >> > http://groups.google.com/group/clojure?hl=en
>> >> > ---
>> >> > You received this message because you are subscribed to the Google
>> >> > Groups
>> >> > "Clojure" group.
>> >> > To unsubscribe from this group and stop receiving emails from it,
>> >> > send
>> >> > an
>> >> > email to clojure+unsubscr...@googlegroups.com.
>> >> > For more options, visit https://groups.google.com/groups/opt_out.
>> >>
>> >> --
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups "Clojure" group.
>> >> To post to this group, send email to clojure@googlegroups.com
>> >> Note that posts from new members are moderated - please be patient with
>> >> your first post.
>> >> To unsubscribe from this group, send email to
>> >> clojure+unsubscr...@googlegroups.com
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/clojure?hl=en
>> >> ---
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "Clojure" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an
>> >> email to clojure+unsubscr...@googlegroups.com.
>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>> > --
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with
>> > your
>> > first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Clojure" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to clojure+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>>
>> --
>> --
>> 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

Re: Step by step debugging

[Alex Miller]

If you're willing to look outside of Emacs *shock* *horror*, both Eclipse 
CCW and IntelliJ Cursive have debuggers that work to some degree with 
Clojure. 

On Thursday, November 7, 2013 3:16:17 AM UTC-6, Bastien Guerry wrote:
>
> I'm a big fan of edebug, the Emacs debugger, which allows step through 
> debugging (and breakpoints, and some more fun.) 
>
> Is there anything similar for Clojure? 
>
> For example, from an Emacs (cider) REPL, I'd evaluate some Clojure 
> expression, then a window would let me go through a buffer containing 
> a copy of the function being evaluated, while allowing me to stop at 
> any step, and to show the result of each step in the minibuffer. 
>
> (I'm aware of LightTable "live" REPL, but this is not exactly what 
> I describe above.) 
>
> Thanks for any hints/pointers, 
>
> -- 
>  Bastien 
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Bastien]

Hi Alex,

Alex Miller  writes:

> If you're willing to look outside of Emacs *shock* *horror*, both
> Eclipse CCW and IntelliJ Cursive have debuggers that work to some
> degree with Clojure. 

I love testing new tools, I did not sign a life-time contract with
any software ;)

Is there a video somewhere where I can see this debugging tools in
action?

Thanks!

-- 
 Bastien

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Alex Miller]

Not to my knowledge. (if anyone wants to make one, that would be useful
hint hint)

I would try asking on the CCW list at
https://groups.google.com/forum/#!msg/clojuredev-users/ for help on the
CCW/Eclipse debugger.

For Cursive, there is some info at
http://cursiveclojure.com/userguide/repl.html on starting a debug REPL.




On Thu, Nov 7, 2013 at 8:37 AM, Bastien  wrote:

> Hi Alex,
>
> Alex Miller  writes:
>
> > If you're willing to look outside of Emacs *shock* *horror*, both
> > Eclipse CCW and IntelliJ Cursive have debuggers that work to some
> > degree with Clojure.
>
> I love testing new tools, I did not sign a life-time contract with
> any software ;)
>
> Is there a video somewhere where I can see this debugging tools in
> action?
>
> Thanks!
>
> --
>  Bastien
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ANN: ClojureScript 0.0-2014 - source maps, incremental compilation, and internal changes

[Alan Moore]

Just in case it hasn't been mentioned lately... you guys rock!

Thank you *so* much for your hard work on these tools... let me know how I can 
help.

Alan

On Wednesday, November 6, 2013 12:24:08 PM UTC-8, David Nolen wrote:
> Oh, the speed of incremental compilation is now dependent on tools preserving 
> the complier environment information - Chas Emerick should be cutting a 
> release of lein-cljsbuild that does this when ClojureScript 0.0-2014 hits 
> Maven Central.
> 
> 
> 
> 
> On Wed, Nov 6, 2013 at 3:09 PM, David Nolen  wrote:
> 
> 
> 
> 
> ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> 
> 
> README and source code: https://github.com/clojure/clojurescript
> 
> 
> 
> New release version: 0.0-2014
> 
> 
> Leiningen dependency information:
> 
> 
>     [org.clojure/clojurescript "0.0-2014"]
> 
> 
> There are a number of significant enhancements in this
> 
> 
> release. We finally have relative source maps! This should be big
> for people integrating ClojureScript with existing web
> based workflows.
> 
> 
> Under the hood Chas Emerick has improved how the analyzer works making
> 
> 
> it thread safe. This make the compiler considerably more robust and
> eliminates some race conditions in the browser REPL support.
> 
> 
> Incremental compilation is enhanced both with and without source
> 
> 
> maps. In particular we now tag ClojureScript compiled JavaScript files
> with the version of the compiler used - this should make transitioning
> to a new version of the compiler considerably less frustrating - stale
> 
> 
> files will get compiled.
> 
> 
> For those people using the compiler internals directly you will likely
> encounter breakage. If anyone feels inclined to outline a more stable
> interface to internals please get involved in leading an incremental
> 
> 
> process towards a stable and flexible API for tool builders.
> 
> 
> Enhancements:
> * relative source map paths, all original sources will be copied to
>   :ouput-dir this should make integrating with web workflow much simpler.
> 
> 
> * runtime obtainable compiler version number, *clojurescript-version* now
>   available at runtime as a string
> 
> 
> Bug fixes:
> * CLJS-643: make the ClojureScript compiler (more) idempotent
> 
> 
> * CLJS-662: CLJS files compiled from JARs get lost from source map
> * CLJS-661: (try ... (catch :default e ...) ...)
> * CLJS-627: Add warnings on function arity problems
> * CLJS-654: Quit repljs on ^D, don't loop on nil
> 
> 
> * CLJS-659: tag compiled files with compiler version
> * CLJS-642: deftype/record should not emit goog.provide
> * CLJS-648: persistent assoc/conj on a transient-created collision node
> * CLJS-631: Use ana/namespaces for shadowing vars
> 
> 
> * CLJS-641: js* overflow for large inputs
> * CLJS-645: parse-ns needs to include 'constants-table as a dep
> * CLJS-646: single segment namespaces and reify don't work
> * CLJS-521: pass along entire repl environment when loading dependencies

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Rob Ashton]

There is redl which does some of this too, that's more for the vim workflow
though

On Thursday, November 7, 2013, Phillip Lord wrote:

>
>
> Ritz does some things, but it doesn't do step through like edebug.
>
> I've never found anything as nice as edebug in any language; I guess,
> it's the big advantage of running your editor and whatever you are
> debugging in the environment.
>
> Phil
>
> Bastien > writes:
> > I'm a big fan of edebug, the Emacs debugger, which allows step through
> > debugging (and breakpoints, and some more fun.)
> >
> > Is there anything similar for Clojure?
> >
> > For example, from an Emacs (cider) REPL, I'd evaluate some Clojure
> > expression, then a window would let me go through a buffer containing
> > a copy of the function being evaluated, while allowing me to stop at
> > any step, and to show the result of each step in the minibuffer.
> >
> > (I'm aware of LightTable "live" REPL, but this is not exactly what
> > I describe above.)
> >
> > Thanks for any hints/pointers,
> >
> > --
> >  Bastien
> >
> > --
>
> --
> Phillip Lord,   Phone: +44 (0) 191 222 7827
> Lecturer in Bioinformatics, Email:
> phillip.l...@newcastle.ac.uk 
> School of Computing Science,
> http://homepages.cs.ncl.ac.uk/phillip.lord
> Room 914 Claremont Tower,   skype: russet_apples
> Newcastle University,   twitter: phillord
> NE1 7RU
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: newbie question: how to include external libraries from Leiningen REPL

[Mars0i]

I'm pretty new, also.  The Leiningen documentation that's easy to find has 
all of the information you need ... but it's not easy to sort out at 
first.  Cedric Greevey gives the answer for standard libraries that usually 
come with Clojure.  For others, I suggest:

Find the library name and version number that you want at clojars.org.

Create a project directory with a command like:
lein new app newdir

Then edit newdir/project.clj:
Add 
[libname-from-clojars.org "version number"]
inside the outer pair of brackets [] after :dependencies,
and save.

Then change to the newdir directory and enter
lein deps

Then start the lein repl.

Then follow Cedric's instructions.
 
On Thursday, November 7, 2013 7:18:30 AM UTC-6, Starry SHI wrote:
>
> Hi, I am new to clojure and I find lein REPL very convenient to use. But I 
> have one question: in REPL, how to include functions defined in other 
> libraries and call them in my clojure code?
>
> For example, my code need to call square root function defined in 
> clojure.contrib.math (included in clojure-contrib.jar). Can anyone tell me 
> how to include this jar file from lein repl, so that my code can call sqrt 
> function?
>
> Thank you! 
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: What are effective ways to debug Clojure code?

[Gary Trakhman]

The absolutely most useful thing I reach for time and again is the dbg
macro:
http://www.learningclojure.com/2010/09/clojure-macro-tutorial-part-i-getting.html
(defmacro dbg[x] `(let [x# ~x] (println '~x "=" x#) x#))

My current variation:

(defn pprint-str
  [x]
  (with-out-str (pp/pprint x)))

(defmacro dbg
  [x]
  `(let [x# ~x]
 (printf "dbg %s:%s> %s is %s\n"
   ~*ns*
   ~(:line (meta &form))
   ~(pr-str x)
   (pprint-str x#))
 (flush)
 x#))





On Wed, Nov 6, 2013 at 10:37 PM, Jeffrey Charles
wrote:

> I'm interested in hearing how people who use Clojure in production are
> debugging their code, particularly those who use Emacs.
>
> I am having issues quickly locating problems in my Clojure code that are
> identified by automated integration test failures. As an example, I had a
> Midje test that would make an HTTP call into my application running
> Compojure and Liberator on Ring on Jetty and I'd get an error back in a
> stacktrace in my shell running the Ring process. I got to a somewhat useful
> error of not being able to find a terminator for a JSON object which I
> correctly divined was actually that the request body was empty. My usual
> approach to debugging these sorts of problems in C# and Visual Studio is to
> set the built-in debugger to break on CLR exceptions and then run the
> integration test with my debugger attached to the web server process and
> take a look at the exception and local variables starting at the bottom of
> the stack and going up the stack until I spot something funky. I'm
> completely lost in figuring out how to do something similar in Clojure and
> Emacs or a shell, that is to say, running something that will pause
> execution and let me examine the exception and in-scope variables on a
> stack frame by stack frame basis with source code context (bonus points if
> it's a REPL).
>
> One thing I've taken a look at is ritz and ritz-nrepl but I seem to get
> errors when I try to use them. Specifically, "Symbol's value as variable is
> void: nrepl-mode-map" which seems to be an already reported issue. As well,
> the Github repositories don't appear to have been updated in several months
> which makes me pessimistic that these libraries will be meaningfully
> maintained and as a result, I feel uncomfortable relying on them.
>
> Another thing I looked at was George Jahad's Clojure Debug Toolkit which
> also doesn't seem to have gotten any love in the last few years and has
> pretty minimal public documentation around using it..
>
> While playing around with functions in the REPL usually does the job,
> sometimes the bugs and their locations are not obvious or they're at
> integration points where the input is a complicated object. I'd like to
> know what other developers who use Clojure do when they need to debug
> something and a REPL in a namespace with minimal execution context doesn't
> seem to do the trick.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

confused over meta on var

[Phillip Lord]

I find myself confused by the metadata on a var. Consider this code:

(def a-test-var 10)

(pritnln (meta #'a-test-var))

Now when run under "lein test" (by stuffing it into a test namespace), I
get this


{:ns #, :name a-test-var, :column 1, :line 102, 
:file tawny/util_test.clj}


But, when evaled in a live REPL I get this...


{:ns #, :name a-test-var, :column 1, :line 102, 
:file "/home/phillord/src/knowledge/tawny-owl/test/tawny/util_test.clj"}


So, how come the :file is fully qualified in one case, and relative in
the other?

Phil

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Lee Spector]

I'd like to chime in here from a background that involved a lot of Common 
Lisping back in the day.

I have been continually dismayed, as I've moved further from Common Lisp, that 
debugging facilities that are so basic and ubiquitous and helpful in that world 
are considered exotic or specialized or necessarily tied to particular IDEs or 
tool chains in other language ecosystems.

Even more basic (and useful, in my experience) than things like steppers or the 
ability to set break points is the ability just to see the values of locals 
when an error occurs. This is so obviously useful, and so obviously doable (for 
decades), that I'm really quite stunned that it's so complicated to do in 
Clojure and tied to a particular toolset if you can do it at all.

In Common Lisp when you hit an error you're thrown into a break loop REPL in 
which you can view locals, move up and down the stack, and do lots of other 
fancier things (re-binding things, restarting...) that are probably useful in 
some situations, but just being able to see the locals is, in my experience, 
the really huge win. It doesn't matter what IDE you're using or if you're 
running it from a command line or whatever -- it's part of the language and 
easy to access no matter how you write and run your code. And my guess is that 
every Common Lisper takes advantage of this frequently. Different 
implementations/environments provide different modes of access to this 
information (e.g. some are GUI-based, and in emacs you can have interactive 
access to it using interaction conventions that seemed like a good idea in the 
1970s :-), but there's always some way to get the information. 

By contrast in Clojure this information seems really hard to come by. I saw and 
was excited by a Ritz video -- and I note the enthusiastic applause from the 
crowd when it was shown that you could see locals (gasp!) -- but my 
understanding is that this functionality requires commitment to an Emacs-based 
tool set with all that that implies (which is a lot, IMHO).

When I hit an error running my code from "lein run" or from Clooj or from 
Eclipse/CCW (or I think from any other way that I might run it) I get (or can 
easily get) a backtrace that shows the function call stack at the time of the 
error... which is good, but surely (?) the locals are also available when the 
backtrace is produced and I really also want to see those. The ability to 
browse and navigate this information dynamically, as in a Common Lisp break 
loop, is cool but I can understand that something about the Clojure/JVM 
execution architecture might make that difficult -- maybe that really would 
have to be tied to a particular IDE? However, if it would just dump all of the 
values of the locals to standard output, just like it does already with the 
trace, then I'd be plenty happy since I could dig through that output to find 
what I need but can't currently get. (Yes, dumping the values of all of the 
locals might produce a lot of output and yes, one might want to make this an 
option that could be turned off or on, maybe including options re: limits on 
how much of sequences to print, etc.)

I guess the bottom line of this long message (sorry) is that I hope that some 
of the great tool developers in this community will continue to consider 
providing things like debugging tools that are as untethered as possible from 
particular IDEs. My impression is that nrepl (and maybe other projects) are 
intended to help "untether" things in this way, but it still seems like a lot 
of people assume that something like access to locals should naturally be tied 
to a specific IDE. From my perspective that seems like a really unfortunate 
assumption. I realize that debugging tools are unlikely to become "part of the 
language" in Clojure as they are in Common Lisp, but I think there's an 
important middle ground between that and being available only within some 
specific IDE.

Thanks,

 -Lee


> phillip.l...@newcastle.ac.uk (Phillip Lord) writes:
> 
>> Ritz does some things, but it doesn't do step through like edebug.
>> 
>> I've never found anything as nice as edebug in any language; I guess,
>> it's the big advantage of running your editor and whatever you are
>> debugging in the environment.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Rob Ashton]

There is redl which does some of this too, that's more for the vim workflow
though

On Thursday, November 7, 2013, Phillip Lord wrote:

>
>
> Ritz does some things, but it doesn't do step through like edebug.
>
> I've never found anything as nice as edebug in any language; I guess,
> it's the big advantage of running your editor and whatever you are
> debugging in the environment.
>
> Phil
>
> Bastien > writes:
> > I'm a big fan of edebug, the Emacs debugger, which allows step through
> > debugging (and breakpoints, and some more fun.)
> >
> > Is there anything similar for Clojure?
> >
> > For example, from an Emacs (cider) REPL, I'd evaluate some Clojure
> > expression, then a window would let me go through a buffer containing
> > a copy of the function being evaluated, while allowing me to stop at
> > any step, and to show the result of each step in the minibuffer.
> >
> > (I'm aware of LightTable "live" REPL, but this is not exactly what
> > I describe above.)
> >
> > Thanks for any hints/pointers,
> >
> > --
> >  Bastien
> >
> > --
>
> --
> Phillip Lord,   Phone: +44 (0) 191 222 7827
> Lecturer in Bioinformatics, Email:
> phillip.l...@newcastle.ac.uk 
> School of Computing Science,
> http://homepages.cs.ncl.ac.uk/phillip.lord
> Room 914 Claremont Tower,   skype: russet_apples
> Newcastle University,   twitter: phillord
> NE1 7RU
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

ANN: byte vector backed, utf8 strings for Clojure

[Paul Stadig]

I have released a byte vector backed, utf8 string library for Clojure. It
exists because when doing lots of ASCII string processing, Java strings can
be pretty hefty. Using byte arrays to represent strings can be annoying for
various reasons (mutability, bad equality semantics). However, byte vectors
are persistent data structures that store byte values efficiently. Some
interesting points:

* these strings implement the CharSequence interface, so you can use most
every clojure.string function with them, and you can match regular
expressions against them, which is pretty cool.
* in addition to the efficient storage, since they are persistent data
structures you also get structure sharing
* the library includes a "StringWriter" that will write directly to a utf8
string, so you don't even have to go through Java Strings if you don't want
to
* utf8 strings can be seq'ed and are lazily decoded as you traverse them
* also because they are persistent data structures you can use conj and
into with them

I think that's most of the salient features. The README has more details
and examples.


https://github.com/pjstadig/utf8


Cheers,
Paul

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Mimmo Cosenza]

Hi Lee,
you made me cry (almost). 

I've been working in the eighties on Lisp Machine (both Symbolics and Texas 
Instruments) and I still have to see a programming environment comparable to 
the one I was using 30 years ago. At the moment we're still far way from those 
happy days. 

Well written!

My Best

Mimmo
  
On Nov 7, 2013, at 6:32 PM, Lee Spector  wrote:

> 
> I'd like to chime in here from a background that involved a lot of Common 
> Lisping back in the day.
> 
> I have been continually dismayed, as I've moved further from Common Lisp, 
> that debugging facilities that are so basic and ubiquitous and helpful in 
> that world are considered exotic or specialized or necessarily tied to 
> particular IDEs or tool chains in other language ecosystems.
> 
> Even more basic (and useful, in my experience) than things like steppers or 
> the ability to set break points is the ability just to see the values of 
> locals when an error occurs. This is so obviously useful, and so obviously 
> doable (for decades), that I'm really quite stunned that it's so complicated 
> to do in Clojure and tied to a particular toolset if you can do it at all.
> 
> In Common Lisp when you hit an error you're thrown into a break loop REPL in 
> which you can view locals, move up and down the stack, and do lots of other 
> fancier things (re-binding things, restarting...) that are probably useful in 
> some situations, but just being able to see the locals is, in my experience, 
> the really huge win. It doesn't matter what IDE you're using or if you're 
> running it from a command line or whatever -- it's part of the language and 
> easy to access no matter how you write and run your code. And my guess is 
> that every Common Lisper takes advantage of this frequently. Different 
> implementations/environments provide different modes of access to this 
> information (e.g. some are GUI-based, and in emacs you can have interactive 
> access to it using interaction conventions that seemed like a good idea in 
> the 1970s :-), but there's always some way to get the information. 
> 
> By contrast in Clojure this information seems really hard to come by. I saw 
> and was excited by a Ritz video -- and I note the enthusiastic applause from 
> the crowd when it was shown that you could see locals (gasp!) -- but my 
> understanding is that this functionality requires commitment to an 
> Emacs-based tool set with all that that implies (which is a lot, IMHO).
> 
> When I hit an error running my code from "lein run" or from Clooj or from 
> Eclipse/CCW (or I think from any other way that I might run it) I get (or can 
> easily get) a backtrace that shows the function call stack at the time of the 
> error... which is good, but surely (?) the locals are also available when the 
> backtrace is produced and I really also want to see those. The ability to 
> browse and navigate this information dynamically, as in a Common Lisp break 
> loop, is cool but I can understand that something about the Clojure/JVM 
> execution architecture might make that difficult -- maybe that really would 
> have to be tied to a particular IDE? However, if it would just dump all of 
> the values of the locals to standard output, just like it does already with 
> the trace, then I'd be plenty happy since I could dig through that output to 
> find what I need but can't currently get. (Yes, dumping the values of all of 
> the locals might produce a lot of output and yes, one might want to make this 
> an option that could be turned off or on, maybe including options re: limits 
> on how much of sequences to print, etc.)
> 
> I guess the bottom line of this long message (sorry) is that I hope that some 
> of the great tool developers in this community will continue to consider 
> providing things like debugging tools that are as untethered as possible from 
> particular IDEs. My impression is that nrepl (and maybe other projects) are 
> intended to help "untether" things in this way, but it still seems like a lot 
> of people assume that something like access to locals should naturally be 
> tied to a specific IDE. From my perspective that seems like a really 
> unfortunate assumption. I realize that debugging tools are unlikely to become 
> "part of the language" in Clojure as they are in Common Lisp, but I think 
> there's an important middle ground between that and being available only 
> within some specific IDE.
> 
> Thanks,
> 
> -Lee
> 
> 
>> phillip.l...@newcastle.ac.uk (Phillip Lord) writes:
>> 
>>> Ritz does some things, but it doesn't do step through like edebug.
>>> 
>>> I've never found anything as nice as edebug in any language; I guess,
>>> it's the big advantage of running your editor and whatever you are
>>> debugging in the environment.
> 
> -- 
> -- 
> 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 mode

[ANN] Will be giving a Lecture on Clojure to Computer Science Students in Tunisia

[Rafik NACCACHE]

Hi all,

I am particularly excited to announce that I will be presenting Clojure to 
my Former University, the "Faculté des Sciences de Tunis" ! Hope it will 
drain interest from the young engineers there ! It will be scheduled on 
November the 20th !

Regards,

Rafik


-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Andy Fingerhut]

Lee, I am curious whether you would consider it "too tied to a particular
dev environment" if the kind of minimal debugging features you wish for
worked from Leiningen's REPL?  i.e. 'lein repl'

I do not know if Ritz can work in such an environment or not, but I am
guessing it might be easier to get a subset of it working there than from a
REPL started via 'java -cp clojure.jar clojure.main'

Andy


On Thu, Nov 7, 2013 at 9:32 AM, Lee Spector  wrote:

>
> I'd like to chime in here from a background that involved a lot of Common
> Lisping back in the day.
>
> I have been continually dismayed, as I've moved further from Common Lisp,
> that debugging facilities that are so basic and ubiquitous and helpful in
> that world are considered exotic or specialized or necessarily tied to
> particular IDEs or tool chains in other language ecosystems.
>
> Even more basic (and useful, in my experience) than things like steppers
> or the ability to set break points is the ability just to see the values of
> locals when an error occurs. This is so obviously useful, and so obviously
> doable (for decades), that I'm really quite stunned that it's so
> complicated to do in Clojure and tied to a particular toolset if you can do
> it at all.
>
> In Common Lisp when you hit an error you're thrown into a break loop REPL
> in which you can view locals, move up and down the stack, and do lots of
> other fancier things (re-binding things, restarting...) that are probably
> useful in some situations, but just being able to see the locals is, in my
> experience, the really huge win. It doesn't matter what IDE you're using or
> if you're running it from a command line or whatever -- it's part of the
> language and easy to access no matter how you write and run your code. And
> my guess is that every Common Lisper takes advantage of this frequently.
> Different implementations/environments provide different modes of access to
> this information (e.g. some are GUI-based, and in emacs you can have
> interactive access to it using interaction conventions that seemed like a
> good idea in the 1970s :-), but there's always some way to get the
> information.
>
> By contrast in Clojure this information seems really hard to come by. I
> saw and was excited by a Ritz video -- and I note the enthusiastic applause
> from the crowd when it was shown that you could see locals (gasp!) -- but
> my understanding is that this functionality requires commitment to an
> Emacs-based tool set with all that that implies (which is a lot, IMHO).
>
> When I hit an error running my code from "lein run" or from Clooj or from
> Eclipse/CCW (or I think from any other way that I might run it) I get (or
> can easily get) a backtrace that shows the function call stack at the time
> of the error... which is good, but surely (?) the locals are also available
> when the backtrace is produced and I really also want to see those. The
> ability to browse and navigate this information dynamically, as in a Common
> Lisp break loop, is cool but I can understand that something about the
> Clojure/JVM execution architecture might make that difficult -- maybe that
> really would have to be tied to a particular IDE? However, if it would just
> dump all of the values of the locals to standard output, just like it does
> already with the trace, then I'd be plenty happy since I could dig through
> that output to find what I need but can't currently get. (Yes, dumping the
> values of all of the locals might produce a lot of output and yes, one
> might want to make this an option that could be turned off or on, maybe
> including options re: limits on how much of sequences to print, etc.)
>
> I guess the bottom line of this long message (sorry) is that I hope that
> some of the great tool developers in this community will continue to
> consider providing things like debugging tools that are as untethered as
> possible from particular IDEs. My impression is that nrepl (and maybe other
> projects) are intended to help "untether" things in this way, but it still
> seems like a lot of people assume that something like access to locals
> should naturally be tied to a specific IDE. From my perspective that seems
> like a really unfortunate assumption. I realize that debugging tools are
> unlikely to become "part of the language" in Clojure as they are in Common
> Lisp, but I think there's an important middle ground between that and being
> available only within some specific IDE.
>
> Thanks,
>
>  -Lee
>
>
> > phillip.l...@newcastle.ac.uk (Phillip Lord) writes:
> >
> >> Ritz does some things, but it doesn't do step through like edebug.
> >>
> >> I've never found anything as nice as edebug in any language; I guess,
> >> it's the big advantage of running your editor and whatever you are
> >> debugging in the environment.
>
> --
> --
> 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

Re: ANN: byte vector backed, utf8 strings for Clojure

[Andy Fingerhut]

Very cool.

I read through your README (thank you for that), and did not notice an
answer to the question of: does seq on a utf8 string return a sequence of
Unicode code points?  Java UTF-16 code points (with pairs of them for
characters outside the BMP)?  Something else?  It would be great to have
the answer in the README.

One idea I had for such a thing was: if any operation ever traversed part
of such a variable-bytes-per-char string for any reason (e.g. counting its
length in Unicode code points, or indexing), maintain some kind of data
structure mapping a few selected index values to their byte offset within
the byte array.  For example, a string containing 100 Unicode code points
might have byte offsets for the start of the UTF-8 encodings of every 32
code points, or 64.  This limits any sequential scanning to be from the
most recent cached byte offset.  Not a trivial amount of implementation
work, I know, but would be cool.



On Thu, Nov 7, 2013 at 11:41 AM, Paul Stadig  wrote:

> I have released a byte vector backed, utf8 string library for Clojure. It
> exists because when doing lots of ASCII string processing, Java strings can
> be pretty hefty. Using byte arrays to represent strings can be annoying for
> various reasons (mutability, bad equality semantics). However, byte vectors
> are persistent data structures that store byte values efficiently. Some
> interesting points:
>
> * these strings implement the CharSequence interface, so you can use most
> every clojure.string function with them, and you can match regular
> expressions against them, which is pretty cool.
> * in addition to the efficient storage, since they are persistent data
> structures you also get structure sharing
> * the library includes a "StringWriter" that will write directly to a utf8
> string, so you don't even have to go through Java Strings if you don't want
> to
> * utf8 strings can be seq'ed and are lazily decoded as you traverse them
> * also because they are persistent data structures you can use conj and
> into with them
>
> I think that's most of the salient features. The README has more details
> and examples.
>
>
> https://github.com/pjstadig/utf8
>
>
> Cheers,
> Paul
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[ANN] Clojure 1.6.0-alpha2 release

[Alex Miller]

Clojure 1.6.0-alpha2 is now available. 
 
Try it via 
- Download: 
http://central.maven.org/maven2/org/clojure/clojure/1.6.0-alpha2/
- Leiningen: [org.clojure/clojure "1.6.0-alpha2"]

Clojure 1.6.0-alpha2 has the following changes from 1.6.0-alpha1:

1) Reverted: CLJ-1252 (keywords starting with a digit no longer accepted by 
the reader) 

2) Added: CLJ-1285 - fix collection bug that happens after modifying a 
transient data structure - thanks to Zach Tellman, Michał Marczyk, 
Christophe Grand, and others for their work in finding and fixing in this.

3) Added: changelog for 1.6.0.
https://github.com/clojure/clojure/blob/master/changes.md

Please give it a whirl!

Alex Miller

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Clojure 1.6.0-alpha2 release

[Michael Klishin]

2013/11/8 Alex Miller 

> 3) Added: changelog for 1.6.0.
> https://github.com/clojure/clojure/blob/master/changes.md
>
>
This is *much* more detailed and human-oriented than any other change log
Clojure/core has ever produced. And it's posted shortly after the release.

Good job!
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Alex Miller]

I believe the locals are actually *not* available because they are 
proactively cleared to help GC.  

Setting the *compiler-options* var with :disable-locals-clearing can turn 
that off. Which is probably what you often want in dev, but is not the 
default.  You can also set this via command line with 
-Dclojure.compile.disable-locals-clearing=true 


On Thursday, November 7, 2013 11:32:29 AM UTC-6, Lee wrote:
>
>
> I'd like to chime in here from a background that involved a lot of Common 
> Lisping back in the day. 
>
> I have been continually dismayed, as I've moved further from Common Lisp, 
> that debugging facilities that are so basic and ubiquitous and helpful in 
> that world are considered exotic or specialized or necessarily tied to 
> particular IDEs or tool chains in other language ecosystems. 
>
> Even more basic (and useful, in my experience) than things like steppers 
> or the ability to set break points is the ability just to see the values of 
> locals when an error occurs. This is so obviously useful, and so obviously 
> doable (for decades), that I'm really quite stunned that it's so 
> complicated to do in Clojure and tied to a particular toolset if you can do 
> it at all. 
>
> In Common Lisp when you hit an error you're thrown into a break loop REPL 
> in which you can view locals, move up and down the stack, and do lots of 
> other fancier things (re-binding things, restarting...) that are probably 
> useful in some situations, but just being able to see the locals is, in my 
> experience, the really huge win. It doesn't matter what IDE you're using or 
> if you're running it from a command line or whatever -- it's part of the 
> language and easy to access no matter how you write and run your code. And 
> my guess is that every Common Lisper takes advantage of this frequently. 
> Different implementations/environments provide different modes of access to 
> this information (e.g. some are GUI-based, and in emacs you can have 
> interactive access to it using interaction conventions that seemed like a 
> good idea in the 1970s :-), but there's always some way to get the 
> information. 
>
> By contrast in Clojure this information seems really hard to come by. I 
> saw and was excited by a Ritz video -- and I note the enthusiastic applause 
> from the crowd when it was shown that you could see locals (gasp!) -- but 
> my understanding is that this functionality requires commitment to an 
> Emacs-based tool set with all that that implies (which is a lot, IMHO). 
>
> When I hit an error running my code from "lein run" or from Clooj or from 
> Eclipse/CCW (or I think from any other way that I might run it) I get (or 
> can easily get) a backtrace that shows the function call stack at the time 
> of the error... which is good, but surely (?) the locals are also available 
> when the backtrace is produced and I really also want to see those. The 
> ability to browse and navigate this information dynamically, as in a Common 
> Lisp break loop, is cool but I can understand that something about the 
> Clojure/JVM execution architecture might make that difficult -- maybe that 
> really would have to be tied to a particular IDE? However, if it would just 
> dump all of the values of the locals to standard output, just like it does 
> already with the trace, then I'd be plenty happy since I could dig through 
> that output to find what I need but can't currently get. (Yes, dumping the 
> values of all of the locals might produce a lot of output and yes, one 
> might want to make this an option that could be turned off or on, maybe 
> including options re: limits on how much of sequences to print, etc.) 
>
> I guess the bottom line of this long message (sorry) is that I hope that 
> some of the great tool developers in this community will continue to 
> consider providing things like debugging tools that are as untethered as 
> possible from particular IDEs. My impression is that nrepl (and maybe other 
> projects) are intended to help "untether" things in this way, but it still 
> seems like a lot of people assume that something like access to locals 
> should naturally be tied to a specific IDE. From my perspective that seems 
> like a really unfortunate assumption. I realize that debugging tools are 
> unlikely to become "part of the language" in Clojure as they are in Common 
> Lisp, but I think there's an important middle ground between that and being 
> available only within some specific IDE. 
>
> Thanks, 
>
>  -Lee 
>
>
> > philli...@newcastle.ac.uk  (Phillip Lord) writes: 
> > 
> >> Ritz does some things, but it doesn't do step through like edebug. 
> >> 
> >> I've never found anything as nice as edebug in any language; I guess, 
> >> it's the big advantage of running your editor and whatever you are 
> >> debugging in the environment. 
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@goog

Re: ANN: byte vector backed, utf8 strings for Clojure

[Paul Stadig]

On Thursday, November 7, 2013 2:57:03 PM UTC-5, Andy Fingerhut wrote:
>
> Very cool.
>
> I read through your README (thank you for that), and did not notice an 
> answer to the question of: does seq on a utf8 string return a sequence of 
> Unicode code points?  Java UTF-16 code points (with pairs of them for 
> characters outside the BMP)?  Something else?  It would be great to have 
> the answer in the README.
>

The utf8 strings implement the CharSequence interface, and when seq'ed 
produce a sequence of characters. In both those cases "characters" refers 
to Java UTF-16 character values, which means anything outside the BMP would 
be represented as surrogate pairs. Maybe I was assuming too much using 
those terms? I can clarify the README.

One idea I had for such a thing was: if any operation ever traversed part 
> of such a variable-bytes-per-char string for any reason (e.g. counting its 
> length in Unicode code points, or indexing), maintain some kind of data 
> structure mapping a few selected index values to their byte offset within 
> the byte array.  For example, a string containing 100 Unicode code points 
> might have byte offsets for the start of the UTF-8 encodings of every 32 
> code points, or 64.  This limits any sequential scanning to be from the 
> most recent cached byte offset.  Not a trivial amount of implementation 
> work, I know, but would be cool.
>

Even if you used full 32-bit integers to represent code points (even though 
code points are only 21-bit values...*sigh*) you still can't count 
"characters" in constant time, unless you define characters to mean code 
points (like you say above), because code points can represent combining 
marks which together represent a single character. You could 
create/maintain some kind of index for an encoded sequence of code points, 
but there's always a space/time tradeoff, and ultimately it will depend on 
your use case. If you mostly access strings sequentially, then utf8 isn't 
so bad. You can index into the middle of the stream find your way to the 
beginning of the next code point, and skip through code points from there. 
Not to say there's no merit to your idea. I've had the same myself. It 
would be nice to be able to jump to the nth encoded code point in a utf8 
string.

I have a book called "Unicode Demystified" and recommend it. It talks about 
what terms people use (like character vs. code point vs. glyph). It talks 
about some of the history of Unicode, and some practical tips like data 
structures that can be used to represent code points in memory for 
different types of tasks.

Anyway, Unicode is much for complex than any of us could hope, but I 
digress.


Paul

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Lee Spector]

Andy,

I do think that if a debugging feature has to be limited to a particular 
environment then Leiningen would be preferable to any other, since it's so 
simple to install and use (and maybe most people have it anyway?) that people 
who use other environments could, without too much trouble, do a new run from 
Leiningen when they know they need to do some debugging. Not as good as having 
it work everywhere with whatever you're already using, of course, but certainly 
better than (for example) requiring that you figure out how to install and use 
an Emacs-based environment just to figure out what values your locals have when 
you crash.

Would what you have in mind work from "lein run" as well as "lein repl"? FWIW I 
(and my students) do a lot via "lein run".

 -Lee

On Nov 7, 2013, at 2:47 PM, Andy Fingerhut wrote:

> Lee, I am curious whether you would consider it "too tied to a particular dev 
> environment" if the kind of minimal debugging features you wish for worked 
> from Leiningen's REPL?  i.e. 'lein repl'
> 
> I do not know if Ritz can work in such an environment or not, but I am 
> guessing it might be easier to get a subset of it working there than from a 
> REPL started via 'java -cp clojure.jar clojure.main'
> 
> Andy

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Lee Spector]

What would I need to do to get it to not only retain locals but also show them 
to me when I hit an error?

 -Lee

On Nov 7, 2013, at 4:22 PM, Alex Miller wrote:

> I believe the locals are actually *not* available because they are 
> proactively cleared to help GC.  
> 
> Setting the *compiler-options* var with :disable-locals-clearing can turn 
> that off. Which is probably what you often want in dev, but is not the 
> default.  You can also set this via command line with 
> -Dclojure.compile.disable-locals-clearing=true 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Clojure 1.6.0-alpha2 release

[Alex Miller]

This is exactly the same change log that has been posted for every release? 
I just added the 1.6 stuff. 

Hoping to be a little more diligent in keeping it up to date as we go.

Alex


On Thursday, November 7, 2013 3:16:32 PM UTC-6, Michael Klishin wrote:
>
> 2013/11/8 Alex Miller >
>
>> 3) Added: changelog for 1.6.0.
>> https://github.com/clojure/clojure/blob/master/changes.md
>>
>>
> This is *much* more detailed and human-oriented than any other change log
> Clojure/core has ever produced. And it's posted shortly after the release.
>
> Good job!
> -- 
> MK
>
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
>  

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ANN: ClojureScript 0.0-2014 - source maps, incremental compilation, and internal changes

[Geraldo Lopes de Souza]

David,

Using relative source maps is not updating .cljs equivalents when the original 
source is updated. If you delete it'll be created. If you update the .cljs it 
remains stalled.

Using lein-cljsbuild "1.0.0-alpha2".

Regards,

Geraldo

On Wednesday, November 6, 2013 6:09:09 PM UTC-2, David Nolen wrote:
> ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> 
> README and source code: https://github.com/clojure/clojurescript
> 
> 
> 
> New release version: 0.0-2014
> 
> 
> Leiningen dependency information:
> 
> 
>     [org.clojure/clojurescript "0.0-2014"]
> 
> 
> There are a number of significant enhancements in this
> 
> release. We finally have relative source maps! This should be big
> for people integrating ClojureScript with existing web
> based workflows.
> 
> 
> Under the hood Chas Emerick has improved how the analyzer works making
> 
> it thread safe. This make the compiler considerably more robust and
> eliminates some race conditions in the browser REPL support.
> 
> 
> Incremental compilation is enhanced both with and without source
> 
> maps. In particular we now tag ClojureScript compiled JavaScript files
> with the version of the compiler used - this should make transitioning
> to a new version of the compiler considerably less frustrating - stale
> 
> files will get compiled.
> 
> 
> For those people using the compiler internals directly you will likely
> encounter breakage. If anyone feels inclined to outline a more stable
> interface to internals please get involved in leading an incremental
> 
> process towards a stable and flexible API for tool builders.
> 
> 
> Enhancements:
> * relative source map paths, all original sources will be copied to
>   :ouput-dir this should make integrating with web workflow much simpler.
> 
> * runtime obtainable compiler version number, *clojurescript-version* now
>   available at runtime as a string
> 
> 
> Bug fixes:
> * CLJS-643: make the ClojureScript compiler (more) idempotent
> 
> * CLJS-662: CLJS files compiled from JARs get lost from source map
> * CLJS-661: (try ... (catch :default e ...) ...)
> * CLJS-627: Add warnings on function arity problems
> * CLJS-654: Quit repljs on ^D, don't loop on nil
> 
> * CLJS-659: tag compiled files with compiler version
> * CLJS-642: deftype/record should not emit goog.provide
> * CLJS-648: persistent assoc/conj on a transient-created collision node
> * CLJS-631: Use ana/namespaces for shadowing vars
> 
> * CLJS-641: js* overflow for large inputs
> * CLJS-645: parse-ns needs to include 'constants-table as a dep
> * CLJS-646: single segment namespaces and reify don't work
> * CLJS-521: pass along entire repl environment when loading dependencies

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Rudi Engelbrecht]

+1

Rudi Engelbrecht

Mobile: +61 (0) 455 500 369
Voice: +61 (0) 2 8091 5554
Voice: +27 (0) 11 083 7774
Email: r...@engelbrecht.me

> On 8 Nov 2013, at 8:29, Lee Spector  wrote:
> 
> 
> Andy,
> 
> I do think that if a debugging feature has to be limited to a particular 
> environment then Leiningen would be preferable to any other, since it's so 
> simple to install and use (and maybe most people have it anyway?) that people 
> who use other environments could, without too much trouble, do a new run from 
> Leiningen when they know they need to do some debugging. Not as good as 
> having it work everywhere with whatever you're already using, of course, but 
> certainly better than (for example) requiring that you figure out how to 
> install and use an Emacs-based environment just to figure out what values 
> your locals have when you crash.
> 
> Would what you have in mind work from "lein run" as well as "lein repl"? FWIW 
> I (and my students) do a lot via "lein run".
> 
> -Lee
> 
>> On Nov 7, 2013, at 2:47 PM, Andy Fingerhut wrote:
>> 
>> Lee, I am curious whether you would consider it "too tied to a particular 
>> dev environment" if the kind of minimal debugging features you wish for 
>> worked from Leiningen's REPL?  i.e. 'lein repl'
>> 
>> I do not know if Ritz can work in such an environment or not, but I am 
>> guessing it might be easier to get a subset of it working there than from a 
>> REPL started via 'java -cp clojure.jar clojure.main'
>> 
>> Andy
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Does Pedestal have a future in the long run

[Marko Kocić]

Hi all,

I'd like to hear opinions about Pedestal from the people that have been 
playing more with it. Right now I started looking at it, and like some of 
the things, but not sure should I invest more time learning it. While I do 
like some concepts, I'm not sure is it going to became abandonware like 
Clojurescript One (does anyone reemembers it anymore).

So far, after initial splash, I haven't seen large community interest in 
it. The number of aproachable getting started guides and hands on tutorials 
is missing. That might change over time, but I'm afraid that next year this 
time we'll get another Clojurescript one page application framework not 
much related with Pedestal. How serious Cognitect/Relevance is about it?

Best regards,
Marko

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Alex Miller]

When you say "hit an error", I'm assuming you mean "clojure throws an 
exception" and not "hit a breakpoint in a debugger" or something else. 

I don't think there is one place where we could generically attach locals 
info to a thrown exception. The JVM debugging interface (JVMTI - 
http://docs.oracle.com/javase/7/docs/technotes/guides/jvmti/index.html) can 
do an awful lot of things (including arbitrary class bytecode 
transformation) so I would guess it's possible to build a java agent that 
could do this (or to modify the Compiler to inject the right code at 
compile time). Sounds like a fun project, but probably non-trivial. 

On Thursday, November 7, 2013 3:34:23 PM UTC-6, Lee wrote:
>
>
> What would I need to do to get it to not only retain locals but also show 
> them to me when I hit an error? 
>
>  -Lee 
>
> On Nov 7, 2013, at 4:22 PM, Alex Miller wrote: 
>
> > I believe the locals are actually *not* available because they are 
> proactively cleared to help GC.   
> > 
> > Setting the *compiler-options* var with :disable-locals-clearing can 
> turn that off. Which is probably what you often want in dev, but is not the 
> default.  You can also set this via command line with 
> -Dclojure.compile.disable-locals-clearing=true 
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ANN: byte vector backed, utf8 strings for Clojure

[Jozef Wagner]

Hi,

Thank for releasing this library. Some ideas for next features:
* support for writing an underlaying byte array into the OutputStream
* constructing utf8 string directly from InputStream, byte array or byte 
buffer
* less lazyness and more reducers, current version is very very slow
* cache the count
* equiv should check unfinished surrogates
* transient utf8-writer

Best,
JW

On Thursday, November 7, 2013 8:41:48 PM UTC+1, Paul Stadig wrote:
>
> I have released a byte vector backed, utf8 string library for Clojure. It 
> exists because when doing lots of ASCII string processing, Java strings can 
> be pretty hefty. Using byte arrays to represent strings can be annoying for 
> various reasons (mutability, bad equality semantics). However, byte vectors 
> are persistent data structures that store byte values efficiently. Some 
> interesting points:
>
> * these strings implement the CharSequence interface, so you can use most 
> every clojure.string function with them, and you can match regular 
> expressions against them, which is pretty cool.
> * in addition to the efficient storage, since they are persistent data 
> structures you also get structure sharing
> * the library includes a "StringWriter" that will write directly to a utf8 
> string, so you don't even have to go through Java Strings if you don't want 
> to
> * utf8 strings can be seq'ed and are lazily decoded as you traverse them
> * also because they are persistent data structures you can use conj and 
> into with them
>
> I think that's most of the salient features. The README has more details 
> and examples.
>
>
> https://github.com/pjstadig/utf8
>
>
> Cheers,
> Paul
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Andy Fingerhut]

I don't know yet, since what I have in mind at the moment is based on vague
pattern matching of words rather than on knowledge of how Ritz works. :-)
My basic idea was simply that the Ritz nrepl stuff only works in Emacs now,
but it does work across an nREPL connection between a client and the JVM
process containing the code you want to debug.  If there is a subset of
Ritz's debugging features that could be switched to work over a
terminal/console connection like what you get with 'lein repl', then that
might be a quicker path to the desired goal than lots of modifications to
Clojure itself.

CC'ing Hugo Duncan in case he has time and interest in adding his
much-more-educated-than-mine comments (Hugo, please don't take this as a
request to do any work you don't want to -- I'm mostly hoping for an
off-the-top-of-your-head answer like "debug features X and Y wouldn't be
hard to do that way, but the rest would be much harder").

Andy


On Thu, Nov 7, 2013 at 1:29 PM, Lee Spector  wrote:

>
> Andy,
>
> I do think that if a debugging feature has to be limited to a particular
> environment then Leiningen would be preferable to any other, since it's so
> simple to install and use (and maybe most people have it anyway?) that
> people who use other environments could, without too much trouble, do a new
> run from Leiningen when they know they need to do some debugging. Not as
> good as having it work everywhere with whatever you're already using, of
> course, but certainly better than (for example) requiring that you figure
> out how to install and use an Emacs-based environment just to figure out
> what values your locals have when you crash.
>
> Would what you have in mind work from "lein run" as well as "lein repl"?
> FWIW I (and my students) do a lot via "lein run".
>
>  -Lee
>
> On Nov 7, 2013, at 2:47 PM, Andy Fingerhut wrote:
>
> > Lee, I am curious whether you would consider it "too tied to a
> particular dev environment" if the kind of minimal debugging features you
> wish for worked from Leiningen's REPL?  i.e. 'lein repl'
> >
> > I do not know if Ritz can work in such an environment or not, but I am
> guessing it might be easier to get a subset of it working there than from a
> REPL started via 'java -cp clojure.jar clojure.main'
> >
> > Andy
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Clojure 1.6.0-alpha2 release

[Howard M. Lewis Ship]

Any idea how I can push that patch I submitted (toString for functions) 
along? It's in purgatory now.

On Thursday, 7 November 2013 13:04:19 UTC-8, Alex Miller wrote:
>
> Clojure 1.6.0-alpha2 is now available. 
>  
> Try it via 
> - Download: 
> http://central.maven.org/maven2/org/clojure/clojure/1.6.0-alpha2/
> - Leiningen: [org.clojure/clojure "1.6.0-alpha2"]
>
> Clojure 1.6.0-alpha2 has the following changes from 1.6.0-alpha1:
>
> 1) Reverted: CLJ-1252 (keywords starting with a digit no longer accepted 
> by the reader) 
>
> 2) Added: CLJ-1285 - fix collection bug that happens after modifying a 
> transient data structure - thanks to Zach Tellman, Michał Marczyk, 
> Christophe Grand, and others for their work in finding and fixing in this.
>
> 3) Added: changelog for 1.6.0.
> https://github.com/clojure/clojure/blob/master/changes.md
>
> Please give it a whirl!
>
> Alex Miller
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Does Pedestal have a future in the long run

[Andreas Liljeqvist]

I sure hope it does.

Not a master of it yet, but the concept seems very interesting.
I know that there is a guy writing a book about it.

Many of the other somewhat related technologies like Django are a
completely different cognitive model.
More tutorials would be great, also they should stress the importance of
understanding the model.
Its kind of glossed over in the tutorial.


On Thu, Nov 7, 2013 at 11:30 PM, Marko Kocić  wrote:

> Hi all,
>
> I'd like to hear opinions about Pedestal from the people that have been
> playing more with it. Right now I started looking at it, and like some of
> the things, but not sure should I invest more time learning it. While I do
> like some concepts, I'm not sure is it going to became abandonware like
> Clojurescript One (does anyone reemembers it anymore).
>
> So far, after initial splash, I haven't seen large community interest in
> it. The number of aproachable getting started guides and hands on tutorials
> is missing. That might change over time, but I'm afraid that next year this
> time we'll get another Clojurescript one page application framework not
> much related with Pedestal. How serious Cognitect/Relevance is about it?
>
> Best regards,
> Marko
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Jig

[Timothy Washington]

Umm I can't think of parallel dependency tree walking algos, off the top of
my head. Sorry :/

But niiice. Yeah, we're definitely thinking along the same lines. But
you're way ahead of me. Now just to be able to isolate that browser repl on
a per project basis.


Sweet

Tim Washington
Interruptsoftware.ca  /
Bkeeping.com



On Wed, Nov 6, 2013 at 8:46 PM, Malcolm Sparks  wrote:

> Hi Tim,
>
> It's interesting you're thinking about browser-connected repls. Today I
> added clojurescript support to Jig, it's pushed to master but I haven't
> documented the config options yet, but below is an example. Nothing fancy
> like crossovers yet, it's basically a thin wrapper over ClojureScript's
> compiler, the config options map directly to the options given to the
> compiler.
>
>   :cljs-builder
>   {:jig/component jig.cljs/Builder
>:jig/project "../my-proj/project.clj"
>:source-path "../my-proj/src-cljs"
>:output-dir "../my-proj/target/js"
>:output-to "../my-proj/target/js/main.js"
>:source-map "../my-proj/target/js/main.js.map"
>:optimizations :simple
>:pretty-print true
> ;;   :clean-build true
>}
>
> Another built-in component can figure out, given the dependencies, what
> files to serve and on which server to serve it from.
>
>   :cljs-server
>   {:jig/component jig.cljs/FileServer
>:jig/dependencies [:cljs-builder :web]
>:jig.web/context "/js"
>}
>
> which depends on some Ring or Pedestal routing and Jetty or other
> webserver, but you're likely to have that configured already :-
>
>
>   :server
>   {:jig/component jig.web.server/Component
>:io.pedestal.service.http/port 8000
>:io.pedestal.service.http/type :jetty
>}
>
>   :web
>
>   {:jig/component jig.web.app/Component
>:jig/dependencies [:server]
>:jig/scheme :http
>:jig/hostname "localhost"
>:jig.web/server :server
>}
>
> That's it really. I think Jig makes an ideal platform for building and
> serving clojurescript, in comparison to Leiningen plugins. Firstly, there's
> no JVM start-up cost, the point of Jig is to keep the JVM running all the
> time, so there's no need for the once/auto service that lein-cljsbuild
> offers. Secondly, serving the resulting Javascript files is straight
> forward, and built in, so no 'lein ring server' requirement either.. With
> Leiningen, you either have to build routes to the javascript into your own
> app, or run lein ring server, but then Leiningen doesn't make it easy to
> run multiple services concurrently. Thirdly, there's no file-system
> polling, and services that depend on the clojurescript compilation can be
> started as soon as the compilation is complete.
>
> One thing that lein-cljsbuild does really well is multiple build configs.
> I've decided to use a single build configuration, to keep implementation
> easier and a direct mapping to the clojurescript compiler, but of course
> you can add different builds by just adding (differently configured)
> components to the Jig config. This would benefit from being able to
> initialize and start components in parallel, where possible. Unlike
> cljsbuild, Jig components are started serially, in reverse dependency
> order. Does anyone know of existing algorithms that can walk a dependency
> tree in parallel?
>
> Feel free to take Jig in different directions though, I'm just letting you
> know my current thoughts. The single REPL to multiple projects idea might
> have to be rethought - it seems the prevailing wind is in the direction of
> multiple REPL connections per editor/IDE.
>
>
> On Thursday, 7 November 2013 01:09:53 UTC, frye wrote:
>
>> Too right.
>>
>> Yes, wrt the multi-project / classpath thing, running isolated test for a
>> particular project is only one aspect. I also have an eye to running a i)
>> browser-connected repl and ii) debugger for a particular project. So those
>> things, along with iii) running tests, make very high, the attractiveness
>> of having that isolation.
>>
>> I'll try to put those in github issues. And also pick at the problem
>> myself when I get some cycles. I think it would add a powerful feature to
>> the tool. Anyways... :)
>>
>>
>> Tim Washington
>> Interruptsoftware.ca  / 
>> Bkeeping.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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https:/

Re: [ANN] Clojure 1.6.0-alpha2 release

[Alex Miller]

Any ticket with a fix version of
1.6is
still a candidate for inclusion, and I expect many of those to make it
in.  Everything else (including the one you mention) will wait until the
next release to be considered.

The hashing work that has been under discussion on the mailing lists is
also a candidate and we will focus on that after the Conj.

After 1.6, we will reconsider both features and tickets to look at what
goes into the next release. Votes in JIRA are the best way to indicate
community interest in a ticket.



On Thu, Nov 7, 2013 at 5:05 PM, Howard M. Lewis Ship wrote:

> Any idea how I can push that patch I submitted (toString for functions)
> along? It's in purgatory now.
>
>
> On Thursday, 7 November 2013 13:04:19 UTC-8, Alex Miller wrote:
>>
>> Clojure 1.6.0-alpha2 is now available.
>>
>> Try it via
>> - Download: http://central.maven.org/maven2/org/clojure/clojure/1.
>> 6.0-alpha2/
>> - Leiningen: [org.clojure/clojure "1.6.0-alpha2"]
>>
>> Clojure 1.6.0-alpha2 has the following changes from 1.6.0-alpha1:
>>
>> 1) Reverted: CLJ-1252 (keywords starting with a digit no longer accepted
>> by the reader)
>>
>> 2) Added: CLJ-1285 - fix collection bug that happens after modifying a
>> transient data structure - thanks to Zach Tellman, Michał Marczyk,
>> Christophe Grand, and others for their work in finding and fixing in this.
>>
>> 3) Added: changelog for 1.6.0.
>> https://github.com/clojure/clojure/blob/master/changes.md
>>
>> Please give it a whirl!
>>
>> Alex Miller
>>
>>  --
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/SRrlZ8pGWeI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Lee Spector]

On Nov 7, 2013, at 5:48 PM, Alex Miller wrote:

> When you say "hit an error", I'm assuming you mean "clojure throws an 
> exception" and not "hit a breakpoint in a debugger" or something else. 

Yes -- I mean "clojure throws an exception."

> 
> I don't think there is one place where we could generically attach locals 
> info to a thrown exception. The JVM debugging interface (JVMTI - 
> http://docs.oracle.com/javase/7/docs/technotes/guides/jvmti/index.html) can 
> do an awful lot of things (including arbitrary class bytecode transformation) 
> so I would guess it's possible to build a java agent that could do this (or 
> to modify the Compiler to inject the right code at compile time). Sounds like 
> a fun project, but probably non-trivial. 

Too bad... unless someone wants to have that fun and then share it with the 
rest of us :-). It still strikes me as really odd that such basic and clearly 
desirable functionality, available forever in other environments, should be so 
hard to come by.

 -Lee

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: newbie question: how to include external libraries from Leiningen REPL

[Sean Corfield]

On Thu, Nov 7, 2013 at 5:18 AM, Starry SHI  wrote:
> Hi, I am new to clojure and I find lein REPL very convenient to use. But I
> have one question: in REPL, how to include functions defined in other
> libraries and call them in my clojure code?

As Marshall indicated, you need to edit your project.clj file - which
in turn means you need to have such a file, which you create with:
lein new myproject (or whatever you want to call it). Leiningen will
create a folder called myproject containing a bunch of stuff including
project.clj. If you run `lein repl` inside the myproject folder, it
will have access to whatever libraries you've added to project.clj.

Example:

> lein new math
Generating a project called math based on the 'default' template.
To see other templates (app, lein plugin, etc), try `lein help new`.
> cd math
> cat project.clj
(defproject math "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME";
  :license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [[org.clojure/clojure "1.5.1"]])

See :dependencies? That's where you'll add new libraries. You asked
about clojure.contrib.math but that is old and no longer maintained,
so for contrib libraries, consult this page:

http://dev.clojure.org/display/community/Where+Did+Clojure.Contrib+Go

(for other non-core/non-contrib libraries, you would search
http://clojars.org as Marshall indicated)

You'll see:

* clojure.contrib.math
  * Migrated to clojure.math.numeric-tower - lead Mark Engelberg.
  * Status: latest build status, latest release on Maven, report bugs.

And if you go to https://github.com/clojure/math.numeric-tower/ (which
is where clojure.math.numeric-tower links to) you'll see:

Leiningen dependency information:

[org.clojure/math.numeric-tower "0.0.2"]

So we'll edit project.clj to include that... and get:

> cat project.clj
(defproject math "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME";
  :license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [[org.clojure/clojure "1.5.1"]
 [org.clojure/math.numeric-tower "0.0.2"]])

Be careful about the brackets!

Now we'll start a repl:

> lein repl
...
user=> (require '[clojure.math.numeric-tower :as math])
nil
user=> (math/sqrt 1234)
35.12833614050059
user=>

Hope that helps?
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Does Pedestal have a future in the long run

[Marcus Blankenship]

It seems like Congitect is heavily invested in it’s future, and committed to 
moving it forward.  I suspect it will change significantly as adoption 
increases, but that will probably be a good thing.

Clojure is still so new that it’s hard to know if there will be “one web 
framework to rule them all”, IMHO.

I suggest investing yourself into it.  It can’t hurt, and will make you a 
better cl/cljs dev if nothing else.


On Nov 7, 2013, at 3:12 PM, Andreas Liljeqvist  wrote:

> I sure hope it does.
> 
> Not a master of it yet, but the concept seems very interesting.
> I know that there is a guy writing a book about it.
> 
> Many of the other somewhat related technologies like Django are a completely 
> different cognitive model.
> More tutorials would be great, also they should stress the importance of 
> understanding the model.
> Its kind of glossed over in the tutorial.
> 
> 
> On Thu, Nov 7, 2013 at 11:30 PM, Marko Kocić  wrote:
> Hi all,
> 
> I'd like to hear opinions about Pedestal from the people that have been 
> playing more with it. Right now I started looking at it, and like some of the 
> things, but not sure should I invest more time learning it. While I do like 
> some concepts, I'm not sure is it going to became abandonware like 
> Clojurescript One (does anyone reemembers it anymore).
> 
> So far, after initial splash, I haven't seen large community interest in it. 
> The number of aproachable getting started guides and hands on tutorials is 
> missing. That might change over time, but I'm afraid that next year this time 
> we'll get another Clojurescript one page application framework not much 
> related with Pedestal. How serious Cognitect/Relevance is about it?
> 
> Best regards,
> Marko
> 
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

marcus blankenship
\\\ Partner, Problem Solver, Linear Thinker
\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[intronic]

+1 
well said, Lee.


>
> > philli...@newcastle.ac.uk  (Phillip Lord) writes: 
> > 
> >> Ritz does some things, but it doesn't do step through like edebug. 
> >> 
> >> I've never found anything as nice as edebug in any language; I guess, 
> >> it's the big advantage of running your editor and whatever you are 
> >> debugging in the environment. 
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[intronic]

Why would a break function in clojure  the language not be considered,  
a-la common-lisp?


On Friday, 8 November 2013 09:31:55 UTC+10, Lee wrote:
>
>
> On Nov 7, 2013, at 5:48 PM, Alex Miller wrote: 
>
> > When you say "hit an error", I'm assuming you mean "clojure throws an 
> exception" and not "hit a breakpoint in a debugger" or something else. 
>
> Yes -- I mean "clojure throws an exception." 
>
> > 
> > I don't think there is one place where we could generically attach 
> locals info to a thrown exception. The JVM debugging interface (JVMTI - 
> http://docs.oracle.com/javase/7/docs/technotes/guides/jvmti/index.html) 
> can do an awful lot of things (including arbitrary class bytecode 
> transformation) so I would guess it's possible to build a java agent that 
> could do this (or to modify the Compiler to inject the right code at 
> compile time). Sounds like a fun project, but probably non-trivial. 
>
> Too bad... unless someone wants to have that fun and then share it with 
> the rest of us :-). It still strikes me as really odd that such basic and 
> clearly desirable functionality, available forever in other environments, 
> should be so hard to come by. 
>
>  -Lee

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Does Pedestal have a future in the long run

[Ryan Neufeld]

Speaking as a core Pedestal team member and engineer at Cognitect I can say 
we are *very* serious about continuing to grow and support Pedestal. It may 
be quiet, but we're using the entirety of Pedestal with a number of client 
and are fervently preparing a number of new features and improvements we 
plan to announce at the Conj next week. Further, we've even begun selling 
commercial support that includes Pedestal[1].

ClojureScript One was a huge influence on pedestal-app, but you're 
completely right that we've abandoned it and should probably wind things 
down there.

Are there any other questions I can field while I'm here?

-Ryan

[1]: http://cognitect.com/Cognitect-Support-Services.pdf

On Thursday, November 7, 2013 5:30:59 PM UTC-5, Marko Kocić wrote:
>
> Hi all,
>
> I'd like to hear opinions about Pedestal from the people that have been 
> playing more with it. Right now I started looking at it, and like some of 
> the things, but not sure should I invest more time learning it. While I do 
> like some concepts, I'm not sure is it going to became abandonware like 
> Clojurescript One (does anyone reemembers it anymore).
>
> So far, after initial splash, I haven't seen large community interest in 
> it. The number of aproachable getting started guides and hands on tutorials 
> is missing. That might change over time, but I'm afraid that next year this 
> time we'll get another Clojurescript one page application framework not 
> much related with Pedestal. How serious Cognitect/Relevance is about it?
>
> Best regards,
> Marko
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Jig

[Cedric Greevey]

If you are just visiting every node as a tree, and you have core.async,
then there's

(let [c (chan)]
  (go
(doseq [n (tree-seq ... (depends on tree implementation) ...)]
  (>! c n)))
  (dotimes [_ (.availableProcessors (Runtime/getRuntime))]
(go
  (loop []
(when-let [n (wrote:

> Umm I can't think of parallel dependency tree walking algos, off the top
> of my head. Sorry :/
>
> But niiice. Yeah, we're definitely thinking along the same lines. But
> you're way ahead of me. Now just to be able to isolate that browser repl on
> a per project basis.
>
>
> Sweet
>
> Tim Washington
> Interruptsoftware.ca  / 
> Bkeeping.com
>
>
>
> On Wed, Nov 6, 2013 at 8:46 PM, Malcolm Sparks  wrote:
>
>> Hi Tim,
>>
>> It's interesting you're thinking about browser-connected repls. Today I
>> added clojurescript support to Jig, it's pushed to master but I haven't
>> documented the config options yet, but below is an example. Nothing fancy
>> like crossovers yet, it's basically a thin wrapper over ClojureScript's
>> compiler, the config options map directly to the options given to the
>> compiler.
>>
>>   :cljs-builder
>>   {:jig/component jig.cljs/Builder
>>:jig/project "../my-proj/project.clj"
>>:source-path "../my-proj/src-cljs"
>>:output-dir "../my-proj/target/js"
>>:output-to "../my-proj/target/js/main.js"
>>:source-map "../my-proj/target/js/main.js.map"
>>:optimizations :simple
>>:pretty-print true
>> ;;   :clean-build true
>>}
>>
>> Another built-in component can figure out, given the dependencies, what
>> files to serve and on which server to serve it from.
>>
>>   :cljs-server
>>   {:jig/component jig.cljs/FileServer
>>:jig/dependencies [:cljs-builder :web]
>>:jig.web/context "/js"
>>}
>>
>> which depends on some Ring or Pedestal routing and Jetty or other
>> webserver, but you're likely to have that configured already :-
>>
>>
>>   :server
>>   {:jig/component jig.web.server/Component
>>:io.pedestal.service.http/port 8000
>>:io.pedestal.service.http/type :jetty
>>}
>>
>>   :web
>>
>>   {:jig/component jig.web.app/Component
>>:jig/dependencies [:server]
>>:jig/scheme :http
>>:jig/hostname "localhost"
>>:jig.web/server :server
>>}
>>
>> That's it really. I think Jig makes an ideal platform for building and
>> serving clojurescript, in comparison to Leiningen plugins. Firstly, there's
>> no JVM start-up cost, the point of Jig is to keep the JVM running all the
>> time, so there's no need for the once/auto service that lein-cljsbuild
>> offers. Secondly, serving the resulting Javascript files is straight
>> forward, and built in, so no 'lein ring server' requirement either.. With
>> Leiningen, you either have to build routes to the javascript into your own
>> app, or run lein ring server, but then Leiningen doesn't make it easy to
>> run multiple services concurrently. Thirdly, there's no file-system
>> polling, and services that depend on the clojurescript compilation can be
>> started as soon as the compilation is complete.
>>
>> One thing that lein-cljsbuild does really well is multiple build configs.
>> I've decided to use a single build configuration, to keep implementation
>> easier and a direct mapping to the clojurescript compiler, but of course
>> you can add different builds by just adding (differently configured)
>> components to the Jig config. This would benefit from being able to
>> initialize and start components in parallel, where possible. Unlike
>> cljsbuild, Jig components are started serially, in reverse dependency
>> order. Does anyone know of existing algorithms that can walk a dependency
>> tree in parallel?
>>
>> Feel free to take Jig in different directions though, I'm just letting
>> you know my current thoughts. The single REPL to multiple projects idea
>> might have to be rethought - it seems the prevailing wind is in the
>> direction of multiple REPL connections per editor/IDE.
>>
>>
>> On Thursday, 7 November 2013 01:09:53 UTC, frye wrote:
>>
>>> Too right.
>>>
>>> Yes, wrt the multi-project / classpath thing, running isolated test for
>>> a particular project is only one aspect. I also have an eye to running a i)
>>> browser-connected repl and ii) debugger for a particular project. So those
>>> things, along with iii) running tests, make very high, the attractiveness
>>> of having that isolation.
>>>
>>> I'll try to put those in github issues. And also pick at the problem
>>> myself when I get some cycles. I think it would add a powerful feature to
>>> the tool. Anyways... :)
>>>
>>>
>>> Tim Washington
>>> Interruptsoftware.ca  / 
>>> Bkeeping.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 

Re: [ANN] Jig

[Malcolm Sparks]

This is a good question, but not so much one for Jig as for Stuart's 
workflow pattern on which Jig's based.

Generally, I write my Clojure bottom-up, so that functions that do work 
against database connections and the like, take these as parameters, and 
not the whole system map. This leads to the situation where callers to 
these functions are doing stuff to extract the necessary values from the 
system map in order to pass them as parameters. Also, some functions have 
to take a lot of parameters. So at certain times I feel it's often easier 
to pass down the whole system map. This seems in violation of 
http://en.wikipedia.org/wiki/Principle_of_least_privilege - however, it's 
much better to pass state in to a function as a parameter, than have that 
function pull in state from vars that are scattered around various 
name-spaces. This also has a benefit to testing - it's possible to 
construct mock system map to test functions.

On the plus side, there is some precedent here. Ring handlers take large 
request structures, Liberator and Pedestal handlers take similar large 
'context' parameters. Datomic's query takes a whole database as a 
parameter! There is good support in Clojure for handling larger structures, 
such as clojure.walk, de-structuring, and so on. This would be a good time 
to mention Strucjure https://github.com/jamii/strucjure on which Jamie 
Brandon gave a great talk earlier this week in London. A common pattern in 
Strucjure is to use a tree walk and match on parts of the structure to 
drive processing.


On Thursday, November 7, 2013 5:13:49 AM UTC, julius wrote:
>
> Another question, using jig,  the connection/db/cache/storage will be 
> everywhere in our code as a parameter of functions, is it flexible? 
> ,currently I prefer to managing those side effect at one place but will not 
> spread out to our other core functions.
>
> Thanks
>
> On Saturday, October 12, 2013 12:23:41 AM UTC+8, Malcolm Sparks wrote:
>>
>> A few months ago, Stuart Sierra blogged about the workflow he follows for 
>> building Clojure applications.
>>
>> "One of the great pleasures of working with a dynamic language is being 
>> able to build a system while simultaneously interacting with it. "
>> -- http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded
>>
>> Since then I've been using this workflow for my own projects, and found 
>> it to be amazingly effective. 
>>
>> I've added some extra features, and the result is Jig, which builds on 
>> Stuart's work in the following ways :-
>>
>>- Multiple components can each contribute to the 'system' map
>>- Components are started in dependency order
>>- Components are specified and configured in a config (edn) file
>>- Jig can host 'plain old' Leiningen projects - Jig will even 
>>'reload' them too e.g. if their project.clj dependencies change.
>>- Jig can host multiple projects simultaneously
>>
>> There's a small but growing list of optional re-usable components that 
>> provide extra functionality :-
>>
>>- Pedestal services support. Jig provides the system map and 
>>'url-for' function in the service context.
>>- Nginx cache purging on reload
>>- Git pull prior reload
>>- Reload via JMX
>>- nREPL
>>- Stencil cache purging
>>- Firefox remote control support for 'browser refresh on reload'
>>
>> I know others are working on similar designs. I'd be interested to hear 
>> what people think and whether this is useful.
>>
>> Thanks,
>>
>> Malcolm
>>
>> PS: Jig can be found here: https://github.com/juxt/jig
>>
>>
>>
>>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Jig

[Malcolm Sparks]

That's a nice use of core.async  :)

The key requirement, however, is that a component's dependencies must all 
initialize before a component can start initializing. That reduces 
parallelism but not entirely. A component's dependencies can all be 
initiated in parallel, so long as there aren't any dependencies between 
each other. I'm sure there must be existing barrier sync algorithms out 
there that we could use. 
http://en.wikipedia.org/wiki/Barrier_%28computer_science%29  

On Friday, November 8, 2013 12:58:35 AM UTC, Cedric Greevey wrote:
>
> If you are just visiting every node as a tree, and you have core.async, 
> then there's
>
> (let [c (chan)]
>   (go
> (doseq [n (tree-seq ... (depends on tree implementation) ...)]
>   (>! c n)))
>   (dotimes [_ (.availableProcessors (Runtime/getRuntime))]
> (go
>   (loop []
> (when-let [n (   (expensive-visitation n)
>   (recur))
>
> unless there's some trickiness with core.async that I've not "gotten" 
> here. 
> Of course, if expensive-visitation returns something instead of having 
> side effects, you'll need to accumulate some sort of a result in each loop, 
> and combine these afterward (the dotimes likely becoming a for).
>
> If the visitation is really expensive, then converting the output of 
> tree-seq into a vector and using reducers or pmap might also parallelize 
> things significantly.
>
> If you need to do more than just visit each node -- if the tree structure 
> around the node and not just some value in the node needs to be considered 
> -- then it gets complicated. Something that traverses the tree, but spawns 
> new threads at each branching (up to some limit perhaps), seems indicated.
>
>
>
> On Thu, Nov 7, 2013 at 6:23 PM, Timothy Washington 
> 
> > wrote:
>
>> Umm I can't think of parallel dependency tree walking algos, off the top 
>> of my head. Sorry :/ 
>>
>> But niiice. Yeah, we're definitely thinking along the same lines. But 
>> you're way ahead of me. Now just to be able to isolate that browser repl on 
>> a per project basis. 
>>
>>
>> Sweet 
>>
>> Tim Washington 
>> Interruptsoftware.ca  / 
>> Bkeeping.com
>>  
>>
>>
>> On Wed, Nov 6, 2013 at 8:46 PM, Malcolm Sparks 
>> > wrote:
>>
>>> Hi Tim,
>>>
>>> It's interesting you're thinking about browser-connected repls. Today I 
>>> added clojurescript support to Jig, it's pushed to master but I haven't 
>>> documented the config options yet, but below is an example. Nothing fancy 
>>> like crossovers yet, it's basically a thin wrapper over ClojureScript's 
>>> compiler, the config options map directly to the options given to the 
>>> compiler.
>>>
>>>   :cljs-builder
>>>   {:jig/component jig.cljs/Builder
>>>:jig/project "../my-proj/project.clj"
>>>:source-path "../my-proj/src-cljs"
>>>:output-dir "../my-proj/target/js"
>>>:output-to "../my-proj/target/js/main.js"
>>>:source-map "../my-proj/target/js/main.js.map"
>>>:optimizations :simple
>>>:pretty-print true
>>> ;;   :clean-build true
>>>}
>>>
>>> Another built-in component can figure out, given the dependencies, what 
>>> files to serve and on which server to serve it from.
>>>
>>>   :cljs-server
>>>   {:jig/component jig.cljs/FileServer
>>>:jig/dependencies [:cljs-builder :web]
>>>:jig.web/context "/js"
>>>}
>>>
>>> which depends on some Ring or Pedestal routing and Jetty or other 
>>> webserver, but you're likely to have that configured already :-
>>>
>>>
>>>   :server
>>>   {:jig/component jig.web.server/Component
>>>:io.pedestal.service.http/port 8000
>>>:io.pedestal.service.http/type :jetty
>>>}
>>>
>>>   :web
>>>
>>>   {:jig/component jig.web.app/Component
>>>:jig/dependencies [:server]
>>>:jig/scheme :http
>>>:jig/hostname "localhost"
>>>:jig.web/server :server
>>>}
>>>
>>> That's it really. I think Jig makes an ideal platform for building and 
>>> serving clojurescript, in comparison to Leiningen plugins. Firstly, there's 
>>> no JVM start-up cost, the point of Jig is to keep the JVM running all the 
>>> time, so there's no need for the once/auto service that lein-cljsbuild 
>>> offers. Secondly, serving the resulting Javascript files is straight 
>>> forward, and built in, so no 'lein ring server' requirement either.. With 
>>> Leiningen, you either have to build routes to the javascript into your own 
>>> app, or run lein ring server, but then Leiningen doesn't make it easy to 
>>> run multiple services concurrently. Thirdly, there's no file-system 
>>> polling, and services that depend on the clojurescript compilation can be 
>>> started as soon as the compilation is complete.
>>>
>>> One thing that lein-cljsbuild does really well is multiple build 
>>> configs. I've decided to use a single build configuration, to keep 
>>> implementation easier and a direct mapping to the clojurescript compiler, 
>>> but of course you can add different builds by just 

Re: newbie question: how to include external libraries from Leiningen REPL

[Qiu Xiafei]

you may have a look at alembic: https://github.com/pallet/alembic

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ANN: byte vector backed, utf8 strings for Clojure

[danle...@gmail.com]

By "transient-utf8-writer" -- would that give you, effectively, something 
comparable to what is called an "adjustable-string" in common-lisp?

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: confused over meta on var

[Michael Wood]

Just s guess: Maybe the classpath is absolute in one case and relative in
the other.

On 07 Nov 2013 7:15 PM, "Phillip Lord"  wrote:
>
>
> I find myself confused by the metadata on a var. Consider this code:
>
> (def a-test-var 10)
>
> (pritnln (meta #'a-test-var))
>
> Now when run under "lein test" (by stuffing it into a test namespace), I
> get this
>
>
> {:ns #, :name a-test-var, :column 1, :line
102, :file tawny/util_test.clj}
>
>
> But, when evaled in a live REPL I get this...
>
>
> {:ns #, :name a-test-var, :column 1, :line
102, :file
"/home/phillord/src/knowledge/tawny-owl/test/tawny/util_test.clj"}
>
>
> So, how come the :file is fully qualified in one case, and relative in
> the other?
>
> Phil
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
"Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Jig

[Cedric Greevey]

Ah, for that you need to "layer" your DAG (directed acyclic graph -- if A
and B both depend on C, and are dependencies of D, you don't have a tree).
Start with S an empty set and n = 0. Iteratively let Sn be the items with
no dependencies not in S, S become S U Sn, and n = n + 1 until no items are
not yet in any of the Si. Now initialize, perhaps in parallel, all of the
S0; then all of the S1; then all of the S2 ...


On Thu, Nov 7, 2013 at 9:27 PM, Malcolm Sparks  wrote:

> That's a nice use of core.async  :)
>
> The key requirement, however, is that a component's dependencies must all
> initialize before a component can start initializing. That reduces
> parallelism but not entirely. A component's dependencies can all be
> initiated in parallel, so long as there aren't any dependencies between
> each other. I'm sure there must be existing barrier sync algorithms out
> there that we could use.
> http://en.wikipedia.org/wiki/Barrier_%28computer_science%29
>
> On Friday, November 8, 2013 12:58:35 AM UTC, Cedric Greevey wrote:
>
>> If you are just visiting every node as a tree, and you have core.async,
>> then there's
>>
>> (let [c (chan)]
>>   (go
>> (doseq [n (tree-seq ... (depends on tree implementation) ...)]
>>   (>! c n)))
>>   (dotimes [_ (.availableProcessors (Runtime/getRuntime))]
>> (go
>>   (loop []
>> (when-let [n (>   (expensive-visitation n)
>>   (recur))
>>
>> unless there's some trickiness with core.async that I've not "gotten"
>> here.
>> Of course, if expensive-visitation returns something instead of having
>> side effects, you'll need to accumulate some sort of a result in each loop,
>> and combine these afterward (the dotimes likely becoming a for).
>>
>> If the visitation is really expensive, then converting the output of
>> tree-seq into a vector and using reducers or pmap might also parallelize
>> things significantly.
>>
>> If you need to do more than just visit each node -- if the tree structure
>> around the node and not just some value in the node needs to be considered
>> -- then it gets complicated. Something that traverses the tree, but spawns
>> new threads at each branching (up to some limit perhaps), seems indicated.
>>
>>
>>
>> On Thu, Nov 7, 2013 at 6:23 PM, Timothy Washington wrote:
>>
>>> Umm I can't think of parallel dependency tree walking algos, off the top
>>> of my head. Sorry :/
>>>
>>> But niiice. Yeah, we're definitely thinking along the same lines. But
>>> you're way ahead of me. Now just to be able to isolate that browser repl on
>>> a per project basis.
>>>
>>>
>>> Sweet
>>>
>>> Tim Washington
>>> Interruptsoftware.ca  / 
>>> Bkeeping.com
>>>
>>>
>>>
>>> On Wed, Nov 6, 2013 at 8:46 PM, Malcolm Sparks  wrote:
>>>
 Hi Tim,

 It's interesting you're thinking about browser-connected repls. Today I
 added clojurescript support to Jig, it's pushed to master but I haven't
 documented the config options yet, but below is an example. Nothing fancy
 like crossovers yet, it's basically a thin wrapper over ClojureScript's
 compiler, the config options map directly to the options given to the
 compiler.

   :cljs-builder
   {:jig/component jig.cljs/Builder
:jig/project "../my-proj/project.clj"
:source-path "../my-proj/src-cljs"
:output-dir "../my-proj/target/js"
:output-to "../my-proj/target/js/main.js"
:source-map "../my-proj/target/js/main.js.map"
:optimizations :simple
:pretty-print true
 ;;   :clean-build true
}

 Another built-in component can figure out, given the dependencies, what
 files to serve and on which server to serve it from.

   :cljs-server
   {:jig/component jig.cljs/FileServer
:jig/dependencies [:cljs-builder :web]
:jig.web/context "/js"
}

 which depends on some Ring or Pedestal routing and Jetty or other
 webserver, but you're likely to have that configured already :-


   :server
   {:jig/component jig.web.server/Component
:io.pedestal.service.http/port 8000
:io.pedestal.service.http/type :jetty
}

   :web

   {:jig/component jig.web.app/Component
:jig/dependencies [:server]
:jig/scheme :http
:jig/hostname "localhost"
:jig.web/server :server
}

 That's it really. I think Jig makes an ideal platform for building and
 serving clojurescript, in comparison to Leiningen plugins. Firstly, there's
 no JVM start-up cost, the point of Jig is to keep the JVM running all the
 time, so there's no need for the once/auto service that lein-cljsbuild
 offers. Secondly, serving the resulting Javascript files is straight
 forward, and built in, so no 'lein ring server' requirement either.. With
 Leiningen, you either have to build routes to the javascript into your own
 app, o

Re: Step by step debugging

[Colin Fleming]

I'm slightly late to the discussion, sorry - currently moving cities.
Cursive does indeed have a stepping debugger which works well with Clojure,
although it's quite slow (I haven't been able to figure out why, yet - I
suspect Clojure adds a lot of line information to the bytecode). There have
also been some fairly annoying bugs with it which will be fixed in the next
drop. Here's more or less what it can do:

   1. Standard stepping - step into, step over. Step out is flaky for
   non-Java languages for some reason, I believe this is fixed in the new
   version of IntelliJ (13, currently in beta, due to be released soon).
   2. Place breakpoints on any line. This generally works well but is
   occasionally frustrating with Clojure since you can pack a lot on a line.
   I've found chained sequence operations to be particularly difficult to
   debug. This is really a JVM limitation since JVMTI is line-oriented.
   3. Breakpoints can be configured in various ways. Instead of stopping
   you can configure them to print the value of an expression, or to stop only
   the current thread, or to stop all threads.
   4. Drop frame to go back in time, as long as you're not mutating any
   global state. You're not, right?
   5. Look at locals up and down the stack, as long as you have locals
   clearing disabled.
   6. For the next drop I'm going to add the ability to toggle locals
   clearing in debug REPLs with a button in the REPL tool window.
   7. You can evaluate arbitrary Clojure expressions at any point in the
   call stack.
   8. You can set a breakpoint on an arbitrary exception, and it will pause
   *at the time the exception is thrown* and you can inspect locals etc.

I'm pretty sure all of this works, and I use most of it regularly.
Expression evaluation has been broken until the current dev build so I need
to test that things that depend on it work before promising them, but I'm
pretty sure they will. They include:

   1. Watches.
   2. Being able to configure breakpoints to only stop when a particular
   expression is true.

For the next drop I'm planning to work a lot on the debugger and document
it all properly including some pretty animations, so I'll post to the list
when that is done.


On 8 November 2013 13:14, intronic  wrote:

> Why would a break function in clojure  the language not be considered,
> a-la common-lisp?
>
>
>
> On Friday, 8 November 2013 09:31:55 UTC+10, Lee wrote:
>>
>>
>> On Nov 7, 2013, at 5:48 PM, Alex Miller wrote:
>>
>> > When you say "hit an error", I'm assuming you mean "clojure throws an
>> exception" and not "hit a breakpoint in a debugger" or something else.
>>
>> Yes -- I mean "clojure throws an exception."
>>
>> >
>> > I don't think there is one place where we could generically attach
>> locals info to a thrown exception. The JVM debugging interface (JVMTI -
>> http://docs.oracle.com/javase/7/docs/technotes/guides/jvmti/index.html)
>> can do an awful lot of things (including arbitrary class bytecode
>> transformation) so I would guess it's possible to build a java agent that
>> could do this (or to modify the Compiler to inject the right code at
>> compile time). Sounds like a fun project, but probably non-trivial.
>>
>> Too bad... unless someone wants to have that fun and then share it with
>> the rest of us :-). It still strikes me as really odd that such basic and
>> clearly desirable functionality, available forever in other environments,
>> should be so hard to come by.
>>
>>  -Lee
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Cedric Greevey]

Ideally, in a Lisp I'd think the unit of breakpoints would not be a line
but instead an s-expression, tripping before evaluating the body of the
expression.


On Fri, Nov 8, 2013 at 12:24 AM, Colin Fleming
wrote:

> I'm slightly late to the discussion, sorry - currently moving cities.
> Cursive does indeed have a stepping debugger which works well with Clojure,
> although it's quite slow (I haven't been able to figure out why, yet - I
> suspect Clojure adds a lot of line information to the bytecode). There have
> also been some fairly annoying bugs with it which will be fixed in the next
> drop. Here's more or less what it can do:
>
>1. Standard stepping - step into, step over. Step out is flaky for
>non-Java languages for some reason, I believe this is fixed in the new
>version of IntelliJ (13, currently in beta, due to be released soon).
>2. Place breakpoints on any line. This generally works well but is
>occasionally frustrating with Clojure since you can pack a lot on a line.
>I've found chained sequence operations to be particularly difficult to
>debug. This is really a JVM limitation since JVMTI is line-oriented.
>3. Breakpoints can be configured in various ways. Instead of stopping
>you can configure them to print the value of an expression, or to stop only
>the current thread, or to stop all threads.
>4. Drop frame to go back in time, as long as you're not mutating any
>global state. You're not, right?
>5. Look at locals up and down the stack, as long as you have locals
>clearing disabled.
>6. For the next drop I'm going to add the ability to toggle locals
>clearing in debug REPLs with a button in the REPL tool window.
>7. You can evaluate arbitrary Clojure expressions at any point in the
>call stack.
>8. You can set a breakpoint on an arbitrary exception, and it will
>pause *at the time the exception is thrown* and you can inspect locals etc.
>
> I'm pretty sure all of this works, and I use most of it regularly.
> Expression evaluation has been broken until the current dev build so I need
> to test that things that depend on it work before promising them, but I'm
> pretty sure they will. They include:
>
>1. Watches.
>2. Being able to configure breakpoints to only stop when a particular
>expression is true.
>
> For the next drop I'm planning to work a lot on the debugger and document
> it all properly including some pretty animations, so I'll post to the list
> when that is done.
>
>
> On 8 November 2013 13:14, intronic  wrote:
>
>> Why would a break function in clojure  the language not be considered,
>> a-la common-lisp?
>>
>>
>>
>> On Friday, 8 November 2013 09:31:55 UTC+10, Lee wrote:
>>>
>>>
>>> On Nov 7, 2013, at 5:48 PM, Alex Miller wrote:
>>>
>>> > When you say "hit an error", I'm assuming you mean "clojure throws an
>>> exception" and not "hit a breakpoint in a debugger" or something else.
>>>
>>> Yes -- I mean "clojure throws an exception."
>>>
>>> >
>>> > I don't think there is one place where we could generically attach
>>> locals info to a thrown exception. The JVM debugging interface (JVMTI -
>>> http://docs.oracle.com/javase/7/docs/technotes/guides/jvmti/index.html)
>>> can do an awful lot of things (including arbitrary class bytecode
>>> transformation) so I would guess it's possible to build a java agent that
>>> could do this (or to modify the Compiler to inject the right code at
>>> compile time). Sounds like a fun project, but probably non-trivial.
>>>
>>> Too bad... unless someone wants to have that fun and then share it with
>>> the rest of us :-). It still strikes me as really odd that such basic and
>>> clearly desirable functionality, available forever in other environments,
>>> should be so hard to come by.
>>>
>>>  -Lee
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/cloju

Re: Step by step debugging

[Colin Fleming]

Right, sadly I believe this is impossible using JVMTI, although I'm far
from an expert.


On 8 November 2013 18:51, Cedric Greevey  wrote:

> Ideally, in a Lisp I'd think the unit of breakpoints would not be a line
> but instead an s-expression, tripping before evaluating the body of the
> expression.
>
>
> On Fri, Nov 8, 2013 at 12:24 AM, Colin Fleming <
> colin.mailingl...@gmail.com> wrote:
>
>> I'm slightly late to the discussion, sorry - currently moving cities.
>> Cursive does indeed have a stepping debugger which works well with Clojure,
>> although it's quite slow (I haven't been able to figure out why, yet - I
>> suspect Clojure adds a lot of line information to the bytecode). There have
>> also been some fairly annoying bugs with it which will be fixed in the next
>> drop. Here's more or less what it can do:
>>
>>1. Standard stepping - step into, step over. Step out is flaky for
>>non-Java languages for some reason, I believe this is fixed in the new
>>version of IntelliJ (13, currently in beta, due to be released soon).
>>2. Place breakpoints on any line. This generally works well but is
>>occasionally frustrating with Clojure since you can pack a lot on a line.
>>I've found chained sequence operations to be particularly difficult to
>>debug. This is really a JVM limitation since JVMTI is line-oriented.
>>3. Breakpoints can be configured in various ways. Instead of stopping
>>you can configure them to print the value of an expression, or to stop 
>> only
>>the current thread, or to stop all threads.
>>4. Drop frame to go back in time, as long as you're not mutating any
>>global state. You're not, right?
>>5. Look at locals up and down the stack, as long as you have locals
>>clearing disabled.
>>6. For the next drop I'm going to add the ability to toggle locals
>>clearing in debug REPLs with a button in the REPL tool window.
>>7. You can evaluate arbitrary Clojure expressions at any point in the
>>call stack.
>>8. You can set a breakpoint on an arbitrary exception, and it will
>>pause *at the time the exception is thrown* and you can inspect locals 
>> etc.
>>
>> I'm pretty sure all of this works, and I use most of it regularly.
>> Expression evaluation has been broken until the current dev build so I need
>> to test that things that depend on it work before promising them, but I'm
>> pretty sure they will. They include:
>>
>>1. Watches.
>>2. Being able to configure breakpoints to only stop when a particular
>>expression is true.
>>
>> For the next drop I'm planning to work a lot on the debugger and document
>> it all properly including some pretty animations, so I'll post to the list
>> when that is done.
>>
>>
>> On 8 November 2013 13:14, intronic  wrote:
>>
>>> Why would a break function in clojure  the language not be considered,
>>> a-la common-lisp?
>>>
>>>
>>>
>>> On Friday, 8 November 2013 09:31:55 UTC+10, Lee wrote:


 On Nov 7, 2013, at 5:48 PM, Alex Miller wrote:

 > When you say "hit an error", I'm assuming you mean "clojure throws an
 exception" and not "hit a breakpoint in a debugger" or something else.

 Yes -- I mean "clojure throws an exception."

 >
 > I don't think there is one place where we could generically attach
 locals info to a thrown exception. The JVM debugging interface (JVMTI -
 http://docs.oracle.com/javase/7/docs/technotes/guides/jvmti/index.html)
 can do an awful lot of things (including arbitrary class bytecode
 transformation) so I would guess it's possible to build a java agent that
 could do this (or to modify the Compiler to inject the right code at
 compile time). Sounds like a fun project, but probably non-trivial.

 Too bad... unless someone wants to have that fun and then share it with
 the rest of us :-). It still strikes me as really odd that such basic and
 clearly desirable functionality, available forever in other environments,
 should be so hard to come by.

  -Lee
>>>
>>>  --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send e

Re: Does Pedestal have a future in the long run

[Daniel]

I suspect Pedestal adoption will really take off once it has a well designed 
and advertised widget/ui toolkit.  Just my two cents.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Step by step debugging

[Cedric Greevey]

This JVMTI doesn't know Clojure source code from parsnip soup, I expect, so
can't it be fooled into "thinking" that the bytecode it's interpreting came
from a source with many more, shorter lines? So

(defn x [y z]
  (a (b (c))
  ((d) e (f g

could be passed off to it as if it were

(defn x [y z] (a (b
(c))
 ((d)
e (f g

with breakpoints on (defn ...), (a ...), a, (b (c)), or b being passed to
JVMTI as breakpoints on the first line of the latter formatting of the
code; breakpoints on (c) or c the second line; breakpoints on (d) or d the
third line; and breakpoints on e, (f g), f, or g the fourth line. Execution
would halt at the breakpoint with the correct amount of evaluation done.
(The bare letters are presumed to be self-evaluating literals or var
lookups here, and the operators, other than defn, to be functions.)

Breakpoints on a macro sexp would need to halt on the first evaluation of
any of the expansion, and breakpoints on a macro argument would need to be
carried through into the expansion. The special forms are mostly fairly
obvious -- break on an if or its condition, for example, breaks before
evaluating the condition; break on the then clause breaks after evaluating
the condition, before evaluating the then clause, only if the condition was
true; etc. Combined, those rules mean a breakpoint on a particular (cond
...) condition X would only trip if all the previous conditions were false,
before evaluating condition X, and a breakpoint on the corresponding then
clause only if all the preceding conditions were false but condition X was
true, after evaluating X but before evaluating X's then clause, because it
would end up attached to X's corresponding conditional or then clause
(respectively) in the macro-expanded if-tree (>(sexp)< indicates breakpoint
target):

(cond
  (thing1) (dothis)
  (thing2) (dothat)
  >(thing3)< (dosomethingelse)
  :else (default))

should macroexpand to

(if (thing1)
  (dothis)
  (if (thing2)
(dothat)
  (if >(thing3)<
(dosomethingelse)
(if :else
  (default)
  (throw ( ... no matching clause blah blah ... [never actually
executes in this case]))

so the "(if >(thing3)<" line would be what JVMTI "thinks" is the
breakpointed line in this case.

The real issue I can foresee here would be if there's no way to make the
"lines" seen by the breakpoint/debugging stuff be different from the
"lines" used for error reporting (e.g. in stacktraces), as then *either*
the "line" granularity for breakpoints is whole lines of your actual source
code *or* stacktrace line numbers won't always correspond to what your
editor shows for the problem line in your source code, for example if
(default) threw a ClassCastException because "default" did not implement
IFn in the above the stacktrace might point to line 8 when it was really
line 5 of your (cond ...) expression (but line 8 of the (if ...) it
macroexpanded to, and which was vertically spread out to put each distinct
(as to what nontrivial evaluation has happened yet) sexp-based breakpoint
position on its own line to please JVMTI).




On Fri, Nov 8, 2013 at 12:53 AM, Colin Fleming
wrote:

> Right, sadly I believe this is impossible using JVMTI, although I'm far
> from an expert.
>
>
> On 8 November 2013 18:51, Cedric Greevey  wrote:
>
>> Ideally, in a Lisp I'd think the unit of breakpoints would not be a line
>> but instead an s-expression, tripping before evaluating the body of the
>> expression.
>>
>>
>> On Fri, Nov 8, 2013 at 12:24 AM, Colin Fleming <
>> colin.mailingl...@gmail.com> wrote:
>>
>>> I'm slightly late to the discussion, sorry - currently moving cities.
>>> Cursive does indeed have a stepping debugger which works well with Clojure,
>>> although it's quite slow (I haven't been able to figure out why, yet - I
>>> suspect Clojure adds a lot of line information to the bytecode). There have
>>> also been some fairly annoying bugs with it which will be fixed in the next
>>> drop. Here's more or less what it can do:
>>>
>>>1. Standard stepping - step into, step over. Step out is flaky for
>>>non-Java languages for some reason, I believe this is fixed in the new
>>>version of IntelliJ (13, currently in beta, due to be released soon).
>>>2. Place breakpoints on any line. This generally works well but is
>>>occasionally frustrating with Clojure since you can pack a lot on a line.
>>>I've found chained sequence operations to be particularly difficult to
>>>debug. This is really a JVM limitation since JVMTI is line-oriented.
>>>3. Breakpoints can be configured in various ways. Instead of
>>>stopping you can configure them to print the value of an expression, or 
>>> to
>>>stop only the current thread, or to stop all threads.
>>>4. Drop frame to go back in time, as long as you're not mutating any
>>>global state. You're not, right?
>>>5. Look at locals up and down the stack, a

Clojure try with PredictionIO which is an open source machine learning server

[Tienson Qin]

PredictionIO is an open source machine learning server for software 
developers to create predictive features, 
such as personalization, recommendation and content discovery.

I've written a recommendation sample with clojure, thanks to PredictionIO's 
RESTful api, 
the code is very simple and short. 

Actually i'm a novice, but i do really feel clojure's simplicity and power, 
and here is the repo:
https://github.com/tiensonqin/predictionio-sample

Thanks,
tienson

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ANN: byte vector backed, utf8 strings for Clojure

[Jozef Wagner]

It is more like the transient vector which Clojure provides. You can only 
conj to the transients. If you want to perform other operations, you must 
convert it back to the persistent ut8-string.

On Friday, November 8, 2013 4:33:04 AM UTC+1, danl...@gmail.com wrote:
>
> By "transient-utf8-writer" -- would that give you, effectively, something 
> comparable to what is called an "adjustable-string" in common-lisp?

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.