Re: Any way to replace function body?

[Mars0i]

To make the point explicit, bar now contains the original foo function:
(bar) ;=> 42

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

[Mars0i]

Functions are values.  Why not just this:

(defn foo [] 42)
(def bar foo)
(defn foo [] (inc (bar)))
(foo) ;=> 43

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

[Mars0i]

On Wednesday, December 12, 2018 at 6:42:47 AM UTC-6, Alex Miller wrote:
>
> Thanks for the feedback! I assume the spec one was a bad import statement?
>

Yes, exactly. 

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

[Mars0i]

I have a couple of small apps that use interop pretty heavily because the 
Java library I'm using is very inheritance-based.  There are no  problems 
running with RC5 (although spec did find a syntax error that had passed in 
1.9).  I don't use reflection explicitly, but turning on 
*warn-on-reflection* generates a bunch of warnings in one of the apps, so I 
guess it's using reflection to figure out types at runtime.

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

[Mars0i]

> I think part of it is that examples are easy to edit, so if there are small 
> easily fixed mistakes, often someone will.

Ah, I didn't realize that anyone can edit others' examples.

The two cases in which I've seen complaints about bad community 
help/examples/etc. concerned very popular languages.  My speculation is that 
beyond a certain level of popularity, the absolute number of foolish people can 
hurt a site if they foolishly post and their posts aren't cleaned up.  Maybe 
Clojure fans are all good thoughtful, careful people who never make foolish 
mistakes simply because there aren't enough of us.

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

ClojureDocs example management?

[Mars0i]

Who polices ClojureDocs?  If someone adds a silly or simply incorrect 
example, does someone eventually remove it?  Are there ever spam-like 
"examples"?  Or are Clojure fans all good, thoughtful, careful people who 
never make foolish mistakes?

I'm curious because I see no sign that anyone polices ClojureDocs, and it 
nevertheless seems like a uniformly useful resource.  The only flaws I've 
experienced came when I thought something was missing--and then it was easy 
enough to add an example or crossreference link myself.

I'm asking because of a conversation in another language-centered community 
where a worry was expressed that a community-contributed examples website 
would end up full of junk--bad examples, etc.  Supposedly some sites end up 
that way.  What's our secret?

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

[Mars0i]

Slack is working for me today.  There are posts in the Clojure channel, for 
example, from just two hours ago.  Maybe the end of the world didn't 
occur?  On the other hand, the Specter channel says only "To see this 
channel's full history, upgrade to one of our paid plans."  I'm not sure I 
understand.  Is the idea that old posts are simply getting dropped to 
retain no more than 10K posts, and there have been 10K since the last 
Specter post?  I'm a little bit confused by the whole situation.  I was a 
latecomer to Slack, and still don't use it as much as some other folks.  
Did we start using Slack knowing that one day it would be cut off when 
there were too many posts?

(I haven't tried the new Discord group yet, and as I've said earlier, have 
no opinions about relative benefits of different post-IRC platforms.  I've 
also heard positive things about Gitter btw; it wasn't mentioned earlier in 
this thread.  I do think there might be benefit to using fewer rather than 
more of these options.)



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

[Mars0i]

I have no opinion, but fwiw the OCaml folks began experimenting with Discourse 
about a week ago: https://discuss.ocaml.org.

This isn't really an IRC/Slack style platform, afaics, but the discussions that 
led up to it included concern about Slack's message limit.  (These discussions 
can be found on the Google OCaml Aggregation list starting last summer.)

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

[Mars0i]

There is also this sort of solution:

(def xs (range 9))

(let [ [[a b c] mid3 [d e f]]  (partition 3 xs) ]
  [a b c mid3 d e f])
=>
(0 1 2 (3 4 5) 6 7 8)

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

[Mars0i]

tbc++, lvh, I'm not surprised that Specter doesn't help. That seems 
reasonable.  Although I have come up against Specter's limits, I've been 
surprised at what it can do, so as a non-expert I tend to err on the side 
of thinking that it might help if I don't know that it can't.

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

Faster diffing for large-ish nested data structures

[Mars0i]

This might be a job for which Specter is particularly useful.  You might have 
to dive pretty deep into it, but if you get stuck, the creator Nathan Marz is 
often very helpful.

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

Re: static fields in gen-class

[Mars0i]

You can just define a variable with def in the file containing gen-class.  
gen-class won't help with this; it's just regular Clojure functionality:

(def CLASSNAME "MyClass")

That variable will be specific to the generated class, and public at least 
in the sense that it can be accessed in Clojure from outside the 
namespace.  However, I'm not certain whether a Java class will be willing 
to access it by MyClass.CLASSNAME, if that's what you need.  You can try it 
and see whether it works.   I've used gen-class a but, I've never had to 
define a static field for use by Java classes.

You can certainly define static methods, so if it would work to simply let 
Java get the value of CLASSNAME using an accessor method, you can do that 
using :methods in gen-class.  I haven't done this, but the gen-class 
docstring gives a tip about how to do it.  you'll then have to define a 
function to implement the accessor outside of gen-class, named e.g. 
"-getCLASSNAME" for an accessor that Java will see as "getCLASSNAME".  (You 
probably know that already.)

On Sunday, April 16, 2017 at 1:43:17 AM UTC-5, lambda-knight wrote:
>
> Hi,
>
> I am re-writing a Java class in Clojure using gen-class which is 
> accessible from Java.
> The class has a static field.  Let's assume a Java class as follow:
>
> public class MyClass {
>public static final String CLASSNAME   = "MyClass";
>private String name;
>private int value;
>
> public MyClass() {}
>
> public String getName() {
>   return this.name;
>}
>public void setName(final String name) {
>  this.name = name;
>}
>public int getValue() {
>   return this.value;
>}
>public void setValue(final int value) {
>  this.value = value;
>}
> }
>
> Can I define a such field in Clojure ?
>
> Thanks,
>

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

Re: off-topic: stackof developer survey

[Mars0i]

On Friday, March 24, 2017 at 5:17:15 PM UTC-5, Gregg Reynolds wrote:
>
>
>
> On Mar 24, 2017 5:05 PM,  wrote:
>
>
>
> > This did get me thinking though. If the community *did* want to score 
> highly 
> > on some of these metrics, what would those be?
>
> I'll be happy so long as Clojure is the popular choice for doing the 
> things where it's advantages should matter: machine learning, AI, NLP, 
> concurrent programming. 
>
> It drives me crazy that Python is doing so well in all of the areas where 
> Clojure should be winning. There are such beautiful libraries for working 
> with vectors and matrices with Clojure, which should obviously help with 
> NLP, yet people use Python instead. Likewise, so much of machine learning 
> should be done as work in parallel, and Clojure makes that easy, yet Python 
> is preferred. Drives me crazy. 
>
>
> doesn't drive me mad, but it does puzzle ans annoy me.  puzzle: why is it? 
>  not sure, personally.
>
>
> These last few years I've been at a lot of NLP startups, and the choice of 
> Python makes me sad. 
>
>
I thought that Python had a big head start.  Is that incorrect?

OO is still dominant, overall, and FP requires a big transition.  If you're 
a Java programmer, which is a more natural choice? Python or Clojure?  
Sure, Clojure is more closely tied to the JVM, but you don't write JVM code.

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

[Mars0i]

On Thursday, March 23, 2017 at 7:49:40 PM UTC-5, Mars0i wrote:
>
> The highest-paid win suggests there's greater demand than supply, so 
> people who aren't comfortable with FP or lisp may be forced to code in 
> Clojure, or try to for the sake of a job without doing it right, and are 
> unhappy as a result.


There are better explanations in the #off-topic channel of the Clojurians 
group in slack. 

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

[Mars0i]

The highest-paid win suggests there's greater demand than supply, so people who 
aren't comfortable with FP or lisp may be forced to code in Clojure, or try to 
for the sake of a job without doing it right, and are unhappy as a result.

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

Can you extend a Java class, and add new fields and constructors to it?

[Mars0i]

gen-class lets you define multiple constructors: 
http://stackoverflow.com/questions/18780071/clojure-multiple-constructors-using-gen-class

You can't define multiple fields that can be directed accessed from Java, but 
you can define accessors for data you store in other ways.  gen-class gives you 
only a single variable that's specific to each instance of the class, but you 
can e.g. put a map in it, with atoms as values if you need mutability, and 
define the accessors to access those.

(If you have a lot of variables that you're handling that way, you may want to 
write a gen-class-generating macro.  That's what I did, but it's not general; 
it's tailored to my application.)

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

[Mars0i]

A few thoughts about Specter from someone new to it but who's already found 
it incredibly useful.  I'm happy to be corrected on any points that I've 
misunderstood.

Clojure functions follow something like the Unix "do one thing and do it 
well" ideal.  There are exceptions, but a lot of what's great about Clojure 
is how sensibly Clojure functions "do one thing well" in an integrated, 
flexible way.

Specter doesn't do one thing, and do it well.  It does a slew of things 
extremely well--using a bunch of "does one thing well" functions and macros.

Not everything that's great and useful does just one thing, well.  In Unix, 
you know, there's this command called 'bash'.  It does a slew of things.  
On my system, I have another command 'lein repl', that doesn't just do one 
thing, either.  Both of these allow one to do a slew of things using a 
bunch of "does one thing well" operators.

So ... I think it's correct to say that Specter is a language.  Not a fully 
general language, but a general-purpose language for Clojure data structure 
querying and manipulation.  It's a language in at least the sense that SQL 
is a language.  (Doesn't matter whether we call called it a DSL, a DGL 
("domain general"), a CSV, or what.)

I can't know why RH and the core team don't think Specter should be a part 
of core, but the fact that something is an entire language--something 
that's complex on its own and does more than a couple of things well, is a 
reason that someone might reasonably feel uncomfortable about adding it to 
clojure.core, or even about making it an official contrib library.  It's a 
reason that someone might feel that Specter isn't Clojure-ey--because most 
Clojure functions don't do a slew of things, and we love that about it.  I 
get it.

I'm not expressing an opinion about whether Specter should be in 
Clojure.core or contrib.  I'm trying to clarify why I think it's reasonable 
to feel it shoudn't (because it does a slew of things), and why I think 
it's reasonable to feel that it should (because of the slew of things that 
it does well and more easily and efficiently).

(As for people not liking Specter's syntax: I don't think it's unreasonable 
to simply "feel" that something's syntax isn't sufficiently Clojurey.  Call 
it "aesthetic judgement" if you want, but some things that are important 
for users can be difficult to spell out.  However, discomfort with syntax 
doesn't seem like a good reason not to consider incorporating something 
into the core or the contrib system. Syntax can be revised, if that's 
what's needed, without harm to the underlying system.  Someone who loves 
Specter's functionality but dislikes its syntax could even start their own 
project to give it a new "skin".  Of course syntactic revisions shouldn't 
make the system harder to use overall.)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: 1.9.0-alpha14 doesn't allow Java classes as return type in gen-class :method clause?

[Mars0i]

On Monday, March 6, 2017 at 10:33:43 AM UTC-6, Mars0i wrote:
>
> On Monday, March 6, 2017 at 9:32:37 AM UTC-6, Alex Miller wrote:
>>
>> Ok, this looks like it's related to the macro gen, so I don't see any 
>> issue to fix in the spec - valid inputs at the point are either strings or 
>> symbols - I think through eval you were ending up with a class instance.
>>
>
> OK, that makes sense.  The new version with the added quote works with 
> 1.8.0 as well as 1.9.0--no doubt that's what you'd expect.  I wouldn't have 
> to known for sure until I tried it.  Use of gen-class can seem like a black 
> art sometimes :-) but I'm glad it's available.
>

Of course the problem arose due to my decision to dabble, imperfectly, in 
the black art of macro-writing (which I usually can avoid).

btw when I first saw the 1.9.0 error dump I thought it was horrible--worse 
than a simple Java stacktrace.  It was pretty ugly because my macro had 
generated a very large expression.  Once I figured out what the spec output 
was saying, though, I realized how incredibly helpful it was.  Very nice.  
Thanks.

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

Re: 1.9.0-alpha14 doesn't allow Java classes as return type in gen-class :method clause?

[Mars0i]

On Monday, March 6, 2017 at 9:32:37 AM UTC-6, Alex Miller wrote:
>
> Ok, this looks like it's related to the macro gen, so I don't see any 
> issue to fix in the spec - valid inputs at the point are either strings or 
> symbols - I think through eval you were ending up with a class instance.
>

OK, that makes sense.  The new version with the added quote works with 
1.8.0 as well as 1.9.0--no doubt that's what you'd expect.  I wouldn't have 
to known for sure until I tried it.  Use of gen-class can seem like a black 
art sometimes :-) but I'm glad it's available.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: 1.9.0-alpha14 doesn't allow Java classes as return type in gen-class :method clause?

[Mars0i]

