Re: [ANN] Discontinuing 4clojure.com

[Colin Fleming]

Thanks for all the work (and money!) that's been spent over the years
maintaining 4clojure, I know it's been much appreciated by many in the
community. Is it possible to provide a data dump of the problem set? As far
as I can tell this data isn't in the Github repo, it seems to be in a Mongo
database somewhere? I for one would appreciate a copy if possible.

Cheers,
Colin


On Sun, 4 Jul 2021 at 20:26, Alan Malloy  wrote:

> TL;DR: Turning off 4clojure.com by the end of July 2021
>
> Hello, 4clojure problem solvers. You've probably noticed SSL errors on
> 4clojure.com over the last week. The old decrepit system 4clojure runs on
> has finally gotten out of date enough that I can't even figure out how to
> get it recent enough that SSL certs will auto-renew anymore.
>
> In principle I could start from scratch on a new server and move 4clojure
> over, but I won't. 4clojure has been piggybacking along on a server that I
> use for personal reasons, and over the years I have less and less reason to
> keep paying for that server - it's now pretty much just 4clojure costing me
> an embarrassing amount of money every month because I haven't wanted to
> disappoint the community by shutting it down. This SSL thing is just what
> made me finally pull the trigger.
>
> I don't have a specific EOL date in mind, but sometime near the end of the
> month, since that's the billing cycle. Until that time, 4clojure still
> works, as long as you don't mind clicking through the security warnings -
> it really is still me hosting the site, and since the connection is still
> HTTPS (albeit with an invalid cert) I think that means your data is still
> safe. If you have solutions to problems you're proud of, you've still got
> some time to print them out and put them up on your refrigerator.
>
> I'm not seeking new maintainers. I'd feel uncomfortable handing over a
> database with so many email addresses and password hashes in it to anyone.
> The service has had a good run - just over a decade since the first
> release
> .
> I hope you enjoyed it during that time.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/385cdef8-fa40-47ba-b5b1-0b3a7cc34935n%40googlegroups.com
> 
> .
>

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

Re: Inside Clojure Journal

[Colin Fleming]

I for one would appreciate it if you fixed it rather than removing it :-)

On Wed, 30 Jan 2019 at 20:07, Alex Miller  wrote:

> That's never actually worked. I keep meaning to remove it. :)
>
> On Wednesday, January 30, 2019 at 1:41:16 PM UTC-6, puzzler wrote:
>>
>> +1.
>>
>> I can't seem to subscribe my email to Alex's blog using the form at the
>> bottom of the blog. Clicking the button does nothing. Anyone else having
>> that problem?
>>
>> On Tue, Jan 29, 2019 at 9:03 PM Shaun Parker 
>> wrote:
>>
>>> I just wanted to say thanks to Alex for taking the time to journal all
>>> the Clojure things he's working on (and the non-Clojure things as well).
>>> They're enjoyable to read and eye-opening. It's a great window into the
>>> effort that he and others are putting into Clojure. It's been fun to follow
>>> the spec-alpha2 commits and get to read the thoughts/direction in the
>>> journal. Great work Alex!
>>>
>>> You can find them on the Inside Clojure blog: http://insideclojure.org/
>>>
>>> Shaun
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Prototype code for enhanced CIDER code completion for Java methods

[Colin Fleming]

>
> I'm curious though, why additional macro / slightly differences from
> "idiomatic" seems so important to avoid.
>

I can think of a couple of reasons off the top of my head:

   1. It won't work with any tooling that's unaware of it, e.g. Cursive.
   2. It's very verbose - it's even worse than Java, because instead of
   annotating each variable once where it's declared you have to annotate
   every method call, and those annotations remain forever in the code, not
   just when you're writing it. This is true even when the type is trivially
   obvious, e.g. (String:charAt "my-string" 0).Modern languages are moving
   towards more sophisticated type inference for a reason - it's much more
   comfortable.

Really, this feature is just to make editors work better. Why not do
something similar to what Cursive does, and allow the user to type
(String:ch|) . Then just show the method completions from String and when
the user selects "charAt" just convert to (.charAt |)? This is really a
feature to aid code writing after all, not reading. Then the feature
wouldn't require macros at all, it could be a purely Emacs thing.

On Wed, 17 Oct 2018 at 11:13, 'somewhat-functional-programmer' via Clojure <
clojure@googlegroups.com> wrote:

> I appreciate your detailed response, and you've certainly done great work
> with Cursive.  I always recommend it to any Java programmer who is starting
> to learn Clojure.  I will start to more seriously weigh the pros and
> consadditional of switching away from emacs.  The cult of emacs has had a
> strong pull on me but your good work may mean I should leave it for Clojure
> work too (and not just for Java work :-)).
>
> Cursive is doing much more in trying to match the Clojure compiler than I
> believe the compliment library has done to date.  Part of me likes the
> readability of the syntax:
> (String:charAt my-string 0)
> over
> (-> ^String my-string (.charAt 0))
> But I realize that is much more subjective than anything else.  I have to
> say, in delving into this even a little -- I appreciate the time you must
> have spent matching the Clojure compiler.  I just remember looking at
> Kawa's syntax for Java method calls and thinking, wow, I wish Clojure had
> that -- so much more readable!
>
> I like your last example a lot:
> (foo .method) => getting turned into (.method foo) automatically by the
> editor.
> I've actually looked at doing a similar thing with my macro -- basically
> using it in my editor, and then adding an nREPL middleware to transform it
> to the much beloved (.method obj args) notation.  Since I subjectively like
> the readability of (String:charAt obj 0) better than (.charAt ^String obj
> 0) I didn't go that route in this discussion.
>
> I'm curious though, why additional macro / slightly differences from
> "idiomatic" seems so important to avoid.  I think something as simple as
> (String:charAt obj 0) notation would be pretty simple for a third syntax
> (since we already have two built in ways of doing it) -- and closer to the
> static method invocation syntax -- so really a third built-in syntax
> (Integer/parseInt "12").  But that's more a philosophical question I
> suppose :-).  LISP curse anyone? :-)
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, October 17, 2018 8:40 AM, Colin Fleming <
> colin.mailingl...@gmail.com> wrote:
>
> Cursive already allows this with no syntax changes, but it does require
> reproducing Clojure's type inference in the editor. Cursive performs this
> type inference, so (modulo bugs) it knows the types of basically everything
> that the Clojure compiler does (and in fact in some situations can do
> better, but I deliberately use just what the compiler knows right now).
>
> This is used in various ways in completion. All of the cases that Aaron
> enumerates above work, since Cursive can correctly propagate the types in
> threading forms/doto etc (| is the caret):
>
> (-> "my-string"
> (.ch|)); <- Only String methods here
>
> (-> (new MyType)
> (.|))  ; <- MyType methods here
>
> (def foo "hello")
>
> (-> ^String foo
> (.to|)); <- String completions here too, because of the type hint.
>;Cursive can do better here even though the Clojure
> compiler doesn't.
>;Currently I restrict this, but completing could e.g.
> automagically insert the type hint.
>
> (let [foo "string"]
>   (-> foo (.to|)) ; <- No type hint required, since we know the type of foo
>
> Additionally, Cursive supports the following:
>
> (let [foo (ArrayList.)
>   iterator (.iterator foo)]
>   (.ne|))  ; <- Here, .next will be off

Re: Prototype code for enhanced CIDER code completion for Java methods

[Colin Fleming]

Cursive already allows this with no syntax changes, but it does require
reproducing Clojure's type inference in the editor. Cursive performs this
type inference, so (modulo bugs) it knows the types of basically everything
that the Clojure compiler does (and in fact in some situations can do
better, but I deliberately use just what the compiler knows right now).

This is used in various ways in completion. All of the cases that Aaron
enumerates above work, since Cursive can correctly propagate the types in
threading forms/doto etc (| is the caret):

(-> "my-string"
(.ch|)); <- Only String methods here

(-> (new MyType)
(.|))  ; <- MyType methods here

(def foo "hello")

(-> ^String foo
(.to|)); <- String completions here too, because of the type hint.
   ;Cursive can do better here even though the Clojure
compiler doesn't.
   ;Currently I restrict this, but completing could e.g.
automagically insert the type hint.

(let [foo "string"]
  (-> foo (.to|)) ; <- No type hint required, since we know the type of foo

Additionally, Cursive supports the following:

(let [foo (ArrayList.)
  iterator (.iterator foo)]
  (.ne|))  ; <- Here, .next will be offered even though Iterator isn't
imported,
   ;because Cursive knows the types we have in scope at the
caret.

(let [foo (ArrayList.)]
  (foo .i|))   ; <- Here, I've put the receiver first, then I'm completing
the method call.
   ;Since Cursive knows the type of foo, only ArrayList
methods will be completed.
   ;When I select a completion, Cursive will swap the two
around, like:
(let [foo (ArrayList.)]
  (.iterator foo|))

I use this last one all the time, and it basically makes Clojure completion
as good as Java completion. Someone pointed out to me that this should
really use the existing dot syntax, like:

(let [foo (ArrayList.)]
  (. foo it|))  ; <- completes to:

(let [foo (ArrayList.)]
  (.iterator foo|))

But I haven't implemented that yet.

I don't do any of the more tricky stuff that IntelliJ does like
transitively searching across chained method calls based on the type, etc,
but that's just a time issue - there's nothing preventing Cursive from
doing that too. Also, offering completions from classes that are not
imported but are in scope makes a huge difference, even without any
switching trickiness.

Cheers,
Colin

On Wed, 17 Oct 2018 at 04:34, Didier  wrote:

> How does the new syntax help the tooling figure out the type?
>
> (def var (SomeType.))
> (.method var)
>
> Or
>
> (jvm (var.method))
>
> I'm not sure how you narrow down to only the SomeType methods?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Clojure 1.10.0-beta1

[Colin Fleming]

>
> I’m not sure a guide is needed for tap - the functions are pretty simple?
>

Personally, I understand the mechanics, but I have no idea how they're
intended to be used. I'd love to see some examples of what they're designed
to do.

On Sat, 6 Oct 2018 at 12:17, Alex Miller  wrote:

>
> > On Oct 6, 2018, at 3:53 AM, Mike <145...@gmail.com> wrote:
> >
> > Cool! Will there be more guides how to use tap and prepl ?
>
> I’m not sure a guide is needed for tap - the functions are pretty simple?
> I’ll think about it.
>
> prepl is designed for tool makers so is probably a limited audience and
> not really a good target for a guide. The docstrings have a lot more detail
> and may lead to some updated reference material.
>
> > Is there any plans to release  clj for windows?
>
> Yes, but I can’t give you a timeframe. Significant work has been done.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Unqualified symbol resolution during evaluation

[Colin Fleming]

Note that the doc on that page says:

Note that class names normally denote class objects, but are treated
> specially in certain special forms, e.g. . and new.
>

Basically, only a class makes sense as the first argument to new, and I
suspect new doesn't use the standard symbol resolution.

On Mon, 20 Aug 2018 at 01:03,  wrote:

> I am trying to follow the rules for unqualified symbol resolution as
> listed at https://clojure.org/reference/evaluation
>
> According to those rules, if my symbol is mapped to a class name in the
> current namespace, then that should override any (hopefully, accidental)
> local bindings of the same symbol. But this does not seem to happen
> reliably in the current version (1.9.0) as shown below. The resolution
> seems to be inconsistent depending on how the symbol is used as you can see
> below.
>
> user=> (clojure-version)
>
> "1.9.0"
>
> user=> (deftype my-t [x])
>
> user.my-t
>
> user=>  ((fn [x]
>
> (let [my-t 1]
>
> (println "Now I resolve to the locally bound my-t =" my-t)
>
> (println "You can even pass me as arguments to functions:" (+ my-t x))
>
> (.-x (new my-t "Funnily enough, now I resolve to the class user.my-t"
> 3)
>
> Now I resolve to the locally bound my-t = 1
> You can even pass me as arguments to functions: 4
> "Funnily enough, now I resolve to the class user.my-t"
>
>
> Surely, such a resolution of a symbol alternatively to a local binding and
> a class name is inconsistent, and makes hard to read as well as being a
> potential source of bugs? Am I wrong to expect an error thrown at least
> when evaluating the expression (+ my-t x)?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] CRNTL: An ANSI C reader for Clojure/EDN content

[Colin Fleming]

That's really taking Friday afternoon commits to the next level!

On 30 June 2018 at 21:42, Edwin Watkeys  wrote:

> Hey all,
>
> Have you ever wanted to read Clojure or EDN without using Clojure(Script)?
> If so, feel free to check out CRNTL (C Reader for the Next Thousand Lisps)
> at:
>
> https://github.com/thunknyc/crntl
>
> CRNTL is a new project and is incomplete, but I hope some will find it
> useful as-is. I wrote it because it irked me that I was using PEG.js inside
> JavaScriptCore to parse the iOS-hosted Lisp we're developing. CRNTL is
> written in ANSI C, has no external dependencies, and is thread-safe i.e. it
> doesn't use any static variables. CRNTL is available under an MIT-style
> license.
>
> Pull requests and new issues are welcome. If you have questions or
> comments, please contact me directly for now; I am about to head out on a
> ~4,500mi (7,200km) motorcycle ride and won't be scanning posts here for a
> few weeks.
>
> Regards,
> Edwin
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] editscript: a diffing library for Clojure data

[Colin Fleming]

This looks very nice, thank you!

On 1 May 2018 at 06:52,  wrote:

> Hello,
>
> I am happy to make available a diffing/patching library for Clojure data
> structures.
>
> https://github.com/juji-io/editscript
>
> Two flavors of diffing algorithms are provided, with very different
> performance characteristics, suitable for different applications.
>
> * One optimizing diffing algorithm aimed to reduce the size of diffs. It
> is an A* based graph search algorithm that is optimized for speed, though
> much slower than the next one, it is still practical.
> * Another is a straightforward tree walking algorithm that is about two
> orders of magnitude faster, but produce suboptimal results.
>
> Hope this library will be of some use for someone. Comments, suggestions
> and contributions are also welcome.
>
> -huahai
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Bazel as Clojure build tool

[Colin Fleming]

>
> Don't wanna start a religious war, but I've worked with Gradle (and about
> 150 other build tools). If Gradle makes you happy Bazel will make you
> rapturous.
>

I need to use Gradle because the IntelliJ plugin development infrastructure
uses it.

That said, I just skimmed that blog post, and they have using Groovy as a
negative, and two project-specific languages I've never heard of as a
positive. I'm unlikely to agree with them on that - IntelliJ has great
Groovy support, and there are a lot of blog posts about any problems I
might come across. Groovy is far from my favourite language, but at least
it's widespread which helps if you don't want to become an expert in it to
just get your job done.


On 15 April 2018 at 20:25, Gregg Reynolds <d...@mobileink.com> wrote:

>
>
> On Tue, Jan 30, 2018, 6:07 PM Colin Fleming <colin.mailingl...@gmail.com>
> wrote:
>
>> Another tool that works well for polyglot JVM projects is Gradle. I use
>> it to build Cursive, which has Java, Kotlin and AOT'ed Clojure. I released
>> a mostly-unsupported plugin for it, and Andrew Oberstar and others have
>> taken it over and done a lot of work on it - it now lives at
>> https://github.com/gradle-clojure. It's pretty new but is under active
>> development.
>>
>> Gradle works very well for Cursive, I'm very happy with it.
>>
>
> Don't wanna start a religious war, but I've worked with Gradle (and about
> 150 other build tools). If Gradle makes you happy Bazel will make you
> rapturous.
>
> See e.g. https://www.google.com/amp/s/www.pgrs.net/2015/09/01/
> migrating-from-gradle-to-bazel/amp/
>
> G
>
>>
>> On 29 January 2018 at 20:07, Nathan Fisher <nfis...@junctionbox.ca>
>> wrote:
>>
>>> Hi Kiril,
>>>
>>> I think you’d need to set your expectations. Faster builds are unlikely
>>> to be one of the benefits. A unified build tool is one.
>>>
>>> I’ve seen a few similar attempts with Buck which was inspired by Bazel.
>>> They either generate lein projects on the fly or call into the Clojure
>>> compiler directly.
>>>
>>> I think Clojure’s build model works against these tools in part because
>>> it’s a dynamic language, in part because it doesn’t implicitly forward
>>> declare functions, in part because (I believe) it does breadth first
>>> traversal if dependencies, and in part it’s non-trivial/inefficient to
>>> create a clean Clojure VM per dependency in the build graph.
>>>
>>> Typical usage of these build tools is to have a build file per directory
>>> with one or more targets in each file. In order to get the speed that the
>>> build tool promises you need the ability to efficiently parse the ABI of
>>> each file and only build its dependents when the ABI has changed.
>>>
>>> I’m not certain you can do that with Clojures compiler but someone else
>>> might be able to chime in with a way that you could.
>>>
>>> Cheers,
>>> Nathan
>>>
>>> On Mon, 29 Jan 2018 at 13:16, Kiril Videlov <kiril...@runbox.no> wrote:
>>>
>>>> Hello,
>>>> I have been looking at the Bazel <https://bazel.build> build tool for
>>>> a multi-language mono-repo and I was wondering if anybody has tried it in
>>>> the context of Clojure projects. I have only found the lein-monolith
>>>> <https://github.com/amperity/lein-monolith/> plugin which appears to
>>>> address a similar use case sans the polyglot requirement. Do you think
>>>> there is any value in attempting to build a rule set
>>>> <https://docs.bazel.build/versions/master/skylark/rules.html> similar
>>>> to the bazel rules for Scala
>>>> <https://github.com/bazelbuild/rules_scala>?
>>>>
>>>> Regards,
>>>> Kiril Videlov
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To post to this group, send email to clojure@googlegroups.com
>>>> Note that posts from new members are moderated - please be patient with
>>>> your first post.
>>>> To unsubscribe from this group, send email to
>>>> clojure+unsubscr...@googlegroups.com
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/clojure?hl=en
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To unsubscribe from this group 

Re: [?] Adding my own function to clojure.core namespace

[Colin Fleming]

On 25 February 2018 at 23:42, Gary Fredericks 
wrote:

> For clojure (not cljs, yet) I proxy all the dev utilities I might want to
> use in a namespace called `.` so I can refer to it everywhere no matter
> what the local namespace setup is: https://github.com/
> gfredericks/dot-slash-2
>

Note that the reader doc (https://clojure.org/reference/reader) says that
"Symbols beginning or ending with '.' are reserved by Clojure". It's not
enforced of course, but it might break things. It might be a good idea to
use some other single char prefix.




> On Sunday, February 25, 2018 at 11:45:41 AM UTC-6, Philos Kim wrote:
>>
>> I have another question. Debux library supports ClojureScript as well.
>> Similarly, I want to add my own function or macro to cljs.core as in
>> Clojure. Can I use the same strategy in ClojureScript as in Clojure if I
>> use it in the  ClojureScript source code, not in REPL?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Bazel as Clojure build tool

[Colin Fleming]

Another tool that works well for polyglot JVM projects is Gradle. I use it
to build Cursive, which has Java, Kotlin and AOT'ed Clojure. I released a
mostly-unsupported plugin for it, and Andrew Oberstar and others have taken
it over and done a lot of work on it - it now lives at
https://github.com/gradle-clojure. It's pretty new but is under active
development.

Gradle works very well for Cursive, I'm very happy with it.

On 29 January 2018 at 20:07, Nathan Fisher  wrote:

> Hi Kiril,
>
> I think you’d need to set your expectations. Faster builds are unlikely to
> be one of the benefits. A unified build tool is one.
>
> I’ve seen a few similar attempts with Buck which was inspired by Bazel.
> They either generate lein projects on the fly or call into the Clojure
> compiler directly.
>
> I think Clojure’s build model works against these tools in part because
> it’s a dynamic language, in part because it doesn’t implicitly forward
> declare functions, in part because (I believe) it does breadth first
> traversal if dependencies, and in part it’s non-trivial/inefficient to
> create a clean Clojure VM per dependency in the build graph.
>
> Typical usage of these build tools is to have a build file per directory
> with one or more targets in each file. In order to get the speed that the
> build tool promises you need the ability to efficiently parse the ABI of
> each file and only build its dependents when the ABI has changed.
>
> I’m not certain you can do that with Clojures compiler but someone else
> might be able to chime in with a way that you could.
>
> Cheers,
> Nathan
>
> On Mon, 29 Jan 2018 at 13:16, Kiril Videlov  wrote:
>
>> Hello,
>> I have been looking at the Bazel  build tool for a
>> multi-language mono-repo and I was wondering if anybody has tried it in the
>> context of Clojure projects. I have only found the lein-monolith
>>  plugin which appears to
>> address a similar use case sans the polyglot requirement. Do you think
>> there is any value in attempting to build a rule set
>>  similar to
>> the bazel rules for Scala ?
>>
>> Regards,
>> Kiril Videlov
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> - sent from my mobile
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Q: How to find out how much Clojure you use

[Colin Fleming]

IntelliJ has a nice Productivity Guide feature which works sort of like
this - every time you use a certain feature it's recorded, and you can see
a table of the various features, how often you used it and when you last
used it. You can click on each feature to see documentation about how it
works. It's really handy - I haven't done this for a while, but I used to
browse all the "Never used" features, find one that looked interesting and
try it out. Something similar for Clojure could be really nice.

On 26 October 2017 at 09:32, Robert Levy  wrote:

> That would be very interesting, especially at an aggregate level, to
> visualize clusters of Clojure sub-idioms (?) based on code people have
> publicly shared with their name attached.  One way to get going with that
> quickly would be write some Clojure code to collect, index, and analyze the
> data in Elasticsearch so that you could use the various readymade
> visualization tools that come with Kibana for "dashboards".  For one thing
> you could look at geographical patterns, to see if that's even a thing. :)
> And results over time, to see for example patterns of adoption.  Do people
> still use refs and agents?  Does anyone really use transducers? ;) I am
> curious to see the results if someone does this. It would be a good project
> short enough for a Clojure meetup probably, given some preparation.
>
> On Tue, Oct 24, 2017 at 11:24 PM, Andy Marks  wrote:
>
>> It seems like everytime I watch another Clojure/Conj video or finish
>> another 4Clojure problem, I learn about another piece of the Clojure core
>> set of functions that I was unfamiliar with... which prompted the question:
>>
>> *What subset of the Clojure core API do I use?  Which functions are my
>> favourites?  Which have I never used?*
>>
>> Ideally, I would like to point a tool at my GitHub account, have it look
>> through all the Clojure code I've written and give me a histogram of my
>> usage of the clojure.core API.
>>
>> My question to you all is: does anyone know of a tool that provides some
>> of this functionality?
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Automatically generate your specs and types

[Colin Fleming]

This looks great! Can this be used to infer macro specs based on examples
of usage?

On 14 October 2017 at 04:30, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:

> Hi,
>
> Happy to announce a new set of tools to *automatically*
> *generate* types and specs for your projects.
>
> *Dependency information:*
> 1. core.typed 
> [org.clojure/core.typed "0.4.2"]
> 2. lein-typed 
> [lein-typed "0.4.2"]
> 3. boot-typedclojure 
>   [org.typedclojure/boot-typedclojure "0.1.0"]
>
> *Tutorial:*
> Here's how to try it out (for Lein projects using clojure.test):
>
> 1. Add {:user {:plugins [[lein-typed "0.4.2"]]}} to your
> ~/.lein/profiles.clj
> 2. Add a runtime dependency to [org.clojure/core.typed "0.4.2"] in your
> chosen Lein project.clj
> 3. To infer specs: Run lein typed infer-spec 
> 4. To infer types: Run lein typed infer-type 
>
> WARNING: This tool *rewrites your files*. Only try with backed up code.
>
> *Some examples:*
> *clj-time:*
> *- *Spec setup
> 
> + spec results
> 
> - Types setup
> 
> + types results
> 
>
> *cheshire*
> *- *Spec setup
> 
> + spec results
> 
> - Types setup
> 
> + types results
> 
>
> (Note: use the latest core.typed versions to reproduce on your machines)
>
> *Hints:*
> This tool instruments your namespace and runs your test suite. This
> can be expensive. Try these options:
>
> *   Choose lein test selectors (here: [:integration :generative]
> selectors)*
>   lein typed infer-spec  :test-selectors "[:integration
> :generative]"
>
> *   Timeout individual tests (1000ms timeout)*
>   lein typed infer-spec  :test-timeout-ms 1000
>
> If annotation generation hangs, try these options:
>
> *   Disable recursive type inference*
>   lein typed infer-spec  :infer-opts "{:no-squash-vertically
> true}"
>
> If you see "No such namespace: s", try deleting existing automatically
> generated specs/types before regenerating them. (git checkout works well
> here)
>
>
>
> *Reply* with your generated specs & types!
>
> Thanks,
> Ambrose
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Colin Fleming]

The other thing that would be affected is debugging using a bytecode
debugger like Cursive's - that won't work without the debug info in the
bytecode. pack200 is usually something that you'd use for deployment
though, so perhaps this isn't a problem.

On 12 October 2017 at 23:39, Alex Miller  wrote:

> The SourceDebugExtension stuff is used (see JSR-45) to provide source code
> maps from the compiled classes back to the original source files, namely
> the source file name and the source file line numbers. This information
> appears in stack traces. Removing these debug extensions means you won't
> have source file names or line numbers in your stack traces for Clojure. As
> far as I know, there should be effects in how anything actually executes
> though.
>
> On Thursday, October 12, 2017 at 2:18:23 AM UTC-4, Nick Mudge wrote:
>>
>> Recently I needed to run pack200 on the clojure-1.8.0.jar
>>
>> When I did this I got an error that SourceDebugExtension is an unknown
>> class attribute.
>>
>> I got around this problem by removing all the SourceDebugExtension class
>> attributes from clojure-1.8.0.jar.
>>
>> Here are my questions:
>>
>> What is clojure using SourceDebugExtension for?   What are the possible
>> consequences or downsides from removing all the SourceDebugExtension class
>> attributes from clojure-1.8.0.jar?
>>
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] JMH-Clojure: Seamless JMH benchmarking for Clojure

