Re: [ANN] proxy-plus: Faster and more usable replacement for "proxy"

[Mike Rodriguez]

Ah yes. I didn't consider that.

On Wednesday, January 15, 2020 at 12:31:13 PM UTC-5, Alex Miller wrote:
>
> Using vars lets you iterate on the impl functions without invalidating the 
> proxy instances. I'm not sure if that was the reason, but that would be one 
> advantage.
>
> On Wednesday, January 15, 2020 at 10:46:36 AM UTC-6, Mike Rodriguez wrote:
>>
>> Do you have any idea about the reason that the Clojure implementation was 
>> done this way - when it obviously seems a bit limited and also slower than 
>> necessary? Just curious if there's some historical context.
>>
>> On Tuesday, January 14, 2020 at 11:58:17 AM UTC-5, Nathan Marz wrote:
>>>
>>> The speedup comes from proxy+ directly overriding methods with the 
>>> provided implementation, while Clojure's proxy has additional indirection. 
>>> For example, if you do (proxy [Object] [] (toString [] "hello")), the 
>>> bytecode for toString is:
>>>
>>>   public java.lang.String toString();
>>>
>>>  0  aload_0 [this]
>>>
>>>  1  getfield user.proxy$java.lang.Object$ff19274a.__clojureFnMap : 
>>> clojure.lang.IPersistentMap [16]
>>>
>>>  4  ldc  [52]
>>>
>>>  6  invokestatic clojure.lang.RT.get(java.lang.Object, 
>>> java.lang.Object) : java.lang.Object [36]
>>>
>>>  9  dup
>>>
>>> 10  ifnull 28
>>>
>>> 13  checkcast clojure.lang.IFn [38]
>>>
>>> 16  aload_0 [this]
>>>
>>> 17  invokeinterface clojure.lang.IFn.invoke(java.lang.Object) : 
>>> java.lang.Object [55] [nargs: 2]
>>>
>>> 22  checkcast java.lang.String [57]
>>>
>>> 25  goto 33
>>>
>>> 28  pop
>>>
>>> 29  aload_0 [this]
>>>
>>> 30  invokespecial java.lang.Object.toString() : java.lang.String 
>>> [59]
>>>
>>> 33  areturn
>>>
>>> Clojure keeps the implementations in a map, and for every dispatch it 
>>> does a map lookup by the method name. This is also why it can't handle 
>>> overriding the same method name with different arities.
>>>
>>> For (proxy+ [] Object (toString [this] "hello")), the bytecode is:
>>>
>>>   public java.lang.String toString();
>>>
>>>  0  aload_0 [this]
>>>
>>>  1  getfield user.proxy_plus5358.toString5357 : clojure.lang.IFn 
>>> [19]
>>>
>>>  4  aload_0 [this]
>>>
>>>  5  invokeinterface clojure.lang.IFn.invoke(java.lang.Object) : 
>>> java.lang.Object [30] [nargs: 2]
>>>
>>> 10  checkcast java.lang.String [32]
>>>
>>> 13  areturn
>>>
>>> The implementation function is stored as a field, so the cost of 
>>> dispatch is a field get rather than a map lookup.
>>>
>>> Clojure's proxy also overrides *every* available method in all 
>>> superclasses/interfaces, while proxy+ only overrides what you specify. So 
>>> proxy+ generates much smaller classes than proxy.
>>>
>>>
>>> On Tuesday, January 14, 2020 at 10:30:32 AM UTC-5, Brent Millare wrote:
>>>>
>>>> I skimmed the code, I don't really understand how it makes it faster 
>>>> over proxy. Is it the generated ASM is better? What's the in-a-nutshell 
>>>> description of how it works?
>>>>
>>>> On Monday, January 13, 2020 at 1:28:46 PM UTC-5, Nathan Marz wrote:
>>>>>
>>>>> No differences in behavior except for API being like reify. It 
>>>>> integrates with AOT and can be consumed just like any other class. No 
>>>>> idea 
>>>>> how it interacts with Graal.
>>>>>
>>>>> On Monday, January 13, 2020 at 12:29:35 PM UTC-5, John Newman wrote:
>>>>>>
>>>>>> Bravo 
>>>>>>
>>>>>> Are there any differences in behavior to be aware of? AOT, Graal, 
>>>>>> consuming proxy+ classes from vanilla clojure classes?
>>>>>>
>>>>>> On Mon, Jan 13, 2020, 11:47 AM Nathan Marz  
>>>>>> wrote:
>>>>>>
>>>>>>> proxy+ is a replacement for Clojure's proxy that's faster and more 
>>>>>>> usable. proxy has a strange implementation where it overrides every 
>>>>>>> possible method and uses a mutable field to store a map of string -> 
>>>>>

Re: [ANN] proxy-plus: Faster and more usable replacement for "proxy"

[Mike Rodriguez]

Do you have any idea about the reason that the Clojure implementation was 
done this way - when it obviously seems a bit limited and also slower than 
necessary? Just curious if there's some historical context.

On Tuesday, January 14, 2020 at 11:58:17 AM UTC-5, Nathan Marz wrote:
>
> The speedup comes from proxy+ directly overriding methods with the 
> provided implementation, while Clojure's proxy has additional indirection. 
> For example, if you do (proxy [Object] [] (toString [] "hello")), the 
> bytecode for toString is:
>
>   public java.lang.String toString();
>
>  0  aload_0 [this]
>
>  1  getfield user.proxy$java.lang.Object$ff19274a.__clojureFnMap : 
> clojure.lang.IPersistentMap [16]
>
>  4  ldc  [52]
>
>  6  invokestatic clojure.lang.RT.get(java.lang.Object, 
> java.lang.Object) : java.lang.Object [36]
>
>  9  dup
>
> 10  ifnull 28
>
> 13  checkcast clojure.lang.IFn [38]
>
> 16  aload_0 [this]
>
> 17  invokeinterface clojure.lang.IFn.invoke(java.lang.Object) : 
> java.lang.Object [55] [nargs: 2]
>
> 22  checkcast java.lang.String [57]
>
> 25  goto 33
>
> 28  pop
>
> 29  aload_0 [this]
>
> 30  invokespecial java.lang.Object.toString() : java.lang.String [59]
>
> 33  areturn
>
> Clojure keeps the implementations in a map, and for every dispatch it does 
> a map lookup by the method name. This is also why it can't handle 
> overriding the same method name with different arities.
>
> For (proxy+ [] Object (toString [this] "hello")), the bytecode is:
>
>   public java.lang.String toString();
>
>  0  aload_0 [this]
>
>  1  getfield user.proxy_plus5358.toString5357 : clojure.lang.IFn [19]
>
>  4  aload_0 [this]
>
>  5  invokeinterface clojure.lang.IFn.invoke(java.lang.Object) : 
> java.lang.Object [30] [nargs: 2]
>
> 10  checkcast java.lang.String [32]
>
> 13  areturn
>
> The implementation function is stored as a field, so the cost of dispatch 
> is a field get rather than a map lookup.
>
> Clojure's proxy also overrides *every* available method in all 
> superclasses/interfaces, while proxy+ only overrides what you specify. So 
> proxy+ generates much smaller classes than proxy.
>
>
> On Tuesday, January 14, 2020 at 10:30:32 AM UTC-5, Brent Millare wrote:
>>
>> I skimmed the code, I don't really understand how it makes it faster over 
>> proxy. Is it the generated ASM is better? What's the in-a-nutshell 
>> description of how it works?
>>
>> On Monday, January 13, 2020 at 1:28:46 PM UTC-5, Nathan Marz wrote:
>>>
>>> No differences in behavior except for API being like reify. It 
>>> integrates with AOT and can be consumed just like any other class. No idea 
>>> how it interacts with Graal.
>>>
>>> On Monday, January 13, 2020 at 12:29:35 PM UTC-5, John Newman wrote:

 Bravo 

 Are there any differences in behavior to be aware of? AOT, Graal, 
 consuming proxy+ classes from vanilla clojure classes?

 On Mon, Jan 13, 2020, 11:47 AM Nathan Marz  wrote:

> proxy+ is a replacement for Clojure's proxy that's faster and more 
> usable. proxy has a strange implementation where it overrides every 
> possible method and uses a mutable field to store a map of string -> 
> function for dispatching the methods. This causes it to be unable to 
> handle 
> methods with the same name but different arities.
>
> proxy+ fixes these issues with proxy. Usage is like reify, and it's up 
> to 10x faster.
>
> *Repository: *https://github.com/redplanetlabs/proxy-plus
>
> -- 
> 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
> clo...@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 clo...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/clojure/6d9bf48a-c5b5-417a-9f66-aa494cc38346%40googlegroups.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

Re: [ANN] MrAnderson 0.5.0 released

[Mike Rodriguez]

It's good to see this lib getting attention. It can be very useful.

On Monday, March 25, 2019 at 12:04:55 PM UTC-4, benedek fazekas wrote:
>
> hi everyone,
>
> happy to announce a new version of MrAnderson <
> https://github.com/benedekfazekas/mranderson>, a dependency inlining and 
> shadowing tool.
>
> This version is a major rewrite of internals and also adds some new 
> features: check it out. Possible use cases here: 
> https://github.com/benedekfazekas/mranderson#is-it-good-should-i-use-it 
> and a description of what it does with examples here: 
> https://github.com/benedekfazekas/mranderson#two-modes-resolved-tree-and-unresolved-tree
>
> cheers,
> --
> Benedek 
>

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

[Mike Rodriguez]

[cider/cider-nrepl "0.8.2"]

is quite old. It looks like lein 2.9.1 (as of 2.8.2) uses a newer version 
of nrepl that requires cider-nrepl 0.18+ or something along those lines. 
In newer versions of cider, you may not need to include this plugin at all. 
I know that the "jack-in" commands of cider can do it automatically for you 
at least. If removing the dep works fine for your workflow, I'd stick with 
that. Less is more. :-P



On Wednesday, March 13, 2019 at 1:54:35 PM UTC-4, Kenneth Reid Beesley 
wrote:
>
>
>
> On 13Mar2019, at 10:19, Sean Corfield > 
> wrote:
>
> Check what’s in your ~/.lein/profiles.clj file – that’s usually the cause 
> of bizarre errors that people report with Leiningen.
>
>
> Hello Sean,
>
> Hah!  I changed my ~/.lein/profiles.clj from
>
> {:user {:plugins [[cider/cider-nrepl "0.8.2"]]}}
>
> to
>
> {:user {:plugins [[lein-pprint "1.1.1"]]
> :dependencies [[slamhound "1.3.1"]]}}
>
> and now ‘lein repl’ launches.
>
> Anything else I should add to ~/.lein/profiles.clj ?
>
> Many thanks!
>
> Ken
>
> ***
> Kenneth R. Beesley, D.Phil.
> PO Box 540475
> North Salt Lake UT 84054
> USA
>
>
>
>
>
>
>

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

[Mike Rodriguez]

@Val Waeselynck

I upgraded to 0.1.3 and it seems to be working without the issue #1 
workaround anymore. I read the documentation that you referenced as well. 
It is useful and helps clarify what sort of situations can come up.
Thanks!

On Thursday, October 19, 2017 at 8:19:43 AM UTC-4, Val Waeselynck wrote:
>
> @Mike Rodriguez the 0.1.3 release improves ClojureScript support and 
> should solve the mentioned issue, along with much better documentation 
> <https://github.com/alvalval/scope-capture/wiki/Pitfalls-with-(browser-connected)-ClojureScript-REPLs>
>  
> regarding ClojureScript support. Please tell me if you still have issues.
>
> Cheers,
>
> Val
>
> On Saturday, 14 October 2017 20:31:35 UTC+2, Mike Rodriguez wrote:
>>
>> I really like this library already. I only had to give it about 5 minutes 
>> of time to immediately see how it simplified quick REPL-driven debugging 
>> workflows for me.
>>
>> The only outstanding issue that is an annoyance for me is the CLJS 
>> support, which is discussed at 
>> https://github.com/alvalval/scope-capture/issues/1 and the 
>> workaround @ 
>> https://github.com/alvalval/scope-capture/issues/1#issuecomment-335117655
>>  
>> is enough to get it working for me. So hopefully that is smoothed over 
>> soon. I haven't dug into the impl details enough at this point to say I 
>> know exactly what the issue is there. I might though if it stays open a 
>> while!
>>
>> Thanks for the lib. It seems really minimal and immediately useful.
>>
>> On Sunday, October 8, 2017 at 3:09:19 AM UTC-4, Val Waeselynck wrote:
>>>
>>> Hi, I'm happy to release a tiny Clojure/Script library called 
>>> scope-capture <https://github.com/alvalval/scope-capture>.
>>>
>>> https://github.com/alvalval/scope-capture
>>>
>>> Loosely speaking, scope-capture makes it trivial to reproduce from the 
>>> REPL the context of a piece of code after it executed. 
>>>
>>> It was inspired by Stuart Halloway's article *REPL Debugging: no 
>>> stacktrace required 
>>> <http://blog.cognitect.com/blog/2017/6/5/repl-debugging-no-stacktrace-required>*.
>>>  
>>> Thanks Stu!
>>>
>>> I've been using it professionally for a few weeks now, and it's been a 
>>> significant productivity boost for me. In my view the benefits are:
>>>
>>>- easier debugging
>>>- making Clojure code / projects more accessible to beginners
>>>- easier ad-hoc exploration
>>>
>>> Please let me know what you think!
>>>
>>> Valentin Waeselynck
>>>
>>

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