On Monday, March 6, 2017 at 1:16:38 AM UTC-6, Mars0i wrote:
>
>
> On Sunday, March 5, 2017 at 6:51:57 PM UTC-6, Alex Miller wrote:
>>
>> I would really appreciate seeing the ns declaration that caused the 
>> original error. I have not been able to exactly reproduce what you are 
>> describing. If you can't share it publicly, you can send it to me at 
>> alex@cognitect.com.
>>
>> Thanks,
>> Alex
>>
>
> Thanks--sure, I am willing to make public the ... bad things I am doing in 
> my code.  I have to explain that the ns declaration is very large; it's 
> generated by a macro that creates a lot of code.  I wrote it to ease 
> interop with a useful but not entirely Clojure-friendly Java library I'm 
> using.  This required violating some standard, useful coding guidelines.
>
> This file 
> <https://github.com/mars0i/pasta/blob/master/doc/notes/defsimconfigOutputMarch2017.clj>
>  
> contains pretty-printed output from macroexpand-1 (made with Clojure 
> 1.8.0--the offending macro call is in an aot-compiled file, so it would 
> have been harder to start the repl with 1.9.0).  There are actually two ns 
> declarations (a trick to avoid some cyclic references).  The code that 
> caused the errors begins at line 66 in the second ns.
>
> The macro call in my source is here 
> <https://github.com/mars0i/pasta/blob/7eaa6835f22f8eecb604e7aa47bfde9d96eac13e/src/clj/free_agent/SimConfig.clj>on
>  
> line 29, and the macro definition is at the bottom of this file 
> <https://github.com/mars0i/pasta/blob/7eaa6835f22f8eecb604e7aa47bfde9d96eac13e/src/clj/utils/defsimconfig.clj>.
>   
> Both of those links are to the code just before the commit in which I added 
> apostrophes to the instances of java.lang.Object (at line 210 of the macro 
> definition file).  This got rid of the errors, and the application seems to 
> run correctly.
>
> (If you look at the current version of the code, you'll see that I 
> recently changed the project name from free-agent to pasta; 'lein uberjar' 
> didn't like the hyphen.)
>
> If you need me to make a minimal example, I can probably do that.
>

I meant to mention, in case it turns out to be relevant, that the other odd 
thing about this code is that the second ns declaration generated by the 
macro is a second instance of the ns declaration at the top of the source 
file.  i.e. at the top of SimConfig.clj there's a hardcoded ns declaration 
(ns free-agent.SimConfig ...), and then the macro inserts a different ns 
declaration (ns free-agent.config-data), followed a few lines later by a 
different instance of (ns free-agent.SimConfig ...).  It's in the latter 
that the :gen-class clause which causes the error occurs.  The reason for 
the (ns X), (ns Y), (ns X) strategy is to avoid the potential cyclic 
dependency problem (forced on me by the MASON library I'm using).

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: 1.9.0-alpha14 doesn't allow Java classes as return type in gen-class :method clause?

[Mars0i]

On Sunday, March 5, 2017 at 6:51:57 PM UTC-6, Alex Miller wrote:
>
> I would really appreciate seeing the ns declaration that caused the 
> original error. I have not been able to exactly reproduce what you are 
> describing. If you can't share it publicly, you can send it to me at 
> alex@cognitect.com .
>
> Thanks,
> Alex
>

Thanks--sure, I am willing to make public the ... bad things I am doing in 
my code.  I have to explain that the ns declaration is very large; it's 
generated by a macro that creates a lot of code.  I wrote it to ease 
interop with a useful but not entirely Clojure-friendly Java library I'm 
using.  This required violating some standard, useful coding guidelines.

This file 
<https://github.com/mars0i/pasta/blob/master/doc/notes/defsimconfigOutputMarch2017.clj>
 
contains pretty-printed output from macroexpand-1 (made with Clojure 
1.8.0--the offending macro call is in an aot-compiled file, so it would 
have been harder to start the repl with 1.9.0).  There are actually two ns 
declarations (a trick to avoid some cyclic references).  The code that 
caused the errors begins at line 66 in the second ns.

The macro call in my source is here 
<https://github.com/mars0i/pasta/blob/7eaa6835f22f8eecb604e7aa47bfde9d96eac13e/src/clj/free_agent/SimConfig.clj>on
 
line 29, and the macro definition is at the bottom of this file 
<https://github.com/mars0i/pasta/blob/7eaa6835f22f8eecb604e7aa47bfde9d96eac13e/src/clj/utils/defsimconfig.clj>.
  
Both of those links are to the code just before the commit in which I added 
apostrophes to the instances of java.lang.Object (at line 210 of the macro 
definition file).  This got rid of the errors, and the application seems to 
run correctly.

(If you look at the current version of the code, you'll see that I recently 
changed the project name from free-agent to pasta; 'lein uberjar' didn't 
like the hyphen.)

If you need me to make a minimal example, I can probably do 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: lein jar, uberjar don't allow hyphens in paths?

[Mars0i]

On Saturday, March 4, 2017 at 8:19:44 PM UTC-6, Sean Corfield wrote:
>
> Java doesn’t allow – in names. That’s why Clojure and Clojure tooling maps 
> – in names to _ in files (and classes).
>

Right, and this normally causes no problems (with a little bit of care).  I 
experience no problems with the hyphen/underscroe mapping using 'lein run' 
or running from the repl.  It's only 'lein jar' or 'lein uberjar' that 
seems unable to manage the mapping properly when there's an underscore in a 
directory name, i.e. a hyphen in a non-terminal namespace path element.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: 1.9.0-alpha14 doesn't allow Java classes as return type in gen-class :method clause?

[Mars0i]

On Saturday, March 4, 2017 at 7:58:38 AM UTC-6, Mars0i wrote:
>
> On Saturday, March 4, 2017 at 7:24:05 AM UTC-6, Alex Miller wrote:
>>
>> This is definitely related to the gen-class spec, but I'm not at a 
>> computer to look at enough stuff to say if the bug is your code or the 
>> spec. 
>>
>> You might try quoting rhe class name in case it's getting resolved to a 
>> class instance? Might be crazy talk.
>>
>
> That produced pretty much the same error:
>
> In: [3 :methods 32 2] val: "java.lang.Object" fails spec: 
> :clojure.core.specs/method at: [:args :clauses :gen-class :options :methods 
> :return-type] predicate: simple-symbol?
>
>  
Oh--sorry.  You  probably meant the other kind of quoting, i.e. with 
apostrophe, the Clojure special form quote.  That fixed it.  Thanks very 
much.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: 1.9.0-alpha14 doesn't allow Java classes as return type in gen-class :method clause?

[Mars0i]

On Saturday, March 4, 2017 at 7:24:05 AM UTC-6, Alex Miller wrote:
>
> This is definitely related to the gen-class spec, but I'm not at a 
> computer to look at enough stuff to say if the bug is your code or the 
> spec. 
>
> You might try quoting rhe class name in case it's getting resolved to a 
> class instance? Might be crazy talk.
>

That produced pretty much the same error:

In: [3 :methods 32 2] val: "java.lang.Object" fails spec: 
:clojure.core.specs/method at: [:args :clauses :gen-class :options :methods 
:return-type] predicate: simple-symbol?

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

[Mars0i]

I've never used Specter, but my needs are modest compared to some Clojure 
programmers'.  (Great introductory blog post, Nathan, btw.)  Intuitively, 
it feels to me like Specter is too big of a monster to be in core.  I am 
not surprised that that's not going to be an option.  

The idea of making it a contrib library seems reasonable, though.  Perhaps 
this would involve some revision of the syntax.  Alex said that there's no 
advantage to making it a contrib library, but maybe there is a bit of an 
advantage.

Contrib libraries are easy to discover--they're listed in a prominent place 
at clojure.org--and they are easier to trust.  There are good non-contrib 
libraries, and always will be, but one has to investigate an external 
library to figure out how robust it is, what stage of development it's at, 
whether it's currently supported, whether it will be supported in the 
future, whether there are competing libraries that should be evaluated, 
etc.  I gather that Specter passes those tests well, but anyone new to it 
might not know that.  With an official release of a contrib library, even 
if it's 0.x version, being an official contrib library is a stamp of 
approval that gives one a reason to trust it, until proven otherwise.  
Further, although I don't think Specter belongs in core, it does feel like 
something that might be appropriate as a contrib library.  I can see how 
useful it could be, and what it does is no more complicated than some other 
contrib libraries.

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

lein jar, uberjar don't allow hyphens in paths?

[Mars0i]

It looks like 'lein uberjar' and 'lein jar' don't like namespace path 
elements that contain hyphens.

Example:

lein new app foo-bar
cd foo-bar

Now edit src/foo_bar/core.clj, changing

(ns foo-bar.core
  (:gen-class))

to

(ns foo-bar.core
  (:gen-class
:name foo-bar.core))

Then 'lein uberjar' reports:

Compiling foo-bar.core
Warning: The Main-Class specified does not exist within the jar. It may not 
be executable as expected. A gen-class directive may be missing in the 
namespace which contains the main method.

Also, 'java -jar target/uberjar/foo-bar-0.1.0-SNAPSHOT-standalone.jar' 
prints:

Error: Could not find or load main class foo_bar.core

A similar problem seems to occur with 'lein jar'.

However, no problem occurs with 'lein run', or with 'lein uberjar' if :name 
is left out of the ns form, or if :name is used but the project namespace 
qualifier does not contain a hyphen.

I think this has to do with the fact that when I use :name with foo-bar, 
core.class ends up in target/uberjar/classes/foo-bar, while its related 
inner class files end up in target/uberjar/classes/foo_bar.  If I don't use 
:name or if the path doesn't contain a dash, all of the classes end up in 
the same directory, e.g. foo_bar.  (I don't know much about jar files or 
subtleties of how the jvm interprets them.)

I have a standalone project that runs fine with 'lein run' but I'm unable 
to make an uberjar because of this problem.  (I apparently to need the 
:name element in order to create an instance of the same class in my -main 
function.)  The project is small enough that it won't be much trouble to 
rename filenames and namespace paths in order to get rid of dashes, but I'm 
wondering if there's a different solution.  

I'm also wondering whether this is a bug/flaw in Leiningen.  I can submit 
an issue if so.

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

1.9.0-alpha14 doesn't allow Java classes as return type in gen-class :method clause?

[Mars0i]

I have a working application that I've been developing using Clojure 1.8.0, 
and just tried it with 1.9.0-alpha14 on it.  This generated a bunch of 
errors that look something like this:

In: [3 :methods 32 2] val: java.lang.Object fails spec: 
:clojure.core.specs/method at: [:args :clauses :gen-class :options :methods 
:return-type] predicate: simple-symbol?

I think this particular error means that within element 3 of my ns 
statement, at element 2 of element 32 of the val of :methods, 
java.lang.Object doesn't satisfy simple-symbol? because it's not a "symbol 
without a namespace" (from the docstring).  Is that correct?  Element 32 is 
the first line of my :methods sequence that specifies a return value other 
than void or a primitive Clojure type:

[domNumKSnipes [] java.lang.Object]

That's exactly the signature that I need for the Java library that's going 
to use my Clojure namespace.  

Is this a bug in the new syntax checking for gen-class, or is there some 
other way that I should use use gen-class :methods to specify a 
non-primitive return type for a function that I want to expose to Java 
classes?  Thanks.

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

Re: Clojure community survey 2016 results

[Mars0i]

Thanks for the survey!

I think the size distribution for the academic and government/military 
categories might be due to different respondents deciding how to 
disambiguate the question in different ways.  For example, everyone who 
works for the U.S. government works in an organization of the same size, 
but some might view their organization instead as a government department 
or an entity within a department, or a research team within a larger 
entity, etc.  So you might say that you work in an organization of size 
1-10 even if you work for the U.S. government.  If this is correct, the 
distribution for these categories isn't meaningful except as information 
about what people think of as their "organization" when they are forced to 
decide.

By contrast, in business, respondents might make similar decisions, but I 
suspect that's it's most common to view the organization as a "company", 
whether that's merely the smallest company for which one works, or instead 
a parent company that owns a smaller company for which one works, etc.  My 
intuition is that most people won't say they work for an organization of 
size 1-10 unless the smallest company they work for has no more than 10 
employees.

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

[Mars0i]

On Monday, January 30, 2017 at 1:34:09 AM UTC-6, Sayth Renshaw wrote:
>
> Hi
>
> If nil is true 
>
> clojure-noob.core> (nil? nil)
> true
>

Similarly, 
user=> (false? false)
true

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

Re: [ANN] Ultra v0.5.1 - a Leiningen plugin for a superior development environment

[Mars0i]

Got it. Thanks David.

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

[Mars0i]

On Thursday, January 12, 2017 at 12:25:38 PM UTC-6, David Jarvis wrote:
>
> I'm not sure, though I have a hypothesis - is this an issue for all 
> sequences, or just for maps?
>

All sequences.  Well, not exactly--see below.  But I don't mind the one 
entry-per-line behavior for maps.  It bothers me for simple 
sequences--lists, vectors, etc.  

I just realized that the behavior depends on the :width setting and the 
size of the output.  For example if I enter (range 20), the entire sequence 
will be displayed on one line.  If I use range with an argument large 
enough to make the output longer than the :width setting, I get one element 
per line.  However, that's generally not what I want.  I'd rather see as 
many elements as possible, letting the terminal wrap the output (or maybe 
something a little nicer but similar, but terminal wrapping is good 
enough).  This actually led to me disabling ultra earlier today, so I 
wouldn't have to scroll up to peruse a sequence of 200 doubles.  I like its 
other features, though!

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

[Mars0i]

Hi David (or anyone else)-   Is there a way to make sequences print all on 
one line, as in the default repl behavior, rather than with one element per 
line?  I haven't found anything about this in the documentation or in the 
whidbey config map.   Thanks.

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

Re: [ANN] Ultra v0.5.1 - a Leiningen plugin for a superior development environment

[Mars0i]

David, thanks very much for the quick reply. (!)  OK, got it now.  

update-options! will be useful because sometimes I have a lot of state set 
up within the repl and then realize that I want to change the size of the 
terminal window to see more data at once (or to see more windows at once).

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

[Mars0i]

One more question--should have included it before.  Is there a way to 
change the print width apart from in profile.clj or project.clj, e.g. with 
a function in the repl.  That way I resize the terminal to see more on each 
line, I wouldn't have to exit out and change the width.  Thanks-

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

Re: [ANN] Ultra v0.5.1 - a Leiningen plugin for a superior development environment

[Mars0i]

Very nice.  Thank you.

One question because my ignorance about how to configure plugins in 
general--I hope you don't mind.  Where would I put this:

{:ultra {:repl {:width 180
:map-delimiter ""
:extend-notation true
:print-meta true
 ...}}}

(I didn't find the Whidbey README to be helpful, but maybe I missed some 
implication there.)


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

[Mars0i]

On Friday, December 30, 2016 at 7:59:46 PM UTC-6, puzzler wrote:
>
> On Fri, Dec 30, 2016 at 4:55 PM, Timothy Baldridge  > wrote:
>
> I wonder whether there could be something like an `external-declare` that 
> would satisfy Rich's concerns about knowing how to intern unencountered 
> vars, while allowing cyclical references when needed.
>

I was thinking that even if a compile option allowing cyclic dependencies 
is bad for pulling arbitrary code into the REPL, but you just would know 
the drawbacks if you used the option.  In my case I'm aot-compiling some of 
the primary namespaces anyway because of the Java lib's needs, so maybe 
that would be OK.

Maybe extern-declare would be better solution, though.

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

[Mars0i]

Aaron, thanks for the RH quote.  I had looked at parts of that Yegge 
discussion at one point, I think, but I don't recall reading this section 
of Rich's remarks.  I never succeeded in understanding Common Lisp packages 
well enough to use the successfully.  I tried and gave up.  Rich may be 
pointing the reasons why.  Clojure namespaces, by contrast, are trivial to 
use in most situations, once you learn a few easy conventions.

tbc++ and puzzler, thanks for those useful strategies.  I'll keep them in 
mind.  potemkin looks potentially very useful.  I didn't know about it (or 
maybe encountered it when I had no use for it and so didn't remember it 
when I did).  In my case, I've only had to struggle with cyclic 
dependencies when using Java library that (almost) forces them 
(http://cs.gmu.edu/~eclab/projects/mason).  It's a great library for its 
purpose, but it's not entirely Clojure-friendly.  Or Clojure's not entirely 
friendly to this kind of library--take your pick.  I think I may have 
avoided the obvious cycle problem with this library, if everything works as 
I expect, however.

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

[Mars0i]

Thanks Nathan!  (See what I mean about my ignorance?)

On Friday, December 30, 2016 at 3:53:27 PM UTC-6, Nathan Davis wrote:
>
>
> On Friday, December 30, 2016 at 10:13:49 AM UTC-6, Mars0i wrote:
>>
>> I love Clojure.  But:  My number one complaint about it is that the 
>> compiler won't allow cyclic namespace dependencies.  I am not a 
>> compiler-writer, but as far as I can tell the only reason for this 
>> restriction is ... philosophical.  It forces bad code organization, and it 
>> wastes time.  Those who think that cyclic code is an evil are free to 
>> encourage its avoidance.  I'm happy to avoid it!  But sometimes I can't.  I 
>> absolutely hate the cyclic namespace restriction.  Drives me crazy when I 
>> am forced to encounter it.
>>
>>
> First of all, there is no such restriction.  So there is no reason for it, 
> philosophical or otherwise.  
>

What I wrote was based on my understanding from past conversations in this 
group and things I'd read, and on a fair amount of experience hitting my 
head against walls in different ways.  I'm happy to be disabused of my 
misunderstandings, even if they weren't completely baseless.

It is true that if you declare all your dependencies in ns forms, you will 
> get an exception with cyclic namespaces.  That's a *good* thing -- the 
> result probably wouldn't be what you want anyway.  However, there's no 
> requirement that all dependencies be declared using ns -- you can use 
> require at any time.
>

Well that's interesting.  I'll have to explore that option.  Thanks.
 

>
> What *is* required is that all the vars a form uses exist when it is 
> compiled.  The reason for this is purely technical -- resolving symbols to 
> vars at compile time means less work (more efficiency) at run time.
>

There's more depth to that statement than I have at that this moment, I 
believe.  There's a lot that's resolved at run time in Clojure.
 

>  
>
>> My latest case is that I'm trying to debug a weird Java interop 
>> problem--something that works in one app I've written, in which I ended up 
>> putting most of the application into one file, but doesn't work in the one 
>> I'm working on now.   And I had finally come up with a clever way of 
>> avoiding sticking most of the code into one namespace.  I'd worked around 
>> the conflict between Clojure's requirements and the requirements of the 
>> Java library I'm using.  But now there's this one problem, and I want to 
>> try an experiment to see whether it fixes the problem.  It looks like I'm 
>> going to have to pack all of the code into one file and rewrite everything 
>> that that necessitates just for this purpose. Aghh.
>>
>
>>
> Perhaps if you provided a coherent description the specifics of your 
> problem, someone would be able to suggest a satisfactory solution.
>

I understand the point, and would have provided a description if I thought 
it was worth the trouble for me or for readers of this group for a one-off 
experiment, and I didn't think there was a good solution, obviously.  I 
wasn't looking for that kind of help this time.

Given what you've said, though, I'll think about asking a more specific 
question about a cyclic dependency when it comes up again.  In the past 
when I encountered similar problems, I didn't find help other than "It's 
bad in general to organize programs non-hierarchically", or "Yeah, my 
solution is to have one slop namespace where I throw all of the things that 
have to refer to each other."  :-)

 
>
>> I have sometimes ranted a bit in this group, and in the end some of my 
>> rants were unreasonable.  I don't think this is unreasonable.  The cyclic 
>> dependency restriction is absurd.  I'm not trying to start a flame ware.  I 
>> feel strongly about this, and I'm frustrated.
>>
>>
> What would be reasonable is asking questions about things until you 
> understand them well enough to be in a position to make an informed 
> opinion.  
>

I very much appreciate you clarifying some points that I thought I 
understood.  I did think I understood well enough to have the general 
opinion I expressed.  If you're suggesting that I didn't have a right to 
express an opinion given what I thought I understood, we can disagree, 
though what you wrote doesn't clearly imply that.
 

> In this case:
>
>
>1. Clojure does allow namespaces to refer to each other (just maybe 
>not how you've tried).
>2. There are plenty of technical considerations when it comes to 
>mixing dynamic languages and cyclic references.  Cyclic namespaces are a 
>subset of this problem.  So describing restrictions on cyclic namespaces 
>(whether real or imagined) as "absurd" is absurd.

Cyclic namespace dependencies!

[Mars0i]

I love Clojure.  But:  My number one complaint about it is that the 
compiler won't allow cyclic namespace dependencies.  I am not a 
compiler-writer, but as far as I can tell the only reason for this 
restriction is ... philosophical.  It forces bad code organization, and it 
wastes time.  Those who think that cyclic code is an evil are free to 
encourage its avoidance.  I'm happy to avoid it!  But sometimes I can't.  I 
absolutely hate the cyclic namespace restriction.  Drives me crazy when I 
am forced to encounter it.

My latest case is that I'm trying to debug a weird Java interop 
problem--something that works in one app I've written, in which I ended up 
putting most of the application into one file, but doesn't work in the one 
I'm working on now.   And I had finally come up with a clever way of 
avoiding sticking most of the code into one namespace.  I'd worked around 
the conflict between Clojure's requirements and the requirements of the 
Java library I'm using.  But now there's this one problem, and I want to 
try an experiment to see whether it fixes the problem.  It looks like I'm 
going to have to pack all of the code into one file and rewrite everything 
that that necessitates just for this purpose. Aghh.

In another post a while ago, I also noted that whether there's a cyclic 
dependency sometimes depends on seemingly arbitrary changes to code--e.g. 
add a type hint to avoid reflection, and all of a sudden you've got cyclic 
code that you didn't have before.  This isn't the current case--I haven't 
even gotten to that stage.

I have sometimes ranted a bit in this group, and in the end some of my 
rants were unreasonable.  I don't think this is unreasonable.  The cyclic 
dependency restriction is absurd.  I'm not trying to start a flame ware.  I 
feel strongly about this, and I'm frustrated.

What I want: I'm not trying to make everyone sit around tapping their 
fingers while code to goes through multi-pass compliations.  All I'm asking 
for is a compiler option that will allow cyclic dependencies when requested.

I'm pretty sure that the way I've put things above illustrates some 
ignorance on my part, but still ... how hard can this be?  It's a 
reasonable thing to ask of a sophisticated compiler.

Finally, is there a JIRA ticket for this issue?  I looked but didn't find 
it.  I will add a ticket if not, even if it's not likely to be acted upon 
any time soon.

Again: I sincerely love Clojure!
But.

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

Re: Errors

[Mars0i]

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

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

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

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

Re: any? in clojure 1.9.0 alpha

[Mars0i]

> Personally I think "any?" and "some?" are aptly named, and that it's the 
> older "not-any?" and "some" functions that mess things up.
>

I can understand the intuition that "not-any?" and "some" are the oddballs, 
but "Are there any Xs?" and "Are there some Xs?" are true in exactly the 
same situations.  Or to remove the predicate, since that's what "some" and 
"not-any?" use: "Is there anything in this thing?" and "Is there something 
in this thing?" are true in the same situations.  So if some? is aptly 
named, then any? is not.  (Maybe "anything?" or "something?" would have 
been better names for some?.)
 

> Maybe if Clojure were being designed from scratch again, we'd have 
> something like "has" and "not-has?", but it's too late to change common 
> function names now.
>

Yeah--too late.

As well as some still uncommon ones.
Like "any?".
:-)

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

[Mars0i]

On Monday, November 7, 2016 at 12:16:28 AM UTC-6, Mars0i wrote:
>
> "any?" wasn't the only option.  I would have gone with something obvious 
> like "always-true", or "yes", or even something possibly too-clever like 
> "arg-or-not-arg?" or "or-not-this?" 
>
 
Or maybe:
"argument?"
"value?"
"is-something?"
"is-a-clojure-value?"
"surrounding-expression-compiled?" (Since if the expression is not true, 
that's because it didn't compile.)

Or, obliquely inspired by Descartes 
<https://en.wikipedia.org/wiki/Cogito_ergo_sum>: 
"i-am?"

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

[Mars0i]

On Sunday, November 6, 2016 at 9:54:19 PM UTC-6, Alan Thompson wrote:
>
> There was quite a discussion of this topic back in July if you'd like to 
> review it:   https://goo.gl/Azy8Nf
>
> The semantic mismatch is unfortunate.
> Alan
>

 It's not just a mismatch with not-any?, though.  "any?" makes no sense as 
a name for a function that returns true no matter what is passed to it.  
That's not what "any" means in English.  

Alex Miller ended the discussion by stating that it was not up for debate.  
(So the rest of this post will affect nothing, and there are good reasons 
to stop reading.)

My respect for Alex (and Rich) is very, very great, but I think this 
choice, and the decision to shut down discussion of it when spec is still 
alpha is, yeah, unfortunate.  Not that it matters now.  But alpha was the 
time to discuss it.

Similar to points I've made before:  There are lots of things I like about 
Clojure, and lots of reasons that I am happier using Clojure than Common 
Lisp.  Here's one: Common Lisp sometimes uses a confusing hodgepodge of 
function names, sometimes with differently named functions that do similar 
things, with different argument orders and different semantics in other 
respects.  I assume that this is because CL was defined by a committee, and 
in particular a committee that wanted to merge independently-developed 
dialects of Lisp.  Clojure, by contrast, was not designed by committee, and 
was designed from the start to have an elegant system of functions and 
function names.  Not perfect in this respect, but still beautiful.  It 
makes Clojure easier to learn, easier to understand, and makes it easier to 
remember function names and semantics.  So it bugs me when Clojure takes a 
step toward arbitrary quirkiness.  

"any?" wasn't the only option.  I would have gone with something obvious 
like "always-true", or "yes", or even something possibly too-clever like 
"arg-or-not-arg?" or "or-not-this?"  These last might be confusing, but not 
misleading, as "any?" is.

(But none of that matters.)

(There is an upside to quirkiness, however.  if you program in CL for a 
bit, you get to experience the pride of your esoteric knowledge of the ins 
and outs of CL's functions.)

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

Re: comp and partial vs ->>

[Mars0i]

On Thursday, October 27, 2016 at 11:39:27 AM UTC-5, Alan Thompson wrote:
>
> I almost never use either the `comp` or the `partial` functions.  I think 
> it is clearer to either compose the functions like Gary showed, or to use a 
> threading macro (my favorite is the `it->` macro from the Tupelo library 
> ).
> Alan
>

I may be weird, but I almost never use the threading macros, and routinely 
use comp and partial, often with map. I often order function parameters in 
my definitions to facilitate the use of partial.  I don't mind reading 
functions "backwards" in a long chain of function calls, even though I 
sometimes use threading macros. I think this is just a matter of taste and 
past experience.

I agree that it can be clearer sometimes to arrange function calls 
"forward" in the order in which they're called.  Obviously, a (small) 
disadvantage of e.g. -> and ->> macros is that they depend on having a 
series of function calls in which it's the same argument (1st, or last) 
that has to be passed on (although you can wrap the calls in e.g. #() to 
fudge that).  I think that for a new user it's probably a little bit 
confusing with -> to have a series of function calls in which there's a 
hidden argument right after the function name.  With normal function 
composition, all arguments are explicit, and you can pass the result of any 
function call as any argument.  I don't think anyone would disagree with 
these points.  Taste and past experience.

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

[Mars0i]

On Monday, October 17, 2016 at 3:37:51 PM UTC-5, Jean Niklas L'orange wrote:
>
> Hi Marshall,
>
> On 17 October 2016 at 07:54, Mars0i <mars...@logical.net > 
> wrote:
>
>> Looks very nice! Thanks Jean Niklas.  I've been using Incanter for 
>> charts, which has been fine so far for my needs, but clj-xchart looks like 
>> it will make it easier to make nicer charts, and it would avoid loading 
>> much of Incanter when you don't need some of the other things Incanter 
>> provides.  (I also use nvd3 to generate charts in a browser with 
>> Clojurescript.)
>>
>
> Thanks! This was also parts of the rationale for clj-xchart as well: 
> Incanter is great, but it feels a bit strange to drag in both json and csv 
> dependencies if you only need to plot some charts.
>  
>
>> But if I'm plotting several sequences of y values that are embedded in a 
>> sequence of maps or vectors, each with several y values for the same x, I 
>> wonder if it could be more to efficient pass the entire complex sequence to 
>> the plotting function at once, and only provide one set of x values if all 
>> of the y values will share the same x's.  If the plotting function extracts 
>> the y values as it reads through the sequence of maps/vectors, and needs 
>> only one sequence of x's, then only two sequences are realized.
>>
>> Maybe this is an unusual need, at present, but as Clojure is used for 
>> more scientific applications, it might become more common.
>>
>
> XChart (and consequently clj-xchart) can take the same x-axis as input. So 
> you can reuse the same x values instead of creating 3 distinct but 
> identical ones:
>
> (let [x [1 2 3]
>   y1 [1 2 3]
>   y2 [2 4 6]
>   y3 [3 6 9]]
>   (c/xy-chart {"y1" {:x x :y y1}
>"y2" {:x x :y y2}
>"y3" {:x x :y y3}}))
>
> I don't think this is unique to clj-xchart though, the same should apply 
> to Incanter/JFreeChart.
>

Right.  I don't know why I didn't think of that.  Good idea.

Unfortunately, clj-xchart will indirectly realise almost all lists it is 
> given, as it calls .size() on them to ensure that the X/Y/error lists are 
> identical in size. It will also walk the lists to find the size/scale of 
> the chart to plot. I'm not sure if there's a way around that, except 
> perhaps if one pin the boundaries of the plot axes.
>
> That being said, it doesn't seem like a bad idea to provide some sort of 
> efficient view over data to avoid creating a new list that will be realised 
> with the exact same data in another list. I made an issue 
> <https://github.com/hyPiRion/clj-xchart/issues/5> on this, it shouldn't 
> be too hard to implement either.
>

Great. 

> For what it's worth, I've had the same "issue" with large datasets as well 
> (10-20M elements). In my case there isn't that much interesting to look at 
> except the occational outlier, or if you have values which differ extremely 
> from one datapoint to another.
>
> What I tend to do is rebin/shrink the data set, typically by computing the 
> average/max value of partitions (after filtering away outliers), depending 
> on what I need to plot. I have a small section in the "Gotchas" section 
> named Many Datapoints 
> <https://github.com/hyPiRion/clj-xchart/blob/master/docs/tutorial.md#many-datapoints>
>  (bottom 
> of the page) which has a couple of lines on how one can do that. I haven't 
> found a good generic interface for it yet, so it's not provided by 
> clj-xchart as of now.
>

Yes, good idea for some situations.  For my present project, it's OK to 
simply use every 10th or 100th point, even when the data is wildly random, 
but sometimes I want to see them all.   Other data elements are roughly 
continuous, so it's no problem to sample every nth point.

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

[Mars0i]

Looks very nice! Thanks Jean Niklas.  I've been using Incanter for charts, 
which has been fine so far for my needs, but clj-xchart looks like it will 
make it easier to make nicer charts, and it would avoid loading much of 
Incanter when you don't need some of the other things Incanter provides.  
(I also use nvd3 to generate charts in a browser with Clojurescript.)

Since you've developed a charting library, maybe I'll mention a feature 
that I have wanted (I think!): 

I've been making plots with a large number of points--100K, sometimes even 
1M or 2M per data sequence.  Sometimes I will sample a larger sequence 
every 10 or 100 steps to reduce the burden on the Incanter or nvd3 plotting 
function, but sometimes I want to see what the data looks like with all of 
the points.

I generate the data in a lazy sequence, using iterate, where, let's say, 
each element of the sequence is a map containing several pieces  of y 
values for the x value corresponding to that element of the sequence, e.g.

data = ({:a y-a-1, :b y-b-1, :c y-c-1}, {:a y-a-2, :b y-b-2, :c y-c-2}, ...)

In order to plot all three sequences of y values in Incanter or nvd3 (and 
clj-xchart?), I have to extract a new sequence of values for each data 
series, e.g. like this:

(map :a data)
(map :b data)
(map :c data)

and I have to generate several sequences of x values by calling (range) 
repeatedly.  I pass these six lazy sequences to the chart function, but at 
least in Incanter and nvd3, I don't believe Incanter does anything until it 
realizes all of the sequences.  That means that it realizes six distinct 
sequences, I think, and my initial sequence of maps will have been realized 
as well.  

But if I'm plotting several sequences of y values that are embedded in a 
sequence of maps or vectors, each with several y values for the same x, I 
wonder if it could be more to efficient pass the entire complex sequence to 
the plotting function at once, and only provide one set of x values if all 
of the y values will share the same x's.  If the plotting function extracts 
the y values as it reads through the sequence of maps/vectors, and needs 
only one sequence of x's, then only two sequences are realized.

Maybe this is an unusual need, at present, but as Clojure is used for more 
scientific applications, it might become more common.


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

[Mars0i]

Others have meatier, more detailed answers.  Here's one more factor that 
might matter: 

Clojure makes me happy.  I'm happier programming in Clojure than in other 
languages that are also very suitable for my projects.  I enjoy myself 
more, and it's easier.  I even prefer to use Clojure when I could probably 
do a project more quickly using something else.  It's not the only language 
that can make me feel that way, but it's the best one for me right now.  
You may not feel the same way after you get comfortable with Clojure--but 
you might.

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

[Mars0i]

Thanks Christophe.  Very nice.  I may use partition, or something else as 
the need arises.

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

No transducer variant of partition?

[Mars0i]

partition-all has a transducer variant, but partition doesn't.  Just 
curious why.

The difference between the non-transducer functionalities is that, for 
example, (partition-all n coll) will return shorter-than-n stub sequences 
at the end of the main output sequence if the (count coll) isn't divisible 
by n, while partition will simply stop ignore leave the short sequences out 
of the main sequence (unless you use the four-argument syntax, in which an 
extra argument is used to construct extra sequences at the end of the main 
sequence as needed to use up the input sequence).

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

[Mars0i]

Thanks everyone.  There's a lot here--I'm still digesting it all.  It's 
clear that a lot may depend on the underlying collections, and that, among 
other things, foldmap is worth considering for benchmarking in 
performance-critical code, as is mapping a vector across multiple sequences 
to combine them into one that can be passed to run!.  And Alex's comment 
about range conveys that I shouldn't make superficial assumptions about 
what is and isn't going to run quickly!  More to learn 



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

[Mars0i]

Thanks very much Francis.  

So it sounds as if, if my data would already be in a vector, list or 
sequence (maybe a lazy sequence), doseq will process that structure as fast 
as possible, but there are other structures that might have faster internal 
reduce operations.

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

[Mars0i]

Thanks everyone--I'm very much appreciating the discussion, though I'm not 
sure I follow every point.  

Dragan, thank you very much for suggesting (and writing) foldmap.  Very 
nice.  I certainly don't mind using a library, though I still think there 
ought to be something like what I've described in the language core.

Francis, thanks for separating out the different types of intermediate 
collections.  I'm not entirely clear on type 1.  It sounds like those are 
just collections that are already there before processing them.  Or are you 
saying that Clojure has to convert them to a seq as such?  Why would doseq 
have to do that, for example?

It's an understatement to say that my understanding of monads, monoids, 
etc. is weak.   Haven't used Haskell in years, and I never understood 
monads, etc..  They seem trivial or/and or deeply mysterious.  One day I'll 
have to sit down and figure it out.  For foldmap, I don't understand what 
the first function argument to foldmap is supposed to do, but it's easy 
enough to put something there that does nothing.

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

[Mars0i]

On Friday, September 23, 2016 at 11:11:07 AM UTC-5, Alan Thompson wrote:
>
> ​Huh.  I was also unaware of the run! function.​
>
> I suppose you could always write it like this:
>
> (def x (vec (range 3)))
> (def y (vec (reverse x)))
>
> (run!
>   (fn [[x y]] (println x y))
>
>   (map vector x y))
>
>
>  > lein run
> 0 2
> 1 1
> 2 0
>
>
Yes.  But that's got the same problem.  Doesn't matter with a toy example, 
but the (map vector ...) could be undesirable with large collections in 
performance-critical code.

although the plain old for loop with dotimes looks simpler:
>
> (dotimes [i (count x) ]
>   (println (x i) (y i)))
>
>
> maybe that is the best answer? It is hard to beat the flexibility of a a 
> loop and an explicit index.
>

I agree that this is clearer, but it kind of bothers me to index through a 
vector sequentially in Clojure.  We need indexing In Clojure because 
sometimes you need to access a vector more arbitrarily.  If you're just 
walking the vector in order, we have better methods--as long as we don't 
want to walk multiple vectors in the same order for side effects.

However, the real drawback of the dotimes method is that it's not efficient 
for the general case; it could be slow on lists, lazy sequences, etc. 
(again, on non-toy examples).  Many of the most convenient Clojure 
functions return lazy sequences.  Even the non-lazy sequences returned by 
transducers aren't efficiently indexable, afaik.  Of course you can always 
throw any sequence into 'vec' and get out a vector, but that's an 
unnecessary transformation if you just want to iterate through the 
sequences element by element.

If I'm writing a function that will plot points or that will write data to 
a file, it shouldn't be a requirement for the sake of efficiency that the 
data come in the form of vectors.  I should be able to pass in the data in 
whatever form is easiest.  Right now, if I wanted efficiency for walking 
through sequences in the same order, without creating unnecessary data 
structures, I'd have to write the function using loop/recur.  On the other 
hand, if I wanted the cross product of the sequences, I'd use doseq and be 
done a lot quicker with clearer code.

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

[Mars0i]

On Friday, September 23, 2016 at 1:47:45 AM UTC-5, Francis Avila wrote:
>
> It's not crystal clear to me what you are after, either from this post or 
> the one you link to. I think you want a map that does not produce 
> intermediate collections and accepts multiple colls as input at a time? 


Yes.
 

> Do you have some pseudocode example so we can be precise?


What I was imagining most recently was something like this:

(doseq* [x (range 3) 
  y (reverse (range 3))]
  (println x y))

which would display:

0 2
1 1
2 0

as opposed to 
 
(doseq [x (range 3) 
 y (reverse (range 3))]
  (println x y))

which displays 

0 2
0 1
0 0
1 2
1 1
1 0
2 2
2 1
2 0

What about (run! my-side-effect-fn coll)
>
> This doesn't handle multiple coll at a time like the sequence function, 
> but you can tupleize coll with (map vector coll1 coll2) at some loss of 
> efficiency. Or you can roll your own.
>

Very nice--I didn't know about run! (!)  Yes, that would do it, except that 
it requires constructing unnecessary collections when you want to process 
multiple sequences.  We we able do the same tupelize trick with doseq, 
before run! appeared.

However, since we have run!, which is exactly what I wanted a year and a 
half ago except that it doesn't handle multiple collections, I would 
suggest simply enhancing run! to allow multiple sequence arguments:

 (run! (fn [x y] (println x y))
 (range 3) 
 (reverse (range 3))

which would produce:

0 2
1 1
2 0

 

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

parallel sequence side-effect processor

[Mars0i]

This is almost the same as an issue I raised in this group over a year and 
a half ago, here 
.
  
I suggested that Clojure should include function with map's syntax but that 
was executed only for side-effects, without constructing sequences.  No one 
else was interested--no problem.   It's still bugging me.

It's not map syntax that I care about at this point.  What's bugging me is 
that there's no standard, built-in way to process multiple sequences for 
side effects without (a) constructing unnecessary sequences or (b) rolling 
my own function with loop/recur or something else.

If I want to process multiple sequences for side-effects in the the way 
that 'for' does, Clojure gives me 'doseq'.  Beautiful.  I can operate on 
the cross product of the sequences, or filter them in various ways.

If I want to process multiple sequences by applying an n-ary function to 
the first element of each of n sequences, then to the second element of 
each sequence, and so on, I can use 'map' or 'mapv', but that means 
constructing unnecessary collections.

Or I can splice my n sequences together, and make a single sequence of 
n-tuples, and use doseq to process it.  (There's an example like this on 
the doseq doc page.)  Or I can process such a sequence with 'reduce'.  More 
unnecessary collections, though.

Or I can use 'dotimes', and index into each of the collections, which is OK 
if they're vectors, but ... ugh. why?

Or I can construct my own function using first and rest or first and next 
on each of my sequences, via loop/recur, for example.   But that seems odd 
to me.  

Isn't this a common use case?  Is processing multiple sequences for 
side-effects with corresponding elements in each application so unusual?  
(Am I the only one?)  Isn't it odd that we have doseq and map but nothing 
that processes multiple sequences for side-effects, in sequence, rather 
than as a cross-product?  

(I admit that in my current use case, the sequences are small, so creating 
a sequence of n-tuples would have only a trivial cost.  It just bugs me, 
though. :-)

I'd still be OK with something that had a map-like syntax, but my current 
inclination is that it would be better for such a function to have 
doseq-style syntax.  The name might be derived from "doseq"--maybe 
"doseq*". 

(I'd be willing to suggest this in a JIRA ticket, but that doesn't seem 
reasonable unless there's a call for something like this from more than one 
person.)

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

[Mars0i]

On Friday, September 16, 2016 at 8:14:49 AM UTC-5, Stefan Kamphausen wrote:
>
> Hi,
>
> On Friday, September 16, 2016 at 6:16:14 AM UTC+2, Mars0i wrote:
>>
>> Glad that this is happening.
>> You might want to add the date to the CFP and Schedule pages.  I only 
>> found it on the Press page.
>>
>  
> Thanks for your feedback.  I've added the date to the CfP page.  Did you 
> look for it on the front page, btw? ;-)
>

I looked across the top of the page for anything that seemed like a link to 
a page that might have the dates.  Since you mention the home page, I tried 
clicking on the graphic at the upper left, and found it, but that just 
looked like a graphic.  I never occurred to me that it was a link.  

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

[Mars0i]

Glad that this is happening.
You might want to add the date to the CFP and Schedule pages.  I only found 
it on the Press page.

On Wednesday, September 14, 2016 at 9:38:09 AM UTC-5, Stefan Kamphausen 
wrote:
>
> Dear Clojure-community,
>
>
> Please let me bring the current call for proposals for the next iteration 
> of the German clojure conference in Berlin, the :clojureD, to your 
> attention: 
>
>
> http://www.clojured.de/call-for-proposals/
>
> We call to send us talks for the upcoming :clojureD conference 2017.
>
> The conference is open for all topics. Our main purpose is to learn more 
> about Clojure with basic and advanced topics. All talks will be held in 
> English.
>
> We will have two types of talks:
>
>- Standard Talks (ca. 30 min)
>- Lightning Talks (ca. 6 min)
>
> It would be great if you can activate speakers with many topics! Good 
> lightning talks are not much of an effort. Do you know a keynote speaker?
>
> *The CfP ends 31.10.2016!*
>
>
>
> The team behind the conference is looking forward to receiving your 
> proposals.
>
>
> Regards,
> Stefan
>

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

[Mars0i]

On Friday, September 9, 2016 at 6:36:17 AM UTC-5, puzzler wrote:
>
> ...
> You can use `into` to "pour" the sequence into the collection of your 
> choice.  If you're using `into`, then most of these sequence functions 
> support transducers to avoid allocation of intermediate sequences, 
> providing a speed boost.
>

I routinely use `vec` for the kind of case that Colin described.  The 
effect is the same as `(into [] ...)` but it's more concise and doesn't 
require that extra tenth of a moment to figure out what kind of thing 
`into` is sending the sequence into.  I have no idea whether this is more 
or less efficient than using `into`, however.

A succinct summary of the basic idea implicit or explicit in other answers 
in this thread:
Most Clojure sequence functions produce lazy sequences.
If you want something anything other than a lazy sequence, convert it 
(with vec, into, etc.).

Bit me, too, but the correct rule is very simple, and easy to 
remember--which doesn't mean that I always remember to follow it!

Lazy sequences are the Clojure Way.
I love 'em.
And hate them.
It depends.
But they are the Clojure Way.

(Well--until transducers.)

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

[Mars0i]

The general principle is that the Clojure version that you get when you run 
'lein repl' will be the one specified in the project.clj file in the 
directory you're in when you run 'lein repl'.  (Nikita's link illustrates 
how the Clojure version is specified in project.clj.)  When you run 
'clojure' in your terminal, you're getting whatever script named "clojure" 
is first in your path.  You can see what your path is with a command such 
as 'echo $PATH'.  NightCode may have it's own way of specifying the version 
to use, but I don't use NightCode, so I don't know.

Are you in the drawing directory when you run 'lein repl'?  If not, then 
you're not getting the version of Clojure specified in 
drawing/project.clj.  You're just getting whatever version of Clojure is 
the default for the version of Leiningen that's installed.

If you are in drawing when you run 'lein repl', then I wonder, like Nikita, 
what version of Leiningen you have.  However, you should be able upgrade to 
the latest version of Leiningen by running 'lein upgrade' at a shell 
prompt.  You would still want to run 'lein repl' from the directory that 
was created by 'lein new quil drawing', though, in order to work with quil.

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

[Mars0i]

I'm not anywhere near as deep into spec as would be needed to fully 
understand this thread, but I will say that I agree with those who object 
to the guitar analogy.  That argument would work just as well as a response 
to someone who complained about the difficulty of C++, or assembler, or 
APL.  What's beautiful about Clojure is that it is, right now, already, a 
language for experts--*and* for novices (except for error reporting).  I'm 
not in favor of an assumption that it's only a language for experts, and 
that therefore it's OK if error reporting is hard for novices.

My standard for error reporting: modern Common Lisp implementations (e.g. 
SBCL, ABCL, CCL, LispWorks).  Reading any stack trace requires learning, 
but the CL stacktraces are nowhere near as daunting as Java and Clojure.  I 
don't expect Clojure's error reporting to ever be that good; I suspect that 
the overhead of doing that kind of thing on the JVM is not worth the cost.  
But it can aspire to that kind of ease.  (In other respects, CL is more 
difficult than Clojure, imo.)

If you read the introduction to Bjarne Soutstrup's C++ book 3rd ed (I don't 
know whether it's still there in the 4th), you'll see that at one point he 
says that his goal was to keep C++ a simple language.  If you go on and 
read the rest of the book, you'll see how far from that goal the language 
ended up.  I have (rare) moments when I worry that Clojure is great because 
it's young and hasn't had time to become a mess.  I still trust Rich's 
judgement, though.

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

[Mars0i]

On Wednesday, August 3, 2016 at 6:00:43 AM UTC-5, Yehonathan Sharvit wrote:
>
> Mars0i, as I see it interactivity is the key for effective learning - both 
> for kids and adults.
>
> This is the whole point of Klipse - https://github.com/viebel/klipse.
>

Ah, very nice.  I know about Clojurescript browser repls, but doing it for 
the other languages is a Good Thing.

By the way, do you have any suggestion about how to make the errors less 
> daunting?
>

I've been using Clojure for a while, but only recently starting using 
Clojurescript.  Apparently, you can capture errors in Clojurescript in a 
similar way to the how it's done in Clojure.

http://stackoverflow.com/questions/12655503/how-to-catch-any-javascript-exception-in-clojurescript
https://github.com/clojure/clojurescript/wiki/Exception-Handling

For example:

(try 
  (5 2) 
  (catch js/Object e "That didn't work."))

This returns the string at the end of the catch expression in the 
Clojurescript repl on my computer.  It returns nil at a Klipse prompt in 
kids.klipse.tech, so I'm not sure what else you'll have to do.

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

[Mars0i]

This looks very, very nice.  The instant feedback is especially helpful.  
(You are probably already working on is capturing errors to make them less 
daunting.)

Klipse reminded me of Carin Meier's beautiful and poignant Hello World for 
the Next Generation. 


I always wondered whether *The Little Schemer* 
 would work with kids. I 
suspect not, until mid teens, at least.

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

[Mars0i]

On Monday, July 25, 2016 at 10:56:09 AM UTC-5, Mars0i wrote:
>
>  just noticed this morning that :path is explained in "clojure.spec - 
> Rationale and Overview".
>

There's also material about :path in your Spec Guide, but I had not fully 
understood it.  I get it now--at least up to the level of my understanding 
of the rest of spec. 

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

[Mars0i]

Alex, thanks very much.  That's all very helpful.  Just what I needed.  I 
hadn't seen an explanation of the meaning of :path, :via, and :in, and was 
guessing about them from experiments.:via and :in aren't mentioned in 
the docstring, so I wasn't sure whether to depend on them.   (The source 
code that feeds into explain-data isn't easy reading--no reason to think it 
would be--and I haven't made sense of it so far.)   I just noticed this 
morning that :path is explained in "clojure.spec - Rationale and Overview".

I assume that the explain-data docstring will eventually sketch the meaning 
of :path, :via, and :in.  Or is this the sort of thing that I ought to file 
a JIRA ticket on if I think it's important? (I'm new to using JIRA don't 
want to clutter up with irrelevant tickets during an alpha process.  I 
don't see a ticket about the explain-data docstring.

On Monday, July 25, 2016 at 12:34:23 AM UTC-5, Alex Miller wrote:
>
>
>
> On Sunday, July 24, 2016 at 10:40:41 PM UTC-5, Mars0i wrote:
>>
>> spec/explain-data seems very important.  It allows programmatic responses 
>> to spec failures.  Maybe explain-data's behavior hasn't yet stabilized, 
>> though?  The structure of the return value has changed between 1.9.0-alpha7 
>> to the current 1.9.0-alpha10, the docstring is a bit vague, and the Spec 
>> Guide only talks about it very briefly.
>>
>
> explain-data is not in flux but as we are in alpha, it could still change.
>
> :path are path tags
> :via are specs
> :in are data keys
>
> At present, it's easy to figure out which test(s) has/have failed by 
>> examining the :path value(s) in explain-data's return value in some 
>> situations, such as when specs are combined using spec/keys or spec/or. In 
>> other situations--at least when specs are combined with spec/and,  the:path 
>> values are empty.  Unlike spec/or, there's no way to specify keywords that 
>> would identify the failed test.
>>
>> Am I right that explain-data is in flux?  Is the goal that in the future, 
>> it will always be possible for developers to specify composite specs in 
>> such a way that explain-data can return info that identifies the failed 
>> test clearly?  For example, in the first spec/and illustration below, maybe 
>> explain-data could use the names of the component specs as path elements?  
>> (Or am I just confused about something?)
>>
>
> As specs, the component spec path is recorded in :via.
>  
>
>>
>> Thanks-
>>
>> Example, using Clojure 1.9.0-alpha10:
>>
>> (s/def ::even even?)
>> (s/def ::zero-to-ten (s/int-in 0 10)) ; require number from 0 to 10 
>> inclusive
>>
>> user=> (s/explain-data (s/or :pred1 ::even :pred2 ::zero-to-ten) 11)
>> {:clojure.spec/problems
>>  ({:path [:pred1], :pred even?, :val 11, :via [:user/even], :in []}
>>   {:path [:pred2],
>>:pred (int-in-range? 0 10 %),
>>:val 11,
>>:via [:user/zero-to-ten],
>>:in []})}
>>
>> ;; Note that the format of the path entries are different above and below.
>> ;; Is there a reason for this difference, or will later versions return
>> ;; the same path elements?
>>
>
> Both examples seem consistent with my prior description of the data (specs 
> in :via, paths in :path, and data keys in :in). They are specs with 
> different structure so I would not expect them to yield the same explain 
> results.
>  
>
>> user=> (s/explain-data (s/keys :req-un [::even ::zero-to-ten]) {:even 11 
>> :zero-to-ten 11})
>> {:clojure.spec/problems
>>  ({:path [:even], :pred even?, :val 11, :via [:user/even], :in [:even]}
>>   {:path [:zero-to-ten],
>>:pred (int-in-range? 0 10 %),
>>:val 11,
>>:via [:user/zero-to-ten],
>>:in [:zero-to-ten]})}
>>
>> ;; Here there's nothing in the :path or :in sequences, although :via 
>> provides some information:
>>
>
> Yes, as expected.
>  
>
>> user=> (s/explain-data (s/and ::even ::zero-to-ten) 11)
>> #:clojure.spec{:problems [{:path [], :pred even?, :val 11, :via 
>> [:user/even], :in []}]}
>>
>> ;; Note that only the first failed test is identified, which makes sense.
>>
>  
>
>>
>> ;; Another s/and example, with no info other than the value of :pred to 
>> indicate what test failed:
>>
>  
> What other info could be provided? You have the predicate and the invalid 
> value. If you had named the predicate, you would have more info.
>
> user=> (s/explain-data (s/and even? (s/int-in 0 10)) 11)
>> #:clojure.spec{:problems [{:path [], :pred even?, :val 11, :via [], :in 
>> []}]}
>>
&g