[Colin Fleming]

This looks really fantastic - thank you! I've used JMH recently and it's
definitely awkward to use - I'll use this next time for sure.

On 29 September 2017 at 09:24,  wrote:

> A data-oriented API to JMH
> , the Java
> Microbenchmark Harness.
>
> Much more information is available at the github page:
> https://github.com/jgpc42/jmh-clojure
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Is it wrong that I'm thinking about this?

[Colin Fleming]

I'm pretty sure you can't use a bare colon - Clojure will attempt to read
it as a keyword and will fail since there's nothing following. :- is just a
normal keyword.

I think you can take the minimalist syntax too far, if there were no
separator at all then you'd have to be counting elements to see which was
the type and which was the param. This works for let and other similar
forms, but their elements are generally aligned vertically so it's usually
very clear which is which; this is usually not the case for parameters.

On 25 September 2017 at 18:34, Didier  wrote:

> Agree, but I'm not a huge fan of :- as the syntax. Its fine, but why not
> just colon like in pascal based languages?
> Or even just have the spec follow the arguments and the arg list?
>
> I think for spec, macros of a different name might be best, since I think
> its not useful to have fns that don't have all its args specced and its
> return argument specced.
> So I think it would make more sense to choose to either spec fully or not.
> Only the fn-spec should be optional.
> If you do so, then you can use generative testing and instrumentation, and
> maybe even run spectrum static checks.
>
> My 2 cents.
>
> On Sunday, 24 September 2017 10:34:22 UTC-7, Tommi Reiman wrote:
>>
>> Would also love to see the spec-aware fn, def, defn and defrecord utils
>> somewhere. One thing I like most about Clojure(Script) is it's conciseness
>> and Schema provided just that with it's schema-aware def(n)s & the plumbing
>> defnk. The current fdef seems good for libraries, but feels noisy for
>> apps.
>>
>> Some related links:
>>
>> - https://github.com/plumatic/schema#beyond-type-hints
>> - https://github.com/gfredericks/schpec/blob/master/src/com/
>> gfredericks/schpec/defn%2Bspec.clj
>> - https://github.com/plumatic/schema/issues/366
>> - https://github.com/metosin/spec-tools/issues/72
>>
>> Hopefully there will be one good solution for this, for tools like
>> Cursive to do static analysis on (as it does with the Schema syntax). Not
>> sure if anyone is working on the spec-tools issue right now, looking
>> forward to the Orchestra implementation.
>>
>> Meanwhile: https://www.typescriptlang.org/docs/handbook/typescript-in-
>> 5-minutes.html
>>
>> lauantai 23. syyskuuta 2017 21.42.13 UTC+3 Jeaye kirjoitti:
>>>
>>> Last I checked, on our Clojure back-end, instrumentation was taking up
>>> 2% of our total test running time. This is with jdbc's instrumentation
>>> disabled though; I think it's significantly slower due to its extensive
>>> usage of s/or s/alt and spec regexes. Our specs are almost entirely s/keys
>>> and clojure.core predicates.
>>>
>>> Our fn spec coverage is 47% on the back-end. So the performance impact
>>> of instrumentation really hasn't been a concern.
>>>
>>> On Fri, Sep 22, 2017 at 10:18:52PM -0700, Didier wrote:
>>> > > The goal is to add the macro to orchestra, as a tool to help
>>> encourage spec'ing all functions.
>>> >
>>> > That would be great. My macro for now was also not supporting all defn
>>> cases yet. And it automatically instruments the fn with orchestra. So if
>>> orchestra had a more complete one defacto, I wouldn't need one.
>>> >
>>> > For performance, I've been thinking that caching validation (with some
>>> configurable cache bounds), or having sample based validation, so
>>> validating only a percentage of calls, and maybe even having the sampling
>>> rate controlled by execution time metrics, or cpu metrics or call rates,
>>> etc. would be interesting possibilities. So in prod, you could tweek the
>>> validation to only get as much of it as you can afford.
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> > Groups "Clojure" group.
>>> > To post to this group, send email to clo...@googlegroups.com
>>> > Note that posts from new members are moderated - please be patient
>>> with your first post.
>>> > To unsubscribe from this group, send email to
>>> > clojure+u...@googlegroups.com
>>> > For more options, visit this group at
>>> > http://groups.google.com/group/clojure?hl=en
>>> > ---
>>> > You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@googlegroups.com.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving 

Re: Writing an Android application with Clojure

[Colin Fleming]

Kotlin offers a lot more than just less verbose code and fixing quirks.
It's a sufficiently large step up over Java that the experience of using it
is completely different, in my experience. The null-safe type system is
worth the price of entry alone. I totally recommend it for Android projects.

Sometimes a language offers a combination of existing concepts in a
coherent package which is somehow greater than the sum of its parts -
languages don't have to be innovative to be useful, pleasant and powerful.
Clojure itself is such a language. We already had good lisps. We already
had good JVM functional languages. We already had languages with persistent
data structures. We already had languages with STM, good concurrency
support, interactive development and all the rest of it. But the pragmatic
combination of those features made (and continues to make) it very
compelling.

Kotlin is another such language. I think there's a strong case to be made
for using React Native for mobile dev, and ClojureScript's story is very
good there. But personally I think you'd be nuts to choose JVM Clojure over
Kotlin for serious Android development.

On 6 September 2017 at 07:04, Didier  wrote:

> ​I know Java and C++. A long time ago I worked with Pascal.
>>
>> What I like about Kotlin is that it is less verbose. And Clojure is
>> of-course even less verbose. :-D
>>
>
> Oh yea, and Kotlin exists pretty much only to address Java's verbosity,
> and maybe a few small other quirks, and it did a great job at that. But you
> won't learn anything new conceptually. All you will learn is a new less
> verbose syntax for the same concepts. I honestly just hope Kotlin pushes
> future Java versions to improve on their verbosity and quirks, so that we
> don't need Kotlin in the future, but Java is not a pain to use anymore. I
> like Kotlin, but its also dumb to have a whole new JVM language works the
> same conceptually, just because Java never bothered improving on its quirks
> and verbosity.
>
> On Tuesday, 5 September 2017 04:14:33 UTC-7, Cecil Westerhof wrote:
>>
>> 2017-09-03 20:23 GMT+02:00 Didier :
>>
>>> Kotlin is actually officialy supported on Android, so definitly a good
>>> choice there.
>>
>>
>> ​I started with Kotlin. I think I first learn to write some applications
>> for Android and then decide if I want to switch to Clojure(Script).
>>
>> ​
>>
>>
>>> That said, if you know Java, C#, C++, Pascal, or even ActionScript 3,
>>> Kotlin brings nothing new to the table conceptually. It does improve on
>>> convenience over Java though.
>>
>>
>> ​I know Java and C++. A long time ago I worked with Pascal.
>>
>> What I like about Kotlin is that it is less verbose. And Clojure is
>> of-course even less verbose. :-D
>>
>> --
>> Cecil Westerhof
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Clojure 1.9.0-alpha18

[Colin Fleming]

>
> Tighten autoresolved keywords and autoresolved namespace map syntax to
> support *only* aliases, as originally intended


What does this mean? Is there a JIRA discussion about this?

On 24 August 2017 at 04:03, Alex Miller  wrote:

> Clojure 1.9.0-alpha18 is now available.
>
> Try it via
>
> - Download: https://repo1.maven.org/maven2/org/clojure/
> clojure/1.9.0-alpha18
> - Leiningen: [org.clojure/clojure "1.9.0-alpha18"]
>
> 1.9.0-alpha18 includes the following changes since 1.9.0-alpha17:
>
> - Can now bind *reader-resolver* to an impl of LispReader$Resolver to
> control the reader's use of namespace interactions when resolving
> autoresolved keywords and maps.
> - Tighten autoresolved keywords and autoresolved namespace map syntax to
> support *only* aliases, as originally intended
> - Updated to use core.specs.alpha 0.1.24
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Insn: Functional JVM bytecode generation for Clojure.

[Colin Fleming]

This looks very interesting. How would you compare this to Mage for the
CLR? Are they essentially equivalent?

On 19 August 2017 at 11:49,  wrote:

> Insn is a data-oriented API to the ASM  JVM bytecode
> generation library. It also provides additional utilities like generating
> Clojure fns built from bytecode.
>
> Much more information is available at the github page:
> https://github.com/jgpc42/insn
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: CHAMP an improvement on HAMT?

[Colin Fleming]

Previous discussion from Zach Tellman about his CHAMP implementation
(bifurcan): https://groups.google.com/d/topic/clojure/1m_I7IrDGb0/discussion

It seems that Clojure's hashing and in particular equality semantics are
relatively expensive, and this accounts for most of the performance
difference. Zach's implementation does offer some advantages (faster
iteration, lower memory usage and some improved operations specific to each
data structure) but if you're stuck with Clojure's hashing and equality the
gains are not as significant.

On 15 August 2017 at 03:23, Timothy Baldridge  wrote:

> It came up today in the Clojurian's Slack mailing list, and it sounds like
> the gist is that the papers did a bit of a apples-to-oranges comparison by
> using a different hashing algorithm when comparing CHAMP to Clojure's
> hashmaps. Once this difference is rectified the performance improvements
> are much smaller, if they exist at all. Apparently CHAMP uses less memory,
> and that might be a reason to switch, but I think the efforts to integrate
> CHAMP mostly died when the fixed benchmarks failed to show significant
> performance gains.
>
> On Mon, Aug 14, 2017 at 3:00 AM, Didier  wrote:
>
>> I think that paper is from 2015. Curious to hear what are people's
>> thoughts as to why it didn't replace Clojure's HAMT. I wouldn't mind a free
>> 3x performance boost and a reduced memory footprint. Is it just a matter of
>> didn't have someone doing the work, or did it turn out that there was
>> issues with CHAMP that would prevent Clojure's default core data structures
>> from being migrated to it?
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> “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.
>

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

Re: Reducing Jar file size for AWS Lambda

[Colin Fleming]

portkey looks great, I wasn't aware of that - thanks!

On 23 July 2017 at 20:35, Kimmo Koskinen  wrote:

> Hi!
>
> Although still at early stages, check out portkey
> https://github.com/cgrand/portkey.
>
> Portkey does tree-shaking by starting from a closure to minimize resulting
> jar size. Uses kryo and implementation of var tracing started in powderkeg
> project (https://github.com/HCADatalab/powderkeg)
> .
>
> pk/deploy can lift (an anonymous) function with [in out ctx] args as a
> Lambda function. pk/mount can expose a defn through API gateway with query
> params mapped to function arguments.
>
> Christophe Grand and I have been working on portkey for now, but we'd
> welcome additional help on making it more awesome :)
>
> - Kimmo
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Migrating nREPL out of Clojure Contrib

[Colin Fleming]

>
> Are you saying the contrib process is deliberatly made to be difficult for
> the community to contribute to it?


No, not at all, just that it's deliberately designed to be exactly the way
it is, so dedicating a lot of time to trying to change that is likely to be
frustrating and fruitless.

I agree about the confusion of a lot of the contrib projects, I'm often
unsure if they're abandoned or just mature. I don't know if the expectation
or the reality is that they should all be in a working state.

On 23 July 2017 at 09:17, Didier  wrote:

> > The contrib process is in place because some want it that way - it's
> very deliberately by design and AFAICT unlikely to change.
>
> Are you saying the contrib process is deliberatly made to be difficult for
> the community to contribute to it?
>
> If so, maybe if it had more obvious tenets, I find its difficult as a user
> to understand what the contribs are for, who maintains them, what their
> status are, and how they differ to the standards library, or other
> community projects.
>
> I can't contribute to OSS, because of my current employment, but as a non
> contributing Clojure user, I've always wondered how much I should rely on
> contribs, some of them seem quasi-abandonned, yet they appear more
> official, and it makes it hard for me to decide if I want to take a
> dependency on them or not.
>
> In a way, an active project gives me more trust, and if taking nRepl out
> of contrib makes it more active, that's a good thing. Unless contrib libs
> come with any official support guarantees, or some form of stronger
> commitments?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Migrating nREPL out of Clojure Contrib

[Colin Fleming]

>
> I'd much rather see nREPL stay within contrib and the renewed effort, that
> you propose, to go into ironing out kinks in the contrib process


FWIW I don't think this is a realistic option, certainly not for anyone
outside of Clojure core. The contrib process is in place because some want
it that way - it's very deliberately by design and AFAICT unlikely to
change. For projects where the maintainer for whatever reason doesn't want
to use that process (I believe nREPL would be the first, but I don't know
all the history) I think moving that project out of contrib is likely to
mean the least amount of frustration.

On 22 July 2017 at 00:15, Herwig Hochleitner  wrote:

> 2017-07-18 14:48 GMT+02:00 Chas Emerick :
> > I would like to hear here (no more private mails, please! :-) from any
> nREPL users, contributors, etc. As much as possible, I would like not to
> debate/re-litigate the merits of contrib and its process here; let's focus
> on what steps will yield the best outcome for nREPL and its stakeholders.
>
> I only have a stake as a user (unfortunately), but FWIW, I'd much rather
> see nREPL stay within contrib and the renewed effort, that you propose, to
> go into ironing out kinks in the contrib process (e.g. for one-off
> contributions, the assignment could go into the commit message, maybe?;
> also our atlassian versions could do with an update; also, it would be
> _really_ nice, if patches could be discussed/accepted on the [dev-] mailing
> list, LKML style)
>
> I realize, that this is effectively asking Chas to roll the boulder up the
> hill, yet another time, but my reason is simple:
> For infrastructure, free market principles don't easily apply: People
> generally fix roads instead of adding new ones in parallel to existing
> ones, and if there ever is an "infrastructurey" clojure library, it would
> be tools.nrepl. Also, like Sean Corfield, I have my reservations about the
> potential for contribution increases due to a reboot.
> To me the risks of a reboot far outweigh the potential benefits.
>
> That said, Chas and Bozhidar, as the largest stakeholders, both seem to be
> in favor of a reboot, hence I wouldn't veto it even if I could.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Migrating nREPL out of Clojure Contrib

[Colin Fleming]

I don't have much more to add than what others have written - I don't have
very strong feelings about this, but it seems worth fixing if the contrib
process is a significant barrier to contribution. And if that happens, I
agree with Chas that it seems worth taking the time to reboot it properly,
since having the CA in the project's history will probably confuse
potential contributors who care about that sort of thing.

In general, I've never had the need to submit patches for nREPL since it's
been stable since I started using it seriously. That's only for Clojure
though, I believe there's some serious work that could be done on the
ClojureScript side and IIRC that was a source of some frustration for some
users a while back. I'd be very happy to see that progressing!

There are also potential issues with API compatibility going forward, but I
don't see those as particularly more difficult than if nREPL continues to
evolve under the contrib umbrella. I also suspect that there's probably not
too much risk of the community fragmenting - you'd only have to convince
less than half a dozen nREPL clients to switch and you'd get essentially
the whole community moving, I expect. As long as the wire protocol doesn't
change during that transition I don't see why that would be too painful.

Cheers,
Colin

On 19 July 2017 at 12:09, Chas Emerick  wrote:

> Of course, my aim would be to gather as much consensus as possible around
> a single nREPL vector; this thread is the first effort in service of that,
> with presumably much more ahead. An obvious move for example would be to
> shim out the legacy namespaces until a major version number change, so that
> migrating would involve only swapping some project.clj/pom.xml
> coordinateswhere things go from there would be as much up to the
> community as anything else.
>
> - Chas
>
> On 7/18/2017 17:30, Phil Hagelberg wrote:
>
> Thanks for continuing to maintain this lib, Chas; I'm glad to see this
> move to make it more accessible to potential contributors.
>
> I believe the original choice of the EPL was made specifically to support
> this kind of scenario. Personally I see a reboot as being a lot of effort
> for little gain, but then again it's neither my effort going into it nor my
> gain coming out of it. Besides, everyone's doing reboots these days.
>
> I do suspect that a reboot will lead to a longer transition time in which
> both org.clojure/tools.nrepl and com.cemerick/nrepl are in active use by
> greenfield projects, so perhaps if you do a reboot you could cut an 0.2.12
> release under the new group-id which has a stable known-good version and
> then do the reboot under a 1.x series or something. This might help
> alleviate the concerns raised by Colin more quickly.
>
> -Phil
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/6SX7q39lK90/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: slackpocalypse?

[Colin Fleming]

On 24 May 2017 at 00:13, Herwig Hochleitner  wrote:

> I doubt the whole community would want to move anywhere from Slack.
>

Perhaps this will have to wait until Slack inevitably throws us off, then.

What would you need to solve your discoverability issues (a)? Isn't it as
> easy as handing out a link like https://riot.im/app/#/
> room/#clojure-community:matrix.org ? Not even registration needed.
>

It's a far cry from searching for "cursive" from anywhere in Clojurians,
though. Searching for channels based on some vague criteria seemed
difficult, and searching for Clojure related content across channels is
also a pretty bad experience. There has been some talk of making a
Clojure-related room directory in an external webpage or something but it's
still a kludge. I'm not sure to what extent this would be fixed if we ran
our own room server, but then someone has to maintain 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.
>

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

[Colin Fleming]

There's been a lot of discussion around this, there's a page about the
possibility of moving to Matrix here:
https://hackpad.com/The-case-for-Matrix-xRXYSO9zpyh. While it has some nice
properties (decentralised, open, can be encrypted etc) it comes at a
serious usability cost. I doubt the whole community would want to move
there from Slack.

Personally I'd prefer Discord, since I use these things for support and my
main requirements are that a) people can find me easily, b) everything
works with no hassle and c) old conversations don't disappear. Matrix fails
pretty badly on a), is ok with some serious usability issues on b) and is
ok for c), modulo that searching is a pain (can either search a single room
or all rooms, not all Clojure-related ones).

Really, my only actual problem with Slack is the disappearing messages, but
that is bad enough that I definitely think we should move. I vote Discord.

On 23 May 2017 at 19:40, Herwig Hochleitner  wrote:

> 2017-05-22 15:50 GMT+02:00 Gregg Reynolds :
>
>>
>> Took a closer look - now I remember where I saw matrix before, they
>> participate in tadhacks .  It's not really an
>> app, much more ambitious than that.  Definitely deserves a closer look.
>>
>
> Yes, it's a decentralized persistent chat protocol with bridging between
> silos in mind. This current talk does a pretty good job of explaining it:
> https://ftp.heanet.ie/mirrors/fosdem-video/2017/
> Janson/encrypting_matrix.mp4
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] huffman-keybindings 0.0.1

[Colin Fleming]

Hi Edouard,

This library is indeed interesting.

However one comment (without wanting to derail the conversation from the
library itself) - the use of AGPL is likely problematic since Clojure and
the majority of the libraries available for it use the EPL. See here
 and
elsewhere in the archives of this list for tons of discussion around this.

Cheers,
Colin

On 9 May 2017 at 11:32, Daniel Compton 
wrote:

> Hi Edouard
>
> This is very cool, thanks for sharing!
>
> On Tue, May 9, 2017 at 3:11 AM Edouard KLEIN 
> wrote:
>
>> huffman-keybindings is a small library to balance a 26-ary huffman tree,
>> typically to associate shorter keybindings to the most often used UI
>> components.
>>
>> The code is here https://github.com/edouardklein/huffman-keybindings/
>>
>> This is my first time disclosing clojure code. Any comments or
>> suggestions are welcome.
>>
>> Cheers,
>>
>> Edouard.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
>
> Daniel
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Clojure 1.9 / clojure.spec split

[Colin Fleming]

Doesn't this mean that Clojure and spec will be mutually dependent, i.e. a
dependency cycle? Is that likely to cause problems for any tooling?

On 27 April 2017 at 06:27, Sean Corfield  wrote:

> Whilst this is rather disruptive for current users of clojure.spec, I
> understand and appreciate the goal.
>
>
>
> I hope that the new org.clojure/spec.alpha will be made available for a
> few days ahead of actually removing it from Clojure 1.9 so that those of us
> already using it and doing multi-version against master-SNAPSHOT will have
> a few days to update our code rather than just see our dev builds break and
> get blocked while we’re forced to make this code change?
>
>
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>
>
> On 4/26/17, 8:30 AM, "Alex Miller"  a...@puredanger.com> wrote:
>
>
>
> We are moving spec out of the Clojure repo/artifact and into a library to
> make it easier to evolve spec independently from Clojure. While we consider
> spec to be an essential part of Clojure 1.9, there are a number of design
> concerns to resolve before it can be finalized. This allows us to move
> towards a production Clojure release (1.9) that depends on an alpha version
> of spec. Users can also pick up newer versions of the spec alpha library as
> desired. Additionally, this is a first step towards increased support for
> leveraging dependencies within Clojure.
>
>
>
> We will be creating two new contrib libraries that will contain the
> following (renamed) namespaces:
>
>
>
> *org.clojure/spec.alpha*
> clojure.spec.alpha  (previously clojure.spec)
> clojure.spec.gen.alpha  (previously clojure.spec.gen)
> clojure.spec.test.alpha (previously clojure.spec.test)
>
>
>
> *org.clojure/core.specs.alpha*
> clojure.core.specs.alpha(previously clojure.core.specs)
>
>
>
> In most cases, we expect that users have aliased their reference to the
> spec namespaces and updating to the changed namespaces will only require a
> single change at the point of the require.
>
>
>
> *How will ClojureScript's spec implementation change?*
>
>
>
> ClojureScript will also change namespace names to match Clojure.
> Eventually, the ClojureScript implementation may move out of ClojureScript
> and into the spec.alpha library - this is still under discussion.
>
>
>
> *Why do the libraries and namespaces end in alpha?*
>
>
>
> The "alpha" indicates that the spec API and implementation is still
> subject to change.
>
>
>
> *What will happen when the spec api is no longer considered alpha?*
>
>
>
> At that point we expect to release a non-alpha version of the spec library
> (with non-alpha namespaces). Users may immediately begin to use that
> version of spec along with whatever version of Clojure it depends on.
> Clojure itself will depend on it at some later point. Timing of all these
> actions is TBD.
>
>
>
> *Will the library support Clojure 1.8 or older versions?*
>
>
>
> No. spec uses new functions in Clojure 1.9 and it has never been a goal to
> provide spec for older versions. Rather, we are trying to accelerate the
> release of a stable Clojure 1.9 so that users can migrate forward to a
> stable production release with access to an alpha version of spec, and
> access to ongoing updated versions as they become 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.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the 

Re: Derefs broken after clojure.tools.namespace.repl/refresh

[Colin Fleming]

Yes, that's correct.

On 12 April 2017 at 17:56, Didier  wrote:

> @Colin If I understand correctly, if I buy the personal license I can use
> it for my own commercial projects, but I can also use it at my work, to
> work on their code base, as long as I'm the one using it. Is that correct?
> I probably can't convince work to buy into a bunch of licenses, but I'd
> love to have a debugger availaible to me, to make my life easier.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Derefs broken after clojure.tools.namespace.repl/refresh

[Colin Fleming]

I spoke about it at Clojure/West:
https://www.youtube.com/watch?v=ql77RwhcCK0. I talked there about some of
the limitations, but it works really nicely for the most part.

CIDER actually has a nice debugger these days too. It works in a very
different way, via source instrumentation. It works better for some things,
but the sort of problem from this thread (unexpected exceptions in
multithreaded scenarios) is one of the situations where Cursive's really
shines.


On 12 April 2017 at 13:55, Timothy Baldridge <tbaldri...@gmail.com> wrote:

> Cursive has had a really good debugger for a long time. I don't use it
> much, but when I need it it *just works*.
>
> Timothy
>
> On Tue, Apr 11, 2017 at 7:37 PM, Didier <didi...@gmail.com> wrote:
>
>> A good debugger is indeed extremely useful for Clojure - I use one every
>>> day :-)
>>>
>>
>> Am I living in the past? I thought Clojure didn't have a way to step
>> through code interactively?
>>
>> On Tuesday, 11 April 2017 16:30:14 UTC-7, Colin Fleming wrote:
>>>
>>> A good debugger is indeed extremely useful for Clojure - I use one every
>>> day :-)
>>>
>>> On 12 April 2017 at 05:29, Didier <did...@gmail.com> wrote:
>>>
>>>> Experimentation is good. This is indeed surprising. I think it shows
>>>> that a good debugger would still sometime be useful in Clojure. I can't
>>>> really explain what's happening.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To post to this group, send email to clo...@googlegroups.com
>>>> Note that posts from new members are moderated - please be patient with
>>>> your first post.
>>>> To unsubscribe from this group, send email to
>>>> clojure+u...@googlegroups.com
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/clojure?hl=en
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to clojure+u...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> “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.
>

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

[Colin Fleming]

A good debugger is indeed extremely useful for Clojure - I use one every
day :-)

On 12 April 2017 at 05:29, Didier  wrote:

> Experimentation is good. This is indeed surprising. I think it shows that
> a good debugger would still sometime be useful in Clojure. I can't really
> explain what's happening.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Colin Fleming]

>
> I have longed for a statically compiled language with type inference with
> the simplicity and consistency of Clojure's syntax that also supports
> generative testing and works on the JVM but alas, I have not found one.
> Frege and PureScript both look interesting but I am unsure of Frege's
> longevity and PureScript's performance on the JVM's Javascript
> environment.


Note that both of those options both suffer from very difficult interop -
PureScript will probably not have any at all since it will be expecting to
interop with JS, and Frege has some but it's clunky due to the type system
mismatch.

Personally I long for a Kotlin/Clojure hybrid, to the point that I have
seriously considered trying to build one.

On 8 April 2017 at 14:57, Didier  wrote:

>  | I think you missed my point, which is only "Spec is great as we have
> the power of Clojure" - sure, just don't forget you have the power of
> ANOther language in that language as well.
>
> Hum, I've probably missed your point sorry, I'm still not following.
>
>  | no, this will, or at least should, be caught. 10/0 is not an int, and
> typed "/' would reject 0 as an ill-typed denominator.
>
> In most static type systems this will not be caught, because they don't
> have a fraction type. So this is actually a function that takes two number
> types, and 0 is a number too, so it will type check, but throw an exception
> 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.
>

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

[Colin Fleming]

Ah yes, I remember this now. It seems like this is a fix that would
definitely help, too, since many (most?) people using serious interop will
be type hinting.

On 28 March 2017 at 23:15, Adam Clements  wrote:

> Potentially relevant? I posted a patch two years ago for some static
> initialisers still running in 1.8, not yet merged. It was actually the type
> hints causing the initialisers to be run at compile time
>
> http://dev.clojure.org/jira/browse/CLJ-1714
>
> On Tue, Mar 28, 2017 at 10:21 AM 'Gunnar Völkel' via Clojure <
> clojure@googlegroups.com> wrote:
>
>> The JavaFX workaround consist of creating a javafx.embed.swing.JFXPanel
>> statically in a namespace that is loaded before any other namespace that
>> import problematic JavaFX classes as in [1,2].
>> This initializes the JavaFX platform.
>>
>> [1] https://github.com/halgari/fn-fx/blob/master/src/fn_fx/
>> render_core.clj#L20
>> [2] https://github.com/zilti/clojurefx/blob/master/src/
>> clojurefx/core.clj#L7
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Compiling gen-class runs static initializers: workarounds, solutions?

[Colin Fleming]

I believe this is fixed in Clojure 1.7, see
http://dev.clojure.org/jira/browse/CLJ-1315 for lots of detail.

On 27 March 2017 at 08:51, lonign via Clojure 
wrote:

> Hi David,
>
> It's been a long time, but have you found a solution to this problem? I
> came across a StackOverflow question about a similar problem:
>
> Clojure can't import JavaFX classes with static initializers
> 
> I have a similar problem, but have not been able to solve it using only
> Clojure. I've had to use a workaround of writing the class I want in Java
> and having to import that class. It just makes the project a bit messier.
>
> 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.
>

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

Re: java interop, `(.instanceMember Classname)`

[Colin Fleming]

I commented over there too - I'm still confused.

On 22 March 2017 at 10:59, Alex Miller  wrote:

>
>
> On Tuesday, March 21, 2017 at 11:43:25 AM UTC-5, John Gabriele wrote:
>>
>>
>> Erf. Sorry. I don't think I understand that after all, and as well may
>> have confused java.lang.String and java.lang.Class in my above reply.
>>
>> I also notice now that:
>>
>> user=> (class String)
>> java.lang.Class
>>
>> but
>>
>> user=> (. java.lang.Class getName)
>> CompilerException java.lang.NoSuchFieldException: getName,
>> compiling:(/tmp/form-init2724986764275224936.clj:1:1)
>>
>>
> This is exactly the reason that it's actually a different case. As the
> reference doc says, the equivalent expansion is:
>
> user=> (. (identity Class) getName)
> "java.lang.Class"
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: java interop, `(.instanceMember Classname)`

[Colin Fleming]

Object doesn't have a getName() method.

This doc is confusing - as Phill comments above, this is calling the
getName() method on an instance of Class. In Clojure, a bare classname
(String, ArrayList or whatever) resolves to the class itself if it has been
imported (i.e. what would be String.class in Java). The doc is confusing
because (.instanceMember Classname args*) is really just a special case
of (.instanceMember instance args*), where "instance" refers to an instance
of a Class object. I'm not sure why that doc makes that distinction, it
doesn't seem useful to me.

On 21 March 2017 at 09:49, Gregg Reynolds  wrote:

>
>
> On Mar 20, 2017 3:11 PM, "John Gabriele"  wrote:
>
> On Monday, March 20, 2017 at 4:14:46 AM UTC-4, Matching Socks wrote:
>>
>> Methods having the same name might be distinguished by their argument
>> lists.
>>
>
> Thanks, but it sounds like you're describing method overloading, as in
>
> (.someMethod someObj arg1) ; vs
> (.someMethod someObj arg1 arg2) ; different arity gets different method
>
> whereas I think I'm asking about what the `(.someMethod SomeClass ...)`
> syntax is supposed to mean (where it looks like one is trying to call an
> instance method on a Class (?).
>
>
> String inherits from Object, which has a getName method.
>
> Am I misunderstanding your reply?
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: No :out in my nREPL responses

[Colin Fleming]

Sure, but it might be worth trying the bare nREPL option in Cursive to rule
out something that lein could be doing.

On 18 March 2017 at 21:44, Terje Dahl <te...@terjedahl.no> wrote:

> Hey, Collin.
>
> By "standard" REPL I mean "clojure.main REPL in JVM" - which worked fine.
> I don't think my issue has anything to do with Cursive's way of connecting
> to nREPL, but rather with nREPL itself, seeing as had the same problem in a
> terminal window running `lein repl`.
>
> Terje
>
>
> On Friday, March 17, 2017 at 2:11:11 AM UTC+1, Colin Fleming wrote:
>>
>> Hi Terje,
>>
>> When you say the "standard" REPL in Cursive, are you referring to the
>> "Use nREPL in normal JVM process" option, or the "Use clojure.main in
>> normal JVM process" option? Obviously the first does use nREPL, but doesn't
>> go through lein - Cursive just runs a JVM process, starts a bare-bones
>> nREPL server in it and connects to it. If you haven't tried that option, it
>> might be worth trying to see if the issue is in nREPL or in lein.
>>
>> Cheers,
>> Colin
>>
>> On 17 March 2017 at 11:05, Terje Dahl <te...@terjedahl.no> wrote:
>>
>>> UPDATE:
>>> I only just discovered:
>>> It *does* work as expected when I run it from the "standard" REPL in JVM
>>> (in IntelliJ/Cursive),
>>> And it *does* work as expected when I run it in my own "home grown" REPL
>>> stack.
>>> It does *not* work as expected when running it in any variant of nREPL -
>>> including:
>>>  - Through IntelliJ/Cursive
>>>  - In command-line via `lein repl` (which is simply nREPL)
>>>
>>> So I have a potential solution, (and a possible nREPL bug), but it would
>>> be valuable to understand the cause of the issue.
>>>
>>>
>>>
>>> On Thursday, March 16, 2017 at 10:24:21 PM UTC+1, Terje Dahl wrote:
>>>>
>>>> I am attempting to embed an nREPL server in my application (version
>>>> 0.2.12).  Everything seems to work nicely, except I am not able to get any
>>>> out from print statements et al.  Even the basic example on the README
>>>> "(time (reduce + (range 1e6)))" doesn't work for me: I do not get back the
>>>> map containing the :out, but I get the two remaining.
>>>>
>>>> After two days of studying the source code of tools.nrepl (including
>>>> the testing code),  leiningen.repl, reply, and a myriad of things online, I
>>>> am getting rather frustrated.
>>>>
>>>> It seems to maybe have something to do with *out*, but I can't figure
>>>> it out. Any hints at debugging it will be much appreciated.
>>>>
>>>> Also, any resources for "tool makers" would be of interest.
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Colin Fleming]

Hi Terje,

When you say the "standard" REPL in Cursive, are you referring to the "Use
nREPL in normal JVM process" option, or the "Use clojure.main in normal JVM
process" option? Obviously the first does use nREPL, but doesn't go through
lein - Cursive just runs a JVM process, starts a bare-bones nREPL server in
it and connects to it. If you haven't tried that option, it might be worth
trying to see if the issue is in nREPL or in lein.

Cheers,
Colin

On 17 March 2017 at 11:05, Terje Dahl  wrote:

> UPDATE:
> I only just discovered:
> It *does* work as expected when I run it from the "standard" REPL in JVM
> (in IntelliJ/Cursive),
> And it *does* work as expected when I run it in my own "home grown" REPL
> stack.
> It does *not* work as expected when running it in any variant of nREPL -
> including:
>  - Through IntelliJ/Cursive
>  - In command-line via `lein repl` (which is simply nREPL)
>
> So I have a potential solution, (and a possible nREPL bug), but it would
> be valuable to understand the cause of the issue.
>
>
>
> On Thursday, March 16, 2017 at 10:24:21 PM UTC+1, Terje Dahl wrote:
>>
>> I am attempting to embed an nREPL server in my application (version
>> 0.2.12).  Everything seems to work nicely, except I am not able to get any
>> out from print statements et al.  Even the basic example on the README
>> "(time (reduce + (range 1e6)))" doesn't work for me: I do not get back the
>> map containing the :out, but I get the two remaining.
>>
>> After two days of studying the source code of tools.nrepl (including the
>> testing code),  leiningen.repl, reply, and a myriad of things online, I am
>> getting rather frustrated.
>>
>> It seems to maybe have something to do with *out*, but I can't figure it
>> out. Any hints at debugging it will be much appreciated.
>>
>> Also, any resources for "tool makers" would be of interest.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: ANN: ClojureScript 1.9.456, Externs Inference & Comprehensive JS Modules Support

[Colin Fleming]

I believe that dependency is because Google Closure requires it.

On 9 March 2017 at 16:45, Mike Rodriguez  wrote:

> Guava is often a dependency conflict when trying to put libs together that
> use it. I'm surprised cljs has dependencies like this. I'd think a language
> would try to avoid having any deps at all or repackage them or something.
> For example, Clojure only has ASM.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

FYI: Eclipse Aether moved to Apache Maven

[Colin Fleming]

Hi all,

I just saw a notice about this on the Aether mailing list today, and it
potentially affects some of us building tooling (especially
Leiningen/boot/pomegranate etc). Aether has been developed under the
Eclipse umbrella until recently, but as far as I could tell had been almost
totally abandoned there. It's just been switched over to being managed
under Apache Maven. Its new site is at https://maven.apache.org/resolver,
and the mailing lists are us...@maven.apache.org and d...@maven.apache.org.
I hope this will lead to it being more actively maintained.

Cheers,
Colin

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

[Colin Fleming]

I'm actually planning to do exactly that in Cursive, and it's more or less
what Eastwood does too per the link Ben posted.

On 4 February 2017 at 14:23, Linus Ericsson 
wrote:

> It would be great if an editor highlighted a (possibly qualified) keyword
> that was used only in that particular place (given all code loaded). This
> wouldn't be bullet-proof, but would have highlighted mistakes like
> :encypted (but could still confuse :encrypted? with :encrypted, and
> whatnot).
>
> /Linus
>
> On Friday, February 3, 2017 at 1:49:20 AM UTC+1, tbc++ wrote:
>>
>> A good editor should auto-complete your keywords for you. Since using
>> this feature in Cursive (same sort of thing is available in other editors)
>> the cases where I've mis-spelled a keyword have dropped dramatically. It's
>> a lot harder to mis-spell a keyword when you can just do: :egg/th
>> and the rest is auto-filled.
>>
>> On Thu, Feb 2, 2017 at 5:37 PM, Alex Miller  wrote:
>>
>>> Ugh, don't do that. Introducing layers that add no value is a bad idea.
>>> Just use the keyword directly.
>>>
>>> --
>>> 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.
>

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

[Colin Fleming]

As a counterpoint to this, note that ClojureScript does the same thing (for
different reasons, but the same mechanism):

https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/core.cljc#L91-L101


On 1 January 2017 at 05:24, Timothy Baldridge  wrote:

> Be really careful with Potemkin. I've had a lot of build issues
> (especially around AOT) with that library. I'll try to put this as kindly
> as I can...it's a bit of a hack that leverages some undocumented aspects of
> the Clojure API. As such it's been the source of some really weird compile
> errors that have taken me many hours to debug. So much so that some
> libraries have go so far as to copy-paste certain files from potemkin
> (macros around map-like type creation), in order not to get the more
> fragile parts of the library (var reorganization).
>
> In short...the language wasn't designed to do what Potemkin tries to make
> it do when it comes to vars. I really recommend against using the library.
>
> On Sat, Dec 31, 2016 at 7:32 AM, squeegee  wrote:
>
>>
>>
>> On Friday, December 30, 2016 at 8:59:46 PM UTC-5, puzzler wrote:
>>>
>>> On Fri, Dec 30, 2016 at 4:55 PM, Timothy Baldridge 
>>> wrote:
>>>
 I can see that, and even spec has this use case. In Spec it's solved by
 having both A and B in one namespace and using declare to forward-declare
 the constructors (or defns in this case).

 So I guess the way I see it the tradeoff is a declare and
 all-in-one-namespace vs a massive complexity addition to the compiler and
 the redefinition of compilation units. The declare method seems like the
 cleaner route.


>>> 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.
>>>
>>
>> The macros defined in ‘scarlett.core’ here: https://github.com/scgil
>> ardi/scarlett are an experiment along those lines.
>>
>> *scarlett*
>>
>> Provides macros to declare vars in namespaces other than *ns*
>>
>> To be used sparingly to overcome otherwise cyclic namespace dependencies
>>
>> *Usage*
>>
>>   (ns-declare my-module startup shutdown)
>>
>> declares my-module/startup and my-module/shutdown
>>
>>   (declare+ module-a/startup module-b/startup)
>>
>> declares module-a/startup and module-b/startup
>>
>>
>> They work by using “declare” after switching to the target namespace
>> using “in-ns” (and switching back at the end). They have to be issued at
>> the “top level” (as is highly recommended for ns, declare, def, etc.) to be
>> effective and they contain code to notify with an exception if they are
>> used at other than the top level. (The exception is preferable to silent
>> failure or a confusing error message.)
>>
>>
>> The macros rely on the compiler behavior of handling top-level “do” forms
>> in a special way: evaluating each of the contained forms sequentially *at
>> the top level*, effectively removing the nesting and allowing each
>> contained form to be compiled and evaluated before compiling the next one.
>> Macro expansion facilities other than the compiler (e.g., in an editor or
>> debugger) may not duplicate that subtle behavior so the expansions they
>> produce may not accurately reflect the expansion that will be produced and
>> seen by the compiler. There may be contexts where that causes trouble at
>> development time.
>>
>>
>> I’m not aware of these being used anywhere in other than experimental/POC
>> code.
>>
>>
>> —Steve
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> “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 

Re: Kotlin null-safety in Clojure?

[Colin Fleming]

I wrote about this a bit on the ML recently:
https://groups.google.com/d/msg/clojure/Dxk-rCVL5Ss/NqF-Na9ABQAJ

TL;DR - you really need types for this, and it's very difficult to add
types to a Clojure-like language without losing what makes it Clojure. In
particular, if you want to maintain Java interop then the type system
becomes very, very complex.

I'm in a similar boat - I would trade types, spec etc for just the
null-safety feature. The only way I could think of to create essentially a
two-type system (nullable and non-nullable) would be using a naming
convention - var% accepts nulls and var doesn't or something like that. But
you still need to know which functions can return null and so on, you'd
need to use a similar :key/:key% convention for map access - it's far from
trivial, and I haven't thought it through properly.

One thing I'm becoming increasingly convinced of - my null problems aren't
due to interop. I've paid attention to the last couple of NPEs I've fixed,
and they're generally just common or garden bugs that types would catch.
Cursive is probably unusual in the large input space it deals with (all
code that anyone might write anywhere, in any state of brokenness while the
user is editing) and the code is very complex - that seems to be what
provokes the bugs.

On 31 December 2016 at 12:19, James Reeves  wrote:

> Well, if you use Typed Clojure you get static null checking. Clojure spec
> can give you dynamic null checking you can turn on during development and
> turn off during production. There's also Spectrum, which statically checks
> Clojure spec, but obviously it can't handle all eventualities.
>
> - James
>
>
>
> On 30 Dec 2016 8:53 p.m., "gvim"  wrote:
>
> On 30/12/2016 19:19, James Reeves wrote:
>
>> Well, Kotlin is statically typed, and Clojure is dynamically typed. Null
>> checking on dynamically typed languages is hard (impossible?) to achieve
>> without impacting performance.
>>
>> - James
>>
>>
> Personally, I'd trade the whole of clojure.spec & core.typed for this
> feature of Kotlin.
>
>
> gvim
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] An exploration of Hash Array Mapped Tries

[Colin Fleming]

Hi Ambrose,

This looks very interesting, and I look forward to investigating it further
when I have a moment.

Once comment on the defrecords generated at runtime based on small keysets
- I'd be very careful with this sort of optimisation, and it needs much
more than micro-benchmarks to establish whether it's really a win or not. A
recent similar change that was proposed for Clojure was Zach Tellman's
unrolled small collections (see CLJ-1517
, in particular see Rich's
comment here
).
Essentially, the JVM optimises call sites speculatively. Per call site, if
you only see a single implementation of the interface you're calling, the
site is monomorphic and very highly optimised. If two implementations are
seen, the site is bimorphic, and optimised but not as highly. If more than
two implementations are seen, the call site is considered megamorphic and
is optimised poorly. Additionally, the optimisations that are applied can
depend on the order in which the different implementations are seen, which
can produce extremely unpredictable performance.

There's a very interesting issue
 on the Google Guava tracker
with tons of really interesting detail by people who know way more about
this than I do. It's highly recommended. The tl;dr is that your benchmarks
must mix collection types to measure benefit, and that those benchmarks are
extremely difficult to relate to real-world use.

Since reading all that, I've often wondered how much Clojure's
PersistentArrayMap might affect performance since it will probably cause
many call sites to be bimorphic rather than monomorphic. I could imagine it
being worthwhile to have a flag which only ever uses PersistentHashMap
instead for people who really understand their workload, but I have never
had time to investigate it more.

Cheers,
Colin

On 6 December 2016 at 22:16, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:

> Hi,
>
> I've been having a ton of fun this semester learning about
> Hash Array Mapped Tries (like PersistentHashMap).
>
> Link
>
> I have written a visual tutorial for HAMT's, as well
> as a reference implementation in Clojure that supports
> trie visualisations with Rhizome.
>
> There's also a little prototype+writeup of an idea I had about
> generating defrecords at runtime based on the frequency
> of certain keysets at runtime.
>
> Enjoy!
>
> Ambrose
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Colin Fleming]

On 5 December 2016 at 02:56, 'Lee Spector' via Clojure <
clojure@googlegroups.com> wrote:

Colin Fleming has done some nice work on this in Cursive.
>

Sadly that work is not in Cursive proper yet, although I'm planning to get
it in there soon once I work out what I'm doing with spec.

However I think macro errors are only a part of what Nathan is asking for.
It's true that they cause some of the more confusing stacktraces, but there
are other errors which cause stack traces but which are really compiler
errors. I've been considering some kind of pattern matching system to try
to work out from a stacktrace what the problem really is. After all,
experienced Clojure developers can often work out easily what the issue is
from a stacktrace, so I'm sure a machine can too. However although I'm
considering this, I don't have it at the proof of concept stage yet.


> ... I am currently planning to revisit Proto REPL (in Atom), following a
> nice talk on it by Jason Gilman at Clojure Conj 2016:
> https://www.youtube.com/watch?v=buPPGxOnBnk


I agree, that talk was great and Proto REPL looks lovely. I think it would
probably be a great match for your needs.

Cheers,
Colin




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

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

[ANN] gradle-clojure 1.1.0

[Colin Fleming]

Hi all,

I've just published 1.1.0 of gradle-clojure, a Gradle plugin for compiling
Clojure code and running tests.

You can find it at https://github.com/cursive-ide/gradle-clojure.

Changes in this version are support for JUnit XML test report generation
thanks to Piotrek Bzdyl, and also support for compiler options (disabling
locals clearing, eliding meta and direct linking.

Cheers
Colin

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

Re: Java like static typing for Clojure?

[Colin Fleming]

Yes, that is a major selling point. Generative testing is really cool, and
you should definitely not be disheartened - it's a tool like any other,
with its strong points and weak points (like static typing, too). It's
definitely not universally applicable, and even more than standard testing,
it requires you to write your code keeping in mind how you will test it. It
happens that in my case I believe that static typing is a better fit, but
that doesn't mean that it won't work well for your use case. You should
definitely be excited to try it and see - if it works well in your case,
it's pretty magical.

The limitation in my case is that generative testing works best when
testing pure functions. Because so much of my system involves calls out to
a huge mutable blob of Java, it doesn't work well for me.

i actually don't have a lot of experience with generative testing, but here
are two examples from the little experience I have, one which worked well
and one which didn't.

The one that worked well was testing a binary object serialiser. This was
in Java several years ago, so a lot of the complexity in my code was
writing generators - spec (via test.check) really helps with this and it
would be relatively trivial to achieve nowadays what took me a long time
back then. But once I had a generator which generated random objects, I
then just ran a bunch of tests which generated an object, serialised it,
deserialised the resulting bytes, and checked that the deserialised object
was equal to the original one. It was really useful, and caught a whole lot
of edge case bugs I would never have caught otherwise. Things to note are
that the serialisation and deserialisation are pure functions, and the
success condition is very easy to define.

One that I have not yet found a good way to test generatively is the
paredit code in Cursive, which occasionally suffers from edge case bugs.
I'd also like to test code refactorings. However here, the generation is
much much harder (I'd have to generate valid code in some way) and then I'd
have to randomly refactor it and somehow check that the refactored version
is equivalent. Here both the generation and the success condition are
extremely hard to define, and the risk is that in your success condition
you really just end up reimplementing your original algorithm and then what
you're testing is actually that those two algorithms are the same, not
necessarily that they do what you expect. I was lucky enough to talk at
length to Thomas Arts at Curry On last year and I asked him about this. He
had done something similar for Erlang code, and had a very complicated code
generator. They generated code that produced some output, then randomly
refactored it, compiled both versions, ran them both and checked that the
output was the same. His conclusion was that in that case, the tests
weren't worth it - they took forever to run and were very brittle.

On 22 October 2016 at 02:54, Daniel  wrote:

> > In this sort of situation, a static type system which provides universal
> guarantees (this value can never be null) is more useful than a contract
> system (no null values have been seen yet for the test inputs you've
> tried). There's simply no way I can test all combinations, or reproduce all
> combinations that users might have running.
>
> Isn't a major selling point of generative testing was that it creates
> loads of unique cases you can't invent on your own?
>
> You don't trust it to do that? Is that from personal experience?
> Genuinely curious because I am a little excited about using it in a project
> at work but this is disheartening.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Java like static typing for Clojure?

[Colin Fleming]

Absolutely, both that and the dogfooding are compelling arguments :-)

On 21 October 2016 at 20:04, Colin Yates <colin.ya...@gmail.com> wrote:

> "making me sad" is unsustainable - problem solving with 1s and 0s is
> hard enough as it is without using demotivating tools :-).
>
> On 21 October 2016 at 18:40, Colin Fleming <colin.mailingl...@gmail.com>
> wrote:
> > I tried it a couple of years ago, and my impressions were more or less
> the
> > same as CircleCI's here. I found the type annotation burden much higher
> than
> > using a typed language such as Kotlin, the type checking was very slow
> and
> > the boundary between typed and untyped code was really onerous. Ambrose
> has
> > done some great work recently though, so I should check it out again.
> > However my general feeling is that retrofitting something like Typed
> Clojure
> > onto an existing language is always going to be more difficult and
> fraught
> > with problems than having a language which was designed with the types in
> > mind in the first place.
> >
> > Another possibility which I haven't had time to explore properly is Allen
> > Rohner's spectrum.
> >
> > Honestly, the easiest solution to my problem is probably just to use
> Kotlin,
> > which was designed by JetBrains for almost exactly my use case, has great
> > IDE support, and has a lot of smart people working full-time on it.
> However
> > that has a couple of problems: 1) it would make me sad and 2) I would no
> > longer be dogfooding Cursive all the time, which is a valuable source of
> > finding bugs during development. But at least I'd be spending all my
> time on
> > developing Cursive features, and not chasing NPEs or investigating all
> this.
> >
> > On 21 October 2016 at 19:20, Josh Tilles <merelyapseudo...@gmail.com>
> wrote:
> >>
> >> Out of curiosity, did you try Typed Clojure? It certainly has its rough
> >> edges, but you sound willing to bear the burden of annotating code with
> >> types (at the top-level, at least) and I think its treatment of Java
> interop
> >> does what you want: unless instructed otherwise, the typechecker assumes
> >> that arguments to Java methods must not be nil and that any Java method
> may
> >> return nil.
> >>
> >> On Thursday, October 20, 2016 at 8:39:04 AM UTC-4, Colin Fleming wrote:
> >>>
> >>> I recently spent a bunch of time researching exactly this. My
> motivation
> >>> was that my main project, Cursive, suffers from a ton of NPEs which I
> find
> >>> very difficult to manage. I wanted to see how difficult it would be to
> have
> >>> a typed Clojure-like thing, using something similar to Kotlin's type
> system.
> >>> Kotlin uses a type system which is similar to Java and has Java
> interop as a
> >>> primary goal, which I would also need since Java interop is essential
> to me.
> >>> It fixes a bunch of flaws in the Java type system and adds new
> features like
> >>> nullable types, which I now find it difficult to live without.
> >>>
> >>> Before anyone asks, spec is not useful for me because it relies heavily
> >>> on generative testing to increase your confidence in your functions. I
> can't
> >>> use generative testing because my application is tied to a large Java
> >>> codebase which I cannot model to any useful degree. Essentially, spec
> >>> recommends runtime tests at the boundary of your system, and nearly my
> >>> entire system is interop boundary. I'm not interested in runtime checks
> >>> except where absolutely necessary - Kotlin does this for me
> transparently,
> >>> spec doesn't.
> >>>
> >>> Here's a short list of my findings. I'm happy to expand on any of these
> >>> points if anyone is curious. It bears repeating - Java interop is
> >>> non-negotiable for me, and that makes a lot of this harder than it
> would be
> >>> otherwise.
> >>>
> >>> Disclaimer: I'm no programming language expert. This was hard for me,
> and
> >>> a surprising amount of it was new to me. I'd appreciate any
> corrections or
> >>> clarifications.
> >>>
> >>> Type systems are hard. I for one didn't appreciate the complexity that
> >>> goes into making them easy to use. Don't be fooled by the 20-line
> >>> implementations of Hindley-Milner.
> >>> In particular, generics are very hard, and variance for generic objects
> >>> 

