Re: Clojure as first language

[Gary Trakhman]

Not only the language and the techniques you intend to apply, but the
larger language and library ecosystem.  For most people, Clojure is best
used when you
have familiarity with the JVM and existing java core libraries and
3rd-party libraries, and some IDE/editor environment with enough features
to be productive, but
those are extra things to learn.  Something like Scheme/Racket used for
SICP is a great teaching language because all those decisions are made for
you and
you can focus on the abstract content in the book instead of getting bogged
down in tooling.

As for data-science/ML, it has good tools, it's just not the most widely
used language by data scientists.
Check out Clojure for data science:
https://www.amazon.com/Clojure-Data-Science-Henry-Garner/dp/1784397180

For the most part, I'd expect production-scale data science tools to wrap
java ones with a better/clojurey interface.
There's some other tools I'm not familiar with, eg
https://github.com/originrose/cortex, but there are definitely people doing
data science in clojure.

On Mon, Sep 28, 2020 at 12:55 PM Soule S  wrote:

> Thank you for your insight. By " learning more than one thing at a time",
> do you mean data science/ML and the language itself? If so, then I want to
> clarify, I have a solid foundation in data science; I am trained in the
> most advanced topics in econometrics (Statistics). My apprehension is
> mainly whether closure has good tools to do those. I know Python does.
>
> Thanks again
>
> On Mon, Sep 28, 2020 at 7:40 PM Gary Trakhman 
> wrote:
>
>> Clojure is a fine language to learn on, but there are going to be some
>> complex details along the way. I think there are 2 approaches
>> to entry into programming that you might consider.
>>
>> You can start with the basic fundamentals of computation and work up into
>> software engineering. For that, clojure is
>> very similar to a teaching language, 'scheme', and people can work
>> through books like SICP:
>> https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book.html
>> with it.
>> If you follow that strategy, you'll eventually have a good foundation of
>> understanding to build on, but it might not feel very useful in the first
>> year.
>>
>> Another strategy is to hack up small demos of individual techniques, like
>> numerical methodologies or data visualizations.  This would go more
>> along the data-science/ML track. While it can be done in clojure and
>> there are books on the topic, you might have an easier time in python
>> if you're going down that path.
>>
>> I would say if you start with clojure, you're going to be learning more
>> than one thing at a time and the learning curve is steeper. Whether
>> that's worth the cost depends on your goals and market conditions.
>>
>>
>> On Mon, Sep 28, 2020 at 12:13 PM Baye  wrote:
>>
>>> I am new to programming. I have started to learn C++ and even some python
>>> My background is Economics. I have strong quantitative background (Math
>>> and Econ) and I know STATA.
>>>
>>> In general, I would like to use programming
>>> (1) for ML/AI in economics topics+other utilities such as webcraping,
>>> and other data driven analyses
>>> (2) for it, fintech matchmaking platforms
>>>
>>> In particular, I just recently discovered I love programming. I am old
>>> (35) as a beginner but I have set a goal to become a fully capable
>>> programmer by 40...Hopefully I can learn 2 languages well enough by then.
>>>
>>> If jobs opportunities are present then, I can switch careers although I
>>> still like my career path. I could always use my programming skills for
>>> either my job, a start up, or become a full fledge prgrammer.
>>>
>>> Online research has led me to think that Clojure might be an excellent
>>> language to focus on because they say it is an excellent for rapid
>>> development (If I want to use it for a start up, lone developer),
>>> data-driven (econ and ML), and provide a path to be a great programmer.
>>>
>>> My Apprehension is that Clojure doesn't seem widely used so might issues
>>> with doing ML projects with few libraries (compare to Python for ex), and
>>> future job prospects, etc...
>>>
>>> Anyway, I welcome any insights/advice, tips.
>>>
>>> Thanks in advance,
>>> Baye
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@g

Re: Clojure as first language

[Gary Trakhman]

Clojure is a fine language to learn on, but there are going to be some
complex details along the way. I think there are 2 approaches
to entry into programming that you might consider.

You can start with the basic fundamentals of computation and work up into
software engineering. For that, clojure is
very similar to a teaching language, 'scheme', and people can work through
books like SICP:
https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book.html
with it.
If you follow that strategy, you'll eventually have a good foundation of
understanding to build on, but it might not feel very useful in the first
year.

Another strategy is to hack up small demos of individual techniques, like
numerical methodologies or data visualizations.  This would go more
along the data-science/ML track. While it can be done in clojure and there
are books on the topic, you might have an easier time in python
if you're going down that path.

I would say if you start with clojure, you're going to be learning more
than one thing at a time and the learning curve is steeper. Whether
that's worth the cost depends on your goals and market conditions.


On Mon, Sep 28, 2020 at 12:13 PM Baye  wrote:

> I am new to programming. I have started to learn C++ and even some python
> My background is Economics. I have strong quantitative background (Math
> and Econ) and I know STATA.
>
> In general, I would like to use programming
> (1) for ML/AI in economics topics+other utilities such as webcraping, and
> other data driven analyses
> (2) for it, fintech matchmaking platforms
>
> In particular, I just recently discovered I love programming. I am old
> (35) as a beginner but I have set a goal to become a fully capable
> programmer by 40...Hopefully I can learn 2 languages well enough by then.
>
> If jobs opportunities are present then, I can switch careers although I
> still like my career path. I could always use my programming skills for
> either my job, a start up, or become a full fledge prgrammer.
>
> Online research has led me to think that Clojure might be an excellent
> language to focus on because they say it is an excellent for rapid
> development (If I want to use it for a start up, lone developer),
> data-driven (econ and ML), and provide a path to be a great programmer.
>
> My Apprehension is that Clojure doesn't seem widely used so might issues
> with doing ML projects with few libraries (compare to Python for ex), and
> future job prospects, etc...
>
> Anyway, I welcome any insights/advice, tips.
>
> Thanks in advance,
> Baye
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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/10bd1d68-78f9-472b-8de3-5be96f6804a7n%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/CAJvqBXgPpyPvDdjRNzbL-%2Bqjj-CFxYg%3D0ypSX5--iqFemH%3D-7w%40mail.gmail.com.

Re: GraalVM's native-image incompatible with Clojure's eval?

[Gary Trakhman]

Yes, eval will generate classes in a dynamic classloader, load them, then
call methods on the newly formed class/object except for
too-simple-to-be-interesting cases.

On Mon, Nov 26, 2018 at 11:43 AM Khalid Jebbari 
wrote:

> Hi,
>
> I was doing a small experiment with Clojure and GraalVM and ended with
> this minimal reproduction case of an incompatibility between Clojure's
> `eval` and GraalVM's native-image tool (the program that compiles a JVM
> program to a native executable, based on the GraalVM's SubstrateVM
> compiler).
>
> Here's the Clojure program:
>
> (ns test-cli.main
>   (:gen-class))
>
> (set! *warn-on-reflection* true)
>
> (defn -main
>   "I don't do a whole lot ... yet."
>   [& args]
>   (println (+ 1 1)) ;; trick to force loading clojure.lang.Numbers, not
> working
>   (eval (read-string "(+ 1 1)")))
>
> Using Clojure 1.9.0 and GraalVM version 1.0.0-rc9.
>
> When I compile it with the
> option "--report-unsupported-elements-at-runtime" (which gives a more
> precised error message), here's the output when I try executing the
> resulting executable:
>
> Exception in thread "main" java.lang.ClassNotFoundException:
> clojure.lang.Numbers, compiling:(NO_SOURCE_PATH:0:0)
> at java.lang.Throwable.(Throwable.java:287)
> at java.lang.Exception.(Exception.java:84)
> at java.lang.RuntimeException.(RuntimeException.java:80)
> at
> clojure.lang.Compiler$CompilerException.(Compiler.java:6804)
> at clojure.lang.Compiler.analyzeSeq(Compiler.java:7010)
> at clojure.lang.Compiler.analyze(Compiler.java:6773)
> at clojure.lang.Compiler.analyze(Compiler.java:6729)
> at clojure.lang.Compiler.analyzeSeq(Compiler.java:6998)
> at clojure.lang.Compiler.analyze(Compiler.java:6773)
> at clojure.lang.Compiler.analyze(Compiler.java:6729)
> at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6100)
> at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5460)
> at clojure.lang.Compiler$FnExpr.parse(Compiler.java:4022)
> at clojure.lang.Compiler.analyzeSeq(Compiler.java:7001)
> at clojure.lang.Compiler.analyze(Compiler.java:6773)
> at clojure.lang.Compiler.eval(Compiler.java:7059)
> at clojure.lang.Compiler.eval(Compiler.java:7025)
> at clojure.core$eval.invokeStatic(core.clj:3206)
> at test_cli.main$_main.invokeStatic(main.clj:7)
> at test_cli.main$_main.doInvoke(main.clj:7)
> at clojure.lang.RestFn.invoke(RestFn.java:397)
> at clojure.lang.AFn.applyToHelper(AFn.java:152)
> at clojure.lang.RestFn.applyTo(RestFn.java:132)
> at test_cli.main.main(Unknown Source)
> at
> com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:164)
> Caused by: java.lang.ClassNotFoundException: clojure.lang.Numbers
> at java.lang.Throwable.(Throwable.java:287)
> at java.lang.Exception.(Exception.java:84)
> at
> java.lang.ReflectiveOperationException.(ReflectiveOperationException.java:75)
> at
> java.lang.ClassNotFoundException.(ClassNotFoundException.java:82)
> at
> com.oracle.svm.core.hub.ClassForNameSupport.forName(ClassForNameSupport.java:51)
> at com.oracle.svm.core.hub.DynamicHub.forName(DynamicHub.java:1036)
> at clojure.lang.RT.classForName(RT.java:2204)
> at clojure.lang.RT.classForNameNonLoading(RT.java:2217)
> at clojure.lang.Compiler$HostExpr.maybeClass(Compiler.java:1041)
> at clojure.lang.Compiler$HostExpr$Parser.parse(Compiler.java:982)
> at clojure.lang.Compiler.analyzeSeq(Compiler.java:7003)
> ... 20 more
>
> I'm no expert in Java/JVM and would like to understand the problem.
> According to the SubstrateVM documentation (
> https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md)
> it can't compile Dynamic Class Loading/Unloading. Is Clojure's `eval` doing
> such dynamic loading? Or doing something else not supported by SubstrateVM
> as said in the documentation?
>
> Thanks *a lot* in advance for you answers.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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 

Re: Ask Community: Feedback/Suggestion Needed about the Code Nirvana Specification

[Gary Trakhman]

Have you evaluated Phabricator?  I think it's trying to do all of SDLC in
one tool as well, more or less successfully.  Our team spends a lot of time
fighting its limitations.

On Fri, Nov 9, 2018 at 1:18 AM Piyush Katariya 
wrote:

> Hello Clojurians,
>
>  Could you please have a look at the specification of Code Nirvana and
> share your feedback/opinion/suggestion about it in terms of its need,
> usability and productivity
>
>
> https://docs.google.com/document/d/e/2PACX-1vTK7FVU-tPUwM8FXP33-qqPZk3pUOm4JI0JbOxHwkKmMH0skIxviOsEwB4ek_x_d9L8teI4dGWT-Avs/pub
>
>
> Thanks,
> Piyush Katariya
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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] com.walmartlabs/cond-let 1.0.0

[Gary Trakhman]

The short-circuiting is a 'feature' of letting the type control the
sequencing of operations.  In practice you mix multiple interacting monads
depending on what your requirements are, for example I regularly work with
Deferred Options and Deferred Results.  In clojure, you could try to add a
'if-let' style nil-punning thing to a cond-let implementation but at that
point I imagine it more appropriate to take a step back instead :-).

I'm not convinced yet that it's worth thinking about it like this in a
dynamically typed language, but brought it up because there's a named
concept that addresses the need people feel to extend cond/lets.

On Thu, Oct 4, 2018 at 12:57 PM lei Shulang  wrote:

> But a Maybe/Nothing will short-circuit the whole flow where cond-let
> won't?
>
>
> On Thursday, 4 October 2018 08:38:05 UTC-7, Moe Aboulkheir wrote:
>
>> See https://funcool.github.io/cats/latest/#mlet for something closer to
>> home, in the monadic vein.
>>
>>
>> On Thu, Oct 4, 2018 at 4:10 PM Gary Trakhman  wrote:
>>
> These are all just sugar over monadic bind, right?
>>>
>>> Here's one way to do it in the ocaml alternate universe:
>>>
>>> https://github.com/janestreet/ppx_let#syntactic-forms-and-actual-rewriting
>>>
>>> But it can be made to work for async or options or whatever, too.
>>>
>>> We can put the async helpers in the same bucket:
>>> https://github.com/ztellman/manifold/blob/master/docs/deferred.md#let-flow
>>>
>>> The general idea is turning function application into something that
>>> looks less nested.
>>>
>>> On Wed, Oct 3, 2018 at 10:22 PM Mark Engelberg 
>>> wrote:
>>>
>> This looks like a case of "convergent evolution".
>>>>
>>>> Having the ability to do a :let in the middle of a cond feels like one
>>>> of those things that *should* be in the core language, so if it's not
>>>> in there, a bunch of people are naturally going to arrive at the same
>>>> solution and make it happen in their own utility libraries.  A bunch of us
>>>> Clojure programmers from the early 1.0 days had been privately passing
>>>> around and using a "cond that supports :let bindings" macro for years.  The
>>>> first time I saw the macro was in a blog post by Christophe Grand. I really
>>>> hoped it would make it into Clojure proper -- other functional languages
>>>> like Racket and F# support ways to bind local variables with "clearer, more
>>>> linear code, that doesn't make a march for the right margin", as Howard
>>>> Lewis Ship put it.  But after several years had passed without any
>>>> indication that CLJ-200 was ever going to be addressed, I eventually made
>>>> the improved cond macro into a clojars library.
>>>>
>>>> walmartlabs' cond-let addresses the most important thing (let), which
>>>> is the critical piece of functionality that feels like the most natural,
>>>> needed addition to the language.  better-cond's :let syntax is identical.
>>>> But as us old-school Clojurians passed around the "better cond" macro over
>>>> the years, it grew in functionality.  So in better-cond, I included the
>>>> other little improvements that had accumulated over time, which I had found
>>>> useful.  So better-cond also supports :when, :when-let, and :do (and will
>>>> soon have :when-some).  :let is the only piece that I felt really belonged
>>>> in the core language's cond, and if CLJ-200 had made it into the core
>>>> language, I would have been content to just use Clojure's own cond.  But
>>>> once I realized I was going to need a library to achieve the much-needed
>>>> :let inside of cond, I figured I might as well use that library to include
>>>> the other convenient cond additions as well.  So better-cond is a superset
>>>> of cond-let's functionality, with support for :let plus a few bonuses.
>>>>
>>>> Use whichever one strikes your fancy.  cond-let is perfect if all you
>>>> care about is adding :let to your cond.  If you want to experiment with
>>>> some of the other features beyond :let, you could use better-cond and see
>>>> what you think.
>>>>
>>>> Either way, I strongly encourage you to use one of these two libraries
>>>> so you can start using :let inside your cond.  I agree fully with Howard
>>>> Lewis Ship that it results in clearer code.  

Re: [ANN] com.walmartlabs/cond-let 1.0.0

[Gary Trakhman]

These are all just sugar over monadic bind, right?

Here's one way to do it in the ocaml alternate universe:
https://github.com/janestreet/ppx_let#syntactic-forms-and-actual-rewriting

But it can be made to work for async or options or whatever, too.

We can put the async helpers in the same bucket:
https://github.com/ztellman/manifold/blob/master/docs/deferred.md#let-flow

The general idea is turning function application into something that looks
less nested.

On Wed, Oct 3, 2018 at 10:22 PM Mark Engelberg 
wrote:

> This looks like a case of "convergent evolution".
>
> Having the ability to do a :let in the middle of a cond feels like one of
> those things that *should* be in the core language, so if it's not in
> there, a bunch of people are naturally going to arrive at the same solution
> and make it happen in their own utility libraries.  A bunch of us Clojure
> programmers from the early 1.0 days had been privately passing around and
> using a "cond that supports :let bindings" macro for years.  The first time
> I saw the macro was in a blog post by Christophe Grand. I really hoped it
> would make it into Clojure proper -- other functional languages like Racket
> and F# support ways to bind local variables with "clearer, more linear
> code, that doesn't make a march for the right margin", as Howard Lewis Ship
> put it.  But after several years had passed without any indication that
> CLJ-200 was ever going to be addressed, I eventually made the improved cond
> macro into a clojars library.
>
> walmartlabs' cond-let addresses the most important thing (let), which is
> the critical piece of functionality that feels like the most natural,
> needed addition to the language.  better-cond's :let syntax is identical.
> But as us old-school Clojurians passed around the "better cond" macro over
> the years, it grew in functionality.  So in better-cond, I included the
> other little improvements that had accumulated over time, which I had found
> useful.  So better-cond also supports :when, :when-let, and :do (and will
> soon have :when-some).  :let is the only piece that I felt really belonged
> in the core language's cond, and if CLJ-200 had made it into the core
> language, I would have been content to just use Clojure's own cond.  But
> once I realized I was going to need a library to achieve the much-needed
> :let inside of cond, I figured I might as well use that library to include
> the other convenient cond additions as well.  So better-cond is a superset
> of cond-let's functionality, with support for :let plus a few bonuses.
>
> Use whichever one strikes your fancy.  cond-let is perfect if all you care
> about is adding :let to your cond.  If you want to experiment with some of
> the other features beyond :let, you could use better-cond and see what you
> think.
>
> Either way, I strongly encourage you to use one of these two libraries so
> you can start using :let inside your cond.  I agree fully with Howard Lewis
> Ship that it results in clearer code.  Try either library which supports
> this -- it will change your life!
>
>
> On Wed, Oct 3, 2018 at 5:05 PM Matching Socks 
> wrote:
>
>> Is this a refinement of Mark Engelberg's "better-cond", or an alternative
>> approach?
>>
>> I have not used better-cond myself, but it starts here:
>> https://dev.clojure.org/jira/browse/CLJ-200.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group 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 memb

Re: How define alias for .indexOf? (def somealias .indexOf) does not work.

[Gary Trakhman]

Ah, this came in with 1.5:
https://dev.clojure.org/jira/browse/CLJ-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

On Fri, Jul 20, 2018 at 12:38 PM Gary Trakhman 
wrote:

> > The memfn docstring says it can be type hinted to avoid reflection. Any
> reason why it would still be slower then wrapping it in a type hinted
> function?
>
> Neat, I didn't know that! Since each memfn creates a new function, it's
> the same thing as writing it out manually, unlike say 'partial', which is a
> little more indirect, shares a single function and can hit you with JIT
> polymorphism costs.
>
> On Fri, Jul 20, 2018 at 1:53 AM Didier  wrote:
>
>> The memfn docstring says it can be type hinted to avoid reflection. Any
>> reason why it would still be slower then wrapping it in a type hinted
>> function?
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group 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: How define alias for .indexOf? (def somealias .indexOf) does not work.

[Gary Trakhman]

> The memfn docstring says it can be type hinted to avoid reflection. Any
reason why it would still be slower then wrapping it in a type hinted
function?

Neat, I didn't know that! Since each memfn creates a new function, it's the
same thing as writing it out manually, unlike say 'partial', which is a
little more indirect, shares a single function and can hit you with JIT
polymorphism costs.

On Fri, Jul 20, 2018 at 1:53 AM Didier  wrote:

> The memfn docstring says it can be type hinted to avoid reflection. Any
> reason why it would still be slower then wrapping it in a type hinted
> function?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

[Gary Trakhman]

@Gary Johnson, your post is otherwise great, but I think a little confusing
for this point:
> , I would advise you to use the "into" function that I demonstrated at
the beginning of this email if you wish to teach a unified API for
appending and prepending to each of Clojure's four main data structures
while preserving the types of the function's inputs.

Into is essentially just 'reduce conj', so doesn't help for
appending/prepending any more than conj.

Here's a few working modifications to the left sides of your examples:

(into '(1 2) [3]) ;=>  (3 1 2) ; This was incorrect to start with
above
(into [1 2] '(3))   ;=>  [1 2 3]
(into {:a 1 :b 2} [[:c 3]]  ;=>  {:a 1, :b 2, :c 3}

On Fri, Jul 20, 2018 at 11:52 AM Gary Johnson 
wrote:

> Hi Christian,
>
> You are looking for "into", which is already part of the Clojure standard
> library.
>
> Appending:
>
> (into '(1 2) '(3)) ;=>  (1 2 3)
> (into [1 2] [3])   ;=>  [1 2 3]
> (into {:a 1 :b 2} {:c 3})  ;=>  {:a 1, :b 2, :c 3}
> (into #{:a :b} #{:c})  ;=>  #{:c :b :a}
>
> Prepending:
>
> (into '(1) '(2 3)) ;=>  (1 2 3)
> (into [1] [2 3])   ;=>  [1 2 3]
> (into {:a 1} {:b 2 :c 3})  ;=>  {:a 1, :b 2, :c 3}
> (into #{:a} #{:b :c})  ;=>  #{:c :b :a}
>
> The "into" function pours the contents of the second collection into the
> first collection, returning a collection of the same type as the first
> argument.
>
> That being said, I agree with Alex and James in this rather lengthy
> discussion. Clojure is unique among the Lisps in that it moved beyond
> having linked lists as the only first class data structure.
>
> Prior to Clojure, if you worked in a Lisp like Scheme or Common Lisp, you
> would design your program around the creation, traversal, and manipulation
> of linked lists using higher order functions and explicit recursions. The
> standard library in both languages is heavily focused on these list-related
> operations. After developing the initial version of your program, if you
> found that it was too slow or used too much memory, the accepted practice
> was to profile your application to identify the functions that were getting
> hammered the most and were using up the majority of your computing
> resources. You would then often end up rewriting those function bodies in
> an imperative fashion using loops and mutable data structures (i.e., arrays
> and hashtables). The "wisdom" here was that this would enable you to "first
> make it right, then make it fast". If even further performance was required
> from your program, you might then rewrite part of your program in C, build
> a foreign function interface (FFI) to link the C code into your Lisp
> program, and go from there. These were the Bad Old Days of Lisp(TM).
>
> What was IMHO quite possibly Rich's greatest contribution in the design of
> Clojure to the Lisp world was his decision to make additional data
> structures first class citizens of the language. Most importantly, he did
> so by creating Clojure's vectors, maps, and sets to be immutable,
> persistent, performant, recursively constructed, and representable as data
> literals. This was already a wonderful improvement over previous Lisps, but
> it created a new problem: How could we enjoy the pure delight of
> list-oriented programming that Lisp had always offered us now that the data
> structure space had been fragmented? A famous quote from Alan Perlis is a
> popular gem in the Lisp world, and it goes like so:
>
> "It is better to have 100 functions operate on one data structure than to
> have 10 functions operate on 10 data structures."
>
> Every Lisp had always satisfied this by simply giving programmers only one
> first class data structure to use: the linked list. As I already mentioned,
> the bulk of its standard library would then be built around list
> manipulation functions. Clojure needed a way to preserve this unified style
> of programming while still providing a collection of performant data
> structures for real-world programming. So how did Rich accomplish this?
>
> He created the "sequence abstraction". A sequence in Clojure serves a
> similar role to the linked list of previous Lisps in that it unifies the
> API for interacting with all of Clojure's first class data structures
> (list, vector, map, set). By calling the function "seq" on any data
> structure, you are given a list-like view of that collection that allows
> you to traverse it from beginning to end one element at a time and to add
> new elements to the beginning of it. These operations are called "first",
> "rest", and "cons", and they behave precisely as you would expect them to
> if you were calling them on a linked list.
>
> By using seq throughout the Clojure sequence library (i.e., the set of
> standard library functions responsible for creating, traversing,
> transforming, and manipulating sequences), Clojure is able to have single
> implementations of all of the common Lispy higher order list transform

Re: How define alias for .indexOf? (def somealias .indexOf) does not work.

[Gary Trakhman]

memfn will do this for you https://clojuredocs.org/clojure.core/memfn

But it's usually the wrong thing.  Wrt reflection-perf/warnings, you'd be
better off with an anonymous function and typehint most of the time.


On Thu, Jul 19, 2018 at 1:33 PM Christian Seberino 
wrote:

> How define alias for .indexOf?
>
>  (def somealias .indexOf) does not work.
>
> cs
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

[Gary Trakhman]

Well, actually, concat returns a seq, not a list. For all practical
purposes, it looks like a list, but it isn't one.  Practically, the
difference is laziness, which is a whole thing on its own. Also the count
operation is linear when lists just keep track of their length, and can do
it in constant-time.

On Wed, Jul 18, 2018 at 11:17 AM Christian Seberino 
wrote:

> Actually I was just kicked out of paradise.  concat always returns a list
> and does NOT return a vector for this (concat [1 2] [3 4]) sadly.
>
> cs
>
> ___
>
> Christian Seberino, Ph.D.
> Phone: (936) 235-1139
> Email: cseber...@gmail.com
> ___
>
>
>
> On Wed, Jul 18, 2018 at 2:16 AM, Didier  wrote:
>
>> It's never a good idea to use the wrong data structure for the job.
>>
>> And thus Clojure takes the stance that it won't make bad ideas easy for
>> you to use. Yet, it will never prevent you from doing anything.
>>
>> If you want to do something bad, you'll need to get your own hands dirty.
>>
>> That's why slow data structure access functions don't exist as standard.
>> That's why data transforms are lazy by default. And why the non lazy
>> variant (transducers) do loop fusion for you. That's why mutability is ugly
>> and requires you to wrap things in extra verbosity. That's why OOP isn't
>> there, and forces you to use the host interop if you want it. That's why
>> there's only recursive loops. Etc.
>>
>> The Clojure standard lib is opinionated. It's not trying to make
>> everything easy and convenient. It's trying to make things simple to reason
>> about, and promote Rich Hickeys opinion of what is a good idea, and what
>> isn't.
>>
>> But, it can afford to be this way, because it made itself a Lisp, meaning
>> it gave you all the power needed to disagree and make your own core, which
>> follows your own opinions of good and bad.[1]
>>
>> Now, I recommend that everyone should have a core library of their own
>> that they keep around for cases like this, where they disagree.
>>
>> And for beginners, I mean, what are you trying to teach them? What
>> problem requires them to add items to the beginning and end of an ordered
>> collection?
>>
>> Anyways, my advice is to teach them concat. It's even nicer then
>> append/prepend. You just give it the arguments where you want them to go.
>>
>> (concat [1] [2 3])
>>
>> (concat [1 2] [3])
>>
>> And it works for any type of ordered collections, even arrays.
>>
>> Also, this blog I think does a great job at teaching all this to a
>> beginner
>> https://medium.com/@greg_63957/conj-cons-concat-oh-my-1398a2981eab
>>
>>
>>
>> [1] Except for reader macros. Rich didn't want you to be able to change
>> the whole program syntax in unconstrained ways. That's probably a good
>> thing to at least keep the foundation universal accross code bases.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group 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://group

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

[Gary Trakhman]

Concat does the job except for keeping the input collection type.  It will
seq anything you throw at it.

There's a general trade-off here. When I started working in ocaml recently
I was taken aback that the List.map call we used constantly would have to
build the new list backwards in linear time, and then reverse it in linear
time, with some crazy stack expansions as an optimization for smaller
lists. I've said stuff like 'i would be happy to have a map call that
changed type on me sometimes', but honestly I've never had to dig that deep
for performance, and when I do, it's to switch to a more async-incremental
Pipe thing analogous to core.async chans.

On Wed, Jul 18, 2018, 3:16 AM Didier  wrote:

> It's never a good idea to use the wrong data structure for the job.
>
> And thus Clojure takes the stance that it won't make bad ideas easy for
> you to use. Yet, it will never prevent you from doing anything.
>
> If you want to do something bad, you'll need to get your own hands dirty.
>
> That's why slow data structure access functions don't exist as standard.
> That's why data transforms are lazy by default. And why the non lazy
> variant (transducers) do loop fusion for you. That's why mutability is ugly
> and requires you to wrap things in extra verbosity. That's why OOP isn't
> there, and forces you to use the host interop if you want it. That's why
> there's only recursive loops. Etc.
>
> The Clojure standard lib is opinionated. It's not trying to make
> everything easy and convenient. It's trying to make things simple to reason
> about, and promote Rich Hickeys opinion of what is a good idea, and what
> isn't.
>
> But, it can afford to be this way, because it made itself a Lisp, meaning
> it gave you all the power needed to disagree and make your own core, which
> follows your own opinions of good and bad.[1]
>
> Now, I recommend that everyone should have a core library of their own
> that they keep around for cases like this, where they disagree.
>
> And for beginners, I mean, what are you trying to teach them? What problem
> requires them to add items to the beginning and end of an ordered
> collection?
>
> Anyways, my advice is to teach them concat. It's even nicer then
> append/prepend. You just give it the arguments where you want them to go.
>
> (concat [1] [2 3])
>
> (concat [1 2] [3])
>
> And it works for any type of ordered collections, even arrays.
>
> Also, this blog I think does a great job at teaching all this to a
> beginner
> https://medium.com/@greg_63957/conj-cons-concat-oh-my-1398a2981eab
>
>
>
> [1] Except for reader macros. Rich didn't want you to be able to change
> the whole program syntax in unconstrained ways. That's probably a good
> thing to at least keep the foundation universal accross code bases.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

[Gary Trakhman]

Data to most people means tabular or relational data and not complex,
compound data, and EDN is a funny case, since it is not the concrete
representation.  What about print-dup, and print-method? Is that subtlety
inherent to the elegance?  How often do you really need complex, immutable
keys?  What about persistent data structures? Sure we make a lot of seqs,
but banging on a vec or map outside of a reduce is an occasional thing, and
most maps are really small, so the copies aren't that slow to start with.

I agree that clojure is self-consistent and has an inherent beauty to it, I
guess I'm arguing that it's not the only way to skin the cat and people
learning a new language are going to use whatever they already know to make
analogies into the new system, and it is a mistake to say something like
'why even start to think about it that way when you won't later if you
stick around long enough'?

On Tue, Jul 17, 2018 at 4:06 PM Gregg Reynolds  wrote:

>
>
> On Tue, Jul 17, 2018, 2:49 PM James Reeves  wrote:
>
>> On Tue, 17 Jul 2018 at 19:52, Christian Seberino 
>> wrote:
>>
>>> By the time a Clojure beginner is doing the kind of hardcore concurrent
>>> applications that Clojure is great at, he/she will know how to use a
>>> profiler.  At the point,  they'll be ready (and motivated!) to learn about
>>> the nuances of conj and friends.
>>>
>>
>> I think this is approaching Clojure from the wrong direction. If I was
>> teaching Clojure, I'd build the lessons around the data structures first.
>>
>
> That is a legit approach, but I think it misses the mark.
>
> Q: is a clojure map a datum or a function?
>
> A: Yes!
>
>>
>> My opinion is that many languages take a "code first" approach to
>> language design, whereas Clojure takes a "data first" approach
>>
>
> Ymmv, but that's not how I think of it. Clojure is function first to me -
> but data are functions and vice-versa. That's the beauty of 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.

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

[Gary Trakhman]

On Tue, Jul 17, 2018 at 1:35 PM Alex Miller  wrote:

> You can talk about Clojure operations from a type perspective, but I think
> when you do so, you are largely missing the point of Clojure.
>
>
Having used Clojure for a very long while, I will have to respectfully
disagree with this one.  Clojure tries to help you reason about programs,
and so do other tools, we're all on the same team.

Not sure if OP is trying to use clojure to understand computers or
clojure.  Some ideas that help large programs can be a distraction on
really small ones, like polymorphism.

Simple Made Easy only really speaks to people once they've felt the pain of
living in the kind of larger-scale mess it addresses and now devs suddenly
have a vocabulary to explain it, it's not really going to make sense sooner.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group 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: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

[Gary Trakhman]

I'm just referring to a language design tradeoff, specifically clojure
picks ad-hoc polymorphism over making it easy to reason about types.
Subtyping, polymorphism, and the ability to do efficient type inference
(auto and human) are a real debate outside of clojure.

People wanting more specific functions are looking for it to be easier to
know the type of something.

Clojure and other dynamic languages tend to convert stuff for you all the
time implicitly, which you get used to eventually, but the OP was talking
about using this for education, and I think no one wants to learn about
computational complexity before they can add something to the right side of
a list.

On Tue, Jul 17, 2018 at 1:07 PM Alex Miller  wrote:

>
> On Tuesday, July 17, 2018 at 11:06:51 AM UTC-5, Gary Trakhman wrote:
>>
>> It's pretty hard in clojure to keep track of a data structure and ensure
>> some function introduced later in the middle of a data path doesn't seq it
>> along the way.
>>
>
> I'll again refer to the faq for when stuff like this comes up:
> https://clojure.org/guides/faq#seqs_vs_colls
>
> There is definitely some learning involved in this but in general I feel
> like it's not "pretty hard". The majority of the time you can even blur
> over the coll/seq distinction entirely and just focusing on writing your
> code to apply operations to sequential data.
>
>
>> You get some discipline around this, but it adds to the learning curve.
>>
>> I wouldn't say polymorphism is better or easier than being stricter with
>> types in a core library, especially when it comes to modifications, but
>> it's super useful on reads (iterators, seqs, slurp).  I will say that this
>> is like a 2008-era debate whose ship has sailed in clojure.
>>
>
> Not sure what you mean. Generally you shouldn't be using iterators at all
> unless you're dealing with Java interop and slurp is something that returns
> a string. This does not relate to any debate I'm aware of.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

[Gary Trakhman]

It's pretty hard in clojure to keep track of a data structure and ensure
some function introduced later in the middle of a data path doesn't seq it
along the way.  You get some discipline around this, but it adds to the
learning curve.

I wouldn't say polymorphism is better or easier than being stricter with
types in a core library, especially when it comes to modifications, but
it's super useful on reads (iterators, seqs, slurp).  I will say that this
is like a 2008-era debate whose ship has sailed in clojure.

On Tue, Jul 17, 2018 at 11:34 AM Alex Miller  wrote:

> I think you're no longer teaching Clojure then. The values embedded in
> this design choice are important and erasing them does a disservice to
> learners.
>
> I think by fighting this, you're actually making Clojure harder than it is.
>
>
> On Tuesday, July 17, 2018 at 9:49:33 AM UTC-5, Christian Seberino wrote:
>>
>> Alex
>>
>> Thanks for all the replies.  It is clear there are 2 values in language
>> design...*simplicity* and *efficiency*.  Sometimes they conflict
>> unfortunately.
>> Clojure sacrificed a tiny amount of simplicity for a huge gain in
>> efficiency with the design of conj and friends.
>>
>> Imagine someone wanted to have Clojure compete with Python and Scheme for
>> introductory programming classes. In that space
>> simplicity is everything.  Maybe it would make sense there to teach using
>> "prepend" and "append" functions to keep things as simple as possible.
>> Then, later when they were more confident and ready, efficiency
>> considerations and conj could be explained.
>>
>> Would that give the best of both worlds?  Everyone could have what they
>> want when they want it.
>>
>> cs
>>
>>
>>
>>
>> On Monday, July 16, 2018 at 4:30:51 PM UTC-5, Alex Miller wrote:
>>>
>>>
>>>
>>> On Monday, July 16, 2018 at 4:08:47 PM UTC-5, solussd wrote:

 Another way to think about it is lists and vectors are different and
 the idiomatic way to add items to them is different.

>>>
>>> I would say different data structures have different ways to
>>> *efficiently* add items to them, and conj is an operation to add items
>>> efficiently (meaning, sub-linear time). So when you see conj, you know it
>>> is always a "fast" operation.
>>>
>>>
 A (singly-linked) list is usually prepended to (otherwise you have to
 walk the entire list to find the end). A vector is usually added to at it’s
 n+1 index, where n is the size of the vector. The conj function is
 polymorphic.

 cons takes a seq and returns a seq. It only cares that it can get a seq
 on whatever collection you give it and will always prepend to that seq.

>>>
>>> Slight modification - I would say cons takes a *seqable* and returns a
>>> seq. For example, a vector is seqable, but not a 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 - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group 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: What is the minimal Emacs config for practical Clojure development?

[Gary Trakhman]

I'm not sure the desires for lightweight clojure-emacs integration and any
CLJS integration are yet sympathetic.  Figwheel is a pretty complex piece
of software. For example, see my issue that has been languishing for almost
a year and hints at greater problems with the compiler integration:
https://github.com/bhauman/lein-figwheel/issues/593 .  From my perspective,
this is more due to coupling of the REPL to the compiler itself than a
problem with figwheel.

But I was surprised when the thread went in this direction just from
reasons I think someone might want to not use cider, fast startup time,
less stuff to go wrong.  CLJS adds that back unless it's gotten
significantly better since the last time I tried.

On Thu, Jul 5, 2018 at 2:19 PM rob  wrote:

> If ClojureScript repl integration works smoothly out of the box then
> that's already one reason to use it over Cider...  (This is not a jab at
> Cider, just a statement of fact that Cider's support for ClojureScript
> development has so far been lacking, IME)
>
>
> On Thursday, July 5, 2018 at 10:51:02 AM UTC-7, Austin Haas wrote:
>>
>>
>> I tried Monroe, yesterday. It seems to work as advertised. I didn't have
>> any issues. It's nice that "jump to definition" works out of the box. It
>> does not appear to support Eldoc, so no help with function signatures.
>>
>> This is the Emacs config I'm currently using:
>>
>> ;;; clojure-mode
>>
>> (add-to-list 'load-path "~/.emacs.d/site-lisp/third-party/clojure-mode/")
>> (require 'clojure-mode)
>> (add-hook 'clojure-mode-hook 'rainbow-delimiters-mode)
>> (add-hook 'clojure-mode-hook 'paredit-mode)
>> (add-hook 'clojure-mode-hook 'hs-minor-mode)
>> (add-hook 'clojure-mode-hook #'eldoc-mode)
>>
>> ;;; REPL
>>
>> ;; Monroe
>>
>> (add-to-list 'load-path "~/.emacs.d/site-lisp/third-party/monroe/")
>> (require 'monroe)
>> (add-hook 'clojure-mode-hook 'clojure-enable-monroe)
>> (setf monroe-detail-stacktraces 'true)
>>
>> I went on to include Figwheel.
>>
>> I created a new project using `lein new figwheel my-project` (which
>> provides the fig-start and cljs-repl functions), and then entered the
>> following commands to set up a Clojurescript dev environment:
>>
>> M-x monroe-nrepl-server-start
>> M-x monroe
>> (fig-start)
>> (cljs-repl)
>>
>> On my machine, those 4 steps take about 30 seconds to run. The first
>> takes 18 seconds, and the rest only take about a second each, but the whole
>> process ends up taking close to 30.
>>
>> Figwheel seems to work great, but I couldn't figure out how to evaluate
>> code in a library dependency and have it updated in the running system. I
>> can evaluate functions, but the new definitions don't appear to be called
>> by the main code. I might be misunderstanding how this is supposed to work;
>> I don't know if it's a Figwheel issue or a Monroe issue or my mistake. But
>> to work around that, and to fix other issues preventing a clean initial
>> compilation, I had to restart the REPL a few dozen times, which was tedious.
>>
>> I'm posting this information in case it is useful to someone else who is
>> trying to discover the current state-of-the-art with running Clojure in
>> Emacs in a straightforward, minimal way. I'm also hoping that people will
>> reply with comments and suggested improvements. (FWIW, I've been using
>> Emacs full-time for about 20 years, Clojure full-time for about 7 years,
>> and Common Lisp for 5+ years before that, so I'm not new to REPL-driven
>> development in Emacs.)
>>
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Anyone spent time with Kawa Scheme?

[Gary Trakhman]

If you're looking for fast CLI utilities, ocaml can be a good fit, or
grenchman for loading clojure code, in this particular case (written in
ocaml): https://github.com/technomancy/grenchman

You don't really need persistent data structures for those use-cases, do
you?  But it does have seqs and async pipes (like channels) etc. My
employer uses Jane St's core/async libs which bundle all that in a
semi-coherent fashion.

Any of those options might be a tradeoff for mindshare and cases covered,
but common lisp might also be a good choice.

On Wed, Apr 4, 2018 at 12:35 AM 'somewhat-functional-programmer' via
Clojure  wrote:

> Thank you for posting these video links along with the time markers.  I
> thought I'd enjoyed all of Rich Hickey's presentations before but I
> actually hadn't seen his "Clojure for Lisp Programmers".  Clojure is the
> only lisp I "know" (still relatively a beginner) but have been fortunate
> enough to use full-time for the last few years -- given my Java background,
> I naturally had started with his "Clojure for Java Programmers".
>
> I did not intend to suggest that Clojure should have been a library to a
> Scheme or Common Lisp.  I love the language as it is and not having a prior
> lisp background, absolutely appreciated watching the "Clojure for Lisp
> Programmers" (as now having some lisp experience, I could more fully
> appreciate some of Clojure's roots).  I've dabbled with toy programs in
> both ABCL/SBCL as well as Kawa mostly out of curiosity.
>
> My reasons for asking my questions about other people's use of Kawa is
> that the performance characteristics of its runtime made me think maybe it
> may be applicable to some areas where Clojure may be a tougher choice
> (Android, CLI utilities).  I think Clojure startup time correlates with how
> many vars defined, and startup time of my projects increases with var
> counts.  I'm curious if any more thought has gone into this topic on the
> wiki: https://dev.clojure.org/pages/viewpage.action?pageId=950293.
>
> I can't give up writing software in an immutable/functional style after
> using Clojure for a couple of years, and was starting to think about what a
> program using Kawa could look like using Clojure's immutable data
> structures and STM.
>
> What I've settled into doing for using Clojure for CLI utilities thus far
> has been to just leave an instance running a socket repl on my machine
> always running and connect to it via rlwrap and socat (only using it
> interactively though):
>
> rlwrap  socat STDIN TCP4:localhost:
>
> Anyhow, thanks again for the video link, always a treat to watch a Rich
> Hickey Clojure talk that I hadn't seen before.
>
>
> ‐‐‐ Original Message ‐‐‐
> On April 4, 2018 3:23 AM, 'André' via Clojure 
> wrote:
>
> They maybe relevant too:
>
> https://www.youtube.com/watch?v=2V1FtfBDsLU, around 1h4min
>
> On 04/03/2018 05:29 PM, 'André' via Clojure wrote:
>
> Rich has covered some of the motivation of why not extending existing
> Lisp->Java integrations, like Kawa and ABCL:
>
> https://www.youtube.com/watch?v=cPNkH-7PRTk, around 3:25
>
>
> On 04/02/2018 05:53 PM, 'somewhat-functional-programmer' via Clojure wrote:
>
> I've recently come across Kawa Scheme and am very intrigued by it.  It's
> Java integration is superb like Clojure and it's very fast.  Has anyone
> here used it to build something?
>
> So far I've only tried it with small toy programs.  Things I like about it:
>   - Starts up very quickly
>   - Java method notation lends itself to auto-complete
>  (instance:method param1 param2)
>   - Can pre-compile and use it on Android
>   - Repl has line numbers so compilation errors on repl forms have source
> lines
>
> Maybe Kawa fits into a niche that Clojure leaves open with its heavier
> runtime?  Maybe I'm just trying toy programs and those toy programs are
> fast? :-)
>
> One thing that intrigues me here though since java integration is so easy
> with Kawa is the notion of using Clojure's immutable data structures from
> Kawa -- maybe even making a clojure "core" library for use from Kawa.
>
> -lc
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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 po

Re: Why does the `def-` not exist?

[Gary Trakhman]

If you're an emacs user, have you considered Yasnippet? It shouldn't be too
hard to add to this:
https://github.com/mpenet/clojure-snippets/tree/master/snippets/clojure-mode
.

Personally, I just don't use private defs at all.  Inevitably, you'll have
to var-hack them during testing, so at some point I stopped doing so.

On Mon, Feb 26, 2018 at 2:50 PM Leon Grapenthin 
wrote:

> I have written enough Clojure so that I can assure you that every few days
> when I type ^:private again I am still annoyed by it. Not every time, but
> probably every second or third time.
>
> Its just in the way of the prototyping typing (micro-)flow. SHIFT-6 you
> don't hit so often so you have to hit it right. On german keyboards, by the
> way, ^ is a much more annoying character to type. Then a colon, did I miss
> the colon? What did I want to do again?
>
> When prototyping an API ns its important to distinguish what is private
> and what isn't. If only I could just write def- without any overhead.
>
> First world aka best language problems, I know...
>
> But whats left for an enthusiast except bikeshedding? We both know that a
> JIRA discussion on this will not happen due to a lack of importance. And
> unless somebody manages to convince Rich, this feature won't happen.
>
> Fair enough. I'd consider myself a power user since 1.5.1 and value its
> conservative governance above every other kind.
> The "lets not start postfixing lots of macros with -" argument a good one
> in general and probably was a good one at the time. But not in this case
> because defn and def are the two most used and most elementary top level
> forms.
>
> This argument didn't convince anyone who has asked me about this. The
> counter argument goes "I don't want the - postfix for anything else, just
> for def because I use it a lot" -rightfully so.
>
> The lack of def- is just unnecessary typing overhead in lots of cases. It
> could be removed at the cost 5m on a beautiful day. I'd appreciate it :)
>
> On Monday, February 26, 2018 at 6:52:51 PM UTC+1, Alexander Yakushev wrote:
>>
>> - Not that often. When I know for certain, I add ^:private. Not like it's
>> much more work. If I didn't know ahead of time, I would forget to add the
>> private flag in either case.
>> - Never.
>> - Can't recollect such an event.
>> - A few times. As far as I can tell, people appreciate the metadata
>> approach since it is unique and powerful. The lack of one particular
>> non-critical syntactic sugar is never an issue.
>>
>> I won't mind having def- as much as I don't mind not having it. Pretty
>> much the same as for defn- – Earth wouldn't stop turning if you had to type
>> defn ^:private once in a while.
>>
>> And while I agree with you that it would be somewhat useful, bikeshedding
>> only gets you so far.
>>
>> On Monday, February 26, 2018 at 7:17:05 PM UTC+2, Leon Grapenthin wrote:
>>>
>>> - How many times do you just write (def ...) instead of (def ^:private
>>> ...) because you are not sure whether you need the definition yet, want to
>>> save effort, and then you forget to add ^:private later?
>>> - How many times have you implemented def- yourself into your project
>>> and then used only half of the time because you had to require and :refer
>>> the thing from some util namespace which is just as annoying as typing
>>> ^:private?
>>> - How many times do you use autocomplete on some namespace and find
>>> internals because their dev forgot ^:private?
>>> - How many times in a year do you have to explain to a Clojure newbie
>>> that there is defn- but no def-?
>>>
>>> IME the statistic strongly supports def- - and I don't see why it would
>>> hurt.
>>> Having def- in clojure.core will not magically result in having
>>> defmacro- and defmulti- and xyz-. Its a false and the only counterargument
>>> I have seen.
>>>
>>> It would be very useful, though.
>>>
>>> On Monday, February 26, 2018 at 1:44:27 PM UTC+1, Alexander Yakushev
>>> wrote:

 Usually, it is better to use metadata rather than create an exponential
 explosion of names. Public/private is just one dimension, but you also have
 static/non-static, dynamic/non-dynamic, etc. Then you have functions, vars,
 macros, perhaps modified functions (like schema.core/defn). Cartesian
 product of those would be huge.

 defn- is an exclusion from the rule probably because it is used more
 often than others.

 On Monday, February 26, 2018 at 10:58:43 AM UTC+2, Promise. wrote:
>
> `defn-` => `defn`
> 'def-` => `def`
>
 --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received th

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

[Gary Trakhman]

@garyv, I haven't tested/profiled in a really long time, but I recall the
majority of startup time being spent in Class.forName.  I'm not sure how to
verify startup exactly, but it should be easy to profile a top-level repl
'require' call from the user ns, which is doing essentially the same work,
except it wouldn't show the difference between direct-linked code and
nondirect, and you'd have to be careful to AOT your project so you're not
just profiling the compiler.

On Wed, Jan 24, 2018 at 8:39 AM Gary Verhaegen 
wrote:

> I've read a mot of discussions around that but have never myself looked
> into the details, so the following may be completely wrong.
>
> My understanding is slightly different: the JVM does not actually load a
> class before it is first accessed by running code. What takes a long time
> for the JVM and not for JS engines, I think, is not loading the code, but
> creating objects.
>
> For Clojure to run, all of your functions need to exist as objects in
> memory. Java bytecode does not have any mechanism to describe objects, so
> when Clojure starts up, it has to first load the code that defines the
> classes, then load the code that creates instances of those classes, and
> then execute that code to actually get the function objects. Only then can
> it start even thinking about looking at your own code. AOT thus just saves
> on parsing string files into Clojure lists, but it cannot really help with
> the problem that all of these objects still have to be created again from
> scratch at each start up.
>
> The javascript engines have a way of representing objects directly (aka
> json), so this is much less of a problem: a lot of that object creation can
> be done at compile time and the js engine can just load objects in memory
> directly from the js file. You can go further (like Lumo does) by
> preloading these objects in memory directly as part of the executable
> bundle, skipping the part where you need to parse a string.
>
> So in my understanding it mostly boils down to the ability to define
> objects directly, so they can just be loaded in memory, versus having to
> load and execute code to create the objects.
>
> On 24 Jan 2018, at 09:09, Didier  wrote:
>
> So if that is true, then the slow startup times are to blame on Java. I
> understand that Clojure does a lot of extra stuff at startup that a plain
> Java main method would not, but those extra things Clojure does are slow,
> because of the way the JVM handles them, where as they are quite fast on V8
> or other JavaScript engines.
>
> On Friday, 14 July 2017 16:24:33 UTC-7, Gary Trakhman wrote:
>>
>> My mental model explains most of this away due to the different load
>> patterns of java vs v8.  In JVM clojure, functions are essentially 1:1 with
>> classes, so in a functional language and standard lib, that's a lot of
>> classes.  Java will eagerly classload your entire app and deps before doing
>> any work.  V8 takes an upfront hit on parsing into javascript, but the JS
>> target fits the structure of clojure itself much more closely.  More time
>> (not sure how much compared to JVM) will be spent JITing hot code paths,
>> but that won't show up in the startup cost.
>>
>> You can get JVM clojure REPL startup a little faster by AOT compiling all
>> your deps, but it's generally not worth it in a development flow.
>>
>> I think lumo does some extra tricks to keep this upfront cost down that
>> are v8-specific:
>> https://anmonteiro.com/2016/11/the-fastest-clojure-repl-in-the-world/
>>
>> On Fri, Jul 14, 2017 at 6:20 PM Didier  wrote:
>>
>>> This link:
>>> https://dev.clojure.org/display/design/Improving+Clojure+Start+Time says
>>> that the Java startup time is ~94 ms, while Clojure boot time is ~640
>>> ms. That's a ~680% increase.
>>>
>>> On my machine the java start time is: ~1042 ms, and the Clojure start
>>> time is around ~3108 ms. A ~298% increase.
>>>
>>> When I time the startup time of lumo against node, I get ~1190 ms for
>>> node, and ~1523 ms for lumo. A ~128% increase only.
>>>
>>> Does Clojure perform more initialization then ClojureScript? And would
>>> that explain the much higher overhead Clojure has on top of the JVM, versus
>>> ClojureScript?
>>>
>>> --
>>> 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 un

Re: [ANN] Git Deps for Clojure!

[Gary Trakhman]

Specifically, I'm asking about how to resolve duplicate transitive
dependencies to actual code, possibly referring to the same lib repo at
different git hashes, or different git repos.

I think you answered, 'how do you get a single graph of deps nodes given
different kinds of deps'?

For example:
A->B->C#some_tag
A->D->C#other_tag

So, assuming you use a lot of git deps, which I think is the long-term
intent here based on the messaging, resolving those pointers to actual
loaded code is a potential problem that needs to be addressed somehow.  I
mentioned one way, which is to have multiple copies of a lib loaded
automatically.

>From what I can tell so far, it seems like you can override a dep's
specific transitive deps, but that sounds painful when scaled out over
number of deps and how many more commit hashes exist than maven release
tags for each lib.

Another way to do it might be to make the git repo url+branch itself could
be part of the namespace var mapping, but that seems far off based on the
way clojure namespaces currently work, and doesn't cover the common case
(at least it's what we're used to with maven) of just resolving a single
version for each dep.

Is there some existing design thought along these lines that I've missed?

On Fri, Jan 5, 2018 at 2:39 PM Alex Miller  wrote:

> On Fri, Jan 5, 2018 at 1:20 PM, Gary Trakhman 
> wrote:
>
>> Congrats on the release! It's exciting to see this vision move forward.
>> Wondering if the logical next step is the npm style of trees of duplicate
>> transitive git deps.  In general, how is this going to work for transitive
>> deps?
>>
>
> tools.deps has the ability to read a file-based manifest in a git dep (or
> a local dep) and traverse its transitive dependencies. This works now for
> deps.edn based libraries and can be extended for other manifest types.
>
> I have started work on a pom.xml manifest reader. lein is harder to do
> right, but maybe easy to do badly. :)  There are still some things to work
> out wrt how manifest readers like this are dynamically found and loaded;
> currently they have to be "in the box" but I see that's not the final end
> state.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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] Git Deps for Clojure!

[Gary Trakhman]

Congrats on the release! It's exciting to see this vision move forward.
Wondering if the logical next step is the npm style of trees of duplicate
transitive git deps.  In general, how is this going to work for transitive
deps?

On Fri, Jan 5, 2018 at 1:49 PM Alex Miller  wrote:

> Pleased to announce some new functionality for clj and tools.deps!
>
> https://clojure.org/news/2018/01/05/git-deps
>
> Additionally, there have been new releases of:
> - Brew clojure formula (to get it: brew upgrade clojure)
> - Linux clojure installer (see https://clojure.org/guides/getting_started
> for info)
> - tools.deps.alpha 
> - NEW tools.gitlibs 
>
> Other than git deps, "clj -Spom" for pom generation has some fixes and an
> addition to add Maven repositories 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: sorting a list based on the order of its items in another list

[Gary Trakhman]

How about (filter (set small-list) big-list) ?

On Dec 12, 2017 8:25 AM, "Deyan Yotsov"  wrote:

> Hello,
>
> I have one list of potentially up to 2 million strings: big-list.
>
> Then I have another list, small-list, the elements of which are a subset
> of the elements of big-list.
>
> I want to sort the elements in small-list so that they become sorted in
> the same way in which they are sorted in big-list.
>
> The most obvious way to do this, for me, is:
>
> (filter #(some #{%} small-list) big-list)
>
> (one by one we take the elements from big-list, we check if they are in
> small-list, and if they are, we add them (in big-list order) to the result)
>
> But of course this performs extremely poorly, especially if small-list is
> say 1M elements, and big-list is 2M elements.
>
> Suggestions?
>
> Thank you,
>
> Deyan
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group 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: Am I being stupid regarding how much memory I use?

[Gary Trakhman]

I don't know about MySQL specifics, but I did a similar job on top of
postgresql and relied on its built in temporary tables, indexes and
spill-to-disk functionality, the dataset/computation in question was
already blowing up a Ruby process. There's no need to reinvent it in
clojure if the database can do the work and it's already
deployed/operationalized.

We also made heavy use of js and plv8 on that project for complex map ops.
The tests were written in clojure :).

On Nov 12, 2017 8:18 AM,  wrote:

> I recently worked on a minor project that nevertheless needed to use 10
> gigs of RAM. It ran on a reasonably powerful server, yet it taxed that
> server. And I wondered, how are people scaling up such processes? If my
> approach was naive, what does the less naive approach look like?
>
> I wrote a simple app that pulled data from a MySQL database, denormalized
> it, and then stored it in ElasticSearch. It pulled about 4 million
> documents from MySQL. Parts of the data needed to be built up into complex
> structures (maps, vectors) before being put into ElasticSearch. In the end,
> the 4 million rows from MySQL became 1.5 million documents in ElasticSearch.
>
> I was wondering, what if, instead of 4 million documents, I needed to
> process 400 million documents? I assume I would have to distribute the work
> over several machines? I'm curious what are some of the most common routes
> for doing so? Would this be the situation where people would start to use
> something like Onyx or Storm or Hadoop? I looked at Spark but it seems to
> be for a different use case, more about querying that denormalizing.
> Likewise, dumping everything onto S3 and then using something like Athena
> seems to be more for querying than denormalizing.
>
> For unrelated reasons, I am moving toward the architecture where all data
> is stored in Kafka. I suppose I could write a denormalizing app that reads
> over Kafka and builds up the data and then inserts it to ElasticSearch,
> though I suppose, on the narrow issue of memory usage, using Kafka is no
> different than using using MySQL.
>
> So, I'm asking about common patterns here. When folks have an app that
> needs more RAM than a typical server, what is the first and most common
> steps they take?
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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

[Gary Trakhman]

Grimoire has a usage heatmap, I think it just might be over a few projects:
https://www.conj.io/heatmap

On Oct 26, 2017 7:40 AM, "Erik Assum"  wrote:

> Eric Normand did some research on this some time ago:
>
> http://www.lispcast.com/100-most-used-clojure-expressions
>
> Erik.
> --
> i farta
>
> 25. okt. 2017 kl. 23:05 skrev 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.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email 

Re: About determinism of async

[Gary Trakhman]

If you don't want to split at the consumer I would recommend adding another
channel, and piping it with a cat xform as mentioned above.

On Oct 11, 2017 3:28 AM, "JokkeB"  wrote:

> Thanks. I'm not interested in reading the messages as pairs, I just need
> to make sure nothing gets in between them. I think I'll choose some way to
> merge the messages, for example just a vector like you suggested, and then
> have the end consumer recognise and split the vector. I guess splitting the
> vector into two messages somewhere before the end consumer can't be made
> deterministic.
>
> keskiviikko 11. lokakuuta 2017 8.02.40 UTC+3 Rangel Spasov kirjoitti:
>>
>> I think simply wrapping the two values in a vector is the only thing
>> that's needed in this case. Simply do a put like (>!! ch [my-val-1
>> my-val-2]) and take from the channel from another place. If my-val-1 and
>> my-val-2 are not immediately available, you can have a separate mechanism
>> (atoms, (loop [...] (recur ...)) or another set of core.async channels
>> perhaps) that "collects" them until they are ready to be sent together as
>> one value.
>>
>> partition-all on its own does not really help with the ordering here. For
>> example:
>>
>> (let [ch (chan 42 (partition-all 2))]
>>   (>!! ch :x')
>>   (thread   ;in another 
>> thread far, far away
>> (> for random 0-99ms
>> ;put value on ch
>> (>!! ch :y'))
>>
>>   (> for random 0-99ms
>>   (>!! ch :x'')
>>
>>   ;take from ch
>>   (>
>>
>> This will non-deterministically output either
>> => [:x' :x'']
>>
>> or
>>
>> => [:x' :y']
>>
>> But again as I said, you can employ partition-all separately as a
>> "collecting" mechanism before doing the (>!! ch [my-val-1 my-val-2]).
>> Didn't write an example for that but let me know if that's not clear and
>> I can put together a few lines.
>>
>> On Tuesday, October 10, 2017 at 7:50:20 AM UTC-7, Gary Trakhman wrote:
>>>
>>> So, at the point where you need 2 things to be consecutive, wrap them up
>>> in a vector so they're one thing. `(partition-all 2)` will return a
>>> transducer xform that chunks up your message stream by 2
>>> https://clojuredocs.org/clojure.core/partition-all, and if you need to
>>> undo it you can do so with the `cat` transducer
>>> https://clojuredocs.org/clojure.core/cat .
>>>
>>> On Tue, Oct 10, 2017 at 10:42 AM JokkeB  wrote:
>>>
>>>> Thanks for the response. That's what I suspected.
>>>>
>>>> How does partition help me in this case? I can't see any way of using
>>>> it.
>>>>
>>>> How about onto-chan, would that be deterministic? Or any other function?
>>>>
>>>>
>>>> tiistai 10. lokakuuta 2017 17.33.22 UTC+3 Gary Trakhman kirjoitti:
>>>>
>>>>> I think a core assumption is that all writes can yield control at any
>>>>> time to other worker go processes.  I wouldn't rely on the consecutive
>>>>> behavior even if it were true, nondeterminism is a good assumption with
>>>>> core.async.  If you need that particular guarantee, consider a call to
>>>>> partition?
>>>>>
>>>>> On Tue, Oct 10, 2017 at 10:30 AM JokkeB  wrote:
>>>>>
>>>> I'm wondering about a case when using async:
>>>>>>
>>>>>> I have a channel where I write from multiple threads. One of the
>>>>>> sources is a go-loop with a timeout, so each second I write something to
>>>>>> the channel. If I do two consecutive writes inside the go block, can
>>>>>> another thread write between the two writes? Or can I rely on the two
>>>>>> messages being consecutive in the channel?
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>>
>>>>> 

Re: Updating repeated nested structures?

[Gary Trakhman]

I wrote a terrible terrible function once to help with this while bored in
jury duty, called flipartial, in the style of core's 'let's expand/optimize
out the most common arities':

(defn flipartial
  "A combo of partial/flip, makes it easier to fake-curry
non-data-last functions.
In general, only used for small/obvious things, because it's about as hard to
mentally reverse complex positional args in usage as this was to implement, and
reversing large lazy seqs is generally more explicit and rare."
  ([f]
   (fn
 ([] (f))
 ([x] (f x))
 ([x y] (f y x))
 ([x y z] (f z y x))
 ([x y z & args] (apply f (concat (reverse args) [z y x])
  ([f arg1]
   (fn
 ([] (f arg1))
 ([x] (f x arg1))
 ([x y] (f y x arg1))
 ([x y z] (f z y x arg1))
 ([x y z & args] (apply f (concat (reverse args) [z y x arg1])
  ([f arg1 arg2]
   (fn
 ([] (f arg2 arg1))
 ([x] (f x arg2 arg1))
 ([x y] (f y x arg2 arg1))
 ([x y z] (f z y x arg2 arg1))
 ([x y z & args] (apply f (concat (reverse args) [z y x arg2 arg1])
  ([f arg1 arg2 arg3]
   (fn
 ([] (f arg3 arg2 arg1))
 ([x] (f x arg3 arg2 arg1))
 ([x y] (f y x arg3 arg2 arg1))
 ([x y z] (f z y x arg3 arg2 arg1))
 ([x y z & args] (apply f (concat (reverse args) [z y x arg3 arg2 arg1])
  ([f arg1 arg2 arg3 & more]
   (fn
 ([] (apply f (concat (reverse more) [arg3 arg2 arg1])))
 ([x] (apply f x (concat (reverse more) [arg3 arg2 arg1])))
 ([x y] (apply f y x (concat (reverse more) [arg3 arg2 arg1])))
 ([x y z] (apply f z y x (concat (reverse more) [arg3 arg2 arg1])))
 ([x y z & args] (apply f (concat (reverse args) [z y x]
  (reverse more) [arg3 arg2 arg1]))




On Tue, Oct 10, 2017 at 4:17 PM hitesh  wrote:

> It's not terse, but it is easier to follow.
>
> (defn flip
>   [f x y]
>   (f y x))
>
> (defn update-nums
>   [m f]
>   (update m :qs
>   (fn [x]
> (flip map x
>   (fn [x]
> (update-in x [:nums]
>#(map f %)))
>
> ;; (update-nums m inc)
> ;;=> {:qs ({:nums (4 2 3)} {:nums (8 5)})}
>
>
>
>
>
> On Tuesday, October 10, 2017 at 12:27:45 PM UTC-4, Rob Nikander wrote:
>>
>> Gah. I changed one name and not another. I meant:
>>
>> (update-in m [:qs * :nums] ...)
>>
>>
>>
>> On Tuesday, October 10, 2017 at 10:18:56 AM UTC-4, Rob Nikander wrote:
>>>
>>> Hi,
>>>
>>> Say I have a map like this:
>>>
>>> (def m {:qs [{:nums [3 1 2]} {:nums [7 4]}]})
>>>
>>> I want to transform each number with a function (say, `inc`). I imagine
>>> something like this:
>>>
>>> (update-in m [:qs * :cell-fns] #(map inc %))
>>> ; or
>>> (update-in m [:qs * :cell-fns *] inc)
>>>
>>>
>>> But of course you can't write that.  The following code works, but I
>>> don't like reading it:
>>>
>>> (update m :qs
>>> (fn [qs]
>>>   (mapv
>>> (fn [q]
>>>   (update q :nums #(mapv inc %)))
>>> qs)))
>>> => {:qs [{:nums [4 2 3]} {:nums [8 5]}]}
>>>
>>> Is there an idiomatic way to do this, that looks more like the shorter
>>> `update-in` idea?
>>>
>>> Rob
>>>
>>>
>>>
>>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: About determinism of async

[Gary Trakhman]

So, at the point where you need 2 things to be consecutive, wrap them up in
a vector so they're one thing. `(partition-all 2)` will return a transducer
xform that chunks up your message stream by 2
https://clojuredocs.org/clojure.core/partition-all, and if you need to undo
it you can do so with the `cat` transducer
https://clojuredocs.org/clojure.core/cat .

On Tue, Oct 10, 2017 at 10:42 AM JokkeB  wrote:

> Thanks for the response. That's what I suspected.
>
> How does partition help me in this case? I can't see any way of using it.
>
> How about onto-chan, would that be deterministic? Or any other function?
>
>
> tiistai 10. lokakuuta 2017 17.33.22 UTC+3 Gary Trakhman kirjoitti:
>
>> I think a core assumption is that all writes can yield control at any
>> time to other worker go processes.  I wouldn't rely on the consecutive
>> behavior even if it were true, nondeterminism is a good assumption with
>> core.async.  If you need that particular guarantee, consider a call to
>> partition?
>>
>> On Tue, Oct 10, 2017 at 10:30 AM JokkeB  wrote:
>>
> I'm wondering about a case when using async:
>>>
>>> I have a channel where I write from multiple threads. One of the sources
>>> is a go-loop with a timeout, so each second I write something to the
>>> channel. If I do two consecutive writes inside the go block, can another
>>> thread write between the two writes? Or can I rely on the two messages
>>> being consecutive in the channel?
>>>
>>> --
>>> 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: About determinism of async

[Gary Trakhman]

I think a core assumption is that all writes can yield control at any time
to other worker go processes.  I wouldn't rely on the consecutive behavior
even if it were true, nondeterminism is a good assumption with core.async.
If you need that particular guarantee, consider a call to partition?

On Tue, Oct 10, 2017 at 10:30 AM JokkeB  wrote:

> I'm wondering about a case when using async:
>
> I have a channel where I write from multiple threads. One of the sources
> is a go-loop with a timeout, so each second I write something to the
> channel. If I do two consecutive writes inside the go block, can another
> thread write between the two writes? Or can I rely on the two messages
> being consecutive in the channel?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: [core.spec] Stricter map validations?

[Gary Trakhman]

I don't disagree that there might be a security use-case, and regardless of
how realistic it is businesses need people to tick boxes (that doesn't seem
like something core should worry about?), but what is the actual security
risk of an unspec'd map value, or things being referenced and unused?  The
ocaml (strict) type system allows for this for example with row polymorphic
records.

On Tue, Oct 3, 2017 at 1:25 PM Didier  wrote:

>  | Spec-tools (https://github.com/metosin/spec-tools) has some tools for
> this: the spec visitor (walking over all core specs, e.g. to collect all
> registered specs) and map-conformers: fail-on-extra-keys and
> strip-extra-keys.
>
> I understand the core team wanting to take a minimal approach to spec, and
> that open is easier to restrict later. But I worry that already in alpha
> state, spec is unpractical for many people as is, and Orchestra and
> Spec-tools are already needed supplement.
>
> For instrumentation, it's no big deal, but for specs I think it is. Having
> a canonical set of specs accross Clojure shops is a way to form a common
> language. If I start having my custom map specs, and so does everyone, I'd
> be tempted to say something core is missing. Strict map specs which also
> vallidates each key has a registerer spec I think is a glaring omission.
>
> Having used spec in one of my design, I've had to justify already to 6
> people, some being senior security engineers, why the validation allows for
> open keys. Other team members were just confused as to why that was, and
> the only argument I had was that Rich doesn't like to break APIs :p. But
> I've had to add validation on top to pass security audit. So I think while
> not breaking APIs when incrementally adding specs to legacy code is a good
> use case, there's the security and safety use case which seems to be shared
> by a large swat of Clijurist, and I think spec is in need of a core support
> for 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.

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

[Gary Trakhman]

I think there's the spec is a 'side-band' system (well except we want to
the compiler to know about it for macros) design constraint, but
additionally, I think it's worth thinking about:

Defn right now is primitive enough to be fast and powerful enough for large
programs.  There are many general and competing things a developer might
want to be available in a more powerful or opinionated defn, but I think
we'd agree the benefit of what you propose scales as a convention across a
larger codebase and so do other general defn wrappers.  I can think of a
few other examples like this, how about plumatic's defnk graph function
macro?  How about core.match pattern-matching with the 'defun' project?
How about the schema s/defn?  How would someone combine them when macros
generally don't compose too well?

I think that sort of thing should be possible, but too opinionated for how
'core' clojure.spec is intended to be.  Decisions like that are for
application architectures.

On Tue, Sep 19, 2017 at 5:29 PM Didier  wrote:

> I've been thinking since using Clojure.spec fdef that I'd like something
> like this:
>
> (defns foo
>   [x string? y int?] string?
>forms)
>
> Where an s/fdef spec automatically build of this form:
>
> (s/fdef foo
>   :args (s/cat :x string? :y int?)
>   :ret string?))
>
>
> And obviously the foo var and function would also be created.
>
> I feel like the core team didn't choose this route though, and so I'm
> curious why, and if its actually a bad idea?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Gary Trakhman]

The second to last apply argument doesn't spread args like the last slot.

- terseness from phone

On Sep 6, 2017 8:11 AM, "Cecil Westerhof"  wrote:

I have:
(def digits
 (apply str
(map char (inclusive-range (int \0) (int \9)

and this gives:
"0123456789"

I also have:
(def hex-digits
 (apply str
digits
(map char (inclusive-range (int \A) (int \F)
and this gives:
"0123456789ABCDEF"

So far so good. Then I define:
(def alphanumerics
 (apply str
digits
(map char (inclusive-range (int \A) (int \Z)))
(map char (inclusive-range (int \a) (int \z)))
))

but this gives:
"0123456789clojure.lang.LazySeq@4659426eabcdefghijklmnopqrstuvwxyz"

Why does it not give:
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"

The definition of inclusive-range:
(defn inclusive-range
  ([start end] (inclusive-range start end 1))
  ([start end step]
  (range start (inc end) step)))


-- 
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: core.async got in a bad state?

[Gary Trakhman]

Hm, I came across a similar ordering invariant (No code called by a go
block should ever call the blocking variants of core.async functions) while
wrapping an imperative API, and I thought it might be useful to use
vars/binding to enforce it.  Has this or other approaches been considered
in core.async?  I could see a *fixed-thread-pool* var being set and >!!
checking for false.

An analogy in existing clojure.core would be the STM commute's 'must be
running in a transaction' check that uses a threadlocal.
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LockingTransaction.java#L205

On Tue, Aug 29, 2017 at 1:30 PM Timothy Baldridge 
wrote:

> To add to what Alex said, look at this trace:
> https://gist.github.com/anonymous/65049ffdd37d43df8f23630928e8fed0#file-thread-dump-out-L1337-L1372
>
> Here we see a go block calling mapcat, and inside the inner map something
> is calling >!!. As Alex mentioned this can be a source of deadlocks. No
> code called by a go block should ever call the blocking variants of
> core.async functions (!!, alts!!, etc.). So I'd start at the code
> redacted in those lines and go from there.
>
>
>
> On Tue, Aug 29, 2017 at 11:09 AM, Alex Miller  wrote:
>
>> go blocks are multiplexed over a thread pool which has (by default) 8
>> threads. You should never perform any kind of blocking activity inside a go
>> block, because if every go block in work happens to end up blocked, you
>> will prevent all go blocks from making any further progress. It sounds to
>> me like that's what has happened here. The go block threads are named
>> "async-dispatch-" and it looks like there are 8 blocked ones in your
>> thread dump.
>>
>> It also looks like they are all blocking on a >!!, which is a blocking
>> call. So I would look for a go block that contains a >!! and convert that
>> to a >! or do something else to avoid blocking there.
>>
>>
>> On Tuesday, August 29, 2017 at 11:48:25 AM UTC-5, Aaron Iba wrote:
>>>
>>> My company has a production system that uses core.async extensively.
>>> We've been running it 24/7 for over a year with occasional restarts to
>>> update things and add features, and so far core.async has been working
>>> great.
>>>
>>> The other day, during a particularly high workload, the whole system got
>>> locked up. All the channels seemed blocked at once.  I was able to connect
>>> with a REPL and poke around, and noticed strange behavior of core.async.
>>> Specifically, the following code, when evaluated in the REPL, blocked on
>>> the put (third expression):
>>>
>>> (def c (async/chan))
>>> (go-loop []
>>>   (when-some [x (>> (println x)
>>> (recur)))
>>> (>!! c true)
>>>
>>> Whereas on any fresh system, the above expressions obviously succeed.
>>>
>>> Puts succeeded if they went onto the channel's buffer, but not when they
>>> should go through to a consumer. For example with the following
>>> expressions, evaluated in the REPL, the first put succeeded (presumably
>>> because it went on the buffer), but subsequent puts blocked:
>>>
>>> (def c (async/chan 1))
>>> (def m (async/mult c))
>>> (def out (async/chan (async/sliding-buffer 3)))
>>> (async/tap m out)
>>> (>!! c true) ;; succeeds
>>> (>!! c true) ;; blocks forever
>>>
>>> This leads me to wonder if core.async itself somehow got into a bad
>>> state. It's entirely possible I caused this by misusing the API somewhere
>>> in the codebase, but we use core.async so extensively that I wouldn't know
>>> where to begin looking.
>>>
>>> I'm wondering if someone more familiar with core.async internals has an
>>> idea about what could cause the above situation. Or if we notice it
>>> happening again, what could I do to gather more helpful information.
>>>
>>> I also have a redacted thread dump, in case it's useful:
>>>
>>> https://gist.github.com/anonymous/65049ffdd37d43df8f23630928e8fed0
>>>
>>> Any help would be much appreciated,
>>>
>>> Aaron
>>>
>>> P.S. core.async has been a godsend in terms of helping us structure and
>>> modularize our large system.  Thank you to all those who contributed to
>>> this wonderful library!
>>>
>>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group 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 thei

Re: Is Clojure victim of Spec ?

[Gary Trakhman]

I consider Clojure 1.9-alpha16 reasonably stable and not significantly more
full-featured than 1.8.  Is there any risk to using it, or any harm from
staying on 1.8?

In the past, conversations have come up about clojure's relative stability
in alpha versions compared to people's perceptions of versions and risk
tolerance from other ecosystems.

Besides the pain from the split of spec, does anyone know if there are any
remaining major changes planned to 1.9?

On Fri, Aug 18, 2017 at 12:53 PM Rafik NACCACHE 
wrote:

> Hey guys,
>
> Seems to be a long while we are waiting for 1.9
>
> I kinda feel that core.spec seems to always need more polishing so that's
> why it's still being delayed... Am I right ?
>
> --
>
>
> [image: --]
>
> Rafik Naccache
> [image: https://]about.me/rafik_naccache
>
> 
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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 rookie vs parsing

[Gary Trakhman]

I enjoyed working with clj-antlr recently, it's a wrapper over a java
library, but gives you a fast feedback loop with an interpreter instead of
generated java code.  The 'clojurey' part is that the output is a nested
sequence, from there it's really effective to use tree zippers and
core.match to transform the parse-tree into the data structure you need.

Take a look at:
https://github.com/clojure/core.match
https://github.com/aphyr/clj-antlr
https://www.ibm.com/developerworks/library/j-treevisit/
https://github.com/akhudek/zip-visit

On Tue, Aug 15, 2017 at 9:56 AM Laurens Van Houtven <_...@lvh.cc> wrote:

> Hi,
>
>
> Instaparse is a great parser generator, especially if you already have a
> BNF.
>
> Sent from my iPhone
>
> On Aug 15, 2017, at 08:44, sventrax...@gmail.com wrote:
>
> Thanks for your input. LFE is quite an unexpected "thing".
>
> What I'm trying to do, is just a "lunch time project"; something that I
> can target without corporate constrains just as a learning exercise.
> Furthermore I can test the Clojure version against my old working Java
> version.
>
> As I was saying, while experimenting with Instaparse, I'm having the
> feeling it is not the correct Clojure tool for this type of development
>
>
>
> On Tuesday, August 15, 2017 at 2:17:50 PM UTC+1, adrians wrote:
>>
>> If you need the features of Erlang but would like that in a Lisp (not
>> Common Lisp, though) environment, have you taken a look at LFE (Lisp
>> Flavored Erlang)? I'm not trying to discourage you from looking at Clojure,
>> but if you need/depend on some of the features of Erlang, LFE might be a
>> closer fit.
>>
>> http://lfe.io
>>
>> On Tuesday, August 15, 2017 at 8:11:53 AM UTC-4, svent...@gmail.com
>> wrote:
>>>
>>>
>>> Hi
>>>
>>> Months ago I read a review that praised Clojure's clean approach and use
>>> of JVM that is almost always available in my deployments.
>>>
>>> My background: started with 370 assembly ( so I'm not young!!!) and
>>> during the last four years I've been using Erlang for network applications.
>>> For my type of work the functional approach, concurrency and bit handling
>>> of Erlang are life savings. Nonetheless I feel "the call" of Clojure. As an
>>> exercise I would like to re implement something I did years ago in Java,
>>> i.e. a sort of parser. What I have on my hands is a DSL like this
>>>
>>> HeaderRule=hr-ftp
>>>Term=100
>>>   name="ftp"
>>>   From=1
>>>  networkPort="21"
>>>  Protocol=1
>>> Tcp=1
>>>up
>>> up
>>>  up
>>>   Then=1
>>>  ProtocolInspection=1
>>> ftpRuleSet="frs-ftp"
>>> up
>>>  ServiceDataFlowId=1
>>> payload=99
>>> up
>>>  up
>>>   up
>>>up
>>> HeaderRule=hr-http
>>>   ..
>>>
>>> For my old Java implementation I used state machines to build an
>>> internal representation, sort of an AST, that would be used to analyze pcap
>>> files. In my Clojure challenge, I would like to have a different approach.
>>> Googling around I've found many options: Parsley, Instaparse, cljcc and
>>> more. Some mentioned on www.clojure-toolbox.com seem to be more
>>> abandonware.
>>> At the moment I'm focusing on Instaparse. However, maybe due to the
>>> previous implementation, I feel that this is not the best approach with
>>> Clojure. Certainly my rookie state is leading me the wrong way.
>>>
>>> Comments and feedback will be greatly appreciated
>>>
>>> Fred
>>>
>>>
>>>
>>>
>>>
>>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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 subscri

Re: beginning to learn Clojure after imperative programming my whole life

[Gary Trakhman]

Hi Andy!

Honestly, there's something very lovable and addictive about working in
Clojure and lisp in general, but I would caution against trying to use it
as a silver bullet, and generalizing it to improving general
'problem-solving' skills might be a bridge too far.

I think what lisp does do is remove the magic behind syntax and make it
easier to learn many other languages, since you're constantly interacting
with exposed compiler wires, as well as foster a bottom-up approach to
program design.

Clojure specifically I think helps problem-solving from a set-theory or
collection processing perspective, which is explained well in 'Out of the
Tar Pit' -
https://github.com/papers-we-love/papers-we-love/blob/master/design/out-of-the-tar-pit.pdf
.
It might help when learning SQL, but not something completely unrelated.
Having worked with data science teams left me feeling like language
bikeshedding just isn't that important to getting stuff done, and it might
be more beneficial to use a simple/common language like java/JS at
team-scale. so it depends on what you're trying to do, who you can convince
to let you do it, and externalities like your company's turnover rate.  I
think I've learned over time that generality is an easy trap. If there's a
thing you want to get better at, the best strategy is to do that thing.  My
2c.

On Wed, Aug 9, 2017 at 2:43 PM Andy  wrote:

> This feels like a different world.
>
> Has anyone experienced a sharp increase in their problem solving abilities
> after switching to Clojure?
> I have been working my way through Living Clojure an Oreilly book.
>
> My curiosity got the better of me and I wondered if anyone here had some
> suggestions for resources/
> particular tips/any advice for improving Clojure skills. Does anybody have
> any websites used for solving
> Clojure problems? other than the most popular ones.
>
> Wishing you the best of luck in life and coding.
>
> best wishes fellow Clojurians,
> Andy
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Gary Trakhman]

@Nathan the top-level (def requirement-seq ..) is probably the thing
holding on to all the objects.  Try removing the def and calling (last
(sequence (comp ..))) and see if it returns?  The purpose of a lazy
sequence is to allow processing to happen one item or chunk at a time, if
there are still problems, then maybe each element is too big, but that
top-level def is definitely a no-no.  I don't think transducers are
relevant here and you'd get the same problem with normal map/remove calls.

On Tue, Aug 8, 2017 at 12:19 PM Nathan Smutz  wrote:

> The one thing I'm aware of holding on to is a filtered file-seq:
> (def the-files (filter #(s/ends-with? (.getName %) ".xml" ) (rest
> (file-seq (io/file dw-path)
> There are 7,000+ files; but I'm assuming the elements there are just
> file-references and shouldn't take much space.
>
> The rest of the process is a transducer sequence:
> (def requirement-seq (sequence
>  (comp
>(map xml-zip-from-file)
>(remove degree-complete?)
>(map student-and-requirements))
>  the-files))
>
> Those functions are admittedly space inefficient (lots of work with
> zippers); but are pure.  What comes out the other end is a sequence of
> Clojure maps.  Could holding on to the file references prevent all that
> processing effluvia from being collected?
>
> The original files add up to 1.3 gigs altogether.  I'd expect the gleaned
> data to be significantly smaller; but I'd better check into how close
> that's getting to the default heap-size.
>
> Best,
> Nathan
>
> On Tuesday, August 8, 2017 at 1:20:21 AM UTC-7, Peter Hull wrote:
>>
>>
>> On Tuesday, 8 August 2017 06:20:56 UTC+1, Nathan Smutz wrote:
>>
>>> Does this message sometimes present because the non-garbage data is
>>> getting too big?
>>>
>> Yes, it's when most of your heap is non-garbage, so the GC has to keep
>> running but doesn't succeed in freeing much memory each time.
>> See
>> https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/memleaks002.html
>> 
>>
>> You can increases the heap but that might only defer the problem.
>>
>> As you process all your files, are you holding on to references to
>> objects that you don't need any more?
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Unnamed Types - What Am I Doing Wrong?

[Gary Trakhman]

Maps with named keys work much better than vectors/lists for heterogenuous
data.  I've recently taken up OCaml as a very well-typed language, and it's
basically analogous to records vs tuples tradeoffs there.

Clojure.spec can help at a larger scale.

You can do the same encapsulation as Java by writing accessors in a
namespace, it sounds to me like you didn't abstract it out early enough.

On Jul 25, 2017 9:52 PM, "Kevin Kleinfelter" 
wrote:

I ran into the 'refactoring an unnamed type' problem.  I'd like to know how
experienced Clojurists avoid it.

I've got an account record/structure.  It has things like an account name,
account number, etc.  I started off storing it in a vector, because it had
just two elements.  Account name was (first v).  Account number was (second
v).  And that worked up to a point.  Over time, it has acquired enough
pieces and rules that I really need to change its implementation.  I need
to refactor it.

When it was only a few hundred lines long, in a couple of files, I could
examine each line.  Now that it's a dozen files and several thousand lines,
I just don't have the attention span.

In a language with named types, I could search for AccountRecord.  I could
thoroughly find all the places I used it and refactor it.  Or I could
change the name of the type to tAccountRecord, and the compiler would
identify all the places where I used it (with error messages).

In an OO language, I'd be accessing all of its pieces via getters and
setters, and I wouldn't have to find all of the places where I used it,
because the implementation would be a black box.

But in a language with unnamed types, it's just a vector and I've just got
first and second and nth to search for.  That's going to find lots of
irrelevant stuff.  It's enough to make me pine for Java and a refactoring
IDE.  =:-o

So how do developers who work with un-typed (or un-named type) languages
avoid this sort of problem?  Or, failing to avoid it, how do they clean up
afterward?
tnx

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group 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: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

[Gary Trakhman]

My mental model explains most of this away due to the different load
patterns of java vs v8.  In JVM clojure, functions are essentially 1:1 with
classes, so in a functional language and standard lib, that's a lot of
classes.  Java will eagerly classload your entire app and deps before doing
any work.  V8 takes an upfront hit on parsing into javascript, but the JS
target fits the structure of clojure itself much more closely.  More time
(not sure how much compared to JVM) will be spent JITing hot code paths,
but that won't show up in the startup cost.

You can get JVM clojure REPL startup a little faster by AOT compiling all
your deps, but it's generally not worth it in a development flow.

I think lumo does some extra tricks to keep this upfront cost down that are
v8-specific:
https://anmonteiro.com/2016/11/the-fastest-clojure-repl-in-the-world/

On Fri, Jul 14, 2017 at 6:20 PM Didier  wrote:

> This link:
> https://dev.clojure.org/display/design/Improving+Clojure+Start+Time says
> that the Java startup time is ~94 ms, while Clojure boot time is ~640 ms.
> That's a ~680% increase.
>
> On my machine the java start time is: ~1042 ms, and the Clojure start time
> is around ~3108 ms. A ~298% increase.
>
> When I time the startup time of lumo against node, I get ~1190 ms for
> node, and ~1523 ms for lumo. A ~128% increase only.
>
> Does Clojure perform more initialization then ClojureScript? And would
> that explain the much higher overhead Clojure has on top of the JVM, versus
> 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.
>

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

[Gary Trakhman]

Is this what you're looking for?


user=> (resolve 'java.lang.String)
java.lang.String

user=> (type (resolve 'java.lang.String))
java.lang.Class


On Mon, Jun 26, 2017 at 1:34 PM Manas Marthi  wrote:

> Hi,
>  I have  a jar files with more than 200 DTO classes. Some have only
> primitive data type values and some have other beans from the same jar.
>  I am trying to traverse through a class hierarchy to find the field
> count. If a class has a mix of some primitive types and other java classes,
> then the total field count is to be computed by looking up the field count
> from those fields.
>
>   I am having a map of  lists. I believe some kind of flat map operation
> should be useful here. But I see a need for recursive travel through
> hierarchy. So not sure how to proceed.
>   So I am first trying to solve it imperatively.
>   However, reflect/reflect does not return Class objects, It is returning
> Symbols. So my below filter function is failing.
>   Pls can you help how to covert symbols into Class objects
>
>
>
> (def  primitive-types #{
> java.lang.Boolean
> java.lang.Character
> java.lang.Byte
> java.lang.Short
> java.lang.Integer
> java.lang.Long
> java.lang.Float
> java.lang.Double
> java.lang.String
>  })
>
> ; using hash-maps as I yet don't know how to mutate maps in clojure
> (def refcounts-map (java.util.HashMap.))
> (def final-ref-counts-map (java.util.HashMap.))
>
>
> (defn all-fields-are-of-primitive-type? [fields-list]
>  (every? #(primitive-types  %) fields-list)
>   )
>
>
> (defn init-ref-counts-from-class-hierarchy
>[types-list] ; A list of class objects
>(when-not (empty? types-list)
>  (let [cur-type (first types-list)
> cur-type-data-fields (->>
>   cur-type
>   (reflect/reflect )
>   (:members)
>   (filter #(instance?
>  clojure.reflect.Field %))
>   (map #(:type %))  ; is not a sequence of Class objects. It is giving Symbols!
>   )
>  ]
>   (if (all-fields-are-of-primitive-type? cur-type-data-fields)
> ;<--- This is always failing!!
>  (.put final-ref-counts-map cur-type (count
> cur-type-data-fields))
>  (.put refcounts-map cur-type [cur-type-data-fields 0])
>  )
>   (recur (rest types-list))
>   )
> )
>)
>
> (defn get-reference-counts
>   [types-list]
>   (do
> (init-ref-counts-from-class-hierarchy types-list)
> ;TODO: initiate recursive travel through
>))
>
> (get-reference-counts (take 2 (vals dto-class-objects)))
> (pp/pprint  refcounts-map)
> (pp/pprint  final-ref-counts-map)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: pmap: transducer & chunking

[Gary Trakhman]

Have you looked into core.async's 'pipeline' function for parallelism?
That was my first question when I saw this post.  I'm not sure why there's
a need for pmap.

On Fri, May 26, 2017 at 12:29 PM Timothy Dean 
wrote:

> You can also get an indication this way, I think:
>
> user=> (defn f [x] (Thread/sleep 100) x)
> #'user/f
> user=> (time (doall (pmap f (range 32
> "Elapsed time: 128.383719 msecs"
> user=> (time (doall (pmap f (range 33
> "Elapsed time: 201.462131 msecs"
> user=> (time (doall (pmap f (range 64
> "Elapsed time: 201.89915 msecs"
> user=> (time (doall (pmap f (range 65
> "Elapsed time: 301.711263 msecs"
> user=> (time (doall (pmap f (range 96
> "Elapsed time: 302.205999 msecs"
> user=> (time (doall (pmap f (range 97
> "Elapsed time: 402.236708 msecs"
>
> Regarding motivation for having a pmap transducer, my own is mainly that
> it composes with other transducers. A major practical/implementation
> "triumph" of transducers may be the reduced garbage, but there is a benefit
> of simplified expression as well, since transducers encode transformation
> in a manner agnostic to many elements of the context of the transformation.
> In a project containing many transducers variously composed and consumed
> throughout, it may be that I wish to parallelize one portion of a
> transformation occurring in the middle of a composition of transducers. If
> so, I can't simply drop in clojure.core's pmap.
>
> Instead I now must -- in the specific context of whatever higher-order
> transducing function I happen to be using -- break the composed transducers
> apart, generate a transitory sequence, pmap over that, and then proceed
> with transforming the temporary sequence. That is, in this case I'm not
> concerned so much with the resource overhead of swapping a transducer for a
> non-transducer, but the expressive overhead. Composition is elegant. My
> solutions with clojure.core's pmap are clunky. I'm not ruling out PEBCAK
> error, but a pmap transducer seems to me the "obvious" solution preserving
> compositional elegance.
>
> For instance, a very simple example using transduce:
>
> (transduce (comp (remove bad)
>
>  ...
>
>  (map transform)
>
>  ...
>
>  (keep pred))
>
>reducer
>
>init coll)
>
>
> must become something like:
>
> (->> coll
>
>  (sequence (comp (remove bad)
>
>  ...))
>
>  (pmap transform)
>
>  (transduce (comp ...
>
>   (keep pred))
>
> reducer
>
> init))
>
> But it could be as simple as:
>
> (transduce (comp (remove bad)
>
>  ...
>
>  (pmap transform)
>
>  ...
>
>  (keep pred))
>
>reducer
>
>init coll)
>
> Does that make sense, or am I crazy? :)
>
> ~Timothy Dean
>
> On Friday, May 26, 2017 at 3:10:15 AM UTC-6, Matching Socks wrote:
>>
>> With the overhead of threading, isn't the triumph of a transducer (no
>> seq allocations) rather subtle in the case of pmap?
>>
>>
>> At any rate!, as a point of interest, since you mentioned a quirk of
>> pmap's thread usage: It apparently has to do with whether the input
>> sequence is a
>> chunked sequence or not.
>>
>> Comparing two possible inputs
>>
>> user> (def c (into [] (range 50))) ;; chunked
>>
>> user> (def n (into '() (range 50))) ;; not chunked
>>
>> With pmap invoking a function that just returns the thread's name (and
>> takes some time, so as to keep its assigned thread busy enough not to
>> accept more tasks right away)
>>
>> user> (defn f [x] (Thread/sleep 22) (.getName (Thread/currentThread)))
>> #'user/f
>> user> (count (distinct (pmap f c)))
>> 32
>> user> (count (distinct (pmap f n)))
>> 7
>>
>> The test is not perfect because it does not show that all 32
>> threads were used *at once*. There were simply 32 distinct threads used
>> at one
>> point or another.  Nonetheless the difference between 7 and 32 is
>> suggestive.
>>
>> In this environment there are 4 "processors", so 32 is indeed more than
>> you might want.
>>
>> The docstring about pmap could be clearer about this.
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Beginner: let with Java object

[Gary Trakhman]

There shouldn't be a difference, I would suspect a typo in your file.

The error 'ClassCastException java.awt.image.BufferedImage cannot be cast to
clojure.lang.IFn  tutorial.core/-main (core.clj:11)' would lead me to look
for things like '(img)' where the object ends up in call position of the
s-expression.

On Fri, May 26, 2017 at 11:54 AM Christopher Howard <
christopher.how...@qlfiles.net> wrote:

> When I run
>
> tutorial.core> (let [img (new-image 32 32)] (set-pixel img 10 10 cyan)
> (show img))
>
> from the REPL, this returns a javax.swing.JFrame object, and displays
> the frame and image as expected. However, if put the same in
>
> (defn -main
>   "Generates image."
>   [& args]
>   (let [img (new-image 32 32)]
> (set-pixel img 10 10 cyan)
> (show img)))
>
> in more core.clj, and run (-main) from the REPL, I get error
>
> ClassCastException java.awt.image.BufferedImage cannot be cast to
> clojure.lang.IFn  tutorial.core/-main (core.clj:11)
>
> Why the difference?
>
> --
> https://qlfiles.net
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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 resume tips?

[Gary Trakhman]

I'd put examples of interesting (hard, nontrivial) projects you worked on
during your time, not just keywords.  The function of the resume is to
motivate someone to look deeper instead of throwing it out.  The function
of the top of the resume is to hook someone to read the rest of it.  What's
special about you?  You can pack a lot into a single page, I think yours
has a lot of whitespace.  Does your school have a resume workshop or
something like that?

On Thu, Mar 23, 2017 at 1:10 PM Jason Basanese 
wrote:

> Attached is a fairly bad resume that I am using. Any tips on how I might
> change it to appeal to more places that are looking for functional
> developers?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Handling dependency conflicts

[Gary Trakhman]

MrAnderson is one possible answer to the question, it's used in CIDER:
https://github.com/benedekfazekas/mranderson

On Mon, Mar 13, 2017 at 4:13 PM  wrote:

> Hello All,
>
>
>  I have a general inquiry regarding conflicting dependencies in
> Clojure projects and how they affect applications at runtime. I believe
> this is a common problem faced by many languages in this day and age where
> we try not to reinvent the wheel by depending on the work of others.
> Basically: my application depends on libraries *A*, *B*, *C*, and *D*.
> Libraries *B*, *C*, *D* *also* depend on library *A*, but all of us
> depend on *different versions* of library *A.* Leiningen thankfully warns
> us in many of these situations by suggesting exclusions. However, how can I
> possibly know that something hasn't broken? Stringent testing can give a
> certain degree of confidence that things are still working, but it would
> seem to me that to ensure correctness, we should include *all* versions
> of the dependencies and have the functions link to their respective
> *versioned* identites. Does anyone have advice on how they solve these
> kinds of problems on their codebases in the wild? Thankfully nothing has
> broken yet (to my knowledge), but it seems we have very few assurances here
> and the best we can do is *hope* nothing is broken. Any advice is much
> appreciated.
>
> Thanks,
>
> Arthur
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: why doesn't java.lang.ArithmeticException have Exception as a parent?

[Gary Trakhman]

Turns out ancestors works on the class, not the instance:
> (ancestors ArithmeticException)
#{java.lang.Throwable java.io.Serializable java.lang.Exception
java.lang.RuntimeException java.lang.Object}

> (ancestors (new ArithmeticException))
nil


On Tue, Mar 7, 2017 at 7:05 PM  wrote:

> This gives me nil:
>
> (try (/ 4 0) (catch Exception e (println (parents e
>
> This too:
>
> (try (/ 4 0) (catch Exception e (println (ancestors e
>
> This too:
>
> (try (/ 4 0) (catch ArithmeticException e (println (ancestors e
>
> How is this possible? Shouldn't Exception be an ancestor?
>
> Or, more generally, shouldn't something be a parent?
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Prgram uses a lot of swap

[Gary Trakhman]

I've had great luck with the G1 garbage collector when running lots of JVMs
on a single (linux) box.  It's different from the default by actually
freeing memory back to the OS on a full collection, this would result in
lower total memory use thus lower swapping when multiple JVMs are running.

The JVM command line parameter is as follows:
-XX:+UseG1GC

When using lein, it needs to be in the project profile and additionally the
LEIN_JVM_OPTS environment variable to cover both JVMs lein spins up
(trampoline notwithstanding).

On Mon, Feb 27, 2017 at 12:35 PM Thomas Heller  wrote:

> ​What is the best way to determine the right value for this? I remember
> that in the past I had a lot of little Java​
>
> ​programs running and got a much better performance by limiting memory
> usage.
>
>
>
> That is not an easy question to answer. If you make it too small your
> process may crash with OutOfMemory errors, if you give it just enough it
> will constantly be running running garbage collections making your program
> slower. So "just right" is very dependent on your program and also on what
> else is happening on the machine running it. You can use tools like
> JVisualVM or Java Mission Control to better understand your system but that
> takes a lot of time and effort.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: How can I re-order rows in a table (hiccup)?

[Gary Trakhman]

Generally it's easier to sort the data before it gets put into hiccup table
formatting. Is there any reason not to?

On Feb 24, 2017 5:41 PM, "John Gabriele"  wrote:

> I'm using hiccup, and I'd like to build a table, but then have the option
> to re-order it (sort its rows by a column of my choosing). I want a
> `sort-table-by` function.
>
> That is, if I've got
>
>
> Color   Size
> --  
> red 2
> green   7
> blue4
>
>
> (or, as a data structure: `(def tbl [:table [:tr [:th "Color"] [:th
> "Size"]] [:tr [:td "red"] [:td 2]] [:tr [:td "green"] [:td 7]] [:tr [:td
> "blue"] [:td 4]]])`)
>
> I'd like to be able to do `(sort-table-by tbl 0)` and get
>
>
> Color   Size
> --  
> blue4
> green   7
> red 2
>
>
> or `(sort-table-by tbl 1)` and get
>
>
> Color   Size
> --  
> red 2
> blue4
> green   7
>
>
> Where it gets tricky though is when your table has various attribute maps
> in it, and also when some of the values you're sorting on may be links.
>
> A first try at a solution yields ... oh man, {sigh, deep breath} this,
> which doesn't work:
> .
>
> Thanks!
> -- John
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Gary Trakhman]

Thank you so much for getting around to ASYNC-138+32, it was a usability
issue between idiomatic clojure code and async code, would show up almost
immediately in new projects, the workaround raised questions during
code-reviews, etc.

On Wed, Feb 22, 2017 at 1:47 PM Alex Miller  wrote:

> core.async 0.3.426 is now available.
>
> Try it via:  [org.clojure/core.async "0.3.426"]
>
> 0.3.426 includes the following changes:
>
>- ASYNC-169  - handling
>of catch and finally inside go blocks was broken, causing a number of 
> issues
>   - Related: ASYNC-100 
>   , ASYNC-173 ,
>   ASYNC-180 , ASYNC-179
>   , ASYNC-122
>   , ASYNC-78
>   , ASYNC-168
>   
>- ASYNC-138  - go blocks
>do not allow closed over locals to be cleared which can lead to a memory
>leak
>   - Related: ASYNC-32 
>- ASYNC-155  - preserve
>loop binding metadata when inside a go block
>- ASYNC-54  - fix bad
>type hint on MAX-QUEUE-SIZE
>- ASYNC-177  - fix
>docstring typo in Buffer protocol full? method
>- ASYNC-70  - docstring
>change in thread, thread-call
>- ASYNC-143  - assert
>that fixed buffers must have size > 0
>- Update tools.analyzer.jvm dependency
>
>
> Many thanks to Kevin Downey and Nicola Mometto for their help on the go
> block issues.
>
> Additionally, I've done some work to make the core.async build less weird
> and to match all the other contrib projects (other than how the version is
> computed). This will make core.async easier to use and manage for
> development and CI and also lets us use our automated CI matrix test setup
> to give us more coverage going forward.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Apparently nondeterministic compilation failure

[Gary Trakhman]

I've seen non-determinism across machines with regard to multiple
namespaces being searched to AOT with the clojure-maven plugin (only
noticed because it resulted in an error). The workaround was to specify a
single entry point namespace to clojure-maven and let the clojure compiler
sort out namespace dependency order.

On Jan 23, 2017 6:24 PM, "'William Parker' via Clojure" <
clojure@googlegroups.com> wrote:

> Clojure 1.8 both before and after; I should have put that in my original
> post.  As far as I'm aware there were no changes of any kind in the
> environment or code between the failing state and the successful one,
> although since I don't control our CI environment it is possible there were
> environmental changes I'm not aware of (it is a large enterprise
> environment with many different teams potentially making changes).
> Unfortunately I've been unable to change anything such as JVM versions in
> my local environment to get the code to compile but I'll post back here if
> I find some such method.  Without the ability to duplicate the difference
> there probably isn't much debugging that can be done but I was curious if
> there are known issues that could lead to such problems.
>
> On Monday, January 23, 2017 at 4:19:44 PM UTC-6, Alex Miller wrote:
>>
>> Most helpful would be to know what Clojure version you are on now and
>> what changed between when it didn't fail and when it did.
>>
>> There have been a variety of changes to both type hints and classloading
>> over the last few releases and it's likely that the error is now simply
>> found when it was silently not found and ignored before.
>>
>> On Monday, January 23, 2017 at 3:01:38 PM UTC-6, William Parker wrote:
>>>
>>> I have a case where JVM Clojure code like (some-> ^JavaClassA this
>>> ^FieldTypeA (.getFieldTypeA) (.getFieldTypeB)) previously compiled for a
>>> long time and suddenly just started failing in our CI system because the
>>> class FieldTypeA wasn’t imported in the namespace.  I understand the need
>>> to import the class but I don’t see why it ever compiled and am wondering
>>> if there is any known nondeterminism here.  I looked through the Clojure
>>> JIRA tracker but didn't find anything that seemed related.
>>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: maven-shade-plugin issues with Clojure core (or any clj) AOT compilation

[Gary Trakhman]

My workaround in a multi-module maven shaded java project with a clojure
module was to strip out CLJ files in the top-level build (shipped with
clojure.core jar).

I had also stripped CLJ files from my project artifact, but AOT compiles
classfiles from all referenced namespaces, so I attempted to strip those
out too earlier with the maven jar plugin. This necessitated manually
whitelisting AOT'd protocol classes from some of those 3rd party deps to
resolve further classloader issues.

On Wed, Dec 28, 2016 at 8:06 AM Mike Rodriguez  wrote:

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

Re: Errors

[Gary Trakhman]

I think it has been rehashed often and core is very conservative about
changes, but the current latest and greatest for improving many kinds of
errors is going to be clojure.spec, which runs parallel to the actual
execution path, so as not to effect things like performance or old code
that depends on the specific weird behaviors in core.
http://clojure.org/guides/spec

On Mon, Dec 5, 2016 at 8:28 PM  wrote:

> Hi!
>
> Boy I really think you've all done a nice job with Clojure. I've used
> quite a few environments over the years and clojure + CIDER + etc is a
> great experience. The immutability and threading are smart. I've been able
> to finish a hobby project in clojure which I've been mulling for a long
> time and never found the right environment. Super stuff.
>
> And the error messages are not good.
>
> So I was wondering: Is this a philosophical thing? Or is it an effort
> thing? And if it is an effort thing, is there some sort of plan for what
> effort to put in? And if so, can I help by closing tickets?
>
> Here's one, for instance, which bugs me (using a build of branch master in
> clojure from github just now)
>
> user=> (+ 1 1)
>
> 2
>
> user=> (1 + 1)
>
> ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn
> user/eval17 (NO_SOURCE_FILE:10)
>
>
>
>
> OK but what sort of noob would actually type in 1 + 1? (That's a joke.
> Lots of people would. And I do sometimes when switching between java and
> clojure) But that same error pops up if you misalign in parenthesis or
> confuse an argument order or do a variety of other things.
>
> And that error message is terrible. I mean I know why it is there. Clojure
> needs the first element of a list be the function position and 1 is not a
> function, it is a long. But you have to squint rather generously at that
> message to get to the problem. Or just learn what that message "really"
> means, which seems a bit unfriendly.
>
> And so when I go look inside the source
>
> user=> (print-stack-trace *e 20)
>
> java.lang.ClassCastException: java.lang.Long cannot be cast to
> clojure.lang.IFn
>
>  at user$eval9.invokeStatic (NO_SOURCE_FILE:6)
>
> user$eval9.invoke (NO_SOURCE_FILE:6)
>
> clojure.lang.Compiler.eval (Compiler.java:6978)
>
> clojure.lang.Compiler.eval (Compiler.java:6941)
>
>
>
> Compiler.java has
>
> IFn fn = (IFn) fexpr.eval();
>
> return fn.invoke();
>
>
> Which of course throws a class cast exception.
>
>
> But there's so much information right there. Imagine this (in pseudo-code)
> as
>
>
> Object f = fexpr.eval();
>
> if (f instanceof IFn) return (IFn)f.invoke()
>
> else throw ClojureNotAFunctionEvaluationError "First position in form at
> line " ... " of environment " ... " is not a function object. You handed me
> " + fexpr.first() " in form " ... " which has type " fexpr.first().class()
> " and value " fexpr.first().toString()
>
>
> or whatever (like maybe don't toString values - that's why you'd want a
> plan. And maybe use a string table so you can internationalize. Again, plan
> :) )
>
>
> so I almost want to whack this sort of stuff into a local copy as I hit
> error messages which bug me, but that seems foolish. And anyway I'm new
> here.
>
>
> Sorry if I have accidentally stepped into some sort of landmine or if this
> has been rehashed a million times.
>
>
> But I figured, in the spirit of being willing to help if there's help to
> be applied, I would ask if there's some sort of thinking on this topic for
> 1.9.1 or 1.10 or something?
>
>
> Thanks
>
>
>   Paul
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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/op

Re: def partial vs let partial

[Gary Trakhman]

Sum-partial-def gets the original + definition because it is evaluated
first, if you want late binding, try (partial reduce (var +)).

On Dec 1, 2016 4:05 PM, "Matthew Hamrick"  wrote:

> I'm confused by the following code.
> Could someone explain to me why the def-ed partial has different behavior
> to the letted one?
> This is especially confusing to me since the #() special form one works as
> I expect.
>
> (def sum-partial-def (partial reduce +))
>
> (let [sum-partial (partial reduce +)
>   sum-# #(reduce + %1)
>   nums [1 2 3 4]]
>   [(sum-partial-def nums)
>(reduce + nums)
>(sum-# nums)
>(sum-partial nums)]) ;; => [10 10 10 10]
>
> (with-redefs [+ (fn [a b]
>   (.add (.add (BigInteger. (str a))
>   (BigInteger. (str b)))
> (BigInteger/ONE)))]
>   (let [sum-partial (partial reduce +)
> sum-# #(reduce + %1)
> nums [1 2 3 4]]
> [(sum-partial-def nums)
>  (reduce + nums)
>  (sum-# nums)
>  (sum-partial nums)])) ;; => [10 13 13 13]
>
> Thanks,
> Matt
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Design pattern question: how to decouple data layer from application layer in Luminus service?

[Gary Trakhman]

It's dirty and not thread-safe, but you can always replace any clojure
function (caveat: that's not direct-linked (only clojure.core 1.8+))
temporarily during testing with with-redefs.

Instead of mocking out the functions, you might consider mocking out the
database, or the data inside the database instead.  There are projects to
do so: https://github.com/yandex-qatools/postgresql-embedded .

On Fri, Nov 18, 2016 at 12:17 PM Travis Daudelin 
wrote:

> Hello everyone!
>
> I am investigating Clojure and, more specifically, Luminus
> , for a new service my organization will be
> building soon. My team and I are really excited by the prospect of trying
> out something new.
>
> There is a lot that I like about Luminus' design, but I have some concerns
> about its data-layer is implemented. To be clear, what I mean by "data
> layer" is the code that deals with querying a SQL database. As I understand
> it, Luminus uses HugSQL  and Mount
>  to dynamically construct a set of
> functions at run time and injects them into a namespace that the rest of
> the application code can then call to perform DB operations. This is very
> interesting, but I worry that this tightly couples my application code with
> the data code. For example, what if I want to mock these functions in my
> unit tests so that my tests don't need to depend on a database connection,
> or so that I can mock various DB error scenarios to test that my
> application code handles them appropriately?
>
> Coming from a Java background, I would normally place data layer code
> behind an interface and then at run time pass an implementation of that
> interface to my application code. This allows me a lot of freedom during
> unit testing. What would an equivalent design pattern be in Luminus?
>
> Thanks in advance for any insights!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: comp and partial vs ->>

[Gary Trakhman]

Comp does its work at run-time, so you have to call functions that return
functions.  Threading macros do their work at compile-time, so your form
literally compiles to this:


> (clojure.walk/macroexpand-all '(->> (str/split s #"(?<=[a-z])(?=[A-Z])")
   (map str/lower-case)
   (interpose \-)
   str/join
   keyword))
(keyword
  (str/join
(interpose \-
  (map str/lower-case
(str/split s #"(?<=[a-z])(?=[A-Z])")


On Thu, Oct 27, 2016 at 10:56 AM JHacks  wrote:

> I have some confusion about how the function `comp` works, especially as
> compared to the threading macro `->>`.
>
> From the book *Clojure Programming* (pages 70-71 of Chapter 2: Functional
> Programming), the following two functions are described as functionally
> equivalent:
>
> (def camel->keyword
>   (comp keyword
> str/join
> (partial interpose \-)
> (partial map str/lower-case)
> #(str/split % #"(?<=[a-z])(?=[A-Z])")))
>
> (defn camel->keyword*
>   [s]
>   (->> (str/split s #"(?<=[a-z])(?=[A-Z])")
>(map str/lower-case)
>(interpose \-)
>str/join
>keyword))
>
> Why does the first function, `camel->keyword`, need to use `partial` with
> the
> `map` and `interpose` functions? The second function, `camel->keyword*`,
> does
> not need to use `partial`.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Possible ClojureScript compiler issue...

[Gary Trakhman]

Just a quick glance makes it look like handlers can be overridden, but I
haven't tried this and I don't think it's documented anywhere:
https://github.com/cognitect/transit-cljs/blob/master/src/cognitect/transit.cljs#L109

On Tue, Oct 18, 2016 at 11:41 AM John Szakmeister 
wrote:

> Yes, you could do that, but it could also do Bad Things.  Namely if
> you have strings that match some of the format, it could be
> misinterpreted as Transit data rather than JSON, so I don't consider
> it a particularly useful solution either.  It just moves where the
> problem can happen. :-(  If there was a way to so "ignore the transit
> extensions", that would change things though.
>
> -John
>
> On Tue, Oct 18, 2016 at 7:36 AM, Gary Trakhman 
> wrote:
> > If you're parsing raw json streams/strings, I think transit claims to be
> a
> > 30x perf improvement over js/JSON.parse+js->clj:
> > http://swannodette.github.io/2014/07/26/transit-clojurescript
> >
> > On Tue, Oct 18, 2016 at 6:41 AM Matching Socks 
> wrote:
> >>
> >> A reliable "implements?" would be better than a fast-and-sometimes-wrong
> >> "implements?".
> >>
> >> With that in mind, have you tried a distinct sentinel object, as opposed
> >> to true?
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> ---
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to clojure+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group 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: Possible ClojureScript compiler issue...

[Gary Trakhman]

If you're parsing raw json streams/strings, I think transit claims to be a
30x perf improvement over js/JSON.parse+js->clj:
http://swannodette.github.io/2014/07/26/transit-clojurescript

On Tue, Oct 18, 2016 at 6:41 AM Matching Socks  wrote:

> A reliable "implements?" would be better than a fast-and-sometimes-wrong
> "implements?".
>
> With that in mind, have you tried a distinct sentinel object, as opposed
> to true?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Gary Trakhman]

It's possible to do a mixed AOT (your code) non-aot (third-party code)
setup, but it's a huge pain.

The particular issue you're seeing is probably the result of multiple
versions of a class existing across jars and classloaders.  Unfortunately
there is no consistent way to get this right, but the solution would
involve a lot of manual inspection and stripping classes with filters like
the maven jar plugin's 'exclude' functionality.  There are some libraries
that are more troublesome than others.  In particular, any AOT'd 1st-party
code that references protocols from 3rd party code will break if those
classes are compiled dynamically, forcing you to include them, so I think
your multi-module AOT setup is likely to break hard in this case unless the
modules don't share dependencies.

One of the other big sources of problems occurs when there is mixed source
and AOT classes, as with the clojure artifact jar itself.  Uberjarring
would be sensitive to timestamps, the clj source should be older than the
compiled class files.  This is specifically a problem with the
maven-shade-plugin and I experienced it on a mixed-java/clojure project.

In short, it's probably more trouble than it's worth to split the build
into module jars only to combine them again.  If I were to do the
shared-AOT-library consumed by clojure code scenario over again, I'd
include the shared source into the build system of the consuming project,
instead of including the jar artifact.

On Wed, Oct 12, 2016 at 4:26 PM Stuart Halloway 
wrote:

> Hi Piotr,
>
> Yes, the limitation is how the Java classpath works.  If you AOT your app,
> you need to AOT compile other Clojure code your app uses.
>
> See e.g.
> http://dev.clojure.org/jira/browse/CLJ-1544?focusedCommentId=43558&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-43558
>
> Cheers,
> Stu
>
> On Wed, Oct 12, 2016 at 2:22 PM, Piotr Bzdyl  wrote:
>
> Hello,
>
> I am trying to solve an issue in my project where I have the following
> setup. My application modules are AOT-compiled into several jars and then
> packaged with their 3rd party dependencies into an uberjar. As a result my
> uberjar contains my project's namespaces compiled to class files and
> dependencies (in this case clojure.java.jdbc) source clj files.
>
> When I try to start the application it fails with the following
> stacktrace. Is there any limitation that prevents me running AOT-compiled
> namespaces using other namespaces available as clj on classpath?
>
> java.lang.reflect.InvocationTargetException: null
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.8.0_102]
>at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[na:1.8.0_102]
>at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[na:1.8.0_102]
>at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_102]
>at com.example.Launcher$ThreadLauncher.run(Launcher.java:42) ~[na:na]
>at java.lang.Thread.run(Thread.java:745) [na:1.8.0_102]
> Caused by: java.lang.NoClassDefFoundError: clojure/java/jdbc/Connectable
>at com.example.db.common.database__init.load(Unknown Source) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at com.example.db.common.database__init.(Unknown Source) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at java.lang.Class.forName0(Native Method) ~[na:1.8.0_102]
>at java.lang.Class.forName(Class.java:348) ~[na:1.8.0_102]
>at clojure.lang.RT.classForName(RT.java:2154) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RT.classForName(RT.java:2163) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RT.loadClassForName(RT.java:2182) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RT.load(RT.java:436) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RT.load(RT.java:412) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$load$fn__5448.invoke(core.clj:5866) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$load.doInvoke(core.clj:5865) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RestFn.invoke(RestFn.java:408) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$load_one.invoke(core.clj:5671) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$load_lib$fn__5397.invoke(core.clj:5711) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$load_lib.doInvoke(core.clj:5710) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RestFn.applyTo(RestFn.java:142) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$apply.invoke(core.clj:632) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.core$load_libs.doInvoke(core.clj:5749) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clojure.lang.RestFn.applyTo(RestFn.java:137) 
> ~[example-2.5.0-SNAPSHOT-standalone.jar:na]
>at clo

Re: clojure.core/bean throws when passed an empty list

[Gary Trakhman]

This is an existing bug:
http://dev.clojure.org/jira/browse/CLJ-978?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel

It's relatively easy to write a workaround if needed.

On Tue, Oct 4, 2016 at 7:59 AM Divyansh Prakash 
wrote:

> Is this desired behaviour?
>
> user=> (bean [])
> {:class clojure.lang.PersistentVector, :empty true}
>
> user=> (bean {})
> {:class clojure.lang.PersistentArrayMap, :empty true}
>
> user=> (bean ())
> IllegalAccessException Class clojure.core$bean$fn__5975$fn__5976 can not
> access a member of class clojure.lang.PersistentList$EmptyList with
> modifiers "public"  sun.reflect.Reflection.ensureMemberAccess
> (Reflection.java:110)
>
> user=> (bean '(1 2 3))
> {:class clojure.lang.PersistentList, :empty false}
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Why is this not considered to be in a go block?

[Gary Trakhman]

I wouldn't expect it to work in a `for` comprehension, because that's
combining laziness (which uses function thunks under the hood) with the
async state machines.  In general, you shouldn't do side-effects in a
`for`, though I'd be surprised if you couldn't take at the input.

This works

(let [ch (clojure.core.async/to-chan (range 10))
  ch2 (clojure.core.async/chan 2 (partition-all 2))]
  (clojure.core.async/pipe ch ch2)
  (clojure.core.async/ wrote:

> Doesn't work in a FOR loop either. Thank god for LOOP! :)
>
> -kt
>
>
> On Thursday, August 25, 2016 at 7:21:20 PM UTC-4, hiskennyness wrote:
>>
>> I am getting an error about >! not being in a go block with this code:
>>
>>   (go-loop [state :nl
>> column 0
>> last-ws nil
>> buff ""]
>> (let [line-out (fn [c b]
>>  (>! out (apply str b (repeat (- col-width (count
>> b)) \space]
>>   (cond
>> (>= column col-width)
>> (condp = state
>>   :ws (do
>> (line-out \| buff)
>> (recur :nl 0 nil ""))
>>  ..etc etc
>>
>> I just changed the line-out call to just do...
>>
>> (>! out-chan buff)
>>
>> ...and it worked fine.
>>
>> So the failing code is both dynamically and lexically within the scope of
>> the go-loop --- is that supposed to be that way? Or am I completely missing
>> something?
>>
>> -kt
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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

[Gary Trakhman]

Over the years I've kind of started agreeing with what Brian's saying.
Much as I love/know clojure and the philosophy that bears its fruit, I
think spec's sideband error-handling is a great low-risk opportunity to
build in some 'easy'.

My team is moving from rails towards elixir after having seriously
considered clojure (and hiring me recently under that premise), and I'm
having to apologize for the general lack of novice guardrails,
'conventions' and documentation that people from other communities expect.
I think it looks pretty good if you're used to java (java conservatism
notwithstanding), but not so good if you've been in dynlangs (particularly
ruby) or other FP languages besides lisp.

I'm concerned the current approach will lead to too many half-baked
error-reporters.  Alternatively, if there's a canonical human-facing
error-reporter built on top of the more stable data representation, I think
it would be generally acceptable to break 'contracts' there as we find
better ways to show the errors.

On Thu, Aug 25, 2016 at 11:18 AM Brian Marick 
wrote:

>
> On Aug 24, 2016, at 9:28 PM, adrian.med...@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 documentation and error handling.
> In the meantime, the Clojure ideology - reinforced by memes like
> “complecting” - has been getting more rigid.
>
> The result is that what seem to me bizarre decisions are treated as
> normal. We have an `any?` in clojure.core that always returns `true`. This
> deviance from probably every other programming language is justified as
> obvious for a feature - clojure.spec - that is largely unproven, certainly
> when it comes to error reporting. (Even worse, we have `any?`, `some?`, and
> `some` - all idiosyncratic.) Yet the idea of changing the name of `any?` is
> completely dismissed, with the justification that people complain about
> every new name. (Think about what that decision criterion entails, broadly
> applied.)
>
> Also bizarre: the idea that error messages that amount to essentially
> dumping a parse tree + BNF-ish grammar clause (possibly twice with a
> vomitous stack trace between) is a *good* thing. Not a “we wish we could do
> better, but software development is about constraints and tradeoffs” thing.
> Not a “yeah, but Rich Hickey doesn’t want to bother with that stuff” thing.
>
> (I was honestly flummoxed that, although clojure.spec is supposed to be
> the answer for error handling, there’s been no attempt to work through what
> good error messages would be like and how the current infrastructure would
> support the translation from raw data to such error messages.)
>
> I cannot help but think of this as groupthink. And - to be grandiose -
> having people like me Exit will increase that, per evaporative cooling.
>
>
> I also note that my library, Midje, is typically insulted on this mailing
> list whenever a newbie brings it up. One of the contributors to this thread
> has called it “an abomination”. There was no simila

Re: ref strange behavior

[Gary Trakhman]

On Tue, Aug 23, 2016 at 10:59 AM Sergei Koledov  wrote:

> Thank you! I know about Java's thread pools, but I want to do my job in
> clojure-idiomatic way and possibly less using java interop.
>
>
I think many of the use-cases for refs/agents are supplanted by
core.async.  In this case, the 'pipeline' family of functions can be used
much like an executor pool.

I'm not sure how idiomatic STM can be, when I've rarely used it.  I think
in most cases where you'd want to coordinate multiple refs within a
transaction, a single atom is going to be much simpler and performant
enough.

I think clojure uses the 'toolkit' approach, in that it allows many things
to be combined and encourages composition, but it doesn't prescribe or
force you towards any particular shape of solution.  That's a natural
consequence of 'design by decoupling'.

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

[Gary Trakhman]

zipmap-with-merge sounds a lot like merge-with, you might want to check
that out. It's also perfectly acceptable to call merge-with with a sequence
of one-entry maps, that gives you what you were suggesting.

On Fri, Jul 29, 2016 at 3:15 PM Daniel Dinnyes  wrote:

> Wow, thanks for that, actually that looks pretty cool. I haven't thought
> about that. Are there any drawbacks / cons of doing that?
>
> I was actually wrong about distinct, it seems it doesn't change the order,
> but I am not sure it happens by accident, or it is an intended behavior. It
> seems to keep the order of the first appearance of the each element in the
> seq:
>
> (distinct [1 2 3 4 4 3 2 1 0 0])
> >(1 2 3 4 0)
>
> Another idea which came to mind: if zipmap would take an extra optional
> argument called merge (which takes a function), it could be reflected in
> the docstring as well, it would be quite good in itself to raise awareness
> of the possibility of having keys appearing multiple times in the input
> sequence, while also giving some extra features and use-cases. like someone
> could just add a function to merge which just throws an exception or logs a
> warning with my logging library of choice, or conjoin the values in a list
> or set, etc.
>
>
>
> On Friday, 29 July 2016 17:56:20 UTC+1, Gary Trakhman wrote:
>
>> Distinct on the input values wouldn't solve your problems, as the entries
>> are indeed distinct even with repeated keys.  Calling 'distinct' on the
>> input keys is about the same cost as building up a map, since it internally
>> uses a set that is backed by a map ;-), but you seem to be more concerned
>> about the order of overriding, expecting the first value to when, when the
>> behavior of zipmap and things like 'into' is 'as if by repeated conj', in
>> other words, last wins.  If you are concerned about keys overriding, there
>> is an alternative with map literals and 'apply hash-map', so you can do
>> your zipping without zipmap, then apply it to a hash-map call.
>>
>> > (hash-map :a 1 :a 2)
>> java.lang.IllegalArgumentException: Duplicate key: :a
>>
>> > (defn my-zipmap [s1 s2] (apply hash-map (interleave s1 s2)))
>> #'sandbox10223/my-zipmap
>> > (my-zipmap [:a :b :c] (range))
>> {:a 0, :c 2, :b 1}
>> > (my-zipmap [:a :b :a] (range))
>> java.lang.IllegalArgumentException: Duplicate key: :a
>>
>>
>>
>> On Fri, Jul 29, 2016 at 12:33 PM Daniel Dinnyes 
>> wrote:
>>
> Actually, on second thought:
>>>
>>> Doing a distinct on the input values is definitely not acceptable, both
>>> for performance, and for behavior as it potentially changes the order of
>>> the pairing of elements.
>>>
>>> OTOH, in real life zipmap would be rarely used with the intention to
>>> define the same key multiple times. It would be definitely a human-friendly
>>> addition to log some warning when a key is to be defined multiple times,
>>> especially if it can avoid impact on performance.
>>>
>>> Cheers,
>>> D.
>>>
>>>
>>> On Friday, 29 July 2016 17:07:14 UTC+1, Daniel Dinnyes wrote:
>>>>
>>>> Hi All,
>>>>
>>>> This post is just to mention my recent experience with one of the
>>>> clojure.core/zipmap, by witch I was burned badly recently. Consider the
>>>> following example code
>>>>
>>>> (def ks [:a :b :c :d :e :f :b :c :d])
>>>>
>>>> (def m (zipmap ks (range)))
>>>>
>>>> (get m :b)
>>>>
>>>> > 6
>>>>
>>>> Of course the "ks" in my case was like 100-and-something names, which I
>>>> didn't notice got concatenated twice by accident. Alright I accept, it was
>>>> a ridiculously stupid mistake, but finding out what went wrong was
>>>> definitely not straightforward (kind of questioning your sanity feeling)...
>>>> I had to grab a friend for some "second pair of eyes" and her immediate
>>>> reaction was "(= (count (distinct ks)) (count ks))", and said there you go.
>>>>
>>>> Not sure if there is anything which could be improved on the docstring,
>>>> or the behavior. Maybe if the docstring has put a tiny bit more emphasis on
>>>> the implementation details: that it's going to be a reduce over the
>>>> key-value pairs into an empty map, that would have triggered the "aha"
>>>> moment for me.
>>>>
>>>> Anyways, I am n

Re: zipmap behaviour

[Gary Trakhman]

Distinct on the input values wouldn't solve your problems, as the entries
are indeed distinct even with repeated keys.  Calling 'distinct' on the
input keys is about the same cost as building up a map, since it internally
uses a set that is backed by a map ;-), but you seem to be more concerned
about the order of overriding, expecting the first value to when, when the
behavior of zipmap and things like 'into' is 'as if by repeated conj', in
other words, last wins.  If you are concerned about keys overriding, there
is an alternative with map literals and 'apply hash-map', so you can do
your zipping without zipmap, then apply it to a hash-map call.

> (hash-map :a 1 :a 2)
java.lang.IllegalArgumentException: Duplicate key: :a

> (defn my-zipmap [s1 s2] (apply hash-map (interleave s1 s2)))
#'sandbox10223/my-zipmap
> (my-zipmap [:a :b :c] (range))
{:a 0, :c 2, :b 1}
> (my-zipmap [:a :b :a] (range))
java.lang.IllegalArgumentException: Duplicate key: :a



On Fri, Jul 29, 2016 at 12:33 PM Daniel Dinnyes  wrote:

> Actually, on second thought:
>
> Doing a distinct on the input values is definitely not acceptable, both
> for performance, and for behavior as it potentially changes the order of
> the pairing of elements.
>
> OTOH, in real life zipmap would be rarely used with the intention to
> define the same key multiple times. It would be definitely a human-friendly
> addition to log some warning when a key is to be defined multiple times,
> especially if it can avoid impact on performance.
>
> Cheers,
> D.
>
>
> On Friday, 29 July 2016 17:07:14 UTC+1, Daniel Dinnyes wrote:
>>
>> Hi All,
>>
>> This post is just to mention my recent experience with one of the
>> clojure.core/zipmap, by witch I was burned badly recently. Consider the
>> following example code
>>
>> (def ks [:a :b :c :d :e :f :b :c :d])
>>
>> (def m (zipmap ks (range)))
>>
>> (get m :b)
>>
>> > 6
>>
>> Of course the "ks" in my case was like 100-and-something names, which I
>> didn't notice got concatenated twice by accident. Alright I accept, it was
>> a ridiculously stupid mistake, but finding out what went wrong was
>> definitely not straightforward (kind of questioning your sanity feeling)...
>> I had to grab a friend for some "second pair of eyes" and her immediate
>> reaction was "(= (count (distinct ks)) (count ks))", and said there you go.
>>
>> Not sure if there is anything which could be improved on the docstring,
>> or the behavior. Maybe if the docstring has put a tiny bit more emphasis on
>> the implementation details: that it's going to be a reduce over the
>> key-value pairs into an empty map, that would have triggered the "aha"
>> moment for me.
>>
>> Anyways, I am not claiming there is something to be improved / changed
>> here, especially without affecting performance. This is just "for the
>> record" / "future reference".
>>
>> Cheers,
>>
>> D.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Gary Trakhman]

Boot  and inlein
 are both more suitable for one-off scripts.

On Thu, Jul 14, 2016 at 5:16 PM Cecil Westerhof 
wrote:

> In my project I have some functions I use when calling ‘lein repl’ in the
> project directory. Would it be possible to use just that function? So use
> lein to call this function and return?
>
> Maybe not very useful because of the time it takes to start the JVM, but I
> like to experiment. ;-)
>
> --
> 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: lein repl and own functions

[Gary Trakhman]

One way to abuse lein repl, which may get you what you want for a loose
'lein repl' but is sure to cause some problem down the line is to add a
project.clj in your home directory. When you call `lein repl` it'll recurse
from current working directory through parent dirs until it finds a
project.clj, which will be your root project unless you're in another
clojure project.  I have found this to sometimes lead to surprising
behavior, and no longer do it.

On Thu, Jul 14, 2016 at 2:13 PM Cecil Westerhof 
wrote:

> 2016-07-14 20:06 GMT+02:00 Timothy Baldridge :
>
>> There probably is, since the user.clj file can exist anywhere on the
>> classpath. So it should be possible to add an entry to profile.clj and add
>> a classpath folder to some global location.
>>
>> However, I'm not sure I would recommend this approach. IMO, it's better
>> to keep all the development tools for a project with the project itself.
>> With a local user.clj you can check that into git and have it the next time
>> you share/re-download the project
>> ​.
>>
>
> ​It is more for when I am doing lein repl, not for projects. I could make
> a dummy project and always do lein repl there, but I find that a bit of a
> bother. I will look into it.
>
>> ​
>>
>> On Thu, Jul 14, 2016 at 11:50 AM, Cecil Westerhof > > wrote:
>>
>>>
>>> 2016-07-14 18:18 GMT+02:00 Timothy Baldridge :
>>>
 Anything found in src/user.clj will be automatically loaded when lein
 repl starts.

>>>
>>> ​That works only for that directory. With my Bash script the functions
>>> where always included. Is there no way to do it always?​
>>>
>>>
>>>
 On Thu, Jul 14, 2016 at 7:52 AM, Cecil Westerhof <
 cldwester...@gmail.com> wrote:

> When I first worked with Clojure I used a Bash script with had:
> rlwrap java -cp "${CP}" clojure.main --init "${CLOJURE_INIT}"
> --repl
>
> In this way I had several of my own functions in the REPL. Now I
> started again with Clojure I understood I should use ‘lein repl’. Is there
> a method to get my own functions also included when using ‘lein repl’?
>

> --
> 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] Nightcode 2: Total Rewrite

[Gary Trakhman]

Pretty cool!

On Ubuntu, I was unable to run the jar, it couldn't find the main
sekao...core class, although on inspection it was there just fine.

I was able to run it from a git checkout with `boot run`, however I
additionally found out I needed to `sudo apt-get install openjfx`

On Wed, Jul 13, 2016 at 2:16 PM Boris Kourtoukov 
wrote:

> Looks awesome so far Zach! Thanks for going through this monumental
> rewrite!
>
>
> On Wednesday, July 13, 2016 at 1:58:05 PM UTC-4, Zach Oakes wrote:
>>
>> TL;DR: Nightcode, a Clojure IDE, just got a makeover:
>> https://sekao.net/nightcode/
>>
>> In a world...where developer tools are gargantuan beasts, unapproachable
>> to beginners, one IDE stood alone.
>>
>> *a fiddle softly plays ashokan farewell*
>>
>> “You’re not going already, are you, Nightcode?”
>>
>> “I must, father. So many new people are learning Clojure. They need me.”
>>
>> *music becomes ominous as Nightcode rides a wagon into the distance*
>>
>> Until one day, when it embarked on a journey to save the world...from
>> itself.
>>
>> *scene switches to Nightcode crouching in a fetal position in a dense
>> forest*
>>
>> “I’m hearing voices.”
>>
>> *heavy breathing*
>>
>> “STOP TALKING TO ME!”
>>
>> *one of those jumanji drums starts beating slowly and then gets faster
>> and louder*
>>
>> *the camera zooms in on Nightcode’s face as it suddenly smiles wryly*
>>
>> Things are about to get...complicated.
>>
>> *scene changes, a crowd gathers in a small village*
>>
>> “Gather ‘round! I’m making it easy to start coding!”
>>
>> “But Nightcode, those appear to be bugs!”
>>
>> “Wrong, ma’am, they are features! All of them!”
>>
>> “SILENCE!”
>>
>> *the crowd becomes mute as a hooded figure moves forward*
>>
>> “Enough of this madness, Nightcode. In three years your features have
>> remained dormant as your bug count has exploded! Meanwhile, people have
>> been using --”
>>
>> “Don’t listen to this fraud, you all need me”
>>
>> *Nightcode lifts its trench coat and releases a plague of bugs on the
>> village as it runs away*
>>
>> “I don’t want to crash but I will if I have to. I don’t want to crash but
>> I will if I have to. I don’t want to crash but I will if I have to. STOP
>> THE VOICES, MAKE IT STOP!”
>>
>> When your life is no longer your own...
>>
>> *screen dims, Nightcode runs into a forest as the village is ravaged*
>>
>> ...a hero must rise.
>>
>> *the hooded figure reveals himself*
>>
>> Meet...Kevin.
>>
>> *Kevin Hart smiles as upbeat music blares*
>>
>> “HEY Y’ALL THAT WAS CRAZY! I guess it’s a bad time to ask for a
>> better hotel. HAHA!”
>>
>> Kevin is just an average guy, with a few...friends.
>>
>> *the camera pans several feet up to reveal...Ice Cube and Dwayne Johnson*
>>
>> “This is gonna be bad, Cube.”
>>
>> “I know, man. How did we get stuck with this guy again?”
>>
>> A brave trio must save the world from Nightcode...by reinventing it.
>>
>> “Check it. Nightcode can’t be killed. We gotta find the good inside it
>> and rip it out!”
>>
>> “YEAH CUBE I AGREE. JUST LIKE YOU DID WITH YOUR CAREER!”
>>
>> *Cube slaps Hart and continues*
>>
>> “There’s only one way to do that. We gotta rewrite Nightcode.”
>>
>> “You mean like a sequel? Like we keep doing with Fast and the Furious? No
>> way.”
>>
>> “YEAH CUBE, JOEL SPOLSKY SAID YOU SHOULD NEVER --”
>>
>> “Dammit I KNOW what Joel Spolsky said, and I don’t care. You guys got any
>> better ideas?”
>>
>> *Hart and Johnson look at each other sheepishly*
>>
>> *scene switches to a workshop with maps and shit*
>>
>> “Nightcode is written with Swing, a deprecated UI framework. We’re gonna
>> replace it with Java FX. What do you got Rock?”
>>
>> “The editor. Right now it doesn’t offer much beyond syntax highlighting.
>> We’re gonna have to write something from scratch.”
>>
>> “AWW HELL YEAH, GONNA BE LIKE LIGHT TABLE HAD A BABY WITH CURSIVE,
>> HAHAA!”
>>
>> “What? No. Relax Kev. An instaREPL and some basic inline errors, that’s
>> all we have time for.”
>>
>> The trio will learn…
>>
>> *Hart looks in a mirror*
>>
>> “Oh hey Nightcode, what’s up? CAN YOU DEAL WITH THESE RAINBOW PARENS?!
>> Didn’t think so.”
>>
>> ...what it’s like…
>>
>> *Cube emerges from the workshop covered in oil*
>>
>> “We shrunk the damn jar file from 50 MB to just 19!”
>>
>> ...to overcome odds.
>>
>> “The new version has just 1600 lines of code, less than half what the old
>> one has. We may actually pull this off.”
>>
>> This summer, get ready…
>>
>> “WATCH ME MOVE. WATCH ME MOVE. WATCH ME -- hey man take it easy put that
>> down be cool.”
>>
>> ...for the rewrite…
>>
>> “I’m sick of these motherfuckin’ bugs, on this motherfuckin’ IDE!”
>>
>> ...of your life.
>>
>> “We’re gonna get this done or die tryin’. And Kevin IF YOU DON’T STOP
>> DANCING YOU’LL DIE NO MATTER WHAT.”
>>
>> *a door opens as the trio argue, music stops, and Nightcode’s silhouette
>> appears*
>>
>> “Game over, gents. How can you replace me? Beginners don’t know how to
>> run jar files.”
>>
>> “We built

Re: [ANN] Tufte, simple profiling and performance monitoring for Clojure/Script

[Gary Trakhman]

Wonderful, used it today on some core.async code.  It helped me tune
GC/buffer-sizes/parallelism and the metrics are a useful communication tool
across a team that's less familliar with clojure.

On Mon, Jul 11, 2016 at 9:45 AM Peter Taoussanis 
wrote:

> On Clojars, and GitHub at: https://github.com/ptaoussanis/tufte
>
>
> Basically took the weekend to clean up Timbre's old profiling ns,
> generalize it, and move it to its own lib. Biggest difference for most
> folks will probably be the new documentation.
>
>
> Enjoy, cheers! :-)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: lazy-cat's memoization obscuring runtime exceptions

[Gary Trakhman]

Ah, sorry I missed that the first time around.

There's something similar going on with lazy-seq.

user=> (defn the-seq
  #_=>   ([] (the-seq 2))
  #_=>   ([a] (cons (* a a) (lazy-seq (the-seq (* a a))

user=> (def s (the-seq))
#'user/s
user=> (take 100 s)

ArithmeticException integer overflow  clojure.lang.Numbers.throwIntOverflow
(Numbers.java:1501)
user=> (take 100 s)
NullPointerException   clojure.lang.Numbers.ops (Numbers.java:1013)

I think in practice, you stop passing around the seq after the first
exception, you're encouraged not to hold on to heads of seqs, so this
shouldn't get triggered.

On Mon, Jun 13, 2016 at 4:54 PM Sebastian Oberhoff <
oberhoff.sebast...@gmail.com> wrote:

> What's surprising is that I executed a pure function twice in succession
> and got different results. Furthermore the second execution papers over an
> exception.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: lazy-cat's memoization obscuring runtime exceptions

[Gary Trakhman]

What's surprising about this?  Maybe you want the promoting *' variant:

> (def expexp (lazy-cat [2] (map #(*' % %) expexp)))
#'sandbox21201/expexp
> (take 100 expexp)
Execution Timed Out!

Seems like it's a big number :-)


On Mon, Jun 13, 2016 at 4:27 PM Sebastian Oberhoff <
oberhoff.sebast...@gmail.com> wrote:

> The following lines are copied straight from tryclj.com
>
> > (def expexp (lazy-cat [2] (map #(* % %) expexp)))
> #'sandbox20298/expexp
> > (take 100 expexp)
> java.lang.ArithmeticException: integer overflow
> > (take 100 expexp)
> (2 4 16 256 65536 4294967296)
>
> I'm wondering if this behavior is known, because I was really surprised by
> this. Couldn't this lead to some really subtle bugs downstream?
>
> (I just went back to doublecheck and now I'm getting an unbound var for
> expexp on tryclj.com. It still behaves like this on my local machine
> though.)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Gary Trakhman]

Why hasn't anyone mentioned Boot, which provides shebang-style execution
and deps for you? https://github.com/boot-clj/boot/wiki/Scripts

On Thu, Jun 9, 2016 at 12:48 PM James Reeves  wrote:

> You can run Clojure directly, but often you don't just need Clojure, but
> other libraries as well. The "lein run" command not only runs your code, it
> also handles downloading any dependencies your code might have.
>
> In Ruby terms, Leiningen is the equivalent of ruby + rbenv + bundler +
> rake. I'm less familiar with the Python stack, but I believe python +
> virtualenv + pip goes some way to having the same functionality.
>
> - James
>
> On 9 June 2016 at 17:08, Jiacai Liu  wrote:
>
>> I  started learning clojure recently, and I am annoyed at the way to run
>> it (aka. lein run). why clojure script can't be run like python,ruby or
>> scala, like python .py
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group 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: Is there an apply-able new?

[Gary Trakhman]

Here's a complex example using clojure.reflect, the intent of which was to
create a macro that emits type-hints for the actual constructors that are
available, to resolve ambiguity when there are multiple constructors with
the same number of arguments that differ in type.

https://github.com/gtrak/interop/blob/master/src/interop/core.clj

On Fri, May 27, 2016 at 1:25 PM Gary Trakhman 
wrote:

> Yes, you'll have to use the reflection API to create a class dynamically.
>
> https://docs.oracle.com/javase/tutorial/reflect/member/ctorInstance.html
>
> On Fri, May 27, 2016 at 1:24 PM hiskennyness  wrote:
>
>> qooxdoo lets us supply oft-used widget parameters to the constructor. For
>> example, a button can specify its label and icon at new time. And this
>> works fine from cljs:
>>
>>(new qx.ui.mobile.form.Button "Go!") ;; label is the first arg
>>
>> But I am wrapping qooxdoo in something more concise and want to be able
>> to code:
>>
>>(qxia/make (::Button "Go!")
>>   ..other init params to be "set"
>>
>> Unfortunately I cannot even
>>
>>(new (qx-class qia-type)) ;; computed class
>>
>> Let alone
>>
>>(apply new (qx-class qxia-type) make-inits)
>>
>> Not that I thought I would get away with it. :) I grok new is special.
>>
>> I can fall back on the qooxdoo API and use setLabel and setIcon, but I
>> like learning so I thought I would ask if there were some way to:
>>
>>1. compute a class (preferably by first constructing a name) and/or
>>2. do the moral equivalent of applying new to parameters
>>
>> -hk
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group 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 there an apply-able new?

[Gary Trakhman]

Yes, you'll have to use the reflection API to create a class dynamically.

https://docs.oracle.com/javase/tutorial/reflect/member/ctorInstance.html

On Fri, May 27, 2016 at 1:24 PM hiskennyness  wrote:

> qooxdoo lets us supply oft-used widget parameters to the constructor. For
> example, a button can specify its label and icon at new time. And this
> works fine from cljs:
>
>(new qx.ui.mobile.form.Button "Go!") ;; label is the first arg
>
> But I am wrapping qooxdoo in something more concise and want to be able to
> code:
>
>(qxia/make (::Button "Go!")
>   ..other init params to be "set"
>
> Unfortunately I cannot even
>
>(new (qx-class qia-type)) ;; computed class
>
> Let alone
>
>(apply new (qx-class qxia-type) make-inits)
>
> Not that I thought I would get away with it. :) I grok new is special.
>
> I can fall back on the qooxdoo API and use setLabel and setIcon, but I
> like learning so I thought I would ask if there were some way to:
>
>1. compute a class (preferably by first constructing a name) and/or
>2. do the moral equivalent of applying new to parameters
>
> -hk
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Avoiding nested ifs...

[Gary Trakhman]

Ah, yea, having a 'data spec' specifically for validation is above and
beyond what I meant, which was having your domain contained within a single
data structure that can be validated using a number of possible techniques.
That validation would be separate from the code that's pulling it apart
down the line and actually doing the work on known good inputs.

On Thu, May 26, 2016 at 11:39 AM John Szakmeister 
wrote:

> On Thu, May 26, 2016 at 10:55 AM, Gary Trakhman 
> wrote:
> > I think the idiomatic way to handle this in clojure is to do all your
> > validation upfront on a single descriptive data structure, perhaps in a
> > single function, then bail early.  That has the added advantage of being
> > able to report multiple errors, instead of just the first, and is well
> > supported by libs like Schema and the new clojure.spec.
>
> -ENOPARSE. :-)  I think you're saying "describe the data you expect
> with other data in Clojure", and then use that data to validate the
> inputs--hence the reference to Schema.
>
> I guess the problem I see here is that it's complicated.  I really
> dumbed things down in my example, but there are a number of properties
> of the system that are dynamic: the limits of the axis, what
> acceptable values are based on the type of axis, whether the
> coordinate system is linear or compass-based, etc.  Almost all of this
> is determined at runtime when we link up with the equipment, but ends
> up driving the kinds of validation we need to do. I'm not sure how
> something like Schema would handle this, but...
>
> I was trying to avoid using Schema, since it's rather large and I have
> slow links to worry about (at least for the web side of things).  And
> I took clojure.spec as something not to be used in production, but to
> help with testing--though I see the cross-over.
>
> **update**: so I went and pulled in Schema, and it's not as bad as I
> thought.  So perhaps using Schema is more viable than I thought.
>
> > Maybe if the target of the code is by nature imperative, it would make
> this
> > more difficult.  You could probably abuse exceptions to avoid the
> nesting.
>
> I'm not sure I can say it's imperative by nature--it's my desire to
> reduce nesting and the number of edges I have to keep in my brain.  I
> just haven't found a way that I'm happy to deal with it in a
> functional manner.
>
> As I mentioned, I was trying to avoid exceptions, but you're right--it
> may be the only real way forward, but I'm looking for other options
> first. :-)
>
> -John
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Gary Trakhman]

I think the idiomatic way to handle this in clojure is to do all your
validation upfront on a single descriptive data structure, perhaps in a
single function, then bail early.  That has the added advantage of being
able to report multiple errors, instead of just the first, and is well
supported by libs like Schema and the new clojure.spec.

Maybe if the target of the code is by nature imperative, it would make this
more difficult.  You could probably abuse exceptions to avoid the nesting.

On Thu, May 26, 2016 at 10:50 AM John Szakmeister 
wrote:

> I'm very much a fan of bailing out early in imperative
> programming as it helps to avoid a bunch of nested if conditions
> that are to follow and read.  This typically comes up when
> checking arguments to ensure that they're valid (in range, of
> acceptable values, etc).  One of the major stumbling blocks
> I've had when writing Clojure is to find a good way to keep code
> concise, but readable.
>
> For instance, take a snippet like this:
>
> def verify_position(pos, type):
> # It's acceptable to have a None value--it just means don't
> # change the position for the axis.
> if pos is None:
> return True
>
> # Anything outside our limits is invalid.
> if (pos > 90) or (pos < 0):
> return False
>
> if type == 'switched' and pos not in (0, 90):
> # Switched axes only allow 0 and 90, and nothing in
> # between.
> return False
>
> if type == 'dual':
> # We can't control the value on this axis, so anything
> # other than None is invalid.
> return False
>
> return True
>
>
> I find this very readable in that along the way, I can start
> throwing things off the raft: after the first condition, I don't
> need to worry about None being present.  After the second, I
> know the value is within limits, etc.  I have a hard time
> translating the above into (what I believe) is readable Clojure.
> Here's my stab at it:
>
> (defn verify-pos [pos axis-type]
>   (if (nil? pos)
> ;; nil means don't move the axis.
> true
> (case axis-type
>   ;; Only 0 and 90 are allowed on a switched axis.
>   "switched" (or (= pos 0)
>  (= pos 90))
>
>   ;; Any non-nil value is disallowed on dual.
>   "dual" false
>
>   ;; Otherwise, make sure we're within a valid range.
>   (and (<= pos 90)
>(>= pos 0)
>
> Now, this was a rather simple example, but you can see some of
> the nesting starting.  Add in another condition like
> nil?--something that is somewhat global across the different
> types--and you get another level of nesting in there.
>
> I can break it up more:
>
> (defn verify-range [pos axis-type]
>   (case axis-type
> ;; Only 0 and 90 are allowed on a switched axis.
> "switched" (or (= pos 0)
>(= pos 90))
> ;; Any non-nil value is disallowed on dual.
> "dual" false
> ;; Otherwise, make sure we're within a valid range.
> (and (<= pos 90)
>  (>= pos 0
>
> (defn verify-pos [pos axis-type]
>   (or (nil? pos)
>   (verify-range pos axis-type)))
>
> And this is a bit better, but you run up against another issue:
> coming up with good names for each part of the whole so that you
> can combine them.  And, coming up with names that don't sound so
> similar that folks have to dig into the implementation to know
> which one is the correct one (I feel the above break up has this
> problem).
>
> In some cases, the error checking logic is really
> complicated--because the thing being controlled has complex
> restrictions that are out of my control--and the nesting of if
> conditionals is maddening.  Having to come up with names for
> each of them would be more than twice as frustrating, as the
> individual bits don't lend themselves to good names.
>
> Then there's the issue of combining the verification and the
> actual work into a useful function, where you need to verify and
> then act on it:
>
> (defn set-position [pos type]
>   (if (verify-pos pos type)
> (send-position-to-equip pos)
> (do-something-for-invalid-input)))
>
> Again, this is a simple example, but more complicated cases have
> more to check, and therefore more nesting of if statements,
> where the early bail technique leaves the flow pretty readable.
> I also realize pre- and post- conditions might be useful, but I
> don't feel they're appropriate when validating user
> input--especially not assertion errors, which we generally think
> of programming errors, not user input errors.
>
> I realize some of this may be me and shaping my mind more to
> functional programming, though I do feel like I have a decent
> grasp of it.  I've been dabbling in Clojure for several years,
> and have more recently incorporated ClojureScript into a project
> for our web front-end.  However, I feel like I might be missing
> an important strategy for this kind of problem, and I'm hoping
> that one of you can point me in a g

Re: clojure.spec

[Gary Trakhman]

It seems like the :req impls should go further to disallow trash input,
it's not immediately clear that they only allow namespaced keywords.

For example:
> (s/valid? (s/keys :req ["a"]) {:a 5})
true
> (s/valid? (s/keys :req [5]) {:a 5})
true

What ends up happening in practice, is (filter keyword? (flatten req)),
which is suspect.

Could/should spec be used to check itself? That's the lisp way, after all.
To do so here, we might need more map-checking builtins than s/keys.

On Wed, May 25, 2016 at 1:48 PM Brent Millare 
wrote:

> What's the difference between clojure.spec/or and clojure.spec/alt? They
> seem to accept the same inputs, multiple keyword-predicate pairs, and
> output tagged values when used with clojure.spec/conform. Is
> clojure.spec/or usable within a regular expression?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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

[Gary Trakhman]

It would be helpful to make clojure.spec available as a lib for 1.8.  I
have opted to backport clojure.spec (a 30-second copy/paste job) into our
application running on 1.8 for an easy transition, and maybe others would
be more comfortable bringing in a lib until 1.9 is further along.  That
would also allow related libs/fn-specs to show up and be useful sooner.

On Wed, May 25, 2016 at 9:25 AM Alex Miller  wrote:

>
> On Tuesday, May 24, 2016 at 5:45:47 PM UTC-5, Sean Corfield wrote:
>>
>> We have 1.9.0 Alpha 1 in QA at World Singles and plan to start using
>> clojure.spec this week. We’ve gone to production on Alpha builds ever since
>> 1.3 and almost never had any problems (in five years – time has flown
>> past!).
>>
>>
>>
>> What sort of tradeoffs have you in mind regarding whether to use
>> clojure.spec or not? I ask because I’m thinking about adding an optional
>> namespace to clojure.java.jdbc that would provide fn-specs for that library
>> – my assumption is that folks not yet using a 1.9.0 build would simply not
>> require that spec namespace…
>>
>
> Well if you want to validate your data and functions then I think using
> clojure.spec would be useful. :) If you want to check them at runtime then
> there is obviously a performance cost in doing so.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Gary Trakhman]

I answered my own question in the specific case, this seems to work:

(defn to-int
  [x]
  (try
(Long/parseLong x)
(catch Exception _
nil)))

(s/def ::intable (s/conformer to-int))

(s/conform (s/cat :ints ::intable) ["5"])
> {:ints 5}

On Wed, May 25, 2016 at 8:36 AM Gary Trakhman 
wrote:

> Is there a public way to get the registry's spec at a keyword?  I can
> envision other libs being built around the spec registry, and I'm trying to
> write a small one (coercions) to see if I can use spec for this use-case.
> Is that non-sanctioned kind of thing going forward?
>
> The likely candidate seems 'specize'.
>
> On Wed, May 25, 2016 at 8:30 AM Rich Hickey  wrote:
>
>> > Would you ever expect to use fdef/instrument active in production for
>> validation
>>
>> No, definitely not. It’s that kind of runtime checking (and expense) that
>> gives some dynamic lang checking systems a bad rep.
>>
>> The philosophy is - generative testing has made sure your function
>> complies with the specs. So, testing the :ret and :fn properties over and
>> over is redundant and serves no point.
>>
>> OTOH, you may encounter user- or externally-supplied data at runtime and
>> want to use the facilities of spec to validate/process it. Then you can use
>> valid? or conform *explicitly* to do so.
>>
>> The intent is that running with wrappers (instrumentation) should be done
>> only during testing.
>>
>> > On May 24, 2016, at 7:43 PM, Elliot  wrote:
>> >
>> > Super super excited for this feature, thanks so much for creating this.
>> >
>> > In the runtime-validation case, the guide mentions:
>> >
>> > 1. Calling `valid?` in a precondition
>> > 2. Calling `conform` in the fn implementation
>> >
>> > However neither of these appear to use the `fdef`/`instrument` combo,
>> which seems the closest to "type annotating" the function.  Would you ever
>> expect to use fdef/instrument active in production for validation, or is
>> that a misunderstanding of its use?
>> >
>> > Thanks!
>> >
>> > - E
>> >
>> >
>> > On Tuesday, May 24, 2016 at 11:12:59 AM UTC-7, scott stackelhouse wrote:
>> > I restructured my data to make this section an optional sub-map, which
>> I think is actually better anyway.
>> >
>> > On Tuesday, May 24, 2016 at 11:08:27 AM UTC-7, scott stackelhouse wrote:
>> > Ok.
>> >
>> > Thanks all who have worked on this, btw.  It is incredibly timely for
>> me and is already great help for a work project.
>> >
>> > --Scott
>> >
>> > On Tuesday, May 24, 2016 at 10:57:26 AM UTC-7, Rich Hickey wrote:
>> > ‘and' and ‘or’ are not currently supported in :opt
>> >
>> >
>> > > On May 24, 2016, at 1:45 PM, scott stackelhouse <
>> scott.sta...@gmail.com> wrote:
>> > >
>> > > I'm having a problem writing a spec for a map with some required
>> keywords and some optional keywords.  The caveat here is that the optional
>> keywords are all or none... that is they are optional but if one is present
>> they must all be present.
>> > >
>> > > What I tried to write was:
>> > >
>> > > (s/keys :req [::a ::b ::c] :opt [(and ::d ::e ::f)])
>> > >
>> > > and that fails an assertion.  It appears that the logicals (and, or)
>> are not allowed in the optional section?
>> > >
>> > > Am I thinking about this in the wrong way?
>> > >
>> > > --Scott
>> > >
>> > > --
>> > > 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 rec

Re: clojure.spec

[Gary Trakhman]

Is there a public way to get the registry's spec at a keyword?  I can
envision other libs being built around the spec registry, and I'm trying to
write a small one (coercions) to see if I can use spec for this use-case.
Is that non-sanctioned kind of thing going forward?

The likely candidate seems 'specize'.

On Wed, May 25, 2016 at 8:30 AM Rich Hickey  wrote:

> > Would you ever expect to use fdef/instrument active in production for
> validation
>
> No, definitely not. It’s that kind of runtime checking (and expense) that
> gives some dynamic lang checking systems a bad rep.
>
> The philosophy is - generative testing has made sure your function
> complies with the specs. So, testing the :ret and :fn properties over and
> over is redundant and serves no point.
>
> OTOH, you may encounter user- or externally-supplied data at runtime and
> want to use the facilities of spec to validate/process it. Then you can use
> valid? or conform *explicitly* to do so.
>
> The intent is that running with wrappers (instrumentation) should be done
> only during testing.
>
> > On May 24, 2016, at 7:43 PM, Elliot  wrote:
> >
> > Super super excited for this feature, thanks so much for creating this.
> >
> > In the runtime-validation case, the guide mentions:
> >
> > 1. Calling `valid?` in a precondition
> > 2. Calling `conform` in the fn implementation
> >
> > However neither of these appear to use the `fdef`/`instrument` combo,
> which seems the closest to "type annotating" the function.  Would you ever
> expect to use fdef/instrument active in production for validation, or is
> that a misunderstanding of its use?
> >
> > Thanks!
> >
> > - E
> >
> >
> > On Tuesday, May 24, 2016 at 11:12:59 AM UTC-7, scott stackelhouse wrote:
> > I restructured my data to make this section an optional sub-map, which I
> think is actually better anyway.
> >
> > On Tuesday, May 24, 2016 at 11:08:27 AM UTC-7, scott stackelhouse wrote:
> > Ok.
> >
> > Thanks all who have worked on this, btw.  It is incredibly timely for me
> and is already great help for a work project.
> >
> > --Scott
> >
> > On Tuesday, May 24, 2016 at 10:57:26 AM UTC-7, Rich Hickey wrote:
> > ‘and' and ‘or’ are not currently supported in :opt
> >
> >
> > > On May 24, 2016, at 1:45 PM, scott stackelhouse <
> scott.sta...@gmail.com> wrote:
> > >
> > > I'm having a problem writing a spec for a map with some required
> keywords and some optional keywords.  The caveat here is that the optional
> keywords are all or none... that is they are optional but if one is present
> they must all be present.
> > >
> > > What I tried to write was:
> > >
> > > (s/keys :req [::a ::b ::c] :opt [(and ::d ::e ::f)])
> > >
> > > and that fails an assertion.  It appears that the logicals (and, or)
> are not allowed in the optional section?
> > >
> > > Am I thinking about this in the wrong way?
> > >
> > > --Scott
> > >
> > > --
> > > 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
>

Re: [ANN] Clojure 1.9.0-alpha1

[Gary Trakhman]

The inevitable question: is there a release schedule for 1.9 yet? I would
love to start writing greenfield spec code ASAP, knowing that would help me
communicate tradeoffs.

On Tue, May 24, 2016 at 1:05 PM Alex Miller  wrote:

> You know how you always see the typo right after you hit send?
>
> - Leiningen: [org.clojure/clojure "1.9.0-alpha1"]
>
>
> On Tuesday, May 24, 2016 at 12:04:45 PM UTC-5, Alex Miller wrote:
>>
>> Clojure 1.9.0-alpha1 is now available.
>>
>> Try it via
>> - Download:
>> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha1
>> - Leiningen: [org.clojure/clojure "1.8.0-alpha2"]
>>
>> 1.9.0-alpha1 includes the first release of clojure.spec
>> .
>>
>> A usage guide for spec is now available: http://clojure.org/guides/spec.
>>
>> Enjoy!
>> Alex
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Gary Trakhman]

I usually work around this by putting the dispatch in a separate def and
referencing the var within defmulti.

(defmulti my-multi #'my-dispatch)

It's barely slower for the extra var dereference and very convenient for
development.

On Fri, Apr 1, 2016 at 12:10 PM hiskennyness  wrote:

> I just killed two hours trying to figure out why my tweaks to the dispatch
> function of defmulti did not work. Finally got the feeling I had found a
> bug in Clojure, but then I found a comment somewhere saying it is a
> feature, effectively a defonce (and, yes, looking at the source I see it
> does not do anything if it is already defined).
>
> Shucks, could we get a warning or some doc on this?
>
> But I am a Lisper, I am used to this. The classic is the initform to a
> class-allocated variable in defclass. :)
>
> -kt
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Question about how lazy sequences are held/released/garbage collected

[Gary Trakhman]

I think this is an example of locals-clearing at work:
https://groups.google.com/forum/#!topic/clojure/FLrtjyYJdRU

My guess is that the compiler clears the references 'at the point of last
reference', but in this case s2 has no last reference.

On Fri, Apr 1, 2016 at 9:07 AM John Jacobsen  wrote:

> The problem of correctly handling large lazy sequences so they don't blow
> up in memory came up at work this week.
>
> I thought I would try to explain the following simple case to our Monday
> afternoon study group, and I realized I don't understand it 100%:
>
> (def n 1e8)
>
> (let [s1 (range n)
>   s2 (map identity s1)]
>   (count s2))
>
> ;;=> 1
>
>
> (let [s1 (range n)
>   s2 (map identity s1)]
>   (count s1))
>
> ;;=> GC overhead limit exceeded
>
> For the first case, I get that in consuming s2, elements of both s1 and s2
> are consumed and garbage-collected; and that in the second case, clearly s1
> can't be released as it's consumed because s2 might still need it (even
> though we never realize s2).  My question is, as s1 is consumed in the
> second case, how does it "know" that s2 still holds a reference to it, and
> that it therefore should keep the realized values? What is the relevant
> difference between these two examples? And where in the Clojure/core code
> are the relevant details?
>
> Thanks in advance!
> John
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Gary Trakhman]

I always work in a single process, REPL and server, there's no need to
separate them out generally.

You might have better luck with the G1 collector, in addition to JVM
tuning.  The G1 has the useful property of giving memory back to the OS
when a GC is performed.
Use the command-line flag: -XX:+UseG1GC

If this is confusing, in short, PHP is 'interpreted', thus it's leaner and
slower than a 'compiled' language like clojure.  There's a lot of stuff
that needs to be loaded for clojure to work (the compiler lives in memory),
and you'll take a hit in startup-time and memory footprint.  Some of this
is java-specific, probably CLJS on V8 can do better in terms of memory
footprint.

On Mon, Mar 28, 2016 at 10:36 AM Michael Willis 
wrote:

> You can tune memory usage by passing parameters to the JVM:
>
> http://docs.oracle.com/cd/E19900-01/819-4742/abeik/index.html
>
> The sample leiningen project file has an example of how to pass parameters
> to the JVM:
>
>
> https://github.com/technomancy/leiningen/blob/master/sample.project.clj#L264
>
> Hope that helps,
> Michael Willis
>
>
>
> On Monday, March 28, 2016 at 7:11:49 AM UTC-5, Jason Basanese wrote:
>>
>> Hello all! I'm new to this forum. My name Is Jason Basanese and I am a
>> relatively new clojurist.
>>
>> I recently began hosting my first small full stack Clojure web app. While
>> doing this I ran into memory problems with my admittedly small load server.
>> The maximum it can take in temp memory is 741MB. Too much of that memory is
>> consumed giving an error when I try to run two REPLs on the server. One for
>> testing and editing code and the other for leaving the app running. My
>> other dynamic content websites which use php directly with Apache use
>> minimal memory. Why is it that running a Clojure app like such "lein run -m
>> clojureweb.core/serve" takes up so much memory? Here is the code of the
>> function I am running with that command.
>>
>> (defn serve [& args]
>>   (org.apache.log4j.BasicConfigurator/configure)
>>   (run-server
>>(logger/wrap-with-logger
>> (reload/wrap-reload app))
>>{:port 8080}))
>>
>> Are the logger or the wrap-reload making it take up so much memory? Is
>> there a better way to run Clojure apps that is less robust? Or is using a
>> relatively large amount of memory just a bullet to bite when using Clojure?
>> Yes I know an obvious solution would just be to upgrade the server, but
>> where's the fun in that?
>>
>> Requests for more detail, comments, answers and opinions all welcome!
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Scripting with Clojure / "slow" boot time

[Gary Trakhman]

Personally, I've recently fought machine-specific AOT breakage issues by
forcing maven-clojure-plugin to only compile a single entry-point
namespace, making compilation order deterministic again.  Arguably, it
should have worked in any order but this specific issue was hard to track
down.

In any case, I think there is existing code that relies on the determinism.

On Wed, Feb 10, 2016 at 11:36 AM Alex Miller  wrote:

> Parallel loading is something I've looked at a little bit. Unfortunately
> theory is easier in theory than in practice. :) While in many cases, it
> probably works fine, it's possible for there to be problematic ambiguity
> with which namespace is loaded first, especially for things that update
> stateful things in the Clojure runtime (protocol extensions, multimethod
> cases, namespaces, the dynamic classloader, etc). Perhaps you've heard that
> mutable state and concurrency are problematic. :) I think it's been
> interesting to see the issues that ClojureScript has found as they've
> implemented parallel compilation as they are likely similar.
>
> Anyhow, it's certainly worth further consideration.
>
>
> On Wednesday, February 10, 2016 at 4:53:06 AM UTC-6, Marc O'Morain wrote:
>>
>> Hi Alex,
>>
>> I've love to offer any help/test data on this that I can. At CircleCI we
>> run (among other processes) a large Clojure app that takes 2 minutes to
>> load on a top of line Macbook Pro, with Java 1.8 (Hotspot) . From my best
>> efforts at profiling, this time is all spend in the Clojure Compiler and
>> the JVM class loader, loading all transitive dependencies. Mike's analysis
>> above is totally in line with what we see.
>>
>> One thing I have noticed is that all compilation runs in a single thread.
>> In theory all namespaces required in an `ns` form can be loaded in parallel.
>>
>> If there is any profiling you would like me to run on the code-base,
>> please let me know.
>>
>> Marc
>>
>> On 10 February 2016 at 08:22, Mikera 
>> wrote:
>>
>>> Good initiative, I've filled in a response to the survey.
>>>
>>> One thing that strikes me is that the main issue with loading time is
>>> the time required to transitively load and compile all the referred
>>> namespaces (which can be a lot in a big project...). This in turn may
>>> trigger class loading of Java libraries, IO as various resources are
>>> initialised etc. An observation is that a lot of this is often not required
>>> initially, so there *might* be a clever strategy to mitigate this through
>>> laziness.
>>>
>>> This could be something like:
>>> - When loading the current namespace, *don't* load referred namespaces
>>> (yet)
>>> - Create lazy placeholders within vars in the current namespace for (for
>>> every def, defn etc.)
>>> - Only when the placeholder is deref'd / invoked then compile the
>>> relevant function and pull in dependencies.
>>> - After first deref / invocation, replace the placeholder with the full
>>> compiled function / value, so that subsequent access has no overhead
>>>
>>> This would be a pretty big change, and might break tools that make
>>> assumptions about order of loading of namespaces... but I think it would
>>> solve 90% of the boot time problems if implemented correctly.
>>>
>>> The other potentially big win would be concurrent loading of namespaces.
>>> Guess you are looking at that already?
>>>
>>>
>>>
>>> On Wednesday, 10 February 2016 02:36:43 UTC+8, Alex Miller wrote:

 I'm doing some research on slow Clojure boot time and would be
 interested in collecting info about example use cases where it's been a
 problem for people.

 http://goo.gl/forms/eSpn8M5FNB

 I'm not expecting to release the results in any formal way, mostly
 looking to use it to pull out particular use cases and/or commonalities
 across anecdotes so that we can work on boot time problems that matter the
 most (and solutions likely to help the most). Any numbers you can provide
 would be great.

 Alex


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

Re: Java Interop for a static method call that returns an ArrayList

[Gary Trakhman]

(map (fn [u] (.getName u)) (DAO/getUsers)) ?

You'll need to write a getter since name is private.

On Wed, Feb 10, 2016 at 8:44 AM Adrian Cooley 
wrote:

> Hi,
>
> I have a Java class that has a static method call that returns a Java
> Array List of users as follows:
>
> public final class DAO {
>
> public static List getUsers() {
> List userList = new ArrayList();
> User user = new User("Mike");
> userList.add(user);
> return userList;
> }
> }
>
> public class User {
>
> private String name;
>
> public User(String name) {
> this.name = name;
> }
> }
>
> In a clojure project I'm not fully sure how to retrieve the call to the
> list of Users and just print out the name of the User I've created here
> Mike. I have searched online under the keywords "clojure java interop
> java.util.ArrayList", but I can only find examples where in clojure you
> create a new arraylist instance and do operations on this newly created
> list. How does clojure deal with an ArrayList that is being passed into
> clojure from java?
>
> Thanks,
> Adrian.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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 API type hint question

[Gary Trakhman]

Just because no else has said it yet, clojure vectors, lists and seqs all
implement the read part of the interface java.util.List, and your java API
should most likely be refactored to use the List interface instead of
ArrayList if it isn't already.

If that's the case, and it's not trying to mutate what's passed in (any
well-designed java api should only read from collections or defensively
copy first), you can just pass the clojure collection to the java api as is.

On Tue, Jan 26, 2016 at 5:58 PM Beau Fabry  wrote:

> Tell the compiler that the type you're passing to the constructor is a
> Collection, so it will know which constructor to use without reflection.
>
> (set! *warn-on-reflection* true)
> => true
> (import '(java.util ArrayList Collection))
> => java.util.Collection
> (ArrayList. (list 1 2))
> Reflection warning,
> /Users/bfabry/Library/Caches/IdeaIC15/tmp/form-init108635367050123227.clj:1:1
> - call to java.util.ArrayList ctor can't be resolved.
> => [1 2]
> (ArrayList. ^Collection (list 1 2))
> => [1 2]
>
>
>
> On Tuesday, January 26, 2016 at 1:56:19 PM UTC-8, Ritchie Cai wrote:
>>
>> Quoting for small example like I mention is not an issue, but in general,
>> I need to pass an vector or list, since that's what I get, in which case I
>> cannot quote.
>>
>> On Tuesday, January 26, 2016 at 3:52:17 PM UTC-6, Michael Willis wrote:
>>>
>>> What's not practical about quoting?  I thought it was considered more
>>> idiomatic than doing (list ...)
>>>
>>> On Sunday, January 17, 2016 at 2:48:29 PM UTC-6, Ritchie Cai wrote:

 Hi all,

 I'm trying to create a Java ArrayList object from a Clojure collection
 to pass to another Java API. I get reflection warnings when the elements
 are not primitive types, in this case I'm using SparseIndexedVector
 class from vectorz library.

 (ArrayList. [c0 c1 c2])
 Reflection warning, *cider-repl localhost*:77:11 - call to
 java.util.ArrayList ctor can't be resolved.

 where c0 c1 c2 are of type SparseIndexedVector. Alternatively, I can
 create create ArrayList then add elements one by one in a loop.

 (doto (ArrayList.)
(.add c0)
(.add c1)
(.add c2))

 But I'm wondering if there is away to get rid of the the reflection
 warning when calling ArrayList constructor.

 Also, quoting a list will not give reflection warning:

 (ArrayList. '(c0 c1 c2))  ;; no warning

 (ArrayList. (list c0 c1 c2))
 Reflection warning, *cider-repl localhost*:77:11 - call to
 java.util.ArrayList ctor can't be resolved.

 However, quoting is not very practical.

 Thanks
 Ritchie

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

[Gary Trakhman]

We've been using it on our development branch without a hitch since Dec 2.

On Thu, Dec 10, 2015 at 2:32 AM Michael Blume  wrote:

> No issues here.
>
> On Tue, Dec 8, 2015 at 5:39 PM James Elliott  wrote:
>
>> I’ve been working with it for a few days and have seen no issues yet.
>>
>>
>> On Wednesday, December 2, 2015 at 10:03:31 AM UTC-6, Alex Miller wrote:
>>
>>> Clojure 1.8.0-RC3 is now available. *This build is a "release
>>> candidate"!* We would appreciate any and all testing you can do on your
>>> own libraries or internal projects to find problems.
>>>
>>> Try it via
>>>
>>>- Download:
>>>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC3
>>>- Leiningen: [org.clojure/clojure "1.8.0-RC3"]
>>>
>>> Below are the changes since 1.8.0-RC2. See the full 1.8 change log here:
>>> https://github.com/clojure/clojure/blob/master/changes.md.
>>>
>>>- CLJ-1845  / CLJ-1851
>>> New ^:redef to mark
>>>vars that should not be direct linked
>>>   - The metadata ^:redef can be used to mark function vars that
>>>   should not be direct linked
>>>   - clojure.core/load was previously marked with ^:dynamic for this
>>>   purpose, but is now marked ^:redef
>>>- CLJ-1856  Direct
>>>linking breaks clojure.test location reporting for failures
>>>- CLJ-1854  Set line
>>>number in bytecode prior to invokeStatic call
>>>- CLJ-1853  In socket
>>>server, require the ns of the accept-fn before resolving 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.
>

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

[Gary Trakhman]

I spend most of my time on application code, I think the tradeoffs are
different when shipping public libraries.  Obviously, I would prefer my
libs to be more slow-moving, more well-documented, more generally useful
and well-defined.  I want my application code to be quick to change and
develop first and foremost.

As time goes on, I am more likely to end up having to read the source code
of the libraries I use.  I'm willing to accept that risk if using the
library in the first place lets me ship faster with fewer errors than
reinventing what it does from scratch.  I don't think understanding all
dataflow upfront is a useful way to spend time, and most libraries I've
used try to provide a sane interface and document it well via test-cases,
at least.

Doing clojure work in a large codebase taught me to create orderly
namespaces with few data shapes and the tightest code possible to express
them, which helps when someone (or myself 6 months later) has to read it,
to be more concerned with what it 'does' than the names I gave things.

I'd like to try haskell, but I'm not sure types in general would provide
enough benefit to be worth it for small projects and well-written/tested
large ones.  There is that intermediate stage of a project, where many
things have been written in a hurry, and tests are not comprehensive, where
I think types would help keep up development speed a little longer before
hitting the tech-debt wall.  Perhaps the curves look different to a
haskeller :-).

I like prismatic schema, but have only used it at module boundaries and for
more dynamic use-cases (to avoid having to write user-facing validation
code myself), and don't hold to it as a discipline except in the context of
a team.

It's hard to know if I could write the same code faster by following a
compiler's types, but my instinct says that it would get in the way for
prototyping, and provide less security and more noise the more decoupled
your code, which is a practice that clojure encourages.

Printing stuff in the REPL is kind of great:
http://www.learningclojure.com/2010/09/clojure-macro-tutorial-part-i-getting.html
https://github.com/dgrnbrg/spyscope


On Mon, Nov 30, 2015 at 4:49 PM Jonathon McKitrick 
wrote:

> I've read the recent comments on 'the end of dynamic languages' and I'm
> curious what ways you have found for dealing with one of the issues I've
> heard mentioned frequently: when libraries (or functions in general) pass
> maps around as arguments or return values, how to go about finding out
> exactly what those maps contains without slogging through source code.
>
> Any suggestions?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: A call for an idiomatic rendering of Clojure EDN in info/error messages

[Gary Trakhman]

A pair of curly brackets with a single value isn't part of the grammar
either, and I think reads better than _
On Nov 13, 2015 8:47 AM, "Colin Yates"  wrote:

> Really, I don’t mind - I would just like consistency :-)
>
> One argument for the right delimiter of some sort is that it is
> unambiguous and therefore nobody can misinterpret it. If you were
> unfamiliar with a validation library and it reported [:a :b :c must
> be “2”] you _could_ interpret that as either the literal 2 or a
> string containing 2.  To interpret it correctly you must know more than
> just the literal text, therefore it isn’t a great choice.
>
> I like _ because [:a :b :c must be _”2”_] is less open to
> misinterpretation because the _ symbol is not part of the Clojure grammar
> (unlike brackets and quotes). It is also idiomatic to use as a symbol to
> mean “I don’t care about the value of this” which has some symmetry (albeit
> at a stretch) in the use I am proposing here.
>
> On 13 Nov 2015, at 13:19, Atamert Ölçgen  wrote:
>
> Hi Colin,
>
> Why not just "2"?
>
> On Fri, Nov 13, 2015 at 1:55 PM, Colin Yates 
> wrote:
>
>> Hi all,
>>
>> Can we, the community agree a consistent way of rendering Clojure EDN
>> when we report it in info or error. For example, given the EDN "2" (i.e. a
>> string containing a single character 2) I have seen various libraries
>> render it as:
>>
>>  - 2
>>  - "2"
>>  - ["2"]
>>  - [2]
>>  - (2)
>>  - '"2"'
>>
>> I would like to propose that we standardise around "_" as the boundary
>> character as that isn't likely to be used in (except for some markup I
>> guess but that is pretty unlikely), so a test framework might render as
>> such:
>>
>>  - expected _2_ but was _"2"_
>>
>> Please? :-)
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Kind Regards,
> Atamert Ölçgen
>
> ◻◼◻
> ◻◻◼
> ◼◼◼
>
> www.muhuk.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.
> 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: Cryptic crashes in Leiningen

[Gary Trakhman]

Hahaha to the chances :).

Looks like it'll help.

Lein deps :tree will give you more information about the dependencies that
are resolved
On Nov 8, 2015 8:50 PM, "James Elliott"  wrote:

> Thanks, Gary! Kevin tried a :verbose require, and the last few lines
> involved loading tools.reader and the ExceptionInfo class, so it seems very
> likely that you are correct about the problem. I have suggested trying this
> exclusion, does that look like it might do the trick? (I’m not entirely
> confident of the semantics of Leiningen exclusions and how they propagate
> to recursive dependencies):
>
>   :dependencies [[org.clojure/clojure "1.7.0"]
>  [org.clojure/tools.reader "0.10.0"]  ; Or perhaps 
> 1.0.0-alpha1
>  [afterglow "0.1.4" :exclusions [org.clojure/tools.reader]]]
>
>
> On Sunday, November 8, 2015 at 1:17:47 PM UTC-6, Gary Trakhman wrote:
>>
>> Just a guess, since your project has many dependencies, and I have little
>> time right now, but I had a recent issue with tools.reader <=0.9.2 and the
>> ExceptionInfo class.  The maven artifacts for tools.reader bundled .class
>> files, and triggered this bug:
>> http://dev.clojure.org/jira/browse/CLJ-1639
>>
>> Our stacktraces looked like this:
>> Caused by: java.lang.ExceptionInInitializerError
>> at java.lang.Class.forName0(Native Method)
>> at java.lang.Class.forName(Class.java:348)
>> at clojure.lang.RT.classForName(RT.java:2154)
>> at clojure.lang.RT.classForName(RT.java:2163)
>> at clojure.lang.RT.loadClassForName(RT.java:2182)
>> at clojure.lang.RT.load(RT.java:436)
>> at clojure.lang.RT.load(RT.java:412)
>> at clojure.core$load$fn__7859.invoke(core.clj:5866)
>> at clojure.core$load.doInvoke(core.clj:5865)
>> at clojure.lang.RestFn.invoke(RestFn.java:408)
>> at clojure.core$load_one.invoke(core.clj:5671)
>> at clojure.core$load_lib$fn__7808.invoke(core.clj:5711)
>> at clojure.core$load_lib.doInvoke(core.clj:5710)
>> at clojure.lang.RestFn.applyTo(RestFn.java:142)
>> at clojure.core$apply.invoke(core.clj:632)
>> ...
>> at
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:1069)
>> ... 32 more
>> Caused by: java.lang.RuntimeException: Unable to resolve symbol: init in
>> this context, compiling:(clojure/tools/reader/impl/ExceptionInfo.clj:1:1)
>> at clojure.lang.Compiler.analyze(Compiler.java:6543)
>> at clojure.lang.Compiler.analyze(Compiler.java:6485)
>> at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3791)
>> at clojure.lang.Compiler.analyzeSeq(Compiler.java:6725)
>> at clojure.lang.Compiler.analyze(Compiler.java:6524)
>> at clojure.lang.Compiler.analyze(Compiler.java:6485)
>> at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5861)
>> ...
>>
>> I'm not sure what's causing leiningen to omit the full stacktrace, but
>> it's possible you can get to it with *e from the repl, since you're doing a
>> dynamic require.
>>
>> In this case, we bumped up to 0.10.0 which no longer had the
>> ExceptionInfo class nor AOT issue.
>>
>> On Sun, Nov 8, 2015 at 2:10 PM James Elliott  wrote:
>>
>>> This weekend I was thrilled to have two people pick up and start
>>> experimenting with Afterglow, the live-coding light show software I’ve been
>>> working on this year, and both are new to Clojure as well. Unfortunately
>>> one is stuck and I am stumped about how to try to help: He’s been able to
>>> use Afterglow when running it from source, but when he tries including it
>>> as a library in a new Leiningen project, the attempt to require the
>>> examples namespace in the REPL, which is the first step in the walkthrough,
>>> fails in an utterly cryptic way:
>>>
>>>
>>> (require 'afterglow.examples)
>>>
>>> CompilerException java.lang.ExceptionInInitializerError, 
>>> compiling:(afterglow/examples.clj:1:1
>>>
>>> There is no stack trace shown, nor a root cause, and this leaves me
>>> baffled as to how to diagnose it. Starting a new project on my own system
>>> works fine. Is there a way we can try to load things in smaller pieces and
>>> see the underlying issues?
>>>
>>> I have suggested trying adding the :verbose flag in the require, and we
>>> will see if that helps any, but I am hoping for some other angles of attack
>>> too. The issue thread wh

Re: Cryptic crashes in Leiningen

[Gary Trakhman]

Just a guess, since your project has many dependencies, and I have little
time right now, but I had a recent issue with tools.reader <=0.9.2 and the
ExceptionInfo class.  The maven artifacts for tools.reader bundled .class
files, and triggered this bug: http://dev.clojure.org/jira/browse/CLJ-1639

Our stacktraces looked like this:
Caused by: java.lang.ExceptionInInitializerError
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at clojure.lang.RT.classForName(RT.java:2154)
at clojure.lang.RT.classForName(RT.java:2163)
at clojure.lang.RT.loadClassForName(RT.java:2182)
at clojure.lang.RT.load(RT.java:436)
at clojure.lang.RT.load(RT.java:412)
at clojure.core$load$fn__7859.invoke(core.clj:5866)
at clojure.core$load.doInvoke(core.clj:5865)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5671)
at clojure.core$load_lib$fn__7808.invoke(core.clj:5711)
at clojure.core$load_lib.doInvoke(core.clj:5710)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:632)
...
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:1069)
... 32 more
Caused by: java.lang.RuntimeException: Unable to resolve symbol: init in
this context, compiling:(clojure/tools/reader/impl/ExceptionInfo.clj:1:1)
at clojure.lang.Compiler.analyze(Compiler.java:6543)
at clojure.lang.Compiler.analyze(Compiler.java:6485)
at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3791)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6725)
at clojure.lang.Compiler.analyze(Compiler.java:6524)
at clojure.lang.Compiler.analyze(Compiler.java:6485)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5861)
...

I'm not sure what's causing leiningen to omit the full stacktrace, but it's
possible you can get to it with *e from the repl, since you're doing a
dynamic require.

In this case, we bumped up to 0.10.0 which no longer had the ExceptionInfo
class nor AOT issue.

On Sun, Nov 8, 2015 at 2:10 PM James Elliott  wrote:

> This weekend I was thrilled to have two people pick up and start
> experimenting with Afterglow, the live-coding light show software I’ve been
> working on this year, and both are new to Clojure as well. Unfortunately
> one is stuck and I am stumped about how to try to help: He’s been able to
> use Afterglow when running it from source, but when he tries including it
> as a library in a new Leiningen project, the attempt to require the
> examples namespace in the REPL, which is the first step in the walkthrough,
> fails in an utterly cryptic way:
>
>
> (require 'afterglow.examples)
>
> CompilerException java.lang.ExceptionInInitializerError, 
> compiling:(afterglow/examples.clj:1:1
>
> There is no stack trace shown, nor a root cause, and this leaves me
> baffled as to how to diagnose it. Starting a new project on my own system
> works fine. Is there a way we can try to load things in smaller pieces and
> see the underlying issues?
>
> I have suggested trying adding the :verbose flag in the require, and we
> will see if that helps any, but I am hoping for some other angles of attack
> too. The issue thread where we are working on this is here:
> https://github.com/brunchboy/afterglow/issues/7
>
> Thanks for any help you can offer me in helping fan these flames 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: is there a community "best practice" for including your co-workers libraries?

[Gary Trakhman]

I've used Nexus and Archiva, and I feel nexus is a better experience:
https://maven.apache.org/repository-management.html

There is a stopgap solution involving s3 that might be easier to set up:
https://github.com/technomancy/s3-wagon-private

On Fri, Oct 16, 2015 at 5:17 PM Lawrence Krubner 
wrote:

> I know this question has been asked before, but when I went searching I
> mostly found old entries that were on a somewhat different topic, such as
> "How to add a java library (that is not in maven) as a dependency for a
> clojure library?"
>
> I wrote a Clojure app and my co-worker wrote a Java app. I have another
> co-worker who is working on an app that would include the first 2 apps as
> libraries.
>
> I have been able to get the combination working using the Leiningen plugin
> "localrepo" but my co-worker wants me to make the other 2 libraries
> available from some central repo that Leiningen can download from. How is
> this usually done? Do I set up a Maven repo on one of the company servers?
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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.8.0-beta1

[Gary Trakhman]

Since upgrading our maven-based project, I'm seeing a new warning:
Reflection warning, clojure/pprint/pretty_writer.clj:419:12 - call to
method write can't be resolved (target class is unknown).

Once I connect with cider, I check *warn-on-reflection* and it is false.

On Tue, Oct 13, 2015 at 11:44 AM Lars Rune Nøstdal 
wrote:

> Just a heads up that http://dev.clojure.org/jira/browse/CLJ-1809 is still
> a problem. A lot of Clojure code fails to compile now. I hope this will be
> fixed before 1.8 final is out.
>
>
> On Tuesday, October 13, 2015 at 4:01:06 PM UTC+2, Alex Miller wrote:
>>
>> Clojure 1.8.0-beta1 is now available.
>>
>> Try it via
>>
>>- Download:
>>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-beta1
>>- Leiningen: [org.clojure/clojure "1.8.0-beta1"]
>>
>> Below is a list of the other changes included in beta1. See the full
>> change log here:
>> https://github.com/clojure/clojure/blob/master/changes.md.
>>
>>
>>- CLJ-1456  Compiler now
>>errors if too few or too many arguments to throw
>>- CLJ-1282  quote now
>>throws if passed more or less than one arg
>>- CLJ-1210  Improved
>>error message for (clojure.java.io/reader nil)
>>- CLJ-1414  sort and
>>sort-by now indicate sort is stable in docstring
>>- CLJ-1765  areduce
>>performance improvements
>>- CLJ-1724  Remove
>>unnecessary call to seq() in LazySeq.hashCode()
>>- CLJ-1295  Improved
>>array-map dissoc performance
>>- CLJ-1277  Speed up
>>printing of time instants with type hints
>>- CLJ-1259  Speed up
>>pprint and cl-format with type hints
>>- CLJ-668  Improve slurp
>>performance by using StringWriter and jio/copy
>>- CLJ-1810  ATransientMap
>>now marked public
>>- CLJ-1653  str of an
>>empty list should be "()"
>>- CLJ-1567  Removed
>>unused local in condp implementation
>>- CLJ-1351  Unused
>>swapThunk method was being emitted for fns with keyword callsites
>>- CLJ-1329  Removed
>>unused local in PersistentVector.cons()
>>- CLJ-1380  3-arg
>>ExceptionInfo constructor permitted nil data
>>- CLJ-1226  set! of a
>>deftype field using field-access syntax caused ClassCastException
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Gary Trakhman]

There are a lot of strategies to deal with the coupling of reuse.  I find
that using pure functions makes it easy to split off responsibilities after
the fact and add multiple entry points (the hard thing becomes naming those
functions).  Eventually a new 'essence' of the abstraction will show itself
and inspire a larger refactor.  That's something I really miss when doing
java.

Also, I feel that the reusable clojure code is always doing more work than
corresponding java code, so my frustration in refactoring is much greater
with java and its IDEs.  The refactorings are always superficial compared
to what I'm trying to express, and in clojure I can work with data
contracts easily.  I often end up writing a new version of the reusable
abstraction, writing adapters (just data transformations) from the old to
the new, then gutting the old implementation, then hopefully gutting the
adapters over time.  Clojure's data focus makes this easy.

On Fri, Oct 2, 2015 at 11:31 AM Colin Yates  wrote:

> It might just be me, but I also find the cost of the explicit coupling
> that is re-use is often far more expensive than any saving offered by
> re-use of a bunch of text. I also find this _more_ expensive in Clojure
> than Java as refactoring in Java was pretty robust (IntelliJ is incredibly
> powerful for this).
>
> On 2 Oct 2015, at 16:25, William la Forge  wrote:
>
> Refactoring for reuse is a kind of early optimization? Agreed! Generally
> for me it waits until the second or third rewrite, as by then I have a bit
> of an idea about where I am headed with the code.
>
> OTOH, I finally realized that when I don't know where I am going with
> something, keeping the logic in functions instead of methods is probably
> safest. I'm thinking now that methods should mostly just be used for their
> polymorphism as just a very thin layer over a set of interfaces.
>
> I was so impressed with the advantages of Java over C++ when I started
> using it 20 years ago. But now that I've been exposed to Clojure, I'm
> inclined to minimize my use of OO and use objects mostly as what I used
> before OO: dispatch tables!
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: 'seq' performance for 'empty?' compared to 'count'. And where's !=?

[Gary Trakhman]

Count is going to be slow for seqs or cons's, but I think a generalized
function could be implemented via protocol, falling back to seq.  Things
that extend
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Counted.java
are
going to have a fast 'count' method.

On Thu, Oct 1, 2015 at 6:40 PM Nathan Davis 
wrote:

> On Thursday, October 1, 2015 at 2:31:46 PM UTC-5, Dave Tenny wrote:
>>
>> So I understand that 'seq' is the idiomatic way to see if a
>> collection/sequence is empty.
>>
>>
> I'm not sure where you got this from.  I personally use empty? to check
> whether a collection is empty.  It is true that (not (empty c)) is not
> encouraged.  I believe the main rationale for this this is that (empty c)
> is (not (seq c)), so (not (empty c)) is (not (not (seq c)).
>
>
>> Logically I'm looking for an O(1) predicate with which I can determine if
>> a seq/collection is empty, and a well behaved
>> one that is idempotent and side effect free (for general performance
>> reasons).
>>
>
> I believe all the implementations of seq in Clojure core are O(1),
> although some (most?) allocate objects.  I'm not sure if it's explicitly
> spelled out anywhere, but I would consider it a bug it was anything other
> than O(1) (or perhaps O(log n) at most).
>
> In what ways is the current implementation of empty not well behaved and
> idempotent?
>
> With regards to side effects, if you can find a completely generic,
> side-effect-free way of determining whether a lazy sequence is empty
> without potentially realizing its head, please let the Clojure community
> know!
>
> I'm not saying having an explicit 'empty' method is a bad idea, but I'm
> not sure the current situation is as bad as you think.
>
>
> Nathan Davis
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: can I use varargs in a multimethod?

[Gary Trakhman]

It works for me, for '(intent {} "yes" :yes "WAT")'

I get the error: IllegalArgumentException No method in multimethod 'intent'
for dispatch value: WAT  clojure.lang.MultiFn.getFn (MultiFn.java:156)

You're probably being bitten by a different issue.  It's impossible to
redefine the dispatch function within the definition of the multimethod
after the first call to 'defmulti'.  In order to do so, you would have to
first ns-unmap that var.

An alternative for development is to use the dispatch function's Var as the
dispatch function:
(defn intent-dispatch [& args]
(apply discern args))
(defmulti intent #'intent-dispatch)


On Wed, Sep 30, 2015 at 8:33 PM Lawrence Krubner 
wrote:

> For maximum flexibility I wanted to use a multimethod, defined like this:
>
>
> (defmulti intent
>   (fn [& args]
> (apply discern args)))
>
> This is how discern is defined:
>
> (defn- discern
>
>   ([this-users-conversation]
>{:pre [(map? this-users-conversation)]}
>(:intent this-users-conversation))
>
>   ([this-users-conversation salesforce-object-name]
>{:pre [(map? this-users-conversation)
>   (string? salesforce-object-name)]}
>(:intent this-users-conversation))
>
>   ([this-users-conversation salesforce-object-name name-of-attribute]
>{:pre [(map? this-users-conversation)
>   (string? salesforce-object-name)
>   (string? name-of-attribute)]}
>(:intent this-users-conversation))
>
>   ([this-users-conversation salesforce-object-name name-of-attribute
> name-of-intent]
>{:pre [(map? this-users-conversation)
>   (string? salesforce-object-name)
>   (keyword? name-of-attribute)
>   (string? name-of-intent)]}
>name-of-intent))
>
> but then I call the multimethod like this:
>
> (intent this-users-conversation "Opportunity" :Name
> "query-salesforce-for-attribute")
>
> and I get:
>
> :class clojure.lang.ArityException,
> :message "Wrong number of args (4) passed to: query/fn--65",
>
> Should I give up on this idea, or is there a way to make this work?
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Gary Trakhman]

Here is another interesting read about how they solved it in immutant:
http://immutant.org/news/2012/05/18/runtime-isolation/

On Mon, Sep 28, 2015 at 6:54 PM Stephen Gilardi  wrote:

> I haven’t seen discussion of isolating some of the RT data structures
> while sharing others and the executable parts.
>
> In case you haven’t seen these, here are some references about isolated
> Clojure runtimes that may be helpful:
>
> https://github.com/boot-clj/boot and its “pods” facility:
> https://github.com/boot-clj/boot/tree/master/boot/pod which uses
> https://github.com/projectodd/shimdandy .
>
> More on pods: https://github.com/boot-clj/boot/wiki/Pods
>
> A presentation about boot (including pods):
> https://www.youtube.com/watch?v=TcnzB2tB-8Q .
>
> —Steve
>
> https://github.com/projectodd/shimdandy
>
> On Sep 28, 2015, at 6:08 PM, Georgi Danov  wrote:
>
> Hi,
>  I am integrating clojure into java micro container. It has hierarchical
> classloaders and can restart modules on the fly. It's almost REPL for Java
> :).
>
>  I have clojure running inside it, but even after reading some of the RT
> and Compiler classes source code I don't understand well enough how much
> state is accumulated where (theadLocals, static class fields/Vars,
> classloader, so on). Given that I don't want to have each module run
> different clojure version, I would prefer to have the basic things loaded
> once and shared.
>
>  I am also not sure what is shareable — I see the RT class has some static
> init functionality that appears to be safe for sharing the same clojure.jar
> classloader with all modules, but can't be sure.
>
>  Would be glad if there is article I have missed that outlines this.
>
> Thanks,
> Georgi
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Using metadata to specify how calls to a macro should be indented

[Gary Trakhman]

Sometimes more than 0% when I'm doing something small in clojurescript,
can't be bothered with the setup, and browser refresh is good enough :-).
On Tue, Sep 22, 2015 at 4:02 PM Fluid Dynamics  wrote:

> On Tuesday, September 22, 2015 at 6:31:34 AM UTC-4, Phillip Lord wrote:
>>
>> ... The interesting question then is what
>>
> percentage of the time do Clojure developers work *without* a repl
>> active.
>>
>
> Uhhh, zero? :)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: Beginning Clojure Development

[Gary Trakhman]

In my opinion the best book for the 'fine details' of the language is going
to be http://www.joyofclojure.com/  .  It's not usually recommended as the
introductory text, for that you might be better off with clojure
programming: http://www.clojurebook.com/ or 'programming clojure':
https://pragprog.com/book/shcloj2/programming-clojure , but there are also
great free online resources like:  http://www.braveclojure.com/

On Wed, Sep 9, 2015 at 12:44 PM Cory Gideon  wrote:

> Hi,
>
> I'm new to the Clojure programming language and I was wondering if anyone
> might be able to suggest a good way to learn the fine details of the
> Clojure language? I'm thinking of trying my hand at writing a compiler in
> Clojure, just as a thought exercise. I'm not 100% sure what a good use case
> for this language is yet to be honest, I'm primarily a .Net and PHP
> developer with a bit of Java experience but this language looked really
> interesting. If anyone knows of any good sites or books that I should check
> out I'd appreciate any suggestions.
>
> Thanks in advance!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: confusion about some paragraph in book "clojure programming" By Chas Emerick, Brian Carper, Christophe Grand 2012

[Gary Trakhman]

I am looking at the definition of fn and I can't see where let is used
inside the function definition:
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L4335

I think they're saying the binding forms are equivalent in power
(destructuring), not implementation.

On Wed, Jul 22, 2015 at 8:07 AM Johnny Wong  wrote:

> page 27(pdf version):
> "
>
> Local Bindings: let
>
>
> let allows you to define named references that are lexically scoped to
> the extent of the let expression. Said another way, let defines locals.
> ..
> ...
>
> Note that let is implicitly used anywhere locals are required. In
> particular, fn (and therefore all other function-creation and
> function-definition forms like defn) uses let to bind function parameters
> as locals within the scope of the function being defined. For example, x and
> y in the hypot function above are let-bound by defn. *So, the vector that
> defines the set of bindings for a let scope obeys the same semantics
> whether it is used to define function parameters or an auxiliary local
> binding scope.*
>
>
> *"*
>
>  i am confused about the text in red.  apparently ,the vector used  for
> let locale binding is not the same as the vector used for function
> parameters , for example
>
>
> (defn hypot
>
>   [x y]
>
> (let [x2 (* x x) y2 (* y y)]
>
>(Math/sqrt (+ x2 y2)))
>
> )
>
>
> the second line [x y] vector says the function has two parameter, it
> doesn't mean let x=y, while , the third line ,it means  let x2=(* x x), it
> is set value operation.
>
>
> is it a book error ?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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.7.0 is now available

[Gary Trakhman]

You'll have to bump instaparse versions:
https://github.com/clojure-emacs/refactor-nrepl/issues/53

On Tue, Jun 30, 2015 at 12:57 PM Robert Beaupre 
wrote:

> Is anyone else getting the following error with 1.7.0 when running lein
> repl?  All I did was change from 1.6.0 to 1.7.0.
>
> #error {
>
>  :cause Wrong number of args (2) passed to: StringReader
>  :via
>  [{:type clojure.lang.Compiler$CompilerException
>:message clojure.lang.ArityException: Wrong number of args (2) passed
> to: StringReader, compiling:(abnf.clj:189:28)
>:at [clojure.lang.Compiler$InvokeExpr eval Compiler.java 3628]}
>   {:type clojure.lang.ArityException
>:message Wrong number of args (2) passed to: StringReader
>:at [clojure.lang.AFn throwArity AFn.java 429]}]
>
> Thanks,
> Robert
>
> On Tuesday, 30 June 2015 07:35:34 UTC-7, Alex Miller wrote:
>>
>> We are pleased to announce the release of Clojure 1.7.
>>
>> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0/
>> - Leiningen: [org.clojure/clojure "1.7.0"]
>>
>> The two headline features for 1.7 are transducers and reader
>> conditionals. Also see the complete list (
>> https://github.com/clojure/clojure/blob/master/changes.md) of all
>> changes since Clojure 1.6 for more details.
>>
>> ## Transducers
>>
>> Transducers (http://clojure.org/transducers) are composable algorithmic
>> transformations. They are independent from the context of their input and
>> output sources and specify only the essence of the transformation in terms
>> of an individual element. Because transducers are decoupled from input or
>> output sources, they can be used in many different processes - collections,
>> streams, channels, observables, etc. Transducers compose directly, without
>> awareness of input or creation of intermediate aggregates.
>>
>> Many existing sequence functions now have a new arity (one fewer argument
>> than before). This arity will return a transducer that represents the same
>> logic but is independent of lazy sequence processing. Functions included
>> are: map, mapcat, filter, remove, take, take-while, drop, drop-while,
>> take-nth, replace, partition-by, partition-all, keep, keep-indexed,
>> map-indexed, distinct, and interpose. Additionally some new transducer
>> functions have been added: cat, dedupe, and random-sample.
>>
>> Transducers can be used in several new or existing contexts:
>>
>> * into - to collect the results of applying a transducer
>> * sequence - to incrementally compute the result of a transducer
>> * transduce - to immediately compute the result of a transducer
>> * eduction - to delay computation and recompute each time
>> * core.async - to apply a transducer while values traverse a channel
>>
>> ## Portable Clojure and Reader Conditionals
>>
>> It is now common to see a library or application targeting multiple
>> Clojure platforms with a single codebase. Clojure 1.7 introduces a new
>> extension (.cljc) for files that can be loaded by Clojure and ClojureScript
>> (and other Clojure platforms).
>>
>> There will often be some parts of the code that vary between platforms.
>> The primary mechanism for dealing with platform-specific code is to isolate
>> that code into a minimal set of namespaces and then provide
>> platform-specific versions (.clj/.class or .cljs) of those namespaces.
>>
>> To support cases where is not feasible to isolate the varying parts of
>> the code, or where the code is mostly portable with only small
>> platform-specific parts, 1.7 provides Reader Conditionals (
>> http://clojure.org/reader#The%20Reader--Reader%20Conditionals).
>>
>> Reader conditionals are a new reader form that is only allowed in
>> portable cljc files. A reader conditional expression is similar to a cond
>> in that it specifies alternating platform identifiers and expressions. Each
>> platform is checked in turn until a match is found and the expression is
>> read. All expressions not selected are read but skipped. A final :default
>> fallthrough can be provided. If no expressions are matched, the reader
>> conditional will read nothing. The reader conditional splicing form takes a
>> sequential expression and splices the result into the surrounding code.
>>
>> ## Contributors
>>
>> Thanks to all of those who contributed patches to Clojure 1.7:
>>
>> Timothy Baldridge
>> Bozhidar Batsov
>> Brandon Bloom
>> Michael Blume
>> Ambrose Bonnaire-Sergeant
>> Aaron Cohen
>> Pepijn de Vos
>> Andy Fingerhut
>> Gary Fredricks
>> Daniel Solano Gómez
>> Stuart Halloway
>> Immo Heikkinen
>> Andrei Kleschinsky
>> Howard Lewis Ship
>> Alex Miller
>> Steve Miner
>> Nicola Mometto
>> Tomasz Nurkiewicz
>> Ghadi Shayban
>> Paul Stadig
>> Zach Tellman
>> Luke VanderHart
>> Jozef Wagner
>> Devin Walters
>> Jason Wolfe
>> Steven Yi
>>
>> Also, continued thanks to the total list of contributors from all
>> releases:
>> http://clojure.org/contributing#patches
>>
>>
>> Thanks!
>> Alex Miller
>>
>  --
> You received this message because you are subscribed t