Future of spec/explain-data, spec/and, etc.

[Mars0i]

spec/explain-data seems very important.  It allows programmatic responses 
to spec failures.  Maybe explain-data's behavior hasn't yet stabilized, 
though?  The structure of the return value has changed between 1.9.0-alpha7 
to the current 1.9.0-alpha10, the docstring is a bit vague, and the Spec 
Guide only talks about it very briefly.

At present, it's easy to figure out which test(s) has/have failed by 
examining the :path value(s) in explain-data's return value in some 
situations, such as when specs are combined using spec/keys or spec/or. In 
other situations--at least when specs are combined with spec/and,  the:path 
values are empty.  Unlike spec/or, there's no way to specify keywords that 
would identify the failed test.

Am I right that explain-data is in flux?  Is the goal that in the future, 
it will always be possible for developers to specify composite specs in 
such a way that explain-data can return info that identifies the failed 
test clearly?  For example, in the first spec/and illustration below, maybe 
explain-data could use the names of the component specs as path elements?  
(Or am I just confused about something?)

Thanks-

Example, using Clojure 1.9.0-alpha10:

(s/def ::even even?)
(s/def ::zero-to-ten (s/int-in 0 10)) ; require number from 0 to 10 
inclusive

user=> (s/explain-data (s/or :pred1 ::even :pred2 ::zero-to-ten) 11)
{:clojure.spec/problems
 ({:path [:pred1], :pred even?, :val 11, :via [:user/even], :in []}
  {:path [:pred2],
   :pred (int-in-range? 0 10 %),
   :val 11,
   :via [:user/zero-to-ten],
   :in []})}

