Re: [ClojureScript] Re: ANN: ClojureScript 1.9.198 - cljs.spec, core ns aliasing, macro inference, :rename, and more!

[David Nolen]

Thanks for the report. This has already been fixed in master and I'll cut
another release on Monday which include this and several other fixes.

On Sat, Aug 13, 2016 at 9:42 AM, yong gou  wrote:

> sorry my English is poor, but need help, thanks ^_^
> after updated to 1.9.189 , I wrote this:
> (require '[cljs.spec :as s])
> (s/def ::a1 int?)
> (s/def ::a2 int?)
> (s/def ::all (s/merge (s/keys :opt-un [::a1]) (s/keys :opt-un [::a2])))
>
> I got:
> clojure.lang.ExceptionInfo: Wrong number of args (-1) passed to: spec/res
> at line 1  {:file "", :line 1, :column 14,
> :root-source-info {:source-type :fragment, :source-form (s/def
> :cljs.user/all (s/merge (s/keys :opt-un [:cljs.user/a1]) (s/keys :opt-un
> [:cljs.user/a2])))}, :tag :cljs/analysis-error}
> at clojure.core$ex_info.invokeStatic(core.clj:4617)
> at clojure.core$ex_info.invoke(core.clj:4617)
> at cljs.analyzer$error.invokeStatic(analyzer.cljc:620)
> at cljs.analyzer$error.invoke(analyzer.cljc:616)
> at cljs.analyzer$macroexpand_1.invokeStatic(analyzer.cljc:2688)
> at cljs.analyzer$macroexpand_1.invoke(analyzer.cljc:2684)
> at cljs.analyzer$analyze_seq.invokeStatic(analyzer.cljc:2718)
> at cljs.analyzer$analyze_seq.invoke(analyzer.cljc:2701)
> at cljs.analyzer$analyze_form.invokeStatic(analyzer.cljc:2838)
> at cljs.analyzer$analyze_form.invoke(analyzer.cljc:2834)
> at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:2885)
> at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2876)
> at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2901)
> at cljs.analyzer$analyze.invoke(analyzer.cljc:2888)
> at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2896)
> at cljs.analyzer$analyze.invoke(analyzer.cljc:2888)
> at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2895)
> at cljs.analyzer$analyze.invoke(analyzer.cljc:2888)
> at cljs.analyzer$parse_invoke_STAR_$ana_expr__3134.invoke(
> analyzer.cljc:2520)
> at clojure.core$map$fn__4785.invoke(core.clj:2646)
> at clojure.lang.LazySeq.sval(LazySeq.java:40)
> at clojure.lang.LazySeq.seq(LazySeq.java:49)
> at clojure.lang.Cons.next(Cons.java:39)
> at clojure.lang.PersistentVector.create(PersistentVector.java:73)
> at clojure.lang.LazilyPersistentVector.create(
> LazilyPersistentVector.java:44)
> at clojure.core$vec.invokeStatic(core.clj:377)
> at clojure.core$vec.invoke(core.clj:367)
> at cljs.analyzer$parse_invoke_STAR_.invokeStatic(analyzer.
> cljc:2522)
> at cljs.analyzer$parse_invoke_STAR_.invoke(analyzer.cljc:2493)
> at cljs.analyzer$parse_invoke.invokeStatic(analyzer.cljc:2531)
> at cljs.analyzer$parse_invoke.invoke(analyzer.cljc:2529)
> at cljs.analyzer$analyze_seq_STAR_.invokeStatic(analyzer.
> cljc:2695)
> at cljs.analyzer$analyze_seq_STAR_.invoke(analyzer.cljc:2692)
> at cljs.analyzer$analyze_seq_STAR__wrap.invokeStatic(
> analyzer.cljc:2699)
> at cljs.analyzer$analyze_seq_STAR__wrap.invoke(analyzer.cljc:2697)
> at cljs.analyzer$analyze_seq.invokeStatic(analyzer.cljc:2720)
> at cljs.analyzer$analyze_seq.invoke(analyzer.cljc:2701)
> at cljs.analyzer$analyze_form.invokeStatic(analyzer.cljc:2838)
> at cljs.analyzer$analyze_form.invoke(analyzer.cljc:2834)
> at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:2885)
> at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2876)
> at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2901)
> at cljs.analyzer$analyze.invoke(analyzer.cljc:2888)
> at cljs.analyzer$analyze_seq.invokeStatic(analyzer.cljc:2721)
> at cljs.analyzer$analyze_seq.invoke(analyzer.cljc:2701)
> at cljs.analyzer$analyze_form.invokeStatic(analyzer.cljc:2838)
> at cljs.analyzer$analyze_form.invoke(analyzer.cljc:2834)
> at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:2885)
> at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2876)
> at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2901)
> at cljs.analyzer$analyze.invoke(analyzer.cljc:2888)
> at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2896)
> at cljs.analyzer$analyze.invoke(analyzer.cljc:2888)
> at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2895)
> at cljs.analyzer$analyze.invoke(analyzer.cljc:2888)
> at cljs.analyzer$analyze_let_binding_init.invokeStatic(
> analyzer.cljc:1496)
> at cljs.analyzer$analyze_let_binding_init.invoke(analyzer.
> cljc:1494)
> at cljs.analyzer$analyze_let_bindings_STAR_.invokeStatic(
> analyzer.cljc:1518)
> at cljs.analyzer$analyze_let_bindings_STAR_.invoke(
> analyzer.cljc:1507)
> at cljs.analyzer$analyze_let_bindings.invokeStatic(
> analyzer.cljc:1549)
> at 

