Re: core.logic: Strange behaviour when using featurec with nested feature map (bug?).

[David Nolen]

Fixed in master, thanks for the report!


On Thu, Apr 25, 2013 at 5:53 PM, Martin Forsgren
wrote:

> Hi!
>
> I noticed something strange when using featurec with a nested feature map(I'm 
> using core.logic 0.8.3).
> This works as expected:
> (run* [x y]
>   (featurec x {:a {:b 1}})
>   (== y {:b 1})
>   (== x {:a y}))
> and returns:
> ([{:a {:b 1}} {:b 1}])
>
> But with the last two goals swapped I get an exception:
> (run* [x y]
>   (featurec x {:a {:b 1}})
>   (== x {:a y})
>   (== y {:b 1}))
> Throws:
> Exception clojure.core.logic.PMap@3c6f0bed is non-storable
> clojure.core.logic.LVar (logic.clj:647)
> clojure.core.logic/unify (logic.clj:231)
> clojure.core.logic/unify-with-pmap* (logic.clj:2601)
> clojure.core.logic.PMap (logic.clj:2614)
> clojure.core.logic/unify (logic.clj:232)
> clojure.core.logic/==/fn--2819 (logic.clj:1135)
> clojure.core.logic/composeg/fn--2745 (logic.clj:1029)
> clojure.core.logic/-featurec/reify--3655 (logic.clj:2646)
> clojure.core.logic/composeg/fn--2745 (logic.clj:1029)
> clojure.core.logic/composeg/fn--2745 (logic.clj:1030)
> clojure.core.logic/run-constraint/fn--3431 (logic.clj:2184)
> clojure.core.logic/fix-constraints (logic.clj:2211)
>
> I get the same exception when (== y {:b 1}) is left out:
> (run* [x y]
>   (featurec x {:a {:b 1}})
>   (== x {:a y}))
>
> Any ideas why this is happening?
>
> - Martin
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: [GSoC] Mentors: please review student proposals

[David Nolen]

Thanks for the reminder!


On Mon, May 6, 2013 at 9:23 AM, Daniel Solano Gómez wrote:

> Hello, all,
>
> This is just a quick reminder for mentors.  Please sign up to be a
> mentor on Melange[1] with Clojure.  Once you do so, please take a moment
> to review the proposal that have been submitted.  If you are interested
> in mentoring, please be sure to set the 'Wish to Mentor' switch to
> 'yes'.
>
> [1]: https://www.google-melange.com/gsoc/org/google/gsoc2013/clojure_dev
>
> Thanks,
>
> Daniel
>

-- 
-- 
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/groups/opt_out.

Re: ANN: ClojureScript release 0.0-1798

[David Nolen]

Stuart Sierra just pushed out 0.0-1803 which fixes a regression around seq,
get, & reduce and extension to JavaScript natives pointed out by Kevin
Lynagh.


On Fri, May 3, 2013 at 6:14 PM, David Nolen  wrote:

> artifact:
> http://search.maven.org/#artifactdetails%7Corg.clojure%7Cclojurescript%7C0.0-1798%7Cjar
>
> Git log: https://github.com/clojure/clojurescript/compare/r1586...r1798
>
> Enhancements
> 
>
> * Code size improvements, (.log js/console "Hello world!") now
>   generates ~100 LOC of pretty printed advanced compiled JavaScript
> * Source map merging, can produce composition source map, source map
> * Optimize PersistentArrayMaps
>
> Changes
> ---
>
> * Symbols are no longer JavaScript strings, support metadata
>
> Fixes
> -
>
> * CLJS-367: chunked seq support in for and doseq, comprehension benchmarks
> * CLJS-496: better implementation of `char`
> * CLJS-495: add exists? macro
> * CLJS-493: get should accept any type
> * CLJS-492: avoid producing unnecessary calls to next in emit-apply-to
> * CLJS-491: avoid layered subvecs
> * CLJS-488: resolve aliased keywords properly
> * CLJS-438: import new threading macros from 1.5
> * CLJS-482: bind *out* as the target of Rhino REPL env printing
> * CLJS-484: Throw exception instead of trying to throw string in defmulti
> compiler macro
> * CLJS-468: Implement IKVReduce for nil, Test reduce-kv and fold with nil
> * CLJS-477: Vararg fns break when first vararg is undefined.
> * CLJS-473: cljs.closure/add-dep-string calls wrong munge
>

-- 
-- 
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/groups/opt_out.

Re: Separating Out .cljs Content

[David Nolen]

I believe the ClojureScript compiler simply looks for all .cljs files on
the specified compile path. I think maybe you could put your files in
different directories so they don't all get concatenated together. You can
one build specify one path, and another build specify both paths.

Perhaps other people have better solutions?


On Tue, May 7, 2013 at 11:26 AM, Timothy Washington wrote:

> This is on a Clojurescript compilation note. I've noticed that if I have a
> *main.cljs* and *my-other.cljs*, parts of *my-other.cljs* will appear in *
> main.cljs*. Is there a way to avoid this? Using *lein-cljsbuild*, any of
> the :optimization flags, gives the same result (in terms of adding all to
> *main.cljs*). I'd like main.cljs to just be a bootstrap file, and
> separately include my other files. Then at production time, I can choose
> flip a switch to have all the files compiled down to one
>  compressed main.cljs.
>
> Can I do this?
>
>
> Thanks
> Tim
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Separating Out .cljs Content

[David Nolen]

This is why I suggested organizing the project around directories and
specifying different groups of them with different lein-cljsbuild groups.


On Tue, May 7, 2013 at 12:24 PM, Jonathan Fischer Friberg <
odysso...@gmail.com> wrote:

> I haven't used clojurescript in a while, but if I recall correctly, the
> only way
> to not compile everything into a single file is to leave out the
> :optimization flag
> completely. If this is the case this should probably be considered a bug.
> I might
> be wrong though.
>
> Jonathan
>
>
> On Tue, May 7, 2013 at 5:49 PM, David Nolen wrote:
>
>> I believe the ClojureScript compiler simply looks for all .cljs files on
>> the specified compile path. I think maybe you could put your files in
>> different directories so they don't all get concatenated together. You can
>> one build specify one path, and another build specify both paths.
>>
>> Perhaps other people have better solutions?
>>
>>
>> On Tue, May 7, 2013 at 11:26 AM, Timothy Washington 
>> wrote:
>>
>>> This is on a Clojurescript compilation note. I've noticed that if I have
>>> a *main.cljs* and *my-other.cljs*, parts of *my-other.cljs* will appear
>>> in *main.cljs*. Is there a way to avoid this? Using *lein-cljsbuild*,
>>> any of the :optimization flags, gives the same result (in terms of adding
>>> all to *main.cljs*). I'd like main.cljs to just be a bootstrap file,
>>> and separately include my other files. Then at production time, I can
>>> choose flip a switch to have all the files compiled down to one
>>>  compressed main.cljs.
>>>
>>> Can I do this?
>>>
>>>
>>> Thanks
>>> Tim
>>>
>>> --
>>> --
>>> 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/groups/opt_out.
>>>
>>>
>>>
>>
>>  --
>> --
>> 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/groups/opt_out.
>>
>>
>>
>
>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Parallel code execution in ClojureScript?

[David Nolen]

It can probably be done with HTML 5 Workers in browsers that support it,

On Tuesday, May 7, 2013, Ghassan Ayesh wrote:

> Hi:
>
> In Javascript language, and while the language is inherently functional,
> Javascript's *implementation* until now, does not support parallel code
> execution against available CPU cores, unlike Erlang for example or Clojure
> on JVM, so I am thinking that the actor pattern in Clojure when targetting
> JavaScript does not run in parallel natively. Am I right?
>
> -Ghassan.
>
> --
> --
> 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 '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  'clojure%2bunsubscr...@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  'clojure%2bunsubscr...@googlegroups.com');>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Clojure/Script pr-str/read-string roundtrip differences

[David Nolen]

Patch welcome for 1.

As far as 2 I myself see no way to make that work without considering a
numerics overhaul.


On Sun, Jan 6, 2013 at 7:13 PM, Thomas Heller  wrote:

> Hey,
>
> I'm writing a Clojure Webapp with a CLJS Frontend and expected to be able
> to cljs.reader/read-string everything I pr-str'd on the CLJ side. That
> however does not work for defrecords and BigDecimals (1.1M) .
>
> 1. defrecord
>
> In CLJ I can:
>
> (ns dummy)
> (defrecord Foo [bar])
> (pr-str (Foo. 1)) ; => "#dummy.Foo{:bar 1}"
>
> in CLJS however this will print as
>
> "#Foo{:bar 1}"
>
> missing the Namespace. I found an old 
> postabout 
> this but no other information.
>
> Also when I pr-str this record in CLJ and cljs.reader/read-string it in
> CLJS it fails with "Could not find tag parser for dummy.Foo in ("inst"
> "uuid" "queue") ", although the defrecord exists and is in the same ns
> (actually a cljsbuild crossover). I figured out that I can
> (cljs.reader/register-tag-parser! 'dummy.Foo make-foo) but thats seems
> faulty. I read about EDN and understand why the reader would think its
> reading a Tag but I can do read-string in CLJ just fine. Shouldnt both
> sides be equal here?
>
> 2. BigDecimals:
>
> I understand that JavaScript has no BigDecimals and I can live with
> js/parseFloat on the Client for now, however is there any way I can hint
> the CLJS printer to print "1.1" as "1.1M"?
>
> On the Topic of EDN: How would I "tag" a value in CLJ(S) to print {:foo
> "bar"} as #my/tag {:foo "bar"}? The docs only talk about data_readers.clj.
>
> The answers probably lie in the sources, but I hope somebody here has a
> quick answer. ;)
>
> Cheers,
> /thomas
>
> PS: I'd actually prefer using "tagged" literals instead of the defrecord
> constructor form since I dont trust anything coming from the client even it
> looks like clojure data. Is there some protocol I can implement for the
> record and have it print as tagged instead? For CLJ and CLJS? :)
>
>
>  --
> 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 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/groups/opt_out.

Re: Clojure/Script pr-str/read-string roundtrip differences

[David Nolen]

Heh didn't notice the date on the first post :)


On Thu, May 9, 2013 at 8:29 PM, Thomas Heller  wrote:

> Hey Brian,
>
> been a while since that Post, Issue #1 has been resolved for a while (see
> http://dev.clojure.org/jira/browse/CLJS-466) but I actually switched to
> using proper EDN tags via IPrintWithWriter, clj/print-method and
> clojure.edn/read-string like you suggested.
>
> #2 I solved indirectly via #1, I didnt find an acceptable BigDecimal
> JavaScript implementation and since all the math happens on the server
> anyways I just transmit them as Strings inside records. The Reader function
> in CLJS just keeps it as a String, the CLJ Reader function just does
> (BigDecimal. s) so all is good. (eg. #ns/money [:EUR "1234567.89"])
>
>
>
>
> On Thu, May 9, 2013 at 9:03 PM, Brian Jenkins  wrote:
>
>> Hi, Thomas.
>>
>> I also found this frustrating. Here's a work-around I came up with:
>>
>>
>> ;; assuming (defrecord Design [id name]) in namespace tektite.model.design
>>
>> (cljs.reader/register-tag-parser!  "tektite.model.design.Design"
>> tektite.model.design/map->Design)
>>
>> (extend-protocol IPrintWithWriter
>>   tektite.model.design/Design
>>   (-pr-writer [coll writer opts]
>> (let [pr-pair (fn [keyval] (pr-sequential-writer writer pr-writer ""
>> " " "" opts keyval))]
>>   (pr-sequential-writer writer pr-pair
>> "#tektite.model.design.Design{" ", " "}" opts coll
>>
>>
>> On the server side, I read EDN out of the request body with
>> clojure.edn/read (because clojure.core/read is
>> unsafe for reading evil strings from the internet).  clojure.edn/read
>> doesn't pick up new readers
>> from data_readers.clj or *data-readers* (fortunately), but can be taught
>> new tags like this:
>>
>>
>> (def model-readers {'tektite.model.design.Design
>> #'tektite.model.design/map->Design})
>>
>> (defn read-edn-body [context]
>>   (clojure.edn/read {:readers model-readers, :eof nil}
>> (java.io.PushbackReader.
>>  (java.io.InputStreamReader.
>>   (get-in context [:request :body])
>>   "UTF-8"
>>
>>
>> (I use liberator, so the request arrives in a context hash)
>>
>> Best,
>> Brian
>>
>> On Monday, January 7, 2013 1:13:30 AM UTC+1, Thomas Heller wrote:
>>>
>>> Hey,
>>>
>>> I'm writing a Clojure Webapp with a CLJS Frontend and expected to be
>>> able to cljs.reader/read-string everything I pr-str'd on the CLJ side. That
>>> however does not work for defrecords and BigDecimals (1.1M) .
>>>
>>> 1. defrecord
>>>
>>> In CLJ I can:
>>>
>>> (ns dummy)
>>> (defrecord Foo [bar])
>>> (pr-str (Foo. 1)) ; => "#dummy.Foo{:bar 1}"
>>>
>>> in CLJS however this will print as
>>>
>>> "#Foo{:bar 1}"
>>>
>>> missing the Namespace. I found an old 
>>> postabout 
>>> this but no other information.
>>>
>>> Also when I pr-str this record in CLJ and cljs.reader/read-string it in
>>> CLJS it fails with "Could not find tag parser for dummy.Foo in ("inst"
>>> "uuid" "queue") ", although the defrecord exists and is in the same ns
>>> (actually a cljsbuild crossover). I figured out that I can
>>> (cljs.reader/register-tag-**parser! 'dummy.Foo make-foo) but thats
>>> seems faulty. I read about EDN and understand why the reader would think
>>> its reading a Tag but I can do read-string in CLJ just fine. Shouldnt both
>>> sides be equal here?
>>>
>>  --
>> --
>> 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/4aeIxs_yNG4/unsubscribe?hl=en.
>> 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/groups/opt_out.
>>
>>
>>
>
>  --
> --
> 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 opt

Re: Clojure/Script pr-str/read-string roundtrip differences

[David Nolen]

I believe 0.0-1806 is the latest.


On Fri, May 10, 2013 at 12:35 PM, Brian Jenkins  wrote:

> Doh!
>
> I was running 0.0-1586 instead of 0.0-1798
>
> Brian
>
> On Monday, January 7, 2013 1:13:30 AM UTC+1, Thomas Heller wrote:
>
>> Hey,
>>
>> I'm writing a Clojure Webapp with a CLJS Frontend and expected to be able
>> to cljs.reader/read-string everything I pr-str'd on the CLJ side. That
>> however does not work for defrecords and BigDecimals (1.1M) .
>>
>> 1. defrecord
>>
>> In CLJ I can:
>>
>> (ns dummy)
>> (defrecord Foo [bar])
>> (pr-str (Foo. 1)) ; => "#dummy.Foo{:bar 1}"
>>
>> in CLJS however this will print as
>>
>> "#Foo{:bar 1}"
>>
>> missing the Namespace. I found an old 
>> postabout 
>> this but no other information.
>>
>> Also when I pr-str this record in CLJ and cljs.reader/read-string it in
>> CLJS it fails with "Could not find tag parser for dummy.Foo in ("inst"
>> "uuid" "queue") ", although the defrecord exists and is in the same ns
>> (actually a cljsbuild crossover). I figured out that I can
>> (cljs.reader/register-tag-**parser! 'dummy.Foo make-foo) but thats seems
>> faulty. I read about EDN and understand why the reader would think its
>> reading a Tag but I can do read-string in CLJ just fine. Shouldnt both
>> sides be equal here?
>>
>> 2. BigDecimals:
>>
>> I understand that JavaScript has no BigDecimals and I can live with
>> js/parseFloat on the Client for now, however is there any way I can hint
>> the CLJS printer to print "1.1" as "1.1M"?
>>
>> On the Topic of EDN: How would I "tag" a value in CLJ(S) to print {:foo
>> "bar"} as #my/tag {:foo "bar"}? The docs only talk about data_readers.clj.
>>
>> The answers probably lie in the sources, but I hope somebody here has a
>> quick answer. ;)
>>
>> Cheers,
>> /thomas
>>
>> PS: I'd actually prefer using "tagged" literals instead of the defrecord
>> constructor form since I dont trust anything coming from the client even it
>> looks like clojure data. Is there some protocol I can implement for the
>> record and have it print as tagged instead? For CLJ and CLJS? :)
>>
>>
>>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Quick question on protocols

[David Nolen]

It was my impression that extending to Object is handled as a special case
- much like extend-type default in ClojureScript.


On Fri, May 10, 2013 at 6:06 PM, Alan Malloy  wrote:

> Even when the interface and class you've extended them to are related by
> inheritance? I thought the most-derived implementation was chosen, and only
> when there's a "tie" like a class that implements two unrelated interfaces,
> both of which have had the protocol extended to them. If it were completely
> undefined, all sorts of useful idioms would become untenable. For example,
> you couldn't extend a protocol to Object and also to various other classes.
> Dave's scenario is like this, in which TUnion is more-derived than TBase,
> and so as far as I know should always "win" in the polymorphic dispatch.
> Reading through core_deftype's functions 'pref and 'find-protocol-impl seem
> to support this assertion; am I missing something?
>
> On Friday, May 10, 2013 2:20:31 PM UTC-7, Stuart Sierra wrote:
>>
>> When you extend a protocol to multiple Java interfaces / abstract
>> classes, then call the methods on an instance which implements/extends more
>> than one of those, the result is *undefined*.
>>
>> The problem is that this permits multiple inheritance of concrete
>> behavior, the reason Java doesn't allow multiple base classes.
>>
>> Protocols do not (currently) have any mechanism to "prefer" one method
>> implementation over another.
>>
>> In general, I recommend extending protocols only to concrete types, not
>> interfaces.
>>
>> -S
>>
>>
>> On Friday, May 10, 2013 4:45:57 AM UTC+10, Dave Kincaid wrote:
>>>
>>> I've not worked with protocols much, but saw a good fit recently.
>>> However, I'm a little bit unsure about this situation. I have some Thrift
>>> objects that I'd like to be able to easily unpack into maps, so I created a
>>> protocol
>>>
>>> (defprotocol Unpackable
>>>   (unpack [x]))
>>>
>>> Thrift has two main data types - structs and unions that need to be
>>> handled differently. Structs always implement the interface TBase. Unions
>>> extend the abstract class TUnion which in turn implements the interface
>>> TBase. So I'm extending my protocol to these types like this:
>>>
>>> (extend-protocol IUnpackable
>>>   TUnion
>>>   (unpack [x] (unpack-union x))
>>>
>>>   TBase
>>>   (unpack [x] (unpack-struct x (get-meta-data (class x)
>>>
>>> It all seems to work correctly, but I'm a little unsure that it is
>>> guaranteed to work especially in the case of a union. Since a union extends
>>> TUnion, but also implements TBase will a call to (unpack the-union) do the
>>> right thing (go to unpack-union instead of unpack-struct) every time?
>>>
>>> Thanks.
>>>
>>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Untangling Compilation & External Libs: Clojurescript -> Javascript

[David Nolen]

to-array is not sufficient, use clj->js


On Fri, May 10, 2013 at 8:58 PM, Timothy Washington wrote:

> Hi all,
>
> I'm trying to suss out some problems I'm encountering when compiling
> Clojurescript, down to Javascript. I'm using i) a 3rd-party charting
> library (highcharts.com), and ii) using cljsbuild with :optimizations
> :whitespace ( :simple doesn't make a difference).
>
>1. Clojurescript in *fig.1*, generates the Javascript in *fig.2*. Now,
>this clojurescript compiles and runs in a browser.
>2. But the chart doesn't render properly, as it's expecting an array
>of *arrays* (see *fig.3*), and instead, gets an array of *
>cljs.core.PersistenVector(s)*.
>3. If I change only the *edgar.tick_list* , using fig.3, it still
>doesn't work.
>4. I have to manually change both the tick_list, and the call (all of
>fig.3), in order for the highcharts library to render properly.
>
> What this tells me, is that there's a problem with both i) the data and
> ii) invoking the highcharts function. While legal JS, it is not usable with
> some libs, because of things like *cljs.core.PersistenVector* or 
> *cljs.core.ObjMap.fromObject
> (["\ufdd0'rangeSelector",etc*. So basically I'm trying to solve that
> problem. Is there anyway to get from fig.1 to fig.3 ? Or is there another,
> cleaner solution? To some degree, we're always going to have to use
> external JS libs.
>
>
> Thanks for any insights. Code is below:
>
>
> (def *tick-list* (to-array [[1368215573010 203.98] [1368215576331 203.99]
> [1368215576857 203.99] [1368215577765 203.99] [1368215578769 204.0]
> [1368215579272 204.01] [1368215579517 204.02] [1368215581769 204.02]
> [1368215583602 204.01] [1368215585650 204.02] [1368215586060 204.02]
> [1368215587029 204.01] [1368215588318 204.02] [1368215589335 204.01]
> [1368215589536 204.01] [1368215589846 204.0] [1368215591079 203.99 ]
> [1368215591789 203.99] [1368215592104 203.98] [1368215592615 203.98]
> [1368215592758 203.99] [1368215594039 203.97] [1368215597119 203.98]
> [1368215597632 203.97] [1368215599396 203.97] [1368215603876 203.96]
> [1368215606059 203.96] [1368215610316 203.95] [1368215610634 203.95]
> [1368215610813 203.93] [1368215612886 203.95] [1368215615858 203.94]
> [1368215618621 203.94] [1368215619138 203.96] [1368215623846 203.94]
> [1368215632669 203.94] [1368215634709 203.92] [1368215636587 203.93]
> [1368215636952 203.94] [1368215638328 203.93]]))
>
>   (-> ($ "#tab-one-graph")
>   (.highcharts "StockChart"
>{:rangeSelector {:selected 1},
> :title {:text "Test Stock Data"},
> :series [{:name "Test Stock Data",
>   :data *tick-list*,
>   :marker {:enabled true, :radius 3},
>   :shadow true,
>   :tooltip {:valueDecimals 2}}]}
>))
>
> *fig.1* - source Clojurescript
>
>
> *edgar.tick_list* = cljs.core.PersistentVector.fromArray
> ([cljs.core.PersistentVector.fromArray ([1368215573010, 203.98], true),
> cljs.core.PersistentVector.fromArray ([1368215576331, 203.99], true),
> cljs.core.PersistentVector.fromArray ([1368215576857, 203.99], true),
> cljs.core.PersistentVector.fromArray ([1368215577765, 203.99], true),
> cljs.core.PersistentVector.fromArray ([1368215578769, 204], true),
> cljs.core.PersistentVector.fromArray ([1368215579272, 204.01], true),
> cljs.core.PersistentVector.fromArray ([1368215579517, 204.02], true),
> cljs.core.PersistentVector.fromArray ([1368215581769, 204.02], true),
> cljs.core.PersistentVector.fromArray ([1368215583602, 204.01], true),
> cljs.core.PersistentVector.fromArray ([1368215585650, 204.02], true),
> cljs.core.PersistentVector.fromArray ([1368215586060, 204.02], true),
> cljs.core.PersistentVector.fromArray ([1368215587029, 204.01], true),
> cljs.core.PersistentVector.fromArray ([1368215588318, 204.02], true),
> cljs.core.PersistentVector.fromArray ([1368215589335, 204.01], true),
> cljs.core.PersistentVector.fromArray ([1368215589536, 204.01], true),
> cljs.core.PersistentVector.fromArray ([1368215589846, 204], true),
> cljs.core.PersistentVector.fromArray ([1368215591079, 203.99], true),
> cljs.core.PersistentVector.fromArray ([1368215591789, 203.99], true),
> cljs.core.PersistentVector.fromArray ([1368215592104, 203.98], true),
> cljs.core.PersistentVector.fromArray ([1368215592615, 203.98], true),
> cljs.core.PersistentVector.fromArray ([1368215592758, 203.99], true),
> cljs.core.PersistentVector.fromArray ([1368215594039, 203.97], true),
> cljs.core.PersistentVector.fromArray ([1368215597119, 203.98], true),
> cljs.core.PersistentVector.fromArray ([1368215597632, 203.97], true),
> cljs.core.PersistentVector.fromArray ([1368215599396, 203.97], true),
> cljs.core.PersistentVector.fromArray ([1368215603876, 203.96], true),
> cljs.core.PersistentVector.fromArray ([1368215606059, 203.96], true),
> cljs.core.PersistentVector.fromArray

Re: Released lein-cljsbuild 0.3.1

[David Nolen]

Thanks!

On Saturday, May 11, 2013, Evan Mezeske wrote:

> Nothing major in this release other than some bugfixes and bringing the
> default ClojureScript version up to date.  Thanks to all contributors!
>  Release notes:
>
> https://github.com/emezeske/lein-cljsbuild/blob/master/doc/RELEASE-NOTES.md
>
> -Evan
>
> --
> --
> 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 '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  'clojure%2bunsubscr...@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  'clojure%2bunsubscr...@googlegroups.com');>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: [ANN] - purnam 0.0.9 (javascript.dot.notation language extensions for cljs)

[David Nolen]

It wasn't intentional that aset not be variadic, I'm surprised no one has
ever opened a ticket for this. Fixed in master and it inlines into
efficient javascript:

(defn bad-code [obj val]
  (aset obj "inner" "number" 10)
  (aset val "inner" "count" (+ 10 (aget obj "inner" "count")))




On Sun, May 12, 2013 at 5:37 AM, zcaudate  wrote:

> This is a quick and dirty release for interested parties. I found it very
> useful when working with angularjs. The syntax should not change that much
> but there will be more documentation in the future. I would love to have
> some input into additional features that could be added.
>
> Excerpt from Github: https://github.com/zcaudate/purnam
>
> Installation
>
> In your project file, add
>
> [purnam "0.0.9"]
>
> Why?
>
> Because the javascript dot-notation is awesome and the
> javascript/clojurescript interop (aget aset, . and .-accessors)
> make for really ugly code. Using the language-extension macros,
> clojurescript becomes more than twice as concise when working with existing
> javascript libraries (I'm mainly working with angularjs).
>
> So the use case can be seen below:
> Getters:
>
> ## javascript (12 keystrokes):
> object.a.b.c
>
> ## clojurescript (45 keystrokes):
> (-> object
>   (aget "a")
>   (aget "b")
>   (aget "c"))
>
> ## clojurescript + purnam (16 keystrokes):
> (? object.a.b.c)
>
> Setters:
>
> ## javascript (17 keystrokes):
> object.a.b.c = 10
>
> ## clojurescript (48 keystrokes):
> (-> object
>   (aget "a")
>   (aget "b")
>   (aset "c" 10))
>
> ## clojurescript + purnam (19 keystrokes):
> (! object.a.b.c 10)
>
> Functions:
>
> These are really bad examples of code but its what usually happens when
> working with existing javascript libraries. Using the dot-notation can save
> alot of screen and head space:
>
> ## javascript (~100 chars):
> var bad_code = function(obj, val){
>   obj.inner.number = 10;
>   val.inner.count = obj.inner.count + 10;}
>
> ## clojurescript (~180 chars):
> (defn bad-code [obj val]
>   (-> obj (aget "inner") (aset "number" 10))
>   (-> val
>   (aget "inner")
>   (aset "count"
> (+ 10 (-> obj (aget "inner") (aget "count")
>   nil)
>
> ## clojurescript + purnam (~110 chars):
> (def.n bad-code [obj val]
>   (! obj.inner.number 10)
>   (! val.inner.count
>  (+ 10 obj.inner.count))
>   nil)
>
> 
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Is there any particular reason for using this form?

[David Nolen]

It is necessary - integer literals default to primitive long and I'm not
sure if >= will inline if it doesn't have type information in scope. This
bit of noise could probably be removed by improving type inference in the
compiler.


On Thu, May 16, 2013 at 3:09 PM, Pavel Prokopenko <
pavel.a.prokope...@gmail.com> wrote:

> Hi,
>
> I've been reading Clojure sources in order to get a better understanding
> of how and why things work and found this implementation of nth function
> in src/clj/clojure/gvec.clj:
>
>   (nth [this i not-found]
>(let [z (int 0)]
>  (if (and (>= i z) (< i (.count this)))
>(.nth this i)
>not-found)))
>
>
> The question might sound weird, but anyway..  Is there any reason for
> doing so instead of:
>
>
>   (nth [this i not-found]
>  (if (and (>= i 0) (< i (.count this)))
>(.nth this i)
>not-found))
>
>
> or is it just a matter of taste? I'm just curious because the first form 
> seems more verbose and doesn't improve readability, though it's not complex 
> either.
>
>
> Thanks.
>
>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Is there any particular reason for using this form?

[David Nolen]

.nth is a method call, nth is a function call. Another perf thing.

In anycase if you're looking for examples of everyday Clojure it's best to
look elsewhere :) fast Clojure tends to look a bit quirky and relies on
details of the current state of the compiler.



On Thu, May 16, 2013 at 4:15 PM, Pavel Prokopenko <
pavel.a.prokope...@gmail.com> wrote:

> Thanks, David!
>
> What about (.nth this i) vs (nth this i)? Is that also some optimization
> trick like direct object's method call vs reflection method call?
>
>
> On Thursday, May 16, 2013 10:34:16 PM UTC+3, David Nolen wrote:
>>
>> It is necessary - integer literals default to primitive long and I'm not
>> sure if >= will inline if it doesn't have type information in scope. This
>> bit of noise could probably be removed by improving type inference in the
>> compiler.
>>
>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Is there any particular reason for using this form?

[David Nolen]

On Thu, May 16, 2013 at 4:30 PM, David Nolen  wrote:

> .nth is a method call, nth is a function call. Another perf thing.
>
> In anycase if you're looking for examples of everyday Clojure it's best to
> look elsewhere :) fast Clojure tends to look a bit quirky and relies on
> details of the current state of the compiler.
>

And by "fast" I mean code that for some reason or another needs to reach
the best performance offered by the host. These sorts of tricks are not
necessary to write reasonably efficient everyday code IMO.

-- 
-- 
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/groups/opt_out.

Re: core.match

[David Nolen]

On Thu, May 16, 2013 at 11:35 PM, Mark Engelberg
wrote:

> core.match has been alpha for about two years.
>
> I've been itching to use it in real projects for a long time, but with the
> alpha status, I've been reluctant to trust that it has been vetted for
> correctness.
>
> What aspects are preventing core.match from being ready for prime-time?
>
> --Mark


AOT issue and lots of bugs. I've picked it up again and spent a quite a bit
of time recently re-familiarizing and refactoring the code. Hopefully we're
not too far off from a real 0.2.0 release, which to be honest will still
mean alpha status - but expect more documentation, faster response on
tickets, and a code base that is more inviting to contribution.

David

-- 
-- 
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/groups/opt_out.

core.logic: Negation As Failure

[David Nolen]

I've finally got around to adding a negation as failure operator `nafc` to
core.logic. The constraint framework has allowed this to be done while
avoided the many pitfalls you might encounter with this operator in Prolog.
You can now write things like the following:

(run* [q]
  (membero q '(:a :b :c :d))
  (nafc membero q '(:a :b :c)))
;; => (:d)

As you can see nafc can take a goal (or constraint) and list of arguments
and produce a negated goal. The main limitation is that negated goals will
not run until the arguments are ground (fully instantiated). This is to
avoid the issues normally found in Prolog.

This is very experimental but I'm excited that it will simplify the writing
of many interesting core.logic programs.

This is available in master. Feedback very welcome!

David

-- 
-- 
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/groups/opt_out.

Re: ClojureScript: spurious warning about symbol not being a protocol

[David Nolen]

Looks like a bug, please open a ticket in JIRA with the example code.
Thanks!

David


On Tue, May 21, 2013 at 1:16 AM, Praki  wrote:

> Hi,
>
> For reasons I cant quite fathom, "lein cljsbuild" generates "Symbol X is
> not a protocol" warning. I am using clojure 1.5.1 and cljsbuild 0.3.2. The
> following code snippet reproduces the issue. Please note that renaming
> "my.foo" namespace to "foo" compiles with no warning.
>
> ;; file:: foo.cljs
> (ns my.foo)
>
> (defprotocol IFoo
>   (bar[this]))
>
> ;; file: fubar.cljs
> (ns fubar
>   (:require
>[my.foo :as foo]))
>
> (deftype FuBar []
>   foo/IFoo
>   (bar [this]))
>
> cljs output:
> WARNING: Symbol foo/IFoo is not a protocol at line 5 src/fubar.cljs
> Successfully compiled "target/classes/public/singularis.js" in 8.822898574
> seconds.
>
> I can live to ignore this as it seems to be a spurious warning but
> perchance anybody has any thoughts/suggestions to fix this, it would be
> great.
>
> Thanks.
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Has anyone here played with Wisp?

[David Nolen]

It's another interesting Lisp variant to JavaScript compiler but besides a
surface like similarity, it doesn't really preserve many of Clojure's
semantics (keyword behavior, data structures, immutability, notion of
truth, protocols, multimethods, etc).

David


On Sat, May 25, 2013 at 1:59 AM, Rich Morin  wrote:

> I saw  mention of Wisp the other day (on Hacker News, IIRC), but I
> haven't noticed any discussion of it on the Clojure email list,
> (def newsletter), etc:
>
>   Wisp is a homoiconic JavaScript dialect with clojure syntax,
>   s-expressions and macros.  Unlike clojurescript, Wisp code
>   compiles to human-readable JavaScript.  The goal of Wisp is
>   to compile to the JavaScript you would have written anyway.
>   Think of Wisp asmarkdown for JS programing!
>
>   Homoiconic syntax and macros are the primary motivations!
>
>   -- https://github.com/Gozala/wisp
>
>   See also   http://jeditoolkit.com/try-wisp/
>
> Has anyone here played with Wisp?  Any reactions?
>
> -r
>
>  --
> http://www.cfcl.com/rdmRich Morin
> http://www.cfcl.com/rdm/resume r...@cfcl.com
> http://www.cfcl.com/rdm/weblog +1 650-873-7841
>
> Software system design, development, and documentation
>
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Knowledge derivation in core.logic?

[David Nolen]

I think Nada Amin has already done something like this with the nominal
feature and at least her version was quite simple. Best to ask this
question on the miniKanren/core.logic mailing list -
http://groups.google.com/forum/#!forum/minikanren

David


On Sat, May 25, 2013 at 8:44 PM, Adam Saleh  wrote:

> Hi,
>
> I am trying to implement a simple knowledge derivation program in
> clojure.core.logic,
> and I am not sure how to approach it. To be more specific, after I am
> done, it will be used as a toy cryptographic protocol verifier,
> that tries to infer what knowledge can attacker get based on some initial
> knowledge and some rules.
>
> For example, I might denote [:pk A] a knowledge of public key of somebody
> and [:pcrypted [:pk A] :nonce] an encrypted nonce sent to this person.
>
> Then I'd like be able to somehow specify, that if I know [:pk A], I know
> as well [:pcrypted [:pk A] [:nonce A]] and therefore my program would
> derive from initial knowledge
>
> [ [:pk :a]  [:pk :b] ] the full knowledge [[:pk :a]  [:pk :b] [:pcrypted
> [:pk :a] [:nonce :a]] [:pcrypted [:pk :b] [:nonce :b]]]
>
> Or in slightly more difficult case to specify that if I know a secret key
> [:sk A] and encrypted nonce [:pcrypted [:pk A] [:nonce A]], I also know the
> [:nonce a].
>
> Anybody has any hints?
>
> So far I managed to implement some of this, but it is a tangled mess of
> recursive pattern matching, membero, nonmembero and macros :-/
>
> Thanks for any pointers,
>
> Adam
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: The Reasoned Schemer chpt 4: "Please pass the aspirin"

[David Nolen]

+1


On Sat, May 25, 2013 at 8:12 PM, Austin Haas  wrote:

>
> Hi Brian,
>
> You should post your question to the miniKanren Google group.
>
> minikan...@googlegroups.com
>
> -austin
>
> --
> Austin Haas
> Pet Tomato, Inc.
> http://pettomato.com
>
>
> On Sat May 25 10:21 , Brian Craft wrote:
> > Wondering if anyone can give me some pointers with this, as I dive into
> > logic programming. Or point me to a more appropriate forum, if this is
> the
> > wrong one. I know a lot of you have been trying out core.logic.
> >
> > It was all going well until chapter four. The story so far: introduce
> some
> > simple function, like cdr, then develop a logic programming equivalent,
> > repeat. Then in chapter four we get the second commandment, and the
> > equivalent functions stop being equivalent. Instead, they generate
> > meaningless results, like 4.18, where the value of z is irrelevant to
> > whether the equivalent function (mem) would succeed, since the target
> > pattern appears earlier in the list, but memo outputs an infinite number
> of
> > the target pattern. Or they generate incorrect results, like 4.31, where
> > some of the patterns do not satisfy the equivalent function (rember),
> like
> > (a  b _.0 d e): z can't be removed unless it unifies with y, in which
> case
> > y would have been removed, not z. The chapter concludes by highlighting
> > this issue with "surprise", a simple example which generates solutions
> that
> > don't satisfy the constraints.
> >
> > I was hoping, at that point, for insights into accurately translating
> > functions into their logic programming equivalents, however the chapter
> > ends with "Please pass the aspirin", and the book continues with more
> > "second commandment" examples that also produce unhelpful results.
> >
> > So, I'm a bit baffled about the point of this exercise. Why is it useful
> to
> > have a second commandment that converts functions into logic programming
> > functions that are superficially similar, but fundamentally different,
> > producing solutions that are irrelevant or incorrect for the original
> > function? Is there some different technique that would allow one to
> > generate correct solutions with logic programming?
> >
> > --
> > --
> > 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/groups/opt_out.
> >
> >
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[David Nolen]

Doesn't ritz support nrepl? http://github.com/pallet/ritz


On Mon, May 27, 2013 at 5:53 PM, Mark Engelberg wrote:

> I would be a lot happier with the state of Clojure debugging if, in
> addition to a stacktrace, I could easily explore the local variables in
> play when an error was triggered.  It was possible to do this in earlier
> Clojure environments, but the capability seems to have been lost in the
> transition to nrepl.
>
>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: ClojureScript at its best

[David Nolen]

Capital One's Level Money https://www.levelmoney.com
Thomas Reuters https://open.mediaexpress.reuters.com

There's a list of companies that gets periodically updated here:
https://github.com/clojure/clojurescript/wiki/Companies-Using-ClojureScript

David

On Tue, Mar 1, 2016 at 1:10 AM, Alex Miller  wrote:

> A few that come to mind...
>
> https://circleci.com/ is written in ClojureScript and is available at
> https://github.com/circleci/frontend
>
> https://precursorapp.com/ is another CLJS app
>
> https://github.com/jackschaedler/goya is a pixel editor written in CLJS
>
>
> On Monday, February 29, 2016 at 8:54:04 PM UTC-6, Richard Eng wrote:
>>
>> What's a great example of a production ClojureScript web application that
>> showcases ClojureScript's best qualities? I'm looking for something
>> impressive. A URL would be nice. Thanks.
>>
> --
> 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: ANN: ClojureScript 1.8.34

[David Nolen]

Thanks for the report! Will need to think about how to deal with other
tooling possibly including additional options we don't understand - we now
warn on options we don't support to avoid unnecessary confusion.

David

On Fri, Mar 18, 2016 at 7:01 PM, Rangel Spasov  wrote:

> Thanks, David!
>
> I get those warnings when compiling via "lein figwheel":
>
> WARNING: Unknown option ':compiler-env'.
>
> WARNING: Unknown option ':special-fns'.
>
> WARNING: Unknown option ':warn-on-undeclared'.
>
>
> Otherwise, everything seems fine.
>
> Rangel
>
> On Friday, March 18, 2016 at 11:04:46 AM UTC-7, David Nolen wrote:
>>
>> ClojureScript, the Clojure compiler that emits JavaScript source code.
>>
>> README and source code: https://github.com/clojure/clojurescript
>>
>> Leiningen dependency information:
>>
>> [org.clojure/clojurescript "1.8.34"]
>>
>> There are many minor fixes in this release around bootstrapped
>> ClojureScript. This release also fixes a subtle bug with the
>> new :parallel-build feature.
>>
>> As always feedback welcome!
>>
>> ## 1.8.34
>>
>> ### Changes
>> * CLJS-1582: Type-hint extend-type first arg for primitives
>> * CLJS-1590: split, split-lines differs from Clojure on empty string
>> * CLJS-1594: NaN and both infinities cannot be elements of a set
>> * CLJS-1597: Redundant IPrintWithWriter test in pr-writer-impl
>> * CLJS-1583: (hash (symbol "/")) does not match (hash '/)
>> * bump tools reader
>> * CLJS-1492: Warn when using :optimisations instead of :optimizations
>> * less cryptic error if :main doesn't correspond to any file
>> * CLJS-744: ISequential types should implement JS indexOf, lastIndexOf
>> * CLJS-1411: make-array signature differs from clojure
>>
>> ### Fixes
>> * CLJS-1589: Self-host: case fail with nil
>> * CLJS-1596: Self-host: :load-macros and :analyze-deps don't work in
>> cljs.js
>> * CLJS-1420: get-in behavior differs from Clojure by always deferring to
>> the 3 arity fn
>> * CLJS-1585: Self-host: Alias-scoped keywords
>> * CLJS-1577: Self-host: syntax-quote resolves on dot forms
>> * CLJS-1564: Self-host: cached macro *loaded* update
>> * CLJS-1584: Self-host: core/str error with condp
>> * CLJS-1521: Self-host: Macro namespaces cannot be aliased
>> * CLJS-1573: Self-host: Invalid UTF escaping in cljs-in-cljs
>> * CLJS-1570: :parallel-build causes invalid truth check in
>> cljs.reader/read-number
>> * CLJS-1568: LazyTransformer doesn't implement IMeta
>> * CLJS-1578: Corrupted Analysis Files Break Compilation
>> * CLJS-1579: cljs.source-map/invert-reverse-map discards gcol
>> * CLJS-1580: Self-host: goog.provide offsets source-maps
>> * CLJS-1569: IndexedSeq doesn't implement IWithMeta / IMeta
>> * CLJS-1567: make-array macro missing > 2 arg arity
>> * CLJS-1571: Make special-symbol? true for 'var
>> * CLJS-1555: make-array macro missing 2 arg arity
>> * CLJS-970: generate assert message when compiling
>> * CLJS-1565: Self-host: whitespace optimization is broken
>> * CLJS-1541: Self-host: Cannot require 'cljs.js using cljs.jar
>> * CLJS-1550: Enhance docstring for extend-type wrt type-sym
>> * CLJS-1551: Self-host: assert-args dormant in macros
>> * CLJS-1552: doc for & should match fn
>> * CLJS-1488: cljs.repl/source Cannot read source of cljs functions that
>> use #js reader
>> * CLJS-1557: Make special-symbol? return true for catch and finally
>> * CLJS-1542: Self-host: cljs/compile-str not handling errors properly
>> * CLJS-1318: Fix typo in documentation of `specify`
>> * CLJS-620: Warnings are generated when using a macro in argument position
>> * CLJS-1547: Wrong output encoding when compile with goog.LOCALE
>> * CLJS-1546: cljs.core/run! does not always return nil
>>
>> --
> 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 h

ANN: ClojureScript 1.8.34

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.8.34"]

There are many minor fixes in this release around bootstrapped
ClojureScript. This release also fixes a subtle bug with the
new :parallel-build feature.

As always feedback welcome!

## 1.8.34

### Changes
* CLJS-1582: Type-hint extend-type first arg for primitives
* CLJS-1590: split, split-lines differs from Clojure on empty string
* CLJS-1594: NaN and both infinities cannot be elements of a set
* CLJS-1597: Redundant IPrintWithWriter test in pr-writer-impl
* CLJS-1583: (hash (symbol "/")) does not match (hash '/)
* bump tools reader
* CLJS-1492: Warn when using :optimisations instead of :optimizations
* less cryptic error if :main doesn't correspond to any file
* CLJS-744: ISequential types should implement JS indexOf, lastIndexOf
* CLJS-1411: make-array signature differs from clojure

### Fixes
* CLJS-1589: Self-host: case fail with nil
* CLJS-1596: Self-host: :load-macros and :analyze-deps don't work in cljs.js
* CLJS-1420: get-in behavior differs from Clojure by always deferring to
the 3 arity fn
* CLJS-1585: Self-host: Alias-scoped keywords
* CLJS-1577: Self-host: syntax-quote resolves on dot forms
* CLJS-1564: Self-host: cached macro *loaded* update
* CLJS-1584: Self-host: core/str error with condp
* CLJS-1521: Self-host: Macro namespaces cannot be aliased
* CLJS-1573: Self-host: Invalid UTF escaping in cljs-in-cljs
* CLJS-1570: :parallel-build causes invalid truth check in
cljs.reader/read-number
* CLJS-1568: LazyTransformer doesn't implement IMeta
* CLJS-1578: Corrupted Analysis Files Break Compilation
* CLJS-1579: cljs.source-map/invert-reverse-map discards gcol
* CLJS-1580: Self-host: goog.provide offsets source-maps
* CLJS-1569: IndexedSeq doesn't implement IWithMeta / IMeta
* CLJS-1567: make-array macro missing > 2 arg arity
* CLJS-1571: Make special-symbol? true for 'var
* CLJS-1555: make-array macro missing 2 arg arity
* CLJS-970: generate assert message when compiling
* CLJS-1565: Self-host: whitespace optimization is broken
* CLJS-1541: Self-host: Cannot require 'cljs.js using cljs.jar
* CLJS-1550: Enhance docstring for extend-type wrt type-sym
* CLJS-1551: Self-host: assert-args dormant in macros
* CLJS-1552: doc for & should match fn
* CLJS-1488: cljs.repl/source Cannot read source of cljs functions that use
#js reader
* CLJS-1557: Make special-symbol? return true for catch and finally
* CLJS-1542: Self-host: cljs/compile-str not handling errors properly
* CLJS-1318: Fix typo in documentation of `specify`
* CLJS-620: Warnings are generated when using a macro in argument position
* CLJS-1547: Wrong output encoding when compile with goog.LOCALE
* CLJS-1546: cljs.core/run! does not always return nil

-- 
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.

ANN: ClojureScript 1.8.40

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.8.40"]

This release addresses some minor unintentional interactions with 3rd party
ClojureScript tooling like Figwheel.

As always feedback welcome!

## 1.8.40

### Fixes
* CLJS-1603: Only warn for misspelled comp/REPL opts
* :warning-handlers missing for known compiler options
* CLJS-1592: Self-host: Robustness for core tests

-- 
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.

ANN: ClojureScript 1.8.51

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.8.51"]

This release updates the Closure Compiler and tools.reader dependencies,
fixes a race condition with :parallel-build, improves JS module
integration, and includes a number of enhancements and fixes around
optional self hosting. A big thanks to everyone who contributed!

As always feedback welcome.

## 1.8.51

### Changes
* bump Closure Compiler to v20160315
* bump tools.reader to 1.0.0-beta1
* CLJS-1624: Avoid useage of JSC_HOME in test bash scripts

### Enhancements
* CLJS-1626: cljs.test for bootstrap

### Fixes
* CLJS-1588: defrecord satisfies? behavior under bootstrap
* CLJS-1632: docs / arglist consistency
* CLJS-1612: Resolve ns aliases in syntax-quote
* CLJS-1621: Foreign libs modules of different types don't compile together
* CLJS-1617: inlined `list` evaluation order
* :parallel-build race condition

-- 
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: clojure.spec

[David Nolen]

clojure.spec has been ported to cljs.spec now available in ClojureScript
master. Will probably cut a release later next week but users are
encouraged to build master and give it a spin.

David

On Mon, May 23, 2016 at 10:12 AM, Rich Hickey  wrote:

> Introducing clojure.spec
>
> I'm happy to introduce today clojure.spec, a new core library and support
> for data and function specifications in Clojure.
>
> Better communication
>
> Clojure is a dynamic language, and thus far we have relied on
> documentation or external libraries to explain the use and behavior of
> functions and libraries. But documentation is difficult to produce, is
> frequently not maintained, cannot be automatically checked and varies
> greatly in quality. Specs are expressive and precise. Including spec in
> Clojure creates a lingua franca with which we can state how our programs
> work and how to use them.
>
> More leverage and power
>
> A key advantage of specifications over documentation is the leverage they
> provide. In particular, specs can be utilized by programs in ways that docs
> cannot. Defining specs takes effort, and spec aims to maximize the return
> you get from making that effort. spec gives you tools for leveraging specs
> in documentation, validation, error reporting, destructuring,
> instrumentation, test-data generation and generative testing.
>
> Improved developer experience
>
> Error messages from macros are a perennial challenge for new (and
> experienced) users of Clojure. specs can be used to conform data in macros
> instead of using a custom parser. And Clojure's macro expansion will
> automatically use specs, when present, to explain errors to users. This
> should result in a greatly improved experience for users when errors occur.
>
> More robust software
>
> Clojure has always been about simplifying the development of robust
> software. In all languages, dynamic or not, tests are essential to quality
> - too many critical properties are not captured by common type systems.
> spec has been designed from the ground up to directly support generative
> testing via test.check https://github.com/clojure/test.check. When you
> use spec you get generative tests for free.
>
> Taken together, I think the features of spec demonstrate the ongoing
> advantages of a powerful dynamic language like Clojure for building robust
> software - superior expressivity, instrumentation-enhanced REPL-driven
> development, sophisticated testing and more flexible systems. I encourage
> you to read the spec rationale and overview  http://clojure.org/about/spec.
> Look for spec's inclusion in the next alpha release of Clojure, within a
> day or so.
>
> Note that spec is still alpha, and some details are likely to change.
> Feedback welcome.
>
> I hope you find spec useful and powerful!
>
> Rich
>
> --
> 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.

ANN: ClojureScript 1.9.14, clojure.spec port

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.14"]

This release includes a complete and faithful port of clojure.spec to
ClojureScript. The functionality resides in the new cljs.spec
namespace. All features present in Clojure 1.9.0-alpha4 are
implemented, including REPL support, testing support and macro
checking.

As always feedback welcome.

## 1.9.14

### Enhancements
* clojure.spec ported to cljs.spec

### Fixes
* CLJS-1649: Possible issue with in cljs.reader or
cljs.core/PersistentHashMap
* CLJS-1647: Rethrow exception from parallel-build
* CLJS-1642: cljs.core/reductions does not respect 'reduced'
* CLJS-1635: Var type implements IEquiv but not IHash
* CLJS-1629: Fix warning about duplicate test-pr-str
* CLJS-1637: Missing docstrings for a few vars

-- 
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: Clojurescript macros evaluate?

[David Nolen]

Nothing to do with macros, that wouldn't work in Clojure either, the
problem is only the namespaced keyword - ::tiltontec.qxia.base/m.Composite

Note the leading double colon, ::

The :: indicates that tiltontec.qxia.base is an ns alias, which clearly
it's not since it's the fully qualified name. Just drop the extra : and you
should be good to go.

David

-- 
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: [ClojureScript] Re: ANN: ClojureScript 1.9.14, clojure.spec port

[David Nolen]

Choosing cljs.spec over clojure.spec is out of necessity not preference -
Clojure has already taken the namespace and that namespace defines macros.

We are considering aliasing support for cljs.spec. That is rewriting
clojure.spec vars in ClojureScript sources to cljs.spec but it will likely
cover more than just cljs.spec - cljs.test, cljs.pprint etc.

David

On Wed, Jun 1, 2016 at 10:27 PM, Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

> Would it be good to change the namespace for spec from cljs.spec to
> clojure.spec? This will make CLJC files nicer to write as you won’t need to
> have reader conditionals for requiring cljs.spec in CLJS and clojure.spec
> in CLJ.
>
> It seems like spec is going to be used by lots of projects, so the choices
> made now will affect lots of code, and be hard to change later.
>
> More generally, what are the guidelines for deciding if a ClojureScript
> file gets written as cljs.* or clojure.*?
>
> On Thu, Jun 2, 2016 at 9:19 AM Walter van der Laan <
> waltervanderl...@fincite.nl> wrote:
>
>> It's like magic. I added some specs to cljc namespaces and it just works!
>>
>> I'm making domain specific error messages with just a few lines of code.
>> This is a huge leap forward.
>>
>> Thank you, and all involved, so much.
>>
>> --
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ClojureScript" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojurescript+unsubscr...@googlegroups.com.
>> To post to this group, send email to clojurescr...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/clojurescript.
>>
> --
> —
> Daniel
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/clojurescript.
>

-- 
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.

ANN: ClojureScript 1.9.36 - cljs.spec fixes & performance enhancements

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.36"]

This release fixes a cljs.spec bug around instrumented multi-arity
fns. It also includes various fixes and performance enhancements from
Clojure. Another performance related change is writing out analysis
caches as Transit if transit-clj is available. This is automatic and
requires no configuration and gives a modest speed bump when launching
REPLs.

As always feedback welcome!

## 1.9.36

### Enhancements
* Write analysis caches as Transit if transit-clj available

### Changes
* Clojure 1f25347
* Clojure 47b8d6b
* Optimize seq (&) destructuring as per commit (0aa3467) of Clojure

### Fixes
* CLJS-1611: Function arity dispatch returns arity
* only print specs in REPL if we actually have some
* CLJS-1663: Calling instrumented multi-arity function causes exception
* CLJS-1650: `cljs.reader/read-map` now returns array-map/hash-map based on
the size of the sequence.

-- 
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.

ANN: ClojureScript 1.9.76

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.76"]

This release brings cljs.spec to parity with Clojure 1.9.0-alpha7. It
addresses an issue with Transit analysis caching, includes fixes for
cljs.spec support under bootstrapped, bumps the Closure library
dependency, and includes other minor fixes and enhancements.

As always feedback welcome!

## 1.9.76

### Enhancements
* CLJS-1648: Getting Source Info into ex-info data for Analysis Errors
* cljs.spec updated to Clojure 1.9.0-alpha7 changes

### Changes
* bump Google Closure Library dep
* AOT cljs.spec nses

### Fixes
* CLJS-1679: Self-host: Incorporate spec tests
* CLJS-1680: Self-host: Don't require items no longer provided by Closure
* CLJS-1654: cljs.spec: var name in s/fdef non-conformance
* CLJS-1655: cljs.spec: conformer docstring indicates :clojure.spec/invalid
* CLJS-1656: Self-host: cljs.spec: speced-vars* fn not resolving
* CLJS-1661: cljs.spec: non-spec'ed fn var printing
* compute read/write opts for transit if possible, handle JSValue
* CLJS-1660: cljs.spec: Always return var from instrument / unstrument
* CLJS-1671: Bad cljs.spec interactive instrumentation session
* CLJS-1664: The filename aux.cljs is a problem on windows.
* CLJS-1667: bad describe* for and-spec-impl
* CLJS-1699: Self-host: s/fdef ns-qualify *ns* name field access

-- 
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.

ANN: ClojureScript 1.9.89 - cljs.spec & :preloads

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.89"]

This release fixes several cljs.spec issues. It also includes a new
compiler option - :preloads. This feature is designed to simplify (but
not limited to) the loading of development time side effects such as
enabling printing, REPL connections, and browser tool
integration. With :preloads you may now specify a sequence of
namespaces as symbols to load in order immediately after cljs.core. This
also
means there's a path for providing typical boilerplate as documented
namespaces that users can specify in their dev builds.

As always feedback welcome!

## 1.9.89

### Enhancements
* CLJS-1688: :preloads compiler option for loading other entry points prior
to :main
* cljs.spec - support gen overrides by name in addition to path
* cljs.spec - every and every-kv

### Changes
* added bounded-count

### Fixes
* missing cljs.spec/fn-specs -> cljs.spec/get-spec in cljs.spec.test ns
* CLJS-1687: Self-host: cljs.spec: inst-in-range? and int-in-range? need
qualification
* CLJS-1668: cljs.spec: c alias needs expansion in int-in

-- 
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: is there a way to report an argument number in spec?

[David Nolen]

clojure.spec already does this by communicating the path where the failure
occurred. Also if you use s/cat you can label the arguments which I think
is probably more friendly and you'll still get the path.

(require '[cljs.spec :as s])
(defn foo [a b c] (+ a b c))
(s/fdef foo
  :args (s/cat :a number? :b number? :c number?))
(s/instrument #'foo)
(foo 1 2 :bar)

;; Error: Call to #'cljs.user/foo did not conform to spec:
;; In: [2] val: :bar fails at: [:args :c] predicate: number?
;; :cljs.spec/args  (1 2 :bar)

On Thu, Jun 23, 2016 at 11:41 AM, Elena Machkasova 
wrote:

> I am trying to use a combination of fdef and instrument in spec, and I was
> wondering if there is a way to apply a condition to each of the :args and
> be able to report the argument number on which the precondition fails. For
> instance, we require all args (in a function with a variable number of
> arguments) to be numbers, and get the message that says that the third
> argument has failed this condition.
>
> Thanks!
>
> Elena
>
>
> --
> 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.

ANN: ClojureScript 1.9.198 - cljs.spec, core ns aliasing, macro inference, :rename, and more!

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.198"]

This release brings cljs.spec to parity with Clojure
1.9.0-alpha10. This release also includes a large number of
enhancements to the ns form:

* :refer now features macro inference. There is no longer any need
  to supply both :refer and :refer-macros in the same :require, the
  compiler will figure it out.

* clojure.* namespaces will now automatically be aliased to their
  ClojureScript equivalents. For example this means that the following
  is perfectly valid ClojureScript:

  (ns foo.bar
(:require [clojure.spec :refer [fspec]]))

  This feature and the previous one should significantly reduce reader
  conditional usage in ns forms.

* thanks to Antonio Monteiro we now support :rename

We also have a new feature that is relevant for tooling such as
Figwheel and cljs-devtools - :preloads. This should now be the
standard way to inject some bit of side-effecting setup after core but
before user code (i.e. connecting REPLs to standard ports, etc.).

There are of course many various small fixes and enhancements, so
a very big thank you to everyone that has contributed.

As always feedback welcome!

## 1.9.198

### Enhancements
* CLJS-1508: Extend ns form to support :rename option
* CLJS-1507: Implicit macro loading: macro var inference in :refer
* CLJS-1692: Autoalias clojure.* to exisiting cljs.* namespaces if
possible
* CLJS-1350: Compiler support for browser REPL
* CLJS-1729: Support `use` special function in REPLs
* CLJS-1730: Support `refer-clojure` special function in REPLs

### Changes
* CLJS-1515: Self-host: Allow :file key in cljs.js/*load-fn*
* add toString implementation to Vars
* Use a js array to create collections in cljs.reader
* CLJS-1640: Use the unshaded version of the closure compiler
* add :browser-repl to list of known opts
* add browser REPL preload
* parity with Clojure 1.9.0-alpha10 clojure.spec
* bump to tools.reader 1.0.0-beta3

### Fixes
* CLJS-1733: Macro inference issue for macros & runtime vars with the same
name
* CLJS-1735: Self-host: cljs.spec speced-vars instance
* CLJS-1736: cljs.spec.test: checkable-syms* called with 0-arity
* CLJS-1708: Self-host: [iu]nstrument-1 needs to qualify [iu]nstrument-1*
* CLJS-1707: Self-host: with-instrument-disabled needs to qualify
*instrument-enabled*
* CLJS-1732: Add docstrings for new use and use-macros REPL specials
* CLJS-1720: Qualify symbols and namespaced keywords in spec macros
* CLJS-1731: Self-host: do_template problem with script/test-self-parity
* CLJS-1556: Invalid code emit for obj literal
* CLJS-1607: bug with `specify!` in JS prototypes with `static-fns` true
* CLJS-1591 avoid analyzing invoke arguments multiple times
* CLJS-1638: :elide-asserts disables atom validators in :advanced
* CLJS-1721: 3-arity get-in fails on types which do not implement ILookup
* CLJS-1728: Update doc for ns for new :rename capability
* CLJS-1727: Regression when evaluating non-sequential forms at the REPL
* CLJS-1490: Watch macro files in cljs.build.api/watch
* CLJS-1719: Port destructuring namespaced keys and symbols
* CLJS-1653: cljs.spec: keys* causes exception
* CLJS-1700: Support clojure.* aliasing when not in vector
* CLJS-1717 remove map from equiv-map
* CLJS-1716: No longer possible to use same alias for :require-macros and
:require
* Use keyword options in js->clj 1-arg impl
* Add support for regex in transit for compiler analysis cache
* Escape non-Latin1 characters before base64 encoding the source-map string
* CLJS-1698: cljs.spec: every res call needs &env
* CLJS-1695: Self-host: Port cljs / clojure namespace aliasing
* CLJS-1697: doc on inferred macros fails
* CLJS-1699: Update docstring for ns
* CLJS-1694: Self-host: Port macro var inference in :refer

-- 
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: [ClojureScript] Re: ANN: ClojureScript 1.9.198 - cljs.spec, core ns aliasing, macro inference, :rename, and more!

[David Nolen]

analyze_form.invokeStatic(analyzer.cljc:2838)
> at cljs.analyzer$analyze_form.invoke(analyzer.cljc:2834)
> at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:2885)
> at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2876)
> at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2901)
> at cljs.analyzer$analyze.invoke(analyzer.cljc:2888)
> at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2896)
> at cljs.analyzer$analyze.invoke(analyzer.cljc:2888)
> at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2895)
> cljs.user=> at cljs.analyzer$analyze.invoke(analyzer.cljc:2888)
> at cljs.analyzer$eval2573$fn__2575.invoke(analyzer.cljc:1121)
> at clojure.lang.MultiFn.invoke(MultiFn.java:251)
> at cljs.analyzer$analyze_seq_STAR_.invokeStatic(analyzer.
> cljc:2694)
> at cljs.analyzer$analyze_seq_STAR_.invoke(analyzer.cljc:2692)
> at cljs.analyzer$analyze_seq_STAR__wrap.invokeStatic(
> analyzer.cljc:2699)
> at cljs.analyzer$analyze_seq_STAR__wrap.invoke(analyzer.cljc:2697)
> at cljs.analyzer$analyze_seq.invokeStatic(analyzer.cljc:2720)
> at cljs.analyzer$analyze_seq.invoke(analyzer.cljc:2701)
> at cljs.analyzer$analyze_form.invokeStatic(analyzer.cljc:2838)
> at cljs.analyzer$analyze_form.invoke(analyzer.cljc:2834)
> at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:2885)
> at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2876)
> at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2901)
> at cljs.analyzer$analyze.invoke(analyzer.cljc:2888)
> at cljs.repl$evaluate_form$fn__7452.invoke(repl.cljc:484)
> at cljs.repl$evaluate_form.invokeStatic(repl.cljc:483)
> at cljs.repl$evaluate_form.invoke(repl.cljc:440)
> at cljs.repl$eval_cljs.invokeStatic(repl.cljc:575)
> at cljs.repl$eval_cljs.invoke(repl.cljc:568)
> at cljs.repl$repl_STAR_$read_eval_print__7598.invoke(repl.
> cljc:921)
> at cljs.repl$repl_STAR_$fn__7604$fn__7613.invoke(repl.cljc:960)
> at cljs.repl$repl_STAR_$fn__7604.invoke(repl.cljc:959)
> at cljs.compiler$with_core_cljs.invokeStatic(compiler.cljc:1154)
> at cljs.compiler$with_core_cljs.invoke(compiler.cljc:1145)
> at cljs.repl$repl_STAR_.invokeStatic(repl.cljc:923)
> at cljs.repl$repl_STAR_.invoke(repl.cljc:806)
> at cemerick.piggieback$run_cljs_repl.invokeStatic(piggieback.
> clj:169)
> at cemerick.piggieback$run_cljs_repl.invoke(piggieback.clj:155)
> at clojure.lang.AFn.applyToHelper(AFn.java:171)
> at clojure.lang.AFn.applyTo(AFn.java:144)
> at clojure.core$apply.invokeStatic(core.clj:650)
> at clojure.core$apply.invoke(core.clj:641)
> at cemerick.piggieback$evaluate.invokeStatic(piggieback.clj:258)
> at cemerick.piggieback$evaluate.invoke(piggieback.clj:254)
> at clojure.lang.Var.invoke(Var.java:379)
> at cemerick.piggieback$wrap_cljs_repl$fn__33010$fn__33012$fn__
> 33013.invoke(piggieback.clj:290)
> at cemerick.piggieback$enqueue$fn__32996.invoke(piggieback.
> clj:246)
> at clojure.tools.nrepl.middleware.interruptible_eval$
> run_next$fn__15308.invoke(interruptible_eval.clj:190)
> at clojure.lang.AFn.run(AFn.java:22)
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: clojure.lang.ArityException: Wrong number of args (-1) passed
> to: spec/res
> at cljs.analyzer$macroexpand_1_STAR_$fn__3161.invoke(
> analyzer.cljc:2643)
> at cljs.analyzer$macroexpand_1_STAR_.invokeStatic(analyzer.
> cljc:2640)
> at cljs.analyzer$macroexpand_1_STAR_.invoke(analyzer.cljc:2625)
> ... 173 more
>
>
> Is this a bug?
>
>
> 在 2016年8月13日星期六 UTC+8上午3:50:20，David Nolen写道：
> > ClojureScript, the Clojure compiler that emits JavaScript source code.
> >
> >
> > README and source code: https://github.com/clojure/clojurescript
> >
> >
> > Leiningen dependency information:
> >
> >
> > [org.clojure/clojurescript "1.9.198"]
> >
> >
> > This release brings cljs.spec to parity with Clojure
> > 1.9.0-alpha10. This release also includes a large number of
> > enhancements to the ns form:
> >
> >
> > * :refer now features macro inference. There is no longer any need
> >   to supply both :refer and :refer-macros in the same :require, the
> >   compiler will figure it ou

ANN: ClojureScript 1.9.211, cljs.spec fixes

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.211"]

This release addresses a few bugs around cljs.spec discovered in the
last release along with relevant fixes for self-hosted ClojureScript.

As always feedback welcome!

## 1.9.211

### Fixes
* CLJS-1746: Log the result of loading a dependency
* CLJS-1657: Self-host: Implicit macro loading with alias
* CLJS-1742: Add docstring for new refer-clojure REPL special
* CLJS-1274: Allow assignment to namespace-qualified names in current
namespace
* CLJS-1744: rest produces nil for larger maps
* CLJS-1740: Self-host: Need to port more of CLJS-1733
* CLJS-1741: Add :rename to :refer-clojure in ns docstring
* CLJS-1737: Self-host: clojure alias implicit macro use regression
* invalid cljs.spec/merge res call
* CLJS-1739: seq on map literal with 9 elements leads to rest producing nil
* CLJS-1738: Self-host: need to update call to
check-use-macros-inferring-missing

-- 
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: ANN: ClojureScript 1.9.211, cljs.spec fixes

[David Nolen]

I just cut 1.9.216, the relevant changes are fixing a regression around
instrumenting multi-arity fns and adding spec assert.

On Mon, Aug 15, 2016 at 8:58 AM, David Nolen  wrote:

> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "1.9.211"]
>
> This release addresses a few bugs around cljs.spec discovered in the
> last release along with relevant fixes for self-hosted ClojureScript.
>
> As always feedback welcome!
>
> ## 1.9.211
>
> ### Fixes
> * CLJS-1746: Log the result of loading a dependency
> * CLJS-1657: Self-host: Implicit macro loading with alias
> * CLJS-1742: Add docstring for new refer-clojure REPL special
> * CLJS-1274: Allow assignment to namespace-qualified names in current
> namespace
> * CLJS-1744: rest produces nil for larger maps
> * CLJS-1740: Self-host: Need to port more of CLJS-1733
> * CLJS-1741: Add :rename to :refer-clojure in ns docstring
> * CLJS-1737: Self-host: clojure alias implicit macro use regression
> * invalid cljs.spec/merge res call
> * CLJS-1739: seq on map literal with 9 elements leads to rest producing nil
> * CLJS-1738: Self-host: need to update call to check-use-macros-inferring-
> missing
>
>

-- 
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.

ANN: ClojureScript 1.9.225, cljs.spec fixes

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.225"]

A bug fix release for cljs.spec and a REPL regression.

As always feedback welcome!

## 1.9.225

### Fixes
* CLJS-1759: Errors writing transit analysis cache if parallel build
* CLJS-1760: Self-host: test-cljs-1757 failing in test-self-parity
* CLJS-1751: port fix lost type hints in map destructuring
* CLJS-1756: Add test.check JAR to the bootstrap script
* CLJS-1757: cljs.spec/exercise-fn doesn't work when passed a quoted symbol
* CLJS-1754: Add boolean? generator
* fix REPL regression which removed warnings

-- 
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: ANN: ClojureScript 1.9.225, cljs.spec fixes

[David Nolen]

I just cut 1.9.227. The only change was a warning regression around
cljs.core excludes

David

On Fri, Aug 19, 2016 at 1:40 PM, David Nolen  wrote:

> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "1.9.225"]
>
> A bug fix release for cljs.spec and a REPL regression.
>
> As always feedback welcome!
>
> ## 1.9.225
>
> ### Fixes
> * CLJS-1759: Errors writing transit analysis cache if parallel build
> * CLJS-1760: Self-host: test-cljs-1757 failing in test-self-parity
> * CLJS-1751: port fix lost type hints in map destructuring
> * CLJS-1756: Add test.check JAR to the bootstrap script
> * CLJS-1757: cljs.spec/exercise-fn doesn't work when passed a quoted symbol
> * CLJS-1754: Add boolean? generator
> * fix REPL regression which removed warnings
>
>

-- 
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: ANN: ClojureScript 1.9.225, cljs.spec fixes

[David Nolen]

I just cut 1.9.229. It includes a spec fix as well as a bug around
computing the js dependency index in the presence of .cljc & .cljs files
with the same namespace.

On Fri, Aug 26, 2016 at 6:02 PM, David Nolen  wrote:

> I just cut 1.9.227. The only change was a warning regression around
> cljs.core excludes
>
> David
>
> On Fri, Aug 19, 2016 at 1:40 PM, David Nolen 
> wrote:
>
>> ClojureScript, the Clojure compiler that emits JavaScript source code.
>>
>> README and source code: https://github.com/clojure/clojurescript
>>
>> Leiningen dependency information:
>>
>> [org.clojure/clojurescript "1.9.225"]
>>
>> A bug fix release for cljs.spec and a REPL regression.
>>
>> As always feedback welcome!
>>
>> ## 1.9.225
>>
>> ### Fixes
>> * CLJS-1759: Errors writing transit analysis cache if parallel build
>> * CLJS-1760: Self-host: test-cljs-1757 failing in test-self-parity
>> * CLJS-1751: port fix lost type hints in map destructuring
>> * CLJS-1756: Add test.check JAR to the bootstrap script
>> * CLJS-1757: cljs.spec/exercise-fn doesn't work when passed a quoted
>> symbol
>> * CLJS-1754: Add boolean? generator
>> * fix REPL regression which removed warnings
>>
>>
>

-- 
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: core.logic with 1.9.0-alpha12

[David Nolen]

Oops don't think so. If you have a patch, that would be welcome.

David

On Tue, Sep 13, 2016 at 3:45 AM, 'Burt' via Clojure <
clojure@googlegroups.com> wrote:

> Hi,
>
> with "1.9.0-alpha10" and core.logic "0.8.10":
>
> (ns lwb.nd.rules
>   (:refer-clojure :exclude [==])
>   (:require [clojure.core.logic :refer :all]))
> => nil
>
> with "1.9.0-alpha12" and core.logic "0.8.10":
>
> (ns lwb.nd.rules
>   (:refer-clojure :exclude [==])
>   (:require [clojure.core.logic :refer :all]))
> CompilerException clojure.lang.ExceptionInfo: Call to clojure.core/fn did
> not conform to spec:
> In: [0] val: clojure.core.logic/-inc fails spec:
> :clojure.core.specs/arg-list at: [:args :bs :arity-1 :args] predicate:
> vector?
> In: [0] val: clojure.core.logic/-inc fails spec:
> :clojure.core.specs/args+body at: [:args :bs :arity-n] predicate: (cat
> :args :clojure.core.specs/arg-list :prepost (? map?) :body (* any?))
> :clojure.spec/args  (clojure.core.logic/-inc [] (bind (this) g))
>  #:clojure.spec{:problems ({:path [:args :bs :arity-1 :args], :pred
> vector?, :val clojure.core.logic/-inc, :via [:clojure.core.specs/args+body
> :clojure.core.specs/arg-list :clojure.core.specs/arg-list], :in [0]} {:path
> [:args :bs :arity-n], :pred (cat :args :clojure.core.specs/arg-list
> :prepost (? map?) :body (* any?)), :val clojure.core.logic/-inc, :via
> [:clojure.core.specs/args+body :clojure.core.specs/args+body], :in [0]}),
> :args (clojure.core.logic/-inc [] (bind (this) g))},
> compiling:(clojure/core/logic.clj:1130:5)
>
> Is there already a fix for this?
>
> Kind regards,
> Burt
>
> --
> 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: Possible ClojureScript compiler issue...

[David Nolen]

This issue is somewhat to be expected if you're going to use `js->clj`.
This issue has nothing to do with ClojureScript compiler versions - you
just got lucky before. Google Closure will collapse properties, but some of
these collapsed properties are going to be used to determine protocol
membership. That's it.

I suggest just avoiding `js->clj` and using your own simple helper for
recursively converting JSON into Clojure values. Changing the (admittedly
questionable) behavior of `js->clj` will only lead to more breakage.

HTH,
David

On Sat, Oct 15, 2016 at 11:43 AM, John Szakmeister 
wrote:

> I've been using ClojureScript rather successfully for a year now, but
> ran into an interesting issue recently.
>
> I've discovered that js->clj isn't quite working as expected.  After
> quite a bit of tearing things down and apart, I discovered it was one
> of the keys in some JSON data coming back from the server that looks
> like:
>
> "Bi": 8
>
> And the resultant error would be:
>
> No protocol method IEncodeClojure.-js->clj defined for type
> object: [object Object]
>
> I don't know why this particular sequence caused a problem, but I
> ended trying to vary things a bit just to see what happens.  If I use:
>
> "Bi": 0
>
> I don't see the issue.  Any non-zero value though does seem to bring
> the problem about for this sequence of letters though.  Similarly, I
> tried varying the two letter sequence, and discovered two others with
> similar problems: Ai, and ba.  The latter brought about a different
> error:
>
> [object Object] is not ISeqable
>
> And the pattern with the value needing to be non-zero follows.  If the
> value associated with the key is 0, then I don't see a problem.
>
> As I wasn't seeing this issue before, I backpedaled my version of the
> ClojureScript compiler and eventually found that 1.9.56 didn't seem to
> sufffer from the problem.  After checking out ClojureScript, and
> bisecting more I found that commit
> bcf60ce194e5292fbc5c4b2d89dfc5a7b886b94c is when the behavior changed
> from behaving correctly to behaving badly, but I think it's a false
> positive.
>
> I then created a much smaller test case, with no other libraries
> involved.  This time it's a different set of values that are broken:
>
> * "Ta" with a non-zero value gives: [object Object] is not ISeqable
>
> * "Ub" with a non-zero value gives: No protocol method
> IEmptyableCollection.-empty defined for type object: [object Object]
>
> * "Wb" with a non-zero value gives: No protocol method
> IEncodeClojure.-js->clj defined for type object: [object Object]
>
> If I back up to before the previously mentioned commit, I can still
> cause the problem, though the letter sequences change a bit.
>
> Also, this only appears to happen with advanced optimizations.  With
> no optimizations or with whitespace optimizations, there's no issues.
> So it smells like a strange interaction between the ClojureScript
> runtime and the compiler.
>
> Has anyone seen an issue like this before?  Does anyone have any ideas
> what is going on?  We have these short keys in our data, and it'd be
> pretty painful to make them something else (especially since the names
> are meaningful to those in the know, despite them being cryptic--they
> refer to bit settings on various motors).
>
> I'd be happy to file a ticket, if that's what needs to get done too.
>
> Thanks!
>
> -John
>
> PS Here's the code I used to hunt down problematic keys:
>
> (def alphabet [\a \b \c \d \e \f \g \h \i \j \k \l \m \n \o \p \q \r \s \t
> \u
>\v \w \x \y \z \A \B \C \D \E \F \G \H \I \J \K \L \M \N \O
> \P
>\Q \R \S \T \U \V \W \X \Y \Z])
>
> (enable-console-print!)
>
> (defn ^:export main-page []
>   (println"Starting...")
>   (doseq [c1 alphabet
>   c2 alphabet
>   i  (range 256)]
> (let [s (str "{\"" c1 c2 "\": " i "}")]
>   (try
> ;; (prn :parse-s (js/JSON.parse s))
> ;; (prn :js-clj-parse (js->clj (js/JSON.parse s)))
> (js->clj (js/JSON.parse s))
> (catch js/Error e
>   (println "didn't work" s (str e
>))
>   (println "Done!"))
>
> Then you can observe the results from the JS console.
>
> --
> 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 Go

Re: Possible ClojureScript compiler issue...

[David Nolen]

It's true that there other scenarios where you can encounter this but it
gets reported infrequently enough that I don't think these kinds of
property name collisions are common.

Still it has come up before and I think the simplest solution least likely
to adversely affect performance is to test for a def'onced unique object
instead of `true`.

David

On Sat, Oct 15, 2016 at 8:46 PM, Antonin Hildebrand <
antonin.hildebr...@gmail.com> wrote:

> Unfortunately, this problem is not specific to `js->clj` only.
>
> I believe in general under :advanced optimizations, any object which was
> created or modified by a code which
> was not subject of the same closure compiler optimization pass could
> exhibit similar problems when used with ClojureScript core functions like
> `satisfies?`.
>
> That also includes working with external data (your case), and working
> with objects created/modified by adding properties by string names.
>
> To illustrate, I created a screenshot of cljs type instance with two
> protocols, to see the internals in dev mode:
> https://dl.dropboxusercontent.com/u/559047/cljs-protocol-internals-01.png
> In the selected text I highlighted part of generated code for `satisfies?`
> call.
>
> ClojureScript adds/checks $cljs prefixed properties to objects. These
> internal properties get renamed by closure compiler.
> So any object which happens to have one of those renamed names
> independently added as their property will potentially confuse functions
> like `satisfies?`.
>
> Possible solutions I see:
>
> 1. use string names for clojurescript internal properties, and avoid
> clashes by using "unique-enough" prefix even in advanced mode - still not
> safe solution, but would minimize clash chances
>
> or
>
> 2. start tracking which objects belong to cljs land, have one
> "unique-enough" string name as a marker, clojurescript functions like
> satisfies? would check this marker before proceeding further. Still dirty,
> one could clobber cljs properties by modifying a cljs-land-object from
> unaware Javascript code. And this would probably change behaviour of some
> existing code.
>
> or
>
> 3. use prototypal inheritance and "hide" all ClojureScript internal
> properties in a new link in the prototype chain, plain javascript objects
> would miss this link so it could be easily detected, properties would not
> clash even if they got same names. ClojureScript functions like satisfies?
> would properly
> walk the chain and read properties from proper link which belongs only to
> ClojureScript. Ale we would not need any special "magic" marker - the
> Javascript type of the link in prototype would safely identify it.
> I believe this would be correct solution. But I guess, this would be too
> dramatic change in ClojureScript internals and might break a lot of other
> things I currently don't understand. Also performance could get a hit.
>
> Better ideas, anyone? :-)
>
> ps. don't use :advanced mode when programming atomic reactors in
> ClojureScript ;-p
>
> On Saturday, October 15, 2016 at 10:59:14 PM UTC+2, John Szakmeister wrote:
>
>> On Sat, Oct 15, 2016 at 2:49 PM, David Nolen 
>> wrote:
>> > This issue is somewhat to be expected if you're going to use `js->clj`.
>> This
>> > issue has nothing to do with ClojureScript compiler versions - you just
>> got
>> > lucky before. Google Closure will collapse properties, but some of
>> these
>> > collapsed properties are going to be used to determine protocol
>> membership.
>> > That's it.
>>
>> Wow.  I did not that expect that at all.  It makes sense, but it's
>> unfortunate.
>>
>> > I suggest just avoiding `js->clj` and using your own simple helper for
>> > recursively converting JSON into Clojure values. Changing the
>> (admittedly
>> > questionable) behavior of `js->clj` will only lead to more breakage.
>>
>> I'll definitely look at alternatives.  It'd be nice if js->clj had
>> documentation on this shortcoming though, and perhaps pointers to
>> better alternatives.
>>
>> Thanks for the help David!
>>
>> -John
>>
> --
> 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
> ---
&g

Re: Possible ClojureScript compiler issue...

[David Nolen]

This issue is fixed in master now thanks to Thomas Heller. The performance
hit is negligible.

Thank you for the report.

David

On Tue, Oct 18, 2016 at 3:45 PM, John Szakmeister 
wrote:

> On Tue, Oct 18, 2016 at 5:59 AM, Thomas Heller 
> wrote:
> > Don't think there is a best practice for your case in particular.
>
> Okay.  Earlier in the thread you said "while this issue can be very
> confusing you will hardly ever run into it when following best
> practices."  So it seemed to me that perhaps I missing something
> important, or didn't know about a best practice that would have saved
> me.  I think the issue here is a bit different though.  There's
> nothing that would have saved short of knowing that js->clj has this
> issue lurking in the background. :-)
>
> > The issue is that js->cli is built on top of protocols to allow
> converting
> > custom JS types to CLJS types. Which makes it extensible for the price of
> > checking protocols. In your case you are converting JSON which cannot
> have
> > custom types, so a custom converter only checking for the very few
> possible
> > JSON types would "fix" your problem (and would probably be a lot faster).
>
> Yep.  OTOH, I don't really need the performance and js->clj would have
> been just as nice to use, if it worked correctly. :-)
>
> > The case can be made that cljs-ajax should not be using js->clj when
> > converting JSON, maybe even add a json->clj to cljs.core.
>
> I think having json->clj would be a nice option.  Though for
> cljs-ajax, we probably need to roll our own since the api wouldn't be
> available in older ClojureScript versions.
>
> > The sentinel is the "safest" solution but impacts the performance of
> > everyone, so we should be doing more benchmarks on more platforms before
> > deciding anything. Benchmarks and Votes on the Jira Issue would help to
> push
> > this along.
>
> True, but I think the correctness argument here is pretty valuable.
> Again, much of what I see out there is the js->clj is the way to
> convert data, and having this problem lurking seems like setting folks
> up for failure.  I'm pretty persistent when it comes to
> troubleshooting this stuff, but I could see others being awfully
> frustrated by the result.  So I hope that some version of the sentinel
> patch makes it in. :-)
>
> -John
>
> --
> 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.

ANN: ClojureScript 1.9.293

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.293"]

This release fixes a major issue with transit analysis caching where
files were leaked. It also includes a very significant compiler
enhancement thanks to Antonio Monteiro - you can now create
ClojureScript files without declaring a namespace. This opens the door
to making a much larger class of Clojure programs portable to
ClojureScript. `require` and other ns related macros are now available
granted that they appear at the top of the file. Please take careful
note that they are not functions and cannot be used in dynamic
situations. Still this eases writing simple scripts and the door is
now open to finally support data literals in a comprehensive way.

We also bumped the Google Closure compiler dependency. Please note
that Closure Compiler has made breaking changes around JS module
processing so this version of ClojureScript is pinned to this latest
release.

A huge thanks to the many people old and new that contributed to this
release.

As always, feedback is most welcome!

## 1.9.293

### Enhancements
* CLJS-1346: Support require outside of ns

### Changes
* CLJS-1762: Bump Closure Compiler, refactor module support
* CLJS-1658: testing for protocol membership may return false positives
* CLJS-1536: REPL def symbol init collision
* CLJS-1805: Source map should take false
* CLJS-1804: Self-host: process namespace side-effects for new require
without NS
* CLJS-1803: Use new require capability in REPLs
* CLJS-1796: Measure Google Closure specific optimization time
* CLJS-1782: Self-host: allow namespaces to require their own macros
* CLJS-1563: :source-map option to cljs.build.api/build should take nil
* CLJS-1785: Warn on reference to js/foo shadowed by local binding

### Fixes
* make String an implicit ns like Math. revert char? and clarify docstring.
add unit tests for char?
* fix cljs.spec.test/check docstring
* CLJS-1826: Self-host: load-deps doesn't honor `:reload` and `reload-all`
* CLJS-1825: :source-map error when passing `false` under simple
optimizations
* CLJS-1821: `add-preloads` should only touch sources if `:preloads` option
specified
* CLJS-1814: Move docstrings for require, etc. from `cljs.repl` to their
new definitions in `cljs.core`
* CLJS-1809: Add 0/1 arity to `into`
* CLJS-1824: transit cache feature leaks files
* CLJS-1294: Let macroexpand(-1) accept any quoted argument.
* CLJS-1818: (hash false) returns different value from Clojure
* CLJS-1817: Strange result when assoc'ing 0 to persistent hash map
* CLJS-1815: Fix failing analyzer tests
* follow-up on CLJS-460 defmulti ignores optional :hierarchy argument
* CLJS-1807: Better error messages for `ns*` calls
* CLJS-1802: Generated namespaces should be of the form `cljs.user.file`
* CLJ-1935: Use multimethod dispatch value method lookup to take
hierarchies into account in multi-spec
* CLJS-1682 :foreign-libs with module conversion does not works properly if
it is used form deps.cljs
* CLJS-1710: spec/double-in not implemented
* CLJS-1787: Make cljs.spec explain pluggable
* CLJS-1781: Add cljs.hash-map-test to self-parity tests
* CLJS-1788: Port CLJ-2004: include retag in multi-spec form
* CLJS-1765: Empty iterator for hash maps with nil key
* CLJS-1784: nth doesn't throw on strings or arrays
* CLJS-1773: Self-host: Don't resolve unqualified symbols / keywords with
$macros
* CLJS-1770: goog-defines broken for integers
* CLJS-1600: Destructuring defprotocol fn args causes defrecord impls to
silently fail
* CLJS-1335: resolve-macro-var: information missing for macros
* CLJS-1633: Improve error associated with invalid foreign-libs :file path
* CLJS-1775: `get` with `nil` returns as if `get` with `0`
* CLJS-1780: Records without extmaps fail to iterate
* CLJS-1774: Self-host: Report filenames in warns in test-self-parity
* CLJS-1779: keyword 2-arity constructor accepts anything for both
parameters which leads to different hashing

-- 
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: spurious clojurescript require exception: Namespace does not exist

[David Nolen]

`require` only works if your namespace is in a file that respects Java
classpath conventions. You may have missed this detail in the way all the
Quick Start examples are structured.

HTH,
David

On Sat, Jan 30, 2016 at 12:17 PM, Gregg Reynolds  wrote:

> I'm following the "browser REPL" section in the Clojurescript Quickstart
> .  Everything
> seems hunky-dory; I can connect from the browser and eval code at the
> repl.  But when I change my source and try to require my namespace, I get:
>
> cljs.user=> (require '[test.my-greeting :as t])
> Reading analysis cache for tmp/test/my_greeting.cljs
> java.lang.IllegalArgumentException: Namespace test.my-greeting does not
> exist
>
> Here's the code:
>
> In /browser_repl.cljs:
>
> (require 'cljs.repl)
> (require 'cljs.build.api)
> (require 'cljs.repl.browser)
>
> (cljs.build.api/build "tmp"
>   {:main 'test.my-greeting
>:output-to "dev-resources/public/scripts/main.js"
>:output-dir "dev-resources/public/scripts/cljs"
>:verbose true})
>
> (cljs.repl/repl (cljs.repl.browser/repl-env)
>   :watch "tmp"
>:output-to "dev-resources/public/scripts/main.js"
>   :output-dir "dev-resources/public/scripts/cljs"
>   :verbose true)
>
>
> In /tmp/test/my_greeting.cljs:
>
> (ns test.my-greeting
>(:require [clojure.browser.repl :as repl]))
> (defonce conn
>   (repl/connect "http://localhost:9000/repl";))
> (enable-console-print!)
> (println "HELLO")
>
> I'm stumped.  Help!
>
> Gregg
>
> --
> 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.

ANN: ClojureScript 1.9.456, Externs Inference & Comprehensive JS Modules Support

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.456"]

This is a significant feature release.

The first new feature is externs inference. This should greatly ease
the integration of 3rd party JavaScript libraries incompatible
with Google Closure advanced compilation. By treating the externs
problem as a type-hinting one - we can automatically generate the
required externs for you. This new feature should be considered
of alpha quality and subject to change. Still, feedback is greatly
appreciated to help us better understand how to best deliver this
enhancement.

For details please look at the new guide:
https://clojurescript.org/guides/externs

The second new feature is much more comprehensive support for
JavaScript modules. We now have a good story for integrating the
various kinds of JavaScript modules into a ClojureScript project
build without resorting to JavaScript build tools. This feature
even includes the consumption of modules directly from NPM.

There are far too many details to cover in this release announcement
so once again refer to the guide:
https://clojurescript.org/guides/javascript-modules

Like externs inference this feature is alpha and subject to change.
Again feedback is critical to guiding this enhancement in the
right direction.

I'd like to especially call out Maria Geller's Google Summer of Code work
here around these two major features. This work began almost 2 years
and it's nice to see the long term planning come together so well.

There are quite a few performancement enhancements in this release
related to compiler startup time as well as numerous fixes from
many members of the community.

Congratulations to everyone involved and happy hacking!

## 1.9.456

### Enhancements
* Enhanced JavaScript module support
* Support Node resolution for CommonJS modules
* Externs inference
* Performance enhancements
* CLJS-1835: REPL load special fn
* CLJS-1194: Support for `data_readers.cljc`

### Changes
* expose :closure-module-roots option
* bump Closure Compiler dep
* Under Node.js don't need require entries in the goog.addDependency calls
in cljs_deps.js
* do not throw on circular dependencies between Google Closure JS libs
* str macro should call str/1 function directly, added str benchmark
* CLJS-1718: Foreign lib files should be placed in a relative location
* CLJS-1858: Should allow `:cache-analysis true` and `cache-analysis-format
nil`
* CLJS-1616: Self-host: improve documentation for compile-str
* CLJS-1643: Emit more informative error when emitting a type which has no
emit multimethod case
* CLJS-1816: Basic timing info in verbose output
* add support for emitting inferred externs file
* add cljs.analyzer/analyze-form-seq
* CLJS-1666: Flag to optionally disable transit analysis cache encoding
* Provide more descriptive error message when invalid libspec detected
* CLJS-1768: cljs.spec perf tweaks
* CLJS-1842: Remove analyzer `:merge` hack for REPLs
* CLJS-1839: Relax the constraint that `new` and dot forms must be passed a
symbol
* default to :ecmascript3 if :language-out not specified for :es6 module
* respect :language-out when processing ES6 modules
* default to :ecmascript3 if :language-out not specified for :es6 module
* inline some?

### Fixes
* CLJS-1911: Need to bind Node.js require
* CLJS-1909: Self-host: circular dependency when requiring cljs.reader
* CLJS-1906: Self-host: script/test-self-parity fails
* CLJS-1903: Remove anonymous vars from dir and apropos output
* CLJS-1897: Too many externs generated
* CLJS-1895: Externs inference needs to support user supplied externs
* CLJS-1873: Self-host: Unit tests fail owing to test.check dep
* CLJS-1874: Self-host: :fn-var true for macros
* CLJS-1877: :foreign-libs entries should be allowed to specify directories
along with individual files
* CLJS-1890: s/form for s/nilable in cljs.spec does not match clojure.spec
* CLJS-1811: Can't compose cljs.spec.test.instrument (or
cljs.spec.test.check) with cljs.spec.test.enumerate-namespace
* CLJS-1894: Unnecessary analysis of core.cljs on first compile
* CLJS-1893: Unnecessary analysis of core.cljs
* CLJS-1892: Dependencies in JARs are analyzed every time even if an
analysis cache file exists
* CLJS-1887: add :watch-error-fn option
* CLJS-1883 Foreign libs can't be found on Node.js
* CLJS-1882 Fix constant table sort order when using :modules
* CLJS-1853: var metadata in compiled output
* CLJS-1878: prefer `some?` over `(not (nil? %))` in analyzer
* CLJS-1880: missing ^boolean on some hasNext calls
* CLJS-1875 Difference in seqable? between CLJ & CLJS
* CLJS-1829: get does not return not-found on negative indexes
* cljs.spec.test/unstrument shouldn't return the names of vars that weren't
instrumented in the first place. Fixes CLJS-1812
* CLJS-1786: Add knob for controlling printing of namespaced maps
* CLJS-1836: nth doesn't t

Re: ANN: ClojureScript 1.9.456, Externs Inference & Comprehensive JS Modules Support

[David Nolen]

Looks like you have a dependency issue. Use `lein deps :tree` or the
equivalent command to sort it out.

HTH
David

On Saturday, January 28, 2017, Francesco Bellomi <
francesco.bell...@gmail.com> wrote:

> Hi,
>
> first of all, congratulations on this release, it's a huge step ahead.
>
> I'm having an issue compiling a program with advanced optimizations, which
> worked fine with .293
>
> I get the following exception, any ideas on how can i narrow down the
> problem within my source?
>
> Exception in thread "main" java.lang.NoSuchMethodError:
> com.google.common.base.Preconditions.checkState(
> ZLjava/lang/String;Ljava/lang/Object;)V, compiling:(/tmp/form-
> init5778645093287298904.clj:1:73)
> at clojure.lang.Compiler.load(Compiler.java:7442)
> at clojure.lang.Compiler.loadFile(Compiler.java:7368)
> at clojure.main$load_script.invokeStatic(main.clj:277)
> at clojure.main$init_opt.invokeStatic(main.clj:279)
> at clojure.main$init_opt.invoke(main.clj:279)
> at clojure.main$initialize.invokeStatic(main.clj:310)
> at clojure.main$null_opt.invokeStatic(main.clj:344)
> at clojure.main$null_opt.invoke(main.clj:341)
> at clojure.main$main.invokeStatic(main.clj:423)
> at clojure.main$main.doInvoke(main.clj:386)
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.lang.Var.applyTo(Var.java:700)
> at clojure.main.main(main.java:37)
> Caused by: java.lang.NoSuchMethodError: com.google.common.base.
> Preconditions.checkState(ZLjava/lang/String;Ljava/lang/Object;)V
> at com.google.javascript.rhino.IR.name(IR.java:363)
> at com.google.javascript.jscomp.ClosureCodingConvention.(
> ClosureCodingConvention.java:474)
> at com.google.javascript.jscomp.Compiler.(Compiler.java:202)
> at com.google.javascript.jscomp.Compiler.(Compiler.java:264)
> at cljs.closure$make_closure_compiler.invokeStatic(closure.
> clj:293)
> at cljs.closure$optimize.invokeStatic(closure.clj:1255)
> at cljs.closure$optimize.doInvoke(closure.clj:1251)
> at clojure.lang.RestFn.applyTo(RestFn.java:139)
> at clojure.core$apply.invokeStatic(core.clj:659)
> at cljs.closure$build.invokeStatic(closure.clj:2113)
> at cljs.build.api$build.invokeStatic(api.clj:205)
> at cljs.build.api$build.invoke(api.clj:193)
> at cljs.build.api$build.invokeStatic(api.clj:196)
> at cljsbuild.compiler$compile_cljs$fn__6997.invoke(compiler.
> clj:59)
> at cljsbuild.compiler$compile_cljs.invokeStatic(compiler.clj:59)
> at cljsbuild.compiler$run_compiler.invokeStatic(compiler.clj:167)
> at user$eval7152$iter__7200__7204$fn__7205$fn__7231.invoke(
> form-init5778645093287298904.clj:1)
> at user$eval7152$iter__7200__7204$fn__7205.invoke(form-
> init5778645093287298904.clj:1)
> at clojure.lang.LazySeq.sval(LazySeq.java:40)
> at clojure.lang.LazySeq.seq(LazySeq.java:49)
> at clojure.lang.RT.seq(RT.java:525)
> at clojure.core$seq__6422.invokeStatic(core.clj:137)
> at clojure.core$dorun.invokeStatic(core.clj:3106)
> at clojure.core$doall.invokeStatic(core.clj:3121)
> at user$eval7152.invokeStatic(form-init5778645093287298904.clj:1)
> at user$eval7152.invoke(form-init5778645093287298904.clj:1)
> at clojure.lang.Compiler.eval(Compiler.java:6978)
> at clojure.lang.Compiler.eval(Compiler.java:6968)
> at clojure.lang.Compiler.load(Compiler.java:7430)
> ... 12 more
>
> thanks in advance
>
> Francesco
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com .
> To post to this group, send email to clojurescr...@googlegroups.com
> .
> Visit this group at https://groups.google.com/group/clojurescript.
>

-- 
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.

ANN: ClojureScript 1.9.473, bugfix release

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.473"]

This is a bugfix release.

As always, feedback welcome!

## Fixes
* CLJS-1931: Closure Compiler {{--generate_exports}} flag not supported
* CLJS-1934: Self-host: require-macros :reload / :reload-all fails
* CLJS-1932: Self-host: Perf regression macroexpand-check
* CLJS-1930: Master broken wrt static field: ES5_STRICT_UNCOMMON
* CLJS-1929: When expanding libs don't include Hidden files
* CLJS-1905: Self-host: Stacktraces for script/test-self-parity
* CLJS-1795: Support more options in the `:closure-warnings` compiler option
* CLJS-1922: Use :file as relative output path for foreign-libs
* CLJS-1831: Self-host: Improperly munge ns names
* CLJS-1925: Use of undeclared Var cljs.user/RegExp when extending protocol
for RegExp
* CLJS-1920: cljs.build.api/node-inputs: package.json files are only added
if module entries are top-leve
* CLJS-1916: __dirname and __filename are not defined when compiling for
Node.js with optimizations :none
* CLJS-1915: cljs.test: Index out of bounds for stack element w/o
line/column

-- 
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.

ANN: ClojureScript 1.9.493, another bugfix release

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.493"]

This is a bugfix release.

As always, feedback welcome!

### Fixes
* CLJS-1948: Possible race condition in compiler w/ parallel-build true
* CLJS-1941: `cljs.compiler/cljs-files-in` shouldn't return `.cljc` files
if a `.cljs` file exists for the namespace
* CLJS-1940: Undeclared var warning when invoking a protocol method on a
`js` interop form
* CLJS-1951: Missing 0 and 1 arity versions of interleave
* CLJS-1952: Bump Closure Compiler to Feb 2017 release
* CLJS-1937: Self-host: undeclared cljs.core$macros/mod when compiling
cljs/core.cljs
* CLJS-1936: cljs.analyzer declares vars which are only used in Clojure
* CLJS-1949: Self-host: cljs.compiler/munge doesn't preserve JVM compiler
semantics
* CLJS-1950: Eliminate instances of #^
* CLJS-1943: Self-host: `cljs.pprint`'s macros can't be compiled
* CLJS-1945: cljs.spec/every-impl kind-fn kind-form dead code
* CLJS-1944: Can't spec generate non-vector collections
* CLJS-1946: Self-hosted: don't emit `goog.require` calls for foreign libs
if optimizations different than `:none`
* CLJS-1636: Mark some symbols in core macros ns as private
* CLJS-1939: Fix Node load_file call for foreign-deps
* CLJS-1942: Self-host: `cljs.env.macros` and `cljs.analyzer.macros` can't
be loaded
* CLJS-1935: When calling cljs.spec/valid?, subsequent predicates of
cljs.spec/and are evaluated even when early predicate is unsatisfied

-- 
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: ANN: ClojureScript 1.9.493, another bugfix release

[David Nolen]

Just cut 1.9.494 to back out some macros that were made unintentionally
private.

On Fri, Feb 24, 2017 at 4:47 PM, David Nolen  wrote:

> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "1.9.493"]
>
> This is a bugfix release.
>
> As always, feedback welcome!
>
> ### Fixes
> * CLJS-1948: Possible race condition in compiler w/ parallel-build true
> * CLJS-1941: `cljs.compiler/cljs-files-in` shouldn't return `.cljc` files
> if a `.cljs` file exists for the namespace
> * CLJS-1940: Undeclared var warning when invoking a protocol method on a
> `js` interop form
> * CLJS-1951: Missing 0 and 1 arity versions of interleave
> * CLJS-1952: Bump Closure Compiler to Feb 2017 release
> * CLJS-1937: Self-host: undeclared cljs.core$macros/mod when compiling
> cljs/core.cljs
> * CLJS-1936: cljs.analyzer declares vars which are only used in Clojure
> * CLJS-1949: Self-host: cljs.compiler/munge doesn't preserve JVM compiler
> semantics
> * CLJS-1950: Eliminate instances of #^
> * CLJS-1943: Self-host: `cljs.pprint`'s macros can't be compiled
> * CLJS-1945: cljs.spec/every-impl kind-fn kind-form dead code
> * CLJS-1944: Can't spec generate non-vector collections
> * CLJS-1946: Self-hosted: don't emit `goog.require` calls for foreign libs
> if optimizations different than `:none`
> * CLJS-1636: Mark some symbols in core macros ns as private
> * CLJS-1939: Fix Node load_file call for foreign-deps
> * CLJS-1942: Self-host: `cljs.env.macros` and `cljs.analyzer.macros` can't
> be loaded
> * CLJS-1935: When calling cljs.spec/valid?, subsequent predicates of
> cljs.spec/and are evaluated even when early predicate is unsatisfied
>
>

-- 
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: ANN: ClojureScript 1.9.456, Externs Inference & Comprehensive JS Modules Support

[David Nolen]

This is correct.

On Thu, Mar 9, 2017 at 2:36 AM, Colin Fleming 
wrote:

> I believe that dependency is because Google Closure requires it.
>
> On 9 March 2017 at 16:45, Mike Rodriguez  wrote:
>
>> Guava is often a dependency conflict when trying to put libs together
>> that use it. I'm surprised cljs has dependencies like this. I'd think a
>> language would try to avoid having any deps at all or repackage them or
>> something. For example, Clojure only has ASM.
>>
>> --
>> 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.
>

-- 
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.

ANN: ClojureScript 1.9.518, `async` issue resolved

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.518"]

This release bumps Closure Compiler, finally resolving the issue with
core.async.

As always feedback welcome!

## 1.9.518

### Enhancements
* CLJS-1973: Add support for `:npm-deps` in upstream `deps.cljs`
* CLJS-1968: Enable calling JS modules that export a single function
* CLJS-1960: Require CommonJS modules directly from a ClojureScript
namespace

### Changes
* CLJS-2006: Upgrade Closure Compiler to April 2017 release

### Fixes
* CLJS-1497: `find` on an associative collection does not return collection
key
* CLJS-1996: Support correct checking of :preloads when :optimizations not
specified
* CLJS-1994: assoc on nil returns PHM (expected PAM)
* CLJS-1988: add :npm-deps to recognized compiler options
* Fix tiny bug in index-node-modules when no second argument is given
* CLJS-1985: `index-node-modules` should pass opts to `node-inputs`
* CLJS-1987: don't index node modules blindly
* CLJS-1519 Collection invoke errors report arity off by 1
* CLJS-1964: Validate that `:target :nodejs` and no optimizations requires
a `:main` option to be present
* CLJS-1956: Add missing JS reserved keywords
* CLJS-1983: res -> mres in spec.cljs
* CLJS-1978: port CLJ-2035
* CLJS-1979: port CLJ-2043 (fix s/form of s/conformer)
* CLJS-1980: port CLJ-2100 (s/nilable form should retain original spec form)
* CLJS-1976: hash-map assoc stackoverflow
* CLJS-1957: Process JS modules errors and warnings don't get printed
* CLJS-1868 - Output simpler dependency rel paths when compiling with
Closure libs
* CLJS-1967: Missing ^boolean for removed-leaf? in THM impl

-- 
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: ANN: ClojureScript 1.9.518, `async` issue resolved

[David Nolen]

I just cut 1.9.521. The only change was to fix a regression to
:foreign-libs when there are multiple entries which use the same :file.

David

On Wed, Apr 12, 2017 at 4:52 PM, David Nolen  wrote:

> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "1.9.518"]
>
> This release bumps Closure Compiler, finally resolving the issue with
> core.async.
>
> As always feedback welcome!
>
> ## 1.9.518
>
> ### Enhancements
> * CLJS-1973: Add support for `:npm-deps` in upstream `deps.cljs`
> * CLJS-1968: Enable calling JS modules that export a single function
> * CLJS-1960: Require CommonJS modules directly from a ClojureScript
> namespace
>
> ### Changes
> * CLJS-2006: Upgrade Closure Compiler to April 2017 release
>
> ### Fixes
> * CLJS-1497: `find` on an associative collection does not return
> collection key
> * CLJS-1996: Support correct checking of :preloads when :optimizations not
> specified
> * CLJS-1994: assoc on nil returns PHM (expected PAM)
> * CLJS-1988: add :npm-deps to recognized compiler options
> * Fix tiny bug in index-node-modules when no second argument is given
> * CLJS-1985: `index-node-modules` should pass opts to `node-inputs`
> * CLJS-1987: don't index node modules blindly
> * CLJS-1519 Collection invoke errors report arity off by 1
> * CLJS-1964: Validate that `:target :nodejs` and no optimizations requires
> a `:main` option to be present
> * CLJS-1956: Add missing JS reserved keywords
> * CLJS-1983: res -> mres in spec.cljs
> * CLJS-1978: port CLJ-2035
> * CLJS-1979: port CLJ-2043 (fix s/form of s/conformer)
> * CLJS-1980: port CLJ-2100 (s/nilable form should retain original spec
> form)
> * CLJS-1976: hash-map assoc stackoverflow
> * CLJS-1957: Process JS modules errors and warnings don't get printed
> * CLJS-1868 - Output simpler dependency rel paths when compiling with
> Closure libs
> * CLJS-1967: Missing ^boolean for removed-leaf? in THM impl
>
>

-- 
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.

ANN: ClojureScript 1.9.542, spec changes & REPL enhancement

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.542"]

This release is primarily about staying in sync with the latest changes to
spec. It
also includes a small but significant enhancement to REPLs to allow
handling multiple forms.

As always, feedback welcome!

## 1.9.542

### Enhancements
* CLJS-1572: REPL doesn't give error for expressions with too many right
parentheses

### Changes
* cljs.spec -> cljs.spec.alpha
* CLJS-2013 - Add MapEntry type
* CLJS-2015: Self-host: `defmacro` should return the Var
* CLJS-2017: Upgrade Closure Compiler to latest April 2017 release

### Fixes
* CLJS-485: RegExp flags are being dropped by string/replace
* CLJS-1518: Case macro expansion evaluates expression twice
* CLJS-2024: Self-host: `find-ns-obj` broken for namespaces with 'a' as the
first segment
* CLJS-2028: `realized?` throws on LazyTransformer
* CLJS-2010: refer-clojure :rename throws on valid invocations
* CLJS-2007: Whitespace optimizations should respect :main option.

-- 
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: [ClojureScript] Re: ANN: ClojureScript 1.9.542, spec changes & REPL enhancement

[David Nolen]

That's just a warning. Is there some deeper breakage that you are observing?

David

On Sun, May 14, 2017 at 3:09 AM, Tatu Tarvainen  wrote:

>
> > * CLJS-2013 - Add MapEntry type
>
> This change seems to break plumatic schema, after upgrading I'm getting
> warnings:
>
> WARNING: ->MapEntry already refers to: cljs.core/->MapEntry being replaced
> by: schema.core/->MapEntry at ... schema/core.cljs
>
> Plumatic also defines a MapEntry record type which clashes with the core
> one.
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/clojurescript.
>

-- 
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: [ClojureScript] Re: ANN: ClojureScript 1.9.542, spec changes & REPL enhancement

[David Nolen]

That runtime error doesn't necessarily seem related to the compile time
warning. Would need more information.

On Mon, May 15, 2017 at 10:16 AM, Tatu Tarvainen 
wrote:

>
> My phantom test run crashes with:
> TypeError: undefined is not an object (evaluating 'schema.core.MapEntry.
> prototype')
>
> I'm assuming that is related to this change, but I'll need to investigate
> more. There's already a merged PR for schema that excludes MapEntry in
> refer-clojure. I'm hoping that will fix this.
>
>
> maanantai 15. toukokuuta 2017 14.32.55 UTC+3 David Nolen kirjoitti:
>>
>> That's just a warning. Is there some deeper breakage that you are
>> observing?
>>
>> David
>>
>> On Sun, May 14, 2017 at 3:09 AM, Tatu Tarvainen 
>> wrote:
>>
>>>
>>> > * CLJS-2013 - Add MapEntry type
>>>
>>> This change seems to break plumatic schema, after upgrading I'm getting
>>> warnings:
>>>
>>> WARNING: ->MapEntry already refers to: cljs.core/->MapEntry being
>>> replaced by: schema.core/->MapEntry at ... schema/core.cljs
>>>
>>> Plumatic also defines a MapEntry record type which clashes with the core
>>> one.
>>>
>>> --
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ClojureScript" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojurescrip...@googlegroups.com.
>>> To post to this group, send email to clojur...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/clojurescript.
>>>
>>
>> --
> 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.

ANN: ClojureScript 1.9.562 - Clojure 1.9.0-alpha17 parity

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.562"]

This release coincides with Clojure 1.9.0-alpha17, includes a variety
of fixes, and updates both the Closure Compiler & Library dependencies.

As always, feedback welcome!

### Enhancements
* CLJS-2027: Add language-in for ECMA 2017 and ECMA Next
* CLJS-2026: Add Compiler option for rewrite polyfills

### Changes
* CLJS-2021: subvec throws when passed non-vector
* CLJS-1884: Give a chance to MetaFn to be removed by closure under
:advanced
  optimization Replace with-meta calls by -with-meta calls where possible
* CLJS-2052: Port new spec.alpha enhancements
* Update Google Closure Compiler dependency
* Update Google Closure Library dependency

### Fixes
* CLJS-2053: Regression: cljs.spec.alpha/any for fdef
* CLJS-2039: remove extraneous argument from ChunkBuffer.chunk
* Fix assumption that all closure-compliant JS is goog.*
* CLJS-2035: Self-host: Add map-entry-test to self-parity
* CLJS-2033: set-validator! should check current state
* CLJS-2008: Self-host: backport fixes to threading macros
* CLJS-2005: Bad error message with duplicate arity function definitions
* CLJS-2032: Case macro expansion evaluates expression twice when no
matching clause
* CLJS-2023: User supplied type hints stopped working on js/goog.DEBUG
* CLJS-2020: defmulti "miss" performance poor
* CLJS-2034: Sequence and Eduction produce infinite loop in transducer that
appends to the reduction

-- 
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: The soul of case

[David Nolen]

I agree that this behavior diverges from Clojure's and that we probably
should have thought it through a bit more 2 years ago. But at this point
it's probably water under the bridge. Anybody that's actually relying on
this behavior is likely inlining named numeric constants to make jump
tables. The only semantic fuzzy area is if you want to match a symbol and
you have defined a constant with the exact same symbol or referred such a
constant in your namespace. But I suspect this requirement is esoteric
enough that nobody has reported such a problem in actual code in the last 2
years.

I believe I accidentally let it slip through since I don't think I'd ever
used `case` to match symbols myself and at the time I had not internalized
that symbols need not be quoted in this case (yes I know it says so in the
`case` docstring).

It's a strange historical quirk, but I also don't think the situation is
interesting or common enough to be very worked up about :)

David

On Sun, Jun 18, 2017 at 1:26 PM, Herwig Hochleitner 
wrote:

> I was pretty horrified, when this crossed my timeline. Thanks, Phil, for
> starting this thread, because I'd already forgotten about it.
>
> First thing that seems strange, is, that the blog post is from 2015.
> Nevertheless, I just tried it on a nashorn repl:
>
> cljs.user> *clojurescript-version*
> "1.9.562"
> cljs.user> (case 2
>  x :X
>  :no-match)
> :no-match
> cljs.user> (case 'x
>  x :X
>  :no-match)
> :X
> cljs.user> (def ^:const x 2)
> #'cljs.user/x
> cljs.user> (case 2
>  x :X
>  :no-match)
> :X
> cljs.user> (case 'x
>  x :X
>  :no-match)
> :no-match
>
> 2017-06-18 16:37 GMT+02:00 Alex Miller :
>
>> ... that seems wrong.
>>
>
> Yes, yes it does.
>
> --
> 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: The soul of case

[David Nolen]

On Sat, Jun 24, 2017 at 1:49 PM, Matching Socks 
wrote:

>
> At any rate, I would like to put in either a documentation issue (if it's
> a feature that ClojureScript's "case" does not work like Clojure's) or else
> a defect issue (if it's a bug).
>

As I stated earlier, we're not going to remove it nor change the existing
behavior in anyway whatsoever. And yes it will get documented.

David

-- 
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.

ANN: ClojureScript 1.9.660, compiler performance, runtime performance, cljs.spec fixes

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.660"]

This release includes many performance enhancements to the
ClojureScript compiler as well as ClojureScript runtime code. In
addition, the release contains fixes to cljs.spec so that it works
correctly under incremental compilation.

For more information please refer to the new post here kindly
contributed by Mike Fikes:
https://clojurescript.org/news/2017-06-27-faster-compilation-runtime-and-spec-caching-fixes

Thanks to all that contributed, and as always, feedback welcome!

## 1.9.660

### Enhancements
* CLJS-2108: faster set equivalence
* CLJS-2099: Optimize apply by avoiding .apply
* CLJS-2046: Optimize expression in call position
* CLJS-1876: Faster reduce for PV, Subvec and ChunkedSeq
* CLJS-2080: Faster equiv-map
* CLJS-2066: Avoid analyzing named fn literal bodies twice
* CLJS-2065: Improve analyzer munge performance

### Changes
* CLJS-2134: Warn on variadic signatures in protocol method implementation
* CLJS-2130: Self-host: Add `:fn-invoke-direct` to public API docstrings
* CLJS-2112: Iterator based reduce path
* CLJS-2100: to-array calls seq too often
* CLJS-2041: Compiler flag to drop Function.prototype.call invokes
* CLJS-2093: inline ^:const var values
* CLJS-2042: Variadic invoke calls array_seq inefficiently
* CLJS-2003 remove redundant calls to `str` in munge/demunge
* CLJS-1907: Improve error message from cljs.reader/read-string
* CLJS-1724: Include IIterable in fast-path-protocols
* CLJS-924: Better error message for mistaken use of 'def'
* CLJS-1599: UUIDs are not equal for upper/lower case strings
* NodeJS REPL accepts a :path opt to set NODE_PATH
* CLJS-1886: RangedIterator should only be created from
cljs.core.PersistentVector instances
* CLJS-2068: MapEntry, RedNode and BlackNode are IComparable
* CLJS-2073: Don't flush for every emitted line
* CLJS-2089: Warn message wrong for recur to protocol with nil
* CLJS-2085: defrecord recur method head target object
* CLJS-1977: defrecord should use murmur hashing like Clojure
* CLJS-2076: modules should support wildcard namespaces
* CLJS-2078: add resolve macro

### Fixes
* CLJS-2133: Invalid variadic IFn implementations now fail
* CLJS-2128: Fix regression in CLJS-1886
* CLJS-2126: Add new compiler option :fn-invoke-direct to build-affecting
options
* CLJS-2054: Private core names still result in "already declared" warnings
* CLJS-2125: Duplicate HOF invoke warnings if :static-fns true
* CLJS-2119: s/form for s/& is qualified with `clojure.spec.alpha`
* CLJS-2121: Self-host: Document string as valid name arg
* CLJS-2124: Self-host: Tests failing wth Could not find tag parser for
:cljs.spec.alpha
* CLJS-2122: Self-host: Non-symbol ns names dumped into env
* CLJS-2117: Self-host: Port CLJS-1989 to self-hosted
* CLJS-1989: s/fdef expansion side effect fails when load cached source
* CLJS-2116: Need to handle un-namespaced symbol when evaluating `foo.core
* CLJS-2109: incorrect syntax-quote symbol resolution (resolve-symbol
'clojure.core) -> 'clojure/core
* CLJS-2113: nth function produces different results from clojure when
using a negative index on a sequence
* CLJS-2115: Pass not-found in the native-satisfies? branch of nth
* CLJS-2111: Transit analysis caching broken for JSValue or regex
* CLJS-2101: Undeclared var in do chain of defs
* CLJS-2104: Const-replaced exprs do not emit js "return"
* CLJS-1992: declare after def should have no effect
* CLJS-1251: Missing semicolons when emitting deftype and defrecord
mistaken use of 'def'
* CLJS-1685: Incorrectly lazy subvec when start param is nil
* CLJS-1641: Multi-arity defn copies arguments unnecessarily for all cases
* CLJS-2092: Redundant call to equiv-map in PAM.-equiv
* Check for compilation success, and lib folder
* CLJS-2030: Case with grouped keyword test emit result-expr multiple times
* CLJS-2094: Predicates unit tests constructs a uuid with nil
* CLJS-1891: UUID.toString can return non-string
* CLJS-2072: Eliminate reflection in cljs.js-deps/build-index
* CLJS-2012: Find on PHM with nil entry always returns nil entry
* CLJS-2057: fix language-in options (es6 deprecated and add missing es2016)
* CLJS-2060: Backport CLJ-2141 Return only true/false from qualified-*
predicates
* CLJS-2091: reify docstring ISeqable example needs correction
* CLJS-2088: fix caching collision between macros ns and regular ns in
boostrap
* CLJS-2036: Relative path exception thrown when :preloads requires a
:foreign-lib
* CLJS-2083: Test equiv-map for maps which do not impl IKVReduce
* CLJS-2081: Self-host: Regression with CLJS-2079
* CLJS-2079: Records and maps are not equal
* CLJS-2075: PersistentTreeMap.reduce-kv does not honor reduced?
* Browser REPL regression
* CLJS-2069: Self-host: automatic `clojure` -> `cljs` aliasing doesn't work
when loading macro namespaces
* CLJS-2067: reduce-kv / inod

ANN: ClojureScript 1.9.671, bugfix release

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.671"]

This is a follow up bugfix release to 1.9.660.

As always, feedback welcome!

## 1.9.671

### Fixes
* CLJS-2139: Undeclared var regression in fn bodies
* CLJS-2137: Missing INext on some sequences
* CLJS-2136: Clarify IFind contract to avoid double-lookups
* need to elide :c.a/analyzed in c.a/analyze-wrap-meta to avoid dumping
unintended
  with-meta expressions
* resolve returns improperly constructed Var
* fix :fn-invoke-direct edgecase around keywords

-- 
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.

New Features coming to ClojureScript

[David Nolen]

We have a series of blog posts in the queue that outline several major
enhancements to the ClojureScript compiler that will be available in the
next release. This is the first one in the series:

https://clojurescript.org/news/2017-07-10-code-splitting

Enjoy!
David

-- 
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: New Features coming to ClojureScript

[David Nolen]

Second post in the series is up
https://clojurescript.org/news/2017-07-12-clojurescript-is-not-an-island-integrating-node-modules
kindly contributed by António Nuno Monteiro.

Enjoy!
David

On Mon, Jul 10, 2017 at 5:28 PM, David Nolen  wrote:

> We have a series of blog posts in the queue that outline several major
> enhancements to the ClojureScript compiler that will be available in the
> next release. This is the first one in the series:
>
> https://clojurescript.org/news/2017-07-10-code-splitting
>
> Enjoy!
> David
>
>
>

-- 
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: New Features coming to ClojureScript

[David Nolen]

3rd post in the series is now up thanks to Mike Fixes
https://clojurescript.org/news/2017-07-14-checked-array-access

On Mon, Jul 10, 2017 at 5:28 PM, David Nolen  wrote:

> We have a series of blog posts in the queue that outline several major
> enhancements to the ClojureScript compiler that will be available in the
> next release. This is the first one in the series:
>
> https://clojurescript.org/news/2017-07-10-code-splitting
>
> Enjoy!
> David
>
>
>

-- 
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.

ANN: ClojureScript 1.9.854

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.854"]

This is a significant feature release. Notable new features include
comprehensive NPM dependency support, overhauled code splitting,
enhanced JavaScript module preprocessing, declared global exports for
foreign libs, and checked array operations. There are also a large
number of fixes, changes, and minor enhancementes. For more detailed
descriptions of the major enhancements, please refer to the last month
of posts https://clojurescript.org/news/news.

As always, feedback welcome!

## 1.9.854

### Enhancements
* CLJS-2280: Provide process.env :preload and auto-configure
* CLJS-2279: Infer `:module-type ` for provided `node_modules`
* CLJS-2250: Support :foreign-libs overrides via :provides
* CLJS-2243: Self-host: Add support for :global-exports
* CLJS-2232: Self-host: Add support for string-based requires
* add *print-fn-bodies* knob, set to false
* CLJS-2198: Safe array operations
* CLJS-2217: Support `:rename` for JS modules
* CLJS-2214: Support :global-exports for foreign libraries
* CLJS-1428: Add a cljs.core/*command-line-args* var
* CLJS-2061: Support ns :require for JS libs, allow strings along with
symbol
* CLJS-2148: Add warnings for invalid use of aget and aset
* CLJS-2143: Add support for symbol preprocess values

### Changes
* CLJS-2273: Bump tools.reader to 1.0.3 and development dependencies
* CLJS-2235: Allow passing extra maven opts to build scripts
* CLJS-2267: Allow ^:const inlined vars to affect if emission
* CLJS-2245: Add support for using a local `node_modules` installation
through a new `:node-modules` compiler flag
* CLJS-2002: Don't throw when no *print-fn* is set
* support Clojure primitive array type hints, core.async no longer
  gives warnings
* CLJS-2213: Node.js target should use node_modules index to emit platform
specific require
* CLJS-2200: bump to tools.reader 1.0.2
* CLJS-2135: require macro prints last result of loaded-libs
* CLJS-2192: Add ChakraCore testing facilities
* CLJS-1800: Defer to tools.reader for cljs.reader functionality
* CLJS-2163: Clean up uses of aget / aset on objects
* CLJS-2184: Add `ns-publics` and `ns-imports`
* CLJS-2183: Assert arguments are quoted symbols in some core macros
* CLJS-2182: Assert argument to resolve is a quoted symbol
* CLJS-2186: Update docstrings for aget/aset to be consistent with Clojure
* CLJS-2180: Allow compiling `:modules` with whitespace optimizations
* CLJS-1822: Use `:file-min` when processing JS modules with advanced
optimizations
* CLJS-2169: Error when compiling with :source-map and advanced
optimizations
* CLJS-2037: Throw if overwriting alias in current namespace
* CLJS-2160: Add loaded? and prefetch functions to cljs.loader
* CLJS-2148: Add unsafe-get and use goog.object
* CLJS-2161: Bump Closure Compiler to June 2017 release

### Fixes
* CLJS-1854: Self-host: Reload ns with const
* CLJS-2278: JavaScript object literals are printed wth keys that cannot be
read
* CLJS-2276: Self-host: Need test.check dep for CLJS-2275
* CLJS-2275: cljs.spec.alpha/fdef resolves eagerly
* CLJS-2259: Extra .cljs_node_repl directory containing cljs.core output
* CLJS-2274: Update CI script to install deps
* CLJS-2269: Warn on top level code split loads
* CLJS-2272: Tests that depended on default install deps behavior failing
* CLJS-2255: Clean up :npm-deps
* CLJS-2263: Docstring for neg-int? backwards
* CLJS-2262: Correct comment that *warn-on-infer* is file-scope
* CLJS-2258: Stack overflow regression for sequence xform applied to
eduction
* CLJS-2256: Generated code doesn't add newline after sourceMappingURL
comment
* CLJS-2254: Module Indexing: Provide relative paths for a package's main
module
* CLJS-2248: Build API tests rely on Yarn
* CLJS-2239: Self-host: Add `:target :nodejs` to the docstrings in cljs.js
* CLJS-2251: Follow-up fix to CLJS-2249 and related commit
* CLJS-2249: Provide a test for d4b871cce73
* CLJS-2246: Revert CLJS-2245 and CLJS-2240 and fix `lein test`
* CLJS-2244: Orphaned processed JS modules breaks :modules
* CLJS-2242: Lots of undeclared Var warns in cljs.spec.gen.alpha
* CLJS-2241: Multiple requires of Node.js modules in non :nodejs target are
not idempotent at the REPL
* CLJS-2229: Ensure that new modules work works correctly with REPLs
* CLJS-2238: Perf regression with node module indexing
* CLJS-2240: don't shell out to module_deps.js if `:npm-deps` not specified
* CLJS-2230: Double checked arrays
* CLJS-2227: Squelch some of the array access tests
* CLJS-2228: Port CLJS-2226 to module_deps.js
* CLJS-1955: data_readers.cljc can't reference handlers in user code
* CLJS-2225: Need to add :checked-arrays to known compiler opts
* CLJS-2226: :npm-deps can't index scoped packages
* CLJS-2224: Resolve-var is wrong wrt. module resolution
* CLJS-2223: Self-host: Undeclared Var deps/native-node-modules
* CL

Re: ANN: ClojureScript 1.9.854

[David Nolen]

The ability to consume node_modules is just an additional feature - it
makes no existing features obsolete.

David

On Sun, Jul 30, 2017 at 3:42 PM, Daniel  wrote:

> For someone who is new to clojurescript and pretty confused by
> clojurescript dependency management in general, does this release obsolete
> cljsjs for new projects and what is the new method?
>
>
> On Friday, July 28, 2017 at 4:55:04 PM UTC-5, David Nolen wrote:
>>
>> ClojureScript, the Clojure compiler that emits JavaScript source code.
>>
>> README and source code: https://github.com/clojure/clojurescript
>>
>> Leiningen dependency information:
>>
>> [org.clojure/clojurescript "1.9.854"]
>>
>> This is a significant feature release. Notable new features include
>> comprehensive NPM dependency support, overhauled code splitting,
>> enhanced JavaScript module preprocessing, declared global exports for
>> foreign libs, and checked array operations. There are also a large
>> number of fixes, changes, and minor enhancementes. For more detailed
>> descriptions of the major enhancements, please refer to the last month
>> of posts https://clojurescript.org/news/news.
>>
>> As always, feedback welcome!
>>
>> ## 1.9.854
>>
>> ### Enhancements
>> * CLJS-2280: Provide process.env :preload and auto-configure
>> * CLJS-2279: Infer `:module-type ` for provided `node_modules`
>> * CLJS-2250: Support :foreign-libs overrides via :provides
>> * CLJS-2243: Self-host: Add support for :global-exports
>> * CLJS-2232: Self-host: Add support for string-based requires
>> * add *print-fn-bodies* knob, set to false
>> * CLJS-2198: Safe array operations
>> * CLJS-2217: Support `:rename` for JS modules
>> * CLJS-2214: Support :global-exports for foreign libraries
>> * CLJS-1428: Add a cljs.core/*command-line-args* var
>> * CLJS-2061: Support ns :require for JS libs, allow strings along with
>> symbol
>> * CLJS-2148: Add warnings for invalid use of aget and aset
>> * CLJS-2143: Add support for symbol preprocess values
>>
>> ### Changes
>> * CLJS-2273: Bump tools.reader to 1.0.3 and development dependencies
>> * CLJS-2235: Allow passing extra maven opts to build scripts
>> * CLJS-2267: Allow ^:const inlined vars to affect if emission
>> * CLJS-2245: Add support for using a local `node_modules` installation
>> through a new `:node-modules` compiler flag
>> * CLJS-2002: Don't throw when no *print-fn* is set
>> * support Clojure primitive array type hints, core.async no longer
>>   gives warnings
>> * CLJS-2213: Node.js target should use node_modules index to emit
>> platform specific require
>> * CLJS-2200: bump to tools.reader 1.0.2
>> * CLJS-2135: require macro prints last result of loaded-libs
>> * CLJS-2192: Add ChakraCore testing facilities
>> * CLJS-1800: Defer to tools.reader for cljs.reader functionality
>> * CLJS-2163: Clean up uses of aget / aset on objects
>> * CLJS-2184: Add `ns-publics` and `ns-imports`
>> * CLJS-2183: Assert arguments are quoted symbols in some core macros
>> * CLJS-2182: Assert argument to resolve is a quoted symbol
>> * CLJS-2186: Update docstrings for aget/aset to be consistent with Clojure
>> * CLJS-2180: Allow compiling `:modules` with whitespace optimizations
>> * CLJS-1822: Use `:file-min` when processing JS modules with advanced
>> optimizations
>> * CLJS-2169: Error when compiling with :source-map and advanced
>> optimizations
>> * CLJS-2037: Throw if overwriting alias in current namespace
>> * CLJS-2160: Add loaded? and prefetch functions to cljs.loader
>> * CLJS-2148: Add unsafe-get and use goog.object
>> * CLJS-2161: Bump Closure Compiler to June 2017 release
>>
>> ### Fixes
>> * CLJS-1854: Self-host: Reload ns with const
>> * CLJS-2278: JavaScript object literals are printed wth keys that cannot
>> be read
>> * CLJS-2276: Self-host: Need test.check dep for CLJS-2275
>> * CLJS-2275: cljs.spec.alpha/fdef resolves eagerly
>> * CLJS-2259: Extra .cljs_node_repl directory containing cljs.core output
>> * CLJS-2274: Update CI script to install deps
>> * CLJS-2269: Warn on top level code split loads
>> * CLJS-2272: Tests that depended on default install deps behavior failing
>> * CLJS-2255: Clean up :npm-deps
>> * CLJS-2263: Docstring for neg-int? backwards
>> * CLJS-2262: Correct comment that *warn-on-infer* is file-scope
>> * CLJS-2258: Stack overflow regression for sequence xform applied to
>> eduction
>> * CLJS-2256: Generated code doesn't add newline after sourceMappingURL
>> comment
>> *

ANN: ClojureScript 1.9.908

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.908"]

This release includes a number of bug fixes and changes based on feedback
from the 1.9.854 release. For high level details please refer to the
announcement on the official site
https://clojurescript.org/news/2017-08-16-release

As always feedback welcome!

## 1.9.908

### Enhancements
* CLJS-2323: data readers support for records

### Changes
* CLJS-2322: Require only `@cljs-oss/module-deps` to be installed to figure
out Node.js dep graph
* CLJS-2321: Do not automatically call `set-loaded!` on the user's behalf
* CLJS-2316: Upgrade Closure Compiler to August release
* CLJS-2317: Upgrade Google Closure Library
* CLJS-2234: Make build scripts optionally less verbose
* CLJS-2314: Eliminate str call on literal strings in str macro
* CLJS-2291: Set up Windows CI
* CLJS-2286: Simplify JS module processing

### Fixes
* CLJS-2324: module-graph doesn't munge :requires when indexing inputs
* CLJS-2309: :module foreign-libs order not preserved
* CLJS-2318: module-deps.js doesn't respect the package.json `module` field
* CLJS-2312: Miss-compile: Uncaught SyntaxError: Unexpected token default
* CLJS-2315: module_deps.js can't resolve JSON modules
* CLJS-2313: :language-out is a build affecting option
* CLJS-2306: Provide better warning message when namespace can't be found
* CLJS-2303: Disable duplicate alias checking for self-host
* CLJS-2307: Closure warns on unreachable checked array code
* CLJS-2305 Tests: Unable to resolve symbol: opts in this context
* CLJS-2299: Failure with alias and bad require of clojure.spec
* CLJS-2302: Disable process-shim by default in Node.js targets
* CLJS-2266: Self-host: Cannot require clojure.x where clojure.x has no
macros namespace
* CLJS-2304: Fix compiler infrastructure tests on Windows
* CLJS-2261: Issue using interop record constructors in macros namespaces
* CLJS-2296: Foreign libs that expose modules are not being processed under
target nod
* CLJS-2293: Self-host: Can't load cljs.js owing to set alias
* CLJS-2295: `index-node-modules-dir` can't determine :main for
package.json files that have `.` in the string
* CLJS-1620: In JavaScript ES2015 modules default export name is munged to
default$
* CLJS-2287: Self-host: `require` prints result of loading node deps /
global exports
* CLJS-2290: Node packages using require('assert') fail compilation
* CLJS-2281: module_deps.js cannot compute inputs for ES6 sources
* CLJS-2284: Fix build API tests not to pollute `out` in the current
directory
* CLJS-2282: Some valid keywords are strings in JS object literals
* CLJS-2283: Regression with js-obj and gobject alias?

-- 
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.

ANN: ClojureScript 1.9.946

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.946"]

This release contains many bug fixes and addresses feedback from the 1.9.908
release. Important changes include parity with Clojure 1.9.0-beta1 and an
updated Google Closure Compiler dependency. The later one in particular now
means that ClojureScript has a dependency on JDK 8.

As always feedback welcome!

1.9.946

### Changes
* CLJS-2300: Delegate clojure.string/capitalize to goog.string/capitalize
* CLJS-2374: Print js/Infinity, js/-Infinity, js/NaN using new reader
literals
* bump tools.reader (1.1.0)
* CLJS-2372: update hash to use the new infinity literals
* CLJS-2364: Bump Closure Compiler to the Sep 2017 version
* CLJS-2340: Have js-keys delegate directly to good.object/getKeys
* CLJS-2338: Support renamePrefix{Namespace} closure compiler option

### Fixes
* CLJS-1576: fix source-map string encoding by applying encodeURIComponent
and fixing string/replace call
* CLJS-2294: Always use opts with implicit opts added
* CLJS-2166: Add uri? predicate
* CLJS-2368: Self-host: Never compile macro namespaces with
`:optimize-constants true
* CLJS-2367: Self-host: :def-emits-var leaks into loaded namespace
processing
* CLJS-2352: Emit valid JS for NaN etc. even when used w/ CLJ >=
1.9.0-alpha20
* CLJS-2339: Significant code reload slowdown with :npm-deps
* CLJS-2361: Self-host: circular dependency detection doesn't handle REPL
self-require
* CLJS-2356: Self-host: circular dependency detection is not correct
* CLJS-2354: Self-host: `compile-str` doesn't handle `clojure` -> `cljs`
aliasing
* CLJS-2353: use portable `node-module-dep?` function in analyze-deps
* CLJS-2345: escape paths emitted as args to cljs.core.load_file
* CLJS-2349: Port reset-vals! and swap-vals! over from Clojure
* CLJS-2336: Call alength once in areduce and amap
* CLJS-2335: Avoid alength on strings
* CLJS-2334: Also gather dependencies from foreign-libs that are modules
* CLJS-2333: module-deps.js doesn't correctly compute `main` if aliased in
browser field
* CLJS-2332: module_deps.js doesn't process `export from` correctly
* CLJS-2330: Don't set `"browser"` field for Closure if target is :nodejs
* CLJS-2326: Indexing node_modules can't find `main` when it doesn't have
an extension
* CLJS-2328: Args are not provided to *main-cli-fn* with optimizations
advanced
* CLJS-2327: module_deps.js doesn't know about browser field advanced usage

-- 
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: ANN: ClojureScript 1.9.542, spec changes & REPL enhancement

[David Nolen]

Will need something more minimal. Thanks.

David

On Fri, Oct 13, 2017 at 2:08 PM, Rangel Spasov  wrote:

> I'm getting this (I'm guessing related to the changes around CLJS-485
> RegExp flags):
>
> (iOS simulator screenshot attached).
>
>
> As you can see, the RN/JS stack traces are not very useful in this case.
> I can dig deeper if needed to find exactly where it fails (I have a few
> places where I use RegExp).
>
> Thanks all!
> Rangel
>
>
> On Friday, May 12, 2017 at 1:31:54 PM UTC-7, David Nolen wrote:
>>
>> ClojureScript, the Clojure compiler that emits JavaScript source code.
>>
>> README and source code: https://github.com/clojure/clojurescript
>>
>> Leiningen dependency information:
>>
>> [org.clojure/clojurescript "1.9.542"]
>>
>> This release is primarily about staying in sync with the latest changes
>> to spec. It
>> also includes a small but significant enhancement to REPLs to allow
>> handling multiple forms.
>>
>> As always, feedback welcome!
>>
>> ## 1.9.542
>>
>> ### Enhancements
>> * CLJS-1572: REPL doesn't give error for expressions with too many right
>> parentheses
>>
>> ### Changes
>> * cljs.spec -> cljs.spec.alpha
>> * CLJS-2013 - Add MapEntry type
>> * CLJS-2015: Self-host: `defmacro` should return the Var
>> * CLJS-2017: Upgrade Closure Compiler to latest April 2017 release
>>
>> ### Fixes
>> * CLJS-485: RegExp flags are being dropped by string/replace
>> * CLJS-1518: Case macro expansion evaluates expression twice
>> * CLJS-2024: Self-host: `find-ns-obj` broken for namespaces with 'a' as
>> the first segment
>> * CLJS-2028: `realized?` throws on LazyTransformer
>> * CLJS-2010: refer-clojure :rename throws on valid invocations
>> * CLJS-2007: Whitespace optimizations should respect :main option.
>>
>> --
> 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.

ANN: ClojureScript 1.10.238, cljs.main & more

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.10.238"]

This release contains a very large number of enhancements. Please
refer to the announce post for details:
https://clojurescript.org/news/2018-03-26-release

As always, feedback welcome!

## 1.10.238

### Enhancements
* cljs.main, simple command line access to Compiler & REPLs
* cljs.server.* namespaces for integration with -Dclojure.server.repl
* :aot-cache compiler to enable global AOT caching of dependencies in JARs
* :stable-names compiler flag, to support vendorization when using
:modules,
  defaults to true when using :modules.
* Add :webworker & :nashorn target
* pREPL implementation (usage requires Clojure 1.10.0-alpha)

### Changes
* * CLJS-2592: :npm-deps using ES6 modules with .mjs extensions are not
detected correctly
* AOTed ClojureScript artifact is now the default, for sources only use the
  "slim" Maven classifier
* Bump Closure Compiler
* REPL now show uniform prompts
* CLJS-2660: Add cljs.core/eval which, delegates to an overridable *eval*
* CLJS-2375: Remove AMD Module Support
* CLJS-2413: Port core.specs.alpha to ClojureScript
* CLJS-2423: Allow custom :output-wrapper function
* Map entries are no longer two element vectors, now MapEntry instances
* *print-fn* automatically set
* CLJS-2561: AOT compile browser REPL client js
* CLJS-2581: Create a cljs.repl/*repl-env* dynamic var and bind it around
cljs repl loops

### Fixes
* CLJS-2680: Passing :watch-fn via --compile-opts to cljs.main
* CLJS-2692: cljs.core.specs.alpha: Import list needs to require quote
* CLJS-2696: Large code size in Clojurescript 1.10.x for minimal code with
optimizations advanced
* CLJS-2699: Use higher-level Closure API for module-processing
* CLJS-2691: goog.require in module-processed files shouldn't require
goog.base
* CLJS-2689: Don't try to use node resolve for goog: modules
* CLJS-2676: Bad cljs.loader behavior for modules with multiple provides
* CLJS-2673: Regression: Can't require cljs.js
* CLJS-2650: Fix JAR compilation of cljs.loader
* CLJS-2671: Double analysis warning for source in JAR with AOT cache
* CLJS-2643: Socket REPL output can be directed to the wrong place
* CLJS-2670: Update cljs.compiler/warning-types
* CLJS-2491: Inference warnings are not reported
* CLJS-2653: REPL crash when mapping stacktrace in Chrome for js/blah
* CLJS-2639: Compiler crash when using aot cache with parallel compile
* CLJS-2520: Synthesize ClojureScript version if using non-built
ClojureScript dep
* CLJS-2522: Handle sources that are maps in build-modules
* CLJS-2521: Only expand module graph when modules are actually used
* CLJS-2519: Module loader doesn't load :cljs-base properly
* CLJS-2493: Self host: respect :source-map-timestamp compiler option
* CLJS-2500: Call process-js-modules after compiler restart
* CLJS-2516 Build API fails targeting Node (QuickStart)
* CLJS-2462: subvec on non-integral indexes fails
* CLJS-2474: with-meta on lazy-seq causes separate realization
* CLJS-2501: Fix crash in cljs.util/compiled-by-version and build-options
* CLJS-2476: recur across try should fail compilation
* CLJS-2495: Closure compilation errors should stop Cljs compilation
* CLJS-2496 PHM seq and iter should return MapEntry on nil key case
* CLJS-2473: Infer character literals to have string type
* CLJS-2455: nth fails on eduction
* CLJS-2001: Add map-entry? predicate
* CLJS-2131: Calling empty on a ChunkedSeq should return empty list
* CLJS-1743: Transient maps should support IFn
* CLJS-2452: reverse empty vector returns nil
* CLJS-2450: Allow configuring ignored JS module extensions
* CLJS-2417: Inter-ns s/fdef expansion side effect fails when load cached
source
* CLJS-2447: Ignore css JS modules
* CLJS-2397: Multi-arity function instrumentation fails with :static-fns
true
  CLJS-2197: Calling instrumented var fails to check conformance
* CLJS-2443: doseq should return nil with no collections
* CLJS-2430: Fix foreign-libs with Node target
* CLJS-2414: Self-host: Macro specs are instrumented
* CLJS-2387: CLJS Analyzer does not correctly detect cache hits for
analyzed spec files
* CLJS-2405: Register dumped specs fails
* CLJS-2416: Self-host: defn macro Var doesn't have :macro true meta
* CLJS-2425: Remove unnecessary zero? checks from nat-int?
* CLJS-2377: The CLJS compiled uses deprecated modules on Java 9
* Allow clj->js to preserve namespaces
* CLJS-2391: Unable to :stub a function using stest/instrument
* CLJS-2378: keep the :npm-deps-installed? to avoid to reinstall NPM deps

-- 
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 

ANN: ClojureScript 1.10.312, Improved Externs Inference & Webpack Guide

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.10.312"]

This release contains many fixes and enhancements, the most notable being
those around externs inference. With enhanced externs inference,
integration with tools like Webpack is greatly improved and we now provide
an official guide https://clojurescript.org/guides/webpack.

For more details see https://clojurescript.org/news/2018-06-15-release

As always, feedback welcome!

David

-- 
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: ANN: ClojureScript 1.10.312, Improved Externs Inference & Webpack Guide

[David Nolen]

1.10.329 was released today, it addresses a few minor issues in 312
including an externs inference bug.

David

On Fri, Jun 15, 2018 at 10:50 AM, David Nolen 
wrote:

> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "1.10.312"]
>
> This release contains many fixes and enhancements, the most notable being
> those around externs inference. With enhanced externs inference,
> integration with tools like Webpack is greatly improved and we now provide
> an official guide https://clojurescript.org/guides/webpack.
>
> For more details see https://clojurescript.org/news/2018-06-15-release
>
> As always, feedback welcome!
>
> David
>

-- 
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.

ANN: ClojureScript 1.10.439

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.10.439"]

Please refer the announce post for the details:
https://clojurescript.org/news/2018-11-02-release

As always, feedback welcome!

## 1.10.439

### Changes
* CLJS-2904: Default :npm-deps to false
* CLJS-2878: Update Closure Compiler to v20180805
* CLJS-2827: Avoid var special in core macros for private var access
* CLJS-2819: Warn on non-dynamic earmuffed vars
* CLJS-2806: Bump test.check to 0.10.0-alpha3
* CLJS-2815: Support string keys in :global-exports
* CLJS-2812: Support for overriding object printing
* CLJS-2805: Bump tools.reader to 1.3.0
* CLJS-1702: Warning when using private vars
* Align ClojureScript AST to tools.analyzer

### Enhancements
* CLJS-2903: Support fingerprinting
* CLJS-2897: cljs.main: Display initial REPL prompt sooner
* CLJS-2884: Support for GraalJS RC6
* CLJS-2859: Graal.JS: Enable high-res timers by default, allow
user-configuration
* CLJS-2831: Add a graaljs REPL environment
* CLJS-1997: Outward function type hint propagation
* CLJS-844: Optimize js->clj by switching to transients
* CLJS-2442: `set` and `vec` performance enhancements

### Fixes
* CLJS-2953: stest/with-instrument-disabled prints warning of private use
* CLJS-2728: Ability to disable macro spec checks
* CLJS-2843: s/explain of evaluated predicate yields :s/unknown
* CLJS-2951: Add a spec generator for some?
* CLJS-2940: Can't define nilable spec on undefined pred
* CLJS-2948: Stack overflow calling instrumented variadic fn with zero args
* CLJS-2793: Instrumenting breaks function with varargs
* CLJS-2934: Enhanced delay printing
* CLJS-2864: Optimize str macro for single arity case
* CLJS-1297: defrecord does not emit IKVReduce protocol
* CLJS-2937: docstring for to-array
* CLJS-2943: Update merge-with to use key / val
* CLJS-2941: seqable? should return true for nil
* CLJS-2915: Tests fail if directory has a period (.) in the path
* CLJS-2782: lein test fails if directory has hyphens
* CLJS-2911: Avoid infinite loop on infinite partitions
* CLJS-2906: cljs.main: Crash when with default REPL
* CLJS-2883: Instrumentation fails compilation with a large number of
spec'd functions
* CLJS-2896: Allow parallel analysis and compilation
* CLJS-2893: seq: use .-length instead of alength for strings
* CLJS-2890: fspec role in problem path is not useful
* CLJS-2887: Improve names in core macro specs
* CLJS-2891: stop including data in ex-info message
* CLJS-2888: Printing of spec problems buries the failing predicate which
should be more prominent
* CLJS-2861: Self-host: :checked-arrays not working
* CLJS-2852: Clojure imparity: ns-publics returns different arglists for
macros
* CLJS-2725: Doc on spec keywords
* CLJS-2665: Port clojure.spec.test.alpha/enumerate-namespace
* CLJS-2848: Default explain printer prints root val and spec
* CLJS-2846: [spec] s/tuple explain-data :pred problem
* CLJS-2847: s/coll-of and s/every gen is very slow if :kind specified
without :into
* CLJS-2841: [spec] instrument exception doesn't contain function name in
ex-data
* CLJS-2842: [spec] Clarify s/every docstring for :kind
* CLJS-2845: [spec] generate random subsets of or'd required keys in map
specs
* CLJS-2844: [spec] Add support for undefining a spec
* CLJS-2840: [spec] s/keys explain-data :pred problem
* CLJS-2839: [spec] s/& explain-data :pred problem
* CLJS-2838: [spec] s/& does not check preds if regex matches empty
collection
* CLJS-2837: [spec] `cat` specs should verify value is sequential
* CLJS-2541: binding not made in parallel
* CLJS-2832: Bad code gen for `((not empty?) "foo")` when compiled with no
optimizations
* CLJS-2855: Browser REPL prints empty string after require
* CLJS-2821: Update doto docstring to not use Java example
* CLJS-2817: Suppress private var warnings for specs on private vars
* CLJS-2822: cljs.core.specs.alpha: Map bindings should be `:kind map?`
* CLJS-2829: Fix deep object property access for :global-exports
* CLJS-2816: Skip non-string package.json browser entry values
* CLJS-2814: Fix munge-node-lib/global-export on self-host
* CLJS-2811: cljs-1537-circular-deps fail on Windows
* CLJS-2807: Macroexpand failure with set literal
* CLJS-2799: Handle nth on seqables with negative indexes
* CLJS-2798: ChunkCons -next doesn't handle nil more
* CLJS-2589: allow / as a protocol method name in cljs

-- 
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 

ANN: ClojureScript 1.10.516

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Please refer to the announce post for the details:
https://clojurescript.org/news/2019-01-31-release

As always, feedback welcome!

-- 
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: Clojure, Slime and multiple file projects

[David Nolen]

A simple solution is to define a namespace that brings in all of your
different files. Is there some reason you can't do things this way?

On Mon, Feb 9, 2009 at 8:05 AM, Bradbev  wrote:

>
> Hi folks,
> I'm getting to the stage on a Clojure project that I want to start
> breaking the code into multiple files.  My primary environment is
> Emacs & Slime and interactive development.  Is there a standard way
> for me to load all of my project's files into the running VM?
> Right now I manually go to each file & load it.  I guess I could also
> write a little function that loaded all the files in the correct
> order, but if there is an actual framework tool (like ASDF) then I
> would try to use that.
>
> Cheers,
> Brad
> >
>

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: How to port a mixin to clojure

[David Nolen]

There are quite a few ways to do what you're describing (and no particular
prescribed way).  You want to look at multimethods and tag hierarchies.
http://clojure.org/multimethods

Tags can have multiple parents.

I'm working on a project called Spinoza (search the mailing list for that
and CLJOS) which you might want to give a look if you want to see one
perspective on what a syntax to do the above might look like.  It also uses
multimethods and hierarchies but it removes the need to manually deal with
tags or explicitly call object initializers.

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Generic functions: things, models, and protocols revisited

[David Nolen]

Neat! You've removed the need to even define a dispatch-fn.  I'll need to
chew on this for a bit (I'm a little slow :) I'm still working on my attempt
at implementing protocols, but I'm not totally clear on where it will go or
how useful it will be.
Seems like this kind of dispatch and the Datalog project might meet up soon?
Or am I totally wrong?
On Thu, Feb 12, 2009 at 12:02 PM, mikel  wrote:

>
> David Nolen and I were recently discussing CLOS and method dispatch. I
> implemented such a scheme for my own use. This post is an FYI for
> David and anyone else who might be interested in generic functions and
> predicate dispatch.
>
> Here's a transcript of a sample session in which I exercise the
> dispatch cases:
>
> (def $gf (make-generic-function))
>
> (add-gf-method $gf [nil] (fn [x] (str "found value: " (.toString x) "
> of type: " (.toString (class x)
>
> (add-gf-method $gf [java.lang.Number] (fn [x] (+ x 1)))
>
> (add-gf-method $gf [java.lang.String] (fn [x] (str "Found string: "
> x)))
>
> (add-gf-method $gf [{:equals 5}] (fn [x] (str "Found 5!")))
>
> (add-gf-method $gf [{:model {:name nil}}] (fn [x] (str "Found a thing
> whose name is " (:name x
>
> (add-gf-method $gf [java.lang.Number java.lang.Number] (fn [x y] (+ x
> y)))
>
> (add-gf-method $gf [java.lang.String java.lang.String] (fn [x y] (str
> x " " y)))
>
> (add-gf-method $gf [java.lang.String java.lang.Integer] (fn [s i]
> (apply str (take i (cycle [s])
>
> (add-gf-method $gf [{:test (fn [x] (= x "swordfish"))}] (fn [s] (str
> "You said the secret word, you win a hundred dollars!")))
>
> user> ($gf "hello" "world")
> "hello world"
> user> ($gf 2 3)
> 5
> user> ($gf {:name "Barney"})
> "Found a thing whose name is Barney"
> user> ($gf 5)
> "Found 5!"
> user> ($gf "bananas")
> "Found string: bananas"
> user> ($gf 100)
> 101
> user> ($gf 'some-symbol)
> "found value: some-symbol of type: class clojure.lang.Symbol"
> user> ($gf "foo" 5)
> "foofoofoofoofoo"
> user> ($gf "swordfish")
> "You said the secret word, you win a hundred dollars!"
>
>
> It works well enough to produce that transcript, but is very
> preliminary. I'm sure there are bugs I haven't noticed yet, and no
> doubt it's terribly slow. For one thing, I know it's doing a lot of
> redundant comparisons at the moment.
>
> It's missing a number of amenities and at least one important feature:
> next-method is not yet implemented.
>
> When called, a generic function matches the arguments it received
> against formal parameters in its dispatch table. Matching of a formal
> parameter works like so:
>
> nil: match any value passed in this position
>
> a Java class: match any value that is an instance of the class (or of
> a subclass of it)
>
> a Map of the form: {:model m}: match any value v for which (model? v
> m) returns true
>
> a Map of the form {:equals x}: match any value v for which (= v x)
> returns true
>
> a Map of the form {:test f}: match any value for which (f x) returns
> true
>
>
> Calling  ($gf 2 3) or whatever works because the object in $gf is a
> closure:
>
> (defn make-generic-function [& [dispatch-table]]
>  (let [dt-ref (or dispatch-table (ref {}))]
>(fn [& args] (apply-generic-function dt-ref args
>
> There's a little trickery with sentinel values and metadata to enable
> me to provide an API for adding and removing methods, which are stored
> in the dispatch-table created in make-generic-function. It would be
> nice to make that code a little less clever, but that would require a
> convenient way to create a new kind of callable object; I'd need to be
> able to define what happens when it's applied.
>
> Now we'll see if this thing is useful enough to make it better.
> >
>

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Generic functions: things, models, and protocols revisited

[David Nolen]

>
>
> > Seems like this kind of dispatch and the Datalog project might meet up
> soon?
> > Or am I totally wrong?
>
> I have given it zero thought.


Perhaps interesting to pursue? Rich had brought it up in conversations about
predicate dispatch. Could greatly help from the performance side of things?

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Newbie at macros: Manipulating a vector of bindings

[David Nolen]

You can pretty much call anything outside of the quote, in fact all runtime
information is available (you have access to anything that was previously
read).  The main thing to understand is that all parameters passed to your
macro are unevaluated.

On Sat, Feb 14, 2009 at 10:45 AM, samppi  wrote:

>
> Thank you so much. I'm confused, however, about what functions you're
> allowed to call inside a macro outside of a quote. I read once that
> "runtime information" was unavailable during the macro phase. But it
> seems that one is still allowed to call array-map, apply, take-nth,
> and vec during the macro phase. What is the pattern for what is
> allowed or prohibited in macros?
>
> On Feb 13, 10:52 pm, Chouser  wrote:
> > On Fri, Feb 13, 2009 at 11:17 PM, samppi  wrote:
> >
> > > I'm trying to write a macro that expands from this:
> >
> > > (product-context [n rule0, m rule1)]
> > >  (rule-maker2 (+ n m)) rule3))
> >
> > > Into this (assume that conc-fn and conc-products are functions):
> >
> > > (fn [tokens]
> > >  (if-let [[remainder# n m] (conc-products [rule0 rule1] tokens)]
> > >(conc-fn [(rule-maker2 (+ n m)) rule3] remainder#)))
> > > ...but I can't figure out how to change [n rule0 m rule1] to (if-let
> > > [[remainder# n m] (conc-products [rule0 rule1] tokens)] ...).
> >
> > Try working it out outside of the macro context.
> >
> > (def bindvec '[n rule0, m rule1])
> >
> > Now you've got something to work with.  There are plenty of acceptible
> > answers.  Maybe you want to think of the vector as key/value pairs:
> >
> > (apply array-map bindvec)  ==> {n rule0, m rule1}
> > (keys (apply array-map bindvec))  ==> (n m)
> > (vals (apply array-map bindvec))  ==> (rule0 rule1)
> >
> > Or just use some seq function:
> >
> > (take-nth 2 bindvec)  ==> (n m)
> > (take-nth 2 (rest bindvec))  ==> (rule0 rule1)
> >
> > Once you've got the pieces you need, try sticking them into a
> > syntax-quote:
> >
> > user=> `(if-let [[r# ~(take-nth 2 bindvec)] (cp ~(take-nth 2 (rest
> > bindvec)))] ...)
> > (clojure.core/if-let [[r__215__auto__ (n m)] (user/cp (rule0 rule1))]
> ...)
> >
> > Well, that's close by there are extra parens around (n m) and you want
> > a vector not a list for the rules.  So play with it until it looks
> > right:
> >
> > user=> `(if-let [[r# ~@(take-nth 2 bindvec)] (cp ~(vec (take-nth 2
> > (rest bindvec] ...)
> > (clojure.core/if-let [[r__219__auto__ n m] (user/cp [rule0 rule1])] ...)
> >
> > Then you're ready to build the macro:
> >
> > (defmacro product-context [bindvec & body]
> >   `(fn [tokens#]
> >  (if-let [[remainder# ~@(take-nth 2 bindvec)]
> > (conc-products [~@(take-nth 2 (rest bindvec))] tokens#)]
> >(conc-fn [...@body] remainder#
> >
> > --Chouser
> >
>

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Newbie: Separating and grouping the elements in a bunch of vectors

[David Nolen]

(map (fn [& rest] (apply vector rest)) [1 2 3] ['a 'b 'c] ["cat" "dog"
"bird"])

On Sun, Feb 15, 2009 at 7:16 PM, samppi  wrote:

>
> What would I do if I wanted this:
>
> [[a0 a1 a2] [b0 b1 b2] ...] -> [[a0 b0 ...] [a1 b1 ...] [a2 b2 ...]]
>
> I could write a loop, I guess, but is there a nice, idiomatic,
> functional way of doing this? I didn't spot a way in
> clojure.contrib.seq-utils either.
> >
>

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Newbie: Separating and grouping the elements in a bunch of vectors

[David Nolen]

Actually something closer to your exact expression is this:

(apply (partial map (fn [& rest] (apply vector rest))) [[1 2 3] ['a 'b 'c]
["cat" "dog" "bird"]])

On Sun, Feb 15, 2009 at 7:42 PM, David Nolen  wrote:

> (map (fn [& rest] (apply vector rest)) [1 2 3] ['a 'b 'c] ["cat" "dog"
> "bird"])
>
>
> On Sun, Feb 15, 2009 at 7:16 PM, samppi  wrote:
>
>>
>> What would I do if I wanted this:
>>
>> [[a0 a1 a2] [b0 b1 b2] ...] -> [[a0 b0 ...] [a1 b1 ...] [a2 b2 ...]]
>>
>> I could write a loop, I guess, but is there a nice, idiomatic,
>> functional way of doing this? I didn't spot a way in
>> clojure.contrib.seq-utils either.
>> >>
>>
>

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Newbie: Separating and grouping the elements in a bunch of vectors

[David Nolen]

Of course ;) Keep forgetting the obvious things.

On Sun, Feb 15, 2009 at 9:36 PM, Stuart Halloway
wrote:

>
> (map vector [1 2 3] ['a 'b 'c] ["cat" "dog" "bird"])
> -> ([1 a "cat"] [2 b "dog"] [3 c "bird"])
>
> > Actually something closer to your exact expression is this:
> >
> > (apply (partial map (fn [& rest] (apply vector rest))) [[1 2 3] ['a
> > 'b 'c] ["cat" "dog" "bird"]])
> >
> > On Sun, Feb 15, 2009 at 7:42 PM, David Nolen
> >  wrote:
> > (map (fn [& rest] (apply vector rest)) [1 2 3] ['a 'b 'c] ["cat"
> > "dog" "bird"])
> >
> >
> > On Sun, Feb 15, 2009 at 7:16 PM, samppi  wrote:
> >
> > What would I do if I wanted this:
> >
> > [[a0 a1 a2] [b0 b1 b2] ...] -> [[a0 b0 ...] [a1 b1 ...] [a2 b2 ...]]
> >
> > I could write a loop, I guess, but is there a nice, idiomatic,
> > functional way of doing this? I didn't spot a way in
> > clojure.contrib.seq-utils either.
> >
> >
> >
> >
> > >
>
>
> >
>

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

error-kit + test-is

[David Nolen]

I've been attempting to combine error-kit and test-is, but getting the
relation between assert-expr form in test-is and the handle form in
error-kit is a bit tricky. Looking at the test-is thrown? example and
Chouser's error-kit post on the mailing list I tried something like the
following:

(defmethod assert-expr 'raised? [msg form]
  (let [error-type (second form)
body (rrest form)]
`(with-handler
  (do
~...@body
(report :fail ~msg '~form nil))
  (handle {:keys [& rest#]}
  (let [tag# (last rest#)]
(println "raised!" rest# ~error-type)
(if (= ~error-type tag#)
  (report :pass ~msg '~form nil)
  (report :fail ~msg '~form nil)))

The assert-expr seems OK, but I can't seem to get the error-type tag from
handle.

So here's the promised feedback on handle Chouser ;)

David

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: ANN: clojure.contrib.error-kit

[David Nolen]

Would it be possible to make the arguments to handle be optional? Is this a
good or bad idea?

It seems to me, in the case of setting up test fixtures that check for
raised errors, often you don't care what arguments the error takes.

David

On Fri, Feb 6, 2009 at 9:10 PM, Chouser  wrote:

>  (kit/with-handler
>(vec (map int-half [2 4 5 8]))
>(kit/handle *odd-number-error* [n]
>  (throw (Exception. (format "Odd number %d in vector." n)
>

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Newbie: Separating and grouping the elements in a bunch of vectors

[David Nolen]

> I'm sure it can be done, but it's not clear to me if you have a vector of
> vectors
> how Stuart's solution would work:
>
> 1:15 user=> (map vector vecs)

([[:a0 :a1 :a2]] [[:b0 :b1 :b2]])


(apply (partial map vector) [[1 2 3] ['a 'b 'c] ["cat" "dog" "bird"]])

works on a vector of vectors. The OP wanted a vector of vectors as a result
where the subvector length is the same as the number of vectors originally
passed in.

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: error-kit + test-is

[David Nolen]

(defmethod assert-expr 'raised? [msg form]
  (let [error-type (second form)
error-meta (meta (find-var (qualify-sym error-type)))
error-str  (str (ns-name (:ns error-meta)) "/" (:name error-meta))
body   (rrest form)]
`(with-handler
  (do
~...@body
(report :fail ~msg '~form (str ~error-str " not raised.")))
  (handle ~error-type {:as err#}
(if (= (:tag err#) (symbol ~error-str))
  (report :pass ~msg '~form nil)
  (report :fail ~msg '~form (str ~error-str " was raised."
  (handle *error* {:as err#}
(report :fail ~msg '~form (:tag err#))

Here is the macro that seems to work, any improvements much appreciated ;)
This fails when no error is raised, when the wrong error type is raised, and
I believe it's captures errors which are derived but not the exact error (is
this a weird behavior?).  Your previous post about error-kit got me on the
right track. I can now define test cases like so:

(deftest test-verify-slots
  (is (verify-slots [[:origin [0 0]] :width :height]))
  (is (raised? *malformed-slots-error* (verify-slots [[:origin] :width
:height])))
  (is (raised? *malformed-slots-error* (verify-slots [[:origin 0 0] :width
:height])))

Much nicer than those ugly Java Exceptions, no? ;)

On a last note, I've found your qualify-sym fn quite handy and have been
using it elsewhere ;)


On Sun, Feb 15, 2009 at 11:52 PM, Chouser  wrote:

>
> On Sun, Feb 15, 2009 at 10:06 PM, David Nolen 
> wrote:
> > I've been attempting to combine error-kit and test-is, but getting the
> > relation between assert-expr form in test-is and the handle form in
> > error-kit is a bit tricky. Looking at the test-is thrown? example and
> > Chouser's error-kit post on the mailing list I tried something like the
> > following:
> >
> > (defmethod assert-expr 'raised? [msg form]
> >   (let [error-type (second form)
> > body (rrest form)]
> > `(with-handler
> >   (do
> > ~...@body
> > (report :fail ~msg '~form nil))
> >   (handle {:keys [& rest#]}
> >   (let [tag# (last rest#)]
> > (println "raised!" rest# ~error-type)
> > (if (= ~error-type tag#)
> >   (report :pass ~msg '~form nil)
> >   (report :fail ~msg '~form nil)))
> >
> > The assert-expr seems OK, but I can't seem to get the error-type tag from
> > handle.
> >
> > So here's the promised feedback on handle Chouser ;)
>
> Thanks!  You're a brave man for trying such a thing, when error-kit
> has such thin documentation.
>
> I think there are a couple problems.  One is your attempt at using &
> in a :keys destructuring expression.  It amounts to something like:
>
> (let [{:keys [& etc]} {:a 1, :b 2}]
>  etc)
> -> nil
>
> You may want to use {:as err-map#} instead, and then pick out the :tag
> from the err-map# later.  Or perhaps simply insert the ~error-type
> there directly.
>
> Another issue is that what is stored in the err-map's :tag value is
> the fully-qualified symbol of the error, not the value of that symbol
> (which happens to be the fn used to construct it) which is what your
> ~error-type would evaluate to.  I know it's confusing, but it's how it
> had to be, since I need the name and functions don't really have names.
>
> To make things worse, getting the fully-qualified name from the macro
> argument, which is likely a symbol with a nil namespace, is a bit of a
> trick.  error-kit/qualify-sym does this, but it's currently private.
> It may make sense to make that public for just the kind of shenanigans
> you're trying to pull.
>
> If this has been to dense or sketchy, let me know and I'll see if I
> can help you further.  This is exactly the kind of thing error-kit
> needs to be able to do.
>
> --Chouser
>
> >
>

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: error-kit + test-is

[David Nolen]

Heh not macro, I meant multimethod.

Here is the macro that seems to work, any improvements much appreciated ;)
> This fails when no error is raised, when the wrong error type is raised, and
> I believe it's captures errors which are derived but not the exact error (is
> this a weird behavior?).  Your previous post about error-kit got me on the
> right track. I can now define test cases like so:
>

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: error-kit + test-is

[David Nolen]

> I don't quite understand why you got through all that work to get
> error-str -- isn't it just (str (qualify-sym error-type))?
>
> ...and since you then use it only as an arg to 'symbol' or 'str', you
> could just use the symbol itself instead of converting it to a string
> and back.
>

If I bring the symbol back directly, it gets evaluated to the actual error
object and not the symbol.  I want to compare symbols. Or maybe I don't,
comparing symbols in general seems simpler for meta-hacky stuff like this.


>
>
> > This fails when no error is raised, when the wrong error type is raised,
> and
> > I believe it's captures errors which are derived but not the exact error
> (is
> > this a weird behavior?).
>
> I'm not sure, but I think you'd want to allow an implementation to
> change to a derived error type without breaking the tests.  But I
> could be wrong -- it should probably behave the same as the 'throws?'
> method, since Java Exceptions also do inheritance.
>

Good point. Easy enuf.


>
>
> > Much nicer than those ugly Java Exceptions, no? ;)
>
> Sure, looks good to me.  Would it ever be useful to test that the
> error has a particular set of arguments?  I guess that may be more
> detailed than any test would want to get.
>

Possibly, but I can't think of a really goo reason for this yet.


> It would also be interesting to try to test for the existence and
> behavior of any 'continue' forms.
>

Very interesting, I haven't got to continue yet, baby steps here.


>
>
> Really!?  I'd never needed it before error-kit, and I'm pretty
> suspicious of needing it even there.  I think I'd rather just use Vars
> for error tags, but they're not currently allowed in the Clojure
> inheritance hierarchies.  If Vars were Named, I think it would work,
> and it's not at all clear to me why they aren't, since they have a
> namespace and a name just like symbols and keywords do.  Rich is
> probably too busy with lazier just now, but I intend to be annoying
> about this at some later date.
>

That's the proper solution. Until then for really wacky stuff, I don't know
how to do certain things without qualify-sym.

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Fully lazy sequences are coming - feedback wanted!

[David Nolen]

> butlast, doall, dorun, doseq, dosync, dotimes, doto, fnseq, gensym,
> macroexpand, macroexpand-1, mapcat, nthrest
>
>
-1

Because they are similar to other Lisps I assume.  The same reason for
println vs print-line. Changing these are a bad idea in IMHO.

Breaking the meaning of rest with Common Lisp is a consideration to take
seriously.  However as long as the documentation clearly states (highlights
in big bold colors ;) this difference (and the fact the operation is support
by next) then I think this is a change people can live with.

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: compiling a GUI app and also: interference of Java's built-in architechture

[David Nolen]

On Mon, Feb 16, 2009 at 10:27 AM, rob levy  wrote:

> So if I am right about these two facts, it seems like Clojure should
> include a native way of making applets/applications that both enables the
> truly functional style that Clojure is built on, and doesn't require writing
> Java to call it (it seems like Clojure should replace Java, not perpetuate
> it, other than to build on its vast libraries, IMHO).  What do you think
> (and is there something I'm understanding wrong here)?
>

Someone correct me if I'm way off, but User Interfaces are by definition
very mutation heavy.  It has come up before that Clojure's emphasis on
immutability is a tool not a religious decree.  Mutation is fine, just don't
mindlessly sprinkle it all over your program.  Even a language like Haskell
(which I know very little about) needs special constructs for IO. But this
is exactly what your example illustrates! mouse -> I, screen -> O.
Mutability sneaks in ;)

Of course it would be interesting to see a UI framework that is more
functional, but having done a considerable amount of UI programming this
seems to me like mostly a waste of time.

Instead of dictating, Clojure simply encourages you to reflect on whether
you really need mutation. If you absolutely need mutation, Clojure isn't
going to stop you.  And that's a great thing.

David

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: error-kit + test-is

[David Nolen]

(defmethod assert-expr 'raised? [msg [_ error-type & body :as form]]
 (let [error-name (qualify-sym error-type)]
   `(with-handler
  (do
~...@body
(report :fail ~msg '~form ~(str error-name " not raised.")))
  (handle ~error-type {:as err#}
  (report :pass ~msg '~form nil))
  (handle *error* {:as err#}
(report :fail ~msg '~form (:tag err#))

You're right I think the entire first handle statement was wrong.  I believe
handle does the isa? check on the error type, correct? If so then this will
allow inherited error types to pass the test.

Many, many thanks for the feedback.

test-is + error-kit is a great combo.

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Idiomatic Way to Write the Following:

[David Nolen]

Is using subvec for something like this a bad idea?

On Wed, Feb 18, 2009 at 12:38 AM, CuppoJava wrote:

>
> Hi,
> I'm wondering if there's a terser more idiomatic way to write the
> following. I want to get a new vector with the specified indexes
> removed. I found myself doing this often enough to warrant writing my
> own function for this but I would be much happier if there's some
> terse way of expressing this using the standard clojure functions.
>
> (defn remove_at [coll & indexes]
>  (map second
>   (remove #(some #{(first %)} indexes) (map vector (iterate inc
> 0) coll
>
> Thanks a lot
>  -Patrick
> >
>

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Performance of (fn [] ...)?

[David Nolen]

new MBP 2.53ghz

(defn create-fn []
  (fn [] (println "hi")))

(time (dotimes [x 4000]
(create-fn)))

> "Elapsed time: 1034.409 msecs"

Hopefully you don't need 40,000,000 functions in less than a second ;)

On Wed, Feb 18, 2009 at 1:16 AM, CuppoJava wrote:

> (defn create_fn []
>  (fn [] (println "hi")))
>

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Idiomatic Way to Write the Following:

[David Nolen]

My point was that you could use subvec to do vector splicing and build your
remove function off of that.  I'm sure the more experienced Clojurians can
chime in on what is the most idiomatic form.

On Wed, Feb 18, 2009 at 1:10 AM, CuppoJava wrote:

>
> Mmm, subvec doesn't quite seem to do the same thing.
>
> I want a function that removes certain indexes of a vector:
> eg. (remove_at [1 2 3 4 5 6] 0 3) => [2 3 5 6]
> >
>

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: how to learn clojure ?

[David Nolen]

Practical Common Lisp is also online and free. Though there are significant
differences between the two languages many of the strange and beautiful
concepts that Clojure embraces are covered there.  Especially dynamic
variables, macros, destructuring bind, and multiple dispatch.
On Wed, Feb 18, 2009 at 7:53 AM, MarisO  wrote:

>
> All documentation I've seen about clojure assumes knowledge of lisp
> which I dont have.
>
> >
>

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: bug affecting clojure.core/bean?

[David Nolen]

If I've been following things correct:
rest _used_ to force the seq, it does no longer.
next forces the seq

In my own mind i'm thinking next to mean (return the seq with the next value
computed), rest now means just give me the uncomputed remaining values of
the seq.

On Wed, Feb 18, 2009 at 12:00 PM, Laurent PETIT wrote:

>
>
> 2009/2/18 Mark Volkmann 
>
>
>> On Wed, Feb 18, 2009 at 10:27 AM, Rich Hickey 
>> wrote:
>> >
>> > On Feb 18, 11:04 am, Chouser  wrote:
>> >> On Wed, Feb 18, 2009 at 12:35 AM, Rob  wrote:
>> >>
>> >> > I'm wondering if I found a bug.  I have the latest source from svn
>> >> > (r1291).
>> >>
>> >> > user=> (bean 1)
>> >> > java.lang.IllegalArgumentException: Wrong number of args passed to:
>> >> > core$bean--5161$fn--5179$thisfn
>> >>
>> >> You sure did.  The conversion to lazy-seq code appears to introduce a
>> >> paren typo and an incorrect nil pun.  Patch attached.
>> >>
>> >
>> > Patch applied, svn 1293 - thanks!
>> >
>> >> Rich, I think it'd be pretty useful to have as you mentioned in IRC a
>> >> variant of & destructuring that provided an unforced lazy-seq.  It
>> >> seems pretty common to want, in the body of a lazy-seq, a destructured
>> >> 'first' but an unforced 'rest'.  This is already the third or fourth
>> >> time I've wanted to be able to do something like:
>> >>
>> >>   (fn thisfn [plseq]
>> >> (lazy-seq
>> >>   (when-let [[pkey &rest etc] plseq]
>> >> (cons (new clojure.lang.MapEntry pkey (v pkey))
>> >>   (thisfn etc)
>> >>
>> >
>> > Yes, sure. It just comes down to the name:
>> >
>> > &rest
>> > &&
>> >
>> > others?
>>
>> Of those I prefer &rest because its meaning is more explicit.
>
>
> Maybe I miss the point totally, but didn't the recent change give the
> function 'next the meaning of not forcing the seq ?
>
> So &next instead of &rest ? ... and maybe either &rest or &next , and not
> just & anymore ?
>
>
>>
>>
>> --
>> R. Mark Volkmann
>> Object Computing, Inc.
>>
>>
>>
>
>
> >
>

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---