>
> (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
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
Yesterday, a bug was filed against Suchwow under 1.9alpha11. It turns out to
have been a use of `ns …(require…` instead of `(ns …(:require`. Not in Suchwow,
but in Midje. Unfortunately, the Suchwow file the bug report pointed at *also*
had that typo - apparently I am prone to it - so adding the
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
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 5:17:59 AM UTC-5, Brian Marick wrote:
>
> Yesterday, a bug was filed against Suchwow under 1.9alpha11. It turns out
> to have been a use of `ns …(require…` instead of `(ns …(:require`. Not in
> Suchwow, but in Midje. Unfortunately, the Suchwow file the bug report
> On Aug 20, 2016, at 9:03 AM, Alex Miller wrote:
>
> You left out this next important line too since it points you to exactly the
> file and line where the error occurs:
>
> , compiling:(such/sequences.clj:1:1)
This is interesting. Here’s why I missed it. I attach the error message I saw
f
> On Aug 20, 2016, at 9:03 AM, Alex Miller wrote:
>
> We discussed this before releasing the specs and decided to start on the
> strict side. That said, this is still an alpha and there is plenty of time to
> change our minds prior to official release of 1.9 if that ends up being a
> catastro
Hello,
I am trying to generate lot of files using futures but it hasn't sped up
the process that hoped for. Here is the code I am using. Can someone point
what I am doing wrong?
(ns jsonworker.core
(:require [cheshire.core :refer :all ]))
(defn parse-json
[file-loc]
(parse-stream (cloju
I think you should move the future inside do times, since then you’ll get a
future for each write.
Also, I don’t think you need to put your json-template in an atom:
(ns jsonworker.foo
(:require [cheshire.core :refer :all ]))
(defn parse-json
[file-loc]
(parse-stream (clojure.java.io/read
On Saturday, August 20, 2016 at 9:40:21 AM UTC-5, Brian Marick wrote:
>
>
> On Aug 20, 2016, at 9:03 AM, Alex Miller wrote:
>
> You left out this next important line too since it points you to exactly
> the file and line where the error occurs:
>
> , compiling:(such/sequences.clj:1:1)
>
>
> Th
On Saturday, August 20, 2016 at 9:58:14 AM UTC-5, Brian Marick wrote:
>
>
> On Aug 20, 2016, at 9:03 AM, Alex Miller wrote:
>
> We discussed this before releasing the specs and decided to start on the
> strict side. That said, this is still an alpha and there is plenty of time
> to change our
The future is XML-with-namespaces: POM files and whatnot. Such cases are
tricky because more than one notation is possible. You need a
namespace-enabled parser to figure out what the XML text really means.
Luckily, a contributed project, clojure.data.xml, can read
XML-with-namespaces, and in
I disagree (strongly) with your position here Brian. I’ll try to explain
clearly why but first a little background…
At World Singles, we’ve always done multi-version testing against the stable
version of Clojure that we plan to use in production and also against the very
latest master SNAPSHOT.
As a side note to this conversation, I hit this (require) vs (:require)
thing almost a year ago when porting a file to CLJS. ClojureScript has been
enforcing these keyword regulations for some time, as well as only allowing
a single :require, not allowing anything but :require, :use, etc.
On Sat,
> On Aug 20, 2016, at 5:26 PM, s...@corfield.org wrote:
>
> I disagree (strongly) with your position here Brian. I’ll try to explain
> clearly why but first a little background…
I too have felt the pain of having to maintain backward compatibility. However,
I’m reminded, in this case, of Mark
Brian, let's make it more concrete then...why should the Clojure compiler
continue to support undocumented features that make code unportable?
On Sat, Aug 20, 2016 at 4:48 PM, Brian Marick
wrote:
>
> On Aug 20, 2016, at 5:26 PM, s...@corfield.org wrote:
>
> I disagree (strongly) with your posi
> On Aug 20, 2016, at 6:30 PM, Timothy Baldridge wrote:
>
> Brian, let's make it more concrete then...why should the Clojure compiler
> continue to support undocumented features that make code unportable?
Because:
1. People who want to port to clojurescript will incur exactly the same cost
With respect to preserving undocumented behaviour, while in general I'm in
favour of making compilers stricter, in this case it seems like the change
breaks a lot of existing code in ways that are impossible for library
consumers to fix themselves - they have to wait for an update to the
library, o
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-
I think there's considerable scope to produce better error messages
automatically than what spec produces, and I hope that can happen for 1.9.
The error message produced by the code I demoed at the conj last year would
be:
Unexpected symbol 'require' at while parsing
namespace clauses. Expected :
What about a compromise where you could opt-in or opt-out of checking macro
specs at compile time (via a compiler option)? It seems worth preserving
the correctness of the spec, without forcing all of the breakage.
Andrew Oberstar
On Sat, Aug 20, 2016 at 9:13 PM Colin Fleming
wrote:
> With resp
On 8/20/16, 7:13 PM, "Colin Fleming" wrote:
> in this case it seems like the change breaks a lot of existing code
I disagree. Compared to the vast amount of Clojure code out there, I would
contend that this breaks very little code – and that code is arguably wrong in
the first place. Most of th
Or keep the stricter compiler and:
1. People who want to port to clojurescript will incur exactly the same cost as
they do now.
**2. People who don’t want to port to clojurescript and don’t want to move to
Clojure 1.9 will incur no additional cost.
3. Clojurescript maintainers will incur no a
I'd prefer getting rid of the symbol option. Some kind of deprecation
warning for a version or two might be an idea though.
On Sat, Aug 20, 2016, 10:51 PM Sean Corfield wrote:
> Or keep the stricter compiler and:
>
> 1. People who want to port to clojurescript will incur exactly the same
> cost
I started programming with Racket 2 years ago and i decided i want to use a
Lisp with more libraries at my disposal. So i have made some headway into
Clojure and am familiar with core functions like map, reduce, filter, loop,
for, doseq, some, every?, apply. I make use of macros like ->, ->>, ..
I couldn't help myself...
https://xkcd.com/1172/
--
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.
27 matches
Mail list logo