Re: Multiple key-value pairs in assoc-in (old issue)

[Andy Fingerhut]

That ticket is in a state called "Triaged", which means that a screener
(most likely Alex Miller) thinks the issue is good enough for Rich Hickey
to take a look at it some time.  Rich probably hasn't looked at it yet,
because if he had, it would have likely been changed to Declined or Vetted.

As far as expectations go, there are enough other things being worked on
for Clojure 1.9 that I would not bet any money this ticket will make it in
to that version.  Disclaimer: I am only an observer in this, not a
decision-maker.

Andy

On Sat, Aug 13, 2016 at 4:18 AM, Łukasz Kożuchowski <
lukasz.kozuchow...@gmail.com> wrote:

> Hello,
>
> Currently assoc-in does not support multiple key-value pairs the way assoc
> does.
>
> user=> (assoc {} :a 1 :b 2)
> {:b 2, :a 1}
> user=> (assoc-in {} [:a :b] 1 [:c :d] 2)
> ArityException Wrong number of args (5) passed to: core$assoc-in
> clojure.lang.AFn.throwArity (AFn.java:437)
>
> It appears a patch for this has been ready for more than a year:
> http://dev.clojure.org/jira/browse/CLJ-1771
>
> Can we expect this to work soon?
>
> --
>   Łukasz Kożuchowski
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group 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: grouping and mapping

[Simon Belak]

Another option (and shameless self promotion) is the rollup family of 
functions in https://github.com/sbelak/huri

Your case would be:

(rollup first identity second foos)
=> {:a ("foo" "baz"), :b ("bar")}