;; Note that the format of the path entries are different above and below.
;; Is there a reason for this difference, or will later versions return
;; the same path elements?

user=> (s/explain-data (s/keys :req-un [::even ::zero-to-ten]) {:even 11 
:zero-to-ten 11})
{:clojure.spec/problems
 ({:path [:even], :pred even?, :val 11, :via [:user/even], :in [:even]}
  {:path [:zero-to-ten],
   :pred (int-in-range? 0 10 %),
   :val 11,
   :via [:user/zero-to-ten],
   :in [:zero-to-ten]})}

;; Here there's nothing in the :path or :in sequences, although :via 
provides some information:
user=> (s/explain-data (s/and ::even ::zero-to-ten) 11)
#:clojure.spec{:problems [{:path [], :pred even?, :val 11, :via 
[:user/even], :in []}]}

;; Note that only the first failed test is identified, which makes sense.

;; Another s/and example, with no info other than the value of :pred to 
indicate what test failed:
user=> (s/explain-data (s/and even? (s/int-in 0 10)) 11)
#:clojure.spec{:problems [{:path [], :pred even?, :val 11, :via [], :in 
[]}]}

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

[Mars0i]

On Thursday, July 21, 2016 at 5:34:37 PM UTC-5, adrian...@mail.yu.edu wrote:
>
> Just for future reference this is a mailing list and not a traditional 
> forum, so after you post something here it will email everyone subscribed. 
>