[Mike Rodriguez]

I really like this library already. I only had to give it about 5 minutes 
of time to immediately see how it simplified quick REPL-driven debugging 
workflows for me.

The only outstanding issue that is an annoyance for me is the CLJS support, 
which is discussed 
at https://github.com/alvalval/scope-capture/issues/1 and the 
workaround 
@ https://github.com/alvalval/scope-capture/issues/1#issuecomment-335117655 
is enough to get it working for me. So hopefully that is smoothed over 
soon. I haven't dug into the impl details enough at this point to say I 
know exactly what the issue is there. I might though if it stays open a 
while!

Thanks for the lib. It seems really minimal and immediately useful.

On Sunday, October 8, 2017 at 3:09:19 AM UTC-4, Val Waeselynck wrote:
>
> Hi, I'm happy to release a tiny Clojure/Script library called 
> scope-capture .
>
> https://github.com/alvalval/scope-capture
>
> Loosely speaking, scope-capture makes it trivial to reproduce from the 
> REPL the context of a piece of code after it executed. 
>
> It was inspired by Stuart Halloway's article *REPL Debugging: no 
> stacktrace required 
> *.
>  
> Thanks Stu!
>
> I've been using it professionally for a few weeks now, and it's been a 
> significant productivity boost for me. In my view the benefits are:
>
>- easier debugging
>- making Clojure code / projects more accessible to beginners
>- easier ad-hoc exploration
>
> Please let me know what you think!
>
> Valentin Waeselynck
>

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

[Mike Rodriguez]

I've have used this as a lein plugin and I think it is a really great tool 
to have available.  It makes working on Java or a hybrid Java/Clojure 
project more tolerable.

On Thursday, March 16, 2017 at 2:13:35 PM UTC-4, Zach Tellman wrote:
>
> I figured it was worth reminding everyone that this library exists: 
> https://github.com/ztellman/virgil.  It now seems to work on Java 
> projects of arbitrary size and structure (the in-process compiler is very 
> fussy about compile order, you need to topologically sort the classes), and 
> I've been using it extensively this last month while writing a bunch of 
> Java [1].  I can tweak some Java, wait a second, and then test that code at 
> the REPL.  It's been pretty game-changing for my workflow.
>
> If anyone has questions, I'm happy to answer them.
>
> Zach
>
> [1] https://github.com/lacuna/bifurcan
>

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

[Mike Rodriguez]

I haven't been able to get to the bottom of this as of yet.  Primarily the 
problem is I need to investigate how `lein trampoline` works compared to 
without it, from an implementation perspective.

I'll note that `lein test` does do a :reload option to `require` when 
running tests.  Typically forced reloads of namespaces doesn't mix well 
with AOT compilation, due to classloader issues like you are reporting here.
However, I'm still missing key parts to understanding this.  I want to look 
a bit closer at it, but just responding here in case these thoughts are 
meaningful to anyone else that is looking at it.

On Wednesday, March 8, 2017 at 12:07:31 AM UTC-5, Tianxiang Xiong wrote:
>
> I recently ran into an issue with AOT compilation that I'd like to 
> understand better. A minimal working example (MWE) can be found here 
> . 
>
> Basically, using `:aot :all` in `project.clj` with `lein trampoline test` 
> results in different classloaders for class `Foo`.  
>
> Classloader for lein_trampoline_aot.core.Foo:  
> #object[clojure.lang.DynamicClassLoader 
> 0x4982cc36 clojure.lang.DynamicClassLoader@4982cc36]
> Classloader for (->Foo):  #object[sun.misc.Launcher$AppClassLoader 
> 0x55f96302 sun.misc.Launcher$AppClassLoader@55f96302]
>
> While the same classloaders are used with `lein test`:
>
> Class loader for lein_trampoline_aot.core.Foo:  
> #object[sun.misc.Launcher$AppClassLoader 
> 0x55f96302 sun.misc.Launcher$AppClassLoader@55f96302]
> Classloader for (->Foo):  #object[sun.misc.Launcher$AppClassLoader 
> 0x55f96302 sun.misc.Launcher$AppClassLoader@55f96302]
>
> When is one classloader used instead of another, and why do `lein 
> trampoline test` and `lein test` behave differently with `:aot :all`?
>

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

[Mike Rodriguez]

Guava is often a dependency conflict when trying to put libs together that use 
it. I'm surprised cljs has dependencies like this. I'd think a language would 
try to avoid having any deps at all or repackage them or something. For 
example, Clojure only has ASM. 

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

[Mike Rodriguez]

I believe it is generally true that the Clojure-maven-plugin has 
non-deterministic ordering of namespaces it auto "discovers" for its various 
goals that involve namespace discovery. 

This has been a source of frustration for me in the past as far as trying to 
get determinism with test behaviors and also with having sporadic failures. 
Although I guess the redeeming part is it can sometimes randomly show you when 
you missed a :require or something like that. :)

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

[Mike Rodriguez]

Thanks for the feedback.  I will try to track this issue via the 
maven-shade-plugin then.  Hopefully there can be some momentum to change it 
there.

On Saturday, December 31, 2016 at 12:09:32 PM UTC-5, Alex Miller wrote:
>
> This seems like a pretty straightforward bug with maven-shade-plugin not 
> preserving information that it should, so it seems like it should be fixed 
> there.
>
> On Wednesday, December 28, 2016 at 7:06:11 AM UTC-6, Mike Rodriguez wrote:
>>
>> Background:
>>
>> This problem is specific to building jars that contain AOT (Ahead Of 
>> Time) compiled Clojure code using Maven and the maven-shade-plugin.
>>
>> Clojure AOT compilation depends on timestamps of .class files vs .clj 
>> files being accurate.  When both .class files and their associated .clj 
>> files exist, the AOT .class files are only used by the compiler if their 
>> last modified timestamp is strictly greater than the last modified 
>> timestamp of the associated .clj file.
>>
>> Also note that the Clojure core jar itself is deployed AOTed.
>>
>> I know that much of the Clojure ecosystem uses Leiningen as a build tool 
>> (and boot now too I guess).  This problem doesn't apply to Leiningen (and I 
>> haven't looked at boot).
>>
>> Problem:
>>
>> The maven-shade-plugin is popular for building shaded/uber/standalone 
>> jars in Maven.  Typically this means the jar will include some/all of its 
>> dependency jars' files.  The maven-shade-plugin has an unfortunate property 
>> though.  It does not preserve the timestamps on files that are added to 
>> this final shaded jar.  The resulting jar actually ends up with all files 
>> inside of it having the same timestamp (when the jar was created).  In 
>> particular, if you originally had AOT Clojure .class files and .clj files 
>> with different last modified timestamps, now they will have the same 
>> timestamps in the shaded jar.
>>
>> I've brought this up before @ 
>> http://stackoverflow.com/questions/19594360/preserving-timestamps-on-clojure-clj-files-when-building-shaded-jar-via-maven-s
>>
>> I have rarely seen people bring up issues around this with 
>> maven-shade-plugin beyond this particular case.  I believe I have seen a 
>> complaint or two around the timestamp loss during shading (I can't find 
>> them now), but nothing that has gained any traction (I may try to bring it 
>> up to the plugin people soon though).
>>
>> When the AOTed .class file is ignored in favor of the .clj file, the 
>> namespace is JIT (Just-In-Time) compiled.  There are several issues with 
>> this.
>>
>> 1) Performance:  It makes the AOT files mostly worthless since they are 
>> not saving you on startup time costs anymore.  Everything is JITed anyways.
>> 2) Errors:  The reloading of the .clj files is a forced reload of the 
>> .clj namespaces involved.  This can cause classpath clashes among 
>> ClassLoaders.
>> - There are quite a few CLJ Jiras out there that faced trouble dealing 
>> with the mix of reloading namespaces and AOT compilation.
>>
>> You may be thinking, "Just don't build your Clojure jars with Maven.  Use 
>> Leiningen instead perhaps?"
>> This is fine when it is something you control.  However, what if I want 
>> to use Clojure to develop a library that may be consumed by Java consumers 
>> who very likely will be using Maven.  If my library is going to be shaded 
>> into a standalone jar with maven-shade-plugin by this Java consumer (again, 
>> likely) then this scenario can happen.
>>
>> Another thought that may occur is to just avoid AOT compilation of my 
>> library application to avoid the problem (this is recommended in the 
>> community I believe).  However, Clojure core is AOT compiled and it will 
>> get included in the shaded jar.  That alone is enough to cause the issue.
>>
>> Example:
>>
>> I have a GitHub repo to show a minimum example of where this can be a 
>> problem.  In particular it shows a way for the problem (2) to occur.
>> @ https://github.com/mrrodriguez/mvn-shade-test
>>
>> This repo has a Java API through shade.ShadeJava that will cause the 
>> Clojure compiler to require the shade.main namespace using JIT compilation. 
>>  However, shade.main uses clojure.pprint, which is AOT compiled via Clojure 
>> core.
>>
>> clojure.pprint was chosen here just because it one of the cases I've seen 
>> come up that actually fail with problem (2) from above.  Even if there were 
>> no failures though, the Clojure core namespaces would be getting recompiled 
>> with pr

Re: Order preservation and duplicate removal policy in `distinct`

[Mike Rodriguez]

Thanks for the feedback Alex.

As far as:
> If you wanted to file a jira on anything here, a jira to add a line to 
the doc string stating that the first duplicate is kept would be the only 
thing possibly worth doing.

I'll get one logged then.



On Saturday, December 31, 2016 at 12:05:16 PM UTC-5, Alex Miller wrote:
>
> Replying to many things in this thread at once here...
>
> Re lazy sequences, I think you can take it as implicit and rely on the 
> input seq order is retained (same as other sequence functions).
>
> Re duplicates, the current implementation retains the first element, but 
> as mentioned this is not stated in the doc string (so probably should not 
> be something you rely upon). 
>
> "Equality" in this case is based upon set contains? checks, which 
> ultimately use Clojure's "equiv" notion of equality (NOT Java's .equals). 
> In general for Clojure, equality is based on values and two duplicate 
> values will be indistinguishable. However, two cases where that might not 
> be the case are when they have meta (which is not considered in equality) 
> or if they are arbitrary Java objects (which fall back to .equals behavior).
>
> If you wanted to file a jira on anything here, a jira to add a line to the 
> doc string stating that the first duplicate is kept would be the only thing 
> possibly worth doing.
>
> Alex
>
>
> On Wednesday, December 28, 2016 at 10:22:53 AM UTC-6, Mike Rodriguez wrote:
>>
>> The doc for `distinct` is:
>> "Returns a lazy sequence of the elements of coll with duplicates removed.
>>   Returns a stateful transducer when no collection is provided."
>>
>> (1) In the lazy sequence case, I've thought that maybe it is assuemd 
>> there is a guarantee that the order of the input seq is preserved. 
>>  However, this isn't stated.  Is this an assumption to rely on for 
>> `distinct` and, more generally, the Clojure seq-based API functions?
>>
>> (2) In either case, when there are duplicates, there do not seem to be 
>> any guarantees on which one of the duplicates will be preserved.  Should 
>> this be stated?  I'm thinking that maybe this is about Clojure's design 
>> philosophy being that equal values to not ever need to be distinguished 
>> between, so the API doesn't explicitly support this concern.  However, 
>> there are times when identity relationships can matter - performance would 
>> be one that comes to mind.
>> - This has some relationship to the Scala question @ 
>> http://stackoverflow.com/questions/6735568/scala-seqlike-distinct-preserves-order
>>
>> There have been a few occasions where I relied on (or wanted to rely on) 
>> (1).  I haven't had many cases where (2) matters, but I could see it coming 
>> up on perhaps rare occasions. 
>>
>>

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

[Mike Rodriguez]

Yeah, I was thinking about logging the ticket for it.  I just figured I'd 
discuss it on the google groups first to see if anyone else thought it was 
a useful concern.
It seems that some people have opinions on in it in both directions 
perhaps, i.e. docs are sufficient vs docs are not sufficient.


On Thursday, December 29, 2016 at 5:50:14 PM UTC-6, Matching Socks wrote:
>
> How about a ticket for enhancement of the API documentation to clarify
> the nature of distinct's parameter (any seqable, even lazy)?  That would
> distinguish it from, e.g., (dedupe (sort coll)).
>

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

[Mike Rodriguez]

On Thursday, December 29, 2016 at 5:47:14 PM UTC-6, Erik Assum wrote:
>
> Wouldn't the order be different depending on wether you keep the first or 
> the last?
>
> (distinct [1 2 1])
> => [1 2]
> vs
> (distinct [1 2 1])
> => [2 1]
>
> Erik. 
> -- 
> i farta
>
>
I should have thought about this scenario beforehand.  I was almost 
convinced here that there was no usefulness in knowing which duplicate was 
kept.  However, it can effect order so really the part (2) problem relates 
to part (1).  Thanks for pointing that out.

