Re: Handling exceptions with Reader Conditionals

[Herwig Hochleitner]

2015-06-02 23:57 GMT+02:00 Daniel Compton :

> On the Reader Conditionals
>  dev
> discussion page at one part it talks about exception handling:
>
> "Exception handling, catching "all" - see issue below on why this is not a
> complete solution in either case."
>
> I looked further down the page and couldn't see a discussion of why this
> isn't a complete solution. The only mentions of exceptions talked about
> them at read time, but not in this context at run time. Is this mentioned
> somewhere, on this page or elsewhere?
>

You're right, there doesn't seem to be any further discussion of this on
the page. Probably a Copy&Paste error. I assume, it talks about the issue
that in javascript, anything can be thrown, even stuff that doesn't inherit
from js/Object.
Therefore, to catch really everything, you need to (catch :default ..) in
clojurescript.
Likewise, in java you need to catch java.lang.Throwable in order to catch
everything, though, in most code this is not advisable, since Throwables
that are not Exception are used for fatal errors, like OOM conditions.

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

[Mike Rodriguez]

Sorry for the delay in getting back with a response to this.  I think it is 
fairly clear in the Clojure Compiler that there is an exception that will 
wrap errors that occur during macroexpansion now.

Around 
here 
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L6627-L6649,
 
the Compiler.macroexpand1() now has a try-catch for Throwable around the 
evaluation of the macro invocation.
This was not the case in Clojure version 1.6.  See 
around 
https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/Compiler.java#L6548-L6560
 
for a reference point.

I'm fairly sure that is what has caused this change in behavior that broke 
our expectations that the exception types our code through during 
macroexpansion would propagate all the way back to the caller.  Again, I 
think this was a bad expectation to have, but it is a little tricky.

It is a little trickier for us to have any strong assertions on the type of 
exception that may come from a macro now.  Compiler$CompilerException seems 
too dependent on the implementation.  So we've opted to just assert there 
would be a is-thrown? RuntimeException in these sorts of tests.  If we want 
to test something like an ExceptionInfo's data map, we now just have to 
write a helper to walk the stack trace until we find it - which would 
likely be a single "step" up the trace.

A simple reproducing case:
*clojure-version* ;= {:major 1, :minor 7, :incremental 0, :qualifier "RC1"}

(defmacro demo [] (throw (ex-info "fail" {})))

(demo) ;= CompilerException clojure.lang.ExceptionInfo: fail {}, 
compiling:(form-init4053282905768384039.clj:1:1) 

vs.
*clojure-version* ;= {:major 1, :minor 6, :incremental 0, :qualifier nil}

(demo) ;= ExceptionInfo fail  clojure.core/ex-info (core.clj:4403)



On Saturday, May 23, 2015 at 8:52:47 AM UTC-5, Alex Miller wrote:
>
> I'm not aware of any wholesale changes with respect to compiler 
> exceptions. Can you give an example?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: [BUG?] loading Clojure source files from various data sources (classloading)

[Alex Fowler]

Hello again!

Well, it has been well over a week already. I appreciate the answers and 
works by the people who suggested the workarounds and the benign question 
about the version of Clojure we are using from the dev team. While the 
proposed workarounds are interesting in themselves and their technological 
complexity, and allow to somewhat approach the solution of that otherwise 
simple task, unfortunately, they do not really solve the problem for us: 
the thread bindings will be flushed on the next call to (require) from 
Clojure code, and creating a whole web service for classloading is an 
unaffordable overkill (though, again, thanks for sharing your thoughts and 
works, I understand that you have worked hard to create them, they just do 
not suit our usecase). Looks like we're failing.. another success story 
here.

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

[Marshall Bockrath-Vandegrift]

Richard Möhn  writes:

> How do I remove from a nested datastructure the objects whose (pr obj)
> representation doesn't comply with the EDN specification? Fx, 
> {:a 1 :b (find-ns 'user)} → {:a 1}
> Or, easier, how do I just not print these objects?

Additionally/alternatively to the 1.7.0 changes mentioned by Alex
Miller, check out:

https://github.com/llasram/letterpress

If you can stomach the (very gentle) monkey-patching, it provides the
ability to arbitrarily redefine and hook printing within a particular
dynamic scope.

-- 
Marshall Bockrath-Vandegrift 
Principal Software Engineer, Damballa R&D | 518.859.4559m

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: [BUG?] loading Clojure source files from various data sources (classloading)

[Gary Trakhman]

Have you considered registering custom URL scheme handlers? That's an
available point of extension at JVM process-level.  It should be possible
(though I don't know how painful) to implement custom URL connections that
grab from anywhere:
http://skife.org/java/url/library/2012/05/14/java_url_handlers.html

On Wed, Jun 3, 2015 at 11:06 AM Alex Fowler  wrote:

> Hello again!
>
> Well, it has been well over a week already. I appreciate the answers and
> works by the people who suggested the workarounds and the benign question
> about the version of Clojure we are using from the dev team. While the
> proposed workarounds are interesting in themselves and their technological
> complexity, and allow to somewhat approach the solution of that otherwise
> simple task, unfortunately, they do not really solve the problem for us:
> the thread bindings will be flushed on the next call to (require) from
> Clojure code, and creating a whole web service for classloading is an
> unaffordable overkill (though, again, thanks for sharing your thoughts and
> works, I understand that you have worked hard to create them, they just do
> not suit our usecase). Looks like we're failing.. another success story
> here.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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.

How to include ... in project.clj

[Jacob Goodson]

How would I get this to work?


...


snapshots-repo
https://oss.sonatype.org/content/repositories/snapshots
false
true


...

Then add sphinx4-core to the project dependencies:


  edu.cmu.sphinx
  sphinx4-core
  1.0-SNAPSHOT

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

[Jacob Goodson]

I tried this but it did not work...

:dependencies [[org.clojure/clojure "1.6.0"]
   [edu.cmu.sphinx/sphinx4-core "1.0-SNAPSHOT"]
   [edu.cmu.sphinx/sphinx4-data "1.0-SNAPSHOT"]]
:repositories {"snapshots-repo" 
"https://oss.sonatype.org/content/repositories/snapshots"})


On Wednesday, June 3, 2015 at 12:12:44 PM UTC-4, Jacob Goodson wrote:
>
> How would I get this to work?
>
> 
> ...
> 
> 
> snapshots-repo
> https://oss.sonatype.org/content/repositories/snapshots
> false
> true
> 
> 
> ...
>
> Then add sphinx4-core to the project dependencies:
>
> 
>   edu.cmu.sphinx
>   sphinx4-core
>   1.0-SNAPSHOT
>
>

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

[Steve Ashton]

Try:

:repositories [["..." "url"]]

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

Typed Clojure Crowdfunding 2015 Appeal

[Ambrose Bonnaire-Sergeant]

Hi all,

I have started a crowdfunding campaign

to add "real" Gradual Typing to Typed Clojure. This work will result in
more robust interactions with code checked with core.typed, and better
integration into the compilation process.

Your support and shares are greatly appreciated. As usual this is all open
source work.

If you're eager to use the fruits of this work, check out this screencast
 which outlines the latest
Typed REPL and automatic integration into the compilation process.

Thanks,
Ambrose

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

[Elric Erkose]

@tassilo Your concern could be addressed with a NullReader

user=> (defn NullReader []
 (proxy [java.io.Reader] []
   (close [] nil)
   (read [a b c] -1)))
#'user/NullReader

user=> (slurp (NullReader))
""

However, this does not resolve my question because "" is not nil. Even with 
a NullReader, one would have to "explicitly check for [before] hand or 
handle via try/catch after the fact", like @sean said, to distinguish a 
valid NullReader intent from an errant parameter.

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

[Gary Trakhman]

This is a bad idea, but you can extend IOFactory to nil within your own
programs:
https://github.com/clojure/clojure/blob/master/src/clj/clojure/java/io.clj#L182
to return your nullreader.

On Wed, Jun 3, 2015 at 3:28 PM Elric Erkose  wrote:

> @tassilo Your concern could be addressed with a NullReader
>
> user=> (defn NullReader []
>  (proxy [java.io.Reader] []
>(close [] nil)
>(read [a b c] -1)))
> #'user/NullReader
>
> user=> (slurp (NullReader))
> ""
>
> However, this does not resolve my question because "" is not nil. Even
> with a NullReader, one would have to "explicitly check for [before] hand or
> handle via try/catch after the fact", like @sean said, to distinguish a
> valid NullReader intent from an errant parameter.
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: (slurp nil)

[Elric Erkose]

@gary Agreed, bad idea.

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

[Scott Klarenbach]

I'm unable to post a new topic to the leinigen group so I thought I'd try 
my luck here.

I'd like to exclude certain dependencies from my uberjar, by using the 
:provided profile, but the jars are always included.

I've added the following to my project.clj, but the edu.stanford.nlp jars 
end up in the uberjar no matter what.  I've also tried with a simple 
project just to exclude a few jars and that doesn't seem to work either. 
 Am I missing something simple?  Or is there a better way to exclude large 
dependencies from uberjar if the deployment environment will already have 
them on the classpath?  Thanks.

:profiles {:uberjar {:aot :all}
 :provided {:dependencies
[[edu.stanford.nlp/stanford-corenlp "3.4.1"]
 [edu.stanford.nlp/stanford-corenlp "3.4.1"
  :classifier "models"]]}
 :dev {:resource-paths ["test-data"]}}

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

(clojure.java.io/resource "no-such-file")

[Elric Erkose]

The doc string for clojure.java.io/resource states that it returns a URL. 
When an invalid file is passed as the only parameter, it returns nil. 
Shouldn't we expect an Exception?

user=> (clojure.java.io/resource "no-such-file")
nil

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

[Marshall Bockrath-Vandegrift]

Scott Klarenbach  writes:

> I'd like to exclude certain dependencies from my uberjar, by using the
> :provided profile, but the jars are always included.

I believe the problem you’re seeing is due to the fact that Leiningen
doesn’t quite think about dependency `scope` the same way Maven does.
Adding a direct-only dependency to the `:provided` profile does mark it
as `provided` `scope` in any resulting `pom.xml` and does not include
the dependencies added to an uberjar.  But if one of your normal
dependencies *also* depends on the one you’ve added to `:provided`, then
the “provided-ness” isn’t propogated and it will get pulled into the
uberjar, just like any other indirect dependency.

The work-around is first to add the provided dependency to the
`:provided` profile as you’ve already done, then also add an
`:exclusion` for that same artifact, either at the top-level or on the
offending other direct dependencies.

HTH,

-- 
Marshall Bockrath-Vandegrift 
Principal Software Engineer, Damballa R&D

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

[Scott Klarenbach]

The issue was that I hadn't removed the dependencies from the toplevel 
vector.  Thanks to Jeremy Heiler for pointing that out.

On Wednesday, June 3, 2015 at 12:35:30 PM UTC-7, Scott Klarenbach wrote:
>
> I'm unable to post a new topic to the leinigen group so I thought I'd try 
> my luck here.
>
> I'd like to exclude certain dependencies from my uberjar, by using the 
> :provided profile, but the jars are always included.
>
> I've added the following to my project.clj, but the edu.stanford.nlp jars 
> end up in the uberjar no matter what.  I've also tried with a simple 
> project just to exclude a few jars and that doesn't seem to work either. 
>  Am I missing something simple?  Or is there a better way to exclude large 
> dependencies from uberjar if the deployment environment will already have 
> them on the classpath?  Thanks.
>
> :profiles {:uberjar {:aot :all}
>  :provided {:dependencies
> [[edu.stanford.nlp/stanford-corenlp "3.4.1"]
>  [edu.stanford.nlp/stanford-corenlp "3.4.1"
>   :classifier "models"]]}
>  :dev {:resource-paths ["test-data"]}}
>
>

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

[Andy Fingerhut]

Unofficial answer from the sidelines.  I am in no way associated with the
folks who make decisions like this, other than that some of them know my
name.

Throwing an exception in that case sounds like reasonable behavior to me,
but of course any code written now that uses clojure.java.io/resource and
relies on it returning nil, and does not catch an exception, could break if
clojure.java.io/resource changed behavior from one Clojure release to the
next.  That is not to say that it should not change, or will not change,
but a significant factor to consider in whether it will change.  Anyone is
welcome to create a ticket in JIRA requesting changes, just to get the
question/suggestion 'in the system' and see what the response is (which may
take significant time, given the other work desired to be done, some of
which may be considered higher priority).

I am probably belaboring the obvious by noting that if you want a function
that behaves as you describe, it is pretty easy to write one using the
existing clojure.java.io/resource.  Please, pretty please, do not take this
statement as a dismissal of your question.  It is not intended that way.

Andy

On Wed, Jun 3, 2015 at 12:48 PM, Elric Erkose 
wrote:

> The doc string for clojure.java.io/resource states that it returns a URL.
> When an invalid file is passed as the only parameter, it returns nil.
> Shouldn't we expect an Exception?
>
> user=> (clojure.java.io/resource "no-such-file")
> nil
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: (clojure.java.io/resource "no-such-file")

[James Reeves]

On 3 June 2015 at 20:48, Elric Erkose  wrote:

> The doc string for clojure.java.io/resource states that it returns a URL.
> When an invalid file is passed as the only parameter, it returns nil.
> Shouldn't we expect an Exception?
>
> user=> (clojure.java.io/resource "no-such-file")
> nil
>
> I'd say this was consistent with Clojure's other lookup functions. When we
lookup a value in a data structure that doesn't exist, nil is returned by
default, rather than an exception.

- 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: (clojure.java.io/resource "no-such-file")

[Elric Erkose]

@james Sounds reasonable, though it may not be consistent (or I'm missing 
your point).

user=> (get {:a 1} :no-such-file)
nil
user=> (get {:a 1} nil)
nil

Compared with

user=> (clojure.java.io/resource "no-such-file")
nil
user=> (clojure.java.io/resource nil)
NullPointerException   sun.misc.MetaIndex.mayContain (MetaIndex.java:242)

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

[Francis Avila]

Possibly you are also including the dependencies in the non-profile part of 
the project.clj? You shouldn't: the :provided profile is normally included, 
but excluded when running the uberjar task.

More concrete example:

(defproject myproj "0.1.0"
  :dependencies [[org.clojure/clojure "1.6.0"]] ;; notice standford-corenlp 
is *not* mentioned!!
  :uberjar {:aot :all}  
  :profiles {:provided {:dependencies
[[edu.stanford.nlp/stanford-corenlp "3.4.1"]
 [edu.stanford.nlp/stanford-corenlp "3.4.1"
  :classifier "models"]]}})



On Wednesday, June 3, 2015 at 2:35:30 PM UTC-5, Scott Klarenbach wrote:
>
> I'm unable to post a new topic to the leinigen group so I thought I'd try 
> my luck here.
>
> I'd like to exclude certain dependencies from my uberjar, by using the 
> :provided profile, but the jars are always included.
>
> I've added the following to my project.clj, but the edu.stanford.nlp jars 
> end up in the uberjar no matter what.  I've also tried with a simple 
> project just to exclude a few jars and that doesn't seem to work either. 
>  Am I missing something simple?  Or is there a better way to exclude large 
> dependencies from uberjar if the deployment environment will already have 
> them on the classpath?  Thanks.
>
> :profiles {:uberjar {:aot :all}
>  :provided {:dependencies
> [[edu.stanford.nlp/stanford-corenlp "3.4.1"]
>  [edu.stanford.nlp/stanford-corenlp "3.4.1"
>   :classifier "models"]]}
>  :dev {:resource-paths ["test-data"]}}
>
>

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

[Ivan L]

Removing Java 6 would affect clojure for android projects wouldn't it?

On Wednesday, June 3, 2015 at 9:34:07 AM UTC-4, Mike Rodriguez wrote:
>
> Sorry for the delay in getting back with a response to this.  I think it 
> is fairly clear in the Clojure Compiler that there is an exception that 
> will wrap errors that occur during macroexpansion now.
>
> Around here 
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L6627-L6649,
>  
> the Compiler.macroexpand1() now has a try-catch for Throwable around the 
> evaluation of the macro invocation.
> This was not the case in Clojure version 1.6.  See around 
> https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/Compiler.java#L6548-L6560
>  
> for a reference point.
>
> I'm fairly sure that is what has caused this change in behavior that broke 
> our expectations that the exception types our code through during 
> macroexpansion would propagate all the way back to the caller.  Again, I 
> think this was a bad expectation to have, but it is a little tricky.
>
> It is a little trickier for us to have any strong assertions on the type 
> of exception that may come from a macro now.  Compiler$CompilerException 
> seems too dependent on the implementation.  So we've opted to just assert 
> there would be a is-thrown? RuntimeException in these sorts of tests.  If 
> we want to test something like an ExceptionInfo's data map, we now just 
> have to write a helper to walk the stack trace until we find it - which 
> would likely be a single "step" up the trace.
>
> A simple reproducing case:
> *clojure-version* ;= {:major 1, :minor 7, :incremental 0, :qualifier "RC1"}
>
> (defmacro demo [] (throw (ex-info "fail" {})))
>
> (demo) ;= CompilerException clojure.lang.ExceptionInfo: fail {}, 
> compiling:(form-init4053282905768384039.clj:1:1) 
>
> vs.
> *clojure-version* ;= {:major 1, :minor 6, :incremental 0, :qualifier nil}
>
> (demo) ;= ExceptionInfo fail  clojure.core/ex-info (core.clj:4403)
>
>
>
> On Saturday, May 23, 2015 at 8:52:47 AM UTC-5, Alex Miller wrote:
>>
>> I'm not aware of any wholesale changes with respect to compiler 
>> exceptions. Can you give an example?
>
>

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

[Andy Fingerhut]

Just to provide slightly more info, that change was made because of this
ticket: http://dev.clojure.org/jira/browse/CLJ-1169

Andy

On Wed, Jun 3, 2015 at 6:34 AM, Mike Rodriguez  wrote:

> Sorry for the delay in getting back with a response to this.  I think it
> is fairly clear in the Clojure Compiler that there is an exception that
> will wrap errors that occur during macroexpansion now.
>
> Around here
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L6627-L6649,
> the Compiler.macroexpand1() now has a try-catch for Throwable around the
> evaluation of the macro invocation.
> This was not the case in Clojure version 1.6.  See around
> https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/Compiler.java#L6548-L6560
> for a reference point.
>
> I'm fairly sure that is what has caused this change in behavior that broke
> our expectations that the exception types our code through during
> macroexpansion would propagate all the way back to the caller.  Again, I
> think this was a bad expectation to have, but it is a little tricky.
>
> It is a little trickier for us to have any strong assertions on the type
> of exception that may come from a macro now.  Compiler$CompilerException
> seems too dependent on the implementation.  So we've opted to just assert
> there would be a is-thrown? RuntimeException in these sorts of tests.  If
> we want to test something like an ExceptionInfo's data map, we now just
> have to write a helper to walk the stack trace until we find it - which
> would likely be a single "step" up the trace.
>
> A simple reproducing case:
> *clojure-version* ;= {:major 1, :minor 7, :incremental 0, :qualifier "RC1"}
>
> (defmacro demo [] (throw (ex-info "fail" {})))
>
> (demo) ;= CompilerException clojure.lang.ExceptionInfo: fail {},
> compiling:(form-init4053282905768384039.clj:1:1)
>
> vs.
> *clojure-version* ;= {:major 1, :minor 6, :incremental 0, :qualifier nil}
>
> (demo) ;= ExceptionInfo fail  clojure.core/ex-info (core.clj:4403)
>
>
>
> On Saturday, May 23, 2015 at 8:52:47 AM UTC-5, Alex Miller wrote:
>>
>> I'm not aware of any wholesale changes with respect to compiler
>> exceptions. Can you give an example?
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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: (clojure.java.io/resource "no-such-file")

[Matching Socks]

The docstring is vague about the failure modes, but it drops a clue: "Use 
[sic] the context class loader
if no loader is specified."  The Javadoc for ClassLoader.getResource says 
it returns "null if the resource could not be found or the invoker doesn't 
have adequate privileges to get the resource". 

Currently, clojure.java.io/resource is convenient for use with "some", 
"filter", and "if".  A Jira ticket suggesting a more explicit docstring 
would be helpful.


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

[Alex Miller]

Without reading or thinking about this deeply, I did want to mention the 
existing ticket http://dev.clojure.org/jira/browse/CLJ-1210 which seems 
like it's in the ballpark of this.



On Wednesday, June 3, 2015 at 1:48:15 PM UTC-6, Elric Erkose wrote:
>
> The doc string for clojure.java.io/resource states that it returns a URL. 
> When an invalid file is passed as the only parameter, it returns nil. 
> Shouldn't we expect an Exception?
>
> user=> (clojure.java.io/resource "no-such-file")
> nil
>

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

[Richard Möhn]

Am Donnerstag, 4. Juni 2015 00:10:33 UTC+9 schrieb Marshall 
Bockrath-Vandegrift:
>
> Richard Möhn > writes: 
>
> > How do I remove from a nested datastructure the objects whose (pr obj) 
> > representation doesn't comply with the EDN specification? Fx, 
> > {:a 1 :b (find-ns 'user)} → {:a 1} 
> > Or, easier, how do I just not print these objects? 
>
> Additionally/alternatively to the 1.7.0 changes mentioned by Alex 
> Miller, check out: 
>
> https://github.com/llasram/letterpress 
>
> If you can stomach the (very gentle) monkey-patching, it provides the 
> ability to arbitrarily redefine and hook printing within a particular 
> dynamic scope. 
>

Ah, thanks! If it turns out that writing-and-then-ignoring tagged literals 
(1.7.0 pr) causes problems, I will turn to your library.

Richard

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

[Elric Erkose]

This is what I ran into with (slurp nil)  (slurp 
(clojure.java.io/resource "some-file"))

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

[Alex Miller]

Thanks Ivan and Andy, I'd appreciate a ticket in jira if only to consider 
this again before release.

Thank goodness Stu H screened that one so I can blame him. ;) 


On Wednesday, June 3, 2015 at 4:00:35 PM UTC-6, Andy Fingerhut wrote:
>
> Just to provide slightly more info, that change was made because of this 
> ticket: http://dev.clojure.org/jira/browse/CLJ-1169
>
> Andy
>
> On Wed, Jun 3, 2015 at 6:34 AM, Mike Rodriguez  > wrote:
>
>> Sorry for the delay in getting back with a response to this.  I think it 
>> is fairly clear in the Clojure Compiler that there is an exception that 
>> will wrap errors that occur during macroexpansion now.
>>
>> Around here 
>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L6627-L6649,
>>  
>> the Compiler.macroexpand1() now has a try-catch for Throwable around the 
>> evaluation of the macro invocation.
>> This was not the case in Clojure version 1.6.  See around 
>> https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/Compiler.java#L6548-L6560
>>  
>> for a reference point.
>>
>> I'm fairly sure that is what has caused this change in behavior that 
>> broke our expectations that the exception types our code through during 
>> macroexpansion would propagate all the way back to the caller.  Again, I 
>> think this was a bad expectation to have, but it is a little tricky.
>>
>> It is a little trickier for us to have any strong assertions on the type 
>> of exception that may come from a macro now.  Compiler$CompilerException 
>> seems too dependent on the implementation.  So we've opted to just assert 
>> there would be a is-thrown? RuntimeException in these sorts of tests.  If 
>> we want to test something like an ExceptionInfo's data map, we now just 
>> have to write a helper to walk the stack trace until we find it - which 
>> would likely be a single "step" up the trace.
>>
>> A simple reproducing case:
>> *clojure-version* ;= {:major 1, :minor 7, :incremental 0, :qualifier 
>> "RC1"}
>>
>> (defmacro demo [] (throw (ex-info "fail" {})))
>>
>> (demo) ;= CompilerException clojure.lang.ExceptionInfo: fail {}, 
>> compiling:(form-init4053282905768384039.clj:1:1) 
>>
>> vs.
>> *clojure-version* ;= {:major 1, :minor 6, :incremental 0, :qualifier nil}
>>
>> (demo) ;= ExceptionInfo fail  clojure.core/ex-info (core.clj:4403)
>>
>>
>>
>> On Saturday, May 23, 2015 at 8:52:47 AM UTC-5, Alex Miller wrote:
>>>
>>> I'm not aware of any wholesale changes with respect to compiler 
>>> exceptions. Can you give an example?
>>
>>  -- 
>> 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 the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, 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/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: [ANN] Clojure 1.7.0-RC1 now available

[Alex Miller]

This is the kind of thing that would be considered before making the 
decision. But it's coming eventually.

On Wednesday, June 3, 2015 at 3:32:15 PM UTC-6, Ivan L wrote:
>
> Removing Java 6 would affect clojure for android projects wouldn't it?
>
>

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

Re: [ANN] Clojure 1.7.0-RC1 now available

[Alex Miller]

s/Ivan/Mike Rodriguez/ sorry :)

On Wednesday, June 3, 2015 at 8:19:40 PM UTC-6, Alex Miller wrote:
>
> Thanks Ivan and Andy, I'd appreciate a ticket in jira if only to consider 
> this again before release.
>
> Thank goodness Stu H screened that one so I can blame him. ;) 
>
>
> On Wednesday, June 3, 2015 at 4:00:35 PM UTC-6, Andy Fingerhut wrote:
>>
>> Just to provide slightly more info, that change was made because of this 
>> ticket: http://dev.clojure.org/jira/browse/CLJ-1169
>>
>> Andy
>>
>> On Wed, Jun 3, 2015 at 6:34 AM, Mike Rodriguez  wrote:
>>
>>> Sorry for the delay in getting back with a response to this.  I think it 
>>> is fairly clear in the Clojure Compiler that there is an exception that 
>>> will wrap errors that occur during macroexpansion now.
>>>
>>> Around here 
>>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L6627-L6649,
>>>  
>>> the Compiler.macroexpand1() now has a try-catch for Throwable around the 
>>> evaluation of the macro invocation.
>>> This was not the case in Clojure version 1.6.  See around 
>>> https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/Compiler.java#L6548-L6560
>>>  
>>> for a reference point.
>>>
>>> I'm fairly sure that is what has caused this change in behavior that 
>>> broke our expectations that the exception types our code through during 
>>> macroexpansion would propagate all the way back to the caller.  Again, I 
>>> think this was a bad expectation to have, but it is a little tricky.
>>>
>>> It is a little trickier for us to have any strong assertions on the type 
>>> of exception that may come from a macro now.  Compiler$CompilerException 
>>> seems too dependent on the implementation.  So we've opted to just assert 
>>> there would be a is-thrown? RuntimeException in these sorts of tests.  If 
>>> we want to test something like an ExceptionInfo's data map, we now just 
>>> have to write a helper to walk the stack trace until we find it - which 
>>> would likely be a single "step" up the trace.
>>>
>>> A simple reproducing case:
>>> *clojure-version* ;= {:major 1, :minor 7, :incremental 0, :qualifier 
>>> "RC1"}
>>>
>>> (defmacro demo [] (throw (ex-info "fail" {})))
>>>
>>> (demo) ;= CompilerException clojure.lang.ExceptionInfo: fail {}, 
>>> compiling:(form-init4053282905768384039.clj:1:1) 
>>>
>>> vs.
>>> *clojure-version* ;= {:major 1, :minor 6, :incremental 0, :qualifier nil}
>>>
>>> (demo) ;= ExceptionInfo fail  clojure.core/ex-info (core.clj:4403)
>>>
>>>
>>>
>>> On Saturday, May 23, 2015 at 8:52:47 AM UTC-5, Alex Miller wrote:

 I'm not aware of any wholesale changes with respect to compiler 
 exceptions. Can you give an example?
>>>
>>>  -- 
>>> 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 the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, 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/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: When should defrecord be slower than deftype?

[Mars0i]

On Tuesday, June 2, 2015 at 11:16:49 PM UTC-5, Steven Yi wrote:
>
> As a side note, as an experiment I just tried overriding Object.equals 
> and Object.hashCode with a defrecord, and I got a compiler error: 
>
> CompilerException java.lang.ClassFormatError: Duplicate method 
> name&signature in class file user/R1, 
> compiling:(/private/var/folders/0k/xj_drd990xxf4q99n2bdknrcgn/T/form-init3397614882621384237.clj:1:1)
>  
>
>
> I'm assuming that defrecord is adding its hashCode and equals 
> implementations without checking if it's being overridden, but haven't 
> verified. (That was with 1.7.0-beta3 at least). 
>

I just understood why you tried this experiment, I think.  I tried it in 
1.6.0 and 1.7.0-RC1 and got the same result.  For my purposes, it would be 
ideal if I could override hashCode so that it was based on identity.  I'd 
get speed with Java hashmaps along with the other conveniences of records.  
Oh well.  Perhaps overriding hash behavior seems too bug-prone to be 
allowed.

The docstring for defrecord mentions explicitly that it defines hashCode 
and equals.  It seems as if there's a tiny inconsistency in the 
documentation given that it says that "You can also define overrides for 
methods of Object", though it doesn't say that you can do this for *all* of 
Object's methods; perhaps strictly speaking it's not inconsistent.

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