Re: Java like static typing for Clojure?

[Colin Fleming]

I tried it a couple of years ago, and my impressions were more or less the
same as CircleCI's here
<https://circleci.com/blog/why-were-no-longer-using-core-typed/>. I found
the type annotation burden much higher than using a typed language such as
Kotlin, the type checking was very slow and the boundary between typed and
untyped code was really onerous. Ambrose has done some great work recently
though, so I should check it out again. However my general feeling is that
retrofitting something like Typed Clojure onto an existing language is
always going to be more difficult and fraught with problems than having a
language which was designed with the types in mind in the first place.

Another possibility which I haven't had time to explore properly is Allen
Rohner's spectrum <https://github.com/arohner/spectrum>.

Honestly, the easiest solution to my problem is probably just to use
Kotlin, which was designed by JetBrains for almost exactly my use case, has
great IDE support, and has a lot of smart people working full-time on it.
However that has a couple of problems: 1) it would make me sad and 2) I
would no longer be dogfooding Cursive all the time, which is a valuable
source of finding bugs during development. But at least I'd be spending all
my time on developing Cursive features, and not chasing NPEs or
investigating all this.

On 21 October 2016 at 19:20, Josh Tilles <merelyapseudo...@gmail.com> wrote:

> Out of curiosity, did you try Typed Clojure? It certainly has its rough
> edges, but you sound willing to bear the burden of annotating code with
> types (at the top-level, at least) and I *think* its treatment of Java
> interop does what you want: unless instructed otherwise, the typechecker
> assumes that arguments to Java methods must not be nil and that any Java
> method may return nil.
>
> On Thursday, October 20, 2016 at 8:39:04 AM UTC-4, Colin Fleming wrote:
>>
>> I recently spent a bunch of time researching exactly this. My motivation
>> was that my main project, Cursive, suffers from a ton of NPEs which I find
>> very difficult to manage. I wanted to see how difficult it would be to have
>> a typed Clojure-like thing, using something similar to Kotlin's type
>> system. Kotlin uses a type system which is similar to Java and has Java
>> interop as a primary goal, which I would also need since Java interop is
>> essential to me. It fixes a bunch of flaws in the Java type system and adds
>> new features like nullable types, which I now find it difficult to live
>> without.
>>
>> Before anyone asks, spec is not useful for me because it relies heavily
>> on generative testing to increase your confidence in your functions. I
>> can't use generative testing because my application is tied to a large Java
>> codebase which I cannot model to any useful degree. Essentially, spec
>> recommends runtime tests at the boundary of your system, and nearly my
>> entire system is interop boundary. I'm not interested in runtime checks
>> except where absolutely necessary - Kotlin does this for me transparently,
>> spec doesn't.
>>
>> Here's a short list of my findings. I'm happy to expand on any of these
>> points if anyone is curious. It bears repeating - Java interop is
>> non-negotiable for me, and that makes a lot of this harder than it would be
>> otherwise.
>>
>> Disclaimer: I'm no programming language expert. This was hard for me, and
>> a surprising amount of it was new to me. I'd appreciate any corrections or
>> clarifications.
>>
>>1. Type systems are hard. I for one didn't appreciate the complexity
>>that goes into making them easy to use. Don't be fooled by the 20-line
>>implementations of Hindley-Milner.
>>2. In particular, generics are very hard, and variance for generic
>>objects (i.e. the intersection of generic objects and OO) is the source of
>>much difficulty.
>>3. Type systems are split into two main camps - nominal typing (like
>>Java, where the types are identified by names) and structural typing, 
>> where
>>the type of an object is defined by it's "shape", like Go's interfaces.
>>4. One of the major benefits of Clojure is its heterogeneous
>>collections, a.k.a. "just use a map". This is very difficult to maintain 
>> in
>>a type-safe manner without losing most of the benefit.
>>5. There are two main things I was interested in from a type system -
>>type checking (i.e. making sure that your program's types are correct) and
>>type inference (working out what the types of things are from the code, so
>>you don't have to annotate everything). Type checking is relatively
>>straightforwa

Re: Java like static typing for Clojure?

[Colin Fleming]

Sure, I'm not arguing that all large projects suffer from this, and I'm not
entirely sure why Cursive does so badly. But the argument I often see
online is the opposite - that Clojure codebases never suffer from this, and
if they do then it must be because of interop, or the application must be
strange in some way. I think this sort of argument is equally disingenuous,
and like I say, I've heard numerous anecdotes to the contrary.

One theory about why Cursive is particularly prone to this that I forgot to
mention - Cursive *is* unusual in that it is run on users' desktops. When
writing, for example, a web application, assuming you're validating your
input you have a reasonable handle on the expected space of inputs, and you
can test various combinations of your application state. For Cursive, that
is much harder - I currently support 6 versions of the underlying IntelliJ
platform, and they run on 3 operating systems. There are two
main IntelliJ configurations (Ultimate and Community). These variations are
actually surprisingly stable and don't tend to create a lot of problems,
but users can also have any combination of plugins installed, and they can
sometimes interact in surprising ways - I've had bugs logged against
Cursive that have turned out to be bugs in the Scala plugin, and vice
versa. Plugins can hook into all sorts of different IDE functionality at
different levels and this can interact in strange ways. I've had a lot of
bugs of this sort, and it's plausible that many of the bugs that are
currently unresolved are a result of this in some way.

In this sort of situation, a static type system which provides universal
guarantees (this value can never be null) is more useful than a contract
system (no null values have been seen yet for the test inputs you've
tried). There's simply no way I can test all combinations, or reproduce all
combinations that users might have running. While the spec'ed core
definitely sounds like something I should try, it will still only work for
the combinations that I actually test unless I leave it running in
production builds.

On 21 October 2016 at 17:51, Alex Miller <a...@puredanger.com> wrote:

> Just as a counter-anecdote, I have worked on large Clojure codebases (both
> ones I developed and ones I was unfamiliar with), including ones that
> interfaced with existing Java codebases, and have not experienced this
> problem to the degree you describe Colin. So while I believe these problems
> exist, I don't think it's a foregone conclusion that they must.
>
> FYI, I've found that when working with a partially instrumented spec'ed
> clojure.core, that unexpected nil colls (and colls containing nil) are
> reported earlier and better (because they occur at the point they are
> introduced rather than later and several layers down in some RT method).
>
> On Friday, October 21, 2016 at 10:15:23 AM UTC-5, Colin Fleming wrote:
>>
>> This is a discussion that I've had a couple of times. I don't think that
>> interop is the main factor here, I think it's more that I'm programming
>> against a large codebase I don't understand well (I can't since it's around
>> 4 million LOC). I suspect that if I were programming against a large
>> undocumented Clojure codebase I'd have similar problems, or worse.
>>
>> Note that Java interop often gets the blame here, but it's worth pointing
>> out that in Clojure everything is Java interop in the end. (+ 1 x) or
>> (str/trim x) will give you an NPE as easily as in Java if you pass nil in
>> x. And even if Java interop *is* the root cause of the problem,
>> supposedly interop is idiomatic in Clojure, and interfacing with existing
>> Java systems is a key use case for continuing Clojure adoption. I don't
>> think that the type of application that Cursive is is as much of an outlier
>> as people think - anyone integrating with an existing system will probably
>> face similar problems. Indeed, after my previous conversations, several
>> people contacted me to say that their experience matched mine in similar
>> systems.
>>
>> People have also asked me about whether nil punning helps. In my
>> experience, it allows for some elegant code but it has a really terrible
>> tendency to mask bugs and push them much further into the system than would
>> otherwise be the case. It would be nice to be able to say that I'm
>> expecting a collection to be non-nil, and to get an NPE at the point of the
>> collection call if it's nil due to a bug, rather than just silently
>> returning nil and continuing.
>>
>> Also, when tracking down an NPE from a bug report, if there are
>> collection methods in the stack trace I now have to consider (at least) 3
>> cases: the collection is unexpectedly nil, the collection is unexpectedly
>> empt

Re: Java like static typing for Clojure?

[Colin Fleming]

This is a discussion that I've had a couple of times. I don't think that
interop is the main factor here, I think it's more that I'm programming
against a large codebase I don't understand well (I can't since it's around
4 million LOC). I suspect that if I were programming against a large
undocumented Clojure codebase I'd have similar problems, or worse.

Note that Java interop often gets the blame here, but it's worth pointing
out that in Clojure everything is Java interop in the end. (+ 1 x) or
(str/trim x) will give you an NPE as easily as in Java if you pass nil in
x. And even if Java interop *is* the root cause of the problem, supposedly
interop is idiomatic in Clojure, and interfacing with existing Java systems
is a key use case for continuing Clojure adoption. I don't think that the
type of application that Cursive is is as much of an outlier as people
think - anyone integrating with an existing system will probably face
similar problems. Indeed, after my previous conversations, several people
contacted me to say that their experience matched mine in similar systems.

People have also asked me about whether nil punning helps. In my
experience, it allows for some elegant code but it has a really terrible
tendency to mask bugs and push them much further into the system than would
otherwise be the case. It would be nice to be able to say that I'm
expecting a collection to be non-nil, and to get an NPE at the point of the
collection call if it's nil due to a bug, rather than just silently
returning nil and continuing.

Also, when tracking down an NPE from a bug report, if there are collection
methods in the stack trace I now have to consider (at least) 3 cases: the
collection is unexpectedly nil, the collection is unexpectedly empty, or
the collection unexpectedly contains a nil value. This greatly increases
the space of problems that I have to consider as possibilities when trying
to work out what's going on.



On 21 October 2016 at 05:39, Daniel  wrote:

> Just curious... What do you think the primary contributing factor is for
> Cursive's NPEs? Java interop?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Java like static typing for Clojure?

[Colin Fleming]

I recently spent a bunch of time researching exactly this. My motivation
was that my main project, Cursive, suffers from a ton of NPEs which I find
very difficult to manage. I wanted to see how difficult it would be to have
a typed Clojure-like thing, using something similar to Kotlin's type
system. Kotlin uses a type system which is similar to Java and has Java
interop as a primary goal, which I would also need since Java interop is
essential to me. It fixes a bunch of flaws in the Java type system and adds
new features like nullable types, which I now find it difficult to live
without.

Before anyone asks, spec is not useful for me because it relies heavily on
generative testing to increase your confidence in your functions. I can't
use generative testing because my application is tied to a large Java
codebase which I cannot model to any useful degree. Essentially, spec
recommends runtime tests at the boundary of your system, and nearly my
entire system is interop boundary. I'm not interested in runtime checks
except where absolutely necessary - Kotlin does this for me transparently,
spec doesn't.

Here's a short list of my findings. I'm happy to expand on any of these
points if anyone is curious. It bears repeating - Java interop is
non-negotiable for me, and that makes a lot of this harder than it would be
otherwise.

Disclaimer: I'm no programming language expert. This was hard for me, and a
surprising amount of it was new to me. I'd appreciate any corrections or
clarifications.

   1. Type systems are hard. I for one didn't appreciate the complexity
   that goes into making them easy to use. Don't be fooled by the 20-line
   implementations of Hindley-Milner.
   2. In particular, generics are very hard, and variance for generic
   objects (i.e. the intersection of generic objects and OO) is the source of
   much difficulty.
   3. Type systems are split into two main camps - nominal typing (like
   Java, where the types are identified by names) and structural typing, where
   the type of an object is defined by it's "shape", like Go's interfaces.
   4. One of the major benefits of Clojure is its heterogeneous
   collections, a.k.a. "just use a map". This is very difficult to maintain in
   a type-safe manner without losing most of the benefit.
   5. There are two main things I was interested in from a type system -
   type checking (i.e. making sure that your program's types are correct) and
   type inference (working out what the types of things are from the code, so
   you don't have to annotate everything). Type checking is relatively
   straightforward, but type inference can be very hard indeed.
   6. Much of the complication comes from the need to interop with Java.
   ML-style interface essentially doesn't work if you want to maintain
   compatibility with Java since it cannot be interfaced in a useful way with
   nominal OO systems. In particular, method overriding is basically
   impossible to represent.
   7. #6 implies that you cannot have a language with good Java interop
   *and* global type inference, i.e. you will definitely be annotating your
   function parameter types, and your function return types. I'm ok with this
   since IMO it's a good practice anyway.
   8. Once you start thinking about the fact that you no longer have
   heterogeneous collections, and start thinking about what the alternatives
   would look like, you start to realise that you'd end up with basically the
   ML family style of data types - homogeneous collections, typed tuples and
   ADTs. I'm actually ok with that too, since they're a very nice set of
   primitives and I think they probably represent 95% of how people use
   Clojure's collections anyway.
   9. Structural typing seems like it might be a good fit for something
   like Clojure's maps. However, mixing structural and nominal typing *and*
   OO seems to be the path to madness.

I think that's it. This is still a project I'd like to tinker with at some
point, but I think it's fair to say that I dramatically underestimated the
amount of work a useful Java-compatible type system would be. I still think
it seems like a nice point in the language design space though, which is
curiously unfilled on the JVM (some of you may have noticed that I
basically want F# with nullable types).

Cheers,
Colin

On 16 October 2016 at 00:14, Didier  wrote:

> I know a lot of people like to say how unhelpful Java like static typing
> is, and only more powerful type systems of the ML family add value, but
> I've been wondering recently if for Clojure it wouldn't make more sense to
> simply extend the type hints to enable an optional Java like static typing
> scheme.
>
> It is my understanding that ML style static typing is incredibly difficult
> to add properly and without compromise to a dynamic language. That doing so
> limits the scope of type inference, rendering the task of adding type info
> more tedious then in ML languages themselves.
>
> ML 

[ANN] gradle-clojure 1.0.1

[Colin Fleming]

 Hi all,

I mentioned to several people that I’ve been using a Gradle plugin I wrote
to compile Cursive. I’ve just published it here:
https://github.com/cursive-ide/gradle-clojure. It’s also in the Gradle
plugin repo.

It’s currently very basic, but it works for what I need. If anyone needs
extra features, let me know and I’ll see about adding them. One thing that
I’m going to add soon is support for compiling Android code with this, so
that Cursive can be used with Android Studio.

It tries to use the standard Gradle mechanisms to interoperate better with
other Gradle tasks, for example the tasks all implement JavaForkOptions so
you can run tests under JaCoCo and similar tasks. It also uses the standard
Gradle include/exclude mechanisms for selecting the files to work on, and
derives the namespaces by demunging the file paths.

Let me know if anything isn’t clear from the doc and I’ll update that too.

Cheers,
Colin

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

[Colin Fleming]

I agree that tidied up the error messages are much more understandable.
Replacing things like "path" with a description of what it means goes a
long way. My main issue with the original error which persists in your
version is that the failing predicate really doesn't help much identifying
the problem. However Leon's investigations hopefully will help to make that
better by more precisely identifying the failing predicate.

I'd envisioned the source text for a particular top-level form only being
held for as long as required to eval or compile the form, not being stored
permanently in metadata. But I'd have to go and look at the code to see if
that's feasible or not. AOTing would not be a problem since the
macroexpansion errors would be found when the form was AOTed, those errors
would never occur at runtime.

Thanks for the kind words about Cursive too, one of my main goals is to
make Clojure more approachable (hence the obsession with error messages),
so I'm glad it's helped your co-workers! And you never know, maybe you'll
like it enough one day to switch :-)

On 26 August 2016 at 21:15, Rick Moynihan <rick.moyni...@gmail.com> wrote:

> On 26 August 2016 at 03:11, Colin Fleming <colin.mailingl...@gmail.com>
> wrote:
>
>> Hi Rick,
>>
>> That looks really excellent, and is a huge improvement. Particularly in
>> combination with Leon's proposed change which more precisely identifies the
>> likely failing part of the grammar, this looks like a big win for not much
>> extra effort.
>>
>
> Well it was really just 5-10 minutes work.  I think it shows though that
> specs errors are actually better than a lot of people are giving them
> credit for.  Once I'd tidied it up a bit it surprised me.
>
>
>> One thing that I think would help a lot would be if it were possible to
>> show the actual text from the failing expression rather than pretty
>> printing a seq representation of it. This would mean modifying the reader
>> such that it either caches the program text from each top-level form as it
>> reads it, or perhaps re-reading the file on an error. This means the
>> relevant code is likely to look more familiar to the user, and also avoids
>> any need to pretty print. Pretty printing is likely to be complicated since
>> it normally works top-down, and uses the type of each form to decide how to
>> lay its sub-parts out. If you're only pretty-printing a fragment from
>> within, say, a large ns form, pprint is unlikely to format it as the user
>> would expect.
>>
>
> Yes, as I was re-rendering the error message it did occur to me that you
> could do lots more to make it even nicer.  Capturing the source text is
> certainly one, though mightn't there be a risk of using a large amount of
> memory to store those metadata strings, especially if they're nested,
> overlapping sexps.
>
> Re-reading the file on error would presumably only work if the file was
> available, if it was only aot'd you'd have to either have captured the
> source text at macro expansion time (as mentioned above) or try to lookup
> the source for an even better error - and if it's not found fallback to a
> pretty-pinting of the form.
>
> I didn't want to go too far down the road with the example, as I wanted to
> show how much better the message could be with just a modest amount of
> work.  The main ideas of the proposal are also independent and don't rely
> too much on each other.
>
> I'm curious whether the core team plan for the formatting of these strings
> to be a contract; or whether after 1.9.0 is released if they could be
> flagged as experimental - with further improvements to the rendering being
> pushed into future clojure releases?
>
> R.
>
> p.s. Colin, just wanted to say a massive thanks for Cursive!  I'm an Emacs
> Cider user myself, but it's really helped many members of our team, and
> I've been so impressed with the progress, that I even asked my boss to buy
> me a copy... I think it'll still take quite a lot to get me off
> Emacs/Cider; but you might well make it! :-)
>
>
>> Cheers,
>> Colin
>>
>> On 26 August 2016 at 12:59, Rick Moynihan <rick.moyni...@gmail.com>
>> wrote:
>>
>>> I think one obvious area that specs error messages could be improved is
>>> with some basic formatting and cosmetic changes. If spec presented errors
>>> not as a wall of text and syntax but with some simple formatting it would
>>> make a big difference to legibility.
>>>
>>> As a starter for 10, why could we not render the messages at a REPL more
>>> like this?  (Note this is basically Brian's error - re-rendered):
>>>
>>> user=> (ns such.sequences 

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Colin Fleming]

I'm not sure about that - I suspect it would still be useful even just for
surface forms, although it's probably not ideal to have two different modes
for when you have the data or not. I had assumed that, assuming that most
macro forms are spec'ed, most syntax problems would be encountered by the
top-level macro spec. However thinking about it, in the case you mentioned
the condition is probably passed through the two macros untouched and a
problem there would be encountered by 'if'. However in that case the
original text would still be useful since it would not have been touched
during the expansions, the problem would be detecting that the form hasn't
been modified. Similarly, the 'then' expression of the 'if' would be the
original forms from the when-let body wrapped in a do.

I'm not sure how useful this idea would be in practice, it would need some
experimentation to see how well it works.

On 26 August 2016 at 20:24, Alex Miller <a...@puredanger.com> wrote:

> On Thursday, August 25, 2016 at 9:11:39 PM UTC-5, Colin Fleming wrote:
>>
>>
>> One thing that I think would help a lot would be if it were possible to
>> show the actual text from the failing expression rather than pretty
>> printing a seq representation of it. This would mean modifying the reader
>> such that it either caches the program text from each top-level form as it
>> reads it, or perhaps re-reading the file on an error. This means the
>> relevant code is likely to look more familiar to the user, and also avoids
>> any need to pretty print. Pretty printing is likely to be complicated since
>> it normally works top-down, and uses the type of each form to decide how to
>> lay its sub-parts out. If you're only pretty-printing a fragment from
>> within, say, a large ns form, pprint is unlikely to format it as the user
>> would expect.
>>
>
> Does the caching or file re-reading have any hope of working when you have
> nested macro expansions (like when-let -> when -> if)? The input to when in
> that case is a form constructed by when-let, not text sitting in a file.
> But maybe that doesn't matter if it's still useful for some good percentage
> of macro calls that have access to text. One benefit of using pprint is
> that you (the user) can control stuff like *print-length*,
> *print-suppress-namespace*, *print-right-margin*, etc.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Colin Fleming]

Hi Rick,

That looks really excellent, and is a huge improvement. Particularly in
combination with Leon's proposed change which more precisely identifies the
likely failing part of the grammar, this looks like a big win for not much
extra effort.

One thing that I think would help a lot would be if it were possible to
show the actual text from the failing expression rather than pretty
printing a seq representation of it. This would mean modifying the reader
such that it either caches the program text from each top-level form as it
reads it, or perhaps re-reading the file on an error. This means the
relevant code is likely to look more familiar to the user, and also avoids
any need to pretty print. Pretty printing is likely to be complicated since
it normally works top-down, and uses the type of each form to decide how to
lay its sub-parts out. If you're only pretty-printing a fragment from
within, say, a large ns form, pprint is unlikely to format it as the user
would expect.

Cheers,
Colin

On 26 August 2016 at 12:59, Rick Moynihan  wrote:

> I think one obvious area that specs error messages could be improved is
> with some basic formatting and cosmetic changes. If spec presented errors
> not as a wall of text and syntax but with some simple formatting it would
> make a big difference to legibility.
>
> As a starter for 10, why could we not render the messages at a REPL more
> like this?  (Note this is basically Brian's error - re-rendered):
>
> user=> (ns such.sequences (require ))
>
> CompilerException clojure.lang.SpecException:
>
> Call to clojure.core/ns did not conform to fdef [:args] spec
>
> There was unexpected extra input in: [2]
>
> with value: (,,, (require [such.vars :as var]
>  [such.immigration :as immigrate])
>(require midje.checking.checkers.defining
> midje.checking.checkers.chatty
> midje.checking.checkers.simple
> midje.checking.checkers.combining
> midje.checking.checkers.collection))
>
> Input failed spec predicate: (cat :attr-map (? map?)
>:clauses
> :clojure.core.specs/ns-clauses)
>
> When compiling: (such/sequences.clj:1:1)
>
> user=>
>
> Some things to point out:
>
> 1. Provide some extra context by subclassing IllegalArgumentException as
> SpecException.  This may also help separate SpecException's from other
> IllegalArgumentExceptions too, and help tools do something special on a
> SpecException.
>
> 2. Use of new lines to break up and separate text blocks.
>
> 3. State that it's an fdef spec, and it was the [:args] bit of that spec
> that failed.  By stating them together we implicitly associate [:args] with
> fdef.  Note I'm assuming we can also capture that fdef defined this spec.
>
> 4. It's a bit unclear what "Extra input" means... so clarify that it was
> unexpected.  Provide the path [2] as before.
>
> 5. State the failing value and pretty print it.  Note that we also elide
> the other passing parameters with a 
>
> 6. As before state the predicate that identified the failure in a
> humanised manner and the location of the failing form.
>
> I'm not suggesting these are necessarily good ideas, and I appreciate I've
> not considered all of the other cases you might need to, but it seems that
> something like the above would be a dramatic if entirely cosmetic
> improvement.  It would be a shame if clojure.core made no attempt to
> humanise the display of these messages and left it entirely up to the
> community.
>
> Thoughts?
>
> R.
>
>
> On 20 August 2016 at 15:03, Alex Miller  wrote:
>
>>
>>
>> On Saturday, August 20, 2016 at 5:17:59 AM UTC-5, Brian Marick wrote:
>>>
>>> Yesterday, a bug was filed against Suchwow under 1.9alpha11. It turns
>>> out to have been a use of `ns …(require…` instead of `(ns …(:require`. Not
>>> in Suchwow, but in Midje. Unfortunately, the Suchwow file the bug report
>>> pointed at *also* had that typo - apparently I am prone to it - so adding
>>> the colon to the require there didn’t make the problem go away.
>>>
>>> That caused me to lose my temper and make a fool of myself, which is
>>> neither here nor there, except that I apologize to @puredanger.
>>>
>>> I have two suggestions, though:
>>>
>>> 1. It has long been the case that Clojure allowed `(ns (require…)` even
>>> though that’s strictly incorrect. I suggest that, for backwards
>>> compatibility, it be allowed going forward. That is, I think it does no
>>> harm for a correct `ns` statement to allow symbols as well as keywords.
>>> That wrong code in Midje has been there since Clojure 1.2.
>>>
>>
>> We discussed this before releasing the specs and decided to start on the
>> strict side. That said, this is still an alpha and there is plenty of time
>> to change our minds prior to 

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Colin Fleming]

Thanks, Adrian. I'm unsure about the disrespectful part - as I mentioned,
discussions around community problems are always difficult, but they are
important. As with all internet conversations, of course, tone is
everything.

But since this is very well-trodden ground, and for whatever reason it's
clear it won't change, I definitely agree they're unproductive. I'll be
leaving the non-error-message aspects of this conversation alone now.

On 26 August 2016 at 12:03, <adrian.med...@mail.yu.edu> wrote:

> Colin,
>
> FWIW, I think you're doing a great job of articulating your points (which
> I largely agree with) and are providing great feedback for the core team
> and community to think about. This conversation is supposed to happen as
> the alpha versions are being iterated on.
>
> But I think continually resurfacing meta issues one has with Clojure's
> management (and I'm not saying you're doing this, but others are) instead
> of engaging thoughtfully with a team who is engaging you thoughtfully is
> both disrespectful and unproductive. Actually, it's counter productive
> because it can unfortunately make people think twice before taking you
> seriously in the future.
>
> Like you, I think friendly error messages is an important issue for
> Clojure. We have an amazing source of heavily annotated information we can
> use to generate best-in-class error messages thanks to clojure.spec. We
> should refocus this in thread.
>
> But I'm not a moderator, so I guess take whatever I say with a grain of
> salt. :)
>
> On Thursday, August 25, 2016 at 7:12:04 PM UTC-4, Colin Fleming wrote:
>>
>> I really don't understand how you expect anyone to take your criticism
>>> seriously if you keep implying you're happily abandoning the language for
>>> greener pastures.
>>> Why would anyone developing Clojure look at anything you have to say at
>>> this point as anything less than trolling?
>>
>>
>> Because if we're genuinely interested in improving the language and the
>> community around it, the people who are deliberately choosing to leave it
>> have the answers to what we need to do that.
>>
>> I develop Cursive, and I'm always very interested in feedback from users,
>> and I'm really *more* interested in feedback about what they don't like
>> because my opportunities for improvement are there. It's always nice to
>> hear that people love Cursive and those messages are an important part of
>> maintaining my motivation to continue working on it. But in terms of
>> feedback that I can directly action, problems are where it's at.
>>
>> Of course, sometimes that feedback is not useful, actionable or valuable.
>> "IDEs suck" gets ignored, in much the same way that "Clojure sucks because
>> it's dynamically typed" should. "I don't use it because I find IDE's too
>> heavy" (like "I don't use Clojure because I prefer strong types") is fine,
>> there are lots of people out there with different preferences and I can't
>> cater to everyone. Being based on IntelliJ is what Cursive *is*, and I
>> can't change that. But if someone uses Cursive a lot, likes it, talks
>> publicly about how much they like it, participates in the issue tracker and
>> on the mailing list etc etc but then says "I'm taking up Emacs because I
>> can't stand how Cursive does x, y, and z" then I will absolutely try to
>> make those things better.
>>
>> Criticisms about how the community works are perhaps the hardest to hear
>> since they seem very personal - if we're active in the community, in some
>> way they're directly criticising the ways we behave. Similarly, they're
>> much harder to fix. But they are essential, since no-one uses a programming
>> language purely because of the language itself these days.
>>
>> FWIW, I share many of Brian's concerns.
>>
>> On 26 August 2016 at 03:46, <adrian...@mail.yu.edu> wrote:
>>
>>> I really don't understand how you expect anyone to take your criticism
>>> seriously if you keep implying you're happily abandoning the language for
>>> greener pastures.
>>>
>>> Why would anyone developing Clojure look at anything you have to say at
>>> this point as anything less than trolling?
>>>
>>> Back on topic, I find Colin's suggestions about implementing an error
>>> reporting heuristic intriguing. What he has laid out could form the basis
>>> for a solution to this problem which can satisfy everyone's requirements
>>> when integrated well with spec's explain-data. I am curious to hear what
>>> Alex and others think about it.
>>>

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Colin Fleming]