And in reference to this one:
On Thursday, December 29, 2016 at 4:16:20 PM UTC-6, puzzler wrote:
> They may have different metadata, or some objects may already have cached 
hash values while others do not, or they may be complex enough objects that 
for a later part in the program it matters that certain equal objects meet 
the equality test quickly by actually being identical objects, not just 
equal.
 
These were the sort of things I was thinking about originally as the issue 
with my point (2).  I do agree that object identity has properties that can 
matter.  The metadata is a particularly good point.  
However, as I said above, the ordering concern is more of the issue I was 
mostly concerned with in general.

I appreciate everyone's input on this.

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

[Mike Rodriguez]

> f it helps anyone sleep better at night, were the behavior of distinct ever 
> to change in a way that breaks one's application, the original one is right 
> there in the git history, available for everyone's copying and use, with 
> whatever promises in the doc string you choose to add.

I understand it is easy to just fix it once it breaks. The point I had is just 
that without a guarantee it's an assumption. And if you don't think about it 
and it later changes, it can be subtle and hard to find. 

This actually came up as a discussion with my coworkers one day.  Someone 
mentioned Clojure doesn't seem to have any clear contract around if distinct 
preserves order or not. And I had a hard time arguing that you can "just trust 
it" since it doesn't really state that it does. 

So the main suggestion I'm getting is to just write my own test for this sort 
of assumption to avoid issues. I'd prefer some sort of doc or a generalized 
idea that all seq consuming, lazy seq returning functions build in a order 
preserving way. If that makes any sense. (I'm thinking like map and filter and 
so on relate to this idea). 

It's not really a big deal. Just a discussion I had come up "in the wild 
before". 

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

[Mike Rodriguez]

Yeah. It is so hard to come up with a real use case here after I think about it 
that it is best to just let it be. 

It would only matter if identity mattered for something, but still hard to even 
contrive a scenario. So part (2) solved. 

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

[Mike Rodriguez]

Yeah, adding a test for undocumented behavior seems somewhat reasonable.  I 
do wish the docs would be a bit clearer on these aspects of the contract. 
 Without that it just doesn't seem that there is any real commitment to the 
Clojure implementation to not change later.

I understand the general idea of "it is the most natural way to implement 
it".  However, that is shaky grounds to rely on.  It also makes me question 
if I've really thought it through to know "there isn't any other way to do 
it".  In the case of `distinct` I can be fairly sure it won't reorder them.

Also, it still isn't clear if it keeps the first or later duplicates or 
not.  That was the (2) part of the question.  I'm just guessing there the 
answer may just be "equal values are equal and you should never care which 
one you get out".  There are times to care though, but then perhaps just 
don't use `distinct` or be sure to have a test on it.  :P

I asked this question mostly out of curiosity and to see what others 
thought.  Also, to bring up the issue of if the docs are sufficient.  


On Wednesday, December 28, 2016 at 3:38:03 PM UTC-6, tbc++ wrote:
>
> This is one of those odd questions where the answer of what "could" happen 
> and what "will most likely happen" are completely different. There is no 
> reason why `distinct` should reorder or which item will be preserved. 
> However there's really only one logical way to implement this (the way it's 
> currently implemented) and in that case the answer would be "the first 
> duplicate is used", and "items are not reordered". 
>
> So all that to say, there's nothing in the docs that specify this is the 
> way it has to be, but it is the way it is now, is most likely not going to 
> change. So if you're really concerned about it, I'd say write a test around 
> distinct and wait for it to break someday if Clojure changes the undefined 
> behavior. 
>
> On Wed, Dec 28, 2016 at 9:55 AM, Michael Blume <blume...@gmail.com 
> > wrote:
>
>> Also, I'm assuming distinct uses .equals semantics which might be worth 
>> calling out in the doc
>>
>> On Wed, Dec 28, 2016, 11:22 AM Mike Rodriguez <mjr...@gmail.com 
>> > wrote:
>>
>>> The doc for `distinct` is:
>>> "Returns a lazy sequence of the elements of coll with duplicates removed.
>>>   Returns a stateful transducer when no collection is provided."
>>>
>>> (1) In the lazy sequence case, I've thought that maybe it is assuemd 
>>> there is a guarantee that the order of the input seq is preserved.  
>>> However, this isn't stated.  Is this an assumption to rely on for 
>>> `distinct` and, more generally, the Clojure seq-based API functions?
>>>
>>> (2) In either case, when there are duplicates, there do not seem to be 
>>> any guarantees on which one of the duplicates will be preserved.  Should 
>>> this be stated?  I'm thinking that maybe this is about Clojure's design 
>>> philosophy being that equal values to not ever need to be distinguished 
>>> between, so the API doesn't explicitly support this concern.  However, 
>>> there are times when identity relationships can matter - performance would 
>>> be one that comes to mind.
>>> - This has some relationship to the Scala question @ 
>>> http://stackoverflow.com/questions/6735568/scala-seqlike-distinct-preserves-order
>>>
>>> There have been a few occasions where I relied on (or wanted to rely on) 
>>> (1).  I haven't had many cases where (2) matters, but I could see it coming 
>>> up on perhaps rare occasions. 
>>>
>>> -- 
>>> 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

Order preservation and duplicate removal policy in `distinct`

[Mike Rodriguez]

The doc for `distinct` is:
"Returns a lazy sequence of the elements of coll with duplicates removed.
  Returns a stateful transducer when no collection is provided."

(1) In the lazy sequence case, I've thought that maybe it is assuemd there 
is a guarantee that the order of the input seq is preserved.  However, this 
isn't stated.  Is this an assumption to rely on for `distinct` and, more 
generally, the Clojure seq-based API functions?

(2) In either case, when there are duplicates, there do not seem to be any 
guarantees on which one of the duplicates will be preserved.  Should this 
be stated?  I'm thinking that maybe this is about Clojure's design 
philosophy being that equal values to not ever need to be distinguished 
between, so the API doesn't explicitly support this concern.  However, 
there are times when identity relationships can matter - performance would 
be one that comes to mind.
- This has some relationship to the Scala question @ 
http://stackoverflow.com/questions/6735568/scala-seqlike-distinct-preserves-order

There have been a few occasions where I relied on (or wanted to rely on) 
(1).  I haven't had many cases where (2) matters, but I could see it coming 
up on perhaps rare occasions. 

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

[Mike Rodriguez]

I also forgot to include the error message from my example GitHub project, 
in case it is easier than actually running it.  I understand this issue for 
the most part.  It has still been a bit tricky for me to fully understand 
how this AOT class interface/class is being referred to by any Clojure 
ClassLoader later on causing this.  I dug some and "sort of" understood at 
this point.  I know there have been many AOT + forced reloading of certain 
Clojure namespace issues in the past.  This one doesn't directly look like 
one I've seen.

However, remember, this isn't the only problem I'm bringing up here.  It is 
that AOT files in general would be ignored after shading with 
maven-shade-plugin.

The errors:

Exception in thread "main" java.lang.ClassCastException: 
clojure.pprint.proxy$java.io.Writer$IDeref$PrettyFlush$4923d848 cannot be 
cast to clojure.pprint.PrettyFlush
at 
clojure.pprint$pretty_writer$fn__4700.invoke(pretty_writer.clj:391)
at 
clojure.pprint.proxy$java.io.Writer$IDeref$PrettyFlush$4923d848.flush(Unknown 
Source)
at clojure.core$flush.invokeStatic(core.clj:3609)
at clojure.core$flush.invoke(core.clj:3603)
at clojure.core$prn.invokeStatic(core.clj:3620)
at clojure.core$prn.doInvoke(core.clj:3612)
at clojure.lang.RestFn.invoke(RestFn.java:397)
at clojure.pprint$pprint.invokeStatic(pprint_base.clj:252)
at clojure.pprint$pprint.invoke(pprint_base.clj:241)
at clojure.pprint$pprint.invokeStatic(pprint_base.clj:245)
at clojure.pprint$pprint.invoke(pprint_base.clj:241)
at shade.main$_main.invokeStatic(main.clj:6)
at shade.main$_main.doInvoke(main.clj:4)
at clojure.lang.RestFn.invoke(RestFn.java:397)
at clojure.lang.Var.invoke(Var.java:375)
at shade.ShadeJava.main(ShadeJava.java:14)

On Wednesday, December 28, 2016 at 7:06:11 AM UTC-6, Mike Rodriguez wrote:
>
> Background:
>
> This problem is specific to building jars that contain AOT (Ahead Of Time) 
> compiled Clojure code using Maven and the maven-shade-plugin.
>
> Clojure AOT compilation depends on timestamps of .class files vs .clj 
> files being accurate.  When both .class files and their associated .clj 
> files exist, the AOT .class files are only used by the compiler if their 
> last modified timestamp is strictly greater than the last modified 
> timestamp of the associated .clj file.
>
> Also note that the Clojure core jar itself is deployed AOTed.
>
> I know that much of the Clojure ecosystem uses Leiningen as a build tool 
> (and boot now too I guess).  This problem doesn't apply to Leiningen (and I 
> haven't looked at boot).
>
> Problem:
>
> The maven-shade-plugin is popular for building shaded/uber/standalone jars 
> in Maven.  Typically this means the jar will include some/all of its 
> dependency jars' files.  The maven-shade-plugin has an unfortunate property 
> though.  It does not preserve the timestamps on files that are added to 
> this final shaded jar.  The resulting jar actually ends up with all files 
> inside of it having the same timestamp (when the jar was created).  In 
> particular, if you originally had AOT Clojure .class files and .clj files 
> with different last modified timestamps, now they will have the same 
> timestamps in the shaded jar.
>
> I've brought this up before @ 
> http://stackoverflow.com/questions/19594360/preserving-timestamps-on-clojure-clj-files-when-building-shaded-jar-via-maven-s
>
> I have rarely seen people bring up issues around this with 
> maven-shade-plugin beyond this particular case.  I believe I have seen a 
> complaint or two around the timestamp loss during shading (I can't find 
> them now), but nothing that has gained any traction (I may try to bring it 
> up to the plugin people soon though).
>
> When the AOTed .class file is ignored in favor of the .clj file, the 
> namespace is JIT (Just-In-Time) compiled.  There are several issues with 
> this.
>
> 1) Performance:  It makes the AOT files mostly worthless since they are 
> not saving you on startup time costs anymore.  Everything is JITed anyways.
> 2) Errors:  The reloading of the .clj files is a forced reload of the .clj 
> namespaces involved.  This can cause classpath clashes among ClassLoaders.
> - There are quite a few CLJ Jiras out there that faced trouble dealing 
> with the mix of reloading namespaces and AOT compilation.
>
> You may be thinking, "Just don't build your Clojure jars with Maven.  Use 
> Leiningen instead perhaps?"
> This is fine when it is something you control.  However, what if I want to 
> use Clojure to develop a library that may be consumed by Java consumers who 
> very likely will be using Maven.  If my library is going to be shaded into 
> a standalone jar with maven-shad

Re: maven-shade-plugin issues with Clojure core (or any clj) AOT compilation

[Mike Rodriguez]

I appreciate your input.

When we have controlled the Maven shade projects, we have been able to 
workaround the issue as well.  We actually add a 
org.codehaus.mojo/exec-maven-plugin step where we re-open the shaded jar, 
create a new jar, and re-add every file into the new jar via a script. 
 While re-adding the files, we change all .clj files' timestamps to some 
time in the past and all other files just get the current time.  This 
ensures that all .clj files will look "older" than any AOT .class file that 
happens to be in the jar.

My main problem statement is primarily concerning when you *do not* control 
the build.  If I have a Clojure lib that is not-shaded and not AOT-compiled 
and that I have a Java API exposed on (which is what I demonstrate in my 
example project as shade.ShadeJava), this problem will come up for any Java 
consumer who happens to use maven-shade-plugin.  In this sort of case it 
reflects poorly on Clojure if arbitrary consumers have to do workarounds in 
their shade builds just because in my lib I'm wanting to use Clojure as an 
"implementation detail".

So I bring up this issue to just get a sense of what others think and what 
others think should/could be done about it.  Perhaps using Clojure behind 
Java APIs is just not a very common use-case people are working with.  It 
has been a pretty common one for me.  It does seem like a good use-case 
though to be supported to allow Clojure to sneak into existing Java-centric 
ecosystems.

