Re: with-redefs does not work for macros

[Tiago Espinha]

It's definitely good to mention. It's also what I ended up doing but didn't 
mention it in my answer :)



On Tue, Nov 1, 2016 at 1:15 AM +0100, "Beau Fabry" 
> wrote:

Not an answer to your question, but I usually just redefine 
clojure.tools.logging/log* instead for tests.

On Monday, April 27, 2015 at 9:34:14 AM UTC-7, Vebjorn Ljosa wrote:
In one of my tests, I was trying to mock something 
(`clojure.tools.logging/warn`) that happened to be a macro. It had me puzzled 
for a while until I discovered that `with-redefs` resets the value of the vars 
after the body is executed, but does not reset the flag that says that the var 
is a macro:

$ lein repl
Clojure 1.6.0
...
user=> (defmacro foo [] `(prn "I am a macro"))
#'user/foo
user=> (clojure.test/function? 'foo)
false
user=> (with-redefs [foo (fn [] 42)])
nil
user=> (clojure.test/function? foo)
true
user=> (foo)
ArityException Wrong number of args (0) passed to: user/foo 
clojure.lang.AFn.throwArity (AFn.java:429)
user=> (foo 42 42)
(clojure.core/prn "I am a macro")

Is this a bug?

I looked at the source for `with-redefs-fn`, and the fix appears simple: record 
for each val whether it's a macro or not, and then call the `(setMacro)` method 
on the vars that should be macros after resetting their values.

Vebjorn

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

[Beau Fabry]

Not an answer to your question, but I usually just redefine 
clojure.tools.logging/log* instead for tests.

On Monday, April 27, 2015 at 9:34:14 AM UTC-7, Vebjorn Ljosa wrote:
>
> In one of my tests, I was trying to mock something 
> (`clojure.tools.logging/warn`) that happened to be a macro. It had me 
> puzzled for a while until I discovered that `with-redefs` resets the value 
> of the vars after the body is executed, but does not reset the flag that 
> says that the var is a macro:
>
> $ lein repl
> Clojure 1.6.0
> …
> user=> (defmacro foo [] `(prn "I am a macro")) 
> #'user/foo 
> user=> (clojure.test/function? 'foo)
> false
> user=> (with-redefs [foo (fn [] 42)])
> nil
> user=> (clojure.test/function? foo) 
> true
> user=> (foo) 
> ArityException Wrong number of args (0) passed to: user/foo 
> clojure.lang.AFn.throwArity (AFn.java:429) 
> user=> (foo 42 42) 
> (clojure.core/prn "I am a macro")
>
> Is this a bug?
>
> I looked at the source for `with-redefs-fn`, and the fix appears simple: 
> record for each val whether it's a macro or not, and then call the 
> `(setMacro)` method on the vars that should be macros after resetting their 
> values.
>
> Vebjorn
>

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

[Alex Miller]

You can of course have one concrete instance implement many protocols. 

Another clever thing you can do is to extend a protocol to Object, then inside 
the Object extension check if the instance satisfies? another protocol and if 
so, extend its type at runtime to the original protocol. Rich suggested this at 
the very first conj and I've used it a few times. Can be abused of course.

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

[ANN] data.avl 0.0.17 – tree balance bugfix, more generative tests

[Michał Marczyk]

Hi,

I am pleased to announce the 0.0.17 release of data.avl, a Clojure
Contrib library providing highly performant drop-in replacements for
Clojure(Script)'s built-in sorted maps and sets that support O(log n)
nth, rank-of, first-class submaps/subsets (like subseq, but preserving
collection type; fully independent from the original for GC purposes)
and splits by key and index.

This release addresses an issue whereby the balancing invariant would
not be obeyed in certain cases, leading to degraded performance. The
problem was uncovered by newly expanded generative tests for the
balancing invariant; these should prevent any regressions in the
future.

  [org.clojure/data.avl "0.0.17"]

  
org.clojure
data.avl
0.0.17
  

  org.clojure:data.avl:0.0.17

Cheers,
Michał

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

[John Szakmeister]

On Mon, Oct 31, 2016 at 5:57 PM, Alex Miller  wrote:
> You can create instances that implement multiple Java interfaces using
> `reify` or by declaring them inline of a `defrecord` or a `deftype`. (See
> http://clojure.org/reference/datatypes for more.)

Thank you Alex.  I should have been more clear in that I'd like
something like ICombined which represents several protocols brought
together.  The motivation here is that it helps us ensure that all the
right protocols are being implemented.  AFAICT, Clojure has no
equivalent for abstract base classes... and I see a ticket about
issues with them (http://dev.clojure.org/jira/browse/CLJ-1255).

> Clojure does *not* encourage or support concrete inheritance (other than of
> the limited degree provided by `proxy`) and you will generally find that to
> be a hard way to go.

Sure.  I was more interested in the protocol aspects though.  This
might be a case where it's better for us to do this part in Java.

Thanks for the information.

-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
--- 
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: Deriving a protocol from a protocol...

[Alex Miller]

You can create instances that implement multiple Java interfaces using 
`reify` or by declaring them inline of a `defrecord` or a `deftype`. 
(See http://clojure.org/reference/datatypes for more.)

Clojure does *not* encourage or support concrete inheritance (other than of 
the limited degree provided by `proxy`) and you will generally find that to 
be a hard way to go.


On Monday, October 31, 2016 at 3:22:07 PM UTC-5, John Szakmeister wrote:
>
> I'm looking at using Clojure in an application where we make 
> fine-grained use of interfaces that help describe the capabilities of 
> an object.  We need to take several interfaces and bring them 
> together, not necessarily in an implementation, but to help define 
> what the overall interface for the object needs to support. 
>
> In Java, I could use an abstract base class to help: 
>
> public abstract class MyGear implements IFoo, IBar { 
> // ... 
> } 
>
> How does one do such a thing in Clojure?  Does it even make sense?  I 
> could see turning some things on their head an using multi-methods for 
> this, but I thought I'd ask and see if there is some other approach I 
> may be missing. 
>
> Thanks! 
>
> -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
--- 
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.

Java 9 AOT Compilation

[Alan Moore]

FYI: I just ran across this and thought it would interest this group:

http://openjdk.java.net/jeps/295

Initially only some of the base java stuff will be compiled but it looks 
like it will be extended further.

Hopefully this might help improve startup time for those using OpenJDK.

Alan

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

Deriving a protocol from a protocol...

[John Szakmeister]

I'm looking at using Clojure in an application where we make
fine-grained use of interfaces that help describe the capabilities of
an object.  We need to take several interfaces and bring them
together, not necessarily in an implementation, but to help define
what the overall interface for the object needs to support.

In Java, I could use an abstract base class to help:

public abstract class MyGear implements IFoo, IBar {
// ...
}

How does one do such a thing in Clojure?  Does it even make sense?  I
could see turning some things on their head an using multi-methods for
this, but I thought I'd ask and see if there is some other approach I
may be missing.

Thanks!

-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
--- 
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: Can clojure.spec be used to identify/pinpoint broken invariants on dynamic data?

[Alex Miller]

Getting a bit more concrete, I think this would be a better approach to the 
variable name spec:

(defmacro make-name-spec 
  [var-names]
  `(s/and :lang-name ~var-names))

which can be called in the process of verifying the ast to dynamically 
create a static spec, which can then be used for validation. OR have 
make-name-spec use s/def to register the spec (but then you need to be 
aware that it's in the registry and has affected runtime state - that's 
where tracking the lifecycle becomes important).

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Can clojure.spec be used to identify/pinpoint broken invariants on dynamic data?

[Alex Miller]

On Monday, October 31, 2016 at 10:41:36 AM UTC-5, Yannick Scherer wrote:
>
> imho, you're asking spec to do more than it should here - it's not a magic 
>> wand to wave at all validation problems.
>>
>
> That's good to know. Note that, in regard to the problem stated above, 
> clojure.spec does not fail its validation responsibilities
> – it can perfectly tell me that my data has semantic inconsistencies. 
> Rather, it's failing at providing means to increase the
> usefulness/granularity of any validation errors it emits.
>

I disagree with this - you can define specs in a way that is very granular 
and gives fine-grained errors. The problem where it is falling down for you 
is the notion of some generic spec + later (dynamic) refinement. We have no 
intention of adding anything like that beyond what is already provided 
(things like s/and).
 

> you're asking spec to do more than it should here
>
>
> Can you elaborate? Where do, in this case, the responsibilities of 
> clojure.spec end? 
>

You are seeking to refine specs dynamically based on runtime state, then 
validate additional data in terms of those (stateful) specs. I don't think 
using runtime data is wrong (and I've seen some interesting uses of it). 
But the use of specs with dynamic variables in particular seems 
questionable - you've created a stateful spec whose meaning changes over 
time. To me, this seems like a bad idea (for all the same reasons stateful 
mutable objects introduce problems). Instead, I think it is far preferable 
to dynamically generate static specs (which might incorporate parts of 
existing static specs for the purposes of refinement), than to statically 
define dynamic specs. It is also important to think about the lifecycle of 
dynamically generated specs.
 

>
> Should clojure.spec only be used for structural validation (with 
>> [semantic] validation being done explicitly in a second pass) or if
>> validation errors with low granularity are okay? 
>
>
I think the distinction of structural vs semantic is hazy at best (and more 
likely not even meaningful) in a predicative dynamic system. I will stick 
with my narrower advice above that the use of specs with dynamic vars seems 
like a bad idea to me.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Can clojure.spec be used to identify/pinpoint broken invariants on dynamic data?

[Yannick Scherer]

>
> imho, you're asking spec to do more than it should here - it's not a magic 
> wand to wave at all validation problems.
>

That's good to know. Note that, in regard to the problem stated above, 
clojure.spec does not fail its validation responsibilities
– it can perfectly tell me that my data has semantic inconsistencies. 
Rather, it's failing at providing means to increase the
usefulness/granularity of any validation errors it emits.

you're asking spec to do more than it should here


Can you elaborate? Where do, in this case, the responsibilities of 
clojure.spec end? 

Should clojure.spec only be used for structural validation (with [semantic] 
> validation being done explicitly in a second pass) or if
> validation errors with low granularity are okay? 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Can clojure.spec be used to identify/pinpoint broken invariants on dynamic data?

[Alex Miller]

imho, you're asking spec to do more than it should here - it's not a magic 
wand to wave at all validation problems.




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

[JHacks]

On Sunday, October 30, 2016 at 10:50:08 PM UTC-4, Mikera wrote:
>
>
> I actually prefer the following style to both of the above:
>
> (defn camel->keyword*
>  [s]
>  (let [words (str/split s #"(?<=[a-z])(?=[A-Z])")
>lc-words (map str/lower-case words)
>joined-words (str/join "-" lc-words)]
>(keyword joined-words))) 
>
> Reasons:
> - Your intermediate values are explicitly named, which helps to make the 
> code self-describing
> - It is (marginally) more performant than the composed function case (I 
> think exactly matches the threading macro)
> - You can use the intermediate values in more than one of the following 
> steps if needed, which can make refactoring / adding new features easier
> - The ordering is (to me) more logical as it describes the stages of the 
> transformation in the order they are performed.
> - It is less "Clever". Clever code is generally bad for maintenance and 
> future understanding. Both functional composition and the 
> code-transformation effects of the threading macro represent conceptual 
> overhead that you don't need to pay (in this case).
>

 Wow! I much prefer this style. I'm impressed that even though it's clearer 
(to me), it doesn't suffer in performance.

Thanks for not only showing a clearer way to do this, but also outlining 
good arguments for why one might want to.

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

freeing deftemplate memory after using clojure.tools.namespace.repl/refresh

[Calvin Irwan]

Hi, all

My project is using a lot of enlive deftemplates and the file generated is 
quite big. Whenever I refresh my project it seems going slower and slower 
and out of memory at the end and I found the culprit to be those 
deftemplates. 

My question is, how can I free the old deftemplates memory after 
refreshing? or probably another approach to solve this?

Thanks,
Calvin

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