That is what I figured/suspected but wasn't sure. Thanks for filing those
pull requests so quickly!
Alan
On Fri, Aug 19, 2016 at 10:32 PM, Alex Miller <a...@puredanger.com> wrote:
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/_slHTn-Ej1Y/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
--
*"Whatever you can do, or dream you can do, begin it. Boldness has genius,
power, and magic in it. Begin it now."* - *Goethe*
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