On Wednesday, December 28, 2016 at 7:13:57 AM UTC-6, Gary Trakhman wrote:
>
> My workaround in a multi-module maven shaded java project with a clojure 
> module was to strip out CLJ files in the top-level build (shipped with 
> clojure.core jar). 
>
> I had also stripped CLJ files from my project artifact, but AOT compiles 
> classfiles from all referenced namespaces, so I attempted to strip those 
> out too earlier with the maven jar plugin. This necessitated manually 
> whitelisting AOT'd protocol classes from some of those 3rd party deps to 
> resolve further classloader issues.
>
> On Wed, Dec 28, 2016 at 8:06 AM Mike Rodriguez <mjr...@gmail.com 
> > wrote:
>
>> Background:
>>
>> This problem is specific to building jars that contain AOT (Ahead Of 
>> Time) compiled Clojure code using Maven and the maven-shade-plugin.
>>
>> Clojure AOT compilation depends on timestamps of .class files vs .clj 
>> files being accurate.  When both .class files and their associated .clj 
>> files exist, the AOT .class files are only used by the compiler if their 
>> last modified timestamp is strictly greater than the last modified 
>> timestamp of the associated .clj file.
>>
>> Also note that the Clojure core jar itself is deployed AOTed.
>>
>> I know that much of the Clojure ecosystem uses Leiningen as a build tool 
>> (and boot now too I guess).  This problem doesn't apply to Leiningen (and I 
>> haven't looked at boot).
>>
>> Problem:
>>
>> The maven-shade-plugin is popular for building shaded/uber/standalone 
>> jars in Maven.  Typically this means the jar will include some/all of its 
>> dependency jars' files.  The maven-shade-plugin has an unfortunate property 
>> though.  It does not preserve the timestamps on files that are added to 
>> this final shaded jar.  The resulting jar actually ends up with all files 
>> inside of it having the same timestamp (when the jar was created).  In 
>> particular, if you originally had AOT Clojure .class files and .clj files 
>> with different last modified timestamps, now they will have the same 
>> timestamps in the shaded jar.
>>
>> I've brought this up before @ 
>> http://stackoverflow.com/questions/19594360/preserving-timestamps-on-clojure-clj-files-when-building-shaded-jar-via-maven-s
>>
>> I have rarely seen people bring up issues around this with 
>> maven-shade-plugin beyond this particular case.  I believe I have seen a 
>> complaint or two around the timestamp loss during shading (I can't find 
>> them now), but nothing that has gained any traction (I may try to bring it 
>> up to the plugin people soon though).
>>
>> When the AOTed .class file is ignored in favor of the .clj file, the 
>> namespace is JIT (Just-In-Time) compiled.  There are several issues with 
>> this.
>>
>> 1) Performance:  It makes the AOT files mostly worthless since they are 
>> not saving you on startup time costs anymore.  Everything is JITed anyways.
>> 2) Errors:  The reloading of the .clj files is a forced reload of the 
>> .clj namespaces involved.  This can cause classpath clashes among 
>> ClassLoaders.
>> - There are quite a few CLJ Jiras out there that faced trouble

maven-shade-plugin issues with Clojure core (or any clj) AOT compilation

[Mike Rodriguez]

Background:

This problem is specific to building jars that contain AOT (Ahead Of Time) 
compiled Clojure code using Maven and the maven-shade-plugin.

Clojure AOT compilation depends on timestamps of .class files vs .clj files 
being accurate.  When both .class files and their associated .clj files 
exist, the AOT .class files are only used by the compiler if their last 
modified timestamp is strictly greater than the last modified timestamp of 
the associated .clj file.

Also note that the Clojure core jar itself is deployed AOTed.

I know that much of the Clojure ecosystem uses Leiningen as a build tool 
(and boot now too I guess).  This problem doesn't apply to Leiningen (and I 
haven't looked at boot).

Problem:

The maven-shade-plugin is popular for building shaded/uber/standalone jars 
in Maven.  Typically this means the jar will include some/all of its 
dependency jars' files.  The maven-shade-plugin has an unfortunate property 
though.  It does not preserve the timestamps on files that are added to 
this final shaded jar.  The resulting jar actually ends up with all files 
inside of it having the same timestamp (when the jar was created).  In 
particular, if you originally had AOT Clojure .class files and .clj files 
with different last modified timestamps, now they will have the same 
timestamps in the shaded jar.

I've brought this up before @ 
http://stackoverflow.com/questions/19594360/preserving-timestamps-on-clojure-clj-files-when-building-shaded-jar-via-maven-s

I have rarely seen people bring up issues around this with 
maven-shade-plugin beyond this particular case.  I believe I have seen a 
complaint or two around the timestamp loss during shading (I can't find 
them now), but nothing that has gained any traction (I may try to bring it 
up to the plugin people soon though).

When the AOTed .class file is ignored in favor of the .clj file, the 
namespace is JIT (Just-In-Time) compiled.  There are several issues with 
this.

1) Performance:  It makes the AOT files mostly worthless since they are not 
saving you on startup time costs anymore.  Everything is JITed anyways.
2) Errors:  The reloading of the .clj files is a forced reload of the .clj 
namespaces involved.  This can cause classpath clashes among ClassLoaders.
- There are quite a few CLJ Jiras out there that faced trouble dealing with 
the mix of reloading namespaces and AOT compilation.

You may be thinking, "Just don't build your Clojure jars with Maven.  Use 
Leiningen instead perhaps?"
This is fine when it is something you control.  However, what if I want to 
use Clojure to develop a library that may be consumed by Java consumers who 
very likely will be using Maven.  If my library is going to be shaded into 
a standalone jar with maven-shade-plugin by this Java consumer (again, 
likely) then this scenario can happen.

Another thought that may occur is to just avoid AOT compilation of my 
library application to avoid the problem (this is recommended in the 
community I believe).  However, Clojure core is AOT compiled and it will 
get included in the shaded jar.  That alone is enough to cause the issue.

Example:

I have a GitHub repo to show a minimum example of where this can be a 
problem.  In particular it shows a way for the problem (2) to occur.
@ https://github.com/mrrodriguez/mvn-shade-test

This repo has a Java API through shade.ShadeJava that will cause the 
Clojure compiler to require the shade.main namespace using JIT compilation. 
 However, shade.main uses clojure.pprint, which is AOT compiled via Clojure 
core.

clojure.pprint was chosen here just because it one of the cases I've seen 
come up that actually fail with problem (2) from above.  Even if there were 
no failures though, the Clojure core namespaces would be getting recompiled 
with problem (1).

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

[Mike Rodriguez]

Thanks, both of you, for the extra background there.

On Wednesday, December 21, 2016 at 9:44:34 AM UTC-6, Alex Miller wrote:
>
> From prior conversations, Rich is not in favor of the preference approach 
> for protocols. I'm not sure what he has in mind as an alternative though.
>
> On Wednesday, December 21, 2016 at 9:29:14 AM UTC-6, Nicola Mometto wrote:
>>
>> Something like what I proposed in 
>> http://dev.clojure.org/jira/browse/CLJ-1807 would help solve this 
>> ambiguity
>>
>>

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

[Mike Rodriguez]

On Wednesday, December 21, 2016 at 9:02:36 AM UTC-6, Alex Miller wrote:
>
>
>
> On Wednesday, December 21, 2016 at 7:24:17 AM UTC-6, Mike Rodriguez wrote:
>>
>> That sounds like a good idea to me. I think the major potential issue is 
>> that it creates ambiguity and non-deterministic dispatch for Clojure maps 
>> in CollReduce (as IPersistentMaps are both Iterable and Seqable). So that 
>> would need to be resolved.
>>
>
 
Yes, I thought of that and should have mentioned it in my post.  It seems I 
often run into this issue with extending protocols to types and causing 
non-determinism.
It'd be hard to pinpoint a "lower" type to cover these non-Clojure maps 
too.  I suppose java.util.AbstractMap would cover a large group, but that 
still seems a bit arbitrary.

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

Reducing non-Clojure maps may not behave as expected

[Mike Rodriguez]

I found an issue with Clojure's behavior on iterators that somewhat relates 
to what was discussed the comment thread of 
http://dev.clojure.org/jira/browse/CLJ-1738.  I'm posting it here to raise 
awareness and to see if anyone thinks it is a legitimate concern or 
"behaving as expected".

Fortunately, this issue hasn't came up too often, but Java 6's 
implementation of java.util.IdentityHashMap can be used to demonstrate the 
situation.  Note, the implementation of java.util.IdentityHashMap changed 
in Java 7+ so to see it, you'd have to use the Java 6 version.  My concern 
is more general than this specific occurrence though.

-

(def idm (java.util.IdentityHashMap. {:a 1 :b 2}))

