invokePrim seems to be the most common alternative calling convention.
I've worked around this myself for core.typed, basically generating a
deftype with the correct primitive invoke interfaces based on the :arglists
of the current var we're instrumenting.
I can prepare a patch if this approach i
instrument is going to have issues with any calling convention outisde
of the normal deref var + invoking path.
http://dev.clojure.org/jira/browse/CLJ-1941 is a similar case with some
discussion in the comments.
On 09/01/2016 11:33 AM, Ambrose Bonnaire-Sergeant wrote:
> Hi,
>
> There seems to be
Hi,
There seems to be some issues instrumenting functions that
compile to .invokePrim calls.
user=> (s/fdef blah :args (s/cat :foo int?) :ret any?)
user/blah
user=> (defn blah [^long a])
#'user/blah
user=> (st/instrument)
[clojure.core/symbol user/blah]
user=> (blah 1)
ClassCastException clojure
I have two questions about spec and ns. In clojure/core/specs.clj:
* both ::ns-require and ::prefix-list use s/cat.
* ::refer uses s/coll-of.
So both list and vector could be used, right?
i.e. the following ns declarations work in 1.9.0-alpha11:
* (ns n (:require [clojure.set :refer [map-
alias is not included and I have yet to find code using it in the wild.
That said, it exists in the gray area as well. If it becomes an issue
and/or Rich thinks it should be added, that could be done. I suspect that
if we have any changes related to aliasing non-existing namespaces (for
qualifi
On Saturday, August 20, 2016 at 2:32:29 AM UTC-5, Colin Fleming wrote:
>
> (ns ... (require ...) (import ...) ) instead of (ns ... (:require ...)
>> (:import ...) )
>
>
> Is this not intended to be allowed? The docstring implies no but it has
> always worked fine - I wouldn't call the code brok
I've used `:alias` to alias clojure.core in the past, I've seen it being
used in more than one project
On 20 Aug 2016 8:32 a.m., "Colin Fleming"
wrote:
> (ns ... (require ...) (import ...) ) instead of (ns ... (:require ...)
>> (:import ...) )
>
>
> Is this not intended to be allowed? The docst
>
> (ns ... (require ...) (import ...) ) instead of (ns ... (:require ...)
> (:import ...) )
Is this not intended to be allowed? The docstring implies no but it has
always worked fine - I wouldn't call the code broken.
Does the spec also limit the refs
to refer-clojure/require/use/import/load/g
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 wrote:
> system also depends on the latest released version of monger, which has an
> invalid defn in it (:or [ ] instead of :or { }) in monger
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 Mille
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://gith
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.to
The cljsbuild.crossover namespace has (import …) instead of (:import …) – file
a bug report against that project so the maintainer can update it to be
compatible with Clojure 1.9.0.
The error message says In: [3 0] so you can see it is the 0th element of the
item with index 3 in the ns form tha
Great - thanks Alex! All the efforts around clojure.spec will definitely
bring consistency in the world of Clojure codebases : )
On Friday, August 19, 2016 at 9:05:16 PM UTC-7, Alex Miller wrote:
>
> That looks like a bug in lein-cljsbuild. cljsbuild/crossover.clj is
> failing due to (import jav
That looks like a bug in lein-cljsbuild. cljsbuild/crossover.clj is failing
due to (import java.io.File java.net.URLDecoder) - should be (:import
java.io.File java.net.URLDecoder).
PR filed here: https://github.com/emezeske/lein-cljsbuild/pull/447
On Friday, August 19, 2016 at 9:55:17 PM UTC-
Ran into this problem with ClojureScript/ReactNative/Re-natal project:
Compiling ClojureScript...
Exception in thread "main" java.lang.IllegalArgumentException: Call to
clojure.core/ns did not conform to spec:
In: [3 0] val: import fails spec: :clojure.core.specs/ns-refer-clojure at:
[:args :c
I saw your PR for io.aviso/pretty ... thanks!
I can't imagine how much work it must be to track all of those things down
...
On Friday, 19 August 2016 11:35:31 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 (br
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.
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.co
19 matches
Mail list logo