Thanks Adrian.  I actually didn't realize 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 spec/and ?

[Mars0i]

Ahh...  I realized my mistake very soon after I posted the question, and 
deleted it.  You must have caught it before it went away.  Your explanation 
is helpful, though.  Thanks.

On Thursday, July 21, 2016 at 1:30:56 PM UTC-5, miner wrote:
>
> It looks like you’ve got your #s misplaced.  I think you want something 
> like this:
>
> (s/and #(> % 0.0) #(< % 1.0))
>
> Of course, the first predicate expression could be replaced by `pos?`.
>
> The `s/and` returns a single spec that combines multiple specs.  Of 
> course, `clojure.core/and` is basically the logical AND of “truthy” values.
>
> The #(…) form is creating an anonymous function.  In your first case, that 
> creates a reasonable predicate, which works correctly as a spec.
>
> Your second form isn’t doing what you wanted because the anonymous 
> function notation is wrapping the whole `s/and` combining form, and in that 
> context the tests aren't syntactically the appropriate predicates.  You’re 
> getting an extra level of nesting and bad tests.
>
> I suspect that the confusion comes from the similarity between a predicate 
> and a spec.  In a sense, a predicate function is the simplest form of a 
> spec.  However, you need a special way of combining multiple specs, not 
> just the plain logical `and` combination.  So we have `s/and` to do the job.
>
>
>
> On Jul 21, 2016, at 1:23 PM, Mars0i <mars...@logical.net > 
> wrote:
>
> With Clojure 1.9.0-alpha10:
>
>
>
>
>
>
>
>
> *user=> (s/def ::interval-with-cloj-and #(and   (> % 0.0) (< % 
> 1.0)))user=> (s/def ::interval-with-spec-and #(s/and (> % 0.0) (< % 
> 1.0)))user=> (s/valid? ::interval-with-cloj-and 1.0)false*That's what I 
> expected.
>
>
> *user=> (s/valid? ::interval-with-spec-and 1.0)true*
>
> That's not what I expected.
>
> In fact, as far as I can tell, (valid? ::interval-with-spec-and x) will 
> return true for any number x.  What does spec/and mean, then?  I thought 
> that in this context it would mean the same as Clojure's normal 'and'.  
> That's what the first example of its use in the Clojure.spec Guide seems to 
> show.  I must be misunderstanding something basic and perhaps obvious.
>
>
>
>

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