On Friday, August 12, 2016 at 7:10:37 PM UTC+2, Erik Assum wrote:
>
> I’ve been working on a new project in java 8 at a new client where I’ve 
> been able to play with streams. 
> In doing so I’ve come across Collectors.groupingBy which has some 
> additional features that group-by doesn’t seem to have. 
>
> Example: 
> Given 
> (def foos [[:a "foo"]  [:b "bar"]  [:a "baz"]]) 
>
> (group-by first foos) 
> ;=> {:a [[:a "foo"] [:a "baz"]], :b [[:b "bar"]]} 
>
> but I’d like the result to be 
> ;=> {:a ["FOO" "BAZ"] :b ["BAR”]} 
>
> This is solved in javas stream api by something like this: 
>
> List = [["a", "foo"], ["b" "bar"], ["a", "baz"]]; 
>
> foos 
> .stream() 
> .collect(Collectors.groupingBy(e -> e.get(0), 
>  Collectors.mapping(e -> e.get(1).toUpperCase(), 
> Collectors.toList(; 
>
> Where the key point is that Collectors.groupingBy accepts a mapping 
> function in which to map the values being grouped. 
>
> So how would one go about writing this in Clojure? I could of-course write 
> something that mapped over the grouped map, 
> but I’d really like to write something like 
>
> (defn mapping-group-by grouping-fn mapping-fn coll) 
>
> but I have a suspicion that this already exists in some form already? 
>
> Erik. 

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

Multiple key-value pairs in assoc-in (old issue)

[Łukasz Kożuchowski]

Hello,

Currently assoc-in does not support multiple key-value pairs the way 
assoc does.


user=> (assoc {} :a 1 :b 2)
{:b 2, :a 1}
user=> (assoc-in {} [:a :b] 1 [:c :d] 2)
ArityException Wrong number of args (5) passed to: core$assoc-in 
clojure.lang.AFn.throwArity (AFn.java:437)


It appears a patch for this has been ready for more than a year:
http://dev.clojure.org/jira/browse/CLJ-1771

Can we expect this to work soon?

--
  Łukasz Kożuchowski

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: ClojureScript 1.9.198 - cljs.spec, core ns aliasing, macro inference, :rename, and more!

[Zubair Quraishi]

I don't know what you did but upgrading from cljs .89 to .198 on a fairly 
largish app and it seems to run over twice as fast Welldone, whatever it 
was that did it!!! :)


On Friday, August 12, 2016 at 9:50:20 PM UTC+2, David Nolen wrote:
> ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> 
> README and source code: https://github.com/clojure/clojurescript
> 
> 
> Leiningen dependency information:
> 
> 
>     [org.clojure/clojurescript "1.9.198"]
> 
> 
> This release brings cljs.spec to parity with Clojure
> 1.9.0-alpha10. This release also includes a large number of
> enhancements to the ns form:
> 
> 
> * :refer now features macro inference. There is no longer any need
>   to supply both :refer and :refer-macros in the same :require, the
>   compiler will figure it out.
> 
> 
> * clojure.* namespaces will now automatically be aliased to their
>   ClojureScript equivalents. For example this means that the following
>   is perfectly valid ClojureScript:
> 
> 
>   (ns foo.bar
>     (:require [clojure.spec :refer [fspec]]))
> 
> 
>   This feature and the previous one should significantly reduce reader
>   conditional usage in ns forms.
> 
> 
> * thanks to Antonio Monteiro we now support :rename
> 
> 
> We also have a new feature that is relevant for tooling such as
> Figwheel and cljs-devtools - :preloads. This should now be the
> standard way to inject some bit of side-effecting setup after core but
> before user code (i.e. connecting REPLs to standard ports, etc.).
> 
> 
> There are of course many various small fixes and enhancements, so
> a very big thank you to everyone that has contributed.
> 
> 
> As always feedback welcome!
> 
> 
> ## 1.9.198
> 
> 
> ### Enhancements
> * CLJS-1508: Extend ns form to support :rename option
> * CLJS-1507: Implicit macro loading: macro var inference in :refer
> * CLJS-1692: Autoalias clojure.* to exisiting cljs.* namespaces if
> possible
> * CLJS-1350: Compiler support for browser REPL
> * CLJS-1729: Support `use` special function in REPLs
> * CLJS-1730: Support `refer-clojure` special function in REPLs
> 
> 
> ### Changes
> * CLJS-1515: Self-host: Allow :file key in cljs.js/*load-fn*
> * add toString implementation to Vars
> * Use a js array to create collections in cljs.reader
> * CLJS-1640: Use the unshaded version of the closure compiler
> * add :browser-repl to list of known opts
> * add browser REPL preload
> * parity with Clojure 1.9.0-alpha10 clojure.spec
> * bump to tools.reader 1.0.0-beta3
> 
> 
> ### Fixes
> * CLJS-1733: Macro inference issue for macros & runtime vars with the same 
> name
> * CLJS-1735: Self-host: cljs.spec speced-vars instance
> * CLJS-1736: cljs.spec.test: checkable-syms* called with 0-arity
> * CLJS-1708: Self-host: [iu]nstrument-1 needs to qualify [iu]nstrument-1*
> * CLJS-1707: Self-host: with-instrument-disabled needs to qualify 
> *instrument-enabled*
> * CLJS-1732: Add docstrings for new use and use-macros REPL specials
> * CLJS-1720: Qualify symbols and namespaced keywords in spec macros
> * CLJS-1731: Self-host: do_template problem with script/test-self-parity
> * CLJS-1556: Invalid code emit for obj literal
> * CLJS-1607: bug with `specify!` in JS prototypes with `static-fns` true
> * CLJS-1591 avoid analyzing invoke arguments multiple times
> * CLJS-1638: :elide-asserts disables atom validators in :advanced
> * CLJS-1721: 3-arity get-in fails on types which do not implement ILookup
> * CLJS-1728: Update doc for ns for new :rename capability
> * CLJS-1727: Regression when evaluating non-sequential forms at the REPL
> * CLJS-1490: Watch macro files in cljs.build.api/watch
> * CLJS-1719: Port destructuring namespaced keys and symbols
> * CLJS-1653: cljs.spec: keys* causes exception
> * CLJS-1700: Support clojure.* aliasing when not in vector
> * CLJS-1717 remove map from equiv-map
> * CLJS-1716: No longer possible to use same alias for :require-macros and 
> :require
> * Use keyword options in js->clj 1-arg impl
> * Add support for regex in transit for compiler analysis cache
> * Escape non-Latin1 characters before base64 encoding the source-map string
> * CLJS-1698: cljs.spec: every res call needs 
> * CLJS-1695: Self-host: Port cljs / clojure namespace aliasing
> * CLJS-1697: doc on inferred macros fails
> * CLJS-1699: Update docstring for ns
> * CLJS-1694: Self-host: Port macro var inference in :refer

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

Re: Digest for clojure@googlegroups.com - 17 updates in 6 topics

[Han Tuzun]

On Tue, Aug 9, 2016 at 02:29  wrote:

> clojure@googlegroups.com
> 
>  Google
> Groups
> 
> 
> Topic digest
> View all topics
> 
>
>- Using a function to def other functions?
><#m_5766536650690988793_group_thread_0> - 8 Updates
>- How to do functional programming
><#m_5766536650690988793_group_thread_1> - 2 Updates
>- [JOB] Software Engineer at Xledger in Colorado Springs, CO
><#m_5766536650690988793_group_thread_2> - 1 Update
>- Keep application running when main thread only starts go blocks
><#m_5766536650690988793_group_thread_3> - 3 Updates
>- ANN: diehard 0.3.0 <#m_5766536650690988793_group_thread_4> - 2
>Updates
>- ANN: system 0.3.1 <#m_5766536650690988793_group_thread_5> - 1 Update
>
> Using a function to def other functions?
> 
> fah...@gmail.com: Aug 08 11:52AM -0700
>
> user> (macroexpand-1 '(defn foo [x] (inc x)))
> (def foo (clojure.core/fn ([x] (inc x
>
> If defn is just a macro, then it seems I can do this:
>
> user> (defn bar [] (fn ([x] (inc x
> #'user/bar
>
> user> (def foo (bar))
> #'user/foo
>
> user> foo
> #function[user/bar/fn--10778]
>
> But the result is a little different than doing it directly with defn:
>
> user> (defn foo [x] (inc x))
> #'user/foo
>
> We had #'user/*bar/fn--10778* vs #'user/foo. But either way, foo is bound
> to something.
>
> Is the difference significant? It seems like it is because I tried
> something similar in my project and got the following:
>
> IllegalStateException Attempting to call unbound fn: #'p.core/default-step
> clojure.lang.Var$Unbound.throwArity (Var.java:43)
> p.core> default-step
> #function[p.core/make-step/fn--10747]
>
> Function default-step was def'd using make-step which returned a function
> and default-step is bound, so why does the repl say it is not?
>
> (defn make-step [some-args]
> (fn ([other-args]
> (some-body using-both-args
>
> Basically I need to define a bunch of similar functions and am trying to
> use another function to help define them (instead of using a macro). But
> it
> seems I'm doing something wrong...
> adrian.med...@mail.yu.edu: Aug 08 01:14PM -0700
>
> Using defining macros as non top-level forms may not be forbidden by the
> language but its use is generally discouraged.
> See http://clhs.lisp.se/Issues/iss104_w.htm for a discussion about this
> issue in Common Lisp for some background context. In short, compile time
> effects may not be captured whenever you use defining macros as non
> top-level forms. I think you're seeing something like this manifest here.
> In this case, since you referenced a var which was not installed when the
> compiler reaches the calling code, the compiler will throw this error
> message. I would suggest rethinking this because the solution is ugly, but
> you should use something like clojure.core/resolve or
> clojure.core/ns-resolve to resolve the var dynamically and then funcall
> it.
>
> fah...@gmail.com: Aug 08 02:19PM -0700
>
> Oh... 'bar' and 'make-step' count as macros? My intent was that they're
> ordinary functions that return functions. Am I mistaken? Or does the issue
> you referred to apply to using defining *functions and macros *as
> non-top-level forms?
>
> (defn bar [] (fn ([x] (inc x
>
> (defn make-step [some-args]
> (fn ([other-args]
> (some-body using-both-args
> adrian.med...@mail.yu.edu: Aug 08 02:30PM -0700
>
> defn, def, etc are what I mean by "defining macros".
>
> adrian.med...@mail.yu.edu: Aug 08 02:31PM -0700
>
> def isn't a good example actually because it's a special form. But the
> same
> principle applies when using it as a non-top level form.
>
> Gregg Reynolds : Aug 08 04:32PM -0500
>
>
> > user> (defn foo [x] (inc x))
> > #'user/foo
>
> > We had #'user/bar/fn--10778 vs #'user/foo. But either way, foo is bound
> to something.
>
> > Is the difference significant? It seems like it is because I tried
> something similar in my project and got the following:
>
> > IllegalStateException Attempting to call unbound fn:
> #'p.core/default-step clojure.lang.Var$Unbound.throwArity (Var.java:43)
> > p.core> default-step
> > #function[p.core/make-step/fn--10747]
>
> > Function default-step was def'd using make-step which returned a function
> and default-step is bound, so why does the repl say it is not?
> > (fn ([other-args]
> > (some-body using-both-args
>
> > Basically I need to define a bunch of similar functions and am trying to
> use another function to help define them (instead of using a macro). But it
> seems I'm doing something