Re: cljs.test :after fixture not called if test errors

[Stuart Campbell]

Makes sense. Thanks all!

On Wed, Nov 25, 2020, 6:46 PM David Nolen  wrote:

> In the async case just handle the error yourself and fail the test.
> There's really not a good way to detect async errors since there isn't one
> way to. do async (promises, core.async, etc.).
>
> David
>
> On Wed, Nov 25, 2020 at 1:19 AM Stuart Campbell  wrote:
>
>> That unfortunately doesn't work for async tests, which require the map
>> fixture style (with :before/:after keys).
>>
>> On Tue, 24 Nov 2020 at 21:23, Estevo U. C. Castro 
>> wrote:
>>
>>> Try
>>>
>>> (use-fixtures :once
>>>   (fn [f]
>>> (println "before")
>>> (try (f)
>>>   (finally (println "after")
>>>
>>> O mércores, 25 de novembro de 2020 á/s 00:17:03 UTC+1,
>>> stuart.will...@gmail.com escribiu:
>>>
>>>> Hello,
>>>>
>>>> I'm experimenting with fixtures and it seems like :after fixtures
>>>> aren't run if a test unexpectedly errors. E.g.:
>>>>
>>>> (use-fixtures :once {:before #(println "before")
>>>>  :after #(println "after")})
>>>>
>>>> (deftest a-test
>>>>   (raise (js/Error. "oops")))
>>>>
>>>> In this example I expected to see "after" printed somewhere after the
>>>> test failed. Is this intentional?
>>>>
>>>> (I'm writing some tests for an Electron app using Spectron and want to
>>>> make sure the app is always shut down after the tests are complete.)
>>>>
>>>> Regards,
>>>> Stuart
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from 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/N28pFLtNWpo/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> clojure+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/clojure/84dff1cf-6ea0-438c-a4c0-fac097223201n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/clojure/84dff1cf-6ea0-438c-a4c0-fac097223201n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/clojure/CAFuJp1n1Vz8NKf%3DmxakTYn1EXF8UUqTQwc5NiDUKGMOj-BKBsQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/clojure/CAFuJp1n1Vz8NKf%3DmxakTYn1EXF8UUqTQwc5NiDUKGMOj-BKBsQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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/cloju

Re: cljs.test :after fixture not called if test errors

[David Nolen]

In the async case just handle the error yourself and fail the test. There's
really not a good way to detect async errors since there isn't one way to.
do async (promises, core.async, etc.).

David

On Wed, Nov 25, 2020 at 1:19 AM Stuart Campbell  wrote:

> That unfortunately doesn't work for async tests, which require the map
> fixture style (with :before/:after keys).
>
> On Tue, 24 Nov 2020 at 21:23, Estevo U. C. Castro 
> wrote:
>
>> Try
>>
>> (use-fixtures :once
>>   (fn [f]
>> (println "before")
>> (try (f)
>>   (finally (println "after")
>>
>> O mércores, 25 de novembro de 2020 á/s 00:17:03 UTC+1,
>> stuart.will...@gmail.com escribiu:
>>
>>> Hello,
>>>
>>> I'm experimenting with fixtures and it seems like :after fixtures aren't
>>> run if a test unexpectedly errors. E.g.:
>>>
>>> (use-fixtures :once {:before #(println "before")
>>>  :after #(println "after")})
>>>
>>> (deftest a-test
>>>   (raise (js/Error. "oops")))
>>>
>>> In this example I expected to see "after" printed somewhere after the
>>> test failed. Is this intentional?
>>>
>>> (I'm writing some tests for an Electron app using Spectron and want to
>>> make sure the app is always shut down after the tests are complete.)
>>>
>>> Regards,
>>> Stuart
>>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from 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/N28pFLtNWpo/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/clojure/84dff1cf-6ea0-438c-a4c0-fac097223201n%40googlegroups.com
>> <https://groups.google.com/d/msgid/clojure/84dff1cf-6ea0-438c-a4c0-fac097223201n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/CAFuJp1n1Vz8NKf%3DmxakTYn1EXF8UUqTQwc5NiDUKGMOj-BKBsQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/clojure/CAFuJp1n1Vz8NKf%3DmxakTYn1EXF8UUqTQwc5NiDUKGMOj-BKBsQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAPC9OaetpVoUTexro%3DcJwPghEM8vLeHeHvW8G-3dok_8EfSpug%40mail.gmail.com.

Re: cljs.test :after fixture not called if test errors

[Stuart Campbell]

That unfortunately doesn't work for async tests, which require the map
fixture style (with :before/:after keys).

On Tue, 24 Nov 2020 at 21:23, Estevo U. C. Castro 
wrote:

> Try
>
> (use-fixtures :once
>   (fn [f]
> (println "before")
> (try (f)
>   (finally (println "after")
>
> O mércores, 25 de novembro de 2020 á/s 00:17:03 UTC+1,
> stuart.will...@gmail.com escribiu:
>
>> Hello,
>>
>> I'm experimenting with fixtures and it seems like :after fixtures aren't
>> run if a test unexpectedly errors. E.g.:
>>
>> (use-fixtures :once {:before #(println "before")
>>  :after #(println "after")})
>>
>> (deftest a-test
>>   (raise (js/Error. "oops")))
>>
>> In this example I expected to see "after" printed somewhere after the
>> test failed. Is this intentional?
>>
>> (I'm writing some tests for an Electron app using Spectron and want to
>> make sure the app is always shut down after the tests are complete.)
>>
>> Regards,
>> Stuart
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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/N28pFLtNWpo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/84dff1cf-6ea0-438c-a4c0-fac097223201n%40googlegroups.com
> <https://groups.google.com/d/msgid/clojure/84dff1cf-6ea0-438c-a4c0-fac097223201n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAFuJp1n1Vz8NKf%3DmxakTYn1EXF8UUqTQwc5NiDUKGMOj-BKBsQ%40mail.gmail.com.

Re: cljs.test :after fixture not called if test errors

[Estevo U. C. Castro]

Try

(use-fixtures :once 
  (fn [f]
(println "before") 
(try (f) 
  (finally (println "after")

O mércores, 25 de novembro de 2020 á/s 00:17:03 UTC+1, 
stuart.will...@gmail.com escribiu:

> Hello,
>
> I'm experimenting with fixtures and it seems like :after fixtures aren't 
> run if a test unexpectedly errors. E.g.:
>
> (use-fixtures :once {:before #(println "before")
>  :after #(println "after")})
>
> (deftest a-test
>   (raise (js/Error. "oops")))
>
> In this example I expected to see "after" printed somewhere after the test 
> failed. Is this intentional?
>
> (I'm writing some tests for an Electron app using Spectron and want to 
> make sure the app is always shut down after the tests are complete.)
>
> Regards,
> Stuart
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/84dff1cf-6ea0-438c-a4c0-fac097223201n%40googlegroups.com.

cljs.test :after fixture not called if test errors

[Stuart Campbell]

Hello,

I'm experimenting with fixtures and it seems like :after fixtures aren't 
run if a test unexpectedly errors. E.g.:

(use-fixtures :once {:before #(println "before")
 :after #(println "after")})

(deftest a-test
  (raise (js/Error. "oops")))

In this example I expected to see "after" printed somewhere after the test 
failed. Is this intentional?

(I'm writing some tests for an Electron app using Spectron and want to make 
sure the app is always shut down after the tests are complete.)

Regards,
Stuart

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/53969332-2819-48fe-ab01-a27fd3b0cc00n%40googlegroups.com.

ANN: Promenade - Elegant handling of errors and other oddities (Clojure/ClojureScript)

[Shantanu Kumar]

Hi,

I am pleased to announce Promenade - a Clojure/ClojureScript library to 
elegantly handle errors and other oddities:

Project: https://github.com/kumarshantanu/promenade

Docs: https://github.com/kumarshantanu/promenade/blob/master/doc/intro.md

Promenade helps one express odd conditions (such as errors etc.) as data 
and provides associated control flow facilities. This library is only a 
couple of months old, but the code I have seen this applied to has greatly 
simplified error-handling and improved readability because of it. I hope 
others would find it useful too. I would love to receive your feedback and 
comments - please let me know what you think.


Shantanu

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: Cider - emacs lisp errors reported

[Peter Hull]

On Sunday, 10 December 2017 14:14:05 UTC, Bozhidar Batsov wrote:
>
> It might have been changed upstream. Not sure what's your Emacs version. A 
> while ago we backported this macro in whatever its current form was for 
> compatibility with older Emacsen.
>
> File a ticket on GitHub and we'll investigate. 
>

OK, now I can't reproduce it. My guess is that some other elisp code was 
interfering, not sure how.

Anyway, thanks for the advice.

Peter

 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Cider - emacs lisp errors reported

[Philos Kim]

I encountered the same problem some years ago. In my case the problem was 
solved by removing (require 'cl-lib) line in my init.el file. The cl-lib 
package defined when-let as well.
I hope that this will help you 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/d/optout.

Re: Cider - emacs lisp errors reported

[Bozhidar Batsov]

It might have been changed upstream. Not sure what's your Emacs version. A
while ago we backported this macro in whatever its current form was for
compatibility with older Emacsen.

File a ticket on GitHub and we'll investigate.


On 10 December 2017 at 13:44, Peter Hull  wrote:

> I noticed this when updating cider via melpa, and I wasn't sure if it's
> already known about or whether it is even an problem. I thought I'd ask
> here before submitting an issue to github.
>
> Compiling file 
> /Users/peterhull/.emacs.d/elpa/cider-20171209.1602/cider-browse-spec.el
> at Sun Dec 10 11:29:29 2017
> cider-browse-spec.el:277:1:Error: Wrong number of arguments: when-let, 1
>
> Compiling file 
> /Users/peterhull/.emacs.d/elpa/cider-20171209.1602/cider-classpath.el
> at Sun Dec 10 11:29:29 2017
> cider-classpath.el:102:1:Error: Wrong number of arguments: when-let, 1
>
> Compiling file 
> /Users/peterhull/.emacs.d/elpa/cider-20171209.1602/cider-client.el
> at Sun Dec 10 11:29:29 2017
> cider-client.el:143:1:Error: Wrong number of arguments: when-let, 1
>
> Compiling file 
> /Users/peterhull/.emacs.d/elpa/cider-20171209.1602/cider-common.el
> at Sun Dec 10 11:29:29 2017
> cider-common.el:186:1:Error: Wrong number of arguments: when-let, 4
>
> Compiling file 
> /Users/peterhull/.emacs.d/elpa/cider-20171209.1602/cider-compat.el
> at Sun Dec 10 11:29:29 2017
>
> Compiling file 
> /Users/peterhull/.emacs.d/elpa/cider-20171209.1602/cider-debug.el
> at Sun Dec 10 11:29:29 2017
> cider-debug.el:226:1:Error: Wrong number of arguments: when-let, 1
>
> Compiling file /Users/peterhull/.emacs.d/elpa/cider-20171209.1602/cider-doc.el
> at Sun Dec 10 11:29:29 2017
> cider-doc.el:263:1:Error: Wrong number of arguments: when-let, 1
>
> And for example, the first instance looks like this
>
> (defun cider-browse-spec--browse-at ( pos)
>   "View the definition of a spec.
>
> Optional argument POS is the position of a spec, defaulting to point.  POS
> may also be a button, so this function can be used a the button's `action'
> property."
>   (interactive)
>   (let ((pos (or pos (point
> (when-let ((spec (button-get pos 'spec-name)))
>   (cider-browse-spec--browse spec
>
> I am not an elisp expert but I think the syntax of when-let is (when-let
> (var value) body) rather than (when-let ((var value)) body)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Cider - emacs lisp errors reported

[Peter Hull]

I noticed this when updating cider via melpa, and I wasn't sure if it's 
already known about or whether it is even an problem. I thought I'd ask 
here before submitting an issue to github.

Compiling file 
/Users/peterhull/.emacs.d/elpa/cider-20171209.1602/cider-browse-spec.el at 
Sun Dec 10 11:29:29 2017
cider-browse-spec.el:277:1:Error: Wrong number of arguments: when-let, 1

Compiling file 
/Users/peterhull/.emacs.d/elpa/cider-20171209.1602/cider-classpath.el at 
Sun Dec 10 11:29:29 2017
cider-classpath.el:102:1:Error: Wrong number of arguments: when-let, 1

Compiling file 
/Users/peterhull/.emacs.d/elpa/cider-20171209.1602/cider-client.el at Sun 
Dec 10 11:29:29 2017
cider-client.el:143:1:Error: Wrong number of arguments: when-let, 1

Compiling file 
/Users/peterhull/.emacs.d/elpa/cider-20171209.1602/cider-common.el at Sun 
Dec 10 11:29:29 2017
cider-common.el:186:1:Error: Wrong number of arguments: when-let, 4

Compiling file 
/Users/peterhull/.emacs.d/elpa/cider-20171209.1602/cider-compat.el at Sun 
Dec 10 11:29:29 2017

Compiling file 
/Users/peterhull/.emacs.d/elpa/cider-20171209.1602/cider-debug.el at Sun 
Dec 10 11:29:29 2017
cider-debug.el:226:1:Error: Wrong number of arguments: when-let, 1

Compiling file 
/Users/peterhull/.emacs.d/elpa/cider-20171209.1602/cider-doc.el at Sun Dec 
10 11:29:29 2017
cider-doc.el:263:1:Error: Wrong number of arguments: when-let, 1

And for example, the first instance looks like this

(defun cider-browse-spec--browse-at ( pos)
  "View the definition of a spec.

Optional argument POS is the position of a spec, defaulting to point.  POS
may also be a button, so this function can be used a the button's `action'
property."
  (interactive)
  (let ((pos (or pos (point
(when-let ((spec (button-get pos 'spec-name)))
  (cider-browse-spec--browse spec

I am not an elisp expert but I think the syntax of when-let is (when-let 
(var value) body) rather than (when-let ((var value)) body)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: Errors

[Paul Walker]

Very useful. So it is a *bit* philosophical :) I guess the unabashedly hosted 
philosophy is one I wasn't so sure was intentional but it's good to understand; 
and embracing that changes the way you'd teach or introduce the language. 
Gotcha. Where I thought I "had to form" a dual mental model and I should have 
thought I "got to learn" one quickly. Cool!

And yeah lazyness and locality of error is always always hard. 

I loved elenas talk. At about the 16 minute mark she takes to task exactly the 
message I picked. Her solution looks tricky for non-instructional uses though, 
like when she rebinds map. And a big pile of stack regexps is tricky to 
maintain beyond teaching use cases I could imagine.

Anyway, thanks for the links and thanks for the thoughtful answers. I really 
appreciate it. It has me thinking.

Be well,

  - Paul

> On Dec 6, 2016, at 10:54, Alex Miller <a...@puredanger.com> wrote:
> 
> 
>> On Tuesday, December 6, 2016 at 5:55:52 AM UTC-6, Paul Walker wrote:
>> Wow thank you for the fulsome responses
>> 
>> A couple of thoughts. I brashly said
>> 
>> > I cherrypicked a case where the runtime difference would be tiny
>> 
>> and I appreciate the clarifications - especially that my naive 
>> add-one-bytecode calculation in my head (the code I pasted has a pretty 
>> meaty “analyze” call called before it every time which is why I thought I 
>> cherry-picked) didn’t think about things like byte code inlining or, really, 
>> the pile-of-sand one-more-bytecode syndrome. So thanks for that!
> 
> I think in the case you picked that you're right that the performance impact 
> is minimal. This happens at compile-time and generally we are less sensitive 
> there than in calls during the runtime. Colin's talk from last year's conj 
> gives a good idea of some of the challenges in working on this stuff. 
> https://www.youtube.com/watch?v=kt4haSH2xcs
>  
>> And my favorite response from Alex:
>> 
>> > If I can make a request, it would be that instead of saying "errors are 
>> > bad" (which is honestly, not helpful by itself), but to step back and 
>> > either take a broader approach towards systemic issues
>> 
>> This is so reasonable I’m embarrassed I was a bit glib in my first note. I 
>> mean it’s not like they are C++ template errors from 1998  (my gold standard 
>> for bad errors). So let me expand on “bad” a little. 
>> 
>> I think the error messages are “bad” in 3 particular but related ways. I’d 
>> be happy to expand on these, but the themes are:
>> 
>> 1: They are “large” and “far from my code”. This is partly an issue with 
>> java stack traces, but the intermixing of java and clojure and the 
>> presentation of clojure names in java name-like things in the stacks is 
>> obscuring. The line numbers are obscured instead of displayed prominently. 
>> And so on.
> 
> Personally, I don't have a problem with stack traces - there's a ton of 
> useful information in a stack trace. The issues of "distance from code" are 
> interesting in Clojure though. One area I mentioned is due to errors in 
> macros where it reports either the error in the macro rather than in the 
> source OR where you get a runtime code that is based on code that was written 
> by the macro (not by you). The first problem is significantly improved by 
> spec. Another source of "distance" is laziness - sometimes a nested operation 
> will not error until a lazy seq is forced, possibly far from the core of the 
> problem. Eager transformations (we have more options for this now with 
> transducers) can help with that, as can spec in reporting more accurately the 
> error when it occurs.
>  
>> 2: Similarly, they expose internals of the runtime implementation to the 
>> user. Stacks intertwine java and clojure (CIDER error screen has a toggle to 
>> supress the stack partially for this). They show java exceptions as clojure 
>> errors when they aren’t part of a clojure program. etc…
> 
> Again, Clojure is an unapologetically hosted language. There is no desire to 
> hide that fact or to shield you from it. That means that learning Clojure 
> inevitably means learning something about the JVM or Java as well. 
>  
>> 3: These, plus a few other things, mean the error messages are semantically 
>> far away from the program you write. You stay happily in LISP-y land until 
>> you get a stack, then you realize you are in java. There are lots of 
>> examples of this, but take the dumb one I picked - (1 + 1) in a REPL. That 
>> shows two concepts (java.lang.Long and clojure.lang.IFn) which you don’t 
>> deal with in lisp. I’ve written quite a lot o

Re: Errors

[Alex Miller]

On Tuesday, December 6, 2016 at 5:55:52 AM UTC-6, Paul Walker wrote:
>
> Wow thank you for the fulsome responses
>
> A couple of thoughts. I brashly said
>
> > I cherrypicked a case where the runtime difference would be tiny
>
> and I appreciate the clarifications - especially that my naive 
> add-one-bytecode calculation in my head (the code I pasted has a pretty 
> meaty “analyze” call called before it every time which is why I thought I 
> cherry-picked) didn’t think about things like byte code inlining or, 
> really, the pile-of-sand one-more-bytecode syndrome. So thanks for that!
>

I think in the case you picked that you're right that the performance 
impact is minimal. This happens at compile-time and generally we are less 
sensitive there than in calls during the runtime. Colin's talk from last 
year's conj gives a good idea of some of the challenges in working on this 
stuff. https://www.youtube.com/watch?v=kt4haSH2xcs
 

> And my favorite response from Alex:
>
> > If I can make a request, it would be that instead of saying "errors are 
> bad" (which is honestly, not helpful by itself), but to step back and 
> either take a broader approach towards systemic issues
>
> This is so reasonable I’m embarrassed I was a bit glib in my first note. I 
> mean it’s not like they are C++ template errors from 1998  (my gold 
> standard for bad errors). So let me expand on “bad” a little. 
>
> I think the error messages are “bad” in 3 particular but related ways. I’d 
> be happy to expand on these, but the themes are:
>
> 1: They are “large” and “far from my code”. This is partly an issue with 
> java stack traces, but the intermixing of java and clojure and the 
> presentation of clojure names in java name-like things in the stacks is 
> obscuring. The line numbers are obscured instead of displayed prominently. 
> And so on.
>

Personally, I don't have a problem with stack traces - there's a ton of 
useful information in a stack trace. The issues of "distance from code" are 
interesting in Clojure though. One area I mentioned is due to errors in 
macros where it reports either the error in the macro rather than in the 
source OR where you get a runtime code that is based on code that was 
written by the macro (not by you). The first problem is significantly 
improved by spec. Another source of "distance" is laziness - sometimes a 
nested operation will not error until a lazy seq is forced, possibly far 
from the core of the problem. Eager transformations (we have more options 
for this now with transducers) can help with that, as can spec in reporting 
more accurately the error when it occurs.
 

> 2: Similarly, they expose internals of the runtime implementation to the 
> user. Stacks intertwine java and clojure (CIDER error screen has a toggle 
> to supress the stack partially for this). They show java exceptions as 
> clojure errors when they aren’t part of a clojure program. etc…
>

Again, Clojure is an unapologetically hosted language. There is no desire 
to hide that fact or to shield you from it. That means that learning 
Clojure inevitably means learning something about the JVM or Java as well. 
 

> 3: These, plus a few other things, mean the error messages are 
> semantically far away from the program you write. You stay happily in 
> LISP-y land until you get a stack, then you realize you are in java. There 
> are lots of examples of this, but take the dumb one I picked - (1 + 1) in a 
> REPL. That shows two concepts (java.lang.Long and clojure.lang.IFn) which 
> you don’t deal with in lisp. I’ve written quite a lot of clojure in the 
> last 5 months and never typed clojure.lang.IFn once. It’s a java error 
> message but I’m a clojure programmer. Instant semantic break. And since 
> many error messages are generated at the runtime level, which is java / 
> JVM, I experience this semantic break often. Add the excellent comments in 
> this thread on macro expand non-locality of error and the problem expands.
>

I get this and it's unfortunate when it exposes to you more than you need 
to know initially. But at the same time, I think developing that knowledge 
is essential to make the best use of Clojure in the long term.
 

> So if you imagine a guide like “the error should be as close to the error 
> causing code as possible and presented in the semantics of the problem” 
> then I think I conclude clojure messages are “bad”. (But I love clojure) 
>
> It seems spec, inasmuch as it acts as a sort of optional type system which 
> is in the space of the clojure language and produces information in that 
> space, would address many of these. 
>
> And as to why I mentioned this: I mean I haven’t had a problem. I just 
> built a dual mental model of clojure and the clojure runtime while I 
&g

Re: Errors

[Paul Walker]

Wow thank you for the fulsome responses

A couple of thoughts. I brashly said

> I cherrypicked a case where the runtime difference would be tiny

and I appreciate the clarifications - especially that my naive add-one-bytecode 
calculation in my head (the code I pasted has a pretty meaty “analyze” call 
called before it every time which is why I thought I cherry-picked) didn’t 
think about things like byte code inlining or, really, the pile-of-sand 
one-more-bytecode syndrome. So thanks for that!

And my favorite response from Alex:

> If I can make a request, it would be that instead of saying "errors are bad" 
> (which is honestly, not helpful by itself), but to step back and either take 
> a broader approach towards systemic issues

This is so reasonable I’m embarrassed I was a bit glib in my first note. I mean 
it’s not like they are C++ template errors from 1998  (my gold standard for bad 
errors). So let me expand on “bad” a little. 

I think the error messages are “bad” in 3 particular but related ways. I’d be 
happy to expand on these, but the themes are:

1: They are “large” and “far from my code”. This is partly an issue with java 
stack traces, but the intermixing of java and clojure and the presentation of 
clojure names in java name-like things in the stacks is obscuring. The line 
numbers are obscured instead of displayed prominently. And so on.

2: Similarly, they expose internals of the runtime implementation to the user. 
Stacks intertwine java and clojure (CIDER error screen has a toggle to supress 
the stack partially for this). They show java exceptions as clojure errors when 
they aren’t part of a clojure program. etc…

3: These, plus a few other things, mean the error messages are semantically far 
away from the program you write. You stay happily in LISP-y land until you get 
a stack, then you realize you are in java. There are lots of examples of this, 
but take the dumb one I picked - (1 + 1) in a REPL. That shows two concepts 
(java.lang.Long and clojure.lang.IFn) which you don’t deal with in lisp. I’ve 
written quite a lot of clojure in the last 5 months and never typed 
clojure.lang.IFn once. It’s a java error message but I’m a clojure programmer. 
Instant semantic break. And since many error messages are generated at the 
runtime level, which is java / JVM, I experience this semantic break often. Add 
the excellent comments in this thread on macro expand non-locality of error and 
the problem expands.

So if you imagine a guide like “the error should be as close to the error 
causing code as possible and presented in the semantics of the problem” then I 
think I conclude clojure messages are “bad”. (But I love clojure) 

It seems spec, inasmuch as it acts as a sort of optional type system which is 
in the space of the clojure language and produces information in that space, 
would address many of these. 

And as to why I mentioned this: I mean I haven’t had a problem. I just built a 
dual mental model of clojure and the clojure runtime while I learned the 
language and swapped between when an error popped. And I’ve written a lot of 
java (and interpreters and compilers too) so that was easy enough for me to do. 
And I have been hugely productive in your kit. I love clojure! 

But indeed for teaching it’s an obstacle, but also for teaching’s adjacent 
problem, using a language or toolset in a group of programmers of mixed 
abilities, I was thinking errors would be something I’d improve.

But really, it seemed like a place I could lend a shoulder if work was afoot, 
so the comments on the ticketing approach are appreciated and I will dig into 
them.

Thank you for your rapid and thoughtful responses

- Paul


> On Dec 6, 2016, at 2:56 AM, Mars0i <marsh...@logical.net> wrote:
> 
> On Monday, December 5, 2016 at 10:36:59 PM UTC-6, Sean Corfield wrote:
> Several of the Clojure/core folks have said at various times over the years 
> that Clojure is deliberately not optimized for novices, on the grounds that 
> whilst everyone starts out as a novice, most of your time spent with Clojure 
> is beyond that stage (and an optimization for novices can be a 
> de-optimization for everyone else).
> 
> This makes sense for anyone with significant programming experience.  It's a 
> shame, though, that Clojure would be a great language for novice programmers 
> except for the error messages, which are probably a show-stopper for some p 
> teachers thinking of using it for teaching.  I know that there are people 
> involved in Clojure Bridge and other teaching programs, but as a teacher (in 
> another discipline), I personally would have a hard time choosing Clojure 
> over Scheme at this point, if I was teaching an intro programming course.  
> Clojure's probably a better language for later growth though, given its easy 
> integration with Java and Javascriptl.
> 
> I'm not arguing for a 

Re: Errors

[Mars0i]

On Monday, December 5, 2016 at 10:36:59 PM UTC-6, Sean Corfield wrote:
>
> Several of the Clojure/core folks have said at various times over the 
> years that Clojure is deliberately not optimized for novices, on the 
> grounds that whilst everyone starts out as a novice, most of your time 
> spent with Clojure is beyond that stage (and an optimization for novices 
> can be a de-optimization for everyone else).
>

This makes sense for anyone with significant programming experience.  It's 
a shame, though, that Clojure would be a great language for novice 
programmers except for the error messages, which are probably a 
show-stopper for some p teachers thinking of using it for teaching.  I know 
that there are people involved in Clojure Bridge and other teaching 
programs, but as a teacher (in another discipline), I personally would have 
a hard time choosing Clojure over Scheme at this point, if I was teaching 
an intro programming course.  Clojure's probably a better language for 
later growth though, given its easy integration with Java and Javascriptl.

I'm not arguing for a change.  I like run-time performance, too.  Spec 
messages are not any good for novice programmers, either, but I'd guess 
that down the road it will be possible to build a friendly error system on 
top of spec.  Can't do that as easily with JVM stacktraces. :-)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: Errors

[Alex Miller]

On Monday, December 5, 2016 at 7:28:21 PM UTC-6, p...@pwjw.com wrote:
>
> Hi!
>

Hi Paul,
 

>
> Boy I really think you've all done a nice job with Clojure. I've used 
> quite a few environments over the years and clojure + CIDER + etc is a 
> great experience. The immutability and threading are smart. I've been able 
> to finish a hobby project in clojure which I've been mulling for a long 
> time and never found the right environment. Super stuff.
>
> And the error messages are not good.
>

If I can make a request, it would be that instead of saying "errors are 
bad" (which is honestly, not helpful by itself), but to step back and 
either take a broader approach towards systemic issues or to file and work 
tickets for specific cases/messages, so they can actually be fixed.
 

> So I was wondering: Is this a philosophical thing? 
>

There is certainly no philosophy that errors should be bad. I would say 
that the state of things right now is more a side effect of prioritization 
and choices over many years. Rich's focus has typically been on building 
powerful expressive tools vs the beginner experience (I'd recommend 
watching his Design, Composition & Performance talk for more background on 
that). That said, there is no reason not to also improve the experience for 
newer users.
 

> Or is it an effort thing? And if it is an effort thing, is there some sort 
> of plan for what effort to put in? And if so, can I help by closing tickets?
>

My first wish would be that you log tickets for stuff like the one below. 
Providing patches would be a helpful next step. Everything is gated by the 
rate at which Rich looks at tickets though.
 

> Here's one, for instance, which bugs me (using a build of branch master in 
> clojure from github just now)
>
> user=> (+ 1 1)
>
> 2
>
> user=> (1 + 1)
>
> ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn  
> user/eval17 (NO_SOURCE_FILE:10)
>
>
>
>
> OK but what sort of noob would actually type in 1 + 1? (That's a joke. 
> Lots of people would. And I do sometimes when switching between java and 
> clojure) But that same error pops up if you misalign in parenthesis or 
> confuse an argument order or do a variety of other things.
>
> And that error message is terrible. I mean I know why it is there. Clojure 
> needs the first element of a list be the function position and 1 is not a 
> function, it is a long. But you have to squint rather generously at that 
> message to get to the problem. Or just learn what that message "really" 
> means, which seems a bit unfriendly.
>
> And so when I go look inside the source 
>
> user=> (print-stack-trace *e 20)
>
> java.lang.ClassCastException: java.lang.Long cannot be cast to 
> clojure.lang.IFn
>
>  at user$eval9.invokeStatic (NO_SOURCE_FILE:6)
>
> user$eval9.invoke (NO_SOURCE_FILE:6)
>
> clojure.lang.Compiler.eval (Compiler.java:6978)
>
> clojure.lang.Compiler.eval (Compiler.java:6941)
>
>
>
> Compiler.java has
>
> IFn fn = (IFn) fexpr.eval();
>
> return fn.invoke();
>
>
> Which of course throws a class cast exception.
>
>
> But there's so much information right there. Imagine this (in pseudo-code) 
> as
>
>
> Object f = fexpr.eval();
>
> if (f instanceof IFn) return (IFn)f.invoke()
>
> else throw ClojureNotAFunctionEvaluationError "First position in form at 
> line " ... " of environment " ... " is not a function object. You handed me 
> " + fexpr.first() " in form " ... " which has type " fexpr.first().class() 
> " and value " fexpr.first().toString()
>
>
> or whatever (like maybe don't toString values - that's why you'd want a 
> plan. And maybe use a string table so you can internationalize. Again, plan 
> :) )
>

Another thing to keep in mind is that you may be underestimating the full 
set of paths that lead to this particular error and whether the error 
message you are crafting makes sense in all of them. In runtime code, 
constructing better errors changes the size of the generated code, which 
can affect the ability of the JVM to inline code and lead to unexpected 
performance degradations (we've had to pull error message improvements for 
this in the past). I say this not to dissuade us, but just to highlight 
that things are not always as easy as they seem at first.
 

> so I almost want to whack this sort of stuff into a local copy as I hit 
> error messages which bug me, but that seems foolish. And anyway I'm new 
> here.
>

Logging bugs is helpful. A search for dupes is helpful, but not essential. 
I am mostly aware of what's in the system already and 

Re: Errors

[Mikera]

On Tuesday, 6 December 2016 10:47:42 UTC+8, James Reeves wrote:
>
> On 6 December 2016 at 01:28,  wrote:
>>
>> And the error messages are not good.
>>
>> So I was wondering: Is this a philosophical thing? Or is it an effort 
>> thing? And if it is an effort thing, is there some sort of plan for what 
>> effort to put in? And if so, can I help by closing tickets?
>>
>
> This is an issue that's been discussed often.
>
> The fundamental problem is that in a dynamically typed language, good 
> error messages are often at odds with runtime performance. The more checks 
> we add to catch specific scenarios, or to provide more descriptive 
> scenarios, the more performance tends to be impacted.
>
>
Runtime checks are clearly bad for performance, but this kind of thing can 
typically be done at compile time, with no runtime cost.

>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: Errors

[Sean Corfield]

> I cherrypicked a case where the runtime difference would be tiny

 

I wouldn’t be so sure of that. Adding any additional code to the function call 
logic is going to impact almost every single expression in Clojure and that 
“tiny” difference is going to add up pretty fast.

 

As others have noted, runtime performance is a Big Deal™ for Clojure and that 
means that some things are traded off for that speed.

 

Also, as others have noted, this topic comes up repeatedly, probably a handful 
of times a year in some form or other. After using Clojure in production for 
just over five and a half years now, all I can say is: you get used to the 
error messages and you develop an intuition for what most of them mean. Several 
of the Clojure/core folks have said at various times over the years that 
Clojure is deliberately not optimized for novices, on the grounds that whilst 
everyone starts out as a novice, most of your time spent with Clojure is beyond 
that stage (and an optimization for novices can be a de-optimization for 
everyone else).

 

My pet peeve is that clojure.string is not nil-safe. (str nil) produces “” but 
if you pass nil to pretty much any clojure.string function, you get a NPE 
instead. You might think “Hey, it would only be a tiny difference if 
clojure.string functions accepted nil and treated it as an empty string!” … 
until you create a fork of Clojure with that modification and run some 
benchmarks … J

 

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

On 12/5/16, 7:04 PM, "Paul Walker"  wrote:

 

Yeah I understand that tradeoff. I cherrypicked a case where the runtime 
difference would be tiny but others are harder I’m sure.

 

I guess I will go figure out how spec applies to my project.

 

Thanks as always. This group is so responsive. Appreciated.

 

    - Paul

 

On Dec 5, 2016, at 9:46 PM, James Reeves  wrote:

 

On 6 December 2016 at 01:28,  wrote:

And the error messages are not good.

 

So I was wondering: Is this a philosophical thing? Or is it an effort thing? 
And if it is an effort thing, is there some sort of plan for what effort to put 
in? And if so, can I help by closing tickets?

 

This is an issue that's been discussed often.

 

The fundamental problem is that in a dynamically typed language, good error 
messages are often at odds with runtime performance. The more checks we add to 
catch specific scenarios, or to provide more descriptive scenarios, the more 
performance tends to be impacted.

 

However, Clojure 1.9.0 may have a solution to that in the form of specs. We can 
turn on specs selectively at development time, so we get the benefit of 
detailed error messages, while in production we can turn them off for 
performance.

 

- James

 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
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/ANKq6XD1nW8/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/d/optout.

 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.


-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 

Re: Errors

[Paul Walker]

Yeah I understand that tradeoff. I cherrypicked a case where the runtime 
difference would be tiny but others are harder I’m sure.

I guess I will go figure out how spec applies to my project.

Thanks as always. This group is so responsive. Appreciated.

- Paul

> On Dec 5, 2016, at 9:46 PM, James Reeves  wrote:
> 
> On 6 December 2016 at 01:28, > wrote:
> And the error messages are not good.
> 
> So I was wondering: Is this a philosophical thing? Or is it an effort thing? 
> And if it is an effort thing, is there some sort of plan for what effort to 
> put in? And if so, can I help by closing tickets?
> 
> This is an issue that's been discussed often.
> 
> The fundamental problem is that in a dynamically typed language, good error 
> messages are often at odds with runtime performance. The more checks we add 
> to catch specific scenarios, or to provide more descriptive scenarios, the 
> more performance tends to be impacted.
> 
> However, Clojure 1.9.0 may have a solution to that in the form of specs. We 
> can turn on specs selectively at development time, so we get the benefit of 
> detailed error messages, while in production we can turn them off for 
> performance.
> 
> - James
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 
> 
> --- 
> 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/ANKq6XD1nW8/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/d/optout 
> .

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: Errors

[James Reeves]

On 6 December 2016 at 01:28,  wrote:
>
> And the error messages are not good.
>
> So I was wondering: Is this a philosophical thing? Or is it an effort
> thing? And if it is an effort thing, is there some sort of plan for what
> effort to put in? And if so, can I help by closing tickets?
>

This is an issue that's been discussed often.

The fundamental problem is that in a dynamically typed language, good error
messages are often at odds with runtime performance. The more checks we add
to catch specific scenarios, or to provide more descriptive scenarios, the
more performance tends to be impacted.

However, Clojure 1.9.0 may have a solution to that in the form of specs. We
can turn on specs selectively at development time, so we get the benefit of
detailed error messages, while in production we can turn them off for
performance.

- James

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
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/d/optout.

Re: Errors

[Gary Trakhman]

I think it has been rehashed often and core is very conservative about
changes, but the current latest and greatest for improving many kinds of
errors is going to be clojure.spec, which runs parallel to the actual
execution path, so as not to effect things like performance or old code
that depends on the specific weird behaviors in core.
http://clojure.org/guides/spec

On Mon, Dec 5, 2016 at 8:28 PM <p...@pwjw.com> wrote:

> Hi!
>
> Boy I really think you've all done a nice job with Clojure. I've used
> quite a few environments over the years and clojure + CIDER + etc is a
> great experience. The immutability and threading are smart. I've been able
> to finish a hobby project in clojure which I've been mulling for a long
> time and never found the right environment. Super stuff.
>
> And the error messages are not good.
>
> So I was wondering: Is this a philosophical thing? Or is it an effort
> thing? And if it is an effort thing, is there some sort of plan for what
> effort to put in? And if so, can I help by closing tickets?
>
> Here's one, for instance, which bugs me (using a build of branch master in
> clojure from github just now)
>
> user=> (+ 1 1)
>
> 2
>
> user=> (1 + 1)
>
> ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn
> user/eval17 (NO_SOURCE_FILE:10)
>
>
>
>
> OK but what sort of noob would actually type in 1 + 1? (That's a joke.
> Lots of people would. And I do sometimes when switching between java and
> clojure) But that same error pops up if you misalign in parenthesis or
> confuse an argument order or do a variety of other things.
>
> And that error message is terrible. I mean I know why it is there. Clojure
> needs the first element of a list be the function position and 1 is not a
> function, it is a long. But you have to squint rather generously at that
> message to get to the problem. Or just learn what that message "really"
> means, which seems a bit unfriendly.
>
> And so when I go look inside the source
>
> user=> (print-stack-trace *e 20)
>
> java.lang.ClassCastException: java.lang.Long cannot be cast to
> clojure.lang.IFn
>
>  at user$eval9.invokeStatic (NO_SOURCE_FILE:6)
>
> user$eval9.invoke (NO_SOURCE_FILE:6)
>
> clojure.lang.Compiler.eval (Compiler.java:6978)
>
> clojure.lang.Compiler.eval (Compiler.java:6941)
>
>
>
> Compiler.java has
>
> IFn fn = (IFn) fexpr.eval();
>
> return fn.invoke();
>
>
> Which of course throws a class cast exception.
>
>
> But there's so much information right there. Imagine this (in pseudo-code)
> as
>
>
> Object f = fexpr.eval();
>
> if (f instanceof IFn) return (IFn)f.invoke()
>
> else throw ClojureNotAFunctionEvaluationError "First position in form at
> line " ... " of environment " ... " is not a function object. You handed me
> " + fexpr.first() " in form " ... " which has type " fexpr.first().class()
> " and value " fexpr.first().toString()
>
>
> or whatever (like maybe don't toString values - that's why you'd want a
> plan. And maybe use a string table so you can internationalize. Again, plan
> :) )
>
>
> so I almost want to whack this sort of stuff into a local copy as I hit
> error messages which bug me, but that seems foolish. And anyway I'm new
> here.
>
>
> Sorry if I have accidentally stepped into some sort of landmine or if this
> has been rehashed a million times.
>
>
> But I figured, in the spirit of being willing to help if there's help to
> be applied, I would ask if there's some sort of thinking on this topic for
> 1.9.1 or 1.10 or something?
>
>
> Thanks
>
>
>   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/d/optout.
>

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

Errors

[paul]

Hi!

Boy I really think you've all done a nice job with Clojure. I've used quite 
a few environments over the years and clojure + CIDER + etc is a great 
experience. The immutability and threading are smart. I've been able to 
finish a hobby project in clojure which I've been mulling for a long time 
and never found the right environment. Super stuff.

And the error messages are not good.

So I was wondering: Is this a philosophical thing? Or is it an effort 
thing? And if it is an effort thing, is there some sort of plan for what 
effort to put in? And if so, can I help by closing tickets?

Here's one, for instance, which bugs me (using a build of branch master in 
clojure from github just now)

user=> (+ 1 1)

2

user=> (1 + 1)

ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn  
user/eval17 (NO_SOURCE_FILE:10)




OK but what sort of noob would actually type in 1 + 1? (That's a joke. Lots 
of people would. And I do sometimes when switching between java and 
clojure) But that same error pops up if you misalign in parenthesis or 
confuse an argument order or do a variety of other things.

And that error message is terrible. I mean I know why it is there. Clojure 
needs the first element of a list be the function position and 1 is not a 
function, it is a long. But you have to squint rather generously at that 
message to get to the problem. Or just learn what that message "really" 
means, which seems a bit unfriendly.

And so when I go look inside the source 

user=> (print-stack-trace *e 20)

java.lang.ClassCastException: java.lang.Long cannot be cast to 
clojure.lang.IFn

 at user$eval9.invokeStatic (NO_SOURCE_FILE:6)

user$eval9.invoke (NO_SOURCE_FILE:6)

clojure.lang.Compiler.eval (Compiler.java:6978)

clojure.lang.Compiler.eval (Compiler.java:6941)



Compiler.java has

IFn fn = (IFn) fexpr.eval();

return fn.invoke();


Which of course throws a class cast exception.


But there's so much information right there. Imagine this (in pseudo-code) 
as


Object f = fexpr.eval();

if (f instanceof IFn) return (IFn)f.invoke()

else throw ClojureNotAFunctionEvaluationError "First position in form at 
line " ... " of environment " ... " is not a function object. You handed me 
" + fexpr.first() " in form " ... " which has type " fexpr.first().class() 
" and value " fexpr.first().toString()


or whatever (like maybe don't toString values - that's why you'd want a 
plan. And maybe use a string table so you can internationalize. Again, plan 
:) )


so I almost want to whack this sort of stuff into a local copy as I hit 
error messages which bug me, but that seems foolish. And anyway I'm new 
here.


Sorry if I have accidentally stepped into some sort of landmine or if this 
has been rehashed a million times.


But I figured, in the spirit of being willing to help if there's help to be 
applied, I would ask if there's some sort of thinking on this topic for 
1.9.1 or 1.10 or something?


Thanks


  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/d/optout.

Re: Common runtime errors in clojure

[kovas boguta]

Compiling a list of these common errors is a great idea (particularly if
then turned into some kind of How-To guide for interpreting errors)

I think anyone who learns Clojure learns to subconsciously internalize
these errors and what they mean. However, for somewhat just starting out
this is pretty hard.

Another very common one:
(first 1) ; => IllegalArgumentException Don't know how to create ISeq from
...

Comes up in many circumstances, some of the most confusing are when it
happens in an ns form or other macro.

In general beginning Clojure users don't know what ISeq, IFn,
clojure.lang.Numbers.ops etc are. I'd rather see error messages like

"Argument to 'first' cannot be coerced to a sequence (ISeq)"
or
"Expression in function call position '"asdf"' does not implement function
interface (IFn)"

I have no idea if theres technical reasons that make this hard, but haven't
some resource to let users translate the current exception messages into
what they mean in terms of Clojure concepts that would be very useful I
think.






On Sat, Feb 6, 2016 at 4:37 PM, Paulo César Cuneo <
cuneo.paulo.ce...@gmail.com> wrote:

> Hi group,
>  I was googling for enumeration of commons runtime errors in clojure,
> but i couldnt find anything much.
> Stuart Sierra  has a couple of blog post on do/donts in clojure, but is
> not an exhaustive listing.
>
> I understand that using interop will inherit most of the runtime errors
> you can create in java,
>  but even when staying inside the clojure realm there are some common
> cases of errors.
>
> For example,
>
> 1 - applying type specific ops on wrong type :
> ;; math ops.
>
> (+ 1 nil)  ; => NullPointerException.
> (+ 1 "")   ; => ClassCastException.
>
> 2 - call on non-callable:
>
> (map nil [1 2 3]) ; => NullPointerException.
> ("asdf" 2)   ; => ClassCastException.
>
> 3 - cant destruct
>
> (let [[f s] 1] f) ; => UnsupportedOperationException nth
>
>
> I guess most of errors are due to bad plumbing.
> Do you have any insights on these or more examples?
>
> Bye and Thanks.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To 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/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Common runtime errors in clojure

[Paulo César Cuneo]

Hi group, 
 I was googling for enumeration of commons runtime errors in clojure, 
but i couldnt find anything much. 
Stuart Sierra  has a couple of blog post on do/donts in clojure, but is not 
an exhaustive listing.

I understand that using interop will inherit most of the runtime errors you 
can create in java,
 but even when staying inside the clojure realm there are some common cases 
of errors.

For example, 

1 - applying type specific ops on wrong type :
;; math ops.

(+ 1 nil)  ; => NullPointerException.
(+ 1 "")   ; => ClassCastException.

2 - call on non-callable:

(map nil [1 2 3]) ; => NullPointerException. 
("asdf" 2)   ; => ClassCastException. 

3 - cant destruct

(let [[f s] 1] f) ; => UnsupportedOperationException nth


I guess most of errors are due to bad plumbing.
Do you have any insights on these or more examples?

Bye and Thanks.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To 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/d/optout.

Re: Common runtime errors in clojure

[Andy Fingerhut]

I don't know if it works well with Clojure 1.8 or not, but dynalint is
intended to give clearer error messages for some things like this, at the
cost of some performance.

https://github.com/frenchy64/dynalint

I am not sure how beginner-friendly the install instructions are, but you
can try them out and see.

Andy

On Sat, Feb 6, 2016 at 2:26 PM, kovas boguta <kovas.bog...@gmail.com> wrote:

> Compiling a list of these common errors is a great idea (particularly if
> then turned into some kind of How-To guide for interpreting errors)
>
> I think anyone who learns Clojure learns to subconsciously internalize
> these errors and what they mean. However, for somewhat just starting out
> this is pretty hard.
>
> Another very common one:
> (first 1) ; => IllegalArgumentException Don't know how to create ISeq from
> ...
>
> Comes up in many circumstances, some of the most confusing are when it
> happens in an ns form or other macro.
>
> In general beginning Clojure users don't know what ISeq, IFn,
> clojure.lang.Numbers.ops etc are. I'd rather see error messages like
>
> "Argument to 'first' cannot be coerced to a sequence (ISeq)"
> or
> "Expression in function call position '"asdf"' does not implement function
> interface (IFn)"
>
> I have no idea if theres technical reasons that make this hard, but
> haven't some resource to let users translate the current exception messages
> into what they mean in terms of Clojure concepts that would be very useful
> I think.
>
>
>
>
>
>
> On Sat, Feb 6, 2016 at 4:37 PM, Paulo César Cuneo <
> cuneo.paulo.ce...@gmail.com> wrote:
>
>> Hi group,
>>  I was googling for enumeration of commons runtime errors in clojure,
>> but i couldnt find anything much.
>> Stuart Sierra  has a couple of blog post on do/donts in clojure, but is
>> not an exhaustive listing.
>>
>> I understand that using interop will inherit most of the runtime errors
>> you can create in java,
>>  but even when staying inside the clojure realm there are some common
>> cases of errors.
>>
>> For example,
>>
>> 1 - applying type specific ops on wrong type :
>> ;; math ops.
>>
>> (+ 1 nil)  ; => NullPointerException.
>> (+ 1 "")   ; => ClassCastException.
>>
>> 2 - call on non-callable:
>>
>> (map nil [1 2 3]) ; => NullPointerException.
>> ("asdf" 2)   ; => ClassCastException.
>>
>> 3 - cant destruct
>>
>> (let [[f s] 1] f) ; => UnsupportedOperationException nth
>>
>>
>> I guess most of errors are due to bad plumbing.
>> Do you have any insights on these or more examples?
>>
>> Bye and Thanks.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To 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/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: Manifold streams/deferreds raising errors downstream of a sink

[Zach Tellman]

Hi Andy,

To give you some context on this, `put!` will return true if the thing 
directly downstream accepts the value (in this case, the stream).  The fact 
that the callback in `consume` fails is between the stream and the 
callback, and is not propagated all the way back (though the exception will 
cancel the `consume`, which will cause the stream to close).  The approach 
described by Atamert is a reasonable one to get the desired result.

Zach

On Sunday, August 9, 2015 at 9:13:30 PM UTC-7, Andy Chambers wrote:

 Hey All,

 I'm trying to build a library that exposes manifold streams for data 
 producing applications. The intention
 would be for these apps to s/put! to a sink stream returned by the 
 producer function. However, I need to
 take the value that is put in and pipe it into some other function before 
 I know whether there is an error
 and if there is an error, I'd like to propagate it back to the caller.

 I understand that the value returned by put! is a deferred, and how to set 
 the error state of a deferred but I
 don't understand how I can arrange for the deferred to be manipulated 
 downstream of where it has been
 taken off the stream.

 (defn producer []
   (let [in (s/stream)]

 (s/consume (fn [msg]
  (d/future
(prn oops, going to error now)
(throw (Exception. (str msg) in)
 
 in))

 @(s/put! (producer) 42)

 As written, you get a success response even though an exception was 
 triggered by the function that consumes
 the in stream. Is it possible to re-write this so that the exception 
 bubbles up to where the put! is deref'd?

 Cheers,
 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/d/optout.

Re: Manifold streams/deferreds raising errors downstream of a sink

[Atamert Ölçgen]

Hi Andy,

I would provide a function that wraps put!. It would still return a
deferred, but not the result of put!. It would create a deferred,
representing the result of the computation and pass it down the stream
together with the input. Consumers would set its value once the computation
is done.

I am actually using this technique in a couple of projects and very happy
with it.


On Mon, Aug 10, 2015 at 7:13 AM, Andy Chambers achambers.h...@gmail.com
wrote:

 Hey All,

 I'm trying to build a library that exposes manifold streams for data
 producing applications. The intention
 would be for these apps to s/put! to a sink stream returned by the
 producer function. However, I need to
 take the value that is put in and pipe it into some other function before
 I know whether there is an error
 and if there is an error, I'd like to propagate it back to the caller.

 I understand that the value returned by put! is a deferred, and how to set
 the error state of a deferred but I
 don't understand how I can arrange for the deferred to be manipulated
 downstream of where it has been
 taken off the stream.

 (defn producer []
   (let [in (s/stream)]

 (s/consume (fn [msg]
  (d/future
(prn oops, going to error now)
(throw (Exception. (str msg) in)

 in))

 @(s/put! (producer) 42)

 As written, you get a success response even though an exception was
 triggered by the function that consumes
 the in stream. Is it possible to re-write this so that the exception
 bubbles up to where the put! is deref'd?

 Cheers,
 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/d/optout.




-- 
Kind Regards,
Atamert Ölçgen

◻◼◻
◻◻◼
◼◼◼

www.muhuk.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://groups.google.com/d/optout.

Manifold streams/deferreds raising errors downstream of a sink

[Andy Chambers]

Hey All,

I'm trying to build a library that exposes manifold streams for data 
producing applications. The intention
would be for these apps to s/put! to a sink stream returned by the producer 
function. However, I need to
take the value that is put in and pipe it into some other function before I 
know whether there is an error
and if there is an error, I'd like to propagate it back to the caller.

I understand that the value returned by put! is a deferred, and how to set 
the error state of a deferred but I
don't understand how I can arrange for the deferred to be manipulated 
downstream of where it has been
taken off the stream.

(defn producer []
  (let [in (s/stream)]

(s/consume (fn [msg]
 (d/future
   (prn oops, going to error now)
   (throw (Exception. (str msg) in)

in))
   
@(s/put! (producer) 42)

As written, you get a success response even though an exception was 
triggered by the function that consumes
the in stream. Is it possible to re-write this so that the exception 
bubbles up to where the put! is deref'd?

Cheers,
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/d/optout.

Re: Complete lack of helpful compilation errors with :gen-class

[James Elliott]

Indeed, I visited the page you cite while trying to pin down this problem. 
However, I am fairly certain that in my case it is a weird side effect, not 
a root cause: I get that message when compiling my Clojure file if I try to 
call a function which is defined later in the file. If I move the function 
definition up before the point where I was calling it, everything compiles 
fine, and no linkage error. No library changes in between the two tests. 
And this only happens when my Clojure file is subclassing a Java object. 
Very, very strange...

On Monday, August 3, 2015 at 12:27:38 AM UTC-5, Mars0i wrote:

 I don't have anything helpful to say, but:  I've often gotten a useful 
 stacktrace from compile-time errors using 'lein compile' with :gen-class.  
 Not always.  Sometimes I have to use the guess-and-comment-out method.  So 
 I think that whatever's happening is not just an issue with compilation of 
 gen-class.  Maybe an issue involving libraries?  This page 
 http://examples.javacodegeeks.com/java-basics/exceptions/java-lang-unsatisfiedlinkerror-how-to-handle-unsatisfied-link-error/
  
 is consistent with that hypothesis.


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: Complete lack of helpful compilation errors with :gen-class

[Alex Miller]

If you can create a small, reproducible test case (that does not require 
Leiningen), please file a ticket.

On Monday, August 3, 2015 at 9:27:47 AM UTC-5, James Elliott wrote:

 Indeed, I visited the page you cite while trying to pin down this problem. 
 However, I am fairly certain that in my case it is a weird side effect, not 
 a root cause: I get that message when compiling my Clojure file if I try to 
 call a function which is defined later in the file. If I move the function 
 definition up before the point where I was calling it, everything compiles 
 fine, and no linkage error. No library changes in between the two tests. 
 And this only happens when my Clojure file is subclassing a Java object. 
 Very, very strange...

 On Monday, August 3, 2015 at 12:27:38 AM UTC-5, Mars0i wrote:

 I don't have anything helpful to say, but:  I've often gotten a useful 
 stacktrace from compile-time errors using 'lein compile' with :gen-class.  
 Not always.  Sometimes I have to use the guess-and-comment-out method.  So 
 I think that whatever's happening is not just an issue with compilation of 
 gen-class.  Maybe an issue involving libraries?  This page 
 http://examples.javacodegeeks.com/java-basics/exceptions/java-lang-unsatisfiedlinkerror-how-to-handle-unsatisfied-link-error/
  
 is consistent with that hypothesis.



-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: Complete lack of helpful compilation errors with :gen-class

[James Elliott]

Wow, that is a challenge, Alex! I would have no idea how to even compile a 
project without Leiningen. If I ever am not using 200% of my free time working 
on these projects, I may try to research that. I am afraid it may be some time, 
though. I was just hoping this was a known issue with know solutions.

Thanks,

  -James

 On Aug 3, 2015, at 09:41, Alex Miller a...@puredanger.com wrote:
 
 If you can create a small, reproducible test case (that does not require 
 Leiningen), please file a ticket.
 
 On Monday, August 3, 2015 at 9:27:47 AM UTC-5, James Elliott wrote:
 Indeed, I visited the page you cite while trying to pin down this problem. 
 However, I am fairly certain that in my case it is a weird side effect, not a 
 root cause: I get that message when compiling my Clojure file if I try to 
 call a function which is defined later in the file. If I move the function 
 definition up before the point where I was calling it, everything compiles 
 fine, and no linkage error. No library changes in between the two tests. And 
 this only happens when my Clojure file is subclassing a Java object. Very, 
 very strange...
 
 On Monday, August 3, 2015 at 12:27:38 AM UTC-5, Mars0i wrote:
 I don't have anything helpful to say, but:  I've often gotten a useful 
 stacktrace from compile-time errors using 'lein compile' with :gen-class.  
 Not always.  Sometimes I have to use the guess-and-comment-out method.  So I 
 think that whatever's happening is not just an issue with compilation of 
 gen-class.  Maybe an issue involving libraries?  This page 
 http://examples.javacodegeeks.com/java-basics/exceptions/java-lang-unsatisfiedlinkerror-how-to-handle-unsatisfied-link-error/
  is consistent with that hypothesis.
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en 
 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/yONboCAt-UA/unsubscribe 
 https://groups.google.com/d/topic/clojure/yONboCAt-UA/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 clojure+unsubscr...@googlegroups.com 
 mailto:clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: Complete lack of helpful compilation errors with :gen-class

[Mars0i]

On Monday, August 3, 2015 at 9:27:47 AM UTC-5, James Elliott wrote:

 Indeed, I visited the page you cite while trying to pin down this problem. 
 However, I am fairly certain that in my case it is a weird side effect, not 
 a root cause: I get that message when compiling my Clojure file if I try to 
 call a function which is defined later in the file. If I move the function 
 definition up before the point where I was calling it, everything compiles 
 fine, and no linkage error. No library 


Ah--if that's the problem, it sounds familiar.  Try doing 'lein clean' 
before 'lein compile' and see whether you get the same error.  That's 
assuming you have namespaces/classes listed after :aot in project.clj.  (If 
not, then I don't think that 'lein compile' is actually doing anything.)

You probably know this, but: When using Java classes, whether defined by 
gen-class or one of the other four ways to define classes (defrecord, 
deftype, proxy, reify), Clojure is very persnickety about compilation 
order.   A class has to be compiled before you can compile something that 
explicitly references it.  (No cyclic dependencies between explicit 
references to classes.)
 

 changes in between the two tests. And this only happens when my Clojure 
 file is subclassing a Java object. Very, very strange...

 On Monday, August 3, 2015 at 12:27:38 AM UTC-5, Mars0i wrote:

 I don't have anything helpful to say, but:  I've often gotten a useful 
 stacktrace from compile-time errors using 'lein compile' with :gen-class.  
 Not always.  Sometimes I have to use the guess-and-comment-out method.  So 
 I think that whatever's happening is not just an issue with compilation of 
 gen-class.  Maybe an issue involving libraries?  This page 
 http://examples.javacodegeeks.com/java-basics/exceptions/java-lang-unsatisfiedlinkerror-how-to-handle-unsatisfied-link-error/
  
 is consistent with that hypothesis.



-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: Complete lack of helpful compilation errors with :gen-class

[Mars0i]

On Monday, August 3, 2015 at 9:47:10 AM UTC-5, James Elliott wrote:

 Wow, that is a challenge, Alex! I would have no idea how to even compile a 
 project without Leiningen. If I ever am not using 200% 


I think you can do this with compile 
https://clojuredocs.org/clojure.core/compile and then java -cp ... .  
I've never tried it.
 

 of my free time working on these projects, I may try to research that. I 
 am afraid it may be some time, though. I was just hoping this was a known 
 issue with know solutions.

 Thanks,

   -James

 On Aug 3, 2015, at 09:41, Alex Miller al...@puredanger.com javascript: 
 wrote:

 If you can create a small, reproducible test case (that does not require 
 Leiningen), please file a ticket.

 On Monday, August 3, 2015 at 9:27:47 AM UTC-5, James Elliott wrote:

 Indeed, I visited the page you cite while trying to pin down this 
 problem. However, I am fairly certain that in my case it is a weird side 
 effect, not a root cause: I get that message when compiling my Clojure file 
 if I try to call a function which is defined later in the file. If I move 
 the function definition up before the point where I was calling it, 
 everything compiles fine, and no linkage error. No library changes in 
 between the two tests. And this only happens when my Clojure file is 
 subclassing a Java object. Very, very strange...

 On Monday, August 3, 2015 at 12:27:38 AM UTC-5, Mars0i wrote:

 I don't have anything helpful to say, but:  I've often gotten a useful 
 stacktrace from compile-time errors using 'lein compile' with :gen-class.  
 Not always.  Sometimes I have to use the guess-and-comment-out method.  So 
 I think that whatever's happening is not just an issue with compilation of 
 gen-class.  Maybe an issue involving libraries?  This page 
 http://examples.javacodegeeks.com/java-basics/exceptions/java-lang-unsatisfiedlinkerror-how-to-handle-unsatisfied-link-error/
  
 is consistent with that hypothesis.


 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.com javascript:
 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com javascript:
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to a topic in the 
 Google Groups Clojure group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/clojure/yONboCAt-UA/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 clojure+u...@googlegroups.com javascript:.
 For more options, visit https://groups.google.com/d/optout.




-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: Complete lack of helpful compilation errors with :gen-class

[James Elliott]

Yay, this is the kind of insight I was hoping for! ^_^

On Monday, August 3, 2015 at 9:49:17 AM UTC-5, Mars0i wrote:

 Ah--if that's the problem, it sounds familiar.  Try doing 'lein clean' 
 before 'lein compile' and see whether you get the same error.  That's 
 assuming you have namespaces/classes listed after :aot in project.clj.  (If 
 not, then I don't think that 'lein compile' is actually doing anything.)


Excellent point, I completely forgot about that (something about spending 
fifty or so hours in the previous three days cranking out code). The only 
time compilation would actually happen, given my project configuration, 
would be in creating the überjar, because that is the only profile which 
has :aot turned on. So I should have not been surprised that my lein 
compile did nothing.
 

 You probably know this, but: When using Java classes, whether defined by 
 gen-class or one of the other four ways to define classes (defrecord, 
 deftype, proxy, reify), Clojure is very persnickety about compilation 
 order.   A class has to be compiled before you can compile something that 
 explicitly references it.  (No cyclic dependencies between explicit 
 references to classes.)


I had not thought in precisely those terms before, but I am definitely used 
to struggling with cyclic dependencies and the Clojure compiler, so I am 
fairly confident that I did not have this issue.

I think, though, that between what you just reminded me about when 
compilation (doesn't) happen, and what Alex is suggesting about running the 
compiler directly, I likely have a workaround. When I get in this state, I 
will try running the compiler directly on just the suspect Clojure file and 
see what it says.

I now strongly suspect the problem is that somewhere in the bowels of 
Leiningen, this output is being discarded.

Thanks,

  -James

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
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/d/optout.

Re: Complete lack of helpful compilation errors with :gen-class

[Alex Miller]

You can just use the clojure.core/compile function to compile. There is a 
simple example at http://clojure.org/compilation.  

I have not seen or experienced a linkage error like this before and I'm not 
aware of any ticket like this. Generally a linkage error indicates you are 
seeing the wrong version of a class loaded by a different classloader.


On Monday, August 3, 2015 at 9:47:10 AM UTC-5, James Elliott wrote:

 Wow, that is a challenge, Alex! I would have no idea how to even compile a 
 project without Leiningen. If I ever am not using 200% of my free time 
 working on these projects, I may try to research that. I am afraid it may 
 be some time, though. I was just hoping this was a known issue with know 
 solutions.

 Thanks,

   -James

 On Aug 3, 2015, at 09:41, Alex Miller al...@puredanger.com javascript: 
 wrote:

 If you can create a small, reproducible test case (that does not require 
 Leiningen), please file a ticket.

 On Monday, August 3, 2015 at 9:27:47 AM UTC-5, James Elliott wrote:

 Indeed, I visited the page you cite while trying to pin down this 
 problem. However, I am fairly certain that in my case it is a weird side 
 effect, not a root cause: I get that message when compiling my Clojure file 
 if I try to call a function which is defined later in the file. If I move 
 the function definition up before the point where I was calling it, 
 everything compiles fine, and no linkage error. No library changes in 
 between the two tests. And this only happens when my Clojure file is 
 subclassing a Java object. Very, very strange...

 On Monday, August 3, 2015 at 12:27:38 AM UTC-5, Mars0i wrote:

 I don't have anything helpful to say, but:  I've often gotten a useful 
 stacktrace from compile-time errors using 'lein compile' with :gen-class.  
 Not always.  Sometimes I have to use the guess-and-comment-out method.  So 
 I think that whatever's happening is not just an issue with compilation of 
 gen-class.  Maybe an issue involving libraries?  This page 
 http://examples.javacodegeeks.com/java-basics/exceptions/java-lang-unsatisfiedlinkerror-how-to-handle-unsatisfied-link-error/
  
 is consistent with that hypothesis.


 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.com javascript:
 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com javascript:
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to a topic in the 
 Google Groups Clojure group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/clojure/yONboCAt-UA/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 clojure+u...@googlegroups.com javascript:.
 For more options, visit https://groups.google.com/d/optout.




-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: Complete lack of helpful compilation errors with :gen-class

[James Elliott]

Thanks, Alex, I will give this a try the next time I run into this. Given a 
little distance from the problem, and the insights that you and Mars0i have 
been sharing, I have a clearer picture of what was going on at compile 
time. I suspect the problem is something along these lines: Leiningen 
invokes the compiler on the file that is supposed to create my class, and 
it fails because of my incorrect ordering of function invocation and 
definition. For reasons unknown, but which if I can pin down better I will 
open as an issue with Leiningen, the output from this failed compilation is 
lost. Then when something tries tor refer to the class which was supposed 
to have been compiled and fails, the linkage error happens.

But now that you have pointed me at a way to just invoke the compiler 
directly on my problem source file, I bet I will be able to see the 
compilation errors when I do that, which will enable me to fix them without 
trial and error. 

Indeed, I just tested that by commenting out one of the functions in my 
source, confirming that Leiningen gives me the cryptic linkage error, and 
tried a manual compile from the REPL, and was given this completely helpful 
compilation error:
 

afterglow.max.core= (compile 'afterglow.max.Metro)

CompilerException java.lang.RuntimeException: Unable to resolve symbol: 
set-bar in this context, compiling:(afterglow/max/Metro.clj:121:7) 


So the next time I screw up, I will be able to figure out how.

Thanks, everyone! Perhaps I should open a Leiningen issue about this now.

Cheers,

  -James

On Monday, August 3, 2015 at 9:59:57 AM UTC-5, Alex Miller wrote:

 You can just use the clojure.core/compile function to compile. There is a 
 simple example at http://clojure.org/compilation.  

 I have not seen or experienced a linkage error like this before and I'm 
 not aware of any ticket like this. Generally a linkage error indicates you 
 are seeing the wrong version of a class loaded by a different classloader.


 On Monday, August 3, 2015 at 9:47:10 AM UTC-5, James Elliott wrote:

 Wow, that is a challenge, Alex! I would have no idea how to even compile 
 a project without Leiningen. If I ever am not using 200% of my free time 
 working on these projects, I may try to research that. I am afraid it may 
 be some time, though. I was just hoping this was a known issue with know 
 solutions.

 Thanks,

   -James

 On Aug 3, 2015, at 09:41, Alex Miller al...@puredanger.com wrote:

 If you can create a small, reproducible test case (that does not require 
 Leiningen), please file a ticket.

 On Monday, August 3, 2015 at 9:27:47 AM UTC-5, James Elliott wrote:

 Indeed, I visited the page you cite while trying to pin down this 
 problem. However, I am fairly certain that in my case it is a weird side 
 effect, not a root cause: I get that message when compiling my Clojure file 
 if I try to call a function which is defined later in the file. If I move 
 the function definition up before the point where I was calling it, 
 everything compiles fine, and no linkage error. No library changes in 
 between the two tests. And this only happens when my Clojure file is 
 subclassing a Java object. Very, very strange...

 On Monday, August 3, 2015 at 12:27:38 AM UTC-5, Mars0i wrote:

 I don't have anything helpful to say, but:  I've often gotten a useful 
 stacktrace from compile-time errors using 'lein compile' with :gen-class.  
 Not always.  Sometimes I have to use the guess-and-comment-out method.  So 
 I think that whatever's happening is not just an issue with compilation of 
 gen-class.  Maybe an issue involving libraries?  This page 
 http://examples.javacodegeeks.com/java-basics/exceptions/java-lang-unsatisfiedlinkerror-how-to-handle-unsatisfied-link-error/
  
 is consistent with that hypothesis.


 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.com
 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to a topic in the 
 Google Groups Clojure group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/clojure/yONboCAt-UA/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 clojure+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.




-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com

Complete lack of helpful compilation errors with :gen-class

[James Elliott]

I don't know if this is an issue with the compiler in general, with 
Leiningen more specifically, or something I am doing wrong in trying to use 
them, but I have wasted many hours over the last couple weeks while working 
on afterglow-max https://github.com/brunchboy/afterglow-max#afterglow-max due 
to the fact that when I am compiling a Clojure source file which extends a 
Java class, any little mistake I make while coding gives me the following 
opaque output when I try to compile, rather than the helpful message 
telling me where the problem occurred that I am used to:

lein -U uberjar

Compiling afterglow.max.core

Compiling afterglow.max.Cue

Compiling afterglow.max.Eval

Compiling afterglow.max.init

Compiling afterglow.max.Metro


Exception: java.lang.UnsatisfiedLinkError thrown from the 
UncaughtExceptionHandler in thread main

Compilation failed: Subprocess failed

Uberjar aborting because jar failed: Compilation failed: Subprocess failed

Error encountered performing task 'uberjar' with profile(s): 
'base,system,user,provided,dev,update'

Uberjar aborting because jar failed: Compilation failed: Subprocess failed

Trying to just do a lein compile seems to silently do nothing at all when 
it is in this state. In this case it was because I had called a function 
which was not defined until later in the file. Normally super easy to 
figure out from the compiler error messages, of course!

So I end up having to tediously try commenting out sections of my code 
until I can get it compiling again and then narrow down the problem. I had 
developed a style of making a tiny addition then rebuilding the uberjar to 
avoid this problem (and this is made worse by the fact that the compilation 
process creates futures at some point, due to one of the libraries 
involved, so compilation delays for an extra sixty seconds each time, 
waiting for Clojure's agent thread pool to shut itself down! I can't 
believe that *still* does not use daemon threads)... But this time I was 
writing the final object, which was very similar to others I had already 
written, and forged through until the end until trying to compile, then had 
to spend hours figuring out my simple stupid error.

Has anyone else seen a problem like this? Don't get me wrong, I still think 
Clojure is the best thing going, but it could be better without this 
problem. Is there anything I can do to avoid it, beyond what I already was?

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: Complete lack of helpful compilation errors with :gen-class

[Mars0i]

I don't have anything helpful to say, but:  I've often gotten a useful 
stacktrace from compile-time errors using 'lein compile' with :gen-class.  
Not always.  Sometimes I have to use the guess-and-comment-out method.  So 
I think that whatever's happening is not just an issue with compilation of 
gen-class.  Maybe an issue involving libraries?  This page 
http://examples.javacodegeeks.com/java-basics/exceptions/java-lang-unsatisfiedlinkerror-how-to-handle-unsatisfied-link-error/
 
is consistent with that hypothesis.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: Testing macros that throw errors at compile time?

[Scott Rabin]

Thanks Ben  Michael, that works!

On Thursday, January 22, 2015 at 5:08:31 PM UTC-8, Michael Blume wrote:

 macroexpand-1 is a good start, I'd also recommend using the (is (thrown? 
 ...)) special form, so

 (is (thrown? IllegalArgumentException (macroexpend-1 '(my-macro 
 (ill-formed-arguments ...)

 On Thu Jan 22 2015 at 5:05:36 PM Ben Wolfson wol...@gmail.com 
 javascript: wrote:

 (try (macroexpand-1 '(my-macro (ill-formed-arguments ...)))
   false ;; shouldn't get here
   (catch Exception _ true)) ;; whole expression should be true

 As long as you know that the *right* exception is being thrown.

 On Thu, Jan 22, 2015 at 4:41 PM, Scott Rabin scott...@gmail.com 
 javascript: wrote:

 We have a few macros in my employer's codebase that throw compile-time 
 errors when you've given them invalid configurations, and have generally 
 simply tested the result of these macros and not necessarily the direct 
 expansion of said macros. What we would like to do is *test* that the 
 macro blows up; but unfortunately, since this happens before tests are run, 
 the result is that the compiler just complains at you instead of telling 
 you that a specific test failed.

 Is there a decent way to test for thrown exceptions from macros other 
 than writing a few cases and saying well, if the tests didn't even run, 
 it's not right!?

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




 -- 
 Ben Wolfson
 Human kind has used its intelligence to vary the flavour of drinks, 
 which may be sweet, aromatic, fermented or spirit-based. ... Family and 
 social life also offer numerous other occasions to consume drinks for 
 pleasure. [Larousse, Drink entry]

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



-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: Testing macros that throw errors at compile time?

[Ben Wolfson]

(try (macroexpand-1 '(my-macro (ill-formed-arguments ...)))
  false ;; shouldn't get here
  (catch Exception _ true)) ;; whole expression should be true

As long as you know that the *right* exception is being thrown.

On Thu, Jan 22, 2015 at 4:41 PM, Scott Rabin scottra...@gmail.com wrote:

 We have a few macros in my employer's codebase that throw compile-time
 errors when you've given them invalid configurations, and have generally
 simply tested the result of these macros and not necessarily the direct
 expansion of said macros. What we would like to do is *test* that the
 macro blows up; but unfortunately, since this happens before tests are run,
 the result is that the compiler just complains at you instead of telling
 you that a specific test failed.

 Is there a decent way to test for thrown exceptions from macros other than
 writing a few cases and saying well, if the tests didn't even run, it's
 not right!?

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from 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/d/optout.




-- 
Ben Wolfson
Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure.
[Larousse, Drink entry]

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: Testing macros that throw errors at compile time?

[Michael Blume]

macroexpand-1 is a good start, I'd also recommend using the (is (thrown?
...)) special form, so

(is (thrown? IllegalArgumentException (macroexpend-1 '(my-macro
(ill-formed-arguments ...)

On Thu Jan 22 2015 at 5:05:36 PM Ben Wolfson wolf...@gmail.com wrote:

 (try (macroexpand-1 '(my-macro (ill-formed-arguments ...)))
   false ;; shouldn't get here
   (catch Exception _ true)) ;; whole expression should be true

 As long as you know that the *right* exception is being thrown.

 On Thu, Jan 22, 2015 at 4:41 PM, Scott Rabin scottra...@gmail.com wrote:

 We have a few macros in my employer's codebase that throw compile-time
 errors when you've given them invalid configurations, and have generally
 simply tested the result of these macros and not necessarily the direct
 expansion of said macros. What we would like to do is *test* that the
 macro blows up; but unfortunately, since this happens before tests are run,
 the result is that the compiler just complains at you instead of telling
 you that a specific test failed.

 Is there a decent way to test for thrown exceptions from macros other
 than writing a few cases and saying well, if the tests didn't even run,
 it's not right!?

 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from 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/d/optout.




 --
 Ben Wolfson
 Human kind has used its intelligence to vary the flavour of drinks, which
 may be sweet, aromatic, fermented or spirit-based. ... Family and social
 life also offer numerous other occasions to consume drinks for pleasure.
 [Larousse, Drink entry]

  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from 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/d/optout.


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Testing macros that throw errors at compile time?

[Scott Rabin]

We have a few macros in my employer's codebase that throw compile-time 
errors when you've given them invalid configurations, and have generally 
simply tested the result of these macros and not necessarily the direct 
expansion of said macros. What we would like to do is *test* that the macro 
blows up; but unfortunately, since this happens before tests are run, the 
result is that the compiler just complains at you instead of telling you 
that a specific test failed.

Is there a decent way to test for thrown exceptions from macros other than 
writing a few cases and saying well, if the tests didn't even run, it's 
not right!?

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Warnings as errors

[Robert Tweed]

Hi list,

Is there a way to get Clojure warnings to act as errors and abort the 
attempted operation? For now, I'm mainly interested in doing this in the 
repl, because I will often do something like this:


  (defn fn [x] (+ 1 x))
  ; WARNING: fn already refers to: #'clojure.core/fn ...

Oops! Did not really want to do that!

In some cases it's possible to unbind accidental bindings but in other 
cases it's either not possible or just doesn't seem to work for me and I 
end up having to restart the repl, which is annoying. I'd rather just 
prevent it happening at all.


In production code I'm not a big fan of warnings either, as with a few 
rare exceptions they correctly indicate that something is wrong, but can 
lead to silent errors instead of fast, noisy failure. That leads to 
things like subtle errors in your persistent data that comes back to 
bite you several months later, far removed from the original error, 
making it very hard to diagnose the root cause of the problem. So again, 
a hard failure mode would be welcome.


- Robert

--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: handling agent errors

[Brian Craft]

On Monday, August 11, 2014 10:08:09 PM UTC-7, Jeremy Heiler wrote:

 On Mon, Aug 11, 2014 at 3:07 PM, Brian Craft craft...@gmail.com 
 javascript: wrote:

 Two questions, really. I'm running large batch jobs with an agent. The 
 jobs may fail in any number of unanticipated ways (due to user input), so I 
 do a try/catch in the agent, log any errors, and continue with the next job.

 First question: how to deal with OOM (the Xmx limit, not the OS out of 
 mem)? The try/catch doesn't appear to help, here. The agent dies, and all 
 subsequent jobs never run. Is there some way to prevent or recover from 
 this?


 Once it has happened, I don't think there's much you can do to save the 
 process. I'd suggest that you figure out where you're improperly managing 
 memory by throwing a profiler at it.


Profiling is not going to change user behavior: users can give us inputs 
too large for their systems. If we can't recover from it, then we need to 
predict the event and abort. Perhaps we could monitor heap usage in another 
thread, and shut down the agent if it goes past some fraction. But there 
doesn't appear to be any mechanism for shutting down an agent. Maybe the 
agent action could stash the thread id in an atom, and a watcher thread 
could shut it down somehow.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: handling agent errors

[Brian Craft]

On Tuesday, August 12, 2014 9:59:54 AM UTC-7, Brian Craft wrote:



 On Monday, August 11, 2014 10:08:09 PM UTC-7, Jeremy Heiler wrote:

 On Mon, Aug 11, 2014 at 3:07 PM, Brian Craft craft...@gmail.com wrote:

 Two questions, really. I'm running large batch jobs with an agent. The 
 jobs may fail in any number of unanticipated ways (due to user input), so I 
 do a try/catch in the agent, log any errors, and continue with the next job.

 First question: how to deal with OOM (the Xmx limit, not the OS out of 
 mem)? The try/catch doesn't appear to help, here. The agent dies, and all 
 subsequent jobs never run. Is there some way to prevent or recover from 
 this?


 Once it has happened, I don't think there's much you can do to save the 
 process. I'd suggest that you figure out where you're improperly managing 
 memory by throwing a profiler at it.


 Profiling is not going to change user behavior: users can give us inputs 
 too large for their systems. If we can't recover from it, then we need to 
 predict the event and abort. Perhaps we could monitor heap usage in another 
 thread, and shut down the agent if it goes past some fraction. But there 
 doesn't appear to be any mechanism for shutting down an agent. Maybe the 
 agent action could stash the thread id in an atom, and a watcher thread 
 could shut it down somehow.


http://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html

Hm... from this doc it appears that maybe the thing to do is implement a 
please stop atom that the agent action would check periodically.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

handling agent errors

[Brian Craft]

Two questions, really. I'm running large batch jobs with an agent. The jobs 
may fail in any number of unanticipated ways (due to user input), so I do a 
try/catch in the agent, log any errors, and continue with the next job.

First question: how to deal with OOM (the Xmx limit, not the OS out of 
mem)? The try/catch doesn't appear to help, here. The agent dies, and all 
subsequent jobs never run. Is there some way to prevent or recover from 
this?

I posed this to a long-time java developer, who said I shouldn't be doing a 
blanket try/catch in the first place, because it's likely to result in 
leaked memory (presumably due to badly-coded libs that don't release 
resources on error). His suggestion: let the thread die on error, and 
restart it from a monitoring thread. I'm not sure how this translates to 
clojure agents. If I don't catch the errors, then log the agent error state 
and restart it, is that equivalent? Is this best practice? Seems like 
badly-coded libs could still leak memory this way, if they've stashed a 
reference in any shared state.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: handling agent errors

[Jeremy Heiler]

On Mon, Aug 11, 2014 at 3:07 PM, Brian Craft craft.br...@gmail.com wrote:

 Two questions, really. I'm running large batch jobs with an agent. The
 jobs may fail in any number of unanticipated ways (due to user input), so I
 do a try/catch in the agent, log any errors, and continue with the next job.

 First question: how to deal with OOM (the Xmx limit, not the OS out of
 mem)? The try/catch doesn't appear to help, here. The agent dies, and all
 subsequent jobs never run. Is there some way to prevent or recover from
 this?


Once it has happened, I don't think there's much you can do to save the
process. I'd suggest that you figure out where you're improperly managing
memory by throwing a profiler at it.


 I posed this to a long-time java developer, who said I shouldn't be doing
 a blanket try/catch in the first place, because it's likely to result in
 leaked memory (presumably due to badly-coded libs that don't release
 resources on error). His suggestion: let the thread die on error, and
 restart it from a monitoring thread. I'm not sure how this translates to
 clojure agents. If I don't catch the errors, then log the agent error state
 and restart it, is that equivalent? Is this best practice? Seems like
 badly-coded libs could still leak memory this way, if they've stashed a
 reference in any shared state.


Agents are not dealing irectly with threads, so unless you are, you don't
need to worry about that. Internally, agents use one of  two
ExecuterServices that to do their work, depending on whether you're calling
send or send-off. These ExecuterServices manage their threads for you, and
will clean them up if they throw an exception.

I think the spirit of that person's advice is to not blindly catch an
exception and do nothing about it. Make sure that you are cleaning up any
resources that your'e using, and do some profiling! Because you question
was so general, it's hard to get into anything specific.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Data Literals: How to handle read errors?

[Thomas Heller]

Hey there,

I upgraded to JDK8 and wanted to start using the new java.time.* packages. 
I started by implementing reader functions to get rid of #inst like:

#time/local-date [2014 4 13]
#time/local-datetime [2014 4 13 14 23]

While that works fine and as expected, one thing I ran into is confusing 
error messages.

For example, from a REPL:

user= (pr-str #time/local-datetime [2014 4 1 0 0 2 999])

DateTimeException Invalid value for NanoOfSecond (valid values 0 - 
9): 1215752191  java.time.temporal.ValueRange.checkValidValue 
(ValueRange.java:311)
RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException 
(Util.java:221)

Or another one:

user= (pr-str #time/local-date [2014 4 31])

DateTimeException Invalid date 'APRIL 31'  java.time.LocalDate.create 
(LocalDate.java:431)
RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException 
(Util.java:221)


The first part is what I expected, however the Unmatched delimiter part 
is not what I expected. Is there any special exception I should be throwing 
in a reader function that read something that can never be correct? Also 
why do I need print-dup?

Nothing serious, just curious if its a bug or an oversight on my part.

Regards,
/thomas



PS: Clojure 1.6.0 btw

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/d/optout.

Re: Data Literals: How to handle read errors?

[Stephen Gilardi]

On Apr 13, 2014, at 8:31 AM, Thomas Heller th.hel...@gmail.com wrote:

 [...] confusing error messages.
 
 user= (pr-str #time/local-datetime [2014 4 1 0 0 2 999])
 
 [...]
 RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException 
 (Util.java:221)

Using default #inst reader gives the same behavior.

This is an artifact of how the repl currently works. Its input is a stream of 
characters to which it applies the read, eval, and print operations in a loop. 
There is prompt-handling code in the repl that makes it feel turn oriented in 
most cases, but this case isn't handled. It does not currently implement on 
exception in read, flush the rest of the pending user input and re-prompt.

Here's an example with a vanilla clojure 1.6.0 (java -jar the clojure 
1.6.0.jar) that may clarify what's going on:

user= (println 1 2 3 #inst 4 5 6 7 8 9)
RuntimeException Unrecognized date/time syntax: 4  
clojure.instant/fn--6236/fn--6237 (instant.clj:118)
5
6
7
8
9
RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException 
(Util.java:221)

The start of the list (println 1 2 3 reads fine, then the #inst read throws 
an exception. After the exception, the repl starts working on the remainder of 
the input characters as if it were fresh user input. It sees integers and 
prints them. When it hits ), there's no corresponding ( pending, so it 
throws again.

--Steve

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

Re: Data Literals: How to handle read errors?

[Thomas Heller]

Ah, didn't even think about the REPL causing trouble here.

Thanks.

On Sunday, April 13, 2014 5:30:09 PM UTC+2, squeegee wrote:


 On Apr 13, 2014, at 8:31 AM, Thomas Heller th.h...@gmail.comjavascript: 
 wrote:

 […] confusing error messages.

 user= (pr-str #time/local-datetime [2014 4 1 0 0 2 999])

 […]

 RuntimeException Unmatched delimiter: ) 
  clojure.lang.Util.runtimeException (Util.java:221)


 Using default #inst reader gives the same behavior.

 This is an artifact of how the repl currently works. Its input is a stream 
 of characters to which it applies the read, eval, and print operations in a 
 loop. There is prompt-handling code in the repl that makes it feel “turn” 
 oriented in most cases, but this case isn’t handled. It does not currently 
 implement “on exception in read, flush the rest of the pending user input 
 and re-prompt”.

 Here’s an example with a vanilla clojure 1.6.0 (java -jar the clojure 
 1.6.0.jar) that may clarify what’s going on:

 user= (println 1 2 3 #inst 4 5 6 7 8 9)
 RuntimeException Unrecognized date/time syntax: 4 
  clojure.instant/fn--6236/fn--6237 (instant.clj:118)
 5
 6
 7
 8
 9
 RuntimeException Unmatched delimiter: ) 
  clojure.lang.Util.runtimeException (Util.java:221)

 The start of the list (println 1 2 3” reads fine, then the #inst read 
 throws an exception. After the exception, the repl starts working on the 
 remainder of the input characters as if it were fresh user input. It sees 
 integers and prints them. When it hits “)”, there’s no corresponding “(“ 
 pending, so it throws again.

 —Steve



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

lein script installation errors on CentOS 6.5

[gvim]

The lein script is producing errors when I try to install it on CentOS 6.5:

$ lein
/sw/bin/lein: command substitution: line 93: syntax error near 
unexpected token `)'

/sw/bin/lein: command substitution: line 93: `dirname $PWD)'
/sw/bin/lein: command substitution: line 110: syntax error near 
unexpected token `)'

/sw/bin/lein: command substitution: line 110: `dirname $0)'
/sw/bin/lein: command substitution: line 123: syntax error near 
unexpected token `)'

/sw/bin/lein: command substitution: line 123: `dirname $SCRIPT)'
/sw/bin/lein: command substitution: line 44: syntax error near 
unexpected token `)'

/sw/bin/lein: command substitution: line 44: `make_native_path $1)'
/sw/bin/lein: command substitution: line 50: syntax error near 
unexpected token `)'

/sw/bin/lein: command substitution: line 50: `basename $LEIN_JAVA_CMD)'
/sw/bin/lein: command substitution: line 140: syntax error near 
unexpected token `)'
/sw/bin/lein: command substitution: line 140: `mktemp 
/tmp/lein-trampoline-X)'


I downloaded it first with wget and when that failed I copied and pasted 
the online version into MacVim  and uploaded the file to my CentOS 
server. Same result. I have Oracle's jdk-7u45 installed.


gvim

--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: lein script installation errors on CentOS 6.5

[Matching Socks]

Scripts in Red Hat ought to begin with #!/bin/bash which is writable only 
by root and kept updated by system updates. But lein uses #!/usr/bin/env 
bash -- use whatever bash executable is on my path -- which is less well 
controlled and might be different. Try which bash to see what shell is 
being used to run lein.  If it's not /bin/bash, try adjusting lein's first 
line.  If you get the error when using /bin/bash, see what version it is 
with rpm -q bash. 

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: lein script installation errors on CentOS 6.5

[gvim]

Resolved, thanks. Still puzzled as Red Hat's /bin/bash is 4.1.2 and my 
custom /sw/bin/bash is 4.2.24. Surely such a minor version difference 
should not result in such a catastrophe?


gvim

On 14/01/2014 01:31, Matching Socks wrote:

Scripts in Red Hat ought to begin with #!/bin/bash which is writable
only by root and kept updated by system updates. But lein uses
#!/usr/bin/env bash -- use whatever bash executable is on my path --
which is less well controlled and might be different. Try which bash
to see what shell is being used to run lein.  If it's not /bin/bash, try
adjusting lein's first line.  If you get the error when using /bin/bash,
see what version it is with rpm -q bash.



--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: sending errors to the ui - web development using luminus

[Mark Nutter]

I am using Validateur (http://clojurevalidations.info/) as the basis for a
custom validation mechanism with Luminus. The validation-set fn gets you
about 90% of the way there: it takes a list of rules and returns a
function. Pass your data map to the function, and it returns a set of the
error messages. You can also write custom validation rules in case the
basic set isn't what you need.


On Fri, Aug 9, 2013 at 2:02 AM, Abraham abev...@gmail.com wrote:

 Dear
 How to send validate the input and then send all errors at a time .?
 I am using luminus , the doc shows send one error at a time.
 Thanks in advance
 A

  --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from 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.

sending errors to the ui - web development using luminus

[Abraham]

Dear 
How to send validate the input and then send all errors at a time .?
I am using luminus , the doc shows send one error at a time.
Thanks in advance
A

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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.

Why are errors in nested futures suppressed?

[Colin Yates]

Hi all,

If the function executed in a future throws an error it is printed out in 
the repl immediately.  If that function is executed in a future which 
itself is executed in a future then it isn't.

For example, imagine somebody wrote the following code (please, suspend 
belief and just accept people do do this when learning Clojure :)):

[code]
;; some silly code
user (swap! atom inc 0)
ClassCastException clojure.core$atom cannot be cast to clojure.lang.Atom 
 clojure.core/swap! (core.clj:2161)
;; silly code wrapped in a future
user (future (swap! atom inc 0))
ClassCastException clojure.core$atom cannot be cast to clojure.lang.Atom 
 clojure.core/swap! (core.clj:2161)
;; silly code wrapped in a future wrapped in a future
user (future (future (swap! atom inc 0)))
#core$future_call$reify__6267@11e55d39: :pending
user 
[/code]

My understanding is that future executes its delegate in a separate thread, 
hence the (future (swa...)) code prints out the exception almost 
immediately.  I don't understand why the nested future doesn't print out 
the error though as it should surely be executed almost immediately as well?

Of course, if you dereference the call then it prints out the stack trace.

As to why you would want a future in a future...that is a different kettle 
of fish :).

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Why are errors in nested futures suppressed?

[atkaaz]

= (future (swap! atom inc 0))
#core$future_call$reify__6267@38db2b7e: :pending

= @(future (swap! atom inc 0))
ClassCastException clojure.core$atom cannot be cast to clojure.lang.Atom
clojure.core/swap! (core.clj:2161)


(both in ccw, but i notice that the first statement does throw in lein repl)

guessing the error is actually thrown in that thread, but nobody can see it
unless they are trying to deref it in current thread or something else
along those lines



On Tue, May 21, 2013 at 1:01 PM, Colin Yates colin.ya...@gmail.com wrote:

 Hi all,

 If the function executed in a future throws an error it is printed out in
 the repl immediately.  If that function is executed in a future which
 itself is executed in a future then it isn't.

 For example, imagine somebody wrote the following code (please, suspend
 belief and just accept people do do this when learning Clojure :)):

 [code]
 ;; some silly code
 user (swap! atom inc 0)
 ClassCastException clojure.core$atom cannot be cast to clojure.lang.Atom
  clojure.core/swap! (core.clj:2161)
 ;; silly code wrapped in a future
 user (future (swap! atom inc 0))
 ClassCastException clojure.core$atom cannot be cast to clojure.lang.Atom
  clojure.core/swap! (core.clj:2161)
 ;; silly code wrapped in a future wrapped in a future
 user (future (future (swap! atom inc 0)))
 #core$future_call$reify__6267@11e55d39: :pending
 user
 [/code]

 My understanding is that future executes its delegate in a separate
 thread, hence the (future (swa...)) code prints out the exception almost
 immediately.  I don't understand why the nested future doesn't print out
 the error though as it should surely be executed almost immediately as well?

 Of course, if you dereference the call then it prints out the stack trace.

 As to why you would want a future in a future...that is a different kettle
 of fish :).

 --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from 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: Namespaced symbols, and errors

[Gary Verhaegen]

Here's another mental model that you can use. (Not sure it is 100%
accurate with the actual implementation, but it has served me well so
far.)

Keywords are not bound, in the same sense that numbers are not bound.
1 is 1, just as 2 is 2, whatever the namespace you are into. 1 from
the user namespace is the same a 1 from the clojure.core namespace.

Similarly, the keyword :hello is not bound, it just is. :hello in the
user namespace is the same value as :hello in the core namespace or in
any other namespace. As keywords are very lightweight to create and
very fast to compare for equality, they are often used as keys in
associative data structures.

Sometimes, though, you actually want to have keywords that are local
to your namespace, because you want to encapsulate some behaviour. Say
you want to create a simple tree-manipulation library, where your
nodes are, for some reason, represented as maps with a special key
:children. Other than that, you want the user of your library to be
able to add any information to the maps representing the nodes of the
tree. One way to approach this would be to document that the special
key :children is reserved and cannot be used.

Another way to handle this would be to create a keyword that is
supposedly unique to your library, by prefixing the keyword with some
chosen prefix, say :tree-children. That would soon become quite
cumbersome to type, and does not really preclude the preceding point,
though it would make conflicts rarer. But there is one thing that
Clojure can guarantee, which is that in a single application, there
will not be two namespaces with the same name. So, assuming your
library is contained in a namespace called my.tree-manipulation.core,
you could decide to call your special key
:my.tree-manipulation.core.children. That, too, would be cumbersome,
but conceivably safer.

Now, this is originally an implementation detail, but it just so
happens that keywords are basically implemented as symbols that
evaluate to themselves. That is, if keywords did not exist in Clojure,
you could invent them by declaring them as (def :a ':a); after that
declaration, :a would work exactly like a keyword works today in
Clojure. Which means that we can reuse the namespace resolution
feature of symbols : every time the reader reads in a symbols, it
first resolves it in the current namespace, and then evaluates the
full symbol to find its value. Keywords sort of short-circuit that by
default.

However, with the :: notation, you are basically telling the reader to
first evaluate the given symbol in the current namespace, then
evaluate it as a symbol. So ::bla in namespace test is the same as
typing the full keyword :test/bla. But the keyword itself is not
resolved in the namespace, the keyword just is. It just so happens
that its value looks like a namespace-qualified symbol with a colon in
front.

Getting back to the tree example, you can thus have your special key
be ::children, which combines the two following advantages : the
actual keyword is pretty specific to your library, as the real keyword
seen by the compiler will be :my.tree-manipulation.core/children, but
it is also nearly as short to type and to read as plain :children.

Now let's look at your questions in light of this mental model.

On 9 March 2013 19:37, nick rothwell n...@cassiel.com wrote:
 I understand that ::foo is a keyword bound into the local namespace.

So ::foo is actually a shorthand for the :my.ns/foo keyword, which is
a value by itself, independently of any enclosing or existing
namespace. (Keywords follow the symbol rule of maximum one / in the
name, but there is actually no link with existing namespaces : you
can use a keyword :no-namespace/k even if there is no namespace called
no-namespace.)

 I also understand (according to the docs) that

 :my.namespace/foo is the keyword foo in the namespace my.namespace.

As I stated earlier, namespaces are only of interest to symbol
resolution; they do not interfere with keywords beyond their optional
construction via the :: shorthand.

 ::nsalias/foo is the keyword foo in the namespace my.namespace if I've
 aliased my.namespace to nsalias.

So Clojure first tries to find the corresponding symbol, then only
converts it to a keyword. Thus namespace resolution works with
aliases. The resulting keyword is still a value by itself.

 But also:

 ::my.namespace/foo is equivalent to :my.namespace/foo (as a convenience, I
 guess).

Resolving an already namespace-qualified symbol yields the same
namespace-qualified symbol.

 :nsalias/foo is not the same as ::nsalias/foo - in fact, I'm not sure what
 :nsalias/foo is - a call on str yields :nsalias/foo.

:nsalias/foo is the value :nsalias/foo - symbols are self-evaluating
values, just as 1 is 1. The fact that it looks like a namespaced
symbol is irrelevant. ::nsalias/foo is asking the reader to first
resolve the symbol nsalias/foo in the current namespace, using known
aliases if need be, and only afterwards turning it 

Re: Namespaced symbols, and errors

[Marko Topolnik]

On Friday, March 8, 2013 4:56:03 PM UTC+1, nick rothwell wrote:

 Typing the following at a REPL:

 (str ::junk/junk)

 (where there's no alias for junk) gives me:

 RuntimeException Invalid token: ::junk/junk 
  clojure.lang.Util.runtimeException (Util.java:219)
 RuntimeException Unmatched delimiter: ) 
  clojure.lang.Util.runtimeException (Util.java:219)

 A couple of things:

 (i) Invalid token seems a bit curt: doesn't it mean something like no 
 such namespace alias?


This could definitely benefit from an improvement in the reader/compiler.
 

 Another aside: why does Clojure require :: for aliases but only : for 
 namespace-qualified keywords? Under what circumstance would I use 
 :junk/junk in any way other than to mean ::junk/junk (or 
 :my.namespace.junk/junk, given the appropriate alias)?


::keyword being a shortcut for ::current-ns/keyword is more consistent (so 
less surprising) than being a shortcut for :current-ns/keyword. String 
value of a keyword is often important and dictated by outside constraints 
(conversion from/to string is common) so there's benefit to allowing a 
slash in it. I personally appreciate the :: to signal a qualified keyword. 
They are rare and special so it's nice to have them visually stand out. I 
bet other people can enumerate other reasons to support/criticise this 
design choice, but in the end there won't be much to learn from it.

-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: Namespaced symbols, and errors

[Gary Verhaegen]

The reader basically transforms :: into :namespace/, which means that
the remaining part must be an unqualified symbol (i.e. no / in it).
The character / is not allowed in unqualified symbols. As the
documentation [1] says : '/' has special meaning, it can be used once
in the middle of a symbol to separate the namespace from the name,
e.g. my-namespace/foo. '/' by itself names the division function.

Your notation ::junk/junk, assuming your type in namespace
my.namespace.junk, would result in the keyword
:my.namespace.junk/junk/junk, which is invalid (two /'s). Hence the
implied restriction that ::symbol cannot contain a / character.

I'm not really sure what you mean about aliases. Keywords stand by
themselves (they are literals that evaluate to themselves), they are
not aliases for something else.

[1] http://clojure.org/reader

On 8 March 2013 16:56, nick rothwell n...@cassiel.com wrote:
 Typing the following at a REPL:

 (str ::junk/junk)

 (where there's no alias for junk) gives me:

 RuntimeException Invalid token: ::junk/junk
 clojure.lang.Util.runtimeException (Util.java:219)
 RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException
 (Util.java:219)

 A couple of things:

 (i) Invalid token seems a bit curt: doesn't it mean something like no such
 namespace alias?
 (ii) A complete aside, but: the interactive REPL obviously isn't
 disregarding the rest of the line when it gets a token error.

 Another aside: why does Clojure require :: for aliases but only : for
 namespace-qualified keywords? Under what circumstance would I use :junk/junk
 in any way other than to mean ::junk/junk (or :my.namespace.junk/junk, given
 the appropriate alias)?

 --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your
 first post.
 To unsubscribe from 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: Namespaced symbols, and errors

[Bronsa]

Gary, ::foo/bar is valid syntax if foo is a valid namespace alias.

Try:
(alias 'foo 'clojure.core)
::foo/bar
Il giorno 09/mar/2013 09.36, Gary Verhaegen gary.verhae...@gmail.com ha
scritto:

 The reader basically transforms :: into :namespace/, which means that
 the remaining part must be an unqualified symbol (i.e. no / in it).
 The character / is not allowed in unqualified symbols. As the
 documentation [1] says : '/' has special meaning, it can be used once
 in the middle of a symbol to separate the namespace from the name,
 e.g. my-namespace/foo. '/' by itself names the division function.

 Your notation ::junk/junk, assuming your type in namespace
 my.namespace.junk, would result in the keyword
 :my.namespace.junk/junk/junk, which is invalid (two /'s). Hence the
 implied restriction that ::symbol cannot contain a / character.

 I'm not really sure what you mean about aliases. Keywords stand by
 themselves (they are literals that evaluate to themselves), they are
 not aliases for something else.

 [1] http://clojure.org/reader

 On 8 March 2013 16:56, nick rothwell n...@cassiel.com wrote:
  Typing the following at a REPL:
 
  (str ::junk/junk)
 
  (where there's no alias for junk) gives me:
 
  RuntimeException Invalid token: ::junk/junk
  clojure.lang.Util.runtimeException (Util.java:219)
  RuntimeException Unmatched delimiter: )
  clojure.lang.Util.runtimeException
  (Util.java:219)
 
  A couple of things:
 
  (i) Invalid token seems a bit curt: doesn't it mean something like no
 such
  namespace alias?
  (ii) A complete aside, but: the interactive REPL obviously isn't
  disregarding the rest of the line when it gets a token error.
 
  Another aside: why does Clojure require :: for aliases but only : for
  namespace-qualified keywords? Under what circumstance would I use
 :junk/junk
  in any way other than to mean ::junk/junk (or :my.namespace.junk/junk,
 given
  the appropriate alias)?
 
  --
  --
  You received this message because you are subscribed to the Google
  Groups Clojure group.
  To post to this group, send email to clojure@googlegroups.com
  Note that posts from new members are moderated - please be patient with
 your
  first post.
  To unsubscribe from 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: Namespaced symbols, and errors

[Gary Verhaegen]

On 9 March 2013 12:27, Bronsa brobro...@gmail.com wrote:
 Gary, ::foo/bar is valid syntax if foo is a valid namespace alias.

 Try:
 (alias 'foo 'clojure.core)
 ::foo/bar

I did not know that. Is that documented anywhere ? I was under the
impression that :: was just intended as a shorthand to create local
keywords so as to avoid clashing with other namespaces; that it does
namespace resolution looks to me more like a side-effect of symbols
and keywords sharing the same underlying implementation.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Namespaced symbols, and errors

[nick rothwell]

I understand that ::foo is a keyword bound into the local namespace.

I also understand (according to the docs) that

:my.namespace/foo is the keyword foo in the namespace my.namespace.

::nsalias/foo is the keyword foo in the namespace my.namespace if I've 
aliased my.namespace to nsalias.

But also: 

::my.namespace/foo is equivalent to :my.namespace/foo (as a convenience, I 
guess).

:nsalias/foo is not the same as ::nsalias/foo - in fact, I'm not sure what 
:nsalias/foo is - a call on str yields :nsalias/foo.

This last point is the one that's confusing me.

On Saturday, March 9, 2013 8:36:30 AM UTC, Gary Verhaegen wrote:

 The reader basically transforms :: into :namespace/, which means that 
 the remaining part must be an unqualified symbol (i.e. no / in it). 
 The character / is not allowed in unqualified symbols. As the 
 documentation [1] says : '/' has special meaning, it can be used once 
 in the middle of a symbol to separate the namespace from the name, 
 e.g. my-namespace/foo. '/' by itself names the division function. 

 Your notation ::junk/junk, assuming your type in namespace 
 my.namespace.junk, would result in the keyword 
 :my.namespace.junk/junk/junk, which is invalid (two /'s). Hence the 
 implied restriction that ::symbol cannot contain a / character. 

 I'm not really sure what you mean about aliases. Keywords stand by 
 themselves (they are literals that evaluate to themselves), they are 
 not aliases for something else. 

 [1] http://clojure.org/reader 

 On 8 March 2013 16:56, nick rothwell ni...@cassiel.com javascript: 
 wrote: 
  Typing the following at a REPL: 
  
  (str ::junk/junk) 
  
  (where there's no alias for junk) gives me: 
  
  RuntimeException Invalid token: ::junk/junk 
  clojure.lang.Util.runtimeException (Util.java:219) 
  RuntimeException Unmatched delimiter: ) 
  clojure.lang.Util.runtimeException 
  (Util.java:219) 
  
  A couple of things: 
  
  (i) Invalid token seems a bit curt: doesn't it mean something like no 
 such 
  namespace alias? 
  (ii) A complete aside, but: the interactive REPL obviously isn't 
  disregarding the rest of the line when it gets a token error. 
  
  Another aside: why does Clojure require :: for aliases but only : 
 for 
  namespace-qualified keywords? Under what circumstance would I use 
 :junk/junk 
  in any way other than to mean ::junk/junk (or :my.namespace.junk/junk, 
 given 
  the appropriate alias)? 
  
  -- 
  -- 
  You received this message because you are subscribed to the Google 
  Groups Clojure group. 
  To post to this group, send email to clo...@googlegroups.comjavascript: 
  Note that posts from new members are moderated - please be patient with 
 your 
  first post. 
  To unsubscribe from this group, send email to 
  clojure+u...@googlegroups.com javascript: 
  For more options, visit this group at 
  http://groups.google.com/group/clojure?hl=en 
  --- 
  You received this message because you are subscribed to the Google 
 Groups 
  Clojure group. 
  To unsubscribe from this group and stop receiving emails from it, send 
 an 
  email to clojure+u...@googlegroups.com javascript:. 
  For more options, visit https://groups.google.com/groups/opt_out. 
  
  


-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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.

Namespaced symbols, and errors

[nick rothwell]

Typing the following at a REPL:

(str ::junk/junk)

(where there's no alias for junk) gives me:

RuntimeException Invalid token: ::junk/junk 
 clojure.lang.Util.runtimeException (Util.java:219)
RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException 
(Util.java:219)

A couple of things:

(i) Invalid token seems a bit curt: doesn't it mean something like no such 
namespace alias?
(ii) A complete aside, but: the interactive REPL obviously isn't 
disregarding the rest of the line when it gets a token error.

Another aside: why does Clojure require :: for aliases but only : for 
namespace-qualified keywords? Under what circumstance would I use :junk/junkin 
any way other than to mean 
::junk/junk (or :my.namespace.junk/junk, given the appropriate alias)?

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: ClojureCLR errors on Mono Linux

[RobertLJ]

Shantanu

The best way to get going right now with ClojureCLR is to build it from 
source.  The following is the process to build ClojureCLR on Linux 
(Assuming that the mono development environment is installed).  

1. Download: 
https://github.com/clojure/clojure-clr/archive/clojure-1.4.1.tar.gz
2. Untar clojure-1.4.1.tar.gz
3. Download the NuGet.exe commandline installer: 
http://nuget.codeplex.com/releases . Use the link under Available downloads 
NuGet.exe Command Line. 
4. set up nuget as per these directions: 
http://monomvc.wordpress.com/2012/03/06/nuget-on-mono/

5. From the terminal in the lib directory under clojure-1.4.1 use nuget 
to download the dependencies like this:  

A. nuget install DynamicLanguageRuntime.Net20.Unofficial
B. nuget install DynamicLanguageRuntime.Net40.Unofficial
C. nuget install NUnit

6. Copy the assemblies from 
lib/DynamicLanguageRuntime.Net20.Unofficial/lib/net20 to lib/DLR/2.0

7. Copy the assemblies from 
lib/DynamicLanguageRuntime.Net40.Unofficial/lib/net40 to lib/DLR/4.0

8. In a text editor open the Clojure.Compile.csproj file located in 
clojure-1.4.1/Clojure/Clojure.Compile.  Under the PostBuildEvent add 
mono  to the sections so it looks like this:

*-Clojure.Compile.csproj 
Edit---*
 PostBuildEventmono $(TargetPath) clojure.core clojure.core.protocols 
clojure.main clojure.set clojure.zip  clojure.walk clojure.stacktrace 
clojure.template clojure.test clojure.test.tap clojure.test.junit 
clojure.pprint clojure.clr.io clojure.repl clojure.clr.shell clojure.string 
clojure.data clojure.reflect/PostBuildEvent  /PropertyGroup
*-Clojure.Compile.csproj 
Edit---*

*-NUnit 
Edit--*
9. In a text editor open the Clojure.Tests.csproj file located in 
clojure-1.4.1/Clojure/Clojure.Tests.   Change the nunit.framework 
configuration from:

Original Configuration
 Reference Include=nunit.framework, Version=2.6.0.12051, Culture=neutral, 
PublicKeyToken=96d09a1eb7f44a77, processorArchitecture=MSIL
  
HintPath..\packages\NUnit.2.6.0.12054\lib\nunit.framework.dll/HintPath
/Reference 

Change Configuration to this 
Reference Include=nunit.framework
  HintPath..\..\lib\NUnit.2.6.2\lib\nunit.framework.dll/HintPath
/Reference
*-NUnit 
Edit--*

10. Finaly from the directory clojure-clr-clojure-1.4.1/Clojure run 
either:

MONO_IOMAP=all xbuild build.proj /target:Build /p:Configuration=Release 
4.0 /p:Platform=Any CPU

or
MONO_IOMAP=all xbuild build.proj /target:Build /p:Configuration=Debug 4.0 
/p:Platform=Any CPU

After the build the binaries will be located in 
clojure-clr-clojure-1.4.1/bin/4.0\{Release || Debug}


I'm working on streamlining this for for ClojureCLR 1.5.0. Hope this helps.

-Robert



On Wednesday, December 19, 2012 5:37:10 PM UTC-5, Shantanu Kumar wrote:

 Here are the steps how to reproduce the issue on 32-bit Ubuntu 12.04:

 1. lein new lein-clr foo
 2. cd foo
 3. # edit project.clj to download the dependencies using :clj-dep
 4. lein clr -v compile :all

 

 5. lein clr -v test

 It will show the exact commands being executed. Are the same Clojure 
 binaries supposed to work on 32-bit systems?

 Shantanu

 On Wednesday, 19 December 2012 13:19:55 UTC+5:30, Shantanu Kumar wrote:

 Thanks David, and sorry for the insufficient bug details. I tested this 
 on 64-bit Ubuntu where it works fine; however, the problem shows up on 
 32-bit Ubuntu.

 I will post the exact steps in the evening on how to replicate the issue 
 on 32-bit Ubuntu.

 Shantanu

 On Wednesday, 19 December 2012 02:00:53 UTC+5:30, dmiller wrote:

 Shantanu,

 I created an Ubuntu 12.10 VM running in VirtualBox on my Win7 PC.  
 I installed Mono 2.10.8.
 I downloaded the zip for ClojureCLR 1.4.0 Debug-4.0.
 Extracted.
  mono Clojure.Main.exe  
 Runs with no problem.

  mono Clojure.Compile.exe test.junk
 Runs with no problem.

 From the errors you report, I can only guess that some pre-1.4 DLLs are 
 being found somehow and loaded.  
 For example,  the field clojure.lang.RT.OutVar did not exist in 
 ClojureCLR 1.3.

 I do not know how else to help.

 -David
  


 On Saturday, December 15, 2012 10:17:59 PM UTC-6, Shantanu Kumar wrote:

 This is when using ClojureCLR 1.4.0 Debug-4.0 version.

 Shantanu

 On Sunday, 16 December 2012 09:45:21 UTC+5:30, Shantanu Kumar wrote:

 Hi,

 I noticed the following ClojureCLR errors using Mono 2.10 on Ubuntu 
 12.04 (they do not happen on Windows using either .NET or Mono):

 1. when running Clojure.Compile.exe:

 Exception: System.MissingFieldException: Field 
 'clojure.lang.RT.OutVar' not found.

 2. when using Clojure.Main.exe:

 Exception: System.TypeLoadException: Could not load type 
 'Clojure.CljMain' from assembly

Re: ClojureCLR errors on Mono Linux

[dmiller]

I believe I'm running 32-bit.  
Can you email me your project.clj file so I can make sure I'm reproducing 
your situation?
-David

On Wednesday, December 19, 2012 4:37:10 PM UTC-6, Shantanu Kumar wrote:

 Here are the steps how to reproduce the issue on 32-bit Ubuntu 12.04:

 1. lein new lein-clr foo
 2. cd foo
 3. # edit project.clj to download the dependencies using :clj-dep
 4. lein clr -v compile :all
 5. lein clr -v test

 It will show the exact commands being executed. Are the same Clojure 
 binaries supposed to work on 32-bit systems?

 Shantanu

 On Wednesday, 19 December 2012 13:19:55 UTC+5:30, Shantanu Kumar wrote:

 Thanks David, and sorry for the insufficient bug details. I tested this 
 on 64-bit Ubuntu where it works fine; however, the problem shows up on 
 32-bit Ubuntu.

 I will post the exact steps in the evening on how to replicate the issue 
 on 32-bit Ubuntu.

 Shantanu

 On Wednesday, 19 December 2012 02:00:53 UTC+5:30, dmiller wrote:

 Shantanu,

 I created an Ubuntu 12.10 VM running in VirtualBox on my Win7 PC.  
 I installed Mono 2.10.8.
 I downloaded the zip for ClojureCLR 1.4.0 Debug-4.0.
 Extracted.
  mono Clojure.Main.exe  
 Runs with no problem.

  mono Clojure.Compile.exe test.junk
 Runs with no problem.

 From the errors you report, I can only guess that some pre-1.4 DLLs are 
 being found somehow and loaded.  
 For example,  the field clojure.lang.RT.OutVar did not exist in 
 ClojureCLR 1.3.

 I do not know how else to help.

 -David
  


 On Saturday, December 15, 2012 10:17:59 PM UTC-6, Shantanu Kumar wrote:

 This is when using ClojureCLR 1.4.0 Debug-4.0 version.

 Shantanu

 On Sunday, 16 December 2012 09:45:21 UTC+5:30, Shantanu Kumar wrote:

 Hi,

 I noticed the following ClojureCLR errors using Mono 2.10 on Ubuntu 
 12.04 (they do not happen on Windows using either .NET or Mono):

 1. when running Clojure.Compile.exe:

 Exception: System.MissingFieldException: Field 
 'clojure.lang.RT.OutVar' not found.

 2. when using Clojure.Main.exe:

 Exception: System.TypeLoadException: Could not load type 
 'Clojure.CljMain' from assembly 'Clojure.Main, Version=1.0.0.0, 
 Culture=neutral, PublicKeyToken=null'.

 It would be great if anybody can let me know what's going on.

 Shantanu



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

Re: ClojureCLR errors on Mono Linux

[Shantanu Kumar]

Here are the steps how to reproduce the issue on 32-bit Ubuntu 12.04:

1. lein new lein-clr foo
2. cd foo
3. # edit project.clj to download the dependencies using :clj-dep
4. lein clr -v compile :all
5. lein clr -v test

It will show the exact commands being executed. Are the same Clojure 
binaries supposed to work on 32-bit systems?

Shantanu

On Wednesday, 19 December 2012 13:19:55 UTC+5:30, Shantanu Kumar wrote:

 Thanks David, and sorry for the insufficient bug details. I tested this on 
 64-bit Ubuntu where it works fine; however, the problem shows up on 32-bit 
 Ubuntu.

 I will post the exact steps in the evening on how to replicate the issue 
 on 32-bit Ubuntu.

 Shantanu

 On Wednesday, 19 December 2012 02:00:53 UTC+5:30, dmiller wrote:

 Shantanu,

 I created an Ubuntu 12.10 VM running in VirtualBox on my Win7 PC.  
 I installed Mono 2.10.8.
 I downloaded the zip for ClojureCLR 1.4.0 Debug-4.0.
 Extracted.
  mono Clojure.Main.exe  
 Runs with no problem.

  mono Clojure.Compile.exe test.junk
 Runs with no problem.

 From the errors you report, I can only guess that some pre-1.4 DLLs are 
 being found somehow and loaded.  
 For example,  the field clojure.lang.RT.OutVar did not exist in 
 ClojureCLR 1.3.

 I do not know how else to help.

 -David
  


 On Saturday, December 15, 2012 10:17:59 PM UTC-6, Shantanu Kumar wrote:

 This is when using ClojureCLR 1.4.0 Debug-4.0 version.

 Shantanu

 On Sunday, 16 December 2012 09:45:21 UTC+5:30, Shantanu Kumar wrote:

 Hi,

 I noticed the following ClojureCLR errors using Mono 2.10 on Ubuntu 
 12.04 (they do not happen on Windows using either .NET or Mono):

 1. when running Clojure.Compile.exe:

 Exception: System.MissingFieldException: Field 'clojure.lang.RT.OutVar' 
 not found.

 2. when using Clojure.Main.exe:

 Exception: System.TypeLoadException: Could not load type 
 'Clojure.CljMain' from assembly 'Clojure.Main, Version=1.0.0.0, 
 Culture=neutral, PublicKeyToken=null'.

 It would be great if anybody can let me know what's going on.

 Shantanu



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

Re: ClojureCLR errors on Mono Linux

[dmiller]

Shantanu,

I created an Ubuntu 12.10 VM running in VirtualBox on my Win7 PC.  
I installed Mono 2.10.8.
I downloaded the zip for ClojureCLR 1.4.0 Debug-4.0.
Extracted.
 mono Clojure.Main.exe  
Runs with no problem.

 mono Clojure.Compile.exe test.junk
Runs with no problem.

From the errors you report, I can only guess that some pre-1.4 DLLs are 
being found somehow and loaded.  
For example,  the field clojure.lang.RT.OutVar did not exist in ClojureCLR 
1.3.

I do not know how else to help.

-David
 


On Saturday, December 15, 2012 10:17:59 PM UTC-6, Shantanu Kumar wrote:

 This is when using ClojureCLR 1.4.0 Debug-4.0 version.

 Shantanu

 On Sunday, 16 December 2012 09:45:21 UTC+5:30, Shantanu Kumar wrote:

 Hi,

 I noticed the following ClojureCLR errors using Mono 2.10 on Ubuntu 12.04 
 (they do not happen on Windows using either .NET or Mono):

 1. when running Clojure.Compile.exe:

 Exception: System.MissingFieldException: Field 'clojure.lang.RT.OutVar' 
 not found.

 2. when using Clojure.Main.exe:

 Exception: System.TypeLoadException: Could not load type 
 'Clojure.CljMain' from assembly 'Clojure.Main, Version=1.0.0.0, 
 Culture=neutral, PublicKeyToken=null'.

 It would be great if anybody can let me know what's going on.

 Shantanu



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

Re: ClojureCLR errors on Mono Linux

[Shantanu Kumar]

Thanks David, and sorry for the insufficient bug details. I tested this on 
64-bit Ubuntu where it works fine; however, the problem shows up on 32-bit 
Ubuntu.

I will post the exact steps in the evening on how to replicate the issue on 
32-bit Ubuntu.

Shantanu

On Wednesday, 19 December 2012 02:00:53 UTC+5:30, dmiller wrote:

 Shantanu,

 I created an Ubuntu 12.10 VM running in VirtualBox on my Win7 PC.  
 I installed Mono 2.10.8.
 I downloaded the zip for ClojureCLR 1.4.0 Debug-4.0.
 Extracted.
  mono Clojure.Main.exe  
 Runs with no problem.

  mono Clojure.Compile.exe test.junk
 Runs with no problem.

 From the errors you report, I can only guess that some pre-1.4 DLLs are 
 being found somehow and loaded.  
 For example,  the field clojure.lang.RT.OutVar did not exist in ClojureCLR 
 1.3.

 I do not know how else to help.

 -David
  


 On Saturday, December 15, 2012 10:17:59 PM UTC-6, Shantanu Kumar wrote:

 This is when using ClojureCLR 1.4.0 Debug-4.0 version.

 Shantanu

 On Sunday, 16 December 2012 09:45:21 UTC+5:30, Shantanu Kumar wrote:

 Hi,

 I noticed the following ClojureCLR errors using Mono 2.10 on Ubuntu 
 12.04 (they do not happen on Windows using either .NET or Mono):

 1. when running Clojure.Compile.exe:

 Exception: System.MissingFieldException: Field 'clojure.lang.RT.OutVar' 
 not found.

 2. when using Clojure.Main.exe:

 Exception: System.TypeLoadException: Could not load type 
 'Clojure.CljMain' from assembly 'Clojure.Main, Version=1.0.0.0, 
 Culture=neutral, PublicKeyToken=null'.

 It would be great if anybody can let me know what's going on.

 Shantanu



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

Re: ClojureCLR errors on Mono Linux

[dmiller]

Shantanu,

I don't have a Linux box available at this point to test, but I'll try it 
on Mac w/ Mono when I get a chance.
I don't have a clue how a field disappears between platforms.

-David


On Saturday, December 15, 2012 10:15:21 PM UTC-6, Shantanu Kumar wrote:

 Hi,

 I noticed the following ClojureCLR errors using Mono 2.10 on Ubuntu 12.04 
 (they do not happen on Windows using either .NET or Mono):

 1. when running Clojure.Compile.exe:

 Exception: System.MissingFieldException: Field 'clojure.lang.RT.OutVar' 
 not found.

 2. when using Clojure.Main.exe:

 Exception: System.TypeLoadException: Could not load type 'Clojure.CljMain' 
 from assembly 'Clojure.Main, Version=1.0.0.0, Culture=neutral, 
 PublicKeyToken=null'.

 It would be great if anybody can let me know what's going on.

 Shantanu


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

ClojureCLR errors on Mono Linux

[Shantanu Kumar]

Hi,

I noticed the following ClojureCLR errors using Mono 2.10 on Ubuntu 12.04 
(they do not happen on Windows using either .NET or Mono):

1. when running Clojure.Compile.exe:

Exception: System.MissingFieldException: Field 'clojure.lang.RT.OutVar' not 
found.

2. when using Clojure.Main.exe:

Exception: System.TypeLoadException: Could not load type 'Clojure.CljMain' 
from assembly 'Clojure.Main, Version=1.0.0.0, Culture=neutral, 
PublicKeyToken=null'.

It would be great if anybody can let me know what's going on.

Shantanu

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

Re: ClojureCLR errors on Mono Linux

[Shantanu Kumar]

This is when using ClojureCLR 1.4.0 Debug-4.0 version.

Shantanu

On Sunday, 16 December 2012 09:45:21 UTC+5:30, Shantanu Kumar wrote:

 Hi,

 I noticed the following ClojureCLR errors using Mono 2.10 on Ubuntu 12.04 
 (they do not happen on Windows using either .NET or Mono):

 1. when running Clojure.Compile.exe:

 Exception: System.MissingFieldException: Field 'clojure.lang.RT.OutVar' 
 not found.

 2. when using Clojure.Main.exe:

 Exception: System.TypeLoadException: Could not load type 'Clojure.CljMain' 
 from assembly 'Clojure.Main, Version=1.0.0.0, Culture=neutral, 
 PublicKeyToken=null'.

 It would be great if anybody can let me know what's going on.

 Shantanu


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

Re: Reader errors with Datomic free

[Pierre-Henry Perret]

I've that result (with same config):
___
user #db/id[:db.part/db]
#db/id[:db.part/db -125]
___

The # char is a special char for the reader. Be careful to have redefined 
it in your namespace ?..

Le jeudi 26 juillet 2012 00:02:50 UTC+2, tbc++ a écrit :

 I'm using the new Clojars version of datomic-free: 

 (defproject clj-lobapp 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} 
   :plugins [[lein-localrepo 0.4.0]] 
   :dependencies [[org.clojure/clojure 1.4.0] 
  [com.datomic/datomic 0.8.3335]]) 


 user= ;; make in memory database 
(use '[datomic.api :only (q db) :as d]) 
 nil 
 user= (def uri datomic:mem://matches) 
 #'user/uri 
 user= (d/create-database uri) 
 true 
 user= (def conn (d/connect uri)) 
 #'user/conn 
 user= 

 user= #db/id [:db.part/db] 
 #RuntimeException java.lang.RuntimeException: No reader function for tag 
 db/id 
 nil 
 user= *data-readers* 
 {base64 #'datomic.codec/base-64-literal, db/fn 
 #'datomic.function/construct, db/id #'datomic.db/id-literal} 
 user= (get *data-readers* 'db/id) 
 #'datomic.db/id-literal 
 user= ((get *data-readers* 'db/id) :db.part/db) 
 UnsupportedOperationException nth not supported on this type: Keyword 
 clojure.lang.RT.nthFrom (RT.java:787) 

 user= ((get *data-readers* 'db/id) [:db.part/db]) 
 #db/id[:db.part/db -100] 



 What am I missing here? 


 Thanks, 

 Timothy Baldridge 


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

Re: Reader errors with Datomic free

[Colin Jones]

In Leiningen, the reader side is in a different process (owned by 
Leiningen, without your project code on the classpath), than the execution 
side. So I think you see this error due to classpath separation: the lein 
side doesn't have data_readers.clj specification, or the reader functions 
defined in the project. 

Short-term, you can use `lein trampoline repl` instead of `lein repl` to 
fix this, assuming it's the root problem.

I guess we'll need to do some thinking about what reader-side things would 
need to change to accommodate custom reader literals in a cross-process 
scenario. Simple things like a line consisting of only the reader literal 
could be made to work by catching exceptions, but we use the Clojure reader 
to decide when the user is done entering input, then pass the plaintext to 
the server. So if we're not done with a form when we hit the exception, as 
is the case in `(def x #db/id [:db/part.db] )`, we're stuck not knowing 
whether the form is really complete or not, only that the reader failed to 
read a reader literal.

It seems like ideally we'd have in-hand on the reader side what all the 
data_readers.clj files have on the execution side *and* the functions 
defining them, but it seems scary to have a server shipping code to execute 
directly on the reader side.

Or maybe [hopefully] there's a more elegant solution that I'm missing?



On Wednesday, July 25, 2012 5:02:50 PM UTC-5, tbc++ wrote:

 I'm using the new Clojars version of datomic-free: 

 (defproject clj-lobapp 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} 
   :plugins [[lein-localrepo 0.4.0]] 
   :dependencies [[org.clojure/clojure 1.4.0] 
  [com.datomic/datomic 0.8.3335]]) 


 user= ;; make in memory database 
(use '[datomic.api :only (q db) :as d]) 
 nil 
 user= (def uri datomic:mem://matches) 
 #'user/uri 
 user= (d/create-database uri) 
 true 
 user= (def conn (d/connect uri)) 
 #'user/conn 
 user= 

 user= #db/id [:db.part/db] 
 #RuntimeException java.lang.RuntimeException: No reader function for tag 
 db/id 
 nil 
 user= *data-readers* 
 {base64 #'datomic.codec/base-64-literal, db/fn 
 #'datomic.function/construct, db/id #'datomic.db/id-literal} 
 user= (get *data-readers* 'db/id) 
 #'datomic.db/id-literal 
 user= ((get *data-readers* 'db/id) :db.part/db) 
 UnsupportedOperationException nth not supported on this type: Keyword 
 clojure.lang.RT.nthFrom (RT.java:787) 

 user= ((get *data-readers* 'db/id) [:db.part/db]) 
 #db/id[:db.part/db -100] 



 What am I missing here? 


 Thanks, 

 Timothy Baldridge 


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

Reader errors with Datomic free

[Timothy Baldridge]

I'm using the new Clojars version of datomic-free:

(defproject clj-lobapp 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}
  :plugins [[lein-localrepo 0.4.0]]
  :dependencies [[org.clojure/clojure 1.4.0]
 [com.datomic/datomic 0.8.3335]])


user= ;; make in memory database
   (use '[datomic.api :only (q db) :as d])
nil
user= (def uri datomic:mem://matches)
#'user/uri
user= (d/create-database uri)
true
user= (def conn (d/connect uri))
#'user/conn
user=

user= #db/id [:db.part/db]
#RuntimeException java.lang.RuntimeException: No reader function for tag db/id
nil
user= *data-readers*
{base64 #'datomic.codec/base-64-literal, db/fn
#'datomic.function/construct, db/id #'datomic.db/id-literal}
user= (get *data-readers* 'db/id)
#'datomic.db/id-literal
user= ((get *data-readers* 'db/id) :db.part/db)
UnsupportedOperationException nth not supported on this type: Keyword
clojure.lang.RT.nthFrom (RT.java:787)

user= ((get *data-readers* 'db/id) [:db.part/db])
#db/id[:db.part/db -100]



What am I missing here?


Thanks,

Timothy Baldridge

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

Re: Clojurescript One Errors

[George Oliver]

On Mar 16, 10:19 pm, John Collins johnben...@gmail.com wrote:
 I copied the clojurescript one project and made changes to the html files.

 When I do (go) after `lein repl` I get errors in the browser about not
 being able to resolve some namespaces. And also the wiki makes no mention
 how to compile the project after any modifications to the files. So please
 I need help on how to do this compilation step as I suspect that could be
 the cause why all the namespaces are not being resolved properly.

You should be able to edit the files, see the changes in your browser
and not worry about compiling. In brief what changes did you make to
which files and what was the error?

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

Clojurescript One Errors

[John Collins]

I copied the clojurescript one project and made changes to the html files. 

When I do (go) after `lein repl` I get errors in the browser about not 
being able to resolve some namespaces. And also the wiki makes no mention 
how to compile the project after any modifications to the files. So please 
I need help on how to do this compilation step as I suspect that could be 
the cause why all the namespaces are not being resolved properly.

John

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

Re: Clojure CDT up, cont, down, local-names throws arity errors after hitting breakpoint

[Sean Neilan]

I know. The church of emacs is becoming more compelling each day.

As a convert from Vim, I have some baggage. I hope that won't be an issue.

On Sat, Feb 11, 2012 at 10:50 AM, George Jahad cloj...@blackbirdsystems.net
 wrote:

 SeanC is referring to is the fact that swank-cdt now works seamlessly
 with clojure-jack-in, thanks to the efforts @tavisrudd and the
 indefatigable technomancy.


 On Feb 9, 9:18 am, Sean Corfield seancorfi...@gmail.com wrote:
  On Wed, Feb 8, 2012 at 10:16 PM, George Jahad
 
  cloj...@blackbirdsystems.net wrote:
   If you use Emacs and Swank-clojure, it is much
   easier to use swank-cdt, as your UI:
 
  http://georgejahad.com/clojure/swank-cdt.html
 
  I just want to chime in and say swank-clojure 1.4.0 has made this
  process so much simpler and it really is a pleasure to work with! I
  had a nasty bug in my code the other day and was able to track it down
  and fix in only about an hour and a half using CDT this way - I
  dread to think how long it would have taken with a less integrated
  tool chain setup...
  --
  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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Clojure CDT up, cont, down, local-names throws arity errors after hitting breakpoint

[George Jahad]

SeanC is referring to is the fact that swank-cdt now works seamlessly
with clojure-jack-in, thanks to the efforts @tavisrudd and the
indefatigable technomancy.


On Feb 9, 9:18 am, Sean Corfield seancorfi...@gmail.com wrote:
 On Wed, Feb 8, 2012 at 10:16 PM, George Jahad

 cloj...@blackbirdsystems.net wrote:
  If you use Emacs and Swank-clojure, it is much
  easier to use swank-cdt, as your UI:

 http://georgejahad.com/clojure/swank-cdt.html

 I just want to chime in and say swank-clojure 1.4.0 has made this
 process so much simpler and it really is a pleasure to work with! I
 had a nasty bug in my code the other day and was able to track it down
 and fix in only about an hour and a half using CDT this way - I
 dread to think how long it would have taken with a less integrated
 tool chain setup...
 --
 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

Re: Clojure CDT up, cont, down, local-names throws arity errors after hitting breakpoint

[Sean Neilan]

On Thu, Feb 9, 2012 at 8:20 PM, Phil Hagelberg p...@hagelb.org wrote:

 Sean Neilan s...@seanneilan.com writes:

  It's on the github page at the top.

 Forgive me if I'm slow, but I can't find it. Can you be more specific?

 The canonical page for swank-clojure is
 https://github.com/technomancy/swank-clojure


Sorry about that. Yes, the swank-clojure github page, on the readme under
the Usage heading. It says to install.. wait.. nevermind, it says to
install clojure-mode from the repo.

OK, that's my bad. I misread directions.


 Are you talking about instructions for using swank-clojure.el or
 something else?


I think I meant for using swank-clojure.el.


  It does say to use 1.3.4 over here:
  http://dev.clojure.org/display/doc/Getting+Started+with+Emacs
  That's definitely one of the things I got confused on. As a noob, I
  take dev.clojure.org as gospel since it's part of clojure.org.

 Yes, that was a bit confusing because development on 1.4.0 was blocked
 on getting a stable version of the cdt debugger released, so we went
 back to working on 1.3.x for a while. But that's no longer an issue.



I understand now. There's a lot of information out there still. All the
extra info confused me. I now know that the swank-clojure github page is
the canonical page.


 -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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Clojure CDT up, cont, down, local-names throws arity errors after hitting breakpoint

[Sean Corfield]

On Wed, Feb 8, 2012 at 10:16 PM, George Jahad
cloj...@blackbirdsystems.net wrote:
 If you use Emacs and Swank-clojure, it is much
 easier to use swank-cdt, as your UI:

 http://georgejahad.com/clojure/swank-cdt.html

I just want to chime in and say swank-clojure 1.4.0 has made this
process so much simpler and it really is a pleasure to work with! I
had a nasty bug in my code the other day and was able to track it down
and fix in only about an hour and a half using CDT this way - I
dread to think how long it would have taken with a less integrated
tool chain setup...
-- 
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

Re: Clojure CDT up, cont, down, local-names throws arity errors after hitting breakpoint

[Sean Neilan]

It works! Thank you so much for looking into this! I really appreciate what
you have done.

I went through the rest of the documentation and found three other minor
misnomers.

One, if you set a breakpoint on a function defined in the repl, you'll have
problems. As long as anything you set a breakpoint on is defined in a
clojure source file, one should be fine.

Two, set-catch does not appear to take clojure error objects:
user= (set-catch clojure.lang.ArityException :all)
IllegalArgumentException No reference type found for class
clojure.lang.ArityException  cdt.events/set-catch (events.clj:326)
set-catch does take java error objects though. I haven't tested this yet.

Three, locals does not appear to work.
user= (locals (ct) (cf))
RuntimeException Unreadable form  clojure.lang.Util.runtimeException
(Util.java:156)

Thank you again for writing CDT! It is a life saver.

On Thu, Feb 9, 2012 at 12:16 AM, George Jahad
cloj...@blackbirdsystems.netwrote:

 Sorry about that.  As you noticed the doc here was out of date:

 http://georgejahad.com/clojure/cdt.html

 It should be fixed now.

 Just for your reference however that doc only describes the command
 line version of CDT.  If you use Emacs and Swank-clojure, it is much
 easier to use swank-cdt, as your UI:

 http://georgejahad.com/clojure/swank-cdt.html



 On Feb 8, 11:11 am, Sean Neilan sneil...@gmail.com wrote:
  Hi All,
 
  I'm using Clojure 1.3.0 with CDT 1.2.6.2 on OSX Lion with Java 1.6.
 
  I want to set a breakpoint on -main on the program to be debugged. So,
  run lein repl on this program. It opens up port 8030 successfully.
  (This is based off the documentation here:
 http://georgejahad.com/clojure/cdt.html)
  seans-macaroni-book:gslisp seanneilan$ lein repl
  Listening for transport dt_socket at address: 8030
  REPL started; server listening on localhost port 13575
 
  Then, I start up a new shell in a different project and do this to
  attach to the program to be debugged:
  seans-macaroni-book:cdt seanneilan$ lein repl
  REPL started; server listening on localhost port 57048
  user= (use 'cdt.ui)
  nil
  user= (cdt-attach 8030)
  nil
  user= CDT ready
 
  It attaches correctly. Then, I set the breakpoint on -main
  user= (set-bp gslisp.core/-main)
  bp set on (#LocationImpl gslisp.core$_main:240)
  nil
 
  Then, in the other shell, I call -main
  gslisp.core= (-main)
  which correctly stalls
 
  In the debugger shell, I see
  user= Breakpoint #BreakpointEventImpl breakpointev...@gslisp.core
  $_main:240 in thread Thread-2 hit
  CDT location is /Users/seanneilan/BucketsOfNantucket/research/gslisp/
  src/gslisp/core.clj:240:0:
 
  But, if I try to type any debugging commands, I get this:
  user= (locals)
  ArityException Wrong number of args (0) passed to: reval$locals
  clojure.lang.AFn.throwArity (AFn.java:437)
  user= (up)
  ArityException Wrong number of args (0) passed to: ui$up
  clojure.lang.AFn.throwArity (AFn.java:437)
  user= (down)
  ArityException Wrong number of args (0) passed to: ui$down
  clojure.lang.AFn.throwArity (AFn.java:437)
  user= (up 1)
  ArityException Wrong number of args (1) passed to: ui$up
  clojure.lang.AFn.throwArity (AFn.java:437)
  user= (up 0 0)
  IllegalArgumentException No matching field found: frames for class
  java.lang.Long  clojure.lang.Reflector.getInstanceField
  (Reflector.java:289)
  user= (print-frames)
  ArityException Wrong number of args (0) passed to: ui$print-frames
  clojure.lang.AFn.throwArity (AFn.java:437)
  user= (cont)
  CompilerException java.lang.RuntimeException: Unable to resolve
  symbol: cont in this context, compiling:(NO_SOURCE_PATH:20)
 
  So basically the breakpoint hits but I can't run any debugging
  commands.

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


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

Re: Clojure CDT up, cont, down, local-names throws arity errors after hitting breakpoint

[Sean Neilan]

I agree. I'm a Vim user currently but with Lisp/Clojure, Emacs is the way
to go.

On Thu, Feb 9, 2012 at 11:18 AM, Sean Corfield seancorfi...@gmail.comwrote:

 On Wed, Feb 8, 2012 at 10:16 PM, George Jahad
 cloj...@blackbirdsystems.net wrote:
  If you use Emacs and Swank-clojure, it is much
  easier to use swank-cdt, as your UI:
 
  http://georgejahad.com/clojure/swank-cdt.html

 I just want to chime in and say swank-clojure 1.4.0 has made this
 process so much simpler and it really is a pleasure to work with! I
 had a nasty bug in my code the other day and was able to track it down
 and fix in only about an hour and a half using CDT this way - I
 dread to think how long it would have taken with a less integrated
 tool chain setup...
 --
 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Clojure CDT up, cont, down, local-names throws arity errors after hitting breakpoint

[Sean Neilan]

There's so much documentation about how to set up emacs with clojure but
not a lot of sources saying which documentation works.

Should I trust the readme for swank-clojure, the dev.clojure.org site, the
comments on dev.clojure.org, the blog post at technomancy.us/149 or the
radically simplified setup
herehttp://groups.google.com/group/clojure/browse_thread/thread/91d4f13090afb876/97f8d88255d58798?
Or, if I use the readme from swank-clojure, can I trust the part about how
swank-clojure is available as an emacs package? (I remember somebody
somewhere said it doesn't currently work.) Also, somebody somewhere else
said there are issues with swank-clojure 1.4.0 and that I should use 1.3.x
instead.

I hope I don't sound annoying.. I just don't know who to follow.

On Thu, Feb 9, 2012 at 11:35 AM, Sean Neilan s...@seanneilan.com wrote:

 I agree. I'm a Vim user currently but with Lisp/Clojure, Emacs is the way
 to go.


 On Thu, Feb 9, 2012 at 11:18 AM, Sean Corfield seancorfi...@gmail.comwrote:

 On Wed, Feb 8, 2012 at 10:16 PM, George Jahad
 cloj...@blackbirdsystems.net wrote:
  If you use Emacs and Swank-clojure, it is much
  easier to use swank-cdt, as your UI:
 
  http://georgejahad.com/clojure/swank-cdt.html

 I just want to chime in and say swank-clojure 1.4.0 has made this
 process so much simpler and it really is a pleasure to work with! I
 had a nasty bug in my code the other day and was able to track it down
 and fix in only about an hour and a half using CDT this way - I
 dread to think how long it would have taken with a less integrated
 tool chain setup...
 --
 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Clojure CDT up, cont, down, local-names throws arity errors after hitting breakpoint

[Phil Hagelberg]

Sean Neilan s...@seanneilan.com writes:

 Should I trust the readme for swank-clojure, the dev.clojure.org
 site, the comments on dev.clojure.org, the blog post at 
 technomancy.us/149 or the radically simplified setup here?

The swank-clojure readme should be the most reliable. You may find a
better explanation of how all the pieces fit together elsewhere, but for
swank-clojure itself, trust the readme.

 can I trust the part about how swank-clojure is available as an emacs
 package?

No, that's very old. Where are you seeing it?

 Also, somebody somewhere else said there are issues with swank-clojure
 1.4.0 and that I should use 1.3.x instead.

Do you remember any details? For a time the 1.4.0-SNAPSHOT was behind on
the elisp payload stuff, but it should be fine now.

-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

Re: Clojure CDT up, cont, down, local-names throws arity errors after hitting breakpoint

[Sean Neilan]

On Thu, Feb 9, 2012 at 7:06 PM, Phil Hagelberg p...@hagelb.org wrote:

 Sean Neilan s...@seanneilan.com writes:

  Should I trust the readme for swank-clojure, the dev.clojure.org
  site, the comments on dev.clojure.org, the blog post at
  technomancy.us/149 or the radically simplified setup here?

 The swank-clojure readme should be the most reliable. You may find a
 better explanation of how all the pieces fit together elsewhere, but for
 swank-clojure itself, trust the readme.

  can I trust the part about how swank-clojure is available as an emacs
  package?

 No, that's very old. Where are you seeing it?


It's on the github page at the top.
The emacs packages are mentioned as deprecated here:
http://groups.google.com/group/clojure/browse_thread/thread/1d3f308b1bc3dc61
I guess I confused the marmelade repo with whatever repo was mentioned in
that thread.

I'm sorry, I'm used to really bad documentation in the open source world.
If someone says somewhere
something is not working, my instinct is to take that with a grain of salt
even if it's just a random person
on the internet. I'll give swank-clojure a shot tonight.

Clearly, your software is more polished than I assumed it would be. :)
(based on too much past experience in the open source world.)



  Also, somebody somewhere else said there are issues with swank-clojure
  1.4.0 and that I should use 1.3.x instead.

 Do you remember any details? For a time the 1.4.0-SNAPSHOT was behind on
 the elisp payload stuff, but it should be fine now.


I can't find it again :( But, it was about how the 1.4.0-SNAPSHOT was
behind.

It does say to use 1.3.4 over here:
http://dev.clojure.org/display/doc/Getting+Started+with+Emacs
That's definitely one of the things I got confused on. As a noob, I take
dev.clojure.org as g
ospel since it's part of clojure.org.



 -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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Clojure CDT up, cont, down, local-names throws arity errors after hitting breakpoint

[Phil Hagelberg]

Sean Neilan s...@seanneilan.com writes:

 It's on the github page at the top.

Forgive me if I'm slow, but I can't find it. Can you be more specific?

The canonical page for swank-clojure is
https://github.com/technomancy/swank-clojure

Are you talking about instructions for using swank-clojure.el or
something else?

 It does say to use 1.3.4 over here:
 http://dev.clojure.org/display/doc/Getting+Started+with+Emacs
 That's definitely one of the things I got confused on. As a noob, I
 take dev.clojure.org as gospel since it's part of clojure.org.

Yes, that was a bit confusing because development on 1.4.0 was blocked
on getting a stable version of the cdt debugger released, so we went
back to working on 1.3.x for a while. But that's no longer an issue.

-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

Clojure CDT up, cont, down, local-names throws arity errors after hitting breakpoint

[Sean Neilan]

Hi All,

I'm using Clojure 1.3.0 with CDT 1.2.6.2 on OSX Lion with Java 1.6.

I want to set a breakpoint on -main on the program to be debugged. So,
run lein repl on this program. It opens up port 8030 successfully.
(This is based off the documentation here: 
http://georgejahad.com/clojure/cdt.html)
seans-macaroni-book:gslisp seanneilan$ lein repl
Listening for transport dt_socket at address: 8030
REPL started; server listening on localhost port 13575

Then, I start up a new shell in a different project and do this to
attach to the program to be debugged:
seans-macaroni-book:cdt seanneilan$ lein repl
REPL started; server listening on localhost port 57048
user= (use 'cdt.ui)
nil
user= (cdt-attach 8030)
nil
user= CDT ready

It attaches correctly. Then, I set the breakpoint on -main
user= (set-bp gslisp.core/-main)
bp set on (#LocationImpl gslisp.core$_main:240)
nil

Then, in the other shell, I call -main
gslisp.core= (-main)
which correctly stalls

In the debugger shell, I see
user= Breakpoint #BreakpointEventImpl breakpointev...@gslisp.core
$_main:240 in thread Thread-2 hit
CDT location is /Users/seanneilan/BucketsOfNantucket/research/gslisp/
src/gslisp/core.clj:240:0:

But, if I try to type any debugging commands, I get this:
user= (locals)
ArityException Wrong number of args (0) passed to: reval$locals
clojure.lang.AFn.throwArity (AFn.java:437)
user= (up)
ArityException Wrong number of args (0) passed to: ui$up
clojure.lang.AFn.throwArity (AFn.java:437)
user= (down)
ArityException Wrong number of args (0) passed to: ui$down
clojure.lang.AFn.throwArity (AFn.java:437)
user= (up 1)
ArityException Wrong number of args (1) passed to: ui$up
clojure.lang.AFn.throwArity (AFn.java:437)
user= (up 0 0)
IllegalArgumentException No matching field found: frames for class
java.lang.Long  clojure.lang.Reflector.getInstanceField
(Reflector.java:289)
user= (print-frames)
ArityException Wrong number of args (0) passed to: ui$print-frames
clojure.lang.AFn.throwArity (AFn.java:437)
user= (cont)
CompilerException java.lang.RuntimeException: Unable to resolve
symbol: cont in this context, compiling:(NO_SOURCE_PATH:20)

So basically the breakpoint hits but I can't run any debugging
commands.

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

Re: Clojure CDT up, cont, down, local-names throws arity errors after hitting breakpoint

[George Jahad]

Sorry about that.  As you noticed the doc here was out of date:

http://georgejahad.com/clojure/cdt.html

It should be fixed now.

Just for your reference however that doc only describes the command
line version of CDT.  If you use Emacs and Swank-clojure, it is much
easier to use swank-cdt, as your UI:

http://georgejahad.com/clojure/swank-cdt.html



On Feb 8, 11:11 am, Sean Neilan sneil...@gmail.com wrote:
 Hi All,

 I'm using Clojure 1.3.0 with CDT 1.2.6.2 on OSX Lion with Java 1.6.

 I want to set a breakpoint on -main on the program to be debugged. So,
 run lein repl on this program. It opens up port 8030 successfully.
 (This is based off the documentation 
 here:http://georgejahad.com/clojure/cdt.html)
 seans-macaroni-book:gslisp seanneilan$ lein repl
 Listening for transport dt_socket at address: 8030
 REPL started; server listening on localhost port 13575

 Then, I start up a new shell in a different project and do this to
 attach to the program to be debugged:
 seans-macaroni-book:cdt seanneilan$ lein repl
 REPL started; server listening on localhost port 57048
 user= (use 'cdt.ui)
 nil
 user= (cdt-attach 8030)
 nil
 user= CDT ready

 It attaches correctly. Then, I set the breakpoint on -main
 user= (set-bp gslisp.core/-main)
 bp set on (#LocationImpl gslisp.core$_main:240)
 nil

 Then, in the other shell, I call -main
 gslisp.core= (-main)
 which correctly stalls

 In the debugger shell, I see
 user= Breakpoint #BreakpointEventImpl breakpointev...@gslisp.core
 $_main:240 in thread Thread-2 hit
 CDT location is /Users/seanneilan/BucketsOfNantucket/research/gslisp/
 src/gslisp/core.clj:240:0:

 But, if I try to type any debugging commands, I get this:
 user= (locals)
 ArityException Wrong number of args (0) passed to: reval$locals
 clojure.lang.AFn.throwArity (AFn.java:437)
 user= (up)
 ArityException Wrong number of args (0) passed to: ui$up
 clojure.lang.AFn.throwArity (AFn.java:437)
 user= (down)
 ArityException Wrong number of args (0) passed to: ui$down
 clojure.lang.AFn.throwArity (AFn.java:437)
 user= (up 1)
 ArityException Wrong number of args (1) passed to: ui$up
 clojure.lang.AFn.throwArity (AFn.java:437)
 user= (up 0 0)
 IllegalArgumentException No matching field found: frames for class
 java.lang.Long  clojure.lang.Reflector.getInstanceField
 (Reflector.java:289)
 user= (print-frames)
 ArityException Wrong number of args (0) passed to: ui$print-frames
 clojure.lang.AFn.throwArity (AFn.java:437)
 user= (cont)
 CompilerException java.lang.RuntimeException: Unable to resolve
 symbol: cont in this context, compiling:(NO_SOURCE_PATH:20)

 So basically the breakpoint hits but I can't run any debugging
 commands.

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

Re: Clojure CDT up, cont, down, local-names throws arity errors after hitting breakpoint

[George Jahad]

forgot to mention that Hugo Duncan is also working on a debugger which
can
be found here:
https://github.com/pallet/ritz

On Feb 8, 10:16 pm, George Jahad cloj...@blackbirdsystems.net wrote:
 Sorry about that.  As you noticed the doc here was out of date:

 http://georgejahad.com/clojure/cdt.html

 It should be fixed now.

 Just for your reference however that doc only describes the command
 line version of CDT.  If you use Emacs and Swank-clojure, it is much
 easier to use swank-cdt, as your UI:

 http://georgejahad.com/clojure/swank-cdt.html

 On Feb 8, 11:11 am, Sean Neilan sneil...@gmail.com wrote:

  Hi All,

  I'm using Clojure 1.3.0 with CDT 1.2.6.2 on OSX Lion with Java 1.6.

  I want to set a breakpoint on -main on the program to be debugged. So,
  run lein repl on this program. It opens up port 8030 successfully.
  (This is based off the documentation 
  here:http://georgejahad.com/clojure/cdt.html)
  seans-macaroni-book:gslisp seanneilan$ lein repl
  Listening for transport dt_socket at address: 8030
  REPL started; server listening on localhost port 13575

  Then, I start up a new shell in a different project and do this to
  attach to the program to be debugged:
  seans-macaroni-book:cdt seanneilan$ lein repl
  REPL started; server listening on localhost port 57048
  user= (use 'cdt.ui)
  nil
  user= (cdt-attach 8030)
  nil
  user= CDT ready

  It attaches correctly. Then, I set the breakpoint on -main
  user= (set-bp gslisp.core/-main)
  bp set on (#LocationImpl gslisp.core$_main:240)
  nil

  Then, in the other shell, I call -main
  gslisp.core= (-main)
  which correctly stalls

  In the debugger shell, I see
  user= Breakpoint #BreakpointEventImpl breakpointev...@gslisp.core
  $_main:240 in thread Thread-2 hit
  CDT location is /Users/seanneilan/BucketsOfNantucket/research/gslisp/
  src/gslisp/core.clj:240:0:

  But, if I try to type any debugging commands, I get this:
  user= (locals)
  ArityException Wrong number of args (0) passed to: reval$locals
  clojure.lang.AFn.throwArity (AFn.java:437)
  user= (up)
  ArityException Wrong number of args (0) passed to: ui$up
  clojure.lang.AFn.throwArity (AFn.java:437)
  user= (down)
  ArityException Wrong number of args (0) passed to: ui$down
  clojure.lang.AFn.throwArity (AFn.java:437)
  user= (up 1)
  ArityException Wrong number of args (1) passed to: ui$up
  clojure.lang.AFn.throwArity (AFn.java:437)
  user= (up 0 0)
  IllegalArgumentException No matching field found: frames for class
  java.lang.Long  clojure.lang.Reflector.getInstanceField
  (Reflector.java:289)
  user= (print-frames)
  ArityException Wrong number of args (0) passed to: ui$print-frames
  clojure.lang.AFn.throwArity (AFn.java:437)
  user= (cont)
  CompilerException java.lang.RuntimeException: Unable to resolve
  symbol: cont in this context, compiling:(NO_SOURCE_PATH:20)

  So basically the breakpoint hits but I can't run any debugging
  commands.

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

Re: Errors w/ dynamic symbols in macro-utils or monads?

[Andrew]

Does this still happen for you? It appears to still be the case in my 
environment. Dropping back to Clojure *1.2.1* seems to work but in addition 
to trying out monads, I need to use a library (clj-webdriver) that relies 
on Clojure *1.3.0*  What to do?

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

Re: Errors w/ dynamic symbols in macro-utils or monads?

[Andrew]

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

clojure.contrib.monads
   
   - Migrated to clojure.algo.monads - lead Konrad 
Hinsenhttp://dev.clojure.org/jira/secure/ViewProfile.jspa?name=khinsen
   .
   - Status: latest build 
statushttp://build.clojure.org/job/algo.monads-test-matrix/, 
   latest release on 
Mavenhttp://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.clojure%22%20AND%20a%3A%22algo.monads%22,
 
   report bugs http://dev.clojure.org/jira/browse/ALGOM.


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

good ways to deal with compiler errors in SLIME (emacs)

[Sergey Didenko]

Hi,

How can I see the error line number in SLIME? Or even somehow place editor
point on the place of the error?

For example when I load file in a lein repl, it prints:

java.lang.Exception: Unable to resolve symbol: dd in this context
(mytest.clj:447)

However when I load this file in the SLIME repl it just prints:

Unable to resolve symbol: dd in this context
...
0 [QUIT] Quit to the SLIME top level

and a long backtrace without error line information.

P.S. Sorry, if this is offtopic.

Regards, Sergey.

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

Re: good ways to deal with compiler errors in SLIME (emacs)

[Phil Hagelberg]

On Tue, Sep 13, 2011 at 1:55 AM, Sergey Didenko
sergey.dide...@gmail.com wrote:
 How can I see the error line number in SLIME? Or even somehow place editor
 point on the place of the error?

 However when I load this file in the SLIME repl it just prints:

 Unable to resolve symbol: dd in this context

If you compile using C-c C-k (where it sends the filename instead of
the contents of the file) then it can determine line numbering.

-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

Re: good ways to deal with compiler errors in SLIME (emacs)

[Sergey Didenko]

Thanks, Phil !

That's it. I was using slime-load-file instead of
slime-compile-and-load-file

If you compile using C-c C-k (where it sends the filename instead of
 the contents of the file) then it can determine line numbering.



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

Re: http-client and ignoring ssl errors

[John Newman]

Maybe I should just build the SSL logic into http-client.core/request and
have request instantiate a different DefaultHttpClient based on the value of
:noauth in the request map?

Will try when I get home.

John


On Thu, Sep 1, 2011 at 4:31 PM, John Newman john...@gmail.com wrote:

 Hello All,

 I am trying to add some functionality to http-client.  Basically, I need
 the ability to do get requests on a server while ignoring ssl errors.  Once
 I figure out how to get it working, I'll put it up on github and people can
 pull it if they'd like.

 I am working from a fork of http-client that has support for cookies,
 located here: https://github.com/r0man/clj-http/commits/cookies

 I used r0man's changes (
 https://github.com/r0man/clj-http/commit/f8152c6182c148539148fdc7f77faab14b7567c3)
 as an example of what I needed to change in order to add ssl error ignore
 capability.

 I used some java wisdom from stackoverflow (
 http://stackoverflow.com/questions/2012497/accepting-a-certificate-for-https-on-android/3904473#3904473)
 to ignore ssl errors.

 I came up with this:

 src/http-client/client.clj

 ...
   (:use [clj-http.cookies :only (wrap-cookies)]
 [clj-http.noauth :only (wrap-noauth)])))
 ...
 and
 ...
 (defn wrap-request
   Returns a battaries-included HTTP request function coresponding to the
 given
core client. See client/client.
   [request]
   (- request
 wrap-noauth
 wrap-redirects
 wrap-exceptions
 ...

 I put wrap-noauth (which might have been a bad name) at the beginning
 because it takes the old client and actually returns a new one:

 src/http-client/noauth.clj

 (ns clj-http.noauth
   Allows client to ignore some SSL errors (only use in dev!)
   (:import (javax.net.ssl HostnameVerifier HttpsURLConnection))
   (:import (org.apache.http.conn.ssl SSLSocketFactory
 X509HostnameVerifier))
   (:import (org.apache.http.conn.scheme Scheme SchemeRegistry))
   (:import (org.apache.http.impl.client DefaultHttpClient))
   (:import (org.apache.http.impl.conn SingleClientConnManager)))

 (defn wrap-noauth [client]
   (fn [req]
 (if (:noauth req)
   (let [registry (SchemeRegistry.)
 hostname-verifier SSLSocketFactory/ALLOW_ALL_HOSTNAME_VERIFIER
 socket-factory (SSLSocketFactory/getSocketFactory)
 _ (.setHostnameVerifier
 socket-factory hostname-verifier)
 _ (.register registry (Scheme. https socket-factory 443))
 noauth-client (DefaultHttpClient.
 (SingleClientConnManager. (.getParams client)
 registry)
 (.getParams client))
 _ (HttpsURLConnection/setDefaultHostnameVerifier
 hostname-verifier)]
 (noauth-client req))
   (client req
 I essentially modeled wrap-noauth on the stackoverflow thread.

 When I run (c/get my-url {:noauth true :cookies ...

 I get:

 user= IllegalArgumentException No matching field found: getParams for
 class clojure.lang.Var  clojure.lang.Reflector.getInstanceField
 (Reflector.java:289)

 Taking the ':noauth true' out of the argument map makes the error go away.

 The only place I see getParams used is towards the beginning of the request
 function in core.clj

 src/http-client/core.clj
 ...
   (let [http-client (DefaultHttpClient.)]
 (try
   (- http-client
 (.getParams)
 (.setParameter ClientPNames/COOKIE_POLICY
 CookiePolicy/BROWSER_COMPATIBILITY))
   (let [http-url (str scheme :// server-name
 ...

 I'm still not sure what is going on... Am I breaking it by instantiating a
 new DefaultHttpClient?  Should a new key for noauth be put in the parameters
 to core/request [{:keys [noauth...  the cookies branch didn't do this, so I
 wasn't sure.

 Thanks in advance for the help.  Hopefully, once this is figured out, it
 will be useful to others as well.

 John


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

http-client and ignoring ssl errors

[John Newman]

Hello All,

I am trying to add some functionality to http-client.  Basically, I need the
ability to do get requests on a server while ignoring ssl errors.  Once I
figure out how to get it working, I'll put it up on github and people can
pull it if they'd like.

I am working from a fork of http-client that has support for cookies,
located here: https://github.com/r0man/clj-http/commits/cookies

I used r0man's changes (
https://github.com/r0man/clj-http/commit/f8152c6182c148539148fdc7f77faab14b7567c3)
as an example of what I needed to change in order to add ssl error ignore
capability.

I used some java wisdom from stackoverflow (
http://stackoverflow.com/questions/2012497/accepting-a-certificate-for-https-on-android/3904473#3904473)
to ignore ssl errors.

I came up with this:

src/http-client/client.clj

...
  (:use [clj-http.cookies :only (wrap-cookies)]
[clj-http.noauth :only (wrap-noauth)])))
...
and
...
(defn wrap-request
  Returns a battaries-included HTTP request function coresponding to the
given
   core client. See client/client.
  [request]
  (- request
wrap-noauth
wrap-redirects
wrap-exceptions
...

I put wrap-noauth (which might have been a bad name) at the beginning
because it takes the old client and actually returns a new one:

src/http-client/noauth.clj

(ns clj-http.noauth
  Allows client to ignore some SSL errors (only use in dev!)
  (:import (javax.net.ssl HostnameVerifier HttpsURLConnection))
  (:import (org.apache.http.conn.ssl SSLSocketFactory X509HostnameVerifier))
  (:import (org.apache.http.conn.scheme Scheme SchemeRegistry))
  (:import (org.apache.http.impl.client DefaultHttpClient))
  (:import (org.apache.http.impl.conn SingleClientConnManager)))

(defn wrap-noauth [client]
  (fn [req]
(if (:noauth req)
  (let [registry (SchemeRegistry.)
hostname-verifier SSLSocketFactory/ALLOW_ALL_HOSTNAME_VERIFIER
socket-factory (SSLSocketFactory/getSocketFactory)
_ (.setHostnameVerifier
socket-factory hostname-verifier)
_ (.register registry (Scheme. https socket-factory 443))
noauth-client (DefaultHttpClient.
(SingleClientConnManager. (.getParams client)
registry)
(.getParams client))
_ (HttpsURLConnection/setDefaultHostnameVerifier
hostname-verifier)]
(noauth-client req))
  (client req
I essentially modeled wrap-noauth on the stackoverflow thread.

When I run (c/get my-url {:noauth true :cookies ...

I get:

user= IllegalArgumentException No matching field found: getParams for class
clojure.lang.Var  clojure.lang.Reflector.getInstanceField
(Reflector.java:289)

Taking the ':noauth true' out of the argument map makes the error go away.

The only place I see getParams used is towards the beginning of the request
function in core.clj

src/http-client/core.clj
...
  (let [http-client (DefaultHttpClient.)]
(try
  (- http-client
(.getParams)
(.setParameter ClientPNames/COOKIE_POLICY
CookiePolicy/BROWSER_COMPATIBILITY))
  (let [http-url (str scheme :// server-name
...

I'm still not sure what is going on... Am I breaking it by instantiating a
new DefaultHttpClient?  Should a new key for noauth be put in the parameters
to core/request [{:keys [noauth...  the cookies branch didn't do this, so I
wasn't sure.

Thanks in advance for the help.  Hopefully, once this is figured out, it
will be useful to others as well.

John

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

Re: ClojureScript Compile errors

[David Nolen]

On Wed, Aug 10, 2011 at 7:39 AM, Rich Hickey richhic...@gmail.com wrote:

 :use … :only doesn't have the problems of full :use.

 Enhancement ticket and patch for :use … :only welcome. Note it must support
 :use … :only only, i.e. :only is required.

 Rich


http://dev.clojure.org/jira/browse/CLJS-65. Hopefully this is an ok
approach. Also couldn't find any tests related to namespace declaration
parsing so I didn't add any.

David

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

Errors in Clojure

[J . Pablo Fernández]

Hello Clojurians,

I'm struggling to work with errors in Clojure. This is one example, one 
case, but I had many like these before:

user= (load-file /Users/pupeno/Projects/mgr/src/lobos/migrations.clj)
org.postgresql.util.PSQLException: FATAL: role lobos does not exist 
(config.clj:1)

It just gives one line, no stack trace. config.clj looks like this:

(ns lobos.config)

(def db
  {:classname org.postgresql.Driver
   :subprotocol postgresql
   :subname //localhost:5432/mgr
   :user mgr
   :password chi1lie7Wai3ioP6aing3ooci})

What now? how do I start to unravel this? How would you do it?

Thanks.

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

Re: Errors in Clojure

[Ambrose Bonnaire-Sergeant]

Hi,

The last thrown Exception/Error is kept in the var *e.

You should be able to view the complete stack trace of the last thrown
exception by calling something like:

(.printStackTrace *e)

Ambrose

2011/8/19 J. Pablo Fernández pup...@pupeno.com

 Hello Clojurians,

 I'm struggling to work with errors in Clojure. This is one example, one
 case, but I had many like these before:

 user= (load-file /Users/pupeno/Projects/mgr/src/lobos/migrations.clj)
 org.postgresql.util.PSQLException: FATAL: role lobos does not exist
 (config.clj:1)

 It just gives one line, no stack trace. config.clj looks like this:

 (ns lobos.config)

 (def db
   {:classname org.postgresql.Driver
:subprotocol postgresql
:subname //localhost:5432/mgr
:user mgr
:password chi1lie7Wai3ioP6aing3ooci})

 What now? how do I start to unravel this? How would you do it?

 Thanks.

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

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

Re: Errors in Clojure

[Petr Gladkikh]

This is postgresql exception so problem is there (it's not Clojure's
one). Just try to connect via some other tool to confirm this, use
psql in command line, for example. Maybe there is missing group role
that is linked to login role 'mgr'.

PS: I hope that password is not a confidential one :)

2011/8/19 J. Pablo Fernández pup...@pupeno.com:
 Hello Clojurians,
 I'm struggling to work with errors in Clojure. This is one example, one
 case, but I had many like these before:
 user= (load-file /Users/pupeno/Projects/mgr/src/lobos/migrations.clj)
 org.postgresql.util.PSQLException: FATAL: role lobos does not exist
 (config.clj:1)
 It just gives one line, no stack trace. config.clj looks like this:
 (ns lobos.config)
 (def db
   {:classname org.postgresql.Driver
    :subprotocol postgresql
    :subname //localhost:5432/mgr
    :user mgr
    :password chi1lie7Wai3ioP6aing3ooci})
 What now? how do I start to unravel this? How would you do it?
 Thanks.

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



-- 
Petr Gladkikh

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