system also depends on the latest released version of monger, which has an
invalid defn in it (:or [ ] instead of :or { }) in monger.core. afaict,
this problem has been fixed in master of monger, but no new version is
available yet.
On Saturday, August 20, 2016 at 12:15:08 AM UTC-5, Alex Miller wrote:
>
> Those are bugs in system. When you see "(system.repl (require
> [com.stuartsierra.component :as component] ..." those are the arguments to
> the ns form, so the "system.repl" is the namespace name. You cut out the
> stack trace, but I'd expect the top frame to be in that ns.
>
> PRs filed at https://github.com/danielsz/system/pull/93 and
> https://github.com/danielsz/system/pull/94 (found two problems)
>
> All Clojure code is compiled. Some is compiled early (during AOT) but most
> is compiled late (during load). At the point where you loaded these
> namespaces, they were compiled to be invoked and you triggered the errors.
>
> Alex
>
> On Saturday, August 20, 2016 at 12:01:55 AM UTC-5, Alan Moore wrote:
>>
>> All,
>>
>> Is anyone else experiencing problems using danielz/system and/or
>> stuartsierra/component? I'm getting the following:
>>
>> Caused by: java.lang.IllegalArgumentException: Call to clojure.core/ns
>> did not conform to spec:
>> In: [1] val: ((require [com.stuartsierra.component :as component]
>> [clojure.tools.namespace.track :as track] [system.reload :as reload]
>> [clojure.stacktrace :as st] [io.aviso.ansi :refer [bold-red bold-yellow]]))
>> fails at: [:args] predicate: (cat :docstring (? string?) :attr-map (? map?)
>> :clauses :clojure.core.specs/ns-clauses), Extra input
>> :clojure.spec/args (system.repl (require [com.stuartsierra.component :as
>> component] [clojure.tools.namespace.track :as track] [system.reload :as
>> reload] [clojure.stacktrace :as st] [io.aviso.ansi :refer [bold-red
>> bold-yellow]]))
>>
>> I noticed Alex's PR for aviso but I'm not using it explicitly - it must
>> be coming in transiently but I don't think that is the problem:
>>
>> I can see the use of (require ...) in the implicated ns-form, here:
>>
>> (system.repl (require [com.stuartsierra.component :as component] ...
>>
>> but I searched my project for any "(require" and didn't find any.
>>
>> There must be some macro or namespace magic happening in either of those
>> two libraries. I've been searching them for any use of (require ...) vs
>> (:require ...) and only found a couple in danielz/system, here:
>>
>> src/system/reload.clj
>> src/system/repl.clj
>>
>> but I'm not exactly sure how those would cause my error. The second one
>> looks like it is related.
>>
>> Alex - does a previously compiled library, like system, pulled from
>> clojars uses "(require" be subject to the spec conformance? How much of the
>> ns-form is resolved at compile time and how much happens at runtime?
>>
>> Clearly I've not done my deep-dive homework on that form (yet) and how it
>> works... I know those two libraries do a bit of namespace manipulation to
>> deal with reloading repls and whatnot so it very well could be something
>> they are doing that is beyond my current understanding and pay grade.
>>
>> Alan
>>
>>
>> On Friday, August 19, 2016 at 11:35:31 AM UTC-7, Alex Miller wrote:
>>>
>>> One thing to note is that the new specs for clojure.core means that
>>> there is a reasonable amount of (broken) code in the wild that now does not
>>> compile.
>>>
>>> I have filed PRs in a number of commonly used projects and while those
>>> were all merged, most have not yet been released into new versions yet. Any
>>> project that uses any of those projects via dependencies will also have
>>> issues. So, expect to see some breakage if using the latest alpha. In
>>> particular, ClojureScript itself had a bad ns declaration through version
>>> 1.9.93 so anything not on a fresh CLJS will likely see that.
>>>
>>> The three most common things I saw were:
>>>
>>> 1. (ns ... (require ...) (import ...) ) instead of (ns ... (:require
>>> ...) (:import ...) )
>>>
>>> 2. (fn a.b [] ...) - fully-qualified symbol names in fn (these are
>>> pretty much always the result of a sloppy macro that expands to fn)
>>>
>>> 3. (let [{ ... :or {:a 1}} {}] ... ) - :or keys that are not simple
>>> symbols. There were some accidental cases where this did something for
>>> fully-qualified keyword keys in the past, but those were not intended and
>>> are no longer accepted as of Clojure 1.9.0-alpha8. All of the cases I found
>>> were actually typos though where the keyword was used instead of the symbol.
>>>
>>>
>>>
>>>
>>> On Friday, August 19, 2016 at 1:15:06 PM UTC-5, Alex Miller wrote:
>>>>
>>>> Clojure 1.9.0-alpha11 is now available.
>>>>
>>>> Try it via
>>>>
>>>> - Download:
>>>> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha11
>>>> - Leiningen: [org.clojure/clojure "1.9.0-alpha11"]
>>>>
>>>> 1.9.0-alpha11 includes the following changes since 1.9.0-alpha10:
>>>>
>>>> Clojure now has specs for the following clojure.core macros: let,
>>>> if-let, when-let, defn, defn-, fn, and ns. Because macro specs are checked
>>>> during macroexpansion invalid syntax in these macros will now fail at
>>>> compile time whereas some errors were caught at runtime and some were not
>>>> caught at all.
>>>>
>>>> - CLJ-1914 - Fixed race condition in concurrent range realization
>>>> - CLJ-1870 - Fixed reloading a defmulti removes metadata on the var
>>>> - CLJ-1744 - Clear unused locals, which can prevent memory leaks in
>>>> some cases
>>>> - CLJ-1423 - Allow vars to be invoked with infinite arglists (also,
>>>> faster)
>>>> - CLJ-1993 - Added *print-namespace-maps* dynamic var that controls
>>>> whether to use namespace map syntax for maps with keys from the same
>>>> namespace. The default is false, but standard REPL bindings set this to
>>>> true.
>>>> - CLJ-1985 - Fixed with-gen of conformer losing unform fn
>>>> - Fixed clojure.spec.test/check to skip spec'ed macros
>>>> - Fixed regression from 1.9.0-alpha8 where type hints within
>>>> destructuring were lost
>>>> - Fixed clojure.spec/merge docstring to note merge doesn't flow
>>>> conformed values
>>>> - Fixed regex ops to use gen overrides if they are used
>>>>
>>>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
