ClojureScreencasts.com domain
Hi, would anyone in the Clojure community be interested in purchasing the ClojureScreencasts.com domain? I had created a lot of introductory videos a few years ago, but the site has been idle. Maybe someone else in the community would like to do something useful with that domain? Thanks, Jim -- 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.
ClojureScreencasts.com domain
How much is it for? -- 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: partition & fold
Hi Brian, I think what you’re searching for is: (require ‘[clojure.core.reducers :as r]) (r/fold concat ((comp (partition-all 5) (map #(apply + %))) conj) (into [] (range 1000))) However, the result of the above is undetermined (results are different every time you call). This is because you have a stateful transducer in the mix, which is not parallelizable with fold. One option is to use this lib https://github.com/reborg/parallel#pfold-pxrf-and-pfolder (I’m the author) and write: (require ‘[parallel.core :as p]) (p/fold concat (p/xrf conj (partition-all 5) (map #(apply + %))) (into [] (range 1000))) Which does what you expect in parallel and consistently. More info about your attempt below. > On 26 Jan 2019, at 23:03, Brian Craft wrote: > > Still trying to understand reducers & transducers. Is the difference between > r/folder and r/reducer the parallelization? > > Anyone know what this error is about? > > (r/foldcat (r/map #(apply + %) (r/folder (into [] (range 1000)) > (partition-all 5 > > ArrayIndexOutOfBoundsException 47427 java.util.ArrayList.add > (ArrayList.java:459) > > Is this error to do with partition-all being stateful? Correct. At some point the internal state of the transducer (where the 5 elements are accumulated in an ArrayList) gets out of sync. ArrayList is not thread safe. > This works as expected, with reducer instead of folder: > > (r/foldcat (r/map #(apply + %) (r/reducer (into [] (range 1000)) > (partition-all 5 ; XXX large output Because it’s not parallel. r/reducer creates a reducible-transformer but non-foldable collection. > Is there some way to express "map over partitions, in parallel, without > creating an intermediate collection" with reducers and transducers? There are no interemediate collections created on each parallel chunk. However those chunks are concatenated back with concat to return the final result and those intermediate collections are “wasted”. There are ways to concat into a concurrent mutable collection with good performance speedup. I’ve used that in several functions in the parallel lib. Renzo > > -- > 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: ClojureScreencasts.com domain
I don't have a set price, it doesn't have to cost much... Just looking for a good steward for the domain. -- 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.
(gen/sample (s/gen #{'nil})): Couldn't satisfy such-that predicate
Could anybody explain please why I can't get a sample of falses or
quoted nils / falses here?
foo.core> (clojure-version)
"1.10.0"
foo.core> (require '[clojure.spec.gen.alpha :as gen]
'[clojure.spec.alpha :as s])
nil
foo.core> (gen/sample (s/gen #{'nil}))
Error printing return value (ExceptionInfo) at
clojure.test.check.generators/such-that-helper (generators.cljc:320).
Couldn't satisfy such-that predicate after 100 tries.
Other interesting and/or relevant cases are:
foo.core> (gen/sample (s/gen #{'n}))
(n n n n n n n n n n)
foo.core> (gen/sample (s/gen #{true}))
(true true true true true true true true true true)
foo.core> (gen/sample (s/gen #{'true}))
(true true true true true true true true true true)
foo.core> (gen/sample (s/gen #{false}))
Error printing return value (ExceptionInfo) at
clojure.test.check.generators/such-that-helper (generators.cljc:320).
Couldn't satisfy such-that predicate after 100 tries.
foo.core> (gen/sample (s/gen #{'false}))
Error printing return value (ExceptionInfo) at
clojure.test.check.generators/such-that-helper (generators.cljc:320).
Couldn't satisfy such-that predicate after 100 tries.
foo.core> (gen/sample (s/gen #{nil}))
Error printing return value (ExceptionInfo) at
clojure.test.check.generators/such-that-helper (generators.cljc:320).
Couldn't satisfy such-that predicate after 100 tries.
Thanx
--
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: (gen/sample (s/gen #{'nil})): Couldn't satisfy such-that predicate
Sets are treated as predicate functions which are valid when they produce a
logically true value. Sets with logically false values nil or false will
fail this check. This is not a spec thing, but a general thing to be aware
of in Clojure when using sets as functions.
If you want nils, use (s/gen nil?).
If you want falses, use (s/gen false?).
If you want either, the simplest thing is probably (s/gen (s/nilable
false?)), but keep in mind that the s/nilable generator is constructed to
only produce nils 10% of the time, so you'll get 10% nils, 90% falses.
You could also use the more cumbersome (s/gen (s/nonconforming (s/or :n
nil? :f false?))) which should give you about 50/50 mix.
On Tuesday, January 29, 2019 at 2:23:50 PM UTC-6, Bost wrote:
>
> Could anybody explain please why I can't get a sample of falses or
> quoted nils / falses here?
>
> foo.core> (clojure-version)
> "1.10.0"
> foo.core> (require '[clojure.spec.gen.alpha :as gen]
>'[clojure.spec.alpha :as s])
> nil
> foo.core> (gen/sample (s/gen #{'nil}))
> Error printing return value (ExceptionInfo) at
> clojure.test.check.generators/such-that-helper (generators.cljc:320).
> Couldn't satisfy such-that predicate after 100 tries.
>
>
> Other interesting and/or relevant cases are:
>
> foo.core> (gen/sample (s/gen #{'n}))
> (n n n n n n n n n n)
> foo.core> (gen/sample (s/gen #{true}))
> (true true true true true true true true true true)
> foo.core> (gen/sample (s/gen #{'true}))
> (true true true true true true true true true true)
> foo.core> (gen/sample (s/gen #{false}))
> Error printing return value (ExceptionInfo) at
> clojure.test.check.generators/such-that-helper (generators.cljc:320).
> Couldn't satisfy such-that predicate after 100 tries.
> foo.core> (gen/sample (s/gen #{'false}))
> Error printing return value (ExceptionInfo) at
> clojure.test.check.generators/such-that-helper (generators.cljc:320).
> Couldn't satisfy such-that predicate after 100 tries.
> foo.core> (gen/sample (s/gen #{nil}))
> Error printing return value (ExceptionInfo) at
> clojure.test.check.generators/such-that-helper (generators.cljc:320).
> Couldn't satisfy such-that predicate after 100 tries.
>
>
> Thanx
>
--
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: (gen/sample (s/gen #{'nil})): Couldn't satisfy such-that predicate
Hi Alex,
> Sets are treated as predicate functions which are valid when they produce a
> logically true value.
So then my question boils down to:
Why is then (boolean (quote nil)) => false and (boolean (quote
anything)) => true?
And this boils down to:
Why a type of quoted symbol (type (quote nil)) is nil and not
clojure.lang.Symbol as is it the case for (type (quote anything))?
Here the source says:
(defn type
"Returns the :type metadata of x, or its Class if none"
{:added "1.0"
:static true}
[x]
(or (get (meta x) :type) (class x)))
And if I put few println's here, I see that in both cases (type (quote
nil)), (type (quote anything)) the input arg x is nil, IOW the
information "the arg x has a type of quoted symbol" is lost here. IOW
the clojure.core/type eagerly reports the type of e.g.:
(type (quote true)) => java.lang.Boolean
(type (quote "foo")) => java.lang.String
(type (quote nil)) => nil
(type (quote 1)) => java.lang.Long
etc. when I expect clojure.lang.Symbol, as for:
(type (quote anything)) => clojure.lang.Symbol
Hmm... *if* this type-hiding is a bug then I guess it's crawling too
deeply to fix it, right? :)
Anyway, thank you for your response, Alex!
Bost
Le mar. 29 janv. 2019 à 21:40, Alex Miller a écrit :
>
> Sets are treated as predicate functions which are valid when they produce a
> logically true value. Sets with logically false values nil or false will fail
> this check. This is not a spec thing, but a general thing to be aware of in
> Clojure when using sets as functions.
>
> If you want nils, use (s/gen nil?).
> If you want falses, use (s/gen false?).
> If you want either, the simplest thing is probably (s/gen (s/nilable
> false?)), but keep in mind that the s/nilable generator is constructed to
> only produce nils 10% of the time, so you'll get 10% nils, 90% falses.
>
> You could also use the more cumbersome (s/gen (s/nonconforming (s/or :n nil?
> :f false?))) which should give you about 50/50 mix.
>
>
> On Tuesday, January 29, 2019 at 2:23:50 PM UTC-6, Bost wrote:
>>
>> Could anybody explain please why I can't get a sample of falses or
>> quoted nils / falses here?
>>
>> foo.core> (clojure-version)
>> "1.10.0"
>> foo.core> (require '[clojure.spec.gen.alpha :as gen]
>>'[clojure.spec.alpha :as s])
>> nil
>> foo.core> (gen/sample (s/gen #{'nil}))
>> Error printing return value (ExceptionInfo) at
>> clojure.test.check.generators/such-that-helper (generators.cljc:320).
>> Couldn't satisfy such-that predicate after 100 tries.
>>
>>
>> Other interesting and/or relevant cases are:
>>
>> foo.core> (gen/sample (s/gen #{'n}))
>> (n n n n n n n n n n)
>> foo.core> (gen/sample (s/gen #{true}))
>> (true true true true true true true true true true)
>> foo.core> (gen/sample (s/gen #{'true}))
>> (true true true true true true true true true true)
>> foo.core> (gen/sample (s/gen #{false}))
>> Error printing return value (ExceptionInfo) at
>> clojure.test.check.generators/such-that-helper (generators.cljc:320).
>> Couldn't satisfy such-that predicate after 100 tries.
>> foo.core> (gen/sample (s/gen #{'false}))
>> Error printing return value (ExceptionInfo) at
>> clojure.test.check.generators/such-that-helper (generators.cljc:320).
>> Couldn't satisfy such-that predicate after 100 tries.
>> foo.core> (gen/sample (s/gen #{nil}))
>> Error printing return value (ExceptionInfo) at
>> clojure.test.check.generators/such-that-helper (generators.cljc:320).
>> Couldn't satisfy such-that predicate after 100 tries.
>>
>>
>> Thanx
>
> --
> 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: (gen/sample (s/gen #{'nil})): Couldn't satisfy such-that predicate
On Tue, Jan 29, 2019 at 4:23 PM Rostislav Svoboda <
rostislav.svob...@gmail.com> wrote:
> Hi Alex,
>
> > Sets are treated as predicate functions which are valid when they
> produce a logically true value.
>
> So then my question boils down to:
> Why is then (boolean (quote nil)) => false and (boolean (quote
> anything)) => true?
>
nil, false, and true are the only three special "symbols" that the Clojure
reader reads as something other than a symbol. They are read as
respectively nil and boolean false and true. nil's "type" is nil (there is
no type to represent nil). false and true's type is java.lang.Boolean.
Moreover, the false and true values are exactly the static constants
java.lang.Boolean/FALSE and java.lang.Boolean/TRUE.
quote's purpose is to read (with the Clojure reader, converting from string
to value) but NOT evaluate. For these three values, they all evaluate to
themselves, so quote has no effect.
For something like (type (quote anything)), (quote anything) will read the
string "anything", and construct the symbol anything, with type
clojure.lang.Symbol. The quote prevents evaluation.
Skipping some important details, every value in Clojure evaluates to itself
except for the two special cases of symbols and lists. Symbols evaluate by
looking up their associated value in the current namespace. Lists evaluates
its elements, then invokes the first element as a function while passing
the rest of the elements as arguments.
So, no bug here. Everything is going as planned. :)
> And this boils down to:
> Why a type of quoted symbol (type (quote nil)) is nil and not
> clojure.lang.Symbol as is it the case for (type (quote anything))?
> Here the source says:
> (defn type
> "Returns the :type metadata of x, or its Class if none"
> {:added "1.0"
>:static true}
> [x]
> (or (get (meta x) :type) (class x)))
>
> And if I put few println's here, I see that in both cases (type (quote
> nil)), (type (quote anything)) the input arg x is nil, IOW the
> information "the arg x has a type of quoted symbol" is lost here. IOW
> the clojure.core/type eagerly reports the type of e.g.:
> (type (quote true)) => java.lang.Boolean
> (type (quote "foo")) => java.lang.String
> (type (quote nil)) => nil
> (type (quote 1)) => java.lang.Long
> etc. when I expect clojure.lang.Symbol, as for:
> (type (quote anything)) => clojure.lang.Symbol
>
> Hmm... *if* this type-hiding is a bug then I guess it's crawling too
> deeply to fix it, right? :)
> Anyway, thank you for your response, Alex!
>
> Bost
>
>
> Le mar. 29 janv. 2019 à 21:40, Alex Miller a écrit :
> >
> > Sets are treated as predicate functions which are valid when they
> produce a logically true value. Sets with logically false values nil or
> false will fail this check. This is not a spec thing, but a general thing
> to be aware of in Clojure when using sets as functions.
> >
> > If you want nils, use (s/gen nil?).
> > If you want falses, use (s/gen false?).
> > If you want either, the simplest thing is probably (s/gen (s/nilable
> false?)), but keep in mind that the s/nilable generator is constructed to
> only produce nils 10% of the time, so you'll get 10% nils, 90% falses.
> >
> > You could also use the more cumbersome (s/gen (s/nonconforming (s/or :n
> nil? :f false?))) which should give you about 50/50 mix.
> >
> >
> > On Tuesday, January 29, 2019 at 2:23:50 PM UTC-6, Bost wrote:
> >>
> >> Could anybody explain please why I can't get a sample of falses or
> >> quoted nils / falses here?
> >>
> >> foo.core> (clojure-version)
> >> "1.10.0"
> >> foo.core> (require '[clojure.spec.gen.alpha :as gen]
> >>'[clojure.spec.alpha :as s])
> >> nil
> >> foo.core> (gen/sample (s/gen #{'nil}))
> >> Error printing return value (ExceptionInfo) at
> >> clojure.test.check.generators/such-that-helper (generators.cljc:320).
> >> Couldn't satisfy such-that predicate after 100 tries.
> >>
> >>
> >> Other interesting and/or relevant cases are:
> >>
> >> foo.core> (gen/sample (s/gen #{'n}))
> >> (n n n n n n n n n n)
> >> foo.core> (gen/sample (s/gen #{true}))
> >> (true true true true true true true true true true)
> >> foo.core> (gen/sample (s/gen #{'true}))
> >> (true true true true true true true true true true)
> >> foo.core> (gen/sample (s/gen #{false}))
> >> Error printing return value (ExceptionInfo) at
> >> clojure.test.check.generators/such-that-helper (generators.cljc:320).
> >> Couldn't satisfy such-that predicate after 100 tries.
> >> foo.core> (gen/sample (s/gen #{'false}))
> >> Error printing return value (ExceptionInfo) at
> >> clojure.test.check.generators/such-that-helper (generators.cljc:320).
> >> Couldn't satisfy such-that predicate after 100 tries.
> >> foo.core> (gen/sample (s/gen #{nil}))
> >> Error printing return value (ExceptionInfo) at
> >> clojure.test.check.generators/such-that-helper (generators.cljc:320).
> >> Couldn't satisfy such-that predicate after 100 tries.
> >>
> >>
> >> Thanx
> >
> > --
>
Re: (gen/sample (s/gen #{'nil})): Couldn't satisfy such-that predicate
You can see the special cases of nil, false, and true in the LispReader
here if you're curious:
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LispReader.java#L393-L413
On Tue, Jan 29, 2019 at 4:45 PM Alex Miller wrote:
>
>
> On Tue, Jan 29, 2019 at 4:23 PM Rostislav Svoboda <
> rostislav.svob...@gmail.com> wrote:
>
>> Hi Alex,
>>
>> > Sets are treated as predicate functions which are valid when they
>> produce a logically true value.
>>
>> So then my question boils down to:
>> Why is then (boolean (quote nil)) => false and (boolean (quote
>> anything)) => true?
>>
>
> nil, false, and true are the only three special "symbols" that the Clojure
> reader reads as something other than a symbol. They are read as
> respectively nil and boolean false and true. nil's "type" is nil (there is
> no type to represent nil). false and true's type is java.lang.Boolean.
> Moreover, the false and true values are exactly the static constants
> java.lang.Boolean/FALSE and java.lang.Boolean/TRUE.
>
> quote's purpose is to read (with the Clojure reader, converting from
> string to value) but NOT evaluate. For these three values, they all
> evaluate to themselves, so quote has no effect.
>
> For something like (type (quote anything)), (quote anything) will read the
> string "anything", and construct the symbol anything, with type
> clojure.lang.Symbol. The quote prevents evaluation.
>
> Skipping some important details, every value in Clojure evaluates to
> itself except for the two special cases of symbols and lists. Symbols
> evaluate by looking up their associated value in the current namespace.
> Lists evaluates its elements, then invokes the first element as a function
> while passing the rest of the elements as arguments.
>
> So, no bug here. Everything is going as planned. :)
>
>
>> And this boils down to:
>> Why a type of quoted symbol (type (quote nil)) is nil and not
>> clojure.lang.Symbol as is it the case for (type (quote anything))?
>> Here the source says:
>> (defn type
>> "Returns the :type metadata of x, or its Class if none"
>> {:added "1.0"
>>:static true}
>> [x]
>> (or (get (meta x) :type) (class x)))
>>
>> And if I put few println's here, I see that in both cases (type (quote
>> nil)), (type (quote anything)) the input arg x is nil, IOW the
>> information "the arg x has a type of quoted symbol" is lost here. IOW
>> the clojure.core/type eagerly reports the type of e.g.:
>> (type (quote true)) => java.lang.Boolean
>> (type (quote "foo")) => java.lang.String
>> (type (quote nil)) => nil
>> (type (quote 1)) => java.lang.Long
>> etc. when I expect clojure.lang.Symbol, as for:
>> (type (quote anything)) => clojure.lang.Symbol
>>
>> Hmm... *if* this type-hiding is a bug then I guess it's crawling too
>> deeply to fix it, right? :)
>> Anyway, thank you for your response, Alex!
>>
>> Bost
>>
>>
>> Le mar. 29 janv. 2019 à 21:40, Alex Miller a écrit
>> :
>> >
>> > Sets are treated as predicate functions which are valid when they
>> produce a logically true value. Sets with logically false values nil or
>> false will fail this check. This is not a spec thing, but a general thing
>> to be aware of in Clojure when using sets as functions.
>> >
>> > If you want nils, use (s/gen nil?).
>> > If you want falses, use (s/gen false?).
>> > If you want either, the simplest thing is probably (s/gen (s/nilable
>> false?)), but keep in mind that the s/nilable generator is constructed to
>> only produce nils 10% of the time, so you'll get 10% nils, 90% falses.
>> >
>> > You could also use the more cumbersome (s/gen (s/nonconforming (s/or :n
>> nil? :f false?))) which should give you about 50/50 mix.
>> >
>> >
>> > On Tuesday, January 29, 2019 at 2:23:50 PM UTC-6, Bost wrote:
>> >>
>> >> Could anybody explain please why I can't get a sample of falses or
>> >> quoted nils / falses here?
>> >>
>> >> foo.core> (clojure-version)
>> >> "1.10.0"
>> >> foo.core> (require '[clojure.spec.gen.alpha :as gen]
>> >>'[clojure.spec.alpha :as s])
>> >> nil
>> >> foo.core> (gen/sample (s/gen #{'nil}))
>> >> Error printing return value (ExceptionInfo) at
>> >> clojure.test.check.generators/such-that-helper (generators.cljc:320).
>> >> Couldn't satisfy such-that predicate after 100 tries.
>> >>
>> >>
>> >> Other interesting and/or relevant cases are:
>> >>
>> >> foo.core> (gen/sample (s/gen #{'n}))
>> >> (n n n n n n n n n n)
>> >> foo.core> (gen/sample (s/gen #{true}))
>> >> (true true true true true true true true true true)
>> >> foo.core> (gen/sample (s/gen #{'true}))
>> >> (true true true true true true true true true true)
>> >> foo.core> (gen/sample (s/gen #{false}))
>> >> Error printing return value (ExceptionInfo) at
>> >> clojure.test.check.generators/such-that-helper (generators.cljc:320).
>> >> Couldn't satisfy such-that predicate after 100 tries.
>> >> foo.core> (gen/sample (s/gen #{'false}))
>> >> Error printing return value (ExceptionInfo) at
>> >> cloj
Invalid-token when dereferencing namespaced keywords.
I am moving some code to use spec and namespaced keywords under Clojure
1.10.0 (release). One group of keywords starts with a numeric character
after the colon, which has worked fine in the non-namespaced context.
Creating and using the namespaced keyword works correctly in the local
namespace (using only the double-colon), but fails with "Invalid Token"
when dereferencing from another workspace.
I'm not sure if this is a bug or if I have been taking advantage of an
undocumented/unsupported feature.
Having a leading-digit keyword has been very useful, as the names are an
exacting fit of the problem domain and don't suffer from the addition of
any visual pollution.
user=> (def example-a {:015-00 "015-00"})
#'user/example-a
user=> (def example-b {::015-00 "015-00"})
#'user/example-b
user=> (:015-00 example-a)
"015-00"
user=> (:015-00 example-b)
nil
user=> (::015-00 example-b)
"015-00"
user=> (::015-00 example-a)
nil
user=> (ns try)
nil
try=> (:015-00 user/example-a)
"015-00"
try=> (::user/015-00 user/example-b)
Syntax error reading source at (REPL:1:15).
Invalid token: ::user/015-00
Syntax error reading source at (REPL:1:31).
Unmatched delimiter: )
try=>
The current behavior is certainly inconsistent, even if it is not a serious
bug.
Thank you!
--
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: Invalid-token when dereferencing namespaced keywords.
you are misusing the :: alias resolution operator, user is not an alias
Clojure 1.9.0
(ins)user=> (ns foo)
nil
(ins)foo=> ::user/a
RuntimeException Invalid token: ::user/a
clojure.lang.Util.runtimeException (Util.java:221)
(ins)foo=> :user/a
:user/a
On Tue, Jan 29, 2019 at 2:52 PM Philip Markgraf wrote:
>
> I am moving some code to use spec and namespaced keywords under Clojure
> 1.10.0 (release). One group of keywords starts with a numeric character after
> the colon, which has worked fine in the non-namespaced context. Creating and
> using the namespaced keyword works correctly in the local namespace (using
> only the double-colon), but fails with "Invalid Token" when dereferencing
> from another workspace.
>
> I'm not sure if this is a bug or if I have been taking advantage of an
> undocumented/unsupported feature.
> Having a leading-digit keyword has been very useful, as the names are an
> exacting fit of the problem domain and don't suffer from the addition of any
> visual pollution.
>
> user=> (def example-a {:015-00 "015-00"})
> #'user/example-a
> user=> (def example-b {::015-00 "015-00"})
> #'user/example-b
> user=> (:015-00 example-a)
> "015-00"
> user=> (:015-00 example-b)
> nil
> user=> (::015-00 example-b)
> "015-00"
> user=> (::015-00 example-a)
> nil
> user=> (ns try)
> nil
> try=> (:015-00 user/example-a)
> "015-00"
> try=> (::user/015-00 user/example-b)
>
> Syntax error reading source at (REPL:1:15).
> Invalid token: ::user/015-00
> Syntax error reading source at (REPL:1:31).
> Unmatched delimiter: )
> try=>
>
> The current behavior is certainly inconsistent, even if it is not a serious
> bug.
>
> Thank you!
>
>
> --
> 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: transducer parallelism
Hi Brian, On Friday, 25 January 2019 22:19:21 UTC, Brian Craft wrote: > > Are there any docs on transducer parallelism? > Not a lot, but you can find something here: https://labs.uswitch.com/transducers-from-the-ground-up-the-practice/#parallelism I had the impression, from various sources, that they could operate in > parallel, but in doing some benchmarks over a largish collection (counting > character frequencies in 1.3M strings), transduce never uses more than one > thread. Is this expected? If not, how would one debug it? > Yes it is expected, core/transduce is not designed to run in parallel. But there are ways to run transducers with r/fold or pipelines (see article above) with restrictions related to stateful transducers. If you have a specific problem in mind, I suggest you give a look at https://github.com/reborg/parallel and see if there is a function you can use (such as p/frequencies on strings). That library is also taking care of other details, such as using mutable-concurrent collections internally to speed up performance. Hope this helps Renzo -- 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: Invalid-token when dereferencing namespaced keywords.
Thank you. I apologize that my condensed example was in error. (Is the
error you are showing that you can't create a namespaced keyword in a
namespace you are not in?)
However, the condition I originally describe occurs when the original
namespace is properly created with ns:
user=> (ns name1)
nil
name1=> (def ex1 {:015-00 "1"})
#'name1/ex1
name1=> (def ex2 {::015-00 "2"})
#'name1/ex2
name1=> (::015-00 ex2)
"2"
name1=> (ns name2)
nil
name2=> (::name1/015-00 name1/ex2)
Syntax error reading source at (REPL:1:16).
Invalid token: ::name1/015-00
Syntax error reading source at (REPL:1:27).
Unmatched delimiter: )
name2=>
On Tuesday, January 29, 2019 at 4:49:54 PM UTC-8, Justin Smith wrote:
>
> you are misusing the :: alias resolution operator, user is not an alias
>
> Clojure 1.9.0
> (ins)user=> (ns foo)
> nil
> (ins)foo=> ::user/a
> RuntimeException Invalid token: ::user/a
> clojure.lang.Util.runtimeException (Util.java:221)
> (ins)foo=> :user/a
> :user/a
>
> On Tue, Jan 29, 2019 at 2:52 PM Philip Markgraf > wrote:
> >
> > I am moving some code to use spec and namespaced keywords under Clojure
> 1.10.0 (release). One group of keywords starts with a numeric character
> after the colon, which has worked fine in the non-namespaced context.
> Creating and using the namespaced keyword works correctly in the local
> namespace (using only the double-colon), but fails with "Invalid Token"
> when dereferencing from another workspace.
> >
> > I'm not sure if this is a bug or if I have been taking advantage of an
> undocumented/unsupported feature.
> > Having a leading-digit keyword has been very useful, as the names are an
> exacting fit of the problem domain and don't suffer from the addition of
> any visual pollution.
> >
> > user=> (def example-a {:015-00 "015-00"})
> > #'user/example-a
> > user=> (def example-b {::015-00 "015-00"})
> > #'user/example-b
> > user=> (:015-00 example-a)
> > "015-00"
> > user=> (:015-00 example-b)
> > nil
> > user=> (::015-00 example-b)
> > "015-00"
> > user=> (::015-00 example-a)
> > nil
> > user=> (ns try)
> > nil
> > try=> (:015-00 user/example-a)
> > "015-00"
> > try=> (::user/015-00 user/example-b)
> >
> > Syntax error reading source at (REPL:1:15).
> > Invalid token: ::user/015-00
> > Syntax error reading source at (REPL:1:31).
> > Unmatched delimiter: )
> > try=>
> >
> > The current behavior is certainly inconsistent, even if it is not a
> serious bug.
> >
> > Thank you!
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clo...@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+u...@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+u...@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: Invalid-token when dereferencing namespaced keywords.
I believe the original intent was that keywords with a digit immediately
after the colon would not be supported, but due to a bug in the Clojure
reader they were permitted. There was a brief time in 2013 where this bug
was fixed, but there were enough extant Clojure code bases that used such
keywords, that the change was reverted. See the comments on the Clojure
ticket below for some history:
https://dev.clojure.org/jira/browse/CLJ-1252
I believe that this bug has never existed for namespaced keywords, and I am
not aware of any desire to change Clojure to allow such keywords.
Andy
On Tue, Jan 29, 2019 at 5:12 PM Philip Markgraf wrote:
> Thank you. I apologize that my condensed example was in error. (Is the
> error you are showing that you can't create a namespaced keyword in a
> namespace you are not in?)
>
> However, the condition I originally describe occurs when the original
> namespace is properly created with ns:
>
> user=> (ns name1)
> nil
> name1=> (def ex1 {:015-00 "1"})
> #'name1/ex1
> name1=> (def ex2 {::015-00 "2"})
> #'name1/ex2
> name1=> (::015-00 ex2)
> "2"
> name1=> (ns name2)
> nil
> name2=> (::name1/015-00 name1/ex2)
>
> Syntax error reading source at (REPL:1:16).
> Invalid token: ::name1/015-00
> Syntax error reading source at (REPL:1:27).
> Unmatched delimiter: )
> name2=>
>
>
>
> On Tuesday, January 29, 2019 at 4:49:54 PM UTC-8, Justin Smith wrote:
>>
>> you are misusing the :: alias resolution operator, user is not an alias
>>
>> Clojure 1.9.0
>> (ins)user=> (ns foo)
>> nil
>> (ins)foo=> ::user/a
>> RuntimeException Invalid token: ::user/a
>> clojure.lang.Util.runtimeException (Util.java:221)
>> (ins)foo=> :user/a
>> :user/a
>>
>> On Tue, Jan 29, 2019 at 2:52 PM Philip Markgraf
>> wrote:
>> >
>> > I am moving some code to use spec and namespaced keywords under Clojure
>> 1.10.0 (release). One group of keywords starts with a numeric character
>> after the colon, which has worked fine in the non-namespaced context.
>> Creating and using the namespaced keyword works correctly in the local
>> namespace (using only the double-colon), but fails with "Invalid Token"
>> when dereferencing from another workspace.
>> >
>> > I'm not sure if this is a bug or if I have been taking advantage of an
>> undocumented/unsupported feature.
>> > Having a leading-digit keyword has been very useful, as the names are
>> an exacting fit of the problem domain and don't suffer from the addition of
>> any visual pollution.
>> >
>> > user=> (def example-a {:015-00 "015-00"})
>> > #'user/example-a
>> > user=> (def example-b {::015-00 "015-00"})
>> > #'user/example-b
>> > user=> (:015-00 example-a)
>> > "015-00"
>> > user=> (:015-00 example-b)
>> > nil
>> > user=> (::015-00 example-b)
>> > "015-00"
>> > user=> (::015-00 example-a)
>> > nil
>> > user=> (ns try)
>> > nil
>> > try=> (:015-00 user/example-a)
>> > "015-00"
>> > try=> (::user/015-00 user/example-b)
>> >
>> > Syntax error reading source at (REPL:1:15).
>> > Invalid token: ::user/015-00
>> > Syntax error reading source at (REPL:1:31).
>> > Unmatched delimiter: )
>> > try=>
>> >
>> > The current behavior is certainly inconsistent, even if it is not a
>> serious bug.
>> >
>> > Thank you!
>> >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clo...@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+u...@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+u...@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.
>
--
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...@go
Re: Invalid-token when dereferencing namespaced keywords.
There are two interrelated issues here.
First, when you are using autoresolved keywords, the qualifier part must be
an alias. Here it is a fully-qualified namespace (user). Instead, you
should be using :user/015-00. Note that before Clojure 1.10, this would not
produce an error - this was an oversight that was tightened up in 1.10.
:user/015-00 introduces the second error. Keywords with a leading digit
were not originally legal (according to the reader reference), but have
been grandfathered in (like :1st, etc). However, qualified keywords with a
digit name have never been accepted by the reader and this is kind of an
unresolved issue.
On Tuesday, January 29, 2019 at 4:52:09 PM UTC-6, Philip Markgraf wrote:
>
> I am moving some code to use spec and namespaced keywords under Clojure
> 1.10.0 (release). One group of keywords starts with a numeric character
> after the colon, which has worked fine in the non-namespaced context.
> Creating and using the namespaced keyword works correctly in the local
> namespace (using only the double-colon), but fails with "Invalid Token"
> when dereferencing from another workspace.
>
> I'm not sure if this is a bug or if I have been taking advantage of an
> undocumented/unsupported feature.
> Having a leading-digit keyword has been very useful, as the names are an
> exacting fit of the problem domain and don't suffer from the addition of
> any visual pollution.
>
> user=> (def example-a {:015-00 "015-00"})
> #'user/example-a
> user=> (def example-b {::015-00 "015-00"})
> #'user/example-b
> user=> (:015-00 example-a)
> "015-00"
> user=> (:015-00 example-b)
> nil
> user=> (::015-00 example-b)
> "015-00"
> user=> (::015-00 example-a)
> nil
> user=> (ns try)
> nil
> try=> (:015-00 user/example-a)
> "015-00"
> try=> (::user/015-00 user/example-b)
>
> Syntax error reading source at (REPL:1:15).
> Invalid token: ::user/015-00
> Syntax error reading source at (REPL:1:31).
> Unmatched delimiter: )
> try=>
>
> The current behavior is certainly inconsistent, even if it is not a
> serious bug.
>
> Thank you!
>
>
>
--
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: Invalid-token when dereferencing namespaced keywords.
Thank you, Alex and Andy. This answers my question regarding leading digit
in keywords.
Alex,
You describe an error with autoresolved keywords in my example. Is this
also true of the second example I posted (in response to Justin), which
does not use the user namespace? Am I correct to use double-quote inside a
namespace, and double-quote, namespace-alias, slash when using the keyword
in another namespace?
Thank you!
On Tuesday, January 29, 2019 at 7:40:51 PM UTC-8, Alex Miller wrote:
>
> There are two interrelated issues here.
>
> First, when you are using autoresolved keywords, the qualifier part must
> be an alias. Here it is a fully-qualified namespace (user). Instead, you
> should be using :user/015-00. Note that before Clojure 1.10, this would not
> produce an error - this was an oversight that was tightened up in 1.10.
>
> :user/015-00 introduces the second error. Keywords with a leading digit
> were not originally legal (according to the reader reference), but have
> been grandfathered in (like :1st, etc). However, qualified keywords with a
> digit name have never been accepted by the reader and this is kind of an
> unresolved issue.
>
>
> On Tuesday, January 29, 2019 at 4:52:09 PM UTC-6, Philip Markgraf wrote:
>>
>> I am moving some code to use spec and namespaced keywords under Clojure
>> 1.10.0 (release). One group of keywords starts with a numeric character
>> after the colon, which has worked fine in the non-namespaced context.
>> Creating and using the namespaced keyword works correctly in the local
>> namespace (using only the double-colon), but fails with "Invalid Token"
>> when dereferencing from another workspace.
>>
>> I'm not sure if this is a bug or if I have been taking advantage of an
>> undocumented/unsupported feature.
>> Having a leading-digit keyword has been very useful, as the names are an
>> exacting fit of the problem domain and don't suffer from the addition of
>> any visual pollution.
>>
>> user=> (def example-a {:015-00 "015-00"})
>> #'user/example-a
>> user=> (def example-b {::015-00 "015-00"})
>> #'user/example-b
>> user=> (:015-00 example-a)
>> "015-00"
>> user=> (:015-00 example-b)
>> nil
>> user=> (::015-00 example-b)
>> "015-00"
>> user=> (::015-00 example-a)
>> nil
>> user=> (ns try)
>> nil
>> try=> (:015-00 user/example-a)
>> "015-00"
>> try=> (::user/015-00 user/example-b)
>>
>> Syntax error reading source at (REPL:1:15).
>> Invalid token: ::user/015-00
>> Syntax error reading source at (REPL:1:31).
>> Unmatched delimiter: )
>> try=>
>>
>> The current behavior is certainly inconsistent, even if it is not a
>> serious bug.
>>
>> Thank you!
>>
>>
>>
--
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: Invalid-token when dereferencing namespaced keywords.
On Tuesday, January 29, 2019 at 10:07:29 PM UTC-6, Philip Markgraf wrote: > > Thank you, Alex and Andy. This answers my question regarding leading digit > in keywords. > > > Alex, > You describe an error with autoresolved keywords in my example. Is this > also true of the second example I posted (in response to Justin), which > does not use the user namespace? > Yes > Am I correct to use double-quote inside a namespace, and double-quote, > namespace-alias, slash when using the keyword in another namespace? > No, in all of these cases you are using fully-qualified namespaces, not aliases. The double-colon is only for autoresolving based on the aliases of the current namespace, and you are not using aliases in any of your examples. For example, you could have done the following to use an autoresolved keyword based on the alias n1: (ns name2 (:require [name1 :as n1])) (::n1/015-00 name1/ex2) ;; invalid token Although note that you will still run into the second problem of qualified keywords with leading digit names, so the latter won't work. For something like this, you'll need to avoid the leading digit in the keyword name. Or you can programmatically create the keyword if you must: ((keyword "name1" "015-00") n1/ex2) . ;; "2" -- 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.
Inside Clojure Journal
I just wanted to say thanks to Alex for taking the time to journal all the Clojure things he's working on (and the non-Clojure things as well). They're enjoyable to read and eye-opening. It's a great window into the effort that he and others are putting into Clojure. It's been fun to follow the spec-alpha2 commits and get to read the thoughts/direction in the journal. Great work Alex! You can find them on the Inside Clojure blog: http://insideclojure.org/ Shaun -- 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: Issue when moving to Clojure 1.10
For anyone interested, the approach I ended up taking was to AOT everything all the time. But, require the class namespaces to be explicitly defined in the build config file for any which needs to be included in the Jar. And when packaging the Jar, only the Clojure source and the AOT class files of the namespaces that were explicitly listed are included. I do that by compiling every source files, and then deleting all .class files except for the ones that match the explicitly listed namespaces. If no namespace are listed, then the resulting Jar is thus similar to a non AOT build, and only includes source. The advantages are that the AOT compilation bubbles compile issues early at build time. And the resulting Jars do not include transitive classes that could cause version conflicts. And when you need gen-class, you can include only the gen-class .class in the Jar, not even have its containing namespace. Minimizing the blast radius of AOT. And if you face the protocol issue, you can specify these namespaces as well to ne included in the Jar. -- 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: Invalid-token when dereferencing namespaced keywords.
My actual case is using the keyword across two files (namespaces), using the ns/:require/:as constructs in the file that did not define the keyword. (The REPL example was created to give a minimal replication of the leading digit issue.) So, now I am really wondering what the intent with spec and namespaced keywords is. When should we use single-colon keywords and when should we use the double-colon variety? On Tuesday, January 29, 2019 at 8:48:00 PM UTC-8, Alex Miller wrote: > > > > On Tuesday, January 29, 2019 at 10:07:29 PM UTC-6, Philip Markgraf wrote: >> >> Thank you, Alex and Andy. This answers my question regarding leading >> digit in keywords. >> >> >> Alex, >> You describe an error with autoresolved keywords in my example. Is this >> also true of the second example I posted (in response to Justin), which >> does not use the user namespace? >> > > Yes > > >> Am I correct to use double-quote inside a namespace, and double-quote, >> namespace-alias, slash when using the keyword in another namespace? >> > > No, in all of these cases you are using fully-qualified namespaces, not > aliases. The double-colon is only for autoresolving based on the aliases of > the current namespace, and you are not using aliases in any of your > examples. > > For example, you could have done the following to use an autoresolved > keyword based on the alias n1: > > (ns name2 (:require [name1 :as n1])) > (::n1/015-00 name1/ex2) ;; invalid token > > Although note that you will still run into the second problem of qualified > keywords with leading digit names, so the latter won't work. For something > like this, you'll need to avoid the leading digit in the keyword name. > > Or you can programmatically create the keyword if you must: > > ((keyword "name1" "015-00") n1/ex2) . ;; "2" > > > -- 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.