>
> I really don't understand how you expect anyone to take your criticism
> seriously if you keep implying you're happily abandoning the language for
> greener pastures.
> Why would anyone developing Clojure look at anything you have to say at
> this point as anything less than trolling?


Because if we're genuinely interested in improving the language and the
community around it, the people who are deliberately choosing to leave it
have the answers to what we need to do that.

I develop Cursive, and I'm always very interested in feedback from users,
and I'm really *more* interested in feedback about what they don't like
because my opportunities for improvement are there. It's always nice to
hear that people love Cursive and those messages are an important part of
maintaining my motivation to continue working on it. But in terms of
feedback that I can directly action, problems are where it's at.

Of course, sometimes that feedback is not useful, actionable or valuable.
"IDEs suck" gets ignored, in much the same way that "Clojure sucks because
it's dynamically typed" should. "I don't use it because I find IDE's too
heavy" (like "I don't use Clojure because I prefer strong types") is fine,
there are lots of people out there with different preferences and I can't
cater to everyone. Being based on IntelliJ is what Cursive *is*, and I
can't change that. But if someone uses Cursive a lot, likes it, talks
publicly about how much they like it, participates in the issue tracker and
on the mailing list etc etc but then says "I'm taking up Emacs because I
can't stand how Cursive does x, y, and z" then I will absolutely try to
make those things better.

Criticisms about how the community works are perhaps the hardest to hear
since they seem very personal - if we're active in the community, in some
way they're directly criticising the ways we behave. Similarly, they're
much harder to fix. But they are essential, since no-one uses a programming
language purely because of the language itself these days.

FWIW, I share many of Brian's concerns.

On 26 August 2016 at 03:46,  wrote:

> I really don't understand how you expect anyone to take your criticism
> seriously if you keep implying you're happily abandoning the language for
> greener pastures.
>
> Why would anyone developing Clojure look at anything you have to say at
> this point as anything less than trolling?
>
> Back on topic, I find Colin's suggestions about implementing an error
> reporting heuristic intriguing. What he has laid out could form the basis
> for a solution to this problem which can satisfy everyone's requirements
> when integrated well with spec's explain-data. I am curious to hear what
> Alex and others think about it.
>
> On Thursday, August 25, 2016 at 11:18:28 AM UTC-4, Brian Marick wrote:
>
>>
>> On Aug 24, 2016, at 9:28 PM, adrian...@mail.yu.edu wrote:
>>
>> I do not think your tone and lack of constructive feedback to Alex's (and
>> others) thoughtful responses is helping your case.
>>
>>
>> Probably not(*), though I would characterize the responses differently.
>> They are polite, and they are intended to be helpful to someone who already
>> agrees with axioms like “good error-handling is a nail for which core.spec
>> is the hammer” and “it is wise to push the responsibility for error
>> understanding to third-party libraries or diligent study”. They do a
>> service in that they lay out the rules under which Clojure users should
>> expect to live. But they are largely reiterations rather than engagement. I
>> find that rather frustrating.
>>
>>
>> Let me point to an essential book on business/community management,
>> Hirschman’s /Exit, Voice, and Loyalty/. https://en.wikipedia
>> .org/wiki/Exit,_Voice,_and_Loyalty, and to a clever take on group
>> behavior, “Evaporative Cooling of Group Beliefs”, http://lesswrong.com
>> /lw/lr/evaporative_cooling_of_group_beliefs/. I think there is much to
>> learn from reflecting on those and the direction of Clojure design and the
>> Clojure community over the past few years. (I’m not a huge fan of the
>> application of Satir’s family counseling theory to software management -
>> Gerald Weinberg and the like - but it’s hard not to read books like the
>> /Quality Software Management/ series and see people in the Clojure
>> community - including me! - playing out stereotypical dysfunctional roles.)
>>
>> Read me as someone who’s publicly and self-destructively giving up on
>> Voice and is on the way to Exit. As someone who tends to Loyalty (though
>> perhaps the loyalty of the traditional Catholic Devil’s Advocate), it’s
>> rather agonizing. That is, I still think Clojure is the best raw language
>> out there for broad-spectrum work. However, its design has been doubling
>> down on long-unfortunate tendencies, and - I’d argue - new languages like
>> Rust, Elixir, and Elm (even Pony) - are raising the bar for both community
>> management and “peripheral” concerns like 

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Colin Fleming]

This is almost exactly the intuition behind the standard error reporting
heuristic for grammars involving alternations. It is a heuristic, but it
has to be since on a failure it's impossible to entirely accurately
determine the user's intention. But intuitively, generally the rule that
has managed to parse the furthest into the input is considered the rule
that is most likely to be what the user intended since that's the one that
has matched the most. This is usually calculated using the source offset,
this is subtly different to :path since :path is the distance in the
grammar itself. This doesn't necessarily correspond to the distance into
the input - consider the regex aabcd|a* when matching  - the first
alternation would produce a path of length 2 if the two a's in the grammar
are labeled, but the second would produce a path of length 1 (a single
rule) even though it would match more input.

Here's how the basic algorithm works to produce an error like I showed
above.

   1. Parse the form - if it matches some path through your grammar, you're
   done.
   2. If not, for each failure record the path to that failure, the text
   offset of the error point and what the rule was expecting at that point.
   This may be that you found something unexpected, but may also be that you
   ran out of input and needed more.
   3. When done, find the furthest error point and collect all the failure
   info for rules which failed at that point.
   4. If there's just a single failed rule, use that as your error rule to
   report from. Otherwise, use a heuristic like "find the shortest subset of
   all failed rules and use that path as the failing rule" (since all failures
   start from that point).
   5. Report something like "Error when parsing , found  but was expecting one of ".

There are some complications here in Clojure since we're parsing forms, and
not all form elements have metadata saying where they exist in the source
(e.g. keywords). Also, when you run out of input it's really useful to be
able to indicate the end of the form you were parsing to say "I needed more
input here". Finally, if we're parsing the result of a previous
macroexpansion, macros are historically pretty bad at propagating source
metadata. I'd like to see the following improvements:

   1. Ensure that forms always get source metadata added - I believe there
   were some bugs around this.
   2. For composite forms (i.e. collection literals) add metadata
   indicating the end of the form in the source.
   3. On macroexpansion, automatically propagate the source location
   metadata from the source form to the expansion if it's not present there -
   that way at least the form itself will retain it.

tools.reader handles all this stuff a lot better, I believe. I think there
are also open JIRAs for some of this work.

On 25 August 2016 at 09:33, Leon Grapenthin 
wrote:

>
>
> On Tuesday, August 23, 2016 at 3:27:28 AM UTC+2, Alex Miller wrote:
>>
>> predicate: (cat :args (* :clojure.core.specs/binding-form) :varargs (?
>> (cat :amp #{(quote &)} :form :clojure.core.specs/binding-form))),
>>
>> the predicate that is actually failing in the spec, probably not
>> particularly helpful given the complexity (and recursiveness) of the
>> destructuring specs
>>
>>
>> Extra input
>>
>> this is the part of cat that I think could be made more explicit - could
>> be saying here that the value it had (above) was expected to match the next
>> part of the cat (binding-form). So that could say the equivalent of
>> "Expected binding-form but had non-matching value ..." and could even find
>> what parts of that value matched and maybe which didn't (the :or keys) such
>> that you'd have a more precise description. There is some more stuff Rich
>> and I have worked on around "hybrid maps" which is the case here with map
>> destructuring - it's particularly challenging to get a good error out of
>> that at the moment, but there's more that can be done.
>>
>>
> Thank you for doing the walkthrough. I observed this too and became
> sceptical why spec doesn't go further down the path and apparently stops at
> ::binding-form.
> I could isolate the problem a bit by changing the spec of ::arg-list and
> temporarily removing the :varargs branch.
>
> (s/def ::arg-list
>   (s/and
> vector?
> (s/cat :args (s/* ::binding-form)
> ;;   :varargs (s/? (s/cat :amp #{'&} :form ::binding-form))
>)))
>
> This leads to a much better message:
>
> (s/explain (:args (s/get-spec 'clojure.core/defn))
>'[foo [{:or {a/b 42}}]])
>
> In: [1 0] val: {:or #:a{b 42}} fails spec: :clojure.core.specs/local-name
> at: [:bs :arity-1 :args :args :sym] predicate: simple-symbol?
> In: [1 0 0] val: ([:or #:a{b 42}]) fails spec: 
> :clojure.core.specs/seq-binding-form
> at: [:bs :arity-1 :args :args :seq] predicate: (cat :elems (*
> :clojure.core.specs/binding-form) :rest (? (cat :amp #{(quote &)} :form
> 

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Colin Fleming]

Sure, at the end of the day I don't really care about thre require/:require
issue, it just seems a little incongruent with previous decisions which
have promoted backwards compatibility. I generally prefer increased
strictness, so I'm fine with the change. I do care about the error
messages, though.

On 24 August 2016 at 21:32, Mond Ray <mondraym...@gmail.com> wrote:

> I agree Colin, this feels more like the beatings shall continue until
> morale improves ;-)
>
> More seriously, I understand the point of the musical instruments analogy
> to be a reminder to programmers that learning a language and understanding
> it in depth will increase your power and expressivity with that language.
> That should not be used as a reason to increase the difficulties caused by
> obscure error reporting. My initial understanding of the sales pitch for
> specs was that it would serve to improve error messages as the macro
> expansions / transformations would be more tractable in the compiler. I get
> that it is a work in progress but let's retain that original goal.
>
> Unlike you however, I would prefer correctness and the consequent ripples
> over the continuing acceptance of incorrect expressions. My reasoning is
> that code which has fewer compatibility style branches will be easier to
> equip with the necessary instrumentation for generating more human friendly
> error messages.
>
> Ray
>
> PS I think this require vs :require thing comes from the way that novices
> confuse the ns macro with the function that pulls dependencies in at the
> REPL. Cutting / pasting between the REPL and the file can allow that to
> bleed in. I know it confused me.
>
> On Wednesday, 24 August 2016 01:09:48 UTC+2, Colin Fleming wrote:
>>
>> But creating error messages that are optimal for a user with no knowledge
>>> or Clojure or spec is just not the goal.
>>
>>
>> This is a totally false dichotomy. No-one in this thread is asking for
>> that. This thread has several examples of expert Clojure users for whom the
>> error messages are incomprehensible.
>>
>> I am equally unapologetic about thinking that the musical instrument
>> analogy is mostly bogus here. There are things that will always be
>> difficult about learning Clojure because they're conceptual, such as
>> functional programming. I think the analogy is fair there, they are just
>> things that will require effort and practice to learn. But the error
>> messages are about giving people the information they need *so that they
>> can actually learn from their mistakes*. Clojure has historically been
>> appallingly bad at that, and no-one should expect their users to flail
>> around randomly trying things to see what works. I've spoken to various
>> smart people who have described their experience of using Clojure as
>> exactly that, even after a non-trivial amount of time using it. I hope spec
>> can improve on that experience.
>>
>>
>> On 24 August 2016 at 02:45, Alex Miller <al...@puredanger.com> wrote:
>>
>>> I do not have an idea of what the final end point will look like
>>> exactly. I don't get the feeling that there is any answer that you will
>>> find satisfying, so I'm not sure what else I can do for you. We expect
>>> Clojure users to become familiar with spec and its output as it is (now) an
>>> essential part of the language. You will see specs in error messages.
>>>
>>> The focus in Clojure has always been biased towards building a powerful
>>> and expressive tool that is rewarding for experts vs optimizing for
>>> novices. Rich has talked at length about why that is (see
>>> https://www.infoq.com/presentations/design-composition-
>>> performance-keynote / https://github.com/matthiasn/t
>>> alk-transcripts/blob/master/Hickey_Rich/DesignCompositionPerformance.md
>>> in the section around languages as instruments). Pertinent bit (but you
>>> should watch the whole thing for context):
>>>
>>> So we need players. I would rant here, but I won't. But look at this
>>> guitar player with blisters. A harpist has blisters, a bass player with
>>> blisters. There's this barrier to overcome for every musician. Imagine if
>>> you downloaded something from GitHub and it gave you blisters.
>>>
>>> [Audience laughter]
>>>
>>> Right? The horrors! And yet how many people here play an instrument or
>>> have at one point in their lives? Yeah, a lot of programmers do. And for
>>> how many people did you just pick it up and it was awesome? How many
>>> wished, like, something could have made it more straightforward to g

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Colin Fleming]

effort.
>
>
> ...and there's more there - it's really worth reading/watching the whole
> thing. We are not apologetic about this bias. We expect you to engage and
> learn this tool that you're going to use for serious work because there's
> also deep payoff on the other side, just like learning to play the guitar
> or is more rewarding than learning to play the kazoo.
>
> I'm absolutely not talking about making something hard on purpose and I'm
> not saying that making things easy to learn is bad. I'm stating an ordering
> of priorities. It's more important to us to build a system of many parts
> that can be composed together into specifications that work as validators,
> and conformers, and sample generators, and error explainers, etc. We *also*
> want the automatic errors created from that to be useful and helpful and
> understandable thus this is a WIP. But creating error messages that are
> optimal for a user with no knowledge or Clojure or spec is just not the
> goal.
>
> Elena Machkasova has been doing research (supported in part by Cognitect)
> on figuring out what totally new users of Clojure need from error messages
> for her CS education classes and the answer there is just different from
> what an experienced user needs. That's ok. We care more about the latter.
>
>
>
>
> On Tuesday, August 23, 2016 at 8:49:38 AM UTC-5, Brian Marick wrote:
>>
>>
>> On Aug 22, 2016, at 7:50 PM, Alex Miller <a...@puredanger.com> wrote:
>>
>>
>> You've complained in other channels about the "learning to read" error
>> messages part and I think you've taken it entirely the wrong way or maybe I
>> just disagree. There are benefits from reporting errors in a generic,
>> consistent way. […]
>>
>>
>> Do there exist examples of what is desired for error messages in
>> 1.9-final? Not promises, but a “this is what we’re shooting for”? What
>> would you all like the specific error messages complained about in this
>> thread to look like?
>>
>> Colin Fleming wrote: "The error message produced by the code I demoed at
>> the conj last year would be:
>>
>> Unexpected symbol 'require' at  while parsing
>> namespace clauses. Expected :refer-clojure, :require, :use, :import, :load
>> or :gen-class.”
>>
>> Is that the goal? I fear that the goal is that it should be my job to
>> understand "(cat :attr-map (? map?) :clauses 
>> :clojure.core.specs/ns-clauses)”.
>> For what little it’s worth, I consider that completely unacceptable.
>>
>> - Getting the error data (specifically the explain-data output) to be
>> both sufficient and generically useful is the first priority. I think at
>> this point that's pretty close and unlikely to change significantly.
>>
>>
>> My bias here is that I come from the learned-from-bitter-experience
>> tradition that believes it’s very risky to (1) get the infrastructure
>> right, and then (2) pop down the user-visible features on top of it. Very
>> often, the infrastructure turns out to be a poor match for the actual needs
>> of the features. But, since (1) is already done, the features - and
>> consequently the users - suffer.
>>
>> Please understand I’m not being insulting when I say that everyone has
>> weaknesses and blind spots, even undoubted geniuses. In Clojure, error
>> messages and documentation (especially doc strings) have long been glaring
>> weaknesses. So I am wishing to be helpful when I counsel *quickly* getting
>> to worked examples of output, especially output that novices are likely to
>> encounter. And exposing those messages to typical users, ones who are not
>> familiar with core.spec.
>>
>> That seems prudent.
>>
>> I believe strongly enough in good error messages that I would be willing
>> to do some of the scut work, if needed.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Colin Fleming]

The error message I posted earlier comes right out of the parser with very
little infrastructure on top of it. It certainly doesn't require a 200MB
jar, more like 300 lines of code, including the parser itself.

On 24 August 2016 at 02:21, Timothy Baldridge <tbaldri...@gmail.com> wrote:

> So personally, I don't want extremely accurate suggestions in the core of
> Clojure. Why? Because I think they will never go far enough and I have a
> ton of features I want to see that can't (shouldn't) be in the core of a
> language.
>
> I'll never forget the first undefined symbol I got in Clang after
> switching from GCC. When I say "undefined local 'val' did you mean
> 'vals'?". I was floored, what was this magic?
>
> When I sit down and write a laundry list of things I would like to see in
> error reporting for spec:
> - Spelling suggestions: "did you mean :require instead of :requir?"
> - Type suggestions: "you passed a symbol did you want a keyword?"
> - Phonetic suggestions: "you passed :color, did you mean :colour?"
> - Structural suggestions: "you passed [[42]] did you mean [42]?"
>
> Most (all) of these are way too broad for inclusion in the core of a
> language (imo), not to mention the problems you'd hit with multi-lingual
> support. So I say to all that, give me data and let 3rd parties write the
> libraries. I'd much rather have a 200MB "error reporter" lib in my
> {:profiles {:dev ...}} than included in the clojure.jar.
>
> Anyway, that's my 2cents. And if someone doesn't write that library for me
> soon, I may have to :)
>
> Timothy
>
> On Tue, Aug 23, 2016 at 7:47 AM, Brian Marick <mar...@roundingpegs.com>
> wrote:
>
>>
>> On Aug 22, 2016, at 7:50 PM, Alex Miller <a...@puredanger.com> wrote:
>>
>>
>> You've complained in other channels about the "learning to read" error
>> messages part and I think you've taken it entirely the wrong way or maybe I
>> just disagree. There are benefits from reporting errors in a generic,
>> consistent way. […]
>>
>>
>> Do there exist examples of what is desired for error messages in
>> 1.9-final? Not promises, but a “this is what we’re shooting for”? What
>> would you all like the specific error messages complained about in this
>> thread to look like?
>>
>> Colin Fleming wrote: "The error message produced by the code I demoed at
>> the conj last year would be:
>>
>> Unexpected symbol 'require' at  while parsing
>> namespace clauses. Expected :refer-clojure, :require, :use, :import, :load
>> or :gen-class.”
>>
>> Is that the goal? I fear that the goal is that it should be my job to
>> understand "(cat :attr-map (? map?) :clauses 
>> :clojure.core.specs/ns-clauses)”.
>> For what little it’s worth, I consider that completely unacceptable.
>>
>> - Getting the error data (specifically the explain-data output) to be
>> both sufficient and generically useful is the first priority. I think at
>> this point that's pretty close and unlikely to change significantly.
>>
>>
>> My bias here is that I come from the learned-from-bitter-experience
>> tradition that believes it’s very risky to (1) get the infrastructure
>> right, and then (2) pop down the user-visible features on top of it. Very
>> often, the infrastructure turns out to be a poor match for the actual needs
>> of the features. But, since (1) is already done, the features - and
>> consequently the users - suffer.
>>
>> Please understand I’m not being insulting when I say that everyone has
>> weaknesses and blind spots, even undoubted geniuses. In Clojure, error
>> messages and documentation (especially doc strings) have long been glaring
>> weaknesses. So I am wishing to be helpful when I counsel *quickly* getting
>> to worked examples of output, especially output that novices are likely to
>> encounter. And exposing those messages to typical users, ones who are not
>> familiar with core.spec.
>>
>> That seems prudent.
>>
>> I believe strongly enough in good error messages that I would be willing
>> to do some of the scut work, if needed.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/c

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Colin Fleming]

>
> The big syntax macro cases like ns or let are way past the "average" spec.
> ... I don't think it's fair to judge the general performance of spec's
> errors on just those use cases.


It might be true that these macros are larger than usual, but they're also
the cases that everyone will encounter all the time, particularly new users
trying to figure out the language syntax.

On 23 August 2016 at 12:55, Alex Miller <a...@puredanger.com> wrote:

>
> On Monday, August 22, 2016 at 7:43:53 PM UTC-5, Colin Fleming wrote:
>>
>> I agree that the ability to get a machine-readable parse failure is very
>> important for tooling. However I feel very strongly that the error messages
>> that are printed by default on macro validation failures should be easily
>> understandable, and the current ones are not. If we completely punt to
>> tooling for this, firstly users will receive different (and different
>> quality) error messages depending on the tool they're using, and anyone
>> using plain vanilla Clojure will not get good errors at all.
>>
>
> I largely agree..
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Colin Fleming]

I agree that the ability to get a machine-readable parse failure is very
important for tooling. However I feel very strongly that the error messages
that are printed by default on macro validation failures should be easily
understandable, and the current ones are not. If we completely punt to
tooling for this, firstly users will receive different (and different
quality) error messages depending on the tool they're using, and anyone
using plain vanilla Clojure will not get good errors at all.

On 23 August 2016 at 11:45, Oliver George  wrote:

>
> I'm interested to see any discussion regarding this point.  No doubt
> translating spec data into more friendly formats has been discussed.
>
> Getting the data right is clojure's problem.  That's the concrete
> foundation and building blocks required for tooling.  Seems like Rich has
> done spectacularly there.
>
> Potentially it's up to tooling to do more with that data.  I'd love to
> hear Bruce (figwheel), Collin's (cursive) and Bozhidar (cider) opinions
> about that.
>
>
> On Tuesday, 23 August 2016 08:11:27 UTC+10, Brian Marick wrote:
>>
>>
>> On Aug 22, 2016, at 11:23 AM, Leon Grapenthin 
>> wrote:
>>
>> Still the error messages are simply far from good enough and that is what
>> appears to me as the main problem OP has.
>>
>>
>> This is important. Will the new, stricter error messages be improved
>> before 1.9 is finalized?
>>
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Colin Fleming]

I think there's considerable scope to produce better error messages
automatically than what spec produces, and I hope that can happen for 1.9.
The error message produced by the code I demoed at the conj last year would
be:

Unexpected symbol 'require' at  while parsing
namespace clauses. Expected :refer-clojure, :require, :use, :import, :load
or :gen-class.

The only thing the grammar developer needs to do to get that error is to
provide a descriptive name of "namespace clauses" for the main alternation.
If they don't do that, the error message would just say "...while parsing
clojure.core/ns..." instead, which is still acceptable.

There is plenty of prior art on how to do this, it's not a "people are
hard" problem. I think the precise error messages you want for validating
data structures are not optimal for code error messages. I know the mantra
is that code is data, but in this case I believe that a specialised
implementation for code is superior. But I realise that ship has sailed.

On 21 August 2016 at 02:03, Alex Miller  wrote:

>
>
> On Saturday, August 20, 2016 at 5:17:59 AM UTC-5, Brian Marick wrote:
>>
>> Yesterday, a bug was filed against Suchwow under 1.9alpha11. It turns out
>> to have been a use of `ns …(require…` instead of `(ns …(:require`. Not in
>> Suchwow, but in Midje. Unfortunately, the Suchwow file the bug report
>> pointed at *also* had that typo - apparently I am prone to it - so adding
>> the colon to the require there didn’t make the problem go away.
>>
>> That caused me to lose my temper and make a fool of myself, which is
>> neither here nor there, except that I apologize to @puredanger.
>>
>> I have two suggestions, though:
>>
>> 1. It has long been the case that Clojure allowed `(ns (require…)` even
>> though that’s strictly incorrect. I suggest that, for backwards
>> compatibility, it be allowed going forward. That is, I think it does no
>> harm for a correct `ns` statement to allow symbols as well as keywords.
>> That wrong code in Midje has been there since Clojure 1.2.
>>
>
> We discussed this before releasing the specs and decided to start on the
> strict side. That said, this is still an alpha and there is plenty of time
> to change our minds prior to official release of 1.9 if that ends up being
> a catastrophic decision.
>
>
>>
>> 2. The following is not a good error message:
>>
>> Exception in thread "main" java.lang.IllegalArgumentException: Call to
>> clojure.core/ns did not conform to spec:
>> In: [2] val: ((require [such.vars :as var] [such.immigration :as
>> immigrate]) (require midje.checking.checkers.defining
>> midje.checking.checkers.chatty midje.checking.checkers.simple
>> midje.checking.checkers.combining midje.checking.checkers.collection))
>> fails at: [:args] predicate: (cat :attr-map (? map?) :clauses
>> :clojure.core.specs/ns-clauses),  Extra input
>>
>
> You left out this next important line too since it points you to exactly
> the file and line where the error occurs:
>
> , compiling:(such/sequences.clj:1:1)
>
> spec produces very detailed error messages driven by the specs and the
> value being validated. I admit that in some cases the output from a spec
> error (particularly for complicated syntaxes where there are wide
> alternative fan-outs) is daunting. However, spec error messages are going
> to be increasingly common for all of us to see and understand and I think
> it is worth taking the time to slow down and actually read them.
>
> > Call to clojure.core/ns did not conform to spec:
>   ^^ <- macro that was passed invalid values
> > In: [2]
> ^^^ <- the data path in the :args passed to the macro, here, the
> 2th element is the require clause (ns = 0, such.sequences = 1)
>
> > val: ((require [such.vars :as var] ...)
>  ^^ <- the remaining part of the value that did not match (it has
> already matched or "consumed" the first two elements successfully)
>
> > fails at: [:args]
>^^ <- the path in the ns fdef spec to the failure point
>
> > predicate: (cat :attr-map (? map?) :clauses
> :clojure.core.specs/ns-clauses),
> ^^^etc -> the remaining part of the spec it was trying
> to match
>
> > Extra input
>   specs way of saying that it found something (the val above) but it
> wasn't what the spec expected next
>
>
> I'm not trying to pretend this is as easy to digest as an error message
> that would be produced by hand-written validation and error code, but it's
> also notoriously difficult to cover all possible cases (which is why the
> Clojure DSLs have so many error gaps despite having a lot of that code). We
> are looking to decrease the amount of custom error detection and reporting,
> so anything we do has to be something we can do generically.
>
> For the specific case of macroexpanded error reporting, I think there
> *are* more things we can do here (generically) that will improve
> readability. We *know* we are in the context of checking an 

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[Colin Fleming]

With respect to preserving undocumented behaviour, while in general I'm in
favour of making compilers stricter, in this case it seems like the change
breaks a lot of existing code in ways that are impossible for library
consumers to fix themselves - they have to wait for an update to the
library, or fork it. Leaving the symbol option seems like a very low-impact
change, it's not going to be a massive amount of technical debt in Clojure
itself. There are many areas of unspecified behaviour in the reader (for
example, keywords starting with numbers, the keyword function allowing
creation of unreadable keywords etc) which have not been fixed because it
would break some existing code - I suspect the impact of fixing that would
be far less than the impact of this change.

I don't understand why this particular change is so important that
significant breakage to real code is considered acceptable. I agree with
Brian that it doesn't seem very pragmatic.

On 21 August 2016 at 13:22, Brian Marick  wrote:

>
> On Aug 20, 2016, at 6:30 PM, Timothy Baldridge 
> wrote:
>
> Brian, let's make it more concrete then...why should the Clojure compiler
> continue to support undocumented features that make code unportable?
>
>
> Because:
>
> 1. People who want to port to clojurescript will incur exactly the same
> cost as they do now.
> 2. People who don’t want to port to clojurescript will incur no additional
> cost.
> 3. Clojurescript maintainers will incur no additional cost.
> 4. Clojure maintainers will incur the cost of adding “or symbol” to
> current code.
> 5. No one writing documentation will incur any cost, as what was not
> mentioned before will continue to be unmentioned.
>
> 6. There will be a psychic cost because of an undocumented inconsistency
> between clojure and clojurescript.
> 7. If, at some point, clojure and clojurescript shared code for the
> implementation of `ns`, one or the other would have to change the pre
> 1.9-alpha11 behavior.
>
> Do I have this enumeration of costs wrong?
>
> It’s a bit surprising to me that my explicit appeal to consider costs and
> benefits to real people is not being addressed.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Clojure 1.9.0-alpha11

[Colin Fleming]

>
> (ns ... (require ...) (import ...) )  instead of (ns ... (:require ...)
> (:import ...) )


Is this not intended to be allowed? The docstring implies no but it has
always worked fine - I wouldn't call the code broken.

Does the spec also limit the refs
to refer-clojure/require/use/import/load/gen-class rather than allowing,
say, println? One not on that list that I have seen people using in the
wild is refer.

On 20 August 2016 at 06:35, Alex Miller  wrote:

> One thing to note is that the new specs for clojure.core means that there
> is a reasonable amount of (broken) code in the wild that now does not
> compile.
>
> I have filed PRs in a number of commonly used projects and while those
> were all merged, most have not yet been released into new versions yet. Any
> project that uses any of those projects via dependencies will also have
> issues. So, expect to see some breakage if using the latest alpha. In
> particular, ClojureScript itself had a bad ns declaration through version
> 1.9.93 so anything not on a fresh CLJS will likely see that.
>
> The three most common things I saw were:
>
> 1. (ns ... (require ...) (import ...) )  instead of (ns ... (:require ...)
> (:import ...) )
>
> 2. (fn a.b [] ...) - fully-qualified symbol names in fn (these are pretty
> much always the result of a sloppy macro that expands to fn)
>
> 3. (let [{ ... :or {:a 1}} {}] ... ) - :or keys that are not simple
> symbols. There were some accidental cases where this did something for
> fully-qualified keyword keys in the past, but those were not intended and
> are no longer accepted as of Clojure 1.9.0-alpha8. All of the cases I found
> were actually typos though where the keyword was used instead of the symbol.
>
>
>
>
> On Friday, August 19, 2016 at 1:15:06 PM UTC-5, Alex Miller wrote:
>>
>> Clojure 1.9.0-alpha11 is now available.
>>
>> Try it via
>>
>> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-
>> alpha11
>> - Leiningen: [org.clojure/clojure "1.9.0-alpha11"]
>>
>> 1.9.0-alpha11 includes the following changes since 1.9.0-alpha10:
>>
>> Clojure now has specs for the following clojure.core macros: let, if-let,
>> when-let, defn, defn-, fn, and ns. Because macro specs are checked during
>> macroexpansion invalid syntax in these macros will now fail at compile time
>> whereas some errors were caught at runtime and some were not caught at all.
>>
>> - CLJ-1914 - Fixed race condition in concurrent range realization
>> - CLJ-1870 - Fixed reloading a defmulti removes metadata on the var
>> - CLJ-1744 - Clear unused locals, which can prevent memory leaks in some
>> cases
>> - CLJ-1423 - Allow vars to be invoked with infinite arglists (also,
>> faster)
>> - CLJ-1993 - Added *print-namespace-maps* dynamic var that controls
>> whether to use namespace map syntax for maps with keys from the same
>> namespace. The default is false, but standard REPL bindings set this to
>> true.
>> - CLJ-1985 - Fixed with-gen of conformer losing unform fn
>> - Fixed clojure.spec.test/check to skip spec'ed macros
>> - Fixed regression from 1.9.0-alpha8 where type hints within
>> destructuring were lost
>> - Fixed clojure.spec/merge docstring to note merge doesn't flow conformed
>> values
>> - Fixed regex ops to use gen overrides if they are used
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Multi-OS Engine | Intel(R) Software

[Colin Fleming]

Looks like MOSE uses Android's ART (from
https://software.intel.com/en-us/node/633226):

Multi-OS Engine Runtime is based on the modern Android ART*, which is the
> runtime component of Android that runs Java apps.
> ART has a list of features that provide optimal performance for apps on
> iOS devices:
>
>- Ahead-of-time (AOT) compilation, which can improve app performance.
>
>
>- Use of the same Java runtime libraries as Android, which simplify
>cross-platform app development.
>
>
>- Enhanced memory management and garbage collection.
>
> A compiled Multi-OS Engine app contains the following components:
>
>- Compiled Java sources.
>
>
>- Resources.
>
>
>- Standard (iOS) library bindings.
>
>
>- Third party native libraries and bindings.
>
>
>- Nat/J native library for the Java to native binding that enables the
>implementation of native classes and functions in pure Java and makes them
>available to the native side.
>
>
>- The specialized ART virtual machine (VM) with Multi-OS Engine ART
>enhancements.
>
> I'm not sure what the state of compiling Clojure to ART is, I guess you
could AOT and then convert the bytecode to Dalvik. It would be an
interesting experiment, for sure.

On 10 August 2016 at 08:25, Daniel Compton 
wrote:

> Following up, it seems like it may be possible to use Clojure with MOSE,
> but it doesn’t look like a well worn path. Also, I suspect if you went down
> this route you may end up writing mostly Java in a funny domain specific
> language with lots of parentheses. All that being said, I’d be happy to be
> proven wrong :)
>
> https://groups.google.com/forum/#!topic/robovm/b3jbTcpq1Xo
> https://software.intel.com/en-us/forums/multi-os-engine/topic/640308
> https://github.com/moe-java-samples/moe-kotlin-samples
>
>
> On Wed, Aug 10, 2016 at 8:09 AM Daniel Compton <
> daniel.compton.li...@gmail.com> wrote:
>
>> I had a look at this a few weeks ago, and it seemed like it would only
>> work with Java code, not JVM bytecode?
>>
>> Internal Overview:
>>
>> Multi-OS Engine facilitates Java* support on iOS* through
>>
>>- Auto Java binding generation from ObjectiveC and C header files
>>from existing libraries or 3rd party packages
>>- Java* annotations and NatJ* runtime library
>>- Eliminating the need to write JNI functions
>>- Prebuilt jar files interfacing iOS* API are provided in the
>>Multi-OS Engine, so you can start coding iOS* app in Java* immediately.
>>
>> I looked around and couldn’t find any lower level details of what they
>> were doing, but all of the documentation seems to suggest you need to write
>> Java. I’d be very happy to be proven wrong though :)
>>
>> On Sat, Aug 6, 2016 at 7:47 AM Gregg Reynolds  wrote:
>>
>>> For those interested in mobile clojure, I just discovered this.  Haven't
>>> tried it but it sounds good:
>>>
>>> https://software.intel.com/en-us/multi-os-engine?utm_source=
>>> Develop+Blog+http://www.develop-online.net/_
>>> medium=Text+Link_campaign=Android_EMEA_Q2-16_Developer-
>>> Blog_Blog-Page?29062016
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> —
>> Daniel
>>
> --
> —
> Daniel
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Implementing a generic parameterized Java interface so that it satisfies (instance? ParameterizedType)

[Colin Fleming]

The JVM does retain some generic information (see for example Neil Gafter's
Super Type Tokens), in particular Type instances can retain generic info
which is what the linked code is using. It might be possible to recreate
this in pure Clojure but IMO it's likely to be more difficult than it's
worth - all the reflective Type code is very fiddly. YMMV, of course.

On 5 August 2016 at 11:18, Timothy Baldridge <tbaldri...@gmail.com> wrote:

> I'd dig into it a bit more, since the JVM doesn't support generics either.
> So if there's an api looking for some marker interfaces, it might be
> possible to implement those interfaces as well. There's probably a way to
> do this in pure Clojure.
>
> On Thu, Aug 4, 2016 at 4:55 PM, Colin Fleming <colin.mailingl...@gmail.com
> > wrote:
>
>> Hi Jakub,
>>
>> Yes, that is correct - Clojure interop only deals with raw classes, it
>> has no concept of generics. Java is the way to go here.
>>
>> Cheers,
>> Colin
>>
>> On 5 August 2016 at 09:28, Jakub Holý <jakubholy@gmail.com> wrote:
>>
>>> I need to implement the interface javax.websocket.
>>> MessageHandler.Whole - the type parameter is important since
>>> the Java code uses reflection to check
>>> <https://github.com/tyrus-project/tyrus/blob/373fab2f47ff06167d6ced8475085004ffbbfd5a/core/src/main/java/org/glassfish/tyrus/core/ReflectionHelper.java#L528>
>>> whether the result is instanceof java.lang.reflect.ParameterizedType.
>>>
>>> I believe I cannot use proxy or any other available Clojure mechanism
>>> as they do not support generics. Is that correct?
>>>
>>> I believe that the only (and best) solution is to implement the
>>> interface in Java and then possibly extend the resulting class:
>>>
>>> public class TextMessageHandler implements 
>>> javax.websocket.MessageHandler.Whole
>>> {
>>> public void onMessage(String message) {
>>> }
>>> }
>>> 
>>> (proxy [TextMessageHandler] []
>>> (onMessage [msg]
>>>   (println "received message(" (.getClass msg) "):" msg)))
>>>
>>>
>>> Correct?
>>>
>>> Thank you!
>>>
>>> Cheers, Jakub Holý
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> “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 m

Re: Implementing a generic parameterized Java interface so that it satisfies (instance? ParameterizedType)

[Colin Fleming]

Hi Jakub,

Yes, that is correct - Clojure interop only deals with raw classes, it has
no concept of generics. Java is the way to go here.

Cheers,
Colin

On 5 August 2016 at 09:28, Jakub Holý  wrote:

> I need to implement the interface javax.websocket.
> MessageHandler.Whole - the type parameter is important since the
> Java code uses reflection to check
> 
> whether the result is instanceof java.lang.reflect.ParameterizedType.
>
> I believe I cannot use proxy or any other available Clojure mechanism as
> they do not support generics. Is that correct?
>
> I believe that the only (and best) solution is to implement the interface
> in Java and then possibly extend the resulting class:
>
> public class TextMessageHandler implements 
> javax.websocket.MessageHandler.Whole
> {
> public void onMessage(String message) {
> }
> }
> 
> (proxy [TextMessageHandler] []
> (onMessage [msg]
>   (println "received message(" (.getClass msg) "):" msg)))
>
>
> Correct?
>
> Thank you!
>
> Cheers, Jakub Holý
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ClojureScript] ANN: The REPL, a weekly Clojure/Script newsletter

[Colin Fleming]

Thanks for The REPL, I've been enjoying it very much. I like that it also
has information related to Clojure but not Clojure-specific, such as JVM
performance posts. Nice work!

Cheers,
Colin

On 27 July 2016 at 09:20, Daniel Compton 
wrote:

> Hi folks
>
> I’ve started a weekly Clojure and ClojureScript newsletter called The
> REPL. It covers what’s new (and old) in Clojure, as well as related topics
> (Lisp, JVM, e.t.c.).
>
> You can sign up at http://therepl.net, and see a copy of the latest issue
> here
> 
> .
>
> Thanks, Daniel.
> --
> —
> Daniel
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/clojurescript.
>

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

[Colin Fleming]

What I do for Leiningen in Cursive is basically mimic what the lein script
does, and download the uberjars to .lein/self-installs, and then run
processes with those on the classpath. Would something similar for Boot
work? As I understand it, boot.sh is just a tricky wrapper around an
embedded jar, so hopefully that would work. I'm also selfishly interested
in this because I don't support boot yet but I want to.

On 14 July 2016 at 14:12, Zach Oakes  wrote:

> If I get desperate I may do that, but the main users I care about are
> beginners, and they generally have trouble installing CLI tools. I'm hoping
> it is a trivial fix and I'll be able to get Boot working in 2.1.0 :)
>
> On Wednesday, July 13, 2016 at 9:44:50 PM UTC-4, Mark wrote:
>>
>> How about, until the issues are resolved, you require boot to be
>> installed?
>> On Jul 13, 2016 6:52 PM, "Zach Oakes"  wrote:
>>
>>> That Boot tab is quite a tease ;) I wanted to finish support for it so
>>> bad, but technical difficulties prevented me from doing it. I definitely
>>> plan to still do so, and any help would be appreciated.
>>>
>>> The issue is actually pretty simple: I need to be able to call Boot
>>> commands without having Boot installed. I do so for Leiningen by literally
>>> adding it as a dependency and calling its build commands programatically.
>>> Boot simply isn't designed to work that way.
>>>
>>> After talking to the Boot folks, they suggested I add Boot.java
>>>  to my
>>> project and start a process that calls its main method with the appropriate
>>> task names. Easy enough, but that does not actually work. It turns out that
>>> AOT compilation causes this java file to not behave correctly.
>>>
>>> If anyone is interested in investigating this, I created a minimal case
>>> for this issue here: https://github.com/oakes/boot-clj-issue
>>>
>>> Once that is resolved, it will be pretty trivial to enable building Boot
>>> projects.I actually would like to make the built-in templates use Boot by
>>> default instead of Leiningen. Boot scripts in particular will be awesome
>>> for beginners.
>>>
>>> On Wednesday, July 13, 2016 at 6:44:01 PM UTC-4, Sean Corfield wrote:

 I see a Boot tab in the REPL area but looking at the source code,
 detecting build.boot is disabled (and, indeed, I can’t get NC to recognize
 any of my Boot-only projects).



 Can you speak to where you are on Boot support?



 Thanks,

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

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



 On 7/13/16, 10:58 AM, "Zach Oakes"  wrote:

 TL;DR: Nightcode, a Clojure IDE, just got a makeover:
 https://sekao.net/nightcode/





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

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

Re: [ANN] Clojure 1.9.0-alpha8

[Colin Fleming]

Is there a JIRA with details on the namespaced keyword changes?

On 29 June 2016 at 11:48, Leon Grapenthin  wrote:

> This is fantastic. Spec really seems to turn out like a "killer-feature"
> for Clojure.
>
> On Wednesday, June 29, 2016 at 12:13:25 AM UTC+2, Alex Miller wrote:
>>
>> Clojure 1.9.0-alpha8 is now available.
>>
>> Try it via
>>
>> - Download:
>> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha8
>> - Dependency: [org.clojure/clojure "1.9.0-alpha8"]
>>
>> 1.9.0-alpha8 includes the following changes since 1.9.0-alpha7:
>>
>> The collection spec support has been greatly enhanced, with new controls
>> for conforming, generation, counts, distinct elements and collection kinds.
>> See the docs for every, every-kv, coll-of and map-of for details.
>>
>> instrumenting and testing has been streamlined and made more composable,
>> with powerful new features for spec and gen overrides, stubbing, and
>> mocking. See the docs for these functions in clojure.spec.test: instrument,
>> test, enumerate-ns and summarize-results.
>>
>> Namespaced keyword reader format, printing and destructuring have been
>> enhanced for lifting namespaces up for keys, supporting more succinct use
>> of fully-qualified keywords. Updated docs will be added to clojure.org
>> soon.
>>
>> Many utilities have been added, for keys spec merging, fn exercising,
>> Java 1.8 timestamps, bounded-count and more.
>>
>> Changelog:
>>
>> clojure.spec:
>>
>> - [changed] map-of - now conforms all values and optionally all keys, has
>> additional kind, count, gen options
>> - [changed] coll-of - now conforms all elements, has additional kind,
>> count, gen options. No longer takes init-coll param.
>> - [added] every - validates a collection by sampling, with many
>> additional options
>> - [added] every-kv - validates a map by sampling, with many additional
>> options
>> - [added] merge
>> - [changed] gen overrides can now be specified by either name or path
>> - [changed] fspec generator - creates a function that generates return
>> values according to the :ret spec and ignores :fn spec
>> - [added] explain-out - produces an explain output string from an
>> explain-data result
>> - [changed] explain-data - output is now a vector of problems with a
>> :path element, not a map keyed by path
>> - [added] get-spec - for looking up a spec in the registry by keyword or
>> symbol
>> - [removed] fn-spec - see get-spec
>> - [added] exercise-fn - given a spec'ed function, returns generated args
>> and the return value
>> - All instrument functions moved to clojure.spec.test
>>
>> clojure.spec.test:
>>
>> - [changed] instrument - previously took a var, now takes either a
>> symbol, namespace symbol, or a collection of symbols or namespaces, plus
>> many new options for stubbing or mocking. Check the docstring for more info.
>> - [removed] instrument-ns - see instrument
>> - [removed] instrument-all - see instrument
>> - [changed] unstrument - previously took a var, now takes a symbol,
>> namespace symbol, or collection of symbol or namespaces
>> - [removed] unstrument-ns - see unstrument
>> - [removed] unstrument-all - see unstrument
>> - [added] instrumentable-syms - syms that can be instrumented
>> - [added] with-instrument-disabled - disable instrument's checking of
>> calls within a scope
>> - [changed] check-var renamed to test and has a different signature,
>> check docs
>> - [changed] run-tests - see test
>> - [changed] run-all-tests - see test
>> - [changed] check-fn - renamed to test-fn
>> - [added] abbrev-result - returns a briefer description of a test
>> - [added] summarize-result - returns a summary of many tests
>> - [added] testable-syms - syms that can be tested
>> - [added] enumerate-namespace - provides symbols for vars in namespaces
>>
>> clojure.core:
>>
>> - [changed] - inst-ms now works with java.time.Instant instances when
>> Clojure is used with Java 8
>> - [added] bounded-count - if coll is counted? returns its count, else
>> counts at most first n elements of coll using its seq
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: more minimal clojurescript intro/app

[Colin Fleming]

Hi Lee,

Here's another recent interesting post:
http://blog.klipse.tech/clojure/2016/06/07/klipse-plugin-tuto.html. This
looks like it might be very useful for you.

Cheers,
Colin

On 12 June 2016 at 11:03, 'Lee' via Clojure 
wrote:

>
> Just an update on this and thanks:
>
> Several people provided helpful pointers, leading me on interesting paths
> and teaching me about cool things like hoplon.
>
> The thing that most easily and fully solved my problem was:
> https://github.com/fasiha/re-simple-term. Ahmed Fasih (fasiha) was super
> helpful and produced a really clean and simple way to put a function call
> on a web page, for people who are not web/javascript programmers and just
> want to put a Clojurescript function on a web page. I recommend it!
>
> If you look at the thing that I made with it, you will immediately confirm
> that I'm not a web designer :-), and you will probably also be pretty
> baffled by the content unless you are a mathematician (and maybe even then,
> because the paper it's based on is still in press):
> http://hampshire.edu/lspector/dda (and let me know if you want a
> pre-print of the paper).
>
> But it does exactly what I need, and fasiha's project let me put this
> online without knowing stuff that I haven't had time to learn.
>
> FYI the other approach that currently seems most promising to me, for
> related projects, is to put up a REPL using
> https://github.com/Lambda-X/re-console/tree/init-demo. Thanks to Andrea
> Richiardi and Tomek on this. I haven't yet got it fully working, but when I
> do I think it will be useful in my world of
> programmers-but-not-web-programmers, for putting online things ranging from
> text adventure games to genetic programming systems.
>
>  -Lee
>
>
> On Saturday, March 26, 2016 at 11:06:50 AM UTC-4, Lee wrote:
>>
>> Hi all,
>>
>> I have a pure Clojure program and I would like to make it run in the
>> browser on client machines. It has no dependencies other than Clojure, it
>> does no Java interop, and it has no GUI. There's no database, no user
>> interaction (except for starting the program), and no networking. It just
>> computes something and prints text (which goes to the REPL in the Clojure
>> version). From what I've read, it should run exactly the same in
>> Clojurescript with no changes.
>>
>> For the sake of argument -- and this isn't very far from the truth --
>> let's say that I have absolutely no web programming experience, and that I
>> don't know how to run Clojurescript at all (although I've been using
>> Clojure for many years). I can produce basic HTML files and I can put files
>> on a server in a public directory with a known URL, but that's it in terms
>> of web "programming." And let's suppose that I know absolutely nothing
>> about Javascript.
>>
>> Can anybody tell me or point me to a resource that will tell me how to
>> get my Clojure program running as a Clojurescript program in a web page?
>> Ideally, I would like to do this without learning a lot about Javascript or
>> web programming. I just want this existing, pure Clojure program to run in
>> a client's browser, running a computation and providing text output.
>>
>> Searching for "minimal clojurescript" turns up things much less minimal,
>> assuming that I know more about Javascript and/or web programming, and/or
>> that I want something more sophisticated than I've outlined here.
>>
>> If I can get this working then I will eventually want something
>> *slightly* more complex in terms of user interaction: a text field on the
>> page into which the user can type, and from which my program can read. But
>> aside from this, and I guess a "Start" button, I need no GUI.
>>
>> I would appreciate any pointers that anyone can provide!
>>
>> Thanks,
>>
>>  -Lee
>>
>>
>>
>>
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Deep transients

[Colin Fleming]

BTW if you're interested in Specter, Brian Marick has an interesting book
which aims to teach Specter by implementing it: https://leanpub.com/specter.
I bought it but haven't had time to work through it yet, but from an
initial skimming it looks very nice.

On 3 June 2016 at 16:11, Mark Engelberg <mark.engelb...@gmail.com> wrote:

> That's an interesting idea.  Maybe there's a way to build a set of Specter
> navigators that operate on transients, and then use its corresponding
> eqiuvalences for assoc-in, update-in, etc.
>
> On Thu, Jun 2, 2016 at 9:01 PM, Colin Fleming <colin.mailingl...@gmail.com
> > wrote:
>
>> Have you looked at Specter? I actually don't know if it uses transients
>> under the hood or not, or if you can make it do so, but it seems like a
>> good fit for the data manipulation problem, at least.
>>
>> On 3 June 2016 at 14:43, Mark Engelberg <mark.engelb...@gmail.com> wrote:
>>
>>> Let's say I have an object represented by a series of nested maps:
>>>
>>> {:a {:b 1} :c {:d 2}}
>>>
>>> and now I'm going to be making a whole slew of edits to the submaps.
>>>
>>> To do this efficiently, I need to make all the levels of the map
>>> transients, because any update to the inner map also updates the outer map:
>>>
>>> (transient {:a (transient {:b 1}), :c (transient {:d 2})})
>>>
>>> and then at the end I need to do a nested persistent! operation.
>>>
>>> However, there aren't good facilities for dealing with nested
>>> transients, for example, there's no assoc!-in.  So it's a real pain to work
>>> with.
>>>
>>> Has anyone dealt with this already, and developed a suite of tools for
>>> working with nested transients, or other techniques for making batch
>>> updates efficient for deeply nested objects?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Colin Fleming]

Have you looked at Specter? I actually don't know if it uses transients
under the hood or not, or if you can make it do so, but it seems like a
good fit for the data manipulation problem, at least.

On 3 June 2016 at 14:43, Mark Engelberg  wrote:

> Let's say I have an object represented by a series of nested maps:
>
> {:a {:b 1} :c {:d 2}}
>
> and now I'm going to be making a whole slew of edits to the submaps.
>
> To do this efficiently, I need to make all the levels of the map
> transients, because any update to the inner map also updates the outer map:
>
> (transient {:a (transient {:b 1}), :c (transient {:d 2})})
>
> and then at the end I need to do a nested persistent! operation.
>
> However, there aren't good facilities for dealing with nested transients,
> for example, there's no assoc!-in.  So it's a real pain to work with.
>
> Has anyone dealt with this already, and developed a suite of tools for
> working with nested transients, or other techniques for making batch
> updates efficient for deeply nested objects?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Clojure 1.9.0-alpha1

[Colin Fleming]

I'll also need a spec translator (from s/form or s/describe, I guess - I'm
not clear on the difference), and I'm very interesting in seeing any
details if someone gets to it before I do.

Cheers,
Colin

On 25 May 2016 at 12:38, Timothy Baldridge  wrote:

> The output of `spec/form` is helps a bit with this, as it namespaces vars,
> keywords and symbols correctly. I've had it on my list to write a
> translator for specs sometime in the near future, but I haven't done it
> yet. True the output of `form` isn't as uniform as I would like (sexprs
> instead of maps) but I don't think it would be too much work.
>
> Timothy
>
> On Tue, May 24, 2016 at 6:26 PM, Leif  wrote:
>
>> Hi, Alex, thanks for the responsiveness.
>>
>> The paths refer to tags in the schemas, not keys in the map. However,
>>> this has been asked about several times today and Rich has added support
>>> for a :in clause that will track the key paths to master and that will be
>>> in alpha2.
>>>
>>
>>  Where is this discussion thread?  I wouldn't want to ask duplicate
>> questions.
>>
>>
>>> Is there a recommended way to introspect specs for our own purposes
>>> (coercion, code generation)?  An interpreter on the output of 'describe'
>>> might work (although it's a little complicated for fn specs), but I wanted
>>> to know if you all had any thoughts or plans for the future here.
>>>
>>
>>
>>> Could you give more details on what question you would like to ask?
>>>
>>
>> Better people to ask would be those that have a lot of experience writing
>> translators for specs, like the Schema devs.  But I'll give my muddled
>> thoughts here:
>>
>> Right now, the internals of different instances of Spec are private.  So,
>> to write a translator from a Spec to the approximate json or avro schema it
>> specifies, or translate from a Spec to a function that coerces a String to
>> a data structure that conforms, I would have to:
>>
>> 1. Parse the output of 'describe' back into a description of the Spec's
>> internals (if I can get at all of them)
>> 2. Interpret / translate the parsed tree
>>
>> In fact, the current Spec protocol, in my mind, is actually 4 protocols,
>> one for 4 different translators you all have written:
>>
>> (defprotocol Spec
>>   ;; Spec->Conformer
>>   (conform* [spec x])
>>   :: Spec->Explainer
>>   (explain* [spec path via x])
>>   ;; Spec->Gen
>>   (gen* [spec overrides path rmap])
>>   (with-gen* [spec gfn])
>>   ;; Spec->Describer
>>   (describe* [spec]))
>>
>> But this implementation hiding dooms clojure/core to write *all* the
>> translators.  This just seems weird given how most other Clojure features
>> are open and user-extensible.
>>
>> --Leif
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@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.
>

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

Re: CCW stopped working. How do I fix it?

[Colin Fleming]

On 5 May 2016 at 00:46, Fluid Dynamics  wrote:

> Doesn't cursive (or its host) cost money and emacs cost gray hairs?
>

Cursive is free but not OSS for non-commercial use, and it works fine with
the IntelliJ community edition, which is Apache licensed OSS.


> Also, nothing you wrote addresses the other complaint I have, which is
> that stuff shouldn't just magically stop working one day while it's sitting
> in a drawer unused, and that there's not even an *excuse* for it to do so
> if it's *software*.
>

It's very complicated software that depends on a lot of moving parts,
developed by one person in their spare time, that you got for free and is
mostly very reliable. It's unrealistic to expect it to never break. As long
as you can sort it out promptly when it does break, I don't think you have
much grounds for complaint.


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

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

Re: Simple memory usage tuning for clojure

[Colin Fleming]

As would I - I've used YourKit a bit but the results can often be pretty
impenetrable. Also, knowing how to interpret results specifically for
Clojure would be great too.

Jonathon, if you're specifically interested in memory, check out Eclipse
MAT - it's a great, free tool for analysing heap dumps and there are some
good tutorials out there for how to use it.

On 4 May 2016 at 10:04, Patrick Kristiansen  wrote:

> Well, Tim, there's an idea for material for your Pivotshare videos: how to
> use YourKit efficiently. I'd watch.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Porting Clojure to Native Platforms

[Colin Fleming]

That could be hidden from the user by tooling though, perhaps by
recompiling the previous version of the namespace with just the form the
user wants to load modified. That would also fix one serious problem with
per-form evaluation, which is that the line numbers for subsequent forms
get messed up (assuming that the form you're working on is a different
number of lines to the previous version). This affects exception
stacktraces and debugging.

Also, anyone using CLJS and Figwheel is already loading ns-at-a-time. It's
a slightly different workflow, but most people seem to love it.

On 27 April 2016 at 23:47, Stig Brautaset <s...@brautaset.org> wrote:

> Colin Fleming <colin.mailingl...@gmail.com> writes:
>
> > Unit of compilation is the module, not sure how that all plays out
> with
> > the Elixir repl, but it's not optimal. From what I can tell,
> re-deffing a
> > defn would require re-loading an entire namespace (module)...
> >
> > Reloading a whole namespace on an evaluation doesn't seem like a
> > show-stoppingly bad idea though, does it?
>
> It means the whole namespace has to compile at all times, as opposed to
> just the form I'm currently working on. Not show-stoppingly bad
> perhaps, but certainly workflow-altering.
>
> Stig
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Porting Clojure to Native Platforms

[Colin Fleming]

>
> Unit of compilation is the module, not sure how that all plays out with
> the Elixir repl, but it's not optimal. From what I can tell, re-deffing a
> defn would require re-loading an entire namespace (module)...
>

Reloading a whole namespace on an evaluation doesn't seem like a
show-stoppingly bad idea though, does it? We're only talking during
interactive use at the REPL, if it takes 100ms to evaluate a form I don't
think anyone is going to care that much. I mean, at the REPL no-one
complains about how long require takes except in extreme cases, and that's
generally reloading many namespaces. Of course, in a reload-entire-ns model
you're likely to have to reload namespaces that depend on the one you're
reloading as well, but I'm still not sure it's so horrible.


On 27 April 2016 at 12:45, Timothy Baldridge  wrote:

> >> would you consider a Clojure port to Erlang VM a viable idea for
> production workloads? I know Elixir comes pretty close, but I still prefer
> Lisp : ) .
>
> I looked into that at one point, but sadly the Erlang VM is a really poor
> platform for a Clojure port. Here are a few reasons why:
>
> Unit of compilation is the module, not sure how that all plays out with
> the Elixir repl, but it's not optimal. From what I can tell, re-deffing a
> defn would require re-loading an entire namespace (module) or require
> one-defn-per-module.
>
> No native polymorphism. Elixir fakes it with structs (think defrecords)
> with a custom hidden field, then looks up functions in a hash map on that
> field to dispatch.
>
> Total lack of shared state. This one doesn't sound like a problem till you
> think of how to do things like a REPL that can re-def defns at runtime.
> Also, clojure makes fairly liberal use of atoms, vars, and volatile! cells.
> Even stuff like lazy seqs leverage limited mutability and set-once
> behaviors. You don't have any of that in BEAM, just actors. And converting
> all those things to actors would be a major mistake.
>
> So can you have a lisp flavored Erlang? Sure. But what you're left with
> would not be Clojure.
>
> Timothy
>
>
>
>
>
> On Tue, Apr 26, 2016 at 3:55 PM, Rangel Spasov  wrote:
>
>> tbc++ - given your experience, would you consider a Clojure port to
>> Erlang VM a viable idea for production workloads? I know Elixir comes
>> pretty close, but I still prefer Lisp : ) .
>>
>> On Monday, April 25, 2016 at 1:50:45 PM UTC-7, 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.
>>>
>>> A LLVM/C++/RPython based version of Clojure would on a good day come in
>>> at about 1/10 the speed of Clojure on the JVM for general use cases.
>>>
>>>
>>> On Mon, Apr 25, 2016 at 2:18 PM, Raoul Duke  wrote:
>>>
 > The main motivation would be performance gains.

 blah? so many impedance mismatches and layers of indirection that i
 don't think it will gain much? i mean, it would probably be better to
 spend time tuning gc parameters or something. just a rant / guess.
 e.g. robovm is for some use cases perfectly fine performance wise
 believe it or not.

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

Re: Porting Clojure to Native Platforms

[Colin Fleming]

Of course, most people using Lua seriously use LuaJit, which is
surprisingly fast. However it's very prone to the branching problems you
described earlier for complex application code. I believe LuaJit does
optimise hashmaps when they're used as arrays etc. LuaJit really shines
when used for something with a really tight inner loop with perhaps a
couple of main branches - it's used for packet filtering, for example, and
it's possible to get more or less the same performance as C under those
restricted conditions but with dynamic adaptation to traffic conditions for
things like DDOS attacks.

One thing that LuaJit does offer is much better control over memory layout
than Java/JS etc. You can manually allocate blocks of memory and treat them
as arrays of floats etc - it would be interesting to see how fast it would
run something like a raytracer or a mandelbrot calculation, I'd imagine it
could get pretty fast.

On 27 April 2016 at 09:01, Timothy Baldridge  wrote:

> > Ask all the game people who use Lua big time
>
> See that's the problem. When we say "horses for courses" we have to
> actually dig down into what we're saying there. The reason Lua is used in
> the gaming community is that it's quite fast, very very small, and simple
> for what it does. It also has a fairly decent JIT (in the form of LuaJIT).
> But it's still an interpreted language, with a very basic set
> of data-structures (basically hash-maps for everything even arrays).
>
> So yeah, the reason it's used in the gaming community is that integrating
> the interpreter is fairly easy, and it's "fast enough" to be used for game
> logic. But I seriously doubt anyone picked Lua because it had a world-class
> GC (because it doesn't), or because out-performed other languages.
>
>
>
> On Tue, Apr 26, 2016 at 2:30 PM, Raoul Duke  wrote:
>
>> Horses for courses. Ask all the game people who use Lua big time. :-)
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@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.
>

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

[Colin Fleming]

This is true of a lot of those benchmarks, especially for functional
languages. I haven't looked recently, but back in the day Haskell seemed
very fast on the shootout game. However the code that actually runs that
fast is very very far from idiomatic. Again, I haven't looked at the
Clojure versions recently but I recall several of them being basically Java
written in Clojure form, i.e. lots of interop and not a lot of the sort of
higher-order code that makes Clojure such a pleasure to program. The rules
around functions accepting and returning primitives are way into
expert-level territory.



On 26 April 2016 at 20:15, Niels van Klaveren 
wrote:

> The only conclusion I can draw from these benchmarks over the years is
> that the speed of Clojure is inversely proportional to it's idiomaticity
>
>
> On Tuesday, April 26, 2016 at 7:23:48 AM UTC+2, Mars0i wrote:
>>
>> 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
>>> 
>>> .  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
>>  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.
>

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

[Colin Fleming]

In terms of learning a minimum about how ClojureScript itself works, I'd
recommend starting from the Quick Start
. It uses no
external tooling so there's no house of cards effect which can be
discouraging for new users. You'll end up with a very minimal setup, I'd
recommend that as a point to start from.

On 27 March 2016 at 11:11, Pedro Santos  wrote:

> I've done somehting like that:
>
> https://medium.com/@donbonifacio/running-clojure-code-on-javascript-e1f37071e69e#.mmasgmo7q
>
>
> On Saturday, 26 March 2016, Alan Thompson  wrote:
>
>> Have you seen this tutorial?   https://github.com/magomimmo/modern-cljs
>> Alan
>>
>> On Sat, Mar 26, 2016 at 8:06 AM, Lee Spector 
>> wrote:
>>
>>> Hi all,
>>>
>>> I have a pure Clojure program and I would like to make it run in the
>>> browser on client machines. It has no dependencies other than Clojure, it
>>> does no Java interop, and it has no GUI. There's no database, no user
>>> interaction (except for starting the program), and no networking. It just
>>> computes something and prints text (which goes to the REPL in the Clojure
>>> version). From what I've read, it should run exactly the same in
>>> Clojurescript with no changes.
>>>
>>> For the sake of argument -- and this isn't very far from the truth --
>>> let's say that I have absolutely no web programming experience, and that I
>>> don't know how to run Clojurescript at all (although I've been using
>>> Clojure for many years). I can produce basic HTML files and I can put files
>>> on a server in a public directory with a known URL, but that's it in terms
>>> of web "programming." And let's suppose that I know absolutely nothing
>>> about Javascript.
>>>
>>> Can anybody tell me or point me to a resource that will tell me how to
>>> get my Clojure program running as a Clojurescript program in a web page?
>>> Ideally, I would like to do this without learning a lot about Javascript or
>>> web programming. I just want this existing, pure Clojure program to run in
>>> a client's browser, running a computation and providing text output.
>>>
>>> Searching for "minimal clojurescript" turns up things much less minimal,
>>> assuming that I know more about Javascript and/or web programming, and/or
>>> that I want something more sophisticated than I've outlined here.
>>>
>>> If I can get this working then I will eventually want something
>>> *slightly* more complex in terms of user interaction: a text field on the
>>> page into which the user can type, and from which my program can read. But
>>> aside from this, and I guess a "Start" button, I need no GUI.
>>>
>>> I would appreciate any pointers that anyone can provide!
>>>
>>> Thanks,
>>>
>>>  -Lee
>>>
>>>
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Pedro Pereira Santos
> https://twitter.com/donbonifacio
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, 

Re: Clojure as first language

[Colin Fleming]

Have you come across any *new* programmers who think in terms of bit
twiddling? I agree with Mark - this tends to be intuitive once you've
learned that that is all there is. This might have been the case long ago
when people started programming by learning about how CPUs work, but
computers are so complex now that very few people start out that way any
more.

On 18 March 2016 at 10:03, Val Waeselynck  wrote:

> Really depends on how the brain of the programmer is wired IMHO. To some
> people, the intuitive part of programming is fiddling with bits, to others
> it's all about abstraction.
> On Mar 17, 2016 9:32 PM, "Mark Engelberg" 
> wrote:
>
>> On Thu, Mar 17, 2016 at 11:12 AM, gvim  wrote:
>>
>>> Better to get a foundation in Javascript, Python/Ruby and Java first
>>> then add Clojure later.
>>>
>>
>> Disagree.  It's easier to go from functional programming to imperative
>> programming than vice versa, so it is better to teach functional
>> programming first.
>>
>> The reason is that imperative programming can be thought of as a small,
>> added layer, an extra mutation capability beyond writing pure functions
>> that can be used judiciously to achieve certain effects.  Grounded in
>> functional programming, it's easy to go to imperative programming, because
>> you are *adding* a capability.  You can still write pure functions in an
>> imperative language (although the language gives you less support for doing
>> so), so your prior knowledge applies.
>>
>> On the other hand, if you learn imperative programming first, you learn a
>> way of writing code that uses mutation in everything.  You develop no
>> awareness of the boundary between the set of things you can compute with
>> and without mutation.  From your perspective, everything requires
>> mutation.  When you try to make the move to functional programming, you
>> feel completely lost and completely hamstrung, because a capability you
>> imagine is essential for writing any code is now missing.  You have to
>> completely relearn how to think about coding, figuring out how to write
>> code without mutation.  You are subtracting a capability from your
>> language, which is much, much harder, because all your instincts about how
>> to code no longer apply.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/i1CUQKROJ5U/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Colin Fleming]

That sounds great Timothy, thanks!

On 18 March 2016 at 06:32, Timothy Baldridge  wrote:

> It uses the same sort of logic that React does. Fn-fx creates a virtual
> dom, and then diffs the previous virtual dom against the updated one. From
> there you get a list of necessary updates. JavaFX has a rather uniform
> property interface so applying these updates is quite simple.
>
> On Thu, Mar 17, 2016 at 11:26 AM, Jason Zwolak  wrote:
>
>> You can diff JavaFX components like that?
>>
>> --
>> Jason Zwolak
>>
>> On Thu, Mar 17, 2016 at 12:51 PM, Timothy Baldridge > > wrote:
>>
>>> >> If the app-state has changed then it starts re-rendering the UI.
>>>
>>> That's pretty much exactly what fn-fx does in the latest version, with
>>> two caveats: 1) there's no timer, just a watch on an atom. 2) If you
>>> properly diff components you don't need to re-create them every time, just
>>> change the properties that changed. So if you have a text box 5 components
>>> deep in your app, and you change the background color, only the background
>>> color property of that single component will be changed, the rest of the
>>> app will remain unmodified.
>>>
>>> On Thu, Mar 17, 2016 at 10:37 AM, Jason Zwolak 
>>> wrote:
>>>
 Paul, yeap, Seesaw is definitely something worth considering. Dave Ray
 hasn't abandoned the project, but I sent a personal email to him asking
 about the state of the project and it does seem the Seesaw is in more of a
 maintenance phase than a continue to move forward and improve phase. Dave
 Ray, if you're on this list, would you chime in?

 Also, I was at the talk you mentioned and was very impressed with their
 methods. What wasn't mentioned in the talk was the fundamental structure of
 the interface between Clojure and JavaFX. One point that _really_ struck me
 is that they have a reoccurring timer running in the background and each
 time it wakes up it checks for changes on the app-state (presumably an
 atom, but I do not remember). If the app-state has changed then it starts
 re-rendering the UI. If I remember correctly it recreates the UI components
 that rely on any part of the app state that has changed. It sounds a little
 similar to Facebook React. I questioned them on this approach as it sounded
 strange to me... and they convinced me it's a good approach for their
 project and inspired me to try something similar on my own... which I'm
 secretly working on ;-)

 One thing that makes this work so well for their approach is that they
 have animations that depend on the app state. So their reoccurring timer is
 almost like a video algorithm redrawing the on screen image at the
 specified frame rate.

 --
 Jason Zwolak

 On Thu, Mar 17, 2016 at 11:06 AM, Paul L. Snyder <
 p...@pataprogramming.com> wrote:

> Yow, old indeed!
>
> In 2011, Dave Ray released Seesaw, which is a very nice wrapper for
> Swing.
> I've used it for a bunch of projects, and it works great. Of course, it
> does look like Swing, but it's plenty usable. (It's also still being
> maintained, so if you're looking for a toolkit that you can use right
> now,
> it's a good way to go.)
>
>   https://github.com/daveray/seesaw
>
> That said, I'd also love to see a JavaFX wrapper. At the Conj in
> Philly,
> Cognitect talked about a project where they'd used it extensively:
>
>   https://www.youtube.com/watch?v=ajX09xQ_UEg
>
> It's definitely piqued my interest.
>
> Paul
>
> On Sat, 12 Mar 2016, Jason Zwolak wrote:
>
> > +1 JavaFX.
> >
> > I know this is an old thread... but in case anyone comes across it
> (like I
> > did just now) and wants to see where things are, they should know
> that
> > JavaFX has come a long way and seems to be Oracle's replacement for
> Swing.
> > Now JavaFX is no longer only in JavaFXscript... in fact, I believe
> > JavaFXscript is deprecated in favor of the JavaFX Java classes.
> >
> > I've seen some major projects done with Clojure and JavaFX... even
> from the
> > guys at Cognitect.
> >
> > On Thursday, May 27, 2010 at 11:18:41 AM UTC-4, Luke VanderHart
> wrote:
> > >
> > > My side project is a fairly complex GUI application written in
> > > Clojure. Recently, I've become irritated with using Java interop
> for
> > > everything. It's not that Clojure doesn't have nice java interop -
> it
> > > does. It's just that when interacting with a GUI framework, which
> is a
> > > large part of my app, I have to be back in mutable object-oriented
> > > land, worrying about class hierarchies, mutable state, locks, etc.
> > > Yucky.
> > >
> > > So, with a perhaps dangerous lack of sanity and without any

Re: Including debugging information for Clojure code

[Colin Fleming]

Hi Jason,

Things you might be interested in checking out:

George Jahad's CDT: https://github.com/georgejahad/cdt. It's kind of old,
but the JDI hasn't changed much recently.

There's also Ritz: https://github.com/pallet/ritz. Again, I think it's a
little bit-rotted these days but there's probably lots of good stuff there.

You might also be interested in my talk at Clojure/West last year:
https://www.youtube.com/watch?v=ql77RwhcCK0. I don't talk much about the
implementation, but I do talk a lot about what makes Clojure difficult to
debug over JDI.

Cheers,
Colin

On 15 March 2016 at 13:01, Jason Gilman <jason.gil...@gmail.com> wrote:

> That's awesome that you got it working. If you could share any information
> you found that would be really helpful for others in the future.
>
>
> On Monday, March 14, 2016 at 7:43:26 PM UTC-4, James Norton wrote:
>>
>>
>> Thanks for the reply. I was able to get it working when I looked at other
>> classes. The first class I tried on the list resulted in the exception, but
>> other classes (including those from my test project) worked. And thanks for
>> the note about CIDER. I had looked at those sources briefly, but now I
>> won't spend time on them.
>>
>> -James
>>
>> On Monday, March 14, 2016 at 2:26:11 AM UTC-4, Colin Fleming wrote:
>>>
>>> I don't have much time right now, but AFAIK Cursive is the only debugger
>>> using JDI - CIDER has a source manipulation debugger. I don't generally
>>> have to do anything special to debug, although I use an IntelliJ layer on
>>> top of JDI. I can try to check if it's doing anything with that flag. You
>>> can also check if your classes have debug info using Javap or a decompiler.
>>>
>>> I have to run now, but if you have further questions or you can't get it
>>> working let me know and I can dig further.
>>>
>>> On 14 March 2016 at 15:13, Jason Gilman <jason@gmail.com> wrote:
>>>
>>>> I'd recommend asking on slack. There's a cider channel where they hang
>>>> out and may be able to answer your question. You can join here
>>>> https://clojurians.slack.com/
>>>>
>>>> I'd really like to know this information for Proto REPL as well.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To post to this group, send email to clo...@googlegroups.com
>>>> Note that posts from new members are moderated - please be patient with
>>>> your first post.
>>>> To unsubscribe from this group, send email to
>>>> clojure+u...@googlegroups.com
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/clojure?hl=en
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to clojure+u...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Colin Fleming]

I don't have much time right now, but AFAIK Cursive is the only debugger
using JDI - CIDER has a source manipulation debugger. I don't generally
have to do anything special to debug, although I use an IntelliJ layer on
top of JDI. I can try to check if it's doing anything with that flag. You
can also check if your classes have debug info using Javap or a decompiler.

I have to run now, but if you have further questions or you can't get it
working let me know and I can dig further.

On 14 March 2016 at 15:13, Jason Gilman  wrote:

> I'd recommend asking on slack. There's a cider channel where they hang out
> and may be able to answer your question. You can join here
> https://clojurians.slack.com/
>
> I'd really like to know this information for Proto REPL as well.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ClojureScript] Re: Clojure Google Summer of Code 2016 - Submit your project ideas!

[Colin Fleming]

That's a shame. Was any feedback given?

On 1 March 2016 at 10:05, Alex Miller  wrote:

> Unfortunately, we were informed today that Clojure was not selected as a
> 2016 Google Summer of Code organization.  :(
>
>
> On Thursday, February 18, 2016 at 3:47:59 PM UTC-6, David Nolen wrote:
>>
>> Hello,
>>
>> We're approaching the end of the application period for organisation
>> participation in Google Summer of Code 2016. This is a fantastic
>> program that helps grow open source communities and gives students
>> from around the world the opportunity to get paid to work on open
>> source over the course of the summer. Clojure has participated four
>> years in a row now, and many notable projects have benefitted as a
>> result, including Clojure-in-Clojure, ClojureScript, Typed
>> Clojure(Script), Clojure/Android, Incanter, and more.
>>
>> We would love to see Clojure participate again this year. In order to
>> do so, we need to prepare our application which is due tomorrow. For
>> our application to be a success, we need widespread involvement from
>> the community to prepare a strong project ideas page. You can also
>> review the ideas from the past several years to help you come up with
>> new ideas.
>>
>> Please add your project ideas to the page at
>> http://dev.clojure.org/display/community/Project+Ideas+2016. At this
>> point, you are not committing to anything we just need your ideas.
>> If you don't have edit rights to the wiki and don't want to sign up
>> for an account, just post to the mailing list using [GSoC Idea] in the
>> subject line, and one of the administrators will add it for you.
>>
>> Daniel Solano Gomez, Alex Miller, and Ambrose Bonnaire-Sergeant helped
>> enormously last year, and I will be returning to help this year
>> as an administrator.
>>
>> A big thanks to everyone who has participated in previous years as
>> administrators, mentors, and students. We hope that this will be
>> another successful Google Summer of Code for Clojure.
>>
>> Sincerely,
>> David
>>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/clojurescript.
>

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

[Colin Fleming]

Hi Michael,

Congratulations! That's fantastic - I'm really happy to see more people
being able to work full time on tools :)

Cheers,
Colin

On 25 February 2016 at 05:22, Michael Drogalis  wrote:

> Hi everyone,
>
> I'm happy to announce that, starting next week, I'll be supporting the Onyx
> Platform  full time.
> I want to thank the incredible Clojure community that's helped to make
> Onyx a
> successful open source project. Read on in the blog post
> 
> for specifics, but I wanted to drop
> a message here to say how excited I am to push Clojure forward as a
> distributed systems/data analysis
> front runner.
>
> -- Michael
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] dali SVG library 0.7.0

[Colin Fleming]

This looks really lovely, thanks!

On 11 February 2016 at 13:51, Stathis Sideris  wrote:

> ...aaand the link to the repo: https://github.com/stathissideris/dali
>
>
> On Thursday, 11 February 2016 00:49:54 UTC, Stathis Sideris wrote:
>>
>> Hello all,
>>
>> dali is a Clojure library for representing the SVG graphics format. It
>> allows the creation and manipulation of SVG files. The syntax
>>  used
>> to describe the graphical elements is based on hiccup
>>  with a few extensions.
>>
>> The main advantage of dali is that it provides facilities to perform
>> complex layouts
>> 
>> without having to position elements explicitly.
>>
>> The 0.7.0 brings a lot of new features and very complete documentation to
>> get you started.
>>
>> All feedback very welcome.
>>
>>
>> Thanks,
>>
>> Stathis Sideris
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Splitting Read into 2 steps?

[Colin Fleming]

Hi Terje,

This is how the parsing works in Cursive. I have a classical lexer/parser
split because IntelliJ forces me to do that. That said, I like it that way,
and I believe it makes things more flexible. I've been able to make a
couple of special-case parsers easily on top of the lexer - I'm about to
start work on another one for Parinfer support.

I can't speak to why the Clojure reader works the way it does, but what you
suggest is definitely possible and works well.

Cheers,
Colin

On 8 February 2016 at 20:12, Terje Dahl  wrote:

>
>
> I have been studying and and implementing my own version of LispReader /
> tool.reader - for the purpose of syntax highlighting and visual token
> manipulation.
> My question is this:
> Why not split this into 2 steps?
>
>1. Reads the input (from PushbackReader et al) and emits a stream of
>tokens, preserving information about location in source, and applying
>typing to tokens, if possible.
>2. Consumes the stream from step one, descending recursively, applying
>reader-macros, resolving symbols in name-spaces, etc.
>
> This would allow for easier configuration of each step, such as:
>
>- turning exceptions on/off (useful for syntax highlighting)
>- custom reader-macros and custom classes of reader-macros
>- static analysis of code by controlling the namespacing/context
>
> Is there any reason not to do this?
> (Other than: This is the way it has always been done. This is the way
> lisp-readers are aways implemented.)
>
> Perhaps such a development is already underway?
>
> Finally, if I wanted to implement such a solution, would it be to do it in
> Java or Clojure?  Why?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Scala/Clojure/F# - Functional Programming Advocates - New York/Chicago/San Fran

[Colin Fleming]

Just this afternoon I was looking at the HN Who's Hiring
 thread for February. 621
comments there, mostly job postings with the occasional question comment,
so perhaps 500-550 actual postings. 15 postings mention Clojure, with 9
being what looks like a full time Clojure position. So better than
indeed.com (which probably tends towards the mainstream languages) although
still not a huge number of positions. However I see more companies hiring
at conferences etc than I see ads for, so I do think there's more work out
there. Obviously it won't be taking over from Java (or even Scala) any time
soon though.

On 2 February 2016 at 16:32, gvim  wrote:

> Alex
>
> I was looking at Indeed.com for U.S. FP job stats and I found for "United
> States" by title:
>
> Java: 12,125
> Scala: 336
> Clojure: 28
>
> Considering Clojure 1.0 has been around for nearly 7 years and Scala 2.0
> is almost a decade old is it fair to conclude that FP and Clojure in
> particular are likely to remain niche as far as paid work goes? It seems
> the OO juggernaut just rolls on regardless :(
>
> gvim
>
>
>
> On 01/02/2016 20:54, a...@functionalworks.com wrote:
>
>> Hey All,
>>
>> I am currently working with some of the worlds most talented FP teams in
>> the US to help them build out there Clojure, F# and Scala teams.
>>
>> If you are looking for a new gig within the Functional Space and want to
>> work alongside some of the best engineers then drop me a line!
>> a...@functionalworks.com 
>>
>> Paying up to $180,000 + Benefits + Bonus + Stock!
>>
>> Look forward to hearing from you.
>>
>> thanks,
>>
>> Alex Mesropians
>>
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Clojure beyond Java 6 ?

[Colin Fleming]

>
> Such project obviously don't care about bug fixes and new features, since
> they are stuck with dangerously old legacy JVM versions anyways, which is
> both a security risk, a risk of added defects, and prevents usage of newer
> Java features.
>

Sigh.

I feel like a broken record here, but I'd like to protest again at this
characterisation. No-one cares more than me about getting off Java 6, but I
have no choice. Oracle refuse to fix serious Swing/AWT bugs in later
versions of the JVM, so many IntelliJ (and thus Cursive) users have no
choice but to use it. The situation is getting better because JetBrains
have actually forked the JDK and are working on fixing the bugs, but their
JDK still has hardware-dependent issues, and even once those are fixed
users on older versions of IntelliJ may be using Java 6 for years to come.
The issue will be forced slightly once the next version of OSX comes out
and no longer supports Apple's JDK 6, but until that point (probably two
years from now) I'm stuck with it.

The rest of your points are valid, but the situation for Cursive, at least,
is 100% Oracle's doing, and has no good solution.

On 21 January 2016 at 11:45, Didier  wrote:

> The only reason to maintain compatibility with old JVM is to allow getting
> new features and bug fixes in an environment that for businesses or
> technical constraint can not upgrade to the latest JVM.
>
> Such project obviously don't care about bug fixes and new features, since
> they are stuck with dangerously old legacy JVM versions anyways, which is
> both a security risk, a risk of added defects, and prevents usage of newer
> Java features.
>
> It would not prevent them from running Clojure, it would only prevent them
> from upgrading Clojure to a later version, but I don't think this is a big
> deal, as they are also prevented from upgrading the JVM.
>
> As I see it, if Clojure does not need any of the new JVM's capability to
> implement whatever it wanted for it's next release, than it makes sense to
> target the oldest JVM that works. On the other hand, if the legacy JVM is
> missing functionality that the new JVM brings, which prevents Clojure from
> implementing core ideas that it wants to do, I think that's an issue.
>
> Now, maybe this has never happened, and 1.6 has been good enough for every
> single feature that Clojure decided to adopt. I'd like to know more about
> this point. Is the vision of Clojure to restrict itself to only the things
> JVM 1.6 allows it to do, or has it been more that the need for more never
> presented itself, and so Clojure is happy supporting Java 1.6?
>
> On Wednesday, 20 January 2016 02:14:51 UTC-8, Daniel Compton wrote:
>>
>> Just a reminder that Cursive needs to support Java 6, as there are still
>> issues with OpenJDK8 on Mac OS X 10.11. So not all people using Java 6 can
>> be written off as enterprise laggards.
>> On Wed, 20 Jan 2016 at 8:52 PM, Bozhidar Batsov 
>> wrote:
>>
>>> Even Java 1.7 already reached its end of life. I get it that some
>>> companies are slow to update their infrastructures, but being constrained
>>> to legacy unsupported systems adds both a security risk and some
>>> development overhead. It's high time for Java 1.6 to be laid down to rest
>>> and for people stuck to it to move forward. I'm guessing Cognitect's
>>> enterprise customers are the primary reason 1.6 is still supported.
>>>
>>> On 20 January 2016 at 08:58, Max Penet  wrote:
>>>
 I doubt it such a big deal actually.

 You can run multiple versions of the java on the same machine. The
 only issue would be for legacy projects that are frozen to java 6 and
 would like to upgrade to a lib (like clojure) relying java8.  But I
 doubt such projects are the norm, and the few that are probably do not
 care about upgrading to the latest clojure.

 There are a lot of very large projects (such as Jetty, Cassandra, etc)
 that just made java8 a requirement for their next/current releases, and
 I
 don't see much complaining about it (quite the opposite).

 Also the fact that clojure itself is not getting an avalanche of new
 feature at every release makes upgrading not so critical.




 On Tuesday, January 19, 2016 at 8:33:56 PM UTC+1, Sean Corfield wrote:
>
> Didier wrote on Tuesday, January 19, 2016 at 11:08 AM:
>
> Why not make new versions of Clojure support the latest Java version
> and JDK features
>
>
> Since Clojure 1.7 (and 1.8) run on Java 8 quite happily, I assume you
> mean "Why not drop support for earlier Java versions with each new version
> of Clojure"?
>
> The answer — for any situation like this — is that many companies are
> slow to upgrade fundamental infrastructure like the JVM because they have
> so many things that rely on it, so it is a major exercise. For Clojure to
> be adopted by such companies, 

Re: Reducing the pain of a clojars outage

[Colin Fleming]

I'm travelling at the moment so I don't have time to respond to everything
right now, but one thing about the Java 6 issue - IntelliJ won't be fully
on Java 8 until IntelliJ 16. This means that Java 6 will be around until a)
everyone is on whatever comes after El Capitan (the last OSX to support
Apple's Java 6, which came out not long ago), or b) everyone is on IntelliJ
16, which has only just gone into beta. I support the last two major
IntelliJ versions, so that'll be another two years or so. Of course, there
may be a vanishingly small number of users still on Java 6 at that point
but that's the timeline. It's anyone's guess when a majority of OSX users
will be on JDK 8 - at some point I'll just have to say that you need to
upgrade IntelliJ if you want to use Leiningen on OSX, but that won't be for
a while yet - at least a year I guess.

On 3 January 2016 at 09:33, Toby Crawley  wrote:

> On Sat, Jan 2, 2016 at 1:59 PM, Michael Gardner 
> wrote:
> > Still, my personal opinion (for whatever it's worth) is that ensuring
> the entire process is always cryptographically secure end-to-end should be
> a higher priority than establishing mirrors.
>
> I agree, ensuring the process is cryptographically secure end-to-end
> should be a priority, but it is also a Sisyphean task, since it would
> at least require:
>
> * getting everyone to sign releases: not difficult - we just require
>   signatures at deploy time on clojars.org and deal with the pain of
>   bringing everyone up to speed
> * dealing with existing unsigned releases: deprecate them? give the
>   authors a way to sign them after the fact?
> * changing tooling to confirm that the artifacts are signed with keys
>   that are in your web of trust: lein and boot can already tell you
>   what in the dep graph is signed, and verify that the signatures are
>   valid, but don't yet confirm against the caller's web of
>   trust. Without that, how would you know that the artifact isn't
>   signed with a random, throwaway key?
> * organizing key-signing parties around the world to build the web of
>   trust for the clojure community: Phil Hagelberg started that process
>   with key-signing meetings at clojure conferences, but it didn't
>   spread very far. Initiatives like https://keybase.io/ may help with
>   this.
>
> And this assumes that everyone in your web of trust that publishes
> artifacts is who you think they are, keeps their keys 100% secure,
> and aren't coerceable.
>
> Even after all that, we still won't be able to pull jars when
> clojars.org is down unless we have some alternate source.
>
> - Toby
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] pex, a powerful PEG parsing library

[Colin Fleming]

I'm really impressed by how fast it is out of the box with basically no
optimisations. Tatu Saloranta is fanatical about Jackson performance,
getting to within 6x on the first attempt is very promising.

On 20 November 2015 at 02:43, Ghadi Shayban  wrote:

> Thanks for taking a look.
>
> User-level bytecode allows me an easier choice to build a JIT or tracing
> infrastructure, while being far less complex than writing out JVM bytecode
> during grammar compile.
>
> Christophe has certainly been a help offline with design choices.  I
> wanted PEG, no ambiguity, unlike instaparse or parsnip.  Most of the API
> inspiration was from LPEG & Scala's Parboiled2.  Some of the VM internals
> are close to JRuby's Joni regex engine.
>
>
>
> On Thursday, November 19, 2015 at 8:24:37 AM UTC-5, bernardH wrote:
>>
>> This is interesting !
>> It reminds me of Parsnip from C.Grand [0], have you considered it when
>> desining pex ? As your parser is focusing of characters, I am wondering :
>> could the operations triggered by the execution of your pex code be simple
>> enough to warrant actual compiling to JVM bytecode (at run time, with ASM
>> [1]) for maximum performance ?
>>
>> Best Regards,
>>
>> Bernard
>>
>> [0] https://github.com/cgrand/parsnip/
>> [1] http://asm.ow2.org/
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: deprecation warnings?

[Colin Fleming]

Sadly Cursive doesn't show this right now - it definitely should, though.

Cheers,
Colin

On 15 October 2015 at 06:55, William la Forge  wrote:

> *warn-on-deprecated* would be super! :D
>
> On Wed, Oct 14, 2015 at 1:44 PM, Alex Miller  wrote:
>
>> You might wish to up-vote http://dev.clojure.org/jira/browse/CLJ-706
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/sWUz7VGLv_o/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Colin Fleming]

Unfortunately as tools developers we can't force our indentation
preferences on our users, although I'd be fine with it if you convinced
everyone to just use two spaces for everything, even though it's not my
preferred formatting. Cursive has supported this for ages (copied from
Emacs) but I don't know how many people actually use it.

As above, I agree that this shouldn't be in the code.

I also agree very strongly that this shouldn't just adopt whatever Emacs
does for formatting. The one-space indent for list forms, in particular,
drives me nuts and is purely an implementation detail, not because that
makes any sort of sense for code.

You're right that the format spec is pretty obtuse, although we have far
worse out there (the pprint format, ahem). Separating the format spec out
into a separate doc would allow something more verbose to be used which
could be more expressive.

On 16 September 2015 at 23:34, Chas Emerick  wrote:

> Hi all; here to satisfy the quarterly quota to maintain my status as "that
> guy".
>
> This is a questionable proposal. It:
>
> * introduces completely orthogonal, transient concerns (presentation) into
> code, ideally a canonical, long-lived source-of-truth
> * sets up a bikeshed at the top of every def* form
> * adopts idiosyncratic implementation details of a particular editor's
> language support (the defrecord example's :indent is particularly obtuse
> IMO, even if you are aware of how clojure-mode is implemented)
>
> I *think* I coined the "always two spaces" shorthand for the (admittedly,
> minority) position that list forms should be formatted completely
> regularly, so as to:
>
> * make formatting a trivial operation, not requiring any "real" reading
> * eliminate this entire topic
>
> Here's the first time I talked about this IIRC:
> https://groups.google.com/forum/#!msg/clojuredev-users/NzKTeY722-I/3hmNvJulcksJ
>
> Best,
>
> - Chas
>
>
> On 09/13/2015 06:06 AM, Artur Malabarba wrote:
>
> Hi everyone,
>
>
> Over at CIDER we're adding a feature where the author of a macro (or
> function) can specify how that macro should be indented by adding an
> :indent metadata to its definition. This way the editor (and other tools,
> like cljfmt) will know what's the proper way of indenting any macro (even
> those custom-defined) without having to hardcode a bajillion names.
>
> Here's an example of how you specify the indent spec for your macros
>
>
> (defmacro with-out-str
>   "[DOCSTRING]"
>   {:indent 0}
>   [& body]
>   ...cut for brevity...)
>
> (defmacro defrecord
>   "[DOCSTRING]"
>   {:indent [2 nil nil [1]]}
>   [name fields & opts+specs]
>   ...cut for brevity)
>
> (defmacro with-in-str
>   "[DOCSTRING]"
>   {:indent 1}
>   [s & body]
>   ...cut for brevity...)
>
>
> We'd like to hear any opinions on the practicality of this (specially from
> authors of other editors).
> Below, I'll be saying “macros” all the time, but this applies just the
> same to functions.
>
> *Special arguments*
>
>
> Many macros have a number of “special” arguments, followed by an arbitrary
> number of “non-special” arguments (sometimes called the body). The
> “non-special” arguments have a small indentation (usually 2 spaces). These
> special arguments are usually on the same line as the macro name, but, when
> necessary, they are placed on a separate line with additional indentation.
>
> For instance, defrecord has two special arguments, and here's how it
> might be indented:
>
>
> (defrecord TheNameOfTheRecord
> [a pretty long argument list]
>   SomeType
>   (assoc [_ x]
> (.assoc pretty x 10)))
>
>
> Here's another way one could do it:
>
>
> (defrecord TheNameOfTheRecord
>[a pretty long argument list]
>   SomeType
>   (assoc [_ x]
> (.assoc pretty x 10)))
>
>
> *The point of the indent spec is not to specify how many spaces to use.*
>
>
> The point is just to say “a defrecord has *2* special arguments”, and
> then let the editor and the user come to an agreement on how many spaces
> they like to use for special and non-special arguments.
>
> *Internal indentation*
>
>
> The issue goes a bit deeper. Note the last argument in that defrecord. A
> regular function call would be internally indented as
>
> (assoc [_ x]
>(.assoc pretty x 10))
>
> But this is not a regular function call, it's a definition. So we want to
> specify this form internally has 1 special argument (the arglist vector),
> so that it will be indented like this:
>
> (assoc [_ x]
>   (.assoc pretty x 10))
>
> The indent spec we're working on does this as well. It lets you specify
> that, for each argument beyond the 2nd, if it is a form, it should be
> internally indented as if it had 1 special argument.
>
> *The spec*
>
>
> An indent spec can be:
>
>- nil (or absent), meaning *“indent like a regular function call”*.
>- A vector (or list) meaning that this function/macro takes a number
>of special arguments, and then all other arguments are non-special.
>   - 

Re: Using metadata to specify how calls to a macro should be indented

[Colin Fleming]

This is an interesting proposal, and I like it in general. Everything in
Cursive is based on extensions identified by the head form, like this:

(style/register-formatting :clojure.core/def :only-indent)
(style/register-formatting :clojure.core/defn- :only-indent)
(style/register-formatting resolve/fn-forms :only-indent)
(style/register-formatting resolve/local-binding-forms 1)

I think it's important that the declaration of the formatting be separated
from the declaration of the macro itself. This allows forms which the
editor developer doesn't control to be annotated, e.g. core. Perhaps
library owners could produce an EDN doc containing these specs? Or perhaps
we could obey annotations in the functions themselves, but I think that
some way to additionally annotate external things is essential.

I also think that Mr Dynamics is correct, we should not go down the path of
special casing anything, even defn - this is a hard rule that I have in
Cursive that I only break very occasionally :-). The spec should support
everything we need to do. It will be difficult, though - in Cursive I
actually support programmatically organising the blocks that make up the
source, and I'm not sure how to handle many cases without this. I like the
hierarchical nature of this spec, though, I suspect that many of the cases
I currently solve programmatically could be solved using something like
this.

There are also many more aspects to formatting that this does not address
that I think we should think about - line indentation is only one part of
it. What about breaking lines when they're too long? Aligning subforms like
let-binding values? Do we want to do anything about those? Cursive can
handle all of that but doesn't expose the knobs right now. clj-fmt does, I
believe - I think it can take a single line of pr-str output and produce
nicely formatted code.

There are also lots of edge cases that need to be thought through.
Multi-arity function declarations for letfn, proxy etc come to mind.
extend-type also supports multiple arity declarations. condp is another
example of a form with variable numbers of elements per "block" (the :>>
keyword). for-blocks have internal let blocks, etc etc.

It's hard to tell how far to go with this. One thing that I'm planning in
Cursive that I'm not doing currently is also to identify forms which are
part of a do-body-like-thing. This is very useful for refactoring. This
might not have a place in a spec that is purely for indentation, but
definitely would in a more general form structure spec. I also think it
would be very useful to express implicit grouping of elements, e.g. let
binding keys/values, cond forms etc.


On 16 September 2015 at 07:08, Josh Tilles 
wrote:

>
>
> On Sunday, September 13, 2015 at 8:25:42 AM UTC-4, Artur Malabarba wrote:
>>
>>
>> On 13 Sep 2015 12:33 pm, "Matching Socks"  wrote:
>> >
>> > Unless clojure.core itself will carry these annotations, could the
>> keyword be namespaced?
>>
>> Or do you mean it should be ::indent? (i.e., carry the namespace of the
>> var that they're applied on)
>>
> I suspect that “Matching Socks” meant that there should be a standard
> namespace, similar to how the recent Socket Server REPL design
> 
>  uses
> a “repl” namespace for its magic keywords.
> It seems natural to me to pick a namespace like “editors” or “editing”,
> but alternatives like :display/indentation or :visual/structure also look
> good.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Cursive and gen-class

[Colin Fleming]

On 25 August 2015 at 18:22, Fluid Dynamics a2093...@trbvm.com wrote:

 I seem to recall criticizing a piece of Clojure-relevant *technology* that
 had the rather remarkable property that it could be working, be deleted and
 reinstalled (exact same version), and suddenly be *not* working.


Except that's not actually what happened. The sequence of events is
difficult to work out from the email chain, but William was trying to
install a version of Cursive into a version of IntelliJ it didn't support.
That never works, and I'm 100% sure that it hadn't worked for him
previously. It's a fairly common mistake that users make when upgrading
IntelliJ for the first time when using Cursive, it's no big deal.


 Daniel, on the other hand,  criticized a *person* and moreover his post
 had nothing whatsoever to do with Clojure.


No, he didn't, he criticized the comment you made and said it wasn't
appropriate for the Clojure community, which is very relevant to Clojure.

Personally, I'm pretty confident in the ability of this community to
recognise and disregard uninformed ranting when they see it, so I'm not at
all bothered by it.



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


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