meaning of spec/and ?

[Mars0i]

With Clojure 1.9.0-alpha10:








*user=> (s/def ::interval-with-cloj-and #(and   (> % 0.0) (< % 1.0)))user=> 
(s/def ::interval-with-spec-and #(s/and (> % 0.0) (< % 1.0)))user=> 
(s/valid? ::interval-with-cloj-and 1.0)false*That's what I expected.


*user=> (s/valid? ::interval-with-spec-and 1.0)true*

That's not what I expected.

In fact, as far as I can tell, (valid? ::interval-with-spec-and x) will 
return true for any number x.  What does spec/and mean, then?  I thought 
that in this context it would mean the same as Clojure's normal 'and'.  
That's what the first example of its use in the Clojure.spec Guide seems to 
show.  I must be misunderstanding something basic and perhaps obvious.

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

[Mars0i]

On Thursday, July 21, 2016 at 8:50:21 AM UTC-5, miner wrote:
>
> With a little help from Java, you can make equivalent open intervals for 
> the desired bounds.  For example, 
>
> Also, you can use java.lang.Math/nextUp and nextAfter to get adjacent 
> doubles for your bounds. 
>
> (java.lang.Math/nextUp 1.1) 
> ;=> 1.1003 
>
> (java.lang.Math/nextAfter 1.1 Double/NEGATIVE_INFINITY) 
> ;=> 1.0999 
>
> There are a few tricky situations around the zeroes and infinities so you 
> should read the doc on nextAfter, especially if you’re dealing with extreme 
> doubles. 
>

Cool--very nice to know.  Thanks.  I may use it.

Ideally, I'd rather not have to descend to that level for a spec, because 
the meaning becomes less clear, and I'd rather let built-in language 
constructs hide differences between Clojure and Clojurescript whenever 
possible.  Testing for being > 0.0 and < 1.1 won't involve a meaningful 
difference in different clojure variants, for most 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: Enhance spec/double-in to handle open and half-open intervals?

[Mars0i]

On Thursday, July 21, 2016 at 9:51:02 AM UTC-5, Alex Miller wrote:
>
> You can already get open intervals by just omitting :min or :max.
>

I think my terminology may have created some confusion; I probably 
shouldn't have used open/closed.  I meant "open interval" in the sense that 
an open interval is one 
that doesn't include the endpoints.  e.g. all real numbers x such that x > 
0 and x < 1 are the open interval (0, 1).  A half-open interval is one that 
includes one of the endpoints, but not the other one.   

(s/double-in :infinite? false) sort of specifies an open interval in my 
sense, except that there are hard boundaries on what can be represented as 
a double, so I suppose it's really a closed interval.  I don't know.  
That's getting too pedantic even for me. :-)

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

Re: Enhance spec/double-in to handle open and half-open intervals?

[Mars0i]

On Wednesday, July 20, 2016 at 10:02:17 PM UTC-5, Alex Miller wrote:
>
> On Wednesday, July 20, 2016 at 9:41:59 PM UTC-5, Mars0i wrote:
>>
>> On Wednesday, July 20, 2016 at 4:32:40 PM UTC-5, Alex Miller wrote:
>>>
>>> You can file a jira if you like, I'm not sure Rich's thoughts on this. 
>>>
>>
>> I understand.  Thanks--will do.
>>  
>>
>>> Also, keep in mind that you can also compose preds and get this with 
>>> slightly more effort now:
>>>
>>> (s/and (s/double-in :min 0.0 :max 1.0) #(not= 0.0 %))
>>>
>>
>> Yes, definitely.  Though #(and (> % 0.0) (<= % 1)) seems simpler if one 
>> doesn't really need the NaN and Infinity tests. 
>>
>
> You'll find that the generator for double-in is far better than what 
> you're suggesting, and you should lean on it when doing things slightly 
> differently. 
>
> I didn't try it but I don't think your example would gen at all - you'd 
> need to s/and double? in there too at the beginning and even then it's 
> going to generate random doubles then filter to your range, but most 
> generated values will not be in the range. s/double-in is designed to only 
> generate values in the specified range.
>

Ah.  Thanks.   I'm sure you're right.  I didn't understand the role of the 
spec logic functions generating for testing.  I hadn't thought about the 
generator functionality at all--just validation of real inputs.  I'm still 
feeling my way in the dark with spec.  I needed half-open and closed 
interval tests for user input the very small application that I'm using to 
explore spec, which is how the issue about double-in arose for me.  i.e. I 
have a real use case, but my testing can be pretty simple.

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

[Mars0i]

On Wednesday, July 20, 2016 at 4:32:40 PM UTC-5, Alex Miller wrote:
>
> You can file a jira if you like, I'm not sure Rich's thoughts on this. 
>

I understand.  Thanks--will do.
 

> Also, keep in mind that you can also compose preds and get this with 
> slightly more effort now:
>
> (s/and (s/double-in :min 0.0 :max 1.0) #(not= 0.0 %))
>

Yes, definitely.  Though #(and (> % 0.0) (<= % 1)) seems simpler if one 
doesn't really need the NaN and Infinity tests. 

Thanks.


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

Enhance spec/double-in to handle open and half-open intervals?

[Mars0i]

clojure.spec/double-in defines a spec that tests whether a double is 
greater than or equal to a minimum value and less than or equal to a 
maximum value.  This is useful for many purposes, but sometimes you need to 
test whether a double is greater than a minimum or less than a maximum. 
 There are many mathematical applications that assume half-open intervals 
(> min and <= max; >= min and < max) or open intervals (> min and < max). 
 Example: You are going to divide by the double, so it must be > 0, not 
just >= 0.  Providing double-in but only allowing it to specify closed 
intervals seems arbitrary.

It's easy enough to write open-interval and half-open interval tests, 
either using s/and with s/double-in, or just by defining a function from 
scratch.  However, if Clojure is going to provide double-in, why make us do 
that?  Why not have a common interface that adds two optional keywords to 
specify whether the bounds are open or closed?  This is not a request to 
add the kitchen sink; it's a natural extension to deal with a common use 
case.  The alternative would be to define three additional versions of 
double-in, and people will do that on their own, or define a new more 
flexible double-in if there's no built-in spec function that does it.


I'd suggest a new keyword with one of the following forms: 


:min-open, :min-greater, :min-greater-than, :min-strict, :greater-min, 
:strict-min, etc.,


and a corresponding keyword for the max side.


Default values should be false, for compatibility with the current 
definition of double-in.


I can add a JIRA ticket if this seems worthwhile.  I wanted to see what 
people think first.  (I'd have to sign up with the JIRA system, but I 
assume I'm allowed to do that.)  My apologies if there's already a JIRA 
ticket for this.  I don't seem to be able to find anything on double-in, 
but I'm not sure I understand the search syntax.

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

[mars0i]

This version isn't supposed to have implemented spec/double-in yet, right?  

I get "Use of undeclared Var cljs.spec/double-in".

Sorry to ask--I don't know my way around JIRA well, and searching for 
"double-in" brings up a lot of irrelevant tickets.

Thanks much.

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

[Mars0i]

Upon further investigation, there are helpful examples on this page 
http://clojure.org/guides/spec, which was mentioned in the 1.9.0-alpha1 
release notice, and there's a small example near the end of the Rationale 
and Overview page.  I still feel as if both pages kind of start in the 
middle rather than at the beginning by going over the guts before their 
purpose, but the guides page gets to the point fairly quickly.  I still 
think the "species" etymology and def is unhelpful, even though in some 
sense it's just the sort of thing I would like in a different context.  

Thanks again, in any event.

On Wednesday, May 25, 2016 at 11:14:59 AM UTC-5, Mars0i wrote:
>
> I'm very happy about clojure.spec.  I think. (!)
>
> Two suggestions for the documentation page.  Just my two cents.
>
> First, it would be helpful to begin with a description of what 
> clojure.spec does and how it will be used, and one or two brief examples 
> right at the beginning--ideally before the first or second page scroll.  
> The current "Rationale and Overview" page starts with a very long rationale 
> section ("Problems", "Objectives", "Guidelines"), followed by a long and 
> detailed "Features" section.  Both of these are needed, but throughout the 
> rationale material, I was trying to infer what it was that clojure.spec 
> really was, and then when I got to "Features", I still was trying to get a 
> general sense of how clojure.spec supposed to be used before wading through 
> an informal specification of its details.  No doubt I can study "Features" 
> and synthesize my own general understanding of clojure.spec, but I don't 
> think that should be necessary.  (When I say, "how it is used", I don't 
> mean how it will interact with clojure.test.  That's important but 
> secondary.  I need something more fundamental.)  The many postings in this 
> thread show that many people already have the idea.  I assume that this is 
> either because they've already worked with something similar, or did have 
> the time to closely study the documentation and synthesize their own 
> understanding, or maybe they're just smarter than I am. :-)
>
> 2. This is just confusing:
>
> Communication
>
>
>
> Species - appearance, form, sort, kind, equivalent to spec (ere) to look, 
> regard
>+ -iēs abstract noun suffix
>
> Specify - species + -ficus -fic (make)
>
>
> A specification is about how something 'looks', but is, most importantly, 
> something that is looked at. Specs should be readable, composed of 'words' 
> (predicate functions) programmers are already using, and integrated in 
> documentation.
>
> I gather that the indented part is excerpted from a dictionary entry for 
> the word "Species", but at first I thought it was an example or a part of 
> the specification of clojure.spec.  Just wasn't sure.  Coming as it does in 
> a section called "Communication", and followed by text that includes "Specs 
> should be readable"--when the "example" isn't readable, it's very 
> confusing.  Cute, maybe, once you understand it, but unhelpful for someone 
> who is trying to learn what clojure.spec is.
>
>
> Thanks!  I still am not entirely clear about how clojure.spec should be 
> used, but from what I can tell, it's very good thing and I'm very happy 
> about it.
>
> I was a participant in a few long discussions about improving Clojure 
> docstrings, and I gather that clojure.spec might supplement or end up 
> playing a role in modifying docstrings to provide succinct, clear 
> descriptions of expected arguments, with potentially systematic display 
> formatting, all of which would be great.  The other uses of clojure.spec, 
> at least as I understand them, also seem extremely useful.
>

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

[Mars0i]

I'm very happy about clojure.spec.  I think. (!)

Two suggestions for the documentation page.  Just my two cents.

First, it would be helpful to begin with a description of what clojure.spec 
does and how it will be used, and one or two brief examples right at the 
beginning--ideally before the first or second page scroll.  The current 
"Rationale and Overview" page starts with a very long rationale section 
("Problems", "Objectives", "Guidelines"), followed by a long and detailed 
"Features" section.  Both of these are needed, but throughout the rationale 
material, I was trying to infer what it was that clojure.spec really was, 
and then when I got to "Features", I still was trying to get a general 
sense of how clojure.spec supposed to be used before wading through an 
informal specification of its details.  No doubt I can study "Features" and 
synthesize my own general understanding of clojure.spec, but I don't think 
that should be necessary.  (When I say, "how it is used", I don't mean how 
it will interact with clojure.test.  That's important but secondary.  I 
need something more fundamental.)  The many postings in this thread show 
that many people already have the idea.  I assume that this is either 
because they've already worked with something similar, or did have the time 
to closely study the documentation and synthesize their own understanding, 
or maybe they're just smarter than I am. :-)

2. This is just confusing:

Communication



Species - appearance, form, sort, kind, equivalent to spec (ere) to look, 
regard
   + -iēs abstract noun suffix

Specify - species + -ficus -fic (make)


A specification is about how something 'looks', but is, most importantly, 
something that is looked at. Specs should be readable, composed of 'words' 
(predicate functions) programmers are already using, and integrated in 
documentation.

I gather that the indented part is excerpted from a dictionary entry for 
the word "Species", but at first I thought it was an example or a part of 
the specification of clojure.spec.  Just wasn't sure.  Coming as it does in 
a section called "Communication", and followed by text that includes "Specs 
should be readable"--when the "example" isn't readable, it's very 
confusing.  Cute, maybe, once you understand it, but unhelpful for someone 
who is trying to learn what clojure.spec is.


Thanks!  I still am not entirely clear about how clojure.spec should be 
used, but from what I can tell, it's very good thing and I'm very happy 
about it.

I was a participant in a few long discussions about improving Clojure 
docstrings, and I gather that clojure.spec might supplement or end up 
playing a role in modifying docstrings to provide succinct, clear 
descriptions of expected arguments, with potentially systematic display 
formatting, all of which would be great.  The other uses of clojure.spec, 
at least as I understand them, also seem extremely useful.

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

[question] lein repl exceptions

[Mars0i]

Try (pst) .

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

[Mars0i]

On Tuesday, April 26, 2016 at 12:19:23 AM UTC-5, Mars0i wrote:
>
> I was going to say that I'd be surprised if Clojure were as fast as SBCL 
> (overall, on average, depends on your application, depends on how you code 
> it, ymmv, etc. ...).  Then I stopped back to check the little benchmarks on 
> the Computer Language Benchmarks Game 
> <https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=clojure=sbcl>
>  
> .  Whatever it is that those comparisons do, or don't prove, I would no 
> longer be surprised.
>

I forgot how much faster Clojure got in 1.7 and 1.8.  I remember Java 
wiping the floor with Clojure on most of those benchmarks a couple of years 
ago, but now it's just a little bit faster on average 
<https://benchmarksgame.alioth.debian.org/u64q/clojure.html> on those 
benchmarks.

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

[Mars0i]

On Monday, April 25, 2016 at 3:50:45 PM UTC-5, tbc++ wrote:
>
> As someone who has spent a fair amount of time playing around with such 
> things, I'd have to say people vastly misjudge the raw speed you get from 
> the JVM's JIT and GC. In fact, I'd challenge someone to come up with a 
> general use, dynamic language that is not based on the JVM and comes even 
> close to the speed of Clojure. 
>

I was going to say that I'd be surprised if Clojure were as fast as SBCL 
(overall, on average, depends on your application, depends on how you code 
it, ymmv, etc. ...).  Then I stopped back to check the little benchmarks on 
the Computer Language Benchmarks Game 

 
.  Whatever it is that those comparisons do, or don't prove, I would no 
longer be surprised.

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

[Mars0i]

On Thursday, April 21, 2016 at 2:20:11 PM UTC-5, Mars0i wrote:

> The behavior with strings is simply undocumented anywhere, afaik, though.
>

Sorry, that was wrong even before I added an example to clojure.docs.  The 
conj.io documentation is quite explicit and detailed.

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

[Mars0i]

On Thursday, April 21, 2016 at 11:49:16 AM UTC-5, Andy Fingerhut wrote:
>
> Most doc strings are considered terse by many people.  This appears to be 
> considered a feature by those who maintain Clojure, not a bug, with one 
> reason given by Stuart Halloway in his recent talk on using the scientific 
> method in debugging [1].  Paraphrased from memory it was approximately "if 
> you have a bug in some API you are using, you should read all of the 
> documentation for it.  That is easier if it is short."
>
> If you want longer documentation and/or examples, ClojureDocs.org and 
> conj.io take user submissions for additional documentation, with quite 
> low friction.
>

Yeah, there are tradeoffs.  I understand the value of brief docstrings.  
The current docstring for 'get' is correct for maps and vectors, even 
though the meaning for vectors won't be apparent for novices.  Lots of 
things aren't apparent for novices.  

The behavior with strings is simply undocumented anywhere, afaik, though.  
That seems wrong.  (Correction: I just added an example to clojure.docs.  I 
still think that all of the intended behavior of a function should be at 
least tersely implied by its docstring.)

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

Are strings vectors? Should 'get' docstring be changed?

[Mars0i]

The docstring for 'get' says nothing explicit about vectors ("Returns the 
value mapped to key, not-found or nil if key not present.") but most of us 
know that vectors can be viewed as associative data structures where 
indexes are like keys:

(get [\a \b \c] 1) 
\b

'get' also works on strings:

(get "abc" 1)
\b

However, strings are not treated as vectors or maps in other contexts:

(assoc "abc" 1 \Z)
ClassCastException java.lang.String cannot be cast to 
clojure.lang.Associative

This combination of behaviors is confusing.  If strings are vectors, then 
'assoc' and other similar functions should work with them, and maybe I 
should be able to do this to index into a string:

("abc" 1)
ClassCastException java.lang.String cannot be cast to clojure.lang.IFn

If strings are not vectors, then they seem to be a special case for 'get'.  
One might argue that the very terse docstring for 'get' should note its use 
with vectors, but once you understand the sense in which vectors are like 
maps, the of 'get' use with vectors is implicitly covered by what the 
docstring says.  However, the use of 'get' with strings is not implicitly 
covered by what the docstring says.  If it was, then the last two examples 
I gave should work.

(I'd be willing to file a ticket on this, but the puzzling behavior is not 
new, and I suspect that there's something I'm not understanding.)

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

[Mars0i]

On Sunday, April 17, 2016 at 4:23:32 PM UTC-5, JvJ wrote:
>
> Orders of magnitude?  Is it even worth running things in parallel in this 
> case?
>

I got a 2X-5X speed improvement with pmap, but as adrian says, it depends.

The nice thing about  pmap, though, is that using it just involves adding a 
"p" to the front of a map call.  So if you're already using map for 
something, it's easy to test whether pmap helps (preferably using Criterium 
).  

One thing that can help make pmap worthwhile is rearranging code so that 
the function passed to a single map/pmap call does a lot of work with each 
element of the collection passed to it.  If the amount of computation for 
each element is sufficiently high, pmap will be faster.e.g. rather than 
(map f1 (map f2 (map f3 my-collection))), do (map (comp f1 f2 f3) 
my-collection), and then try adding the "p" on the front.  This avoids 
constructing unnecessary intermediate sequences, 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: Advice getting started with concurrency and parallelism in Clojure

[Mars0i]

Niels-- Ah, interesting.  My uses of pmap haven't been I/O bound.  I didn't 
know about the claypoole library.  Will keep that in mind.

On Thursday, April 7, 2016 at 8:00:39 AM UTC-5, Niels van Klaveren wrote:
>
> The biggest problem with pmap I have is ordering, ie. it will process in 
> batches of (+ 2 (.. Runtime getRuntime availableProcessors)), and only 
> take a new batch when the slowest of the old batch has been evaluated. With 
> functions dependent on IO, parallel gains are only a fraction of what they 
> could be. I used to solve this by creating my own code to process in 
> futures and delays, but when I found the claypoole library, especially it's 
> unordered pmap and for, I never had to touch these again.
>
> On Wednesday, April 6, 2016 at 3:11:52 PM UTC+2, Mars0i wrote:
>>
>> Maybe people forget about pmap <http://clojuredocs.org/clojure.core/pmap>, 
>> pcalls <http://clojuredocs.org/clojure.core/pcalls>, and pvalues 
>> <http://clojuredocs.org/clojure.core/pvalues> because they're just too 
>> easy.
>>
>> On Tuesday, April 5, 2016 at 8:51:59 PM UTC-5, tbc++ wrote:
>>>
>>> If it all seems confusing, do not despair, there's two things that will 
>>> handle the vast majority of the use cases you may have: 
>>>
>>> 1) `future` - spawns a thread that runs the body of the future (
>>> https://clojuredocs.org/clojure.core/future)
>>> 2) `atom` and `swap!` - Used to store data that needs to be shared 
>>> between threads and updated concurrently (
>>> https://clojuredocs.org/clojure.core/atom) these are built on top of 
>>> CAS, which itself is foundation upon which most of concurrent programming 
>>> is built. (https://en.wikipedia.org/wiki/Compare-and-swap)
>>>
>>> Those two primitives alone will handle 90% of the use cases you will run 
>>> into as a new clojure developer. The rest of the stuff (agents, thread 
>>> pools, refs, vars, cps/core.async) can all come in time, but you will use 
>>> them much less often than threads and atoms. So read up on those two and 
>>> feel free to come back with any questions you may have. 
>>>
>>> Timothy
>>>
>>>
>>> On Tue, Apr 5, 2016 at 7:24 PM, Chris White <cwpr...@live.com> wrote:
>>>
>>>> I was doing some reading of code recently to help me get up to speed 
>>>> with Clojure. One of the libraries I randomly came across dealt with 
>>>> parallelism and I had a hard time following along with it. To try and wrap 
>>>> my head around things I did a quick search and found this article:
>>>>
>>>>
>>>> http://www.thattommyhall.com/2014/02/24/concurrency-and-parallelism-in-clojure/
>>>>
>>>> I'm not sure how authoritative this is based on my current experience, 
>>>> but needless to say I was a bit overwhelmed. That said is there any sort 
>>>> of 
>>>> introductory material that list members have used to help get them into 
>>>> how 
>>>> Clojure deals with concurrency and parallelism? I also don't mind anything 
>>>> that's not specifically using Clojure but will at least help me understand 
>>>> the concepts behind how Clojure does it. Thanks again for any and all help!
>>>>
>>>> - Chris White (@cwgem)
>>>>
>>>> -- 
>>>> 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.
>>>>
>>>
>>>
>>>
>>> -- 
>>> “One of the main causes of the fall of the Roman Empire was that–lacking 
>>> zero–they had no way to indicate successful termination of their C 
>>> programs.”
>>> (Robert Firth) 
>>>
>>

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

[Mars0i]

I think I got a big speed boost going from 1.6 to 1.7, and a smaller boost 
going from 1.7 to 1.8.

On Wednesday, April 6, 2016 at 3:38:07 PM UTC-5, Piyush Katariya wrote:
>
>
> Has anybody experienced the performance boost by switching to Clojure 
> version 1.8 (and direct linking) ?
>

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

[Mars0i]

Maybe people forget about pmap , 
pcalls , and pvalues 
 because they're just too easy.

On Tuesday, April 5, 2016 at 8:51:59 PM UTC-5, tbc++ wrote:
>
> If it all seems confusing, do not despair, there's two things that will 
> handle the vast majority of the use cases you may have: 
>
> 1) `future` - spawns a thread that runs the body of the future (
> https://clojuredocs.org/clojure.core/future)
> 2) `atom` and `swap!` - Used to store data that needs to be shared between 
> threads and updated concurrently (
> https://clojuredocs.org/clojure.core/atom) these are built on top of CAS, 
> which itself is foundation upon which most of concurrent programming is 
> built. (https://en.wikipedia.org/wiki/Compare-and-swap)
>
> Those two primitives alone will handle 90% of the use cases you will run 
> into as a new clojure developer. The rest of the stuff (agents, thread 
> pools, refs, vars, cps/core.async) can all come in time, but you will use 
> them much less often than threads and atoms. So read up on those two and 
> feel free to come back with any questions you may have. 
>
> Timothy
>
>
> On Tue, Apr 5, 2016 at 7:24 PM, Chris White  > wrote:
>
>> I was doing some reading of code recently to help me get up to speed with 
>> Clojure. One of the libraries I randomly came across dealt with parallelism 
>> and I had a hard time following along with it. To try and wrap my head 
>> around things I did a quick search and found this article:
>>
>>
>> http://www.thattommyhall.com/2014/02/24/concurrency-and-parallelism-in-clojure/
>>
>> I'm not sure how authoritative this is based on my current experience, 
>> but needless to say I was a bit overwhelmed. That said is there any sort of 
>> introductory material that list members have used to help get them into how 
>> Clojure deals with concurrency and parallelism? I also don't mind anything 
>> that's not specifically using Clojure but will at least help me understand 
>> the concepts behind how Clojure does it. Thanks again for any and all help!
>>
>> - Chris White (@cwgem)
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

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

[Mars0i]

Well, will disagree about some things, but agree very much about 
others--probably all practical matters.  Some of your remarks seem 
valuable.  Some don't seem relevant to me.  Ah well, we're just talking 
here.  Not everything needs to matter.  

Your point about thriving, competing libraries is important.   What's the 
difference between this situation and the Curse of Lisp?  I'm not sure.

There is one each of all of the Clojure contrib libraries 
.  There's a reason that that's a good thing, 
imo.  It's the same reason that there's usually only one of each core 
function in Clojure, and that similar functions usually have similar syntax 
(can't assume this in Common Lisp), although other people can define 
alternative functions, or build Scheme syntax into Clojure, or whatever one 
wants.  That there's a standard set of contrib libraries doesn't mean that 
there can't be competing libraries or competition for core functions, and 
there are in some cases.  (I would never use clojure.core/rand except for 
little experiments.)  If it works for people to have multiple React 
wrappers, etc., yeah, why not?  These competing tools have different costs 
and benefits--not just in efficiency in different contexts, but in how one 
goes about structuring one's code.  Given that, there would be no sense to 
having a single-line switch between competing libraries.  Matrix operations 
seem different, though.  Every matrix library will share a lot of 
functionality with any other, because they're intended to implement the 
same standard mathematical abstractions.  They will have different 
functionality in some places, of course, but on the shared functionality, 
the difference will only be in which library is more efficient for which 
kinds of operations with what kind of data, what systems they'll run on, 
etc.) There are not that many different fundamental operations that one can 
want with matrices.  I don't care whether adding a constant to a matrix is 
written as '(add m c)` or '(add c m)' or '(sum m c)', etc.  I want an API 
that's sensible and not foolish, and I prefer an API that's more sensible 
and more flexible without being more difficult to understand.  Beyond that 
I don't care much about what API I use, except that I don't want to have to 
learn multiple APIs and port my code from one to the other.  My guess is 
that in an alternate universe in which core.matrix had the API that 
Neanderthal has in this universe, I would be equally happy with core.matrix.

(Too bad that the Google Summer of Code deadline is past.  Providing a 
core.matrix interface to Neanderthal would be a great project for someone, 
I bet.)

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

[Mars0i]

Dragan, I still support you doing whatever you want with your time, and I'm 
grateful that you've produced was I gather is a great library.  Wonderful.  
I don't feel that you have to implement the core.matrix api--but I really, 
really wish someone would produce a core.matrix interface to Neanderthal.  
(I don't know how difficult that will be; I just know that I'm not the 
right person to do it.)  

Some of the following has been said before, but some the points below seem 
to have been lost in the current discussion.

I want to try Neanderthal, but I may never do so until someone produces a 
core.matrix mapping.  That needn't be a problem for you, Dragan, but my 
time is too precious to reimplement my existing code for a new api.  Even 
with new code, I'm always going to prefer core.matrix in the foreseeable 
future unless I have very special needs, because being able to swap out 
implementations is just too convenient for me.  core.matrix allows me to 
easily figure out which library is most efficient in my application.  I 
also want there to be a standard api for matrix operations, and at this 
point, core.matrix is the standard imo.  

I came to Clojure from Common Lisp, where there are 5-10 matrix libraries 
with different APIs and different efficiency profiles, several seemingly 
best for different purposes (the Curse of Lisp mentioned by Mikera, applied 
to our case).  I am just very grateful that, instead of CL's mess of 
libraries and APIs, in the Clojure world Mikera and others decided to 
construct a standard API for matrix implementations.  What he's promoting 
is not marketing, nor religion--it's just convenience and coherence.  It's 
part of what Clojure is all about.

Again, Dragan, I certainly don't think that you have to support 
core.matrix, and I am still grateful for Neanderthal even no one ever gives 
it a core.matrix front end.  From my point of view, everyone in the Clojure 
community can be grateful for Neanderthal--even those of us who might never 
end up using it.  It's a good resource for those who know in advance that 
it will be best for their application, or for those with time to benchmark 
their application with variant code.  I personally don't want to negotiate 
different matrix APIs, however.  That's what's important to me.  

I don't have any opinion about the relative benefits of the core.matrix and 
Neanderthal APIs as such.  I just want to write to standard API.  If the 
Neanderthal API became the standard, with multiple back ends, and was 
overall better than core.matrix in that respect, I'd use it.  At this 
point, going that route seems unlikely to be a good option, because 
core.matrix already exists, with a lot of work having gone into it by a 
reasonably large community.  For me the API seems just fine, and it's still 
being enhanced.  (If it can be made better through conversation with you or 
others familiar with Neanderthal, that's even better.)

So ... I understand why Mikera keeps mentioning core.matrix whenever 
Neanderthal is promoted here.  I support him doing that, because I want the 
matrix libraries for Clojure to stay away from the curse of Common Lisp.  I 
also understand why core.matrix isn't important for you, personally.  But 
core.matrix is important for others besides Mikera.  It's not just a pet 
project; it's a Good Thing, because well thought out common APIs for 
libraries with similar functionality is a Good Thing.  I think you probably 
agree, at least *in the abstract,* even if in this particular context you 
don't think that core.matrix is the best API for all matrix applications.  
(Maybe it's not.  Still ... a common API, that's gotta be a good thing.  
And if someone ever does produce a core.matrix interface to Neanderthal, 
the regular Neanderthal interface will still be available, presumably.  
Great!  Best of both worlds.)

I don't think this discussion has to get as heated as it does.  Perhaps 
I'll get some of the heat, now, but it's not necessary, imo.

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

[Mars0i]

You might want to post this on the Numerical clojure group as well or 
instead.  I've never tried using complex numbers with core.matrix.
 

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

[Mars0i]

Just spelling out what the previous comments implied:

You're giving 'if' five arguments:

(= M 0) 
1 
"in case pow is 0 return 1"
(do (* N (recur N (- M 1)
"decrease power M each itr"

'if' needs at least two arguments, and is normally used with three.  If you 
delete the strings, your code will be correct.

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

[Mars0i]

Is the idea that you want a list of very brief definitions, rather than the 
long discussions in the Reference section of clojure.org?  

On Friday, February 19, 2016 at 9:42:56 PM UTC-6, Tianxiang Xiong wrote:
>
> Thanks, but a cheatsheet is not really what I'm looking for. The 
> cheatsheet lists commands grouped by function, which is useful, but I'm 
> looking for rigorous, precise definitions of terms like "var" and 
> "identity".
>
>

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

[Mars0i]

Yes, that looks like a bug.  If you try it with ndarray, you get the 
results I would expect:

=> (def t (mx/array :ndarray [[10][20]]))
=> t
#object[clojure.core.matrix.impl.ndarray_object.NDArray 0x40514dab "[[10] 
[20]]"]

=> (pm t)
[[10.000]
 [20.000]]

=> (pm (emap / t 10))
[[1.000]
 [2.000]]]

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

[Mars0i]

https://github.com/clojure/math.numeric-tower:

   - 
   
   (expt x y) - x to the yth power
   

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

[Mars0i]

Thanks jjttjj, Magomimmo.  I do prefer reading to videos, but I'll consider 
getting Baldridge's series anyway.  Seems worth it.  I don't mind paying.

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

In search of the little transducer

[Mars0i]

Years ago, I learned Common Lisp and Scheme.  I read a number of books that 
explained recursion.  I understood what I read ... but I never really got 
it.  It wasn't a part of me.  Then I worked through *The Little Lisper* 
(renamed *The Little Schemer*), and it became second nature.  Studied ML, 
Haskell, etc.: recursion was easy.

I feel as if I'm in the same position, now, with transducers.  I've read 
Rich Hickey's introductory articles, watched part of a video, read a 
handful of introductory blog posts by others, and I can't say I don't 
understand.  It's not that difficult ... but I don't grok it, really.

I need *The Little Transducer.*

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

[Mars0i]

On Tuesday, January 26, 2016 at 3:51:09 AM UTC-6, icamts wrote:
>
> Are you using the same JVM? It's an optimization introduced at some point 
> in JVM GC. It can be turned off with the JVM flag -XX:-UseGCOverheadLimit. 
> See 
> https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/memleaks002.html
>
>
Yes, all on Java 8.  Thanks.  I thought about using that flag, but wanted 
to get to the bottom of the problem, and have now done so by turning off 
locals clearing.

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

[Mars0i]

On Monday, January 25, 2016 at 9:26:17 AM UTC-6, Alex Miller wrote:
>
> When you disable locals clearing, you will start holding the head of 
> (potentially large) locals everywhere. This is the reason that locals are 
> aggressively called in the first place. This is a typical consequence of 
> disabling locals clearing and the reason why they are cleared by default.
>
> This is a good example of a typical head holding issue:
>
> http://stackoverflow.com/questions/15994316/clojure-head-retention
>

Now that I've had a chance to read this carefully I see that it's not just 
about holding heads, as I thought, but also explains an example of locals 
clearing in the process.  Much clearer to me now--really no pun intended.   
Fascinating.  Thanks.

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

Re: clojure.compiler.disable-locals-clearing memory leak?

[Mars0i]

On Monday, January 25, 2016 at 9:26:17 AM UTC-6, Alex Miller wrote:
>
> When you disable locals clearing, you will start holding the head of 
> (potentially large) locals everywhere. This is the reason that locals are 
> aggressively called in the first place. This is a typical consequence of 
> disabling locals clearing and the reason why they are cleared by default.
>

Got it, thanks.  Makes sense.  So I was just lucky that I didn't experience 
a problem with 1.6.0--maybe because of  the lack of optimizations that were 
introduced in 1.7.0.  Thanks Alex, Ghadi.
 

> This is a good example of a typical head holding issue:
>
> http://stackoverflow.com/questions/15994316/clojure-head-retention
>

I know about head holding in general, and initially spent some time making 
sure I wasn't inadvertently doing that.  The linked example and 
explanations look especially interesting, though--thanks.
 

>
>
> On Monday, January 25, 2016 at 12:49:03 AM UTC-6, Mars0i wrote:
>>
>> In my  application, I seem to get a memory leak when I use 
>> -Dclojure.compiler.disable-locals-clearing=true in Clojure 1.7.0 and 1.8.0, 
>> but not in 1.6.0.  (i.e. I get "java.lang.OutOfMemoryError: GC overhead 
>> limit exceeded" with the more recent versions).
>>
>> Any guesses about why this might happen?  Just curious.  
>>
>> (I think I can live without disabling locals-clearing.  I don't fully 
>> understand it.  Not sure why I started using it.  I don't use a debugger.)
>>
>

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

[Mars0i]

In my  application, I seem to get a memory leak when I use 
-Dclojure.compiler.disable-locals-clearing=true in Clojure 1.7.0 and 1.8.0, 
but not in 1.6.0.  (i.e. I get "java.lang.OutOfMemoryError: GC overhead 
limit exceeded" with the more recent versions).

Any guesses about why this might happen?  Just curious.  

(I think I can live without disabling locals-clearing.  I don't fully 
understand it.  Not sure why I started using it.  I don't use a debugger.)

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

[Mars0i]

There is a text editor written in Clojure: https://github.com/maitria/avi

That's pretty far from an office suite ...

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