(seq idm)
;;= (#object[java.util.IdentityHashMap$EntryIterator 0x70530bd9 ":b=2"] 
#object[java.util.IdentityHashMap$EntryIterator 0x70530bd9 ":b=2"])

(into {} idm)
;;= {:b 2}

;; Really conceptually the same as `into` above, just explicitly expressed 
for clarity.
(reduce conj {} idm)
;;= {:b 2}

;; Use transducers to try to pull key val out immediately

(into {} (map (juxt key val)) idm)
;;= {:b 2}

(sequence (map (juxt key val)) idm)
;;= ([:a 1] [:b 2])

(eduction (map (juxt key val)) idm)
;;= ([:a 1] [:b 2])

-

The issue is that the class IdentityHashMap$EntryIterator is used to 
iterate the entry set of the map.  It can be seen at
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/IdentityHashMap.java#IdentityHashMap.EntryIterator

This class is strange in that it plays both the role of java.util.Iterator 
and java.util.Map$Entry at the same time.  It mutates itself in place as a 
Map$Entry as it iterates.
This seems to be a sort of crazy implementation scenario, but it doesn't 
seem to violate any properties of Iterator or Iterable's contracts.

So above:
* `seq` is fairly obviously going to have a problem with anything that 
mutates in place
* `into` is a surprise to me.  `into` is based on `reduce` which I would 
expect to be inheritently 1-item at a time and therefore avoiding the issue.
* `reduce` just confirms there is an issue with the reducing that underlies 
`into` above

Going to transducers:
* `into` with transducers doesn't help anything - not surprisingly
* `sequence` ends up working out.  `sequence` internally used a chunked 
iterator over a clojure.lang.TransformerIterator.  The TransformerIterator 
gets too apply the transformation prior to the iterator moves onto the next 
item, so `key` + `val` is called "soon enough" to keep us safe.
* `eduction` works out for the same reason as `sequence`, but there is no 
chunking to be concerned with.

I think most of this is as I expect, the one that bothers me is that 
`reduce` is unable to traverse this IdentityHashMap.  I'd typically think 
of `reduce`, and anything based on it to be "safe" in terms of being sure 
to fully access 1-item at a time, regardless of if the underlying iterator 
is doing in place mutation.

Also, since `reduce` doesn't work like I'd expect here, it makes me 
question if I could rely on the fact that `sequence` and `eduction` do 
happen to work out right now.

Digging into `reduce`, the issue seems to be fairly clear.  A 
IdentityHashMap does not extend Iterator, Iterable, clojure.lang.IReduce, 
or clojure.lang.IReduceInit.  This is true for most non-Clojure Map's.
`reduce` is based on protocols.  The first is 
`clojure.core.protocols/CollReduce` with the 
`clojure.core.protocols/coll-reduce` function.  A non-Iterable Map falls 
into the default Object implementation of `coll-reduce`.  In turn this goes 
to `clojure.core.protocols/seq-reduce`.  `seq-reduce` calls `seq` on the 
collection.

In context of this example, this means we end up having `reduce` on an 
IdentityHashMap call through to `seq` before reducing.  As seen and 
expected above, `seq` isn't going to work out with this mutate-in-place 
sort of iterator.

---

I bring this up here because it has snuck up on me a few times.  I haven't 
found many java.util.Map impl's in the wild that cause this trouble beyond 
java.util.IdentityHashMap.  However, it worries me that I need to check 
each impl I may use if I'm going to trust anything that `reduce`s on it.  I 
tend to just completely avoid it with Java iterop now due to not knowing 
what Clojure's guarantees are.  So I just use an explicit `loop` + `recur` 
that manually traverses the entry set via its iterator one at a time for 
these sorts of maps.

I'm curious to see others' thoughts on this issue.  One thought I had was 
that `clojure.core.protocols/CollReduce` could provide an explicit 
implementation of `coll-reduce` for java.util.Map that (recursively) called 
`coll-reduce` on it's Iterable entry set.  This would avoid this particular 
issue it looks like at least.

e.g.

(extend-protocol clojure.core.protocols/CollReduce
  java.util.Map
  (coll-reduce
([coll f] (clojure.core.protocols/coll-reduce (.entrySet coll) f))
   

Re: [ANN] 2016 State of Clojure Community Survey

[Mike Rodriguez]

Uh oh. I should have asked. I ranked my priorities in the exact opposite order 
since I thought 1 was lowest. 

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

[Mike Rodriguez]

Just FYI. The code part under "Tabs are printed as \t:" has a typo and shows a 
new line instead of tab. 

Otherwise nice work. 

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

[Mike Rodriguez]

I'm excited about this :managed-dependencies feature along with it's 
combined usage with lein-parent.  I think this is a feature I really needed 
from Leiningen for quite some time now.


On Wednesday, August 24, 2016 at 7:03:52 PM UTC-5, Jean Niklas L'orange 
wrote:
>
> Greetings, fellow Clojurians!
>
> I am happy to announce Leiningen 2.7.0! This release contains mostly
> bugfixes, but two major new improvements were added. There is now a
> PowerShell version of `lein.bat`, and `:managed-dependencies` has been
> added to Leiningen.
>
> Both improvements should be considered to be in beta, but please try
> them out and report bugs you find in the GitHub issue tracker. The
> rationale for `:managed-dependencies` can be found at [1].
>
> To replace `lein.bat` with the PowerShell equivalent, download
> `lein.cmd` [2] and `lein.ps1` [3] in its stead, and run as usual. If
> you end up with an error related to `Invoke-WebRequest`, then it may
> be a result of an old version of PowerShell, which seems to be
> resolved by installing the Windows Management Framework 4.0 [4].
>
> The full list of significant user changes:
>
> * Add PowerShell script for Windows users. (Brian Lalonde)
> * Run `:prep-tasks` before `lein test`, so generated test namespaces
>   will be tested. (Martin Reck)
> * Better error message when attempting to do `lein run` without
>   `project.clj`. (Eduardo Seabra Silva)
> * Add support for `:managed-dependencies`. (Chris Price)
> * Provide the current clojars certificate. (Toby Crawley)
> * Add `*eval-print-dup*` to evaluate forms passed to
>   `eval-in-leiningen` with `*print-dup*`. (Eduardo Seabra Silva)
> * Update bash completions. (Zack Dever)
> * Respect `:scm :dir` in `lein vcs` commands. (Ian Kerins)
> * Improve whitespace handling from `JVM_OPTS`. (Stephen Nelson)
> * Catch and handle fixture errors during `lein test`. (Alex Hall)
> * Fix a bug where spaces in directory names on Windows caused crashes.
>   (Leon Mergen, Tobias Kiertscher, Jean Niklas L'orange)
> * Fix a bug where `lein search` would take forever downloading
>   clojars.org. (Paul Dorman)
> * Retain user defined private repositories when building jars,
>   uberjars and deploy. (Rick Moynihan)
> * Honor whitelist settings when `lein javac` is called via `lein jar`.
>   (Chris Price)
> * `lein vsc push` for git will now only push branch-related tags.
>   (Łukasz Klich)
>
> Those who have manually installed Leiningen can run `lein upgrade` to
> pull down 2.7.0. `lein downgrade 2.6.1` will back it down to the
> previous version if you run into any issues. Keep in mind that the
> PowerShell script was introduced in this release, hence there are no
> downgrade candidates for it right now.
>
> We have had lots of contributors help out making this release happen,
> and I'd especially like to thank Chris Price (cprice404) and Florian
> Anderiasch (winks) for their help with this release.
>
> [1]: 
> https://github.com/technomancy/leiningen/blob/stable/doc/MANAGED_DEPS.md
> [2]: 
> https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein.cmd
> [3]: 
> https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein.ps1
> [4]: 
> http://social.technet.microsoft.com/wiki/contents/articles/21016.how-to-install-windows-powershell-4-0.aspx
>
> -- Jean Niklas
>
>
>

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

[Mike Rodriguez]

Thanks for the response and giving me some understanding in the thought 
process behind this!

I'm happy that Spec is still offering support for unqualifed keys to fit 
use-cases like this in records.  I do think it would be cool to see 
something come out of the "implicit" namespace already associated to a 
record so that the keywords could be used in a qualified way, but obviously 
we'll have to wait and see how that one may or may not play out.  

It's good to hear that the thought has came up though!

On Saturday, June 11, 2016 at 11:57:38 AM UTC-5, Alex Miller wrote:
>
> This is a good question and one we've discussed a bit. You can use the 
> existing s/keys with :req-un and :opt-un to spec the (unqualified) keys of 
> a record - there's an example of this in the guide at 
> http://clojure.org/guides/spec. So that's the short-term current answer.
>
> However, there are potentially other things that could be done, either to 
> make working with unqualified keys easier (for example in the case where 
> spec names and unqualified key names didn't match) or in leveraging the 
> (implicit) namespace already associated with a record via the record class 
> itself. So, this is an area still potentially open for more work.
>
> I think deftype is not an issue as you don't generally have keyword field 
> access in deftype like you do with defrecord.
>
>
> On Saturday, June 11, 2016 at 11:02:57 AM UTC-5, Mike Rodriguez wrote:
>>
>> I know that Spec and the changes coming to Clojure 1.9 I see that 
>> namespace qualified keys have gained some focus. I understand the 
>> motivations for this and support it.  
>>
>> The one barrier that is coming up for me is in the use of Clojure records 
>> (and perhaps deftype types too). We use records fairly heavily in some of 
>> our applications for a few reasons.  
>>
>> (Some of this is for performance, some for instanceof support for some 
>> Java-style libraries we use, some is for better documentation of expected 
>> fields used repeatedly, and also we have used them to extend different 
>> protocol implementations to.) 
>>
>> I believe in some older talks a selling point of records, which I agree 
>> with, is they could be added later with not much change if you were already 
>> using maps throughout with those keys. This is due to record participating 
>> in the map abstractions.  
>>
>> So how can namespace qualified keys and the use of records intermix? Even 
>> if I am using maps combined with records where the record and maps share 
>> some common keys/fields, if the maps were qualified, they'd be incompatible 
>> I believe. If records keys were qualified it would obviously raise a little 
>> question on how they blend with the emitted Java class field names  
>>
>> I'd be curious to hear if there is any work or thought on this. Or maybe 
>> I can qualify keys and interoperate with records already and I just haven't 
>> noticed? 
>
>

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

Qualified keys, Clojure records, Spec

[Mike Rodriguez]

I know that Spec and the changes coming to Clojure 1.9 I see that namespace 
qualified keys have gained some focus. I understand the motivations for this 
and support it. 

The one barrier that is coming up for me is in the use of Clojure records (and 
perhaps deftype types too). We use records fairly heavily in some of our 
applications for a few reasons. 

(Some of this is for performance, some for instanceof support for some 
Java-style libraries we use, some is for better documentation of expected 
fields used repeatedly, and also we have used them to extend different protocol 
implementations to.)

I believe in some older talks a selling point of records, which I agree with, 
is they could be added later with not much change if you were already using 
maps throughout with those keys. This is due to record participating in the map 
abstractions. 

So how can namespace qualified keys and the use of records intermix? Even if I 
am using maps combined with records where the record and maps share some common 
keys/fields, if the maps were qualified, they'd be incompatible I believe. If 
records keys were qualified it would obviously raise a little question on how 
they blend with the emitted Java class field names 

I'd be curious to hear if there is any work or thought on this. Or maybe I can 
qualify keys and interoperate with records already and I just haven't noticed? 

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

[Mike Rodriguez]

Thanks for this explanation.  I think that cleared up some of this for me 
more.  I'm certainly excited about this new addition.  I should have 
started off with that.

On Wednesday, May 25, 2016 at 8:01:49 PM UTC-5, Rich Hickey wrote:
>
> I’d advise everyone concerned/confused about the relationship between spec 
> and data representations to please spend some more time trying to 
> understand spec and, especially, dial back the rhetoric. I know what the 
> Clojure philosophy is, and it’s not some triviality. 
>
> specs are fundamentally code (predicates and logic) 
>
> Clojure code is a great data format for code, designed to be written and 
> read by humans. There is a reason we don’t write code in AST maps: 
>
> (if x y z) 
>
> vs 
>
> {:tag :if-expr :test x :then y :else z} 
>
> The ‘form’ function will return the spec as sexpr data. This is currently 
> missing gens but that will come (if gens don’t end up somewhere else 
> entirely). You can eval this data and get a running spec. Or not. If you 
> don’t want to, that doesn’t make the fact that you can bad. Data doesn’t 
> run, so any data-driven ‘language’ is going to need an 
> interpreter/compiler. 
>
> Claiming sexprs aren't ‘data’ suitable for programmatic manipulation 
> denies a 50+ year Lisp history. 
>
> Expecting runtime specs to ‘be’ data is no more desirable than leaving 
> code as data at runtime - it would always need interpretation. Runtime 
> specs are (sets of) functions, and are as binary as functions.  What 
> matters is that they are available as data, which they are. 
>
> If you prefer an AST-like thing you are only a spec and conform call away 
> from it. This is the key point people are missing who haven’t used spec 
> enough. If you have an sexpr or other data-format syntax you don’t need to 
> write a parser, you need to write a spec. conform will destructure for you. 
>
> We intend to provide specs for spec which can be used for these and other 
> purposes. 
>
> Rich 
>
> > On May 25, 2016, at 7:11 PM, Leif  
> wrote: 
> > 
> > I guess I'm confused why the Clojure philosophy of "data > fns > macros" 
> is being ignored in this particular case, when the other schema libraries 
> show that there is an army of end-users that want to do unexpected things 
> with specifications, and to do that, it would be easiest if they had data 
> IRs, c.f. the Schema model: 
> > 
> > macros to look nice -> 
> > data repr -> 
> > -compile to-> validator or 
> > -translate to-> data repr with subgenerators attached -> 
> > -compile to-> generator or 
> > -compile to-> ??? something a clever tester dreamed up ??? 
> or 
> > -compile to-> fn returning nice error message or 
> > -compile to-> ??? something a clever user dreamed up ??? 
> > 
> > I'll leave it at that, I've put my 6 cents in. 
> > 
> > -- 
> > 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.9.0-alpha1

[Mike Rodriguez]

>
>
>> Is there a recommended way to introspect specs for our own purposes 
>>> (coercion, code generation)?  An interpreter on the output of 'describe' 
>>> might work (although it's a little complicated for fn specs), but I wanted 
>>> to know if you all had any thoughts or plans for the future here.
>>>
>>  
>>
>>> Could you give more details on what question you would like to ask?
>>>
>>  
>> Better people to ask would be those that have a lot of experience writing 
>> translators for specs, like the Schema devs.  But I'll give my muddled 
>> thoughts here:
>>
>> Right now, the internals of different instances of Spec are private.  So, 
>> to write a translator from a Spec to the approximate json or avro schema it 
>> specifies, or translate from a Spec to a function that coerces a String to 
>> a data structure that conforms, I would have to:
>>
>> 1. Parse the output of 'describe' back into a description of the Spec's 
>> internals (if I can get at all of them)
>>
>
> I'm not sure why you need the internals - the vocabulary of spec is 
> relatively small (+ the open-ended world of predicates). It doesn't seem 
> possible to translate open-ended predicates to fixed types in json or avro, 
> but you could look for known predicates.
>
>>
>>

I will add here that I have found quite a bit of leverage from being able 
to use Prismatic schema's data-representation for generating Avro schema 
from records.  Yes, we only support a subset of all possible Schema, since 
Schema also allows for arbitrary predicates as schema.  We've also had 
other occasions where we could write general functions that gave default 
values to fields that had the same Schema instead of relying on what that 
field is named etc.  
I always really liked that Prismatic Schema had a "data representation" and 
that seems to be the Clojure-way anyways.  I haven't dug into this too much 
yet, but I'm hoping that the Spec's do have some way to programmatically 
inspect them and utilize their structures for other purposes. 

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

[Mike Rodriguez]

Vectors are eager. So they'd need to be finite. Varargs/rest args can be 
infinite lazy sequences. So it is appropriate that they are just generic "seq" 
abstractions instead of something specific (and eager) like a vector. 

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

[Mike Rodriguez]

I won't speak directly to your use-case other than saying that `extend` is 
already a function, so there is no reason to call it with a macro or via 
strange evaluation orders via quotes and eval.
You can define the record first, as normal, then call `extend` after 
dynamically and without messing with the evaluation order of functions etc.

I may be missing something more that you were trying to do, but from your 
example I didn't see any need for the complexity.

On the topic of if eval allows arbitrary objects to be embedded in the 
"code" it is evaluating:

I can see how the docs @ http://clojure.org/reference/evaluation could 
mislead someone to thinking that it is perfectly fine and acceptable to 
embed any objects into a call to `eval`, but I really don't think that is 
what the docs are discussing in this case.  Calling `eval` is a way to dig 
into the evaluator of Clojure to use it "ad hoc" yourself at a different 
time than "normal".

So at this point, you've circumvented Clojure's standard evaluation and you 
are attempting to take matters into your own hand.  When you do that, there 
starts to become a lot of subtle issue, like the one of whether or not you 
can get away with embedding already evaluated objects into a new 
evaluation.  Since, in your example, you functions are already evaluated to 
their function objects, you are effectively "double evaluating" them.  When 
you do that, expect issue.

This is a subtle and confusing topic because there are indeed times when 
you can get away with embedding objects into the code you are calling eval 
on.  However, I'd argue that is not the normal case and you shouldn't rely 
on that because it doesn't take much change to break it and no longer be 
able to do it.  For example, functions that have closures, I believe, can 
never successfully be embedded into a call to eval.

The real point here is in understanding evaluation semantics.  The reader 
reads characters/text into data structures.  However these data structure 
are not unbounded.  They are the data structures that are used to describe 
the syntax of the Clojure language, e.g. [], {}, (), :keywords, symbols, 
"strings", 123, etc.
If you try to print a function object, you'll see it has no clear 
representation as a valid data structures in the Clojure syntax subset of 
data structures.  
It'll be something like: 

This is your warning sign that it is going to be trouble to call eval on 
it.  Eval is intended to evaluate _code_ represented as data.  This 
function object is not in a form amendable for interpretation as code.

If you do not try to control evaluation yourself, when evaluating functions 
typically looks like this (fn [x] (inc x)).  That is not a function object 
to the evaluator.  It is a list, with 3 elements.  The first is a symbol, 
the next is a vector, the last is another list, and we can describe its 
subforms similarly.

Clojure does provide a facility to give a meaningful reader/data syntax 
representation to arbitrary objects to allow evaluation later for things 
like serialization.  This is via the 
clojure.core/print-dup family of functionality.  Functions themselves in 
Clojure do not out-of-the-box come with a useful implementation of 
print-dup, but it is a multimethod and can be dynamically extended to new 
types of data.

I think you should try to solve your problem in a simpler way than going to 
this level of depth and/or trying to call eval yourself on 
already-pre-evaluated forms, but for the sake of learning, you may be 
interested in seeing how to make a macro for creating functions that do 
have a print-dup implementation that would allow them to be printed as 
readable, then "evaluatable" code data structures later on. 
 https://github.com/sorenmacbeth/serializable-fn is an example of this.  I 
have used it for inspiration before where I did want to be able to 
serialize pre-eval'ed functions, but I had some tweaks to it of my own. 
 The basic idea holds.  However, I only have needed to go to this level of 
complexity when I was trying to serialize this data so that I could store 
it away and use it in another separate process later, which I think is 
where it can become useful.


Hopefully you find this useful.

On Wednesday, May 4, 2016 at 5:55:12 PM UTC-5, Ben Kovitz wrote:
>
> On May 4, 2016, at 6:08 PM, Johannes  
> wrote:
>
> okay, but why does the following work without quotation?
> user> (def f- (let [v 1
>   f (fn [x] x)] f))
> ;; => #'user/f-
> user> (eval {:d f-})
> ;; => {:d #function[user/fn--14679/f--14680]}
> user>  
>
>
> The problem is that the place in my program where I give the map 
> containing the function object to eval, the map cannot be quoted.
>
>
> Hmm, I thought I had read “eval doesn’t accept function objects” in a 
> couple places on the Internet, but when I checked this page:
> http://clojure.org/reference/evaluation
> I found the sentence "Any object other 

[ANN] Elements of Clojure

[Mike Rodriguez]

Read it and like it so far! 

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

[Mike Rodriguez]

This issue is a subtle one.  I do find it interesting that all vars are 
created and mapped to their namespace in the initN() (where N is 0 though 
whatever) methods.
However, other top-level function calls happen in the load() method.  All 
of this runs in the clinit of the class though.  

I'd really like to understand/get an explanation of the reason why some 
things go in the initN() methods vs what goes in the load() method.  I 
think it looks mostly clear that initN() methods just assign values to 
static fields of the class and everything else goes in load().  That may be 
an oversimplification though.

The thing that really surprised me on this one is that the order of 
operations in the AOT class is not really the same as the order you'd 
expect the compiler events to occur.  I do agree that multiple `def`s of 
the same var is probably a bad pattern.

On Wednesday, December 30, 2015 at 12:02:35 PM UTC-6, Nicola Mometto wrote:
>
> While it's true that AOT has many issues, it's getting better release 
> after release and this is definitely a bug. 
> I don't understand why you wouldn't expect this to work, you *should*. 
>
> OP: can you open a ticket for this bug? I'd love to have a look at this 
> and try to fix it. 
>
> > On 29 Dec 2015, at 17:28, Stuart Sierra  > wrote: 
> > 
> > AOT-compilation breaks almost any code that tries to redefine Vars. I 
> wouldn't expect this to work. 
> > —S 
> > 
> > 
> > On Monday, December 28, 2015, wparker30 wrote: 
> > I have found what appears to be a bug in AOT-compiled Clojure when 
> ns-unmap is used.  I have the following reduced case: 
> > 
> > (ns unmap-test.core) 
> > 
> > (def a :test-1) 
> > 
> > (ns-unmap 'unmap-test.core 'a) 
> > 
> > (def a :test-2) 
> > 
> > It turns out that a is not resolvable when this namespace is loaded. 
>  When I looked at the compiled bytecode, 
> > it appears that the following operations occur: 
> > 
> > 1. A call to RT.var withe 'unmap-test.core and 'a returns a Var, which 
> is bound to a constant. 
> >   This var is added to the namespaces's mapping during this call. 
> > 2. Same as 1. 
> > 3. The var from 1 is bound to :test-1. 
> > 4. ns-unmap is called. 
> > 5. The var from 2 is bound to :test-2. 
> > 
> > Disclaimer: This is the first time I have had occasion to look directly 
> at bytecode and I could be missing something. 
> > 
> > The basic problem here is that the var is accessible from the load 
> method, but when step 5 executes the var is no longer 
> > accessible from the namespace mappings.  Thus, the root of the Var is 
> set to :test-2, but that Var is not mapped from the namespace. 
> > This works when there is no AOT compilation, as well as when I use 
> > 
> > (ns unmap-test.core) 
> > 
> > (def a :test-1) 
> > 
> > (ns-unmap 'unmap-test.core 'a) 
> > 
> > (intern 'unmap-test.core 'a :test-2) 
> > 
> > I realize that creating defs, unmapping them, and then recreating them 
> is generally poor practice in Clojure. 
> > We have an odd case in that we need to have an interface and a Var of 
> the same name in the same namespace.  Simply 
> > doing definterface and then def causes a compilation failure: 
> > 
> > user=> (definterface abc) 
> > user.abc 
> > user=> (def abc 1) 
> > CompilerException java.lang.RuntimeException: Expecting var, but abc is 
> mapped to interface user.abc, 
> compiling:(/private/var/folders/3m/tvc28b5d7p50v5_8q5ntj0pmflbdh9/T/form-init4734176956271823921.clj:1:1)
>  
>
> > 
> > Without going into too much detail, this is basically a hack to allow us 
> to refactor our internal framework code 
> > without immediately changing a very large amount of downstream consumer 
> code.  We get rid of the usage of the interface during macroexpansion, 
> > but it still needs to exist on the classpath so it can be imported by 
> downstream namespaces.   
> > There are a number of other ways to accomplish this, so it isn't a 
> particularly big problem for us, but I thought the issue was worth raising. 
> > This was just the first thing I tried and I was surprised when it didn't 
> work. 
> > 
> > Note that I used the 1.8.0 RC4 version of Clojure in my sample project, 
> but I had the same behavior on 1.7.0. 
> > 
> > Relevant links: 
> > 
> > 1. Bytecode for the load method of the init class: 
> https://gist.github.com/WilliamParker/d8ef4c0555a30135f35a 
> > 2. Bytecode for the init0 method: 
> https://gist.github.com/WilliamParker/dc606ad086670915efd9 
> > 3. Decompiled Java code for the init class.  Note that this does not 
> completely line up with the bytecode as far as I can tell, 
> > but it is a quicker way to get a general idea of what is happening than 
> the bytecode. 
> > https://gist.github.com/WilliamParker/4cc47939f613d4595d94 
> > 4. A simple project containing the code above: 
> https://github.com/WilliamParker/unmap-test 
> > Note that if you try it without AOT compilation the target folder with 
> any previously compiled classes should be removed. 

Re: Why "some-fn" is not called "some-pred" or "every-pred" is not called "every-fn" and vicer-versa.

[Mike Rodriguez]

Nothing specific but for the same reason you'd want to use 'and' in other 
scenarios. You want the short-circuit behavior if certain criteria are met. 

Only in this case you just want a function that does it instead. 

One contrived example coming to mind:
(every-fn iterative-has-next? get-next)

Of course there are likely better ways to deal with iterators in Clojure. It is 
just a contrived example. The basic idea is that the 'every-fn' is checking 
certain properties of the args first prior to calling the fn that relies on 
those properties being a certain way. 

I'm not saying this is a common scenario I have.
I think I'm Java interop cases these sort of things come up a bit more often 
for me though.
 
My overall point is that it is more convenient/useful in more scenarios to 
return the value instead of 'true'. That is what makes it convenient and useful 
to use 'or' and 'and' and 'some-fn' in non-predicate ways. 
'every-pred' is an outlier. 

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

Why "some-fn" is not called "some-pred" or "every-pred" is not called "every-fn" and vicer-versa.

[Mike Rodriguez]

The distinction between names is important when one is a predicate and the 
other is not. However I think it would be more useful if it were every-fn since 
it is often more useful to have the final return value vs just true false. This 
is consistent with the behavior or and and or. So some-fn seems to get it right 
and every-pred deviates for some reason. 

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

[Mike Rodriguez]

Nice! I'm excited to try this one out. Good 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.

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Mike Rodriguez]

I second Ghadi's question (2). Is there any further information to read that 
discusses the benefits found from direct linking? I understand the motivation. 
I was just hoping to here some performance boost success stories. 

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

[Mike Rodriguez]

I did a trial run of some of my production applications (big data space) and I 
did see an overall improvement in execution time that seemed consistent. It was 
not too significant of a difference though, but it was still good to see. I am 
not positive my use case would have necessarily been in position to drastically 
improve from the direct linking at this point though anyways. 
I also haven't tried to direct link my own application code (I think that's an 
option you can switch on, I forget ). 

I was just curious to hear if there were some significant differences people 
have observed. It's always good to see concrete examples. 

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

[Mike Rodriguez]

Nice.  Thanks for pushing that through a Jira and into 1.8 so quickly!

On Tuesday, October 27, 2015 at 1:32:46 PM UTC-5, Alex Miller wrote:
>
> The map-entry? predicate was just committed to master and will be in the 
> next build.
>
> On Friday, October 16, 2015 at 1:29:21 PM UTC-5, Mike Rodriguez wrote:
>>
>> Yes a `map-entry?` predicate was sort of the direction I was leaning in 
>> that would help avoid issues like this around these changes.
>>
>> On Friday, October 16, 2015 at 10:58:47 AM UTC-5, Alex Miller wrote:
>>>
>>> Perhaps having a "map-entry?" predicate that was smarter would be 
>>> helpful.
>>>
>>> On Friday, October 16, 2015 at 9:39:09 AM UTC-5, Mike Rodriguez wrote:
>>>>
>>>> Yes, I am in support of the fact that size=2 vectors now can now have 
>>>> `key` and `val` called on them.  This not working prior to Clojure 1.8 was 
>>>> occasionally the reason why I just used `first` and `second` instead of 
>>>> `key` and `val` before since some function transformations could result in 
>>>> size=2 vectors rather than true map entries.
>>>>
>>>> I think that supporting `empty` on MapEntry is weird, as Alex said 
>>>> above.  It does sound the same as the record case. 
>>>>
>>>> The only frustration I have with this change is that not all 
>>>> APersistentVectors really act as a map entry.  Only those of size=2 do.  
>>>> So 
>>>> the interface becomes misleading if you try to use it to figure out from a 
>>>> generic standpoint, what things are map entries and what things aren't. 
>>>>  The ambiguity is that all vectors look like map entries.  I guess you 
>>>> could do the 
>>>> (instance? IMapEntry x) check along with (== 2 (count x)) for the 
>>>> vector case...
>>>>
>>>> On Friday, October 16, 2015 at 6:39:50 AM UTC-5, Alex Miller wrote:
>>>>>
>>>>>
>>>>> On Friday, October 16, 2015 at 3:32:43 AM UTC-5, Pierre-Yves Ritschard 
>>>>> wrote:
>>>>>>
>>>>>> Hi Mike, 
>>>>>>
>>>>>> The code at here seems to contradict you: 
>>>>>>
>>>>>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/APersistentVector.java#L448-L460,
>>>>>>  
>>>>>>
>>>>>> as does "(key [:a :b])" in the REPL. 
>>>>>>
>>>>>> The only limitation is that vectors need to be of size two to act as 
>>>>>> IMapEntries (otherwise an IllegalOperation exception is thrown). 
>>>>>>
>>>>>> The change seems logical and allows key & val to be used more 
>>>>>> generically. 
>>>>>>
>>>>>> You're right that will fail on code that checks for (instance? 
>>>>>> IMapEntry). 
>>>>>>
>>>>>
>>>>> APersistentVector implements IMapEntry, so this doesn't seem correct.
>>>>>  
>>>>>
>>>>>> A good alternative - paging Alex Miller - could be for (empty) on a 
>>>>>> MapEntry to return an empty PersistentVector instead of nil, which 
>>>>>> would 
>>>>>> ensure that calls to (into (empty ) (map f )) 
>>>>>> would return a valid map entry (instead of a collection). 
>>>>>>
>>>>>
>>>>> It does not make sense to me for empty on a MapEntry to do what you 
>>>>> ask (for similar reasons why empty on a record is not allowed).
>>>>>  
>>>>>
>>>>>> I'm happy to create a ticket for this use-case if deemed valid. 
>>>>>>
>>>>>> Cheers, 
>>>>>>   - pyr 
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 10/16/2015 01:28 AM, Mike Rodriguez wrote: 
>>>>>> > Someone else looked at the issue on 
>>>>>> https://github.com/ztellman/riddley/issues/18 
>>>>>> > 
>>>>>> > This issue makes the current version of riddley, and therefore 
>>>>>> potemkin, not work on Clojure 1.8 beta1 
>>>>>> > 
>>>>>> > There is a pull request to fix it at 
>>>>>> https://github.com/ztellman/riddley/pull/19 
>>>>>> > 
>>>>>> > However I am wondering if it is going to affect more places. The 
>>>>>> problem is that in Clojuee 1.8 APersistentVector now implements 
>>>>>> IMapEntry 
>>>>>> (therefore j.u.Map$Entry as well), but it doesn't implement the key or 
>>>>>> val 
>>>>>> methods. 
>>>>>> > What is the reason for that change and/or is this a desired side 
>>>>>> effect of the change? 
>>>>>> > 
>>>>>>
>>>>>

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

[Mike Rodriguez]

Yes a `map-entry?` predicate was sort of the direction I was leaning in 
that would help avoid issues like this around these changes.

On Friday, October 16, 2015 at 10:58:47 AM UTC-5, Alex Miller wrote:
>
> Perhaps having a "map-entry?" predicate that was smarter would be helpful.
>
> On Friday, October 16, 2015 at 9:39:09 AM UTC-5, Mike Rodriguez wrote:
>>
>> Yes, I am in support of the fact that size=2 vectors now can now have 
>> `key` and `val` called on them.  This not working prior to Clojure 1.8 was 
>> occasionally the reason why I just used `first` and `second` instead of 
>> `key` and `val` before since some function transformations could result in 
>> size=2 vectors rather than true map entries.
>>
>> I think that supporting `empty` on MapEntry is weird, as Alex said above. 
>>  It does sound the same as the record case. 
>>
>> The only frustration I have with this change is that not all 
>> APersistentVectors really act as a map entry.  Only those of size=2 do.  So 
>> the interface becomes misleading if you try to use it to figure out from a 
>> generic standpoint, what things are map entries and what things aren't. 
>>  The ambiguity is that all vectors look like map entries.  I guess you 
>> could do the 
>> (instance? IMapEntry x) check along with (== 2 (count x)) for the vector 
>> case...
>>
>> On Friday, October 16, 2015 at 6:39:50 AM UTC-5, Alex Miller wrote:
>>>
>>>
>>> On Friday, October 16, 2015 at 3:32:43 AM UTC-5, Pierre-Yves Ritschard 
>>> wrote:
>>>>
>>>> Hi Mike, 
>>>>
>>>> The code at here seems to contradict you: 
>>>>
>>>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/APersistentVector.java#L448-L460,
>>>>  
>>>>
>>>> as does "(key [:a :b])" in the REPL. 
>>>>
>>>> The only limitation is that vectors need to be of size two to act as 
>>>> IMapEntries (otherwise an IllegalOperation exception is thrown). 
>>>>
>>>> The change seems logical and allows key & val to be used more 
>>>> generically. 
>>>>
>>>> You're right that will fail on code that checks for (instance? 
>>>> IMapEntry). 
>>>>
>>>
>>> APersistentVector implements IMapEntry, so this doesn't seem correct.
>>>  
>>>
>>>> A good alternative - paging Alex Miller - could be for (empty) on a 
>>>> MapEntry to return an empty PersistentVector instead of nil, which 
>>>> would 
>>>> ensure that calls to (into (empty ) (map f )) 
>>>> would return a valid map entry (instead of a collection). 
>>>>
>>>
>>> It does not make sense to me for empty on a MapEntry to do what you ask 
>>> (for similar reasons why empty on a record is not allowed).
>>>  
>>>
>>>> I'm happy to create a ticket for this use-case if deemed valid. 
>>>>
>>>> Cheers, 
>>>>   - pyr 
>>>>
>>>>
>>>>
>>>> On 10/16/2015 01:28 AM, Mike Rodriguez wrote: 
>>>> > Someone else looked at the issue on 
>>>> https://github.com/ztellman/riddley/issues/18 
>>>> > 
>>>> > This issue makes the current version of riddley, and therefore 
>>>> potemkin, not work on Clojure 1.8 beta1 
>>>> > 
>>>> > There is a pull request to fix it at 
>>>> https://github.com/ztellman/riddley/pull/19 
>>>> > 
>>>> > However I am wondering if it is going to affect more places. The 
>>>> problem is that in Clojuee 1.8 APersistentVector now implements IMapEntry 
>>>> (therefore j.u.Map$Entry as well), but it doesn't implement the key or val 
>>>> methods. 
>>>> > What is the reason for that change and/or is this a desired side 
>>>> effect of the change? 
>>>> > 
>>>>
>>>

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

[Mike Rodriguez]

Yes, I am in support of the fact that size=2 vectors now can now have `key` 
and `val` called on them.  This not working prior to Clojure 1.8 was 
occasionally the reason why I just used `first` and `second` instead of 
`key` and `val` before since some function transformations could result in 
size=2 vectors rather than true map entries.

I think that supporting `empty` on MapEntry is weird, as Alex said above. 
 It does sound the same as the record case. 

The only frustration I have with this change is that not all 
APersistentVectors really act as a map entry.  Only those of size=2 do.  So 
the interface becomes misleading if you try to use it to figure out from a 
generic standpoint, what things are map entries and what things aren't. 
 The ambiguity is that all vectors look like map entries.  I guess you 
could do the 
(instance? IMapEntry x) check along with (== 2 (count x)) for the vector 
case...

On Friday, October 16, 2015 at 6:39:50 AM UTC-5, Alex Miller wrote:
>
>
> On Friday, October 16, 2015 at 3:32:43 AM UTC-5, Pierre-Yves Ritschard 
> wrote:
>>
>> Hi Mike, 
>>
>> The code at here seems to contradict you: 
>>
>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/APersistentVector.java#L448-L460,
>>  
>>
>> as does "(key [:a :b])" in the REPL. 
>>
>> The only limitation is that vectors need to be of size two to act as 
>> IMapEntries (otherwise an IllegalOperation exception is thrown). 
>>
>> The change seems logical and allows key & val to be used more 
>> generically. 
>>
>> You're right that will fail on code that checks for (instance? 
>> IMapEntry). 
>>
>
> APersistentVector implements IMapEntry, so this doesn't seem correct.
>  
>
>> A good alternative - paging Alex Miller - could be for (empty) on a 
>> MapEntry to return an empty PersistentVector instead of nil, which would 
>> ensure that calls to (into (empty ) (map f )) 
>> would return a valid map entry (instead of a collection). 
>>
>
> It does not make sense to me for empty on a MapEntry to do what you ask 
> (for similar reasons why empty on a record is not allowed).
>  
>
>> I'm happy to create a ticket for this use-case if deemed valid. 
>>
>> Cheers, 
>>   - pyr 
>>
>>
>>
>> On 10/16/2015 01:28 AM, Mike Rodriguez wrote: 
>> > Someone else looked at the issue on 
>> https://github.com/ztellman/riddley/issues/18 
>> > 
>> > This issue makes the current version of riddley, and therefore 
>> potemkin, not work on Clojure 1.8 beta1 
>> > 
>> > There is a pull request to fix it at 
>> https://github.com/ztellman/riddley/pull/19 
>> > 
>> > However I am wondering if it is going to affect more places. The 
>> problem is that in Clojuee 1.8 APersistentVector now implements IMapEntry 
>> (therefore j.u.Map$Entry as well), but it doesn't implement the key or val 
>> methods. 
>> > What is the reason for that change and/or is this a desired side effect 
>> of the change? 
>> > 
>>
>

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

[Mike Rodriguez]

Someone else looked at the issue on 
https://github.com/ztellman/riddley/issues/18

This issue makes the current version of riddley, and therefore potemkin, not 
work on Clojure 1.8 beta1

There is a pull request to fix it at https://github.com/ztellman/riddley/pull/19

However I am wondering if it is going to affect more places. The problem is 
that in Clojuee 1.8 APersistentVector now implements IMapEntry (therefore 
j.u.Map$Entry as well), but it doesn't implement the key or val methods. 
What is the reason for that change and/or is this a desired side effect of the 
change?

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

[Mike Rodriguez]

Just a heads up, I tried upliftign to Clojure 1.8.0-beta1 today and had a 
failure that is originating from potemkin "0.4.1".  I think the issue may 
be in its dependent project riddley "0.1.10".
I logged an issue there at https://github.com/ztellman/riddley/issues/18.

I haven't tracked down the cause of this problem right now.  I figure this 
may affect more people though, since I often read of people using potemkin 
in their projects.  These issues didn't seem to exists when I ran against 
some older potemkin versions (e.g. "0.3.2" was my test case).

On Tuesday, October 13, 2015 at 9:01:06 AM UTC-5, Alex Miller wrote:
>
> Clojure 1.8.0-beta1 is now available.
>
> Try it via
>
>- Download: 
>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-beta1
>- Leiningen: [org.clojure/clojure "1.8.0-beta1"]
>
> Below is a list of the other changes included in beta1. See the full 
> change log here: https://github.com/clojure/clojure/blob/master/changes.md
> .
>
>
>- CLJ-1456  Compiler now 
>errors if too few or too many arguments to throw
>- CLJ-1282  quote now 
>throws if passed more or less than one arg
>- CLJ-1210  Improved 
>error message for (clojure.java.io/reader nil)
>- CLJ-1414  sort and 
>sort-by now indicate sort is stable in docstring
>- CLJ-1765  areduce 
>performance improvements
>- CLJ-1724  Remove 
>unnecessary call to seq() in LazySeq.hashCode()
>- CLJ-1295  Improved 
>array-map dissoc performance
>- CLJ-1277  Speed up 
>printing of time instants with type hints
>- CLJ-1259  Speed up 
>pprint and cl-format with type hints
>- CLJ-668  Improve slurp 
>performance by using StringWriter and jio/copy
>- CLJ-1810  ATransientMap 
>now marked public
>- CLJ-1653  str of an 
>empty list should be "()"
>- CLJ-1567  Removed 
>unused local in condp implementation
>- CLJ-1351  Unused 
>swapThunk method was being emitted for fns with keyword callsites
>- CLJ-1329  Removed 
>unused local in PersistentVector.cons()
>- CLJ-1380  3-arg 
>ExceptionInfo constructor permitted nil data
>- CLJ-1226  set! of a 
>deftype field using field-access syntax caused ClassCastException
>
>

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

[Mike Rodriguez]

Thanks for the info! I should have searched for that on Jira first. I actually 
wasn't sure if doc changes typically warrant a Jira , but it looks like it 
ended up being more than a doc fix! 

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

[Mike Rodriguez]

The doc string for clojure.core/run! is:
  "Runs the supplied procedure (via reduce), for purposes of side
  effects, on successive items in the collection. Returns nil"

However, it does not necessarily return nil.

e.g.

(run! #(do (println %) %) [1 2])
1
2
;= 2

It just returns whatever the given function returns on the last element of 
coll.  I just found the fact that the doc string explicitly says it returns 
nil to be a little misleading.

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

[Mike Rodriguez]

I think Artur described it well. I don't think the docs are wrong. The thing is 
just understanding that the reader macro syntax is interpreted by the reader. 
The reader comes before the evaluation of the compiler (there is grey area here 
with read-eval but that's another topic). 

Since a symbol is auto-resolved by the compiler during eval you have to quote 
them if you want to prevent that. Due to that it makes using a reader macro 
with a symbol awkward, but it makes sense if you think about it. The reader 
macro must apply to the symbol literal form itself. Then you surround the 
returned symbol with quote to prevent the compiler from resolving through it 
post-reading. Putting the metadata outside the quote is just attaching it to a 
list for, from the readers perspective. It doesn't know it is a quote etc. 

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

[Mike Rodriguez]

This has came up numerous times in other posts here. I can't hunt them down 
currently but the quoted symbol issue you showed is just a misunderstanding of 
how the reader macro for metadata works. 

Try (meta '^{:foo :bar} a)

When you put the reader macro in front of the quote it is applied to the quote 
form itself - as a data structure list - and then the metadata is not 
propagated to the return of the eval of the quote so it seems "lost". 

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

when the body of the request is HttpInputOverHTTP, how do I get the string representation?

[Mike Rodriguez]

Off subject. Just going to throw it out there that HttpInputOverHTTP looks like 
a CamelCase naming convention gone wrong. Id like to hear why it was named that 
way. :)

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

[Mike Rodriguez]

I agree. I think it is an excellent talk. I've see pretty much all of his talks 
and I think this is among the best. 

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

[Mike Rodriguez]

Good call on the auto-boxing.  I wasn't considering that before, but 
obviously it is important.

Nice insight into :inline.  I never really did understand the usefulness of 
it before.

On Tuesday, July 7, 2015 at 10:20:51 PM UTC-5, Herwig Hochleitner wrote:

 2015-07-07 15:04 GMT+02:00 Jo Geraerts j...@umask.net javascript::

 * multiply(long x)
 * multiply(double x)
 * multiply(Number x)

 In clojure i want to do something like

 (defn multiply[^MonetaryAmount amount multiplicant]
   (.multiply amount multiplicant))


 Function parameters in Clojure, are generally passed as a 
 java.lang.Object, so numbers are boxed by default.
 Clojure does have infrastructure to pass primitive numbers, see invokePrim 
 here: 
 https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java#L97
  
 see also http://clojure.org/java_interop#Java Interop-Support for Java 
 Primitives
 however, this requires a specific type hint on the multiply fn, so 
 normally that means separate multiply-double and multiply-long fns.

 The way I would do it: Define multiply as a function calling (.multiply 
 amount ^Number x), for higher order usage, and then add an :inline function 
 to its metadata, which returns `(.multiply ~amount ~x).
 That acts as a compiler macro, which inlines the call to .multiply, that 
 way, its parameter type can be assigned via local type inferrence (which 
 clojure does).
 See http://www.bytopia.org/2014/07/07/inline-functions-in-clojure/#sec-3
 Beware, that inline functions aren't public API and subject to change.

 kind regards


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

[Mike Rodriguez]

consional = conditional 

Typo sorry. 

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

[Mike Rodriguez]

You can do some consional instance? checks at runtime and type hint each method 
call appropriately. 

Java would determine the correct method based on the type information known to 
the compiler at compile time. 

You don't have that given in Clojure so you have to runtime check the type and 
then dispatch to the correctly hinted method signature. 

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

[Mike Rodriguez]

I don't think this is a let me google that for you question. Let vs let* in 
Clojure is not at all the same as the popular usages of these forms in popular 
lisp dialects like Common Lisp. 

I've thought it was confusing why let* existed in Clojure since let binding is 
only done in a sequential manner, but I think some answers given here are 
helpful. 

Just to point out Clojure dynamic var binding is done in a parallel/unordered 
way which resembles how Common Lisp let was done. However this is a completely 
different function and not a special form. Just for comparison with CL. 

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

[Mike Rodriguez]

Thanks for the insight Alex!

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

[Mike Rodriguez]

I agree the hashCode performance for records is a concern due to that lack of 
caching. 

I noticed the priority of that Jira 1224 changed to critical about a week ago 
(June 3). I was curious why that was done and what that means in terms of 
prioritization. 

Last minute squeeze into CLJ version 1.7 release?! :) 

Too hopefully I'm sure. 

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

[Mike Rodriguez]

I'll chime in with my opinion on this topic. 

I think the existing if-let and similar forms that have a limitation of only 
allowing a single binding is a confusing restriction to place on the familiar 
binding vector construct. I've always been a little uneasy about repurposing 
binding vectors for this restricted single-binding use case.  I'd probably have 
preferred something more like as-, where there is a direct form binding pair. 
However I guess that would ruin the ability to destructure. Just a thought, I 
can live with if-let and it's slightly awkward binding vector though. 

With that said, and as others have mentioned here, I can't imagine this 
proposed if-let-all macro having clear enough semantics to be something in 
Clojure core. There are just way too many caveats and ways to interpret it. I 
can see the motivation for it, but maybe there is a better design to achieve 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

[Mike Rodriguez]

Thanks Andy for the extra info and for logging the follow-up Jira! 
It looks like the exception changes are expected and are a potential 
improvement with line numbers etc. 
My the main goal was just to provide constructive feedback on here of the 
issues I faced investigating the upgrade of a fairly large code base  from 
Clojure 1.6 to 1.7. 

I appreciate all the feedback from everyone. 

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

[ANN] Clojure 1.7.0-RC1 now available

[Mike Rodriguez]

I can see in Git several areas where the compiler now catches exceptions thrown 
and re throws them wrapped in this exception type. I've been out of town and 
unable to make a small example yet. I will soon.

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

Seems like this could certainly be an issue with any interaction with Hadoop's 
infamous reduce-side iterable object reuse. I will have to test further where I 
may be affected similarly. 

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

[Mike Rodriguez]

This isn't necessarily a problem, but I figured I'd put it up in case anyone 
encounters similar or so that people can be aware of it coming. 

We had some tests fail when I switched to the recent 1.7 versions of Clojure 
(beta3 was last I checked, but it shouldn't have changed here). 

The Clojure compiler now seems to wrap many (most/all?) exceptions thrown with 
a Compiler$CompilerException. 

We had some tests around macros that checked for certain exceptions being 
thrown - like ExceptionInfo or IllegalStateException etc. these were exceptions 
we explicitly through in macro error handling for compile-time error feedback 
with context. 
We used the typically clojure.test is-thrown? Style which makes an instanceof 
assertion. 

Arguably our tests were wrong to expect our macroexpansion exception types to 
be propagated all the way up to the caller without being wrapped first. However 
this was slightly surprising. 

To be better prepared for future changes like this, it looks like we should 
assert no more specific than a RuntimeException (or possibly Exception, but I 
doubt Clojure would switch to checked exceptions). 

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

[Mike Rodriguez]

+1 to Eastwood. It is great. 

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

[Mike Rodriguez]

What you wanted here was 

 (meta '^:abc some-symbol)

It's a little weird but the reader attaches the metadata to the symbol. Then 
the quote just evaluates directly to the same symbol, so the metadata is 
preserved. 

I agree that metadata can be confusing though. Especially around where AND HOW 
you put the metadata for a functions return value(s).   
 
See [1] for more on that confusing track...

Also there are plenty of subtle gotchas to macros etc that do not preserve 
metadata. 'clojure.core/or' is a good example of that. 

A search for Clojure preserve metadata will likely turn up a good list of 
Jiras out there to fix areas that do not preserve metadata as expected. 

Looks like there are some tips at [2]. 

[1] http://dev.clojure.org/jira/browse/CLJ-1232
[2] 
http://stackoverflow.com/questions/4673011/what-functions-in-clojure-core-preserve-meta

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

[Mike Rodriguez]

In reference to [1]:

I do feel like the metadata loss on many macros is undesirable though and I 
wish it were addressed. It certainly  feels unhygienic, just in a new sense 
of the term. 

[1] https://github.com/jonase/eastwood#unused-meta-on-macro

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

[Mike Rodriguez]

Not really related. But I just want to chime in to say I love this quote from 
Fluid in regards to the DSL bit:

Under the hood is a delicate way of saying not homoiconic, whereby 90% of 
the benefit goes away. 

+1 to that! 

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

[Mike Rodriguez]

I have found long docs like that to be useful in some major top-level function 
if it has a large sort of input and configuration parameters to pass in. 

Markdown I believe means with back ticks around the symbol to make it stand out 
as an actual art name vs some other word in the sentence. I have seen this be a 
popular doc style in lisps that I've looked at. When case insensitive I've seen 
all caps used, which would not work in Clojures case. I've like the back tick 
markdown style since it doesn't get as easily confused with something like 
quote. 

I've also tended to use markdown ticks around code expressions of they were 
used in the doc string. I'm not sure I've seen a lot of that in the wild 
though. 

Doing that on every(most) function I'd be worried would be a maintenance issue.

I've wrote doc string style where the arguments are enumerated in an obvious 
argument name - description way. It definitely makes it unambiguous. I still 
tend to reserve that for larger, more complex functions. While in simpler 
functions just ensuring all args referenced directly and markdown ticked and 
are described in a natural type of sentence/paragraph. 

The idea of consistently naming arguments/types of arguments a certain way is 
obviously nice too  

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

[Mike Rodriguez]

I agree about wanting to use the explicit argument name surrounded by markdown 
quotes in docs. I've definitely started adopting this practice and wish there 
were conventions around this sort of thing. Without it, doc strings can easily 
get ambiguous and confusing in how they relate the the actual arguments of the 
function (in function docs that is). 

I also try to make it a point to mention each argument of he function in the 
doc string... 

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

[Mike Rodriguez]

 This is exactly one of the reasons a bunch of folk ( aka, purests maybe ) 
 don't like that map/filter etc. in Clojure convert the input collection 
 into seqs, unlike Haskell or others where the those monad laws keep you in 
 check that map/filter return the *same* container - so mapping a set 
 would yield another set - also with no guaranteed order, and also with 
 uniqueness applied - so technically a map over a set may yield a collection 
 of an equal or smaller size, but never greater.

 This seems to fuel a lot of debate when entered into - so I guess I'm 
 asking for trouble in replies here :)

 Mark


I suppose Clojure 1.7 transducers can address this thought in a way.  

e.g. (into #{} (map some-fn) some-set)

Doesn't expose any intermediate seq state of the collection.

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

[Mike Rodriguez]

Thanks for sharing this.  I found the write-up to be very informative and 
to have good background sources.  

I certainly never thought about this sneaky behavior concerning `seq` and 
hash sets before now.  I'll have to look out for that one!

On Tuesday, April 21, 2015 at 8:13:48 PM UTC-5, Andy Fingerhut wrote:

 I had come across the issue of Clojure hash sets that contain the same set 
 of elements returning their elements in different orders from each other, 
 depending upon which order they were added to the set (only if they have 
 equal values for (hash x)).

 This and other questions on referential transparency on the Clojure group 
 got me thinking on my commutes about it some more, and I dug into it way 
 more than I expected to, and wrote up an article on it.  If you think such 
 a topic would interest you, you can read more about it here:

 
 https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/referential-transparency.md

 Guaranteed at least 99% epiphany free

 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: Who's using Clojure?

[Mike Rodriguez]

We've been using Clojure at Cerner in the healthcare IT space. 

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

Switched map for record and got slower

[Mike Rodriguez]

Another thing to note is if you were using these maps as keys to a hash-based 
associative structure, like a hash map, then you be aware that Clojure record 
do not cache their hash code like other Clojure persistent map impls do. 

I've had this eat up performance time in some scenarios before. This is logged 
to be fixed in a future release (2.8 currently) under the Jira CLJ-1224. 

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

[Mike Rodriguez]

Sorry. That was a typo. I meant 1.8.
I'm just referring to the version tagged on the Jira. 

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

[Mike Rodriguez]

I'm not 100% sure and haven't really looked deeply at this comment or link 
you mention, but perhaps this is related to 
http://dev.clojure.org/jira/browse/CLJ-979.

This would only be the case for Clojure-dynamically generated Java classes 
though, which is those from deftype or the macros built on it like 
defrecord etc.


On Saturday, December 13, 2014 10:19:15 AM UTC-6, Matching Socks wrote:

 Multimethod dispatch based on Java classes is simply not reliable.

 That sentence comes from a comment in a git commit related to an AOT fix 
 mentioned in a recent core.match announcement.  
 
 https://github.com/clojure/core.match/commit/0545c6af9d545dcf1bc0a3ca792771b9a678a030
 
 (The workaround was to use keywords for multimethod dispatch.)  

 I looked on http://clojure.org/multimethods and 
 http://clojure.org/compilation but did not find a warning regarding the 
 combination of those two.

 In a nutshell, how does a conflict arise between AOT and multimethods?  


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

[Mike Rodriguez]

To the point (b) it seems that this posts is saying the clj's = will not be 
faster for keyword than string since the runtime type checking overhead is 
where most time is spent. So the identity part of keyword equals doesn't show 
its benefit here (unless these were long strings vs long keywords I suspect, 
but this is uncommon). 

The hash code calculation stuff would add performance value though. 

I'm just saying I don't see how point (b) is adding performance gains in the 
context of what else I've read here. 

If the compiler (doesn't seem always possible) or map impl's or something is 
smart enough to not use clj's basic = impl on keywords though and use its 
equals directly instead, that'd sound like a win. 

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

[Mike Rodriguez]

To the point (b) it seems that this posts is saying the clj's = will not be 
faster for keyword than string since the runtime type checking overhead is 
where most time is spent. So the identity part of keyword equals doesn't show 
its benefit here (unless these were long strings vs long keywords I suspect, 
but this is uncommon). 

The hash code calculation stuff would add performance value though. 

I'm just saying I don't see how point (b) is adding performance gains in the 
context of what else I've read here. 

If the compiler (doesn't seem always possible) or map impl's or something is 
smart enough to not use clj's basic = impl on keywords though and use its 
equals directly instead, that'd sound like a win. 

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

[Mike Rodriguez]

To the point (b) it seems that this posts is saying the clj's = will not be 
faster for keyword than string since the runtime type checking overhead is 
where most time is spent. So the identity part of keyword equals doesn't show 
its benefit here (unless these were long strings vs long keywords I suspect, 
but this is uncommon). 

The hash code calculation stuff would add performance value though. 

I'm just saying I don't see how point (b) is adding performance gains in the 
context of what else I've read here. 

If the compiler (doesn't seem always possible) or map impl's or something is 
smart enough to not use clj's basic = impl on keywords though and use its 
equals directly instead, that'd sound like a win. 

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

[Mike Rodriguez]

Thanks for taking the time for the (detailed) clarification. I understand  what 
you were saying now. 
:)

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

Rich Hickey's Transducers talk from Strange Loop

[Mike Rodriguez]

Thanks for putting it up so fast!

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