ANN: core.logic 0.8.6

[David Nolen]

The main change is the introduction of a new protocol IVerifyConstraint.
Implementations of it will be called before a constraint is added to the
constraint store - this is the hook needed for detecting incompatible
constraints.

More information here: http://github.com/clojure/core.logic

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

Re: ANN: core.logic 0.8.6

[David Nolen]

My honest suggestion is to get a copies of The Reasoned Schemer, The Art of
Prolog, and Concepts Techniques & Models of Computer Programming. They
cover the terrain far better than any documentation or tutorial can.

David


On Sat, Feb 8, 2014 at 4:26 PM, Plínio Balduino  wrote:

> David, first of all, congratulations for core.logic.
>
> I would like to start with logic programming, but the texts I found aren't
> for starters like me, even though I have a good experience as software
> developer and functional programming is not a mistery anymore. What would
> you recommend for someone who wants to try and understand core.logic?
>
> Thank you
>
> Plinio Balduino
>
>
> On Saturday, February 8, 2014, David Nolen  wrote:
>
>> The main change is the introduction of a new protocol IVerifyConstraint.
>> Implementations of it will be called before a constraint is added to the
>> constraint store - this is the hook needed for detecting incompatible
>> constraints.
>>
>> More information here: http://github.com/clojure/core.logic
>>
>> 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/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.

ANN: core.logic 0.8.7

[David Nolen]

This release just fixes a bug around aliased logic vars and the new
constraint verification functionality.

More information here: http://github.com/clojure/core.logic

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

ANN: om-sync

[David Nolen]

I've been banging the drum about Om & modularity for a while now and I've
come up with the very beginning of a simple reusable component that I think
demonstrates the power of Om's emphasis on modularity and application wide
state management:

http://github.com/swannodette/om-sync

The whole point of Om is to create a universe of shareable components. I
hope this gets people thinking about the possibilities.

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

ANN: Om 0.4.0

[David Nolen]

Happy to announce a new release of Om. There are some breaking changes
mostly to make the API more uniform - om.core/root was needlessly different
from om.core/build.

The biggest and most exciting change is the inclusion of the :tx-listen
option to om.core/root. This will setup a callback which will be invoked
whenever an app state transaction occurs. This function will receive a map
tx-data which will include the :path that changed, :old-value and
:new-value on that path, :new-state and :old-state which is the entire
application (useful for rollbacks), and :tag if one was provided by the
transact! / update! call.

It's extremely powerful to make a subscribeable channel out of this and
share it over your entire application via om.core/root's :shared option.
This is exactly what the reusable om-sync component does http.://
github.com/swannodette/om-sync.

For a full list of changes, bug fixes, and enhancements:

http://github.com/swannodette/om/blob/master/CHANGES.md

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

Re: ANN: Om 0.4.0

[David Nolen]

Om 0.4.0 requires ClojureScript 0.0-2156, also looks like you need to run a
`lein cljsbuild clean`.

David


On Fri, Feb 14, 2014 at 8:00 AM, Tatu Tarvainen wrote:

>
> Btw, I seem to get the following compiler errors after upgrading om from
> 0.3.6 to 0.4.0
>
> (clojurescript version is 0.0-2138)
>
> WARNING: Use of undeclared Var om.core/specify! at line 570
> out\om\core.cljs
> WARNING: Use of undeclared Var om.core/_ at line 572 out\om\core.cljs
> WARNING: Use of undeclared Var om.core/tx-data at line 572 out\om\core.cljs
> WARNING: Use of undeclared Var om.core/root-cursor at line 572
> out\om\core.cljs
> WARNING: Use of undeclared Var om.core/tx-data at line 574 out\om\core.cljs
> WARNING: Use of undeclared Var om.core/root-cursor at line 574
> out\om\core.cljs
> WARNING: Wrong number of args (2) passed to om.core/-notify at line 572
> out\om\core.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: Using core.logic to implement data strutures (CTMCP)

[David Nolen]

You will need to implement unification for your record type. I recommend
just using simpler data structures unless how to do this is apparent to you
- it's not particularly difficult but you need to go to the source if you
want to understand how to make it work.

David


On Fri, Feb 14, 2014 at 1:14 PM, Juan Manuel Gimeno Illa  wrote:

> As a Xmas present I gave myself a copy of "Concepts, Teechniques and
> Models of Computer Programming" and I'm enjoying myself reading it. The
> book uses Oz/Mozart but I'm trying to translate some of the code in clojure.
>
> The first computation model is declarative and variables behave much as
> LVars in core.logic. The first data structure it implements using these
> variables is a queue.
>
> Can anyoone give me some hints about how to translate the code using
> core.logic? My idea is to translate the functions to relations and evaluate
> them inside a run, but all my attempts have failed.
>
> For instance, the function to create a queue is (page 148):
>
> fun {NewQueue} X in q(0 X X) end
>
> where q is a recodr with slots N (number of elements in queue), the
> elements in the list are the difference list S#E.
>
> my translation is
>
> (defn newqueueo [q]
>(fresh [x]
>   [0 x x]))
>
> I tried to use records, but I've had some problems (maybe they can't be
> used) and I'm using vectors now.
>
> Anyone has any hint?
>
> Thanks,
>
> Juan Manuel
>
> --
> 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: [ANN] Clojure 1.6.0-beta1

[David Nolen]

exists? doesn't seem right to me. Also we do use `exists?` currently in
ClojureScript since feature detection is so common in client side code and
the name seems more appropriate to me in that context. That could of course
change but we would need to coordinate.

David


On Fri, Feb 14, 2014 at 3:27 PM, Dom Kiva-Meyer  wrote:

> Great changes! I have a question about #5.
>
>
>> 5) New "some" operations
>> Many conditional functions rely on logical truth (where "falsey"
>> values are nil or false). Sometimes it is useful to have functions
>> that rely on "not nilness" instead. These functions have been added to
>> support these cases [CLJ-1343]:
>> * some? - same as (not (nil? x))
>> * if-some - like if-let, but checks (not (nil? test)) instead of test
>> * when-some - like when-let, but checks (not (nil? test)) instead of test
>
>
> It seems inconsistent to have "some" mean two very different things within
> the same namespace, especially since the prior uses of "some" (`some`,
> `some-fn`, etc.) are more in keeping with its primary definition of having
> to do with amount (and operate on seqs or variadic arguments) while the new
> functions have to do with existence (and operate on any single value). Why
> not call these new functions `not-nil?`, `if-not-nil`, and `when-not-nil`?
> Or, if "not-nil" is too unwieldy then what about "exists" (`exists?`,
> `if-exists`, `when-exists`)?
>
> Are these names up for discussion?
>
> Cheers,
> Dom
>
>
> On Fri, Feb 14, 2014 at 11:04 AM, Alex Miller  wrote:
>
>> Clojure 1.6.0-beta1 is now available.
>>
>> Try it via
>> - Download:
>> http://central.maven.org/maven2/org/clojure/clojure/1.6.0-beta1
>> - Leiningen: [org.clojure/clojure "1.6.0-beta1"]
>>
>> Highlights below or see the full change log here:
>> https://github.com/clojure/clojure/blob/master/changes.md
>>
>> We expect Clojure 1.6.0-beta1 to be close to a release candidate; no
>> other big changes are planned. Please give us your feedback and final
>> issues if you find them so we can do the final release!
>>
>> Clojure 1.6.0-beta1 has the following changes from 1.5.1:
>>
>> 1) Clojure now builds with Java SE 1.6 and emits bytecode requiring Java
>> SE 1.6 instead of Java SE 1.5. [CLJ-1268]
>>
>> 2) The following features are no longer marked "Alpha" in Clojure:
>>
>> * Watches - add-watch, remove-watch
>> * Transients - transient, persistent!, conj!, assoc!, dissoc!, pop!, disj!
>> * Exception data - ex-info, ex-data
>> * Promises - promise, deliver
>> * Records - defrecord
>> * Types - deftype
>> * Pretty-print tables - print-table
>>
>> 3) The clojure.java.api package provides a minimal interface to bootstrap
>> Clojure access from other JVM languages. Example:
>>
>> IFn map = Clojure.var("clojure.core", "map");
>> IFn inc = Clojure.var("clojure.core", "inc");
>> map.invoke(inc, Clojure.read("[1 2 3]"));
>>
>> 4) Map destructuring extended to support namespaced keys. [CLJ-1318]
>>
>> In the past, map destructuring with :keys and :syms would not work
>> with maps containing namespaced keys or symbols. The :keys and :syms
>> forms have been updated to allow them to match namespaced keys and
>> bind to a local variable based on the name.
>>
>> Examples:
>>
>> (let [m {:x/a 1, :y/b 2}
>>   {:keys [x/a y/b]} m]
>>   (+ a b))
>>
>> (let [m {'x/a 1, 'y/b 2}
>>   {:syms [x/a y/b]} m]
>>   (+ a b))
>>
>> Additionally, the :keys form can now take keywords instead of symbols.
>>  This provides support specifically for auto-resolved keywords:
>>
>> (let [m {::x 1}
>>   {:keys [::x]} m]
>>   x)
>>
>> 5) New "some" operations
>>
>> Many conditional functions rely on logical truth (where "falsey"
>> values are nil or false). Sometimes it is useful to have functions
>> that rely on "not nilness" instead. These functions have been added to
>> support these cases [CLJ-1343]:
>>
>> * some? - same as (not (nil? x))
>> * if-some - like if-let, but checks (not (nil? test)) instead of test
>> * when-some - like when-let, but checks (not (nil? test)) instead of test
>>
>> 6) Hashing overhaul
>>
>> The Clojure hash algorithms have changed for many primitives and
>> collections.
>> Read the changelog and http://clojure.org/data_structures#hash for more
>> detail
>> and if you are building external collections.
>>
>> In general, this change creates better hash codes (better bit dispersion,
>> fewer
>> collisions) to improve performance of hashed collections (maps and sets).
>> *NOTE:* One side effect may be that code currently relying on the
>> arbitrary order
>> of hashed elements in a collection (tests for example) may need to be
>> fixed.
>>
>> 7) Other new things
>>
>> * unsigned-bit-shift-right - Java's >>>
>> * clojure.test/test-vars - run a set of tests with fixtures
>>
>> 8) Printing enhancements
>>
>> * [CLJ-908](http://dev.clojure.org/jira/browse/CLJ-908)
>>   Print metadata for functions when *print-meta* is true and remove
>> errant space at beginning.
>> * [CL

Re: [ANN] Clojure 1.6.0-beta1

[David Nolen]

Also I think the ship on overloading some already sailed with some-> and
some->>

David


On Fri, Feb 14, 2014 at 3:27 PM, Dom Kiva-Meyer  wrote:

> Great changes! I have a question about #5.
>
>
>> 5) New "some" operations
>> Many conditional functions rely on logical truth (where "falsey"
>> values are nil or false). Sometimes it is useful to have functions
>> that rely on "not nilness" instead. These functions have been added to
>> support these cases [CLJ-1343]:
>> * some? - same as (not (nil? x))
>> * if-some - like if-let, but checks (not (nil? test)) instead of test
>> * when-some - like when-let, but checks (not (nil? test)) instead of test
>
>
> It seems inconsistent to have "some" mean two very different things within
> the same namespace, especially since the prior uses of "some" (`some`,
> `some-fn`, etc.) are more in keeping with its primary definition of having
> to do with amount (and operate on seqs or variadic arguments) while the new
> functions have to do with existence (and operate on any single value). Why
> not call these new functions `not-nil?`, `if-not-nil`, and `when-not-nil`?
> Or, if "not-nil" is too unwieldy then what about "exists" (`exists?`,
> `if-exists`, `when-exists`)?
>
> Are these names up for discussion?
>
> Cheers,
> Dom
>
>
> On Fri, Feb 14, 2014 at 11:04 AM, Alex Miller  wrote:
>
>> Clojure 1.6.0-beta1 is now available.
>>
>> Try it via
>> - Download:
>> http://central.maven.org/maven2/org/clojure/clojure/1.6.0-beta1
>> - Leiningen: [org.clojure/clojure "1.6.0-beta1"]
>>
>> Highlights below or see the full change log here:
>> https://github.com/clojure/clojure/blob/master/changes.md
>>
>> We expect Clojure 1.6.0-beta1 to be close to a release candidate; no
>> other big changes are planned. Please give us your feedback and final
>> issues if you find them so we can do the final release!
>>
>> Clojure 1.6.0-beta1 has the following changes from 1.5.1:
>>
>> 1) Clojure now builds with Java SE 1.6 and emits bytecode requiring Java
>> SE 1.6 instead of Java SE 1.5. [CLJ-1268]
>>
>> 2) The following features are no longer marked "Alpha" in Clojure:
>>
>> * Watches - add-watch, remove-watch
>> * Transients - transient, persistent!, conj!, assoc!, dissoc!, pop!, disj!
>> * Exception data - ex-info, ex-data
>> * Promises - promise, deliver
>> * Records - defrecord
>> * Types - deftype
>> * Pretty-print tables - print-table
>>
>> 3) The clojure.java.api package provides a minimal interface to bootstrap
>> Clojure access from other JVM languages. Example:
>>
>> IFn map = Clojure.var("clojure.core", "map");
>> IFn inc = Clojure.var("clojure.core", "inc");
>> map.invoke(inc, Clojure.read("[1 2 3]"));
>>
>> 4) Map destructuring extended to support namespaced keys. [CLJ-1318]
>>
>> In the past, map destructuring with :keys and :syms would not work
>> with maps containing namespaced keys or symbols. The :keys and :syms
>> forms have been updated to allow them to match namespaced keys and
>> bind to a local variable based on the name.
>>
>> Examples:
>>
>> (let [m {:x/a 1, :y/b 2}
>>   {:keys [x/a y/b]} m]
>>   (+ a b))
>>
>> (let [m {'x/a 1, 'y/b 2}
>>   {:syms [x/a y/b]} m]
>>   (+ a b))
>>
>> Additionally, the :keys form can now take keywords instead of symbols.
>>  This provides support specifically for auto-resolved keywords:
>>
>> (let [m {::x 1}
>>   {:keys [::x]} m]
>>   x)
>>
>> 5) New "some" operations
>>
>> Many conditional functions rely on logical truth (where "falsey"
>> values are nil or false). Sometimes it is useful to have functions
>> that rely on "not nilness" instead. These functions have been added to
>> support these cases [CLJ-1343]:
>>
>> * some? - same as (not (nil? x))
>> * if-some - like if-let, but checks (not (nil? test)) instead of test
>> * when-some - like when-let, but checks (not (nil? test)) instead of test
>>
>> 6) Hashing overhaul
>>
>> The Clojure hash algorithms have changed for many primitives and
>> collections.
>> Read the changelog and http://clojure.org/data_structures#hash for more
>> detail
>> and if you are building external collections.
>>
>> In general, this change creates better hash codes (better bit dispersion,
>> fewer
>> collisions) to improve performance of hashed collections (maps and sets).
>> *NOTE:* One side effect may be that code currently relying on the
>> arbitrary order
>> of hashed elements in a collection (tests for example) may need to be
>> fixed.
>>
>> 7) Other new things
>>
>> * unsigned-bit-shift-right - Java's >>>
>> * clojure.test/test-vars - run a set of tests with fixtures
>>
>> 8) Printing enhancements
>>
>> * [CLJ-908](http://dev.clojure.org/jira/browse/CLJ-908)
>>   Print metadata for functions when *print-meta* is true and remove
>> errant space at beginning.
>> * [CLJ-937](http://dev.clojure.org/jira/browse/CLJ-937)
>>   pprint cl-format now supports E, F, and G formats for ratios.
>>
>> 9) Error messages
>>
>> * [CLJ-1248](http://dev.clojure.or

Re: [ANN] Clojure 1.6.0-beta1

[David Nolen]

exists? is a pretty critical feature for application writers and I asked
several users about it before committing to a name. Unless Clojure decides
to adopt it, little incentive to cause unnecessary breakage.

David


On Fri, Feb 14, 2014 at 10:28 PM, Joel Holdbrooks wrote:

> Slightly off topic, but I wish I would have been apart of that discussion
> because there's another example of function that, at face value, doesn't
> clearly express it's nature. In tandem with my comment below, there should
> really be a little more consideration for the names of these functions. I
> would agree that short function names should be favored but not at the
> expense of communication.
>
> There's probably nothing that can be done for this now, but while feature
> detection is common *in a program*, it is uncommon *throughout a program*.
> I would thus argue, that a name with a higher degree of precision, and
> perhaps more characters, would have been a better choice.
>
> On Friday, February 14, 2014 2:36:51 PM UTC-8, David Nolen wrote:
>
>> exists? doesn't seem right to me. Also we do use `exists?` currently in
>> ClojureScript since feature detection is so common in client side code and
>> the name seems more appropriate to me in that context. That could of course
>> change but we would need to coordinate.
>>
>> David
>>
>>
>> On Fri, Feb 14, 2014 at 3:27 PM, Dom Kiva-Meyer  wrote:
>>
>>> Great changes! I have a question about #5.
>>>
>>>
>>>> 5) New "some" operations
>>>> Many conditional functions rely on logical truth (where "falsey"
>>>> values are nil or false). Sometimes it is useful to have functions
>>>> that rely on "not nilness" instead. These functions have been added to
>>>> support these cases [CLJ-1343]:
>>>> * some? - same as (not (nil? x))
>>>> * if-some - like if-let, but checks (not (nil? test)) instead of test
>>>> * when-some - like when-let, but checks (not (nil? test)) instead of
>>>> test
>>>
>>>
>>> It seems inconsistent to have "some" mean two very different things
>>> within the same namespace, especially since the prior uses of "some"
>>> (`some`, `some-fn`, etc.) are more in keeping with its primary definition
>>> of having to do with amount (and operate on seqs or variadic arguments)
>>> while the new functions have to do with existence (and operate on any
>>> single value). Why not call these new functions `not-nil?`, `if-not-nil`,
>>> and `when-not-nil`? Or, if "not-nil" is too unwieldy then what about
>>> "exists" (`exists?`, `if-exists`, `when-exists`)?
>>>
>>> Are these names up for discussion?
>>>
>>> Cheers,
>>> Dom
>>>
>>>
>>> On Fri, Feb 14, 2014 at 11:04 AM, Alex Miller wrote:
>>>
>>>> Clojure 1.6.0-beta1 is now available.
>>>>
>>>> Try it via
>>>> - Download: http://central.maven.org/maven2/org/clojure/
>>>> clojure/1.6.0-beta1
>>>> - Leiningen: [org.clojure/clojure "1.6.0-beta1"]
>>>>
>>>> Highlights below or see the full change log here:
>>>> https://github.com/clojure/clojure/blob/master/changes.md
>>>>
>>>> We expect Clojure 1.6.0-beta1 to be close to a release candidate; no
>>>> other big changes are planned. Please give us your feedback and final
>>>> issues if you find them so we can do the final release!
>>>>
>>>> Clojure 1.6.0-beta1 has the following changes from 1.5.1:
>>>>
>>>> 1) Clojure now builds with Java SE 1.6 and emits bytecode requiring Java
>>>> SE 1.6 instead of Java SE 1.5. [CLJ-1268]
>>>>
>>>> 2) The following features are no longer marked "Alpha" in Clojure:
>>>>
>>>> * Watches - add-watch, remove-watch
>>>> * Transients - transient, persistent!, conj!, assoc!, dissoc!, pop!,
>>>> disj!
>>>> * Exception data - ex-info, ex-data
>>>> * Promises - promise, deliver
>>>> * Records - defrecord
>>>> * Types - deftype
>>>> * Pretty-print tables - print-table
>>>>
>>>> 3) The clojure.java.api package provides a minimal interface to
>>>> bootstrap
>>>> Clojure access from other JVM languages. Example:
>>>>
>>>> IFn map = Clojure.var("clojure.core", "map");
>>>> IFn inc = Clojure.var("clojure.co

Re: [ANN] Clojure 1.6.0-beta1

[David Nolen]

Likely discussed in #clojure IRC and I checked with some Clojure/core folks
for feedback.

David


On Fri, Feb 14, 2014 at 10:54 PM, Joel Holdbrooks wrote:

> Right. I won't disagree with the function being critical or with avoiding
> breakage. I'm just mostly whining here cause I missed the boat. :-)
>
> Did that discussion take place here or in Jira? I'd definitely like to be
> able to chime in with thoughts/suggestions in the future WRT this topic.
>
> On Friday, February 14, 2014 7:46:23 PM UTC-8, David Nolen wrote:
>
>> exists? is a pretty critical feature for application writers and I asked
>> several users about it before committing to a name. Unless Clojure decides
>> to adopt it, little incentive to cause unnecessary breakage.
>>
>> David
>>
>>
>> On Fri, Feb 14, 2014 at 10:28 PM, Joel Holdbrooks wrote:
>>
>>> Slightly off topic, but I wish I would have been apart of that
>>> discussion because there's another example of function that, at face value,
>>> doesn't clearly express it's nature. In tandem with my comment below, there
>>> should really be a little more consideration for the names of these
>>> functions. I would agree that short function names should be favored but
>>> not at the expense of communication.
>>>
>>> There's probably nothing that can be done for this now, but while
>>> feature detection is common *in a program*, it is uncommon *throughout
>>> a program*. I would thus argue, that a name with a higher degree of
>>> precision, and perhaps more characters, would have been a better choice.
>>>
>>> On Friday, February 14, 2014 2:36:51 PM UTC-8, David Nolen wrote:
>>>
>>>> exists? doesn't seem right to me. Also we do use `exists?` currently in
>>>> ClojureScript since feature detection is so common in client side code and
>>>> the name seems more appropriate to me in that context. That could of course
>>>> change but we would need to coordinate.
>>>>
>>>> David
>>>>
>>>>
>>>> On Fri, Feb 14, 2014 at 3:27 PM, Dom Kiva-Meyer wrote:
>>>>
>>>>> Great changes! I have a question about #5.
>>>>>
>>>>>
>>>>>> 5) New "some" operations
>>>>>> Many conditional functions rely on logical truth (where "falsey"
>>>>>> values are nil or false). Sometimes it is useful to have functions
>>>>>> that rely on "not nilness" instead. These functions have been added to
>>>>>> support these cases [CLJ-1343]:
>>>>>> * some? - same as (not (nil? x))
>>>>>> * if-some - like if-let, but checks (not (nil? test)) instead of test
>>>>>> * when-some - like when-let, but checks (not (nil? test)) instead of
>>>>>> test
>>>>>
>>>>>
>>>>> It seems inconsistent to have "some" mean two very different things
>>>>> within the same namespace, especially since the prior uses of "some"
>>>>> (`some`, `some-fn`, etc.) are more in keeping with its primary definition
>>>>> of having to do with amount (and operate on seqs or variadic arguments)
>>>>> while the new functions have to do with existence (and operate on any
>>>>> single value). Why not call these new functions `not-nil?`, `if-not-nil`,
>>>>> and `when-not-nil`? Or, if "not-nil" is too unwieldy then what about
>>>>> "exists" (`exists?`, `if-exists`, `when-exists`)?
>>>>>
>>>>> Are these names up for discussion?
>>>>>
>>>>> Cheers,
>>>>> Dom
>>>>>
>>>>>
>>>>> On Fri, Feb 14, 2014 at 11:04 AM, Alex Miller wrote:
>>>>>
>>>>>> Clojure 1.6.0-beta1 is now available.
>>>>>>
>>>>>> Try it via
>>>>>> - Download: http://central.maven.org/maven2/org/clojure/clojur
>>>>>> e/1.6.0-beta1
>>>>>> - Leiningen: [org.clojure/clojure "1.6.0-beta1"]
>>>>>>
>>>>>> Highlights below or see the full change log here:
>>>>>> https://github.com/clojure/clojure/blob/master/changes.md
>>>>>>
>>>>>> We expect Clojure 1.6.0-beta1 to be close to a release candidate; no
>>>>>> other big changes are planned. Please give us your feedback and final
>>>>>>

Re: ANN: Om 0.4.0

[David Nolen]

You can build individual examples, "tests" can't be built - it's just a
dummy thing that I use when I need to quickly verify something.

David


On Sat, Feb 15, 2014 at 3:00 PM, boz  wrote:

> Thanks David!
>
> I get this on a fresh clone (commit
> 7327bcdc17a665d5fde66376bfef9aa2b21c675a)
>Compiling "examples/tests/main.js" failed.
>java.io.FileNotFoundException: examples/tests/src (No such file or
> directory)
>
> $ mkdir examples/tests/src
> and build again works fine.
>
> --- long version ---
> bozs-mbp:~/dev/clojure/temp/om (master|169m) $ lein cljsbuild once
> Compiling ClojureScript.
> Compiling "script/tests.simple.js" from ["src" "test"]...
> Successfully compiled "script/tests.simple.js" in 15.829 seconds.
> Compiling "examples/hello/main.js" from ["src" "examples/hello/src"]...
> Successfully compiled "examples/hello/main.js" in 4.091 seconds.
> Compiling "examples/mouse/main.js" from ["src" "examples/mouse/src"]...
> WARNING: No such namespace: goog.events.EventType at line 23
> examples/mouse/src/core.cljs
> Successfully compiled "examples/mouse/main.js" in 6.781 seconds.
> Compiling "examples/multiroot/main.js" from ["src"
> "examples/multiroot/src"]...
> Successfully compiled "examples/multiroot/main.js" in 3.775 seconds.
> Compiling "examples/counters/main.js" from ["src"
> "examples/counters/src"]...
> Successfully compiled "examples/counters/main.js" in 5.824 seconds.
> Compiling "examples/animation/main.js" from ["src"
> "examples/animation/src"]...
> Successfully compiled "examples/animation/main.js" in 3.538 seconds.
> Compiling "examples/shared/main.js" from ["src" "examples/shared/src"]...
> Successfully compiled "examples/shared/main.js" in 3.533 seconds.
> Compiling "examples/typeahead/main.js" from ["src"
> "examples/typeahead/src"]...
> WARNING: Extending an existing JavaScript type - use a different symbol
> name instead of js/String e.g string at line 29
> examples/typeahead/src/core.cljs
> WARNING: Extending an existing JavaScript type - use a different symbol
> name instead of js/Number e.g number at line 39
> examples/typeahead/src/core.cljs
> Successfully compiled "examples/typeahead/main.js" in 3.577 seconds.
> Compiling "examples/sortable/main.js" from ["src"
> "examples/sortable/src"]...
> Successfully compiled "examples/sortable/main.js" in 5.916 seconds.
> Compiling "examples/graft/main.js" from ["src" "examples/graft/src"]...
> Successfully compiled "examples/graft/main.js" in 3.459 seconds.
> Compiling "examples/tests/main.js" from ["src" "examples/tests/src"]...
> Compiling "examples/tests/main.js" failed.
> java.io.FileNotFoundException: examples/tests/src (No such file or
> directory)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.(FileInputStream.java:138)
> at clojure.java.io$fn__8638.invoke(io.clj:233)
> ...
> Subprocess failed
> bozs-mbp:~/dev/clojure/temp/om (master|170m) $ mkdir examples/tests/src
> bozs-mbp:~/dev/clojure/temp/om (master|171m) $ lein cljsbuild once
> Compiling ClojureScript.
> Compiling "examples/tests/main.js" from ["src" "examples/tests/src"]...
> Successfully compiled "examples/tests/main.js" in 7.81 seconds.
>
> On Thursday, February 13, 2014 10:02:50 PM UTC-8, David Nolen wrote:
>>
>> Happy to announce a new release of Om. There are some breaking changes
>> mostly to make the API more uniform - om.core/root was needlessly different
>> from om.core/build.
>>
>> The biggest and most exciting change is the inclusion of the :tx-listen
>> option to om.core/root. This will setup a callback which will be invoked
>> whenever an app state transaction occurs. This function will receive a map
>> tx-data which will include the :path that changed, :old-value and
>> :new-value on that path, :new-state and :old-state which is the entire
>> application (useful for rollbacks), and :tag if one was provided by the
>> transact! / update! call.
>>
>> It's extremely powerful to make a subscribeable channel out of this and
>> share it over your entire application via om.core/root's :shared option.
>> This is exactly what the reusable om-sync component does http.://
>> github.com/swannodette/om-sync.
>>
>> For a f

Re: clojurescript source maps: chrome's expected behavior, firefox support

[David Nolen]

On Mon, Feb 17, 2014 at 3:43 AM, Ransom Williams wrote:

> First of all thanks to everyone working on clojure for making web
> development suck less.  I recently sandboxed a clojure server application,
> and the tooling, documentation, and availability of libraries are all
> awesome.
>
> Anyway, I'm starting in with a clojurescript client now and want to
> confirm one detail about The Essence of 
> Clojurescriptblog
>  post:  Chrome (32)'s console indeed links the log message to a line in
> clojurescript, but the line number is in the enable-console-print! function
> in cljs/core rather than the call to println in hello_world/core.  Is this
> the expected behavior?  I guess I ought to read up on the details of source
> maps.
>

Nothing to do with source maps, behavior of console.log which we can do
nothing about. So yes, expected.

And finally, what about firefox?  The firefox (27) developer tools have
> source map support, and the debugger pulls up hello_word/core, but unlike
> chrome, it doesn't hit breakpoints, and the log message links to a
> javascript file rather than a clojurescript file.  Any word from mozillians
> on if/when-type questions?
>

No idea, but I'm sure many other compile to JS languages are bugging them
about it :)

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: weird bug with cljs.core.async + macros

[David Nolen]

Due to asm.js some JS engines are starting to compile switch statements
where the cases are integers into jump tables. Compiler enhancement that
compiles optimizable case expressions to JS switch statements would be a
welcome enhancement - http://dev.clojure.org/jira/browse/CLJS-713.

David


On Tue, Feb 18, 2014 at 4:35 PM, t x  wrote:

> Looking at
> https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1144-L1147
> , you win. :-)
>
> On Tue, Feb 18, 2014 at 1:33 PM, Michał Marczyk
>  wrote:
> > On 18 February 2014 22:31, Michał Marczyk 
> wrote:
> >> Actually in ClojureScript case dispatch is O(n), since it's
> >> implemented as a macro expanding to cond.
> >
> > As of release 2156:
> >
> >
> https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1119
> >
> > --
> > 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.

ANN: Om 0.5.0-rc1

[David Nolen]

In order to stay in sync with React 0.9.0-rc1 I've cut Om 0.5.0-rc1. There
are a couple of small breaking changes due to React but otherwise the
differences between 0.4.2 and 0.5.0-rc1 are minor. One big enhancement is
that you can now render to a string with om.dom/render-to-str.

Another big enhancement that I had absolutely nothing to do with is that
React is now almost 2X faster for the initial render under Chrome 32 &
Safari 7. This means under these browser Om is nearly 10X faster than a
naive Backbone.js at rendering 200 items in the TodoMVC application.

http://github.com/swannodette/om

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

ANN: Om 0.5.0

[David Nolen]

The only change is that we now depend on the just released React 0.9.0.

Feedback welcome!

https://github.com/swannodette/om

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.

ANN: ClojureScript 0.0-2173

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

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

New release version: 0.0-2173

Leiningen dependency information:

[org.clojure/clojurescript "0.0-2173"]

Changes & Enhancements:
* IAtom marker protocol
* IReset & ISwap protocols
* ClojureScript compiler can be AOTed

Bug Fixes:
* CLJS-765: IReversible for Subvec
* CLJS-615: Warnings when library does not exist
* CLJS-767: fix (assoc [0] nil 1)
* Use catch :default in browser REPL & reflect
* Permit nodejs targets to have a preamble

-- 
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: Macro writing macro fails with CLJS

[David Nolen]

You shouldn't use js*, and in this case it can be avoided. The problem
you're encountering is a long outstanding wart that ClojureScript macros
resolve symbols in Clojure not ClojureScript. Instead of + (which is
actually clojure.core/+) you want to specify cljs.core/+:

(defmathop cljs.core/+ cljs.core/+)


On Sun, Feb 23, 2014 at 2:47 PM, Karsten Schmidt  wrote:

> After taking another look through cljs.core I managed to reformulate
> my macro using js* templates, but am still wondering why the "normal"
> (and cross-platform) solution doesn't work and also if using the js*
> way is actually safe in the future (i.e. not just a current
> implementation detail)?
>
> (defmacro defmathop
>   "Constructs macro to build inlined nested expressions with f applied
> to inner pairs and f2 to combine results."
>   [name f f2]
>   `(defmacro ~name
>  ([a# b# c#]
> (list '~'js* (str "((~{} " ~f " ~{}) " ~f2 " ~{})")
>   a# b# c#))
>  ([a# b# c# d#]
> (list '~'js* (str "((~{} " ~f " ~{}) " ~f2 " (~{} " ~f " ~{}))")
>   a# b# c# d#
>
> (defmathop madd "*" "+")
>
> Thanks for any answers!
>
> On 23 February 2014 16:28, Karsten Schmidt  wrote:
> > Btw. My cljs example above is slightly wrong due to my simplifying the
> email
> > example. I originally used this ns declaration
> >
> > (ns macromath.test
> >   (:require-macros [macromath.core :as m]))
> >
> > ...and then of course referred to (m/madd ...)
> >
> > But the issue remains regardless...
> >
> > On 23 Feb 2014 15:59, "Karsten Schmidt"  wrote:
> >>
> >> Hi, I've written a macro to build inline expanded math expressions and
> >> it's working well in Clojure, however fails with a compile exception
> >> in CLJS. I'm not sure if this is a shortcoming of the CLJS compiler or
> >> (much more likely) a mistake with my macro.
> >>
> >> (ns macromath.core)
> >>
> >> (defmacro defmathop
> >>   "Constructs a macro to build inlined nested expressions with f applied
> >>   to inner pairs and f2 to combine results."
> >>   [name f f2]
> >>   `(defmacro ~name
> >>  ([a# b# c#] `(~~f2 (~~f ~a# ~b#) ~c#))
> >>  ([a# b# c# d#] `(~~f2 (~~f ~a# ~b#) (~~f ~c# ~d#)
> >>
> >> (defmathop add + +)
> >> (defmathop sub - -)
> >> (defmathop mul * *)
> >> (defmathop div / /)
> >> (defmathop madd * +)
> >> (defmathop msub * -)
> >> (defmathop addm + *)
> >> (defmathop subm - *)
> >>
> >> lein repl
> >>
> >> (use 'macromath.core)
> >> (madd 2 3 4)
> >> ; 10
> >> (madd 2 3 4 5)
> >> ; 26
> >>
> >> My short CLJS test is as follows:
> >>
> >> (ns macromath.test
> >>   (:use-macros [macromath.core]))
> >>
> >> (defn ^:export main
> >>   []
> >>   (.log js/console (madd 2 3 4 5)))
> >>
> >> lein cljsbuild fails with this exception:
> >> Caused by: java.lang.IllegalArgumentException: No method in multimethod
> >> 'emit-constant' for dispatch value: class clojure.core$_PLUS_
> >>
> >> How can I rewrite the macro so it properly works with the CLJS compiler?
> >> Thank you!
>
>
>
> --
> Karsten Schmidt
> http://postspectacular.com | http://toxiclibs.org | http://toxi.co.uk
>
> --
> 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: Macro writing macro fails with CLJS

[David Nolen]

I think your unquoting needs tweaking?

(defmacro defmathop
  "Constructs a macro to build inlined nested expressions with f applied
  to inner pairs and f2 to combine results."
  [name f f2]
  `(defmacro ~name
 ([a# b# c#] `(~'~f2 (~'~f ~a# ~b#) ~c#))
 ([a# b# c# d#] `(~'~f2 (~'~f ~a# ~b#) (~'~f ~c# ~d#)

On Sunday, February 23, 2014, Karsten Schmidt  wrote:

> Thanks, David! I tried that already and it didn't work:
>
> clojure.lang.Compiler$CompilerException:
> java.lang.ClassNotFoundException: cljs.core,
> compiling:(macromath/macros.clj:58:1)
>
> I also tried to require cljs.core in that macro's namespace, but then
> it complains this way:
>
> clojure.lang.Compiler$CompilerException: java.lang.RuntimeException:
> Can't take value of a macro: #'cljs.core/+,
> compiling:(macromath/macros.clj:59:1)
>
> Hmmm
>
> On 23 February 2014 19:52, David Nolen  wrote:
> > You shouldn't use js*, and in this case it can be avoided. The problem
> > you're encountering is a long outstanding wart that ClojureScript macros
> > resolve symbols in Clojure not ClojureScript. Instead of + (which is
> > actually clojure.core/+) you want to specify cljs.core/+:
> >
> > (defmathop cljs.core/+ cljs.core/+)
> >
> >
> > On Sun, Feb 23, 2014 at 2:47 PM, Karsten Schmidt 
> wrote:
> >>
> >> After taking another look through cljs.core I managed to reformulate
> >> my macro using js* templates, but am still wondering why the "normal"
> >> (and cross-platform) solution doesn't work and also if using the js*
> >> way is actually safe in the future (i.e. not just a current
> >> implementation detail)?
> >>
> >> (defmacro defmathop
> >>   "Constructs macro to build inlined nested expressions with f applied
> >> to inner pairs and f2 to combine results."
> >>   [name f f2]
> >>   `(defmacro ~name
> >>  ([a# b# c#]
> >> (list '~'js* (str "((~{} " ~f " ~{}) " ~f2 " ~{})")
> >>   a# b# c#))
> >>  ([a# b# c# d#]
> >> (list '~'js* (str "((~{} " ~f " ~{}) " ~f2 " (~{} " ~f " ~{}))")
> >>   a# b# c# d#
> >>
> >> (defmathop madd "*" "+")
> >>
> >> Thanks for any answers!
> >>
> >> On 23 February 2014 16:28, Karsten Schmidt  wrote:
> >> > Btw. My cljs example above is slightly wrong due to my simplifying the
> >> > email
> >> > example. I originally used this ns declaration
> >> >
> >> > (ns macromath.test
> >> >   (:require-macros [macromath.core :as m]))
> >> >
> >> > ...and then of course referred to (m/madd ...)
> >> >
> >> > But the issue remains regardless...
> >> >
> >> > On 23 Feb 2014 15:59, "Karsten Schmidt"  wrote:
> >> >>
> >> >> Hi, I've written a macro to build inline expanded math expressions
> and
> >> >> it's working well in Clojure, however fails with a compile exception
> >> >> in CLJS. I'm not sure if this is a shortcoming of the CLJS compiler
> or
> >> >> (much more likely) a mistake with my macro.
> >> >>
> >> >> (ns macromath.core)
> >> >>
> >> >> (defmacro defmathop
> >> >>   "Constructs a macro to build inlined nested expressions with f
> >> >> applied
> >> >>   to inner pairs and f2 to combine results."
> >> >>   [name f f2]
> >> >>   `(defmacro ~name
> >> >>  ([a# b# c#] `(~~f2 (~~f ~a# ~b#) ~c#))
> >> >>  ([a# b# c# d#] `(~~f2 (~~f ~a# ~b#) (~~f ~c# ~d#)
> >> >>
> >> >> (defmathop add + +)
> >> >> (defmathop sub - -)
> >> >> (defmathop mul * *)
> >> >> (defmathop div / /)
> >> >> (defmathop madd * +)
> >> >> (defmathop msub * -)
> >> >> (defmathop addm + *)
> >> >> (defmathop subm - *)
> >> >>
> >> >> lein repl
> >> >>
> >> >> (use 'macromath.core)
> >> >> (madd 2 3 4)
> >> >> ; 10
> >> >> (madd 2 3 4 5)
> >> >> ; 26
> >> >>
> >> >> My short CLJS test is as follows:
> >> >>
> >> >> (ns macromath.test
> >> >>   (:use-macros [macromath.core]))
> >> >>
> >> >> (defn ^:export main
> >> >>   []
> >> >>   (.log js/console (madd 2 3 4 5)))
> >> >>
> >> >> lein cljsbuild fails with this exception:
> >> >> Caused by: java.lang.IllegalArgumentException: No method in
> multimetho

-- 
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: Om: trouble with goog reference

[David Nolen]

The issue is that advanced compilation produces a single artifact.

David


On Sun, Feb 23, 2014 at 8:22 PM, boz  wrote:

> I'm having trouble with the Om basic tutorial Higher Order 
> Components
>  using
> emacs and a slightly modified version of
> https://github.com/magomimmo/om-start-template that points to Om 0.5.0
> and React 0.9.0.
> My version is https://github.com/christoferjennings/om-start-template
>
> The template doesn't have the goog/base.js out of the box. When I add it,
> I get a "Uncaught ReferenceError: goog is not defined" (Chrome Version
> 33.0.1750.117)
>
> Here's the final html (basically the same as in the tutorial.
> 
> 
> 
> http://fb.me/react-0.9.0.js";>
> 
> 
>  type="text/javascript">goog.require("my-stuff.core");
> 
> 
>
> There is no "out/goog/base.js", so I'm not too surprised goog is
> undefined. I'm stumped, though, because I don't know if the goog stuff
> that ends up in the .repl folder should be enough, or if I have to do
> something special to get the goog stuff to be in the out folder. I've tried
> "lein cljsbuild once" without luck.
>
> Any ideas on what I'm doing wrong?
>
> 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.

Enhanced Node.js support in ClojureScript master

[David Nolen]

At long last the ClojureScript compiler can now target Node.js under
optimizations :whitespace or :none as of this commit:
http://github.com/clojure/clojurescript/commit/0c7b31ada01237de33cef77b817ccef3f2b3576d

Some basic notes here:
http://github.com/clojure/clojurescript/wiki/Quick-Start#wiki-notes-on-optimization-settings

This change coupled with Node.js source mapping tools (
https://github.com/evanw/node-source-map-support) can hopefully eventually
provide a development experience for Node.js comparable to the one we
currently provide for browsers.

Please give it a try!

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: Macro writing macro fails with CLJS

[David Nolen]

If I recall you are allowed to splice in references to Java objects so this
works out in Clojure.

On Sunday, February 23, 2014, Karsten Schmidt  wrote:

> Oh man, I really do have to spend some more quality time with
> macroexpand-1 to fully grok those "~'~" forms, and - thank you - that
> change does work indeed! But then why does my original version work in
> Clojure? A change in quoting usually only causes havok/failure, but
> here it doesn't seem to...
>
> Thanks again! K.
>
>
> On 23 February 2014 22:15, David Nolen  wrote:
> > I think your unquoting needs tweaking?
> >
> > (defmacro defmathop
> >   "Constructs a macro to build inlined nested expressions with f applied
> >   to inner pairs and f2 to combine results."
> >   [name f f2]
> >   `(defmacro ~name
> >  ([a# b# c#] `(~'~f2 (~'~f ~a# ~b#) ~c#))
> >  ([a# b# c# d#] `(~'~f2 (~'~f ~a# ~b#) (~'~f ~c# ~d#)
> >
> > On Sunday, February 23, 2014, Karsten Schmidt  wrote:
> >>
> >> Thanks, David! I tried that already and it didn't work:
> >>
> >> clojure.lang.Compiler$CompilerException:
> >> java.lang.ClassNotFoundException: cljs.core,
> >> compiling:(macromath/macros.clj:58:1)
> >>
> >> I also tried to require cljs.core in that macro's namespace, but then
> >> it complains this way:
> >>
> >> clojure.lang.Compiler$CompilerException: java.lang.RuntimeException:
> >> Can't take value of a macro: #'cljs.core/+,
> >> compiling:(macromath/macros.clj:59:1)
> >>
> >> Hmmm
> >>
> >> On 23 February 2014 19:52, David Nolen  wrote:
> >> > You shouldn't use js*, and in this case it can be avoided. The problem
> >> > you're encountering is a long outstanding wart that ClojureScript
> macros
> >> > resolve symbols in Clojure not ClojureScript. Instead of + (which is
> >> > actually clojure.core/+) you want to specify cljs.core/+:
> >> >
> >> > (defmathop cljs.core/+ cljs.core/+)
> >> >
> >> >
> >> > On Sun, Feb 23, 2014 at 2:47 PM, Karsten Schmidt 
> >> > wrote:
> >> >>
> >> >> After taking another look through cljs.core I managed to reformulate
> >> >> my macro using js* templates, but am still wondering why the "normal"
> >> >> (and cross-platform) solution doesn't work and also if using the js*
> >> >> way is actually safe in the future (i.e. not just a current
> >> >> implementation detail)?
> >> >>
> >> >> (defmacro defmathop
> >> >>   "Constructs macro to build inlined nested expressions with f
> applied
> >> >> to inner pairs and f2 to combine results."
> >> >>   [name f f2]
> >> >>   `(defmacro ~name
> >> >>  ([a# b# c#]
> >> >> (list '~'js* (str "((~{} " ~f " ~{}) " ~f2 " ~{})")
> >> >>   a# b# c#))
> >> >>  ([a# b# c# d#]
> >> >> (list '~'js* (str "((~{} " ~f " ~{}) " ~f2 " (~{} " ~f "
> >> >> ~{}))")
> >> >>   a# b# c# d#
> >> >>
> >> >> (defmathop madd "*" "+")
> >> >>
> >> >> Thanks for any answers!
> >> >>
> >> >> On 23 February 2014 16:28, Karsten Schmidt  wrote:
> >> >> > Btw. My cljs example above is slightly wrong due to my simplifying
> >> >> > the
> >> >> > email
> >> >> > example. I originally used this ns declaration
> >> >> >
> >> >> > (ns macromath.test
> >> >> >   (:require-macros [macromath.core :as m]))
> >> >> >
> >> >> > ...and then of course referred to (m/madd ...)
> >> >> >
> >> >> > But the issue remains regardless...
> >> >> >
> >> >> > On 23 Feb 2014 15:59, "Karsten Schmidt"  wrote:
> >> >> >>
> >> >> >> Hi, I've written a macro to build inline expanded math expressions
> >> >> >> and
> >> >> --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroup

Re: [GSoC]: We made it! Clojure is a Google Summer of Code 2014 menoring organisation

[David Nolen]

Awesome!


On Mon, Feb 24, 2014 at 2:06 PM, Daniel Solano Gómez wrote:

> Hello, all,
>
> I am happy to report that Clojure has been accepted as a Google Summer
> of Code 2014 mentoring organisation.  I'd like to thank everyone who
> gave us ideas for our Project Ideas [1] page, and a special thanks to
> Ambrose Bonnaire-Sargeant and Alex Miller for volunteering to help
> administer the program.
>
>
>
> What now?
> =
>
> The student application period will be from the 10th to the 21st of
> March.  Between now and then, it is time for students to start working
> on proposals, meeting with mentors, and getting feedback from the
> community.
>
> If you are interested in being a mentor on your project, feel free to
> post your project to the Project Ideas page or announce it on your
> project's mailing list.  Also, please sign up on Melange [2] and
> register to be a mentor for Clojure.
>
> Once the student application period ends, the administrators and mentors
> will rate each student's proposal and ask for slots from Google.  Google
> will give us some number of slots, and we will choose the top n proposal
> to be this year's Clojure GSoC students.
>
> I look forward to seeing what kind of great work our students will be
> able to achieve this year.
>
> Sincerely,
>
> Daniel
>
>
> [1]: http://dev.clojure.org/display/community/Project+Ideas
> [2]: http://www.google-melange.com/gsoc/homepage/google/gsoc2014
>
> --
> 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: object identity

[David Nolen]

I don't really have anything to add to this thread but I will say that Om's
use of identical? is an implementation detail that's likely to change. =
already does an identical? check, ideally Om could use not= in the future
instead of (not (identical? ...)).

David


On Tue, Feb 25, 2014 at 12:54 PM, Brian Craft  wrote:

> No, my question isn't "is there a way" to do this. I'm sure there are a
> dozen ways to do it. My question is about a specific way of doing it. In
> particular, if your solution does not involve calling (identical? ..), then
> it's not what I'm asking about.
>
> In om core there's a call to identical? under the :shouldComponentUpdate
> key, which I suspect is what David was talking about in his blog posts
> about avoiding deep compares via immutable data structures. My question is
> about whether that has implications for how you write algorithms that
> update state, and whether the semantics of update-in (or assoc, really)
> that allow it to return the same object if the update would return an
> identical object, are related to this mechanism, if these semantics are
> documented, and if they depend on the data type being assoc'd.
>
>
>
> On Monday, February 24, 2014 6:27:02 PM UTC-8, t x wrote:
>
>> Perhaps I mis-interpreted your question.
>>
>> I thought the question asked was:
>>
>>
>> GIven:
>>   * pure function "func"
>>   * some object "obj"
>>   * (def a (func obj))
>>   * (def b (func obj))
>>
>> Example:
>>   * obj = [1 2 3]
>>   * (defn func [lst] (map #(* 2 %) lst))
>>
>> Then:
>>   * is there a O(1) way to check if (= a b) ?
>>
>>   In the above, we create two _different_ lists, both of which stores
>> [2 4 6], thus they're equal, but not identical
>>
>> Proposed solution:
>>   tag the returned-value with a meta object, where the meta object
>> describes how the object was computed.
>>
>>   in this case, both [2 4 6] would have _identical_ meta objects,
>> since they're both from the list [1 2 3]
>>
>>
>>
>>
>>
>> On Mon, Feb 24, 2014 at 5:56 PM, Brian Craft  wrote:
>> > You're solving a similar problem, but I'm asking specifically about
>> using
>> > object identity, not equality, for tracking changes in a nested
>> structure.
>> >
>> >
>> > On Monday, February 24, 2014 1:42:03 PM UTC-8, t x wrote:
>> >>
>> >> I finally have a chance to give back. :-)
>> >>
>> >> I hacked up a newb's half-React. It does tree diffing + dom updating,
>> >> but not the virtual event handling system.
>> >>
>> >> I ran into this exact problem, and solved it as follows:
>> >>
>> >>
>> >> ## problem definition:
>> >>
>> >> render: data -> dom
>> >> tree-diff: dom * dom -> list of dom-update-actions
>> >>
>> >> we want to avoid "deep tree diffing" on tree-diff
>> >>
>> >> the key idea is as follows:
>> >>
>> >>   when render is called twice with same args,
>> >>
>> >>   * we still have to recompute every time
>> >>   * we don't have to re-compare every time
>> >>
>> >> if render is a pure function, we do somethign like:
>> >>
>> >> (defn render [data]
>> >>   (with-meta (render-pure data) {:pure data}))
>> >>
>> >> (render-pure data) gives us a dom-tree
>> >> we tag it with a meta project, telling us that it came from "data",
>> >> and that it was a pure function
>> >>
>> >>
>> >> then, doing the tree-diff stage, we do:
>> >>
>> >>
>> >> (defn tree-diff [old-dom new-dom]
>> >>   (let [mo (meta old-dom)
>> >> no (meta new-dom)]
>> >> (if (and (:pure mo) (:pure no) (= (:pure mo) (:pure no)))
>> >>   .. ah, they're from the same pure function, thus the same ...
>> >>   ... okay, let's do expensive deep diff)))
>> >>
>> >>
>> >> so basically, we abuse meta objects, record
>> >>
>> >>   * what data gave us this dom tree ?
>> >>   * was the func that gave us the dom tree pure ?
>> >>
>> >> And if so, we just do a equality check on the data -- which are are
>> >> _not_ "regenerating" and thus matches an equality check.
>> >>
>> >>
>> >> Please let me if:
>> >>
>> >>   (a) this resolves the issue
>> >>   (b) I completely misunderstood the question
>> >>
>> >>
>> >> Thanks!
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Mon, Feb 24, 2014 at 1:00 PM, Brian Craft 
>> wrote:
>> >> > This is vaguely related to David's posts about om/react, where he
>> talks
>> >> > about optimizing state change tracking by checking object identity
>> on
>> >> > immutable objects: deep compares can be avoided if same identity
>> implies
>> >> > no
>> >> > changes.
>> >> >
>> >> > My first thought was that there are many algorithms that will give
>> you a
>> >> > new
>> >> > object every time, even if nothing has changed.  E.g. if your state
>> has
>> >> > an
>> >> > array whose elements must be validated, doing a map over the
>> elements
>> >> > will
>> >> > give you a new array every time, even if it makes no changes.
>> >> >
>> >> > Enforcing non-negative values, for instance:
>> >> >
>> >> > => (let [x {:a [1 -2 3]}] (update-in x [:a] (fn [y] (mapv #(if (< %
>> 0) 0
>> >> > %)
>> >> > y
>> >> > {:a [1 0 3]

Re: Om: trouble with goog reference

[David Nolen]

Your markup needs to look something like:


http://fb.me/react-0.9.0.js";>


goog.require("om_ho.core");

HTH,
David


On Thu, Feb 27, 2014 at 6:26 AM, cig  wrote:

> Hi David
>
> I tried changing :advanced mode to :whitespace mode. My index.html file
> looks as follows:
>
> 
>   
> 
> http://fb.me/react-0.9.0.js";>
> 
>   
> 
>
> my project.clj file looks as follows:
> (defproject om-ho "0.0.1-SNAPSHOT"
>   :description "FIXME: write description"
>   :url "http://example.com/FIXME";
>   :license {:name "Eclipse Public License - v 1.0"
> :url "http://www.eclipse.org/legal/epl-v10.html";
> :distribution :repo}
>
>   :min-lein-version "2.3.4"
>
>   :source-paths ["src/clj" "src/cljs"]
>
>   :dependencies [[org.clojure/clojure "1.5.1"]
>  [org.clojure/clojurescript "0.0-2156"]
>  [org.clojure/core.async "0.1.267.0-0d7780-alpha"]
>  [om "0.5.0"]
>  [com.facebook/react "0.9.0"]]
>
>   :plugins [[lein-cljsbuild "1.0.2"]]
>
>   :hooks [leiningen.cljsbuild]
>
>   :cljsbuild
>   {:builds {:om-ho
> {:source-paths ["src/cljs"]
>  :compiler
>  {:output-to "dev-resources/public/js/om_ho.js"
>   :optimizations :none
>   :pretty-print false)
>
> With this setup. Evaluating core.cljs (which is taken directly from your
> Higher Order Components tutorial) I see the, "XHR finished Loading" events
> in the browser, which is a good sign, but the only text which renders is,
> "Registry". I assume this is because of the missing goog.closure lines in
> the index.html file
>
> i.e.
> 
> goog.require("om_ho.core");
>
> When I include these two lines I get the same errors that Chris mentioned
> above.
>
> Would really appreciate your help.
>
> Clifford
>
> On Monday, 24 February 2014 03:22:22 UTC+2, boz wrote:
>>
>> I'm having trouble with the Om basic tutorial Higher Order 
>> Components
>>  using
>> emacs and a slightly modified version of https://github.com/
>> magomimmo/om-start-template that points to Om 0.5.0 and React 0.9.0.
>> My version is https://github.com/christoferjennings/om-start-template
>>
>> The template doesn't have the goog/base.js out of the box. When I add it,
>> I get a "Uncaught ReferenceError: goog is not defined" (Chrome Version
>> 33.0.1750.117)
>>
>> Here's the final html (basically the same as in the tutorial.
>> 
>> 
>> 
>> http://fb.me/react-0.9.0.js";>
>> 
>> 
>> 

Re: Om: trouble with goog reference

[David Nolen]

Many thanks for taking the time to implement & share your solution!

David


On Thu, Feb 27, 2014 at 1:40 PM, boz  wrote:

> Hi David, Clifford,
>
> I'm pretty sure Clifford is using the Cider version from 
> Mimmo<https://github.com/magomimmo/om-start-template/>.
> I've got a fork of 
> it<https://github.com/christoferjennings/om-start-template>with updates so it 
> work with Om 0.5.0 and React 0.9.0 that I've used to get
> through the basic tutorial so far. Clifford and I have talked about it
> here <https://github.com/magomimmo/om-start-template/issues/5> and there
> is a pull request <https://github.com/magomimmo/om-start-template/pull/6>.
>  When using the Cider version the HTML should actually look like this
> (using "om_ho.js" to match Clifford's)...
>
> 
>   
> 
> http://fb.me/react-0.9.0.js"</a>;>
> 
>   
> 
>
>
> I plan to put some examples online asap, hopefully by tomorrow, so other
> newbies (like myself) can compare notes. ... One thing that I stumbled on
> was that the tutorial shows the whole HTML but really, afaik, the only
> change was the id of the div (from "app" to "registry").
>
> I'm having a lot of fun working on this stuff, btw. Om is very cool.
> Looking forward to getting into the intermediate tutorial with Datomic too
> :)
>
> ,chris
>
> On Thursday, February 27, 2014 6:03:22 AM UTC-8, David Nolen wrote:
>
>> Your markup needs to look something like:
>>
>> 
>> http://fb.me/react-0.9.0.js"</a>;>
>> 
>> 
>> goog.require("om_ho.core");
>>
>> HTH,
>> David
>>
>>
>> On Thu, Feb 27, 2014 at 6:26 AM, cig  wrote:
>>
>>> Hi David
>>>
>>> I tried changing :advanced mode to :whitespace mode. My index.html file
>>> looks as follows:
>>>
>>> 
>>>   
>>> 
>>> http://fb.me/react-0.9.0.js"</a>;>
>>> 
>>>   
>>> 
>>>
>>> my project.clj file looks as follows:
>>> (defproject om-ho "0.0.1-SNAPSHOT"
>>>   :description "FIXME: write description"
>>>   :url "http://example.com/FIXME";
>>>   :license {:name "Eclipse Public License - v 1.0"
>>> :url "http://www.eclipse.org/legal/epl-v10.html";
>>> :distribution :repo}
>>>
>>>   :min-lein-version "2.3.4"
>>>
>>>   :source-paths ["src/clj" "src/cljs"]
>>>
>>>   :dependencies [[org.clojure/clojure "1.5.1"]
>>>  [org.clojure/clojurescript "0.0-2156"]
>>>  [org.clojure/core.async "0.1.267.0-0d7780-alpha"]
>>>  [om "0.5.0"]
>>>  [com.facebook/react "0.9.0"]]
>>>
>>>   :plugins [[lein-cljsbuild "1.0.2"]]
>>>
>>>   :hooks [leiningen.cljsbuild]
>>>
>>>   :cljsbuild
>>>   {:builds {:om-ho
>>> {:source-paths ["src/cljs"]
>>>  :compiler
>>>  {:output-to "dev-resources/public/js/om_ho.js"
>>>   :optimizations :none
>>>   :pretty-print false)
>>>
>>> With this setup. Evaluating core.cljs (which is taken directly from your
>>> Higher Order Components tutorial) I see the, "XHR finished Loading" events
>>> in the browser, which is a good sign, but the only text which renders is,
>>> "Registry". I assume this is because of the missing goog.closure lines in
>>> the index.html file
>>>
>>> i.e.
>>> 
>>> goog.require("om_ho.core");
>>>
>>> When I include these two lines I get the same errors that Chris
>>> mentioned above.
>>>
>>> Would really appreciate your help.
>>>
>>> Clifford
>>>
>>> On Monday, 24 February 2014 03:22:22 UTC+2, boz wrote:
>>>>
>>>> I'm having trouble with the Om basic tutorial Higher Order 
>>>> Components<https://github.com/swannodette/om/wiki/Basic-Tutorial#wiki-higher-order-components>
>>>>  using
>>>> emacs and a slightly modified version of https://github.com/magomimm
>>>> o/om-start-template that points to Om 0.5.0 and React 0.9.0.
>>>> My version is https://github.com/christoferjennings/om-start-template
>>>>
>>>> The template doesn't have the goog/base.js out of the box. When I add
>>>> it, I get a "Uncaught ReferenceError: goog is not defined" (Chrome Version
>>>> 33.0.1750.117)
>>>>
>>>> Here's the final html (basically the same as in the tutorial.
>>>> 
>>>> 
>>>> 
>>>> http://fb.me/react-0.9.0.js"</a>;>
>>>> 
>>>> 
>>>> 

Re: Found some unexpected behavior to me

[David Nolen]

Fixed in 1.6.

David


On Thu, Feb 27, 2014 at 3:50 PM, Brent Millare wrote:

> Clojure 1.5.1
>
> user=> (defprotocol IEmit (-emit [x]))
> IEmit
>
> user=> (defrecord css [y] IEmit (-emit [_] y))
> user.css
>
> user=> (-emit (->css 3))
> 3
>
> user=> (map -emit [(->css 3)])
> IllegalArgumentException No matching field found: emit for class user.css
>  clojure.lang.Reflector.getInstanceField (Reflector.java:271)
>
> user=> (map #(-emit %) [(->css 3)])
> (3)
>
>
> Why can't I pass -emit as an argument to map?
>
> --
> 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: Solving allocation problems; code review and core.logic

[David Nolen]

I'm cross posting this to the miniKanren mailing list.

It sounds like core.logic or cKanren could be applied to your problem but
would need more details. I also wouldn't rule out finite domain solvers
like JaCoP.

David


On Wed, Mar 5, 2014 at 9:52 AM, Laurens Van Houtven <_...@lvh.cc> wrote:

> Hi!
>
>
> I've been experimenting solving some real-world problems related to
> organizing a sizable (2000-3000 people) programming conference with a
> strong open source flavor.
>
> My next problem is a bit more daunting.
>
> This conference has a financial aid program. People who can not afford
> to come to the conference are given grants that have to come out of a
> budget. The budget is much smaller than the sum of all requested
> grants, so it turns into an underspecified optimization problem. In
> order to make that issue slightly less bad, there's a score function
> so that we can bias in favor of certain people, e.g. speakers.
>
> I'm convinced the optimal solution, even assuming it exists, is
> impossible to find. The data is incomplete; it is not necessarily true
> that because you assign less than what people have requested that they
> won't accept the grant.
>
> I wrote an implementation that plausibly matches the above:
>
> https://github.com/lvh/hood/blob/master/src/hood/core.clj
>
> I'm sure that that code has a lot of flaws. I haven't really played
> with it enough yet. Code review on that is very welcome. Any
> suggestions for a cleverer allocation algorithm would also be much
> appreciated.
>
> That said, I really sent this e-mail because I was wondering to what
> extent core.logic could be applied to this problem. The "running your
> program in reverse" concept is potentially interesting here; I'm
> hoping that we could get answers to questions like "what would an
> application have to look like to get X dollars under our budget?"
>
> I seriously don't even know where to start. What would the logic
> variables be? It seems that a lot of the example code uses a single
> logic variable and then "structures" it in the let body; but I have no
> idea what that one variable would even mean.
>
> Perhaps I should just tackle some simpler logic programs first :-)
>
> Thanks in advance for your thoughts and comments!
> lvh
>
>  --
> 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.

ANN: Om 0.5.2, Regeant, Quiescent, React interop & more

[David Nolen]

While I think Om's approach to application state management delivers
considerable benefit, I think it would be unfortunate if all the labor put
into reusable Om components was confined to Om users. With the latest
release I've included examples demonstrating how two important things are
now possible:

1) Because of the cursor abstraction you can reinterpret the meaning of
transact! For example here is an Om component that can be used from a plain
React component
http://github.com/swannodette/om/blob/master/examples/stateful/src/core.cljs.
No Om requestAnimationFrame render loop or batched updates to be found.

2) Because Om components are one step removed from React components, you
can back an Om component with an alternate implementation. For example here
is an Om component that has been forced to write its local state into the
global application state.
http://github.com/swannodette/om/blob/master/examples/harmful/src/core.cljs#L158

Together these features offer a better interoperability story for
ClojureScript React users as well as powerful debugging facilities when
coupled with :instrument.

Feedback welcome!

http://github.com/swannodette/om

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: Test G.Closure lib release 0.0-20140226-71326067

[David Nolen]

Andrew,

I've tried the new JARs on a couple of projects and I have not encountered
these issues. Did you make sure to run a `lein cljsbuild clean`?

Thanks.

David


On Wed, Mar 12, 2014 at 8:19 PM, Andrew Keedle  wrote:

> Stuart,
> Did you ever get any response to this? I made the changes as suggested in
> the gist and ran into problems. With a simple [goog.events :as events] in
> the ns and optimizations :none I get the attached errors on a simple
> project from a lein new mies... optimizations :simple appears to work fine
> for this and more complicated setups.
>
> Thanks,
> Andrew
>
> --
> 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 http://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.

CLJS Advanced Compilation & JS Libraries lacking externs

[David Nolen]

I've written up an explanation how to make this work
http://swannodette.github.io/2014/03/14/externs-got-you-down/

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: [GSoC] Mentor for self-hosting ClojureScript compiler project?

[David Nolen]

Max,

Just a fair bit of warning that such a project should probably only happen
under GSoC only if it actually pushes along *official* support for
bootstrapping ClojureScript in ClojureScript. Just forking the compiler and
making changes until "it works" just isn't going to fly and I do not think
it's a good use of anyone's time. Such a project has already been attempted
in the past and it's now effectively abandon-ware. So working on a separate
compiler is not something I think should be under consideration at all for
GSoC.

The remaining work for CLJS-in-CLJS is actually *not* very ambitious and
can likely be completed in the GSoC period:

* convert AST manipulation to tools.analyzer
* native *compiler* macros (no runtime macro support will be considered for
this project)
* CLJS port of tools.reader
* multimethod perf enhancement

This is really all that remains to be done, everything else is really
papering over platform details (I/O, symbol translation).

If this sounds fun/exciting to you should apply. If it doesn't, I recommend
directing your energies elsewhere. I'm more than happy to mentor this, but
in order for this to succeed I would like to see work done along these
lines from interested parties long before the GSoC period begins.

David


On Tue, Mar 18, 2014 at 2:42 AM, Max Kreminski wrote:

> Hello all,
>
> I'm applying to GSoC this year, and I'm interested in taking the
> opportunity to go full-speed on a project I've been toying with on the side
> for the last month or so now.
>
> Specifically, I'm interested in writing a self-hosting ClojureScript
> compiler – either by forking the current ClojureScript codebase and making
> whatever changes are necessary to get it to compile itself, or by putting
> way more time and energy into the toy CLJS compiler I've been writing from
> the ground up in my spare time. It's an ambitious project either way, but
> I've been pleasantly surprised enough by my progress so far that it seems
> to be within reach.
>
> You can see the progress I've made lately on Ceci, the aforementioned toy
> CLJS compiler, at http://github.com/mkremins/ceci. Fair warning: it's
> pretty rusty, and a lot of functionality is just plain missing or
> unsupported at the moment – patching up some of these holes could be part
> of my summer work if my application gets accepted :)
>
> Is anyone interested in mentoring this or a similar project? I'd love to
> chat.
>
> Thanks,
> Max
>
> --
> 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: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[David Nolen]

Just tried 1.6.0-RC1 with ClojureScript master. All ClojureScript tests
pass except for one which is due to assumptions about print order
(different now due to hash code changes). Easy enough to fix once 1.6.0
actually ships.

David


On Tue, Mar 18, 2014 at 1:44 PM, Alex Miller  wrote:

> Thanks Michael! You're the hops in my ale.
>
> On Tuesday, March 18, 2014 12:22:15 PM UTC-5, Michael Klishin wrote:
>>
>> 2014-03-18 18:21 GMT+04:00 Alex Miller :
>>
>> We need your help in checking out the current release candidate - this is
>>> your opportunity to let us know about problems *before* we release, rather
>>> than after.
>>
>>
>> No issues to report from testing 20+ ClojureWerkz projects on 1.6.0-RC1.
>> --
>> MK
>>
>> http://github.com/michaelklishin
>> http://twitter.com/michaelklishin
>>
>  --
> 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: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[David Nolen]

Yep, we'll get rid of it once 1.6.0 actually ships.

David


On Tue, Mar 18, 2014 at 5:04 PM, Alex Miller  wrote:

> I assume that fixing this is a matter of updating src/clj/cljs/core.clj in
> clojurescript to exclude unsigned-bit-shift-right?
>
>
> On Tuesday, March 18, 2014 2:52:03 PM UTC-5, Ambrose Bonnaire-Sergeant
> wrote:
>
>> FYI `mvn test` will fail on core.typed because of this issue.
>>
>> I believe it otherwise passes.
>>
>> Ambrose
>>
>>
>> On Wed, Mar 19, 2014 at 3:45 AM, Alex Miller wrote:
>>
>>> Yeah, that's a thing. I think the name was chosen intentionally to be
>>> the same across those as cljs had it first.
>>>
>>>
>>> On Tuesday, March 18, 2014 2:29:04 PM UTC-5, Ambrose Bonnaire-Sergeant
>>> wrote:
>>>
 I believe this is because cljs.core defines unsigned-bit-shift-right,
 which now conflicts
 with clojure.core/unsigned-bit-shift-right (added with 1.6.0).

 1.6.0 doesn't seem to break anything here, aside from adding to
 clojure.core.

 Thanks,
 Ambrose


 On Wed, Mar 19, 2014 at 3:12 AM, Ambrose Bonnaire-Sergeant <
 abonnair...@gmail.com> wrote:

> I think I found a difference between 1.5.1->1.6.0-RC1.
>
> (compile 'cljs.core) fails with a NPE in 1.6.0-RC1. I realise this
> isn't particularly supported
> by CLJS, but it still worked in 1.5.1.
>
> https://github.com/frenchy64/clojure-16-fail
>
> Help narrowing this is appreciated.
>
> Thanks,
> Ambrose
>
>
> On Wed, Mar 19, 2014 at 3:05 AM, Alex Miller wrote:
>
>> Thanks Ken! You're the cheese on my nachos.
>>
>>
>> On Tuesday, March 18, 2014 12:45:46 PM UTC-5, Ken Barber wrote:
>>
>>> We had some bugs related to assumed ordering in our code which
>>> 1.6.0-RC1 surfaced (https://github.com/puppetlabs/puppetdb/pull/887),
>>>
>>> otherwise everything looks good for our project - thanks for all the
>>> hard work on this release.
>>>
>>> ken.
>>>
>>> On Tue, Mar 18, 2014 at 2:21 PM, Alex Miller 
>>> wrote:
>>> > Hello all,
>>> >
>>> > We would love to release Clojure 1.6.0 final soon.
>>> >
>>> > We need your help in checking out the current release candidate -
>>> this is
>>> > your opportunity to let us know about problems *before* we
>>> release, rather
>>> > than after.
>>> >
>>> > Try it via
>>> > - Download: http://central.maven.org/maven2/org/clojure/clojure/1.
>>> 6.0-RC1
>>> > - Leiningen: [org.clojure/clojure "1.6.0-RC1"]
>>> >
>>> > See the full change log here:
>>> > https://github.com/clojure/clojure/blob/master/changes.md
>>> >
>>> > If you have questions, feel free to drop them here. For issues,
>>> please log
>>> > them in JIRA.
>>> >
>>> > Alex
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> > Groups "Clojure" group.
>>> > To post to this group, send email to clo...@googlegroups.com
>>> > Note that posts from new members are moderated - please be patient
>>> with your
>>> > first post.
>>> > To unsubscribe from this group, send email to
>>> > clojure+u...@googlegroups.com
>>> > For more options, visit this group at
>>> > http://groups.google.com/group/clojure?hl=en
>>> > ---
>>> > You received this message because you are subscribed to the Google
>>> Groups
>>> > "Clojure" group.
>>> > To unsubscribe from this group and stop receiving emails from it,
>>> send an
>>> > email to clojure+u...@googlegroups.com.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>  --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient
>> with your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to clojure+u...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this 

Re: om component state

[David Nolen]

On Thu, Mar 20, 2014 at 5:57 AM, Adrian Miron wrote:

>
> I'm starting to use om in some projects and one of the first components I
> had to build was a simple notification component. It shows a message at the
> top of the page. Other components in the page will use it to display
> messages when errors happen.
>
> My idea was to send the message string to it via a channel and store it in
> local state. From there it will be rendered by the component.
>
> The component doesn't use any application state so I build it with what I
> believed to be a nil cursor (om/build notification *nil* {...}). The
> problem is that when the component gets rendered I get a "No protocol
> method ICursor.-path defined for type null" error.
>

If you don't pass app state data to this component then you don't need to
bother with build at all. If you need a component that doesn't need app
state but does need component local state you need to use om.core/graft.
Refer to the documentation on om.core/graft and look at the examples in the
repo.

Channels could work. However :shared was also designed with this scenario
in mind, you could use an atom with the message in it and placed it in
:shared if the message is not an important piece of state for the rest of
your application. There are also examples of :shared in the repo as well.

HTH,
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: rant / cljs in cljs ? :-)

[David Nolen]

Unless you're compiling a very large file - with auto :optimizations :none
you should always get sub-second compile times under auto.

David


On Fri, Mar 21, 2014 at 10:55 AM, Timothy Baldridge wrote:

> are you using "lein cljsbuild auto" ? That's what I use, and I get about
> 1-3 sec recompile times for stuff that uses core.async.
>
> Timothy
>
>
> On Fri, Mar 21, 2014 at 12:48 AM, t x  wrote:
>
>> Hi,
>>
>> *  I'm already using:
>>
>>   :incremental true
>>   :compiler { :optimizations :none }
>>
>> * I'm also aware of cljs brepl
>>
>>
>> However:
>>
>> 1) the cljs compiler is still too slow for my liking (even though it's
>> not calling closure)
>>
>> 2) I don't like the cljs repl nearly as much as I like the clj repl
>>
>>
>> Now, my dumb/stupid question:
>>
>>   Is there any cljs in cljs _slow_ interpreter? I'm perfectly happy
>> with an interpreter that runs 10x slower, if, in exchange, I get to
>> hit "refresh" and my new code starts running.
>>
>>   Furthermore, I'm _okay_ with their being a big delay every time I
>> introduce a new macro from clj land.
>>
>>
>>   I realize this sounds spoiled -- but -- the cljs compiler delays are
>> really really breaking my flow.
>>
>>
>> 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.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> 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: om component state

[David Nolen]

On Fri, Mar 21, 2014 at 11:45 AM, Adrian Miron wrote:

>
>
> On Thursday, March 20, 2014 10:58:08 PM UTC+2, David Nolen wrote:
>>
>>
>> If you don't pass app state data to this component then you don't need to
>> bother with build at all. If you need a component that doesn't need app
>> state but does need component local state you need to use om.core/graft.
>> Refer to the documentation on om.core/graft and look at the examples in the
>> repo.
>>
>> Channels could work. However :shared was also designed with this scenario
>> in mind, you could use an atom with the message in it and placed it in
>> :shared if the message is not an important piece of state for the rest of
>> your application. There are also examples of :shared in the repo as well.
>>
>> HTH,
>> David
>>
>
> Thank you for your reply. I've used graft and it works fine with channels.
> I will also try :shared, but I guess I will have to call refresh! after I
> swap the shared atom?
>

No the simplest thing would be to call om.core/root again, however if this
is not really a global change (i.e. switching logged in user) then you have
to pay for re-rendering your entire UI and throwing away all component
local state.

Sounds like the simplest solution for you is a :shared message channel.
Components that care about the message need to set up go loops and update
their state when they receive a new message.

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

ANNN: ClojureScript 0.0-2197

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

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

New release version: 0.0-2197

Leiningen dependency information:

[org.clojure/clojurescript "0.0-2197"]

Changes & Enhancements:
* updated Google Closure Library dependency
* Allow the language_in && the language_out option to be set for the google
closure compiler
* Use Array.isArray when building for node.js

Fixes:
* CLJS-774: ensure correct cljs.reader inst and ratio parsing.
* CLJS-782: toString implementation for UUID
* CLJS-780: apply-to broken for arg count >= 6
* CLJS-778: RSeq does not implement INext, incorrect -rest implementation
* CLJS-777: multimethods are not IFn
* CLJS-772: Support :none & :whitespace optimizations under Node.js
* CLJS-728: fix (get coll k) when coll is vector-like and k is non-numeric.
* CLJS-757: Remove redundant bounds checking in PersistentVector and
TransientVector.
* CLJS-745: Support destructuring maps with namespaced keywords
* CLJS-768: Fix assoc!-ing non-numeric keys into TransientVector.
* CLJS-770: refactor goog-style JS dependency bits into cljs.js-deps,
populate :js-dependency-index in default cljs environments

-- 
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] Clojure 1.6

[David Nolen]

It looks like the zip file that usually included with the releases is
missing?

http://repo1.maven.org/maven2/org/clojure/clojure/1.5.1/

vs.

http://repo1.maven.org/maven2/org/clojure/clojure/1.6.0/

Thanks,
David


On Tue, Mar 25, 2014 at 7:00 AM, Alex Miller  wrote:

> We are pleased to announce the release of Clojure 1.6.
>
> Getting Clojure:
>
>   Web:  http://clojure.org/downloads
>   Lein/Maven:   :dependencies [[org.clojure/clojure "1.6.0"]]
>
> (The download should be available shortly)
>
> This release includes significant features and bug fixes, documented
> here:
>
>   https://github.com/clojure/clojure/blob/master/changes.md
>
> The number of Clojure contributors continues to grow. Thanks to all
> of those who contributed specifically to Clojure 1.6:
>
> Bruce Adams
> Vipul Amler
> Mike Anderson
> Timothy Baldridge
> Brandon Bloom
> Toby Crawley
> Andy Fingerhut
> Michael Fogus
> Gary Fredricks
> Joe Gallo
> Christophe Grand
> Chris Gray
> Anthony Grimes
> Stuart Halloway
> Herwig Hochleitner
> Gabriel Horner
> Colin Jones
> Stefan Kamphausen
> Scott Lowe
> Alan Malloy
> Michał Marczyk
> Tim McCormack
> Alex Miller
> Steve Miner
> Nicola Mometto
> Max Penet
> Christoffer Sawicki
> Karsten Schmidt
> Ghadi Shayban
> Stuart Sierra
> Brian Taylor
> Devin Walters
> Jason Wolfe
>
> and to the total list of contributors from all releases:
> http://clojure.org/contributing#patches
>
> Thanks!
>
> Alex Miller
>
>  --
> 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] Clojure 1.6

[David Nolen]

Thanks!


On Mon, Mar 31, 2014 at 6:26 PM, Stuart Sierra
wrote:

> Oof, it's been ages since I looked at that stuff. I'll take a look.
>
> --
> 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 0.0-2199

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

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

New release version: 0.0-2199

Leiningen dependency information:

[org.clojure/clojurescript "0.0-2199"]

The only difference is the removal of spurious warnings about
required/imported Google Closure libraries.

-- 
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: om: state management considerations

[David Nolen]

On Wed, Apr 2, 2014 at 3:42 AM, rlewczuk  wrote:

>
> First one is about object created by (om/build ...) - in all tutorials
> these objects are always created on the fly in (render ...) functions. So
> if some component disappears from view for some time, it loses its state.
> This might be the case in tab panels for example: views representing
> individual tabs disappear when user switches onto another tab. Is it safe
> to retain reference to such view created by om/build or should it be build
> from scratch every time ?
>

In the case of tabs I would generally not destroy the view but simply hide
it with styling. Views should always be built from scratch every time - it
is not expensive :) Virtual DOM FTW.


> Second thing is inter-component communication. I assume that meddling with
> state of one component from another component (eg. reading data from edited
> row by data grid) is considered harmful and core.async channel should be
> used in such cases which implies actor model for UI app. Is it safe to
> assume that om is opinionated in this regard (using actor model for
> communication) ? If so, are there materials regarding proper design and
> structuring of actors and their communication (think: GoF-like 'design
> patterns' for actor model) ? I've read some parts of a few  Erlang books
> regarding some of it but it seems to cover only basics and simple cases.
>

Yes for coordination between components I would use either callbacks in the
simple case and channels in the complex one.

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

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

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

New release version: 0.0-2202

Leiningen dependency information:

[org.clojure/clojurescript "0.0-2202"]

This release is similar to 0.0-2199, it just addresses an issue that
cropped up with the latest Google Closure Library Third Party release.

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: A thought on Om/React

[David Nolen]

React is already headed in the direction you suggest. Still there would be
advantages to having something native in Clojure of course and perhaps
someone feels inclined to pursue that.

On Tuesday, April 8, 2014, Dave Sann  wrote:

> I haven't built anything with OM or react as yet. But I have read about it
> and I like the model in principle.
>
> A thought which repeatedly pops into my mind when I read about this is -
> ok, react in written in js. which is great for the web. What would happen
> if it were written in Clojure and available on server (As well as client (I
> am not thinking nodejs here).
>
> Going on slightly, it might be possible to
>
> 1. have a generally useful delta calculation - for this sort of use.
> 2. have a DOM structure and event model that could be mapped/bridged to
> swing or javafx or other.
> 3. have different UI models other than DOM that could be mapped to DOM or
> swing of javafx or other.
>
> I have no plans to do anything with this currently - but am interested in
> peoples thoughts.
>
> Dave
>
>  --
> 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: Om and core.async: Necessary together?

[David Nolen]

It's mostly for demonstration purposes, but I think it will be a common
pattern when more complex coordination is required. I think components
should probably communicate via callbacks and applications can glue things
together with core.async if it's beneficial.

David


On Wed, Apr 9, 2014 at 10:54 AM, Kendall Buchanan
wrote:

> Hi,
>
> I have a question about Om's "Basic Tutorial", and perhaps core.async's
> role generally:
>
> The example given in the section, "Intercomponent Communication", uses
> core.async for communication between two components. Is this necessary? Or,
> is it demonstration? It seems in testing that I can even more easily pass
> functions between components as I might a channel, but without go loops?
>
> I've used React.js to some extent and obviously it lacks Clojurescripts
> asynchronous fanciness. Where might core.async excel in Om?
>
> --
> 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: Om and core.async: Necessary together?

[David Nolen]

Reusable components - use callbacks
Application components (non-reusable or less re-usable) - use channels

David


On Wed, Apr 9, 2014 at 7:53 PM, Brendan Stromberger <
brendanstromber...@gmail.com> wrote:

> How can one build up the intuition to know, in what situation, whether it
> would be more beneficial to use callbacks or channels? Are there
> 'rules-of-thumb' that I could follow until that intuition is established?
>
>
> On Wednesday, April 9, 2014 8:40:19 AM UTC-7, David Nolen wrote:
>
>> It's mostly for demonstration purposes, but I think it will be a common
>> pattern when more complex coordination is required. I think components
>> should probably communicate via callbacks and applications can glue things
>> together with core.async if it's beneficial.
>>
>> David
>>
>>
>> On Wed, Apr 9, 2014 at 10:54 AM, Kendall Buchanan > > wrote:
>>
>>> Hi,
>>>
>>> I have a question about Om's "Basic Tutorial", and perhaps core.async's
>>> role generally:
>>>
>>> The example given in the section, "Intercomponent Communication", uses
>>> core.async for communication between two components. Is this necessary? Or,
>>> is it demonstration? It seems in testing that I can even more easily pass
>>> functions between components as I might a channel, but without go loops?
>>>
>>> I've used React.js to some extent and obviously it lacks Clojurescripts
>>> asynchronous fanciness. Where might core.async excel in Om?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>>
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>>
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@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: Om and core.async: Necessary together?

[David Nolen]

Also don't use a channel unless you actually need complex coordination. I
would always default to a callback first.

David


On Wed, Apr 9, 2014 at 7:56 PM, David Nolen  wrote:

> Reusable components - use callbacks
> Application components (non-reusable or less re-usable) - use channels
>
> David
>
>
> On Wed, Apr 9, 2014 at 7:53 PM, Brendan Stromberger <
> brendanstromber...@gmail.com> wrote:
>
>> How can one build up the intuition to know, in what situation, whether it
>> would be more beneficial to use callbacks or channels? Are there
>> 'rules-of-thumb' that I could follow until that intuition is established?
>>
>>
>> On Wednesday, April 9, 2014 8:40:19 AM UTC-7, David Nolen wrote:
>>
>>> It's mostly for demonstration purposes, but I think it will be a common
>>> pattern when more complex coordination is required. I think components
>>> should probably communicate via callbacks and applications can glue things
>>> together with core.async if it's beneficial.
>>>
>>> David
>>>
>>>
>>> On Wed, Apr 9, 2014 at 10:54 AM, Kendall Buchanan <
>>> ken...@teachbanzai.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I have a question about Om's "Basic Tutorial", and perhaps core.async's
>>>> role generally:
>>>>
>>>> The example given in the section, "Intercomponent Communication", uses
>>>> core.async for communication between two components. Is this necessary? Or,
>>>> is it demonstration? It seems in testing that I can even more easily pass
>>>> functions between components as I might a channel, but without go loops?
>>>>
>>>> I've used React.js to some extent and obviously it lacks Clojurescripts
>>>> asynchronous fanciness. Where might core.async excel in Om?
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To post to this group, send email to clo...@googlegroups.com
>>>>
>>>> Note that posts from new members are moderated - please be patient with
>>>> your first post.
>>>> To unsubscribe from this group, send email to
>>>> clojure+u...@googlegroups.com
>>>>
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/clojure?hl=en
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to clojure+u...@googlegroups.com.
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>  --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@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: Om and core.async: Necessary together?

[David Nolen]

I would probably still do an async autocompleter component with channels
where it seems useful *internally*. I just wouldn't expose channels as an
interface to users of this component. I think most of points from my CSP
posts still hold even with React/Om.

David


On Wed, Apr 9, 2014 at 11:57 PM, Mike Haney  wrote:

> David,
>
> This seems to be a different take on things than you proposed in your
> series of CSP articles last summer.  I'm not saying that is a bad thing -
> if an idea doesn't pan out, it needs to be scrapped (and most of us cling
> to bad ideas longer than we should).  I'm just curious why the change of
> heart (if that is the case, maybe I'm just misunderstanding you).  You've
> mentioned reusability a couple of times, but I just don't see how the Om
> approach improves that over the architecture you described in those
> articles.
>
> What attracted me to the React approach initially was how well it seemed
> to fit in with CSP.  The idea of separate coordinated processes
> manipulating the application state, while the UI representation is just a
> function of that state (i.e. a pure transformation from the app state to a
> DOM, or virtual DOM in React's case) is very appealing. I know things are
> usually uglier in practice, and you have far more experience with this
> stuff than I do, so maybe you have just hit enough ugly parts to rethink
> the approach (if so, please share)?
>
> I thought I had figured out the missing piece to my comprehension when I
> read one of your posts on the Clojurescript group the other day, where you
> talked about Om components that don't render.  I didn't even know that was
> possible before you mentioned it, and then the lightbulb came on and I
> started thinking about how to adapt your CSP examples in that context.  It
> seems like you could have processes like a highlighter or selector that are
> implemented as non-rendering Om components and they could wrap and compose
> with other components.  I was anxious to try that out on my current
> project, but I've been tied up on Datomic stuff all week and didn't get the
> chance yet.
>
> But after reading this post, I'm not so sure about that now.  I know
> you've been thinking through some of the reusability issues over the last
> week, so maybe I just need to wait until you write up your ideas.  I really
> want to figure this out and use it on a non-trivial real-world project (the
> one I mentioned above).  So if you need a lab rat for some of these
> ideas...
>
>
> On Wednesday, April 9, 2014 6:57:50 PM UTC-5, David Nolen wrote:
>
>> Also don't use a channel unless you actually need complex coordination. I
>> would always default to a callback first.
>>
>> David
>>
>>
>> On Wed, Apr 9, 2014 at 7:56 PM, David Nolen  wrote:
>>
>>> Reusable components - use callbacks
>>> Application components (non-reusable or less re-usable) - use channels
>>>
>>> David
>>>
>>>
>>> On Wed, Apr 9, 2014 at 7:53 PM, Brendan Stromberger <
>>> brendanst...@gmail.com> wrote:
>>>
>>>> How can one build up the intuition to know, in what situation, whether
>>>> it would be more beneficial to use callbacks or channels? Are there
>>>> 'rules-of-thumb' that I could follow until that intuition is established?
>>>>
>>>>
>>>> On Wednesday, April 9, 2014 8:40:19 AM UTC-7, David Nolen wrote:
>>>>
>>>>> It's mostly for demonstration purposes, but I think it will be a
>>>>> common pattern when more complex coordination is required. I think
>>>>> components should probably communicate via callbacks and applications can
>>>>> glue things together with core.async if it's beneficial.
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>> On Wed, Apr 9, 2014 at 10:54 AM, Kendall Buchanan <
>>>>> ken...@teachbanzai.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have a question about Om's "Basic Tutorial", and perhaps
>>>>>> core.async's role generally:
>>>>>>
>>>>>> The example given in the section, "Intercomponent Communication",
>>>>>> uses core.async for communication between two components. Is this
>>>>>> necessary? Or, is it demonstration? It seems in testing that I can even
>>>>>> more easily pass functions between components as I might a channel, but
>>>>>> wi

ANN: Om 0.6.1, moving towards independently addressable components

[David Nolen]

Om 0.6.1 significantly changes how component local state works - we now
rely on React's forceUpdate to update components that use local state. This
is a significant change so I would like people test this out on their
existing code bases as soon as possible.

The immediate benefit is that components now use `=` for the
shouldComponentUpdate logic instead of `identical?`. This means
considerably more flexibility with regards to what a component may receive
without taking a performance hit with respect to rendering. Even more
importantly it's a big step towards independently addressable components.

What are independently addressable components? Currently many people
struggle with the fact that parent components must take all the data
associated with their children. This often results in a tight coupling that
is not ideal for real applications. The next few releases of Om will be
focused on providing a sensible solution to this issue without backing away
from the existing efficient time travel capabilities.

Feedback welcome!

http://github.com/swannodette/om

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: Core.logic appendo for string?

[David Nolen]

There's no easy way to do this beyond making your own relational string
type as you've suggested.

On Sunday, May 4, 2014, Adam Saleh  wrote:

> Hi,
>
> every once in a while I am toying with an idea of doing string
> manipulation in core.logic.
>
> Naively trying to use appendo doesn't really work.
> As far as I understand, most of the magic, that enables core logic to work
> with lists is in the type LCons, that holds a sequence with tail that is
> still an lvar.
>
> Does it mean that I would need to implement a similar type for string (ie
> LStr),
> and then reimplement conso/firsto/lasto/appendo/e.t.c?
>
> If you know of simpler solution, that would still give me a nice string
> interface, I would like to hear about it :-)
>
> Thanks!
>
> Adam
>
> PS: Using '(\a \s \d \f) instead of "asdf" and then project doesn't cut it
>
> --
> 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: Clojurescript set count returning erroneous values.

[David Nolen]

Can you demonstrate a complete minimal example?

Thanks,
David


On Tue, May 20, 2014 at 4:06 AM, Austin Haas  wrote:

> I'm having trouble isolating a small test case. I call the following code
> in an update tick:
>
> (let [prev'  @prev
>   state' @state]
>   (let [rems (clojure.set/difference prev' state')
> adds (clojure.set/difference state' prev')]
> (reset! prev state')
> (assert (= (count rems) (count (set rems))
>
> (prev and state hold sets of maps.)
>
> After running for a few minutes, the assert will fail. The 'rems' and
> 'adds' will report that their count is > 1, but when I try to access the
> elements there are either none or only one.
>
> What would cause a set to return an incorrect value for count?
>
> FWIW, the elements of the sets are maps, and one of the fields holds a
> mutable javascript array. That was my first suspicion, but the array isn't
> mutated in my code, and I use a memoized function to generate it (to
> preserve identity).
>
> I'm using [org.clojure/clojurescript "0.0-2202"].
>
> --
> 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 0.0-2227

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

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

New release version: 0.0-2227

Leiningen dependency information:

[org.clojure/clojurescript "0.0-2227"]

Enhancements

* optimized case
* CLJS-802: Add :pseudo-names compiler option
* CLJS-795: 10X performance enchancement for multimethods
* CLJS-801: str macro emits unoptimizable js code
* CLJS-656: search classpath for goog-style JavaScript dependencies

Fixes
-
* CLJS-792: Implement IReduce on PersistentArrayMap
* CLJS-804: Binding *print-length* breaks str
* CLJS-775: Fix cljs.reader cljs.reader parses radix form of int literals
* CLJS-805: add-watch returns map of watch fns instead of watched reference
* CLJS-787: cljs.reader does not read blank string as nil
* CLJS-784: Fix *Map.-conj for map-entry seqs, that don't implement INext
* CLJS-784: make conj on maps behave as it does in Clojure
* CLJS-793: fix memoize (non-truthy values don't get cached)
* CLJS-800: PersistentQueueSeq extended to IPrintWithWriter

-- 
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.match incorrect docstring?

[David Nolen]

Thanks for the report, docstring updated.

David


On Tue, May 27, 2014 at 5:16 PM, Dom Kiva-Meyer  wrote:

> The clojure.core.match/match docstring states that it takes "...a vector
> of occurrences, vars. Clause question-answer syntax is like `cond`.
> Questions must be wrapped in a vector..."
> https://github.com/clojure/core.match/blob/5429e20f5db8c398d745f15f7a85f65976f45397/src/main/clojure/clojure/core/match.clj#L1966-1976
>
> However, it seems to work without wrapping the occurrences and questions
> in vectors.
>
> (match [{:a 1 :b 2}]   [{:a 1 :b x}] x);;=> 2(match {:a 1 :b 2}   {:a 
> 1 :b x} x);;=> 2
>
> Is the docstring outdated or are there circumstances that necessitate
> wrapping the occurrence/s and question/s in vectors?
>
>
>
>  --
> 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: Clojure on iOS devices - Swift as a host?

[David Nolen]

I wouldn't pass judgement on Swift too soon. Eval works just fine in the
REPL and it appears the language supports hot code loads out of the box.
Swift also has real support for final fields via 'let'. I personally think
a ClojureSwift could be quite interesting :)

On Wednesday, June 4, 2014, Timothy Baldridge  wrote:

> I'm starting to feel like a broken record, but here we go.
>
> Some things to think about:
>
> 1) Why do you want this? The JVM GC and JIT are some of the fastest (if
> not the fastest) on the planet, so performance will never be a good reason
> to do this.
> 2) Do you want something like eval? As far as I can tell Swift is
> statically compiled. Only XCode has the ability to modify a program on the
> fly.
> 3) Clojure is highly polymorphic and dynamically typed. Walk the source
> code for first  and next and you'll find something like 3-4 polymorphic
> calls involved in something as simple as (doseq [x (range 100)]), per item.
> 4) I have yet to see performance numbers for Swifthow fast/slow is it
> compared to other languages?
>
> To put this all into perspective, I once translated LazySeq to C++ and ran
> some code (with a GC) that performed something like (doall (range 10)).
> The result was about 10x slower than Clojure on the JVM. So simply running
> something in C++/LLVM doesn't mean that you'll even get close to the
> performance of the JVM.
>
> Memory constrained systems might benefit from a LLVM Clojure. In addition
> there's room for improvement with the JVM's horrible warmup times. Python
> will boot instantly on most systems while the Clojure REPL takes about a
> minute to boot on the RPi. But aside form that, I can't see much of a
> point.
>
> If you want something like this there's always (
> https://github.com/galdolber/clojure-objc)
>
> Timothy
>
>
>
>
> On Wed, Jun 4, 2014 at 7:20 AM, Greg Knapp  > wrote:
>
>> The recent release of Swift made me revisit Clojure on LLVM. This post
>> from 2010
>> 
>> suggests it's a very difficult task.
>>
>> Swift would make this job easier? As with ClojureScript, generate Swift
>> code / provide interop and Clojurian's can produce native iOS apps?
>>
>> Perhaps the biggest hole to be filled would be tooling (Xcode is not
>> Clojure/Lisp friendly? i.e. no playground support)
>>
>> --
>> 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.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> 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.

ClojureScript & Clojure 1.6.0

[David Nolen]

Future releases of ClojureScript will have a hard dependency on Clojure
1.6.0. If you have any objections, speak up now :)

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 & Clojure 1.6.0

[David Nolen]

Clojure 1.6.0 introduced Murmur3 for much improved collection hashing and
several new functions & macros. There's very little incentive to continue
to support 1.5.X given these enhancements.

David


On Fri, Jun 6, 2014 at 11:48 AM, Joshua Ballanco 
wrote:

> No objection, but I’m curious what are the motivating factors? Are there
> any new features/bug-fixes planned for ClojureScript that will depend on
> Clojure 1.6.0 features? or is this just a case of keeping things as
> up-to-date as possible?
>
>
> On Friday, June 6, 2014 at 17:43, David Nolen wrote:
>
> > Future releases of ClojureScript will have a hard dependency on Clojure
> 1.6.0. If you have any objections, speak up now :)
> >
> > David
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Clojure Dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure-dev+unsubscr...@googlegroups.com (mailto:
> clojure-dev+unsubscr...@googlegroups.com).
> > To post to this group, send email to clojure-...@googlegroups.com
> (mailto:clojure-...@googlegroups.com).
> > Visit this group at http://groups.google.com/group/clojure-dev.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clojure Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to clojure-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojure-dev.
> 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: [ClojureScript] Re: ClojureScript & Clojure 1.6.0

[David Nolen]

My hope is that the GSoC analyzer work will allow ClojureScript and
projects like LT to share an analyzer without the hassle of conflicting
release cycles. Any help to expedite this decoupling is of course
appreciated.

David


On Fri, Jun 6, 2014 at 1:43 PM, Chris Granger  wrote:

> Since I doubt there'd be any others, I'll be the only dissenter ;)
>
> People already get mad Light Table requiring 1.5 since we use CLJS to do
> analysis and such. Bumping it up to 1.6 means it'd be a long time before we
> could move our version of CLJS again. Maybe that's not a real issue and
> really just an indication that we shouldn't be using the CLJS analyzer for
> this stuff anymore, but figured I should mention.
>
> Cheers,
> Chris.
>
>
> On Fri, Jun 6, 2014 at 10:37 AM, Mimmo Cosenza 
> wrote:
>
>> +1
>> mimmo
>>
>> On 06 Jun 2014, at 19:22, Andrey Antukh  wrote:
>>
>> +1
>>
>>
>> 2014-06-06 19:19 GMT+02:00 Karsten Schmidt :
>>
>>> +1
>>> On 6 Jun 2014 16:59, "David Nolen"  wrote:
>>>
>>>> Clojure 1.6.0 introduced Murmur3 for much improved collection hashing
>>>> and several new functions & macros. There's very little incentive to
>>>> continue to support 1.5.X given these enhancements.
>>>>
>>>> David
>>>>
>>>>
>>>> On Fri, Jun 6, 2014 at 11:48 AM, Joshua Ballanco >>> > wrote:
>>>>
>>>>> No objection, but I’m curious what are the motivating factors? Are
>>>>> there any new features/bug-fixes planned for ClojureScript that will 
>>>>> depend
>>>>> on Clojure 1.6.0 features? or is this just a case of keeping things as
>>>>> up-to-date as possible?
>>>>>
>>>>>
>>>>> On Friday, June 6, 2014 at 17:43, David Nolen wrote:
>>>>>
>>>>> > Future releases of ClojureScript will have a hard dependency on
>>>>> Clojure 1.6.0. If you have any objections, speak up now :)
>>>>> >
>>>>> > David
>>>>> >
>>>>> > --
>>>>> > You received this message because you are subscribed to the Google
>>>>> Groups "Clojure Dev" group.
>>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>>> send an email to clojure-dev+unsubscr...@googlegroups.com (mailto:
>>>>> clojure-dev+unsubscr...@googlegroups.com).
>>>>> > To post to this group, send email to clojure-...@googlegroups.com
>>>>> (mailto:clojure-...@googlegroups.com).
>>>>> > Visit this group at http://groups.google.com/group/clojure-dev.
>>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Clojure Dev" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to clojure-dev+unsubscr...@googlegroups.com.
>>>>> To post to this group, send email to clojure-...@googlegroups.com.
>>>>> Visit this group at http://groups.google.com/group/clojure-dev.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure Dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to clojure-dev+unsubscr...@googlegroups.com.
>>>> To post to this group, send email to clojure-...@googlegroups.com.
>>>> Visit this group at http://groups.google.com/group/clojure-dev.
>>>> 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 y

Re: ClojureScript & Clojure 1.6.0

[David Nolen]

Given the feedback so far such a request seems to be in the minority. You
could run a separate project for the CLJS parts. That said, is there
something in the latest release (0.0-2227) that you find problematic that
you can't continue with it?

David

On Fri, Jun 6, 2014 at 8:36 PM, Matching Socks  wrote:

>
> Can a lein-cljsbuild clj+cljs project specify separate versions of Clojure
> for the cljs and clj parts?
>
> If not, please give it another 6 months.
>
>
> On Friday, June 6, 2014 10:43:42 AM UTC-4, David Nolen wrote:
>>
>> Future releases of ClojureScript will have a hard dependency on Clojure
>> 1.6.0. If you have any objections, speak up now :)
>>
>> 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.
>

-- 
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 & Clojure 1.6.0

[David Nolen]

I don't think we want cut such a release just yet. I think it would be more
informative to understand what's holding people off of 1.6.0.

David


On Sat, Jun 7, 2014 at 4:42 PM, Joshua Ballanco 
wrote:

> At the risk of suggesting something completely heretical…
>
> Would it be possible to declare a v0.1 release before making the cut over
> to 1.6? At least then, if anyone were so inclined, those stuck on Clojure
> v1.5.1 for whatever reason could at least submit/backport critical
> bug-fixes for potential v0.1.1, etc. releases going forward.
>
>
>
>
>
>
> On Saturday, June 7, 2014 at 4:16, David Nolen wrote:
>
> > Given the feedback so far such a request seems to be in the minority.
> You could run a separate project for the CLJS parts. That said, is there
> something in the latest release (0.0-2227) that you find problematic that
> you can't continue with it?
> >
> > David
> >
> > On Fri, Jun 6, 2014 at 8:36 PM, Matching Socks  (mailto:phill.w...@gmail.com)> wrote:
> > >
> > > Can a lein-cljsbuild clj+cljs project specify separate versions of
> Clojure for the cljs and clj parts?
> > >
> > > If not, please give it another 6 months.
> > >
> > >
> > > On Friday, June 6, 2014 10:43:42 AM UTC-4, David Nolen wrote:
> > > > Future releases of ClojureScript will have a hard dependency on
> Clojure 1.6.0. If you have any objections, speak up now :)
> > > >
> > > > 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 (mailto:
> 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 (mailto:
> 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 (mailto:
> 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 Dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure-dev+unsubscr...@googlegroups.com (mailto:
> clojure-dev+unsubscr...@googlegroups.com).
> > To post to this group, send email to clojure-...@googlegroups.com
> (mailto:clojure-...@googlegroups.com).
> > Visit this group at http://groups.google.com/group/clojure-dev.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clojure Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to clojure-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojure-dev.
> 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: ClojureScript & Clojure 1.6.0

[David Nolen]

1.6.0 branch is ready to be tested
http://github.com/clojure/clojurescript/tree/1.6.0, please give it a try in
your projects. You can install this version of ClojureScript by

* checking out the repo
* git checkout 1.6.0
* ./script/install

Take note of the version number that gets installed into your local Maven.
Use this in version number in your project.

David


On Fri, Jun 6, 2014 at 10:43 AM, David Nolen  wrote:

> Future releases of ClojureScript will have a hard dependency on Clojure
> 1.6.0. If you have any objections, speak up now :)
>
> 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 & Clojure 1.6.0

[David Nolen]

That's great to hear, the feedback is much appreciated.

David

On Mon, Jun 9, 2014 at 1:06 PM, Karsten Schmidt  wrote:
> Hi David, this is great! I've switched to this branch, updated all hashing
> impls of deftypes in my library and it works without a hitch and see much
> less hash collisions in large 3d meshes as a result. Awesome!
>
> K.
>
> On 8 Jun 2014 18:07, "David Nolen"  wrote:
>>
>> 1.6.0 branch is ready to be tested
>> http://github.com/clojure/clojurescript/tree/1.6.0, please give it a try in
>> your projects. You can install this version of ClojureScript by
>>
>> * checking out the repo
>> * git checkout 1.6.0
>> * ./script/install
>>
>> Take note of the version number that gets installed into your local Maven.
>> Use this in version number in your project.
>>
>> David
>>
>>
>> On Fri, Jun 6, 2014 at 10:43 AM, David Nolen 
>> wrote:
>>>
>>> Future releases of ClojureScript will have a hard dependency on Clojure
>>> 1.6.0. If you have any objections, speak up now :)
>>>
>>> David
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Clojure Dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure-dev+unsubscr...@googlegroups.com.
>> To post to this group, send email to clojure-...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/clojure-dev.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clojure Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to clojure-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojure-dev.
> 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: [ClojureScript] Re: ClojureScript & Clojure 1.6.0

[David Nolen]

Looks like new warnings from the Closure Compiler - something for
core.async to address. Thanks for the report!

David

On Tue, Jun 10, 2014 at 12:55 AM, Yehonathan Sharvit  wrote:
>
>
> I have compilation warnings related to core.async. Here is the log:
>
> Compiling "resources/public/js/main.js" from ["src/cljs"]...
> Jun 10, 2014 7:49:49 AM com.google.javascript.jscomp.LoggerErrorManager 
> println
> WARNING: 
> /Users/viebel/libs/klozzer/target/cljsbuild-compiler-0/cljs/core/async.js:127:
>  WARNING - unreachable code
> {return null;
> ^
>
> Jun 10, 2014 7:49:49 AM com.google.javascript.jscomp.LoggerErrorManager 
> println
> WARNING: 
> /Users/viebel/libs/klozzer/target/cljsbuild-compiler-0/cljs/core/async.js:178:
>  WARNING - unreachable code
> {return null;
> ^
>
> Jun 10, 2014 7:49:49 AM com.google.javascript.jscomp.LoggerErrorManager 
> println
> WARNING: 
> /Users/viebel/libs/klozzer/target/cljsbuild-compiler-0/cljs/core/async.js:420:
>  WARNING - unreachable code
> {return null;
> ^
>
> Jun 10, 2014 7:49:49 AM com.google.javascript.jscomp.LoggerErrorManager 
> println
> WARNING: 
> /Users/viebel/libs/klozzer/target/cljsbuild-compiler-0/cljs/core/async/impl/ioc_helpers.js:353:
>  WARNING - unreachable code
> {return null;
> ^
>
> Jun 10, 2014 7:49:49 AM com.google.javascript.jscomp.LoggerErrorManager 
> printSummary
> WARNING: 0 error(s), 4 warning(s)
>
> On Monday, 9 June 2014 20:07:48 UTC+3, David Nolen  wrote:
>> That's great to hear, the feedback is much appreciated.
>>
>>
>>
>> David
>>
>>
>>
>> On Mon, Jun 9, 2014 at 1:06 PM, Karsten Schmidt  wrote:
>>
>> > Hi David, this is great! I've switched to this branch, updated all hashing
>>
>> > impls of deftypes in my library and it works without a hitch and see much
>>
>> > less hash collisions in large 3d meshes as a result. Awesome!
>>
>> >
>>
>> > K.
>>
>> >
>>
>> > On 8 Jun 2014 18:07, "David Nolen"  wrote:
>>
>> >>
>>
>> >> 1.6.0 branch is ready to be tested
>>
>> >> http://github.com/clojure/clojurescript/tree/1.6.0, please give it a try 
>> >> in
>>
>> >> your projects. You can install this version of ClojureScript by
>>
>> >>
>>
>> >> * checking out the repo
>>
>> >> * git checkout 1.6.0
>>
>> >> * ./script/install
>>
>> >>
>>
>> >> Take note of the version number that gets installed into your local Maven.
>>
>> >> Use this in version number in your project.
>>
>> >>
>>
>> >> David
>>
>> >>
>>
>> >>
>>
>> >> On Fri, Jun 6, 2014 at 10:43 AM, David Nolen 
>>
>> >> wrote:
>>
>> >>>
>>
>> >>> Future releases of ClojureScript will have a hard dependency on Clojure
>>
>> >>> 1.6.0. If you have any objections, speak up now :)
>>
>> >>>
>>
>> >>> David
>>
>> >>
>>
>> >>
>>
>> >> --
>>
>> >> You received this message because you are subscribed to the Google Groups
>>
>> >> "Clojure Dev" group.
>>
>> >> To unsubscribe from this group and stop receiving emails from it, send an
>>
>> >> email to clojure-dev+unsubscr...@googlegroups.com.
>>
>> >> To post to this group, send email to clojure-...@googlegroups.com.
>>
>> >> Visit this group at http://groups.google.com/group/clojure-dev.
>>
>> >> For more options, visit https://groups.google.com/d/optout.
>>
>> >
>>
>> > --
>>
>> > You received this message because you are subscribed to the Google Groups
>>
>> > "Clojure Dev" group.
>>
>> > To unsubscribe from this group and stop receiving emails from it, send an
>>
>> > email to clojure-dev+unsubscr...@googlegroups.com.
>>
>> > To post to this group, send email to clojure-...@googlegroups.com.
>>
>> > Visit this group at http://groups.google.com/group/clojure-dev.
>>
>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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 http://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: solving an equation for all solutions with constraints: core.logic.fd

[David Nolen]

That's that's the suggested way - just pick a large bound.

David

On Tue, Jun 10, 2014 at 11:28 AM, cej38  wrote:
> I found the solution to my first problem at
> https://github.com/clojure/core.logic/wiki/Features (with a few small
> changes by me):
>
> (run* [q]
>   (fresh [x y]
> (fd/in x y (fd/interval 0 9))
> (fd/eq
>   (= (+ (* x 3) (* y 2)) 8))
> (== q [x y])))
>
>
> I suppose that I could set (fd/interval 0 9) to do a fair
> approximation of the non-negative integers, but out of curiosity, would
> there be a better way of doing this?
>
>
>
> On Tuesday, June 10, 2014 11:12:11 AM UTC-4, cej38 wrote:
>>
>> I am interested in solving a simple equation for all of its solutions when
>> some constraints are applied.  This sounds like a problem for core.logic.fd.
>>
>> Let's use a toy example:
>>
>> 8 = 3*x + 2*y,  where x and y must be non-negative integers.
>>
>> Here are the possible solutions:  [x,y]= {[2,1],[0,4]}.
>>
>>
>> I tried something like this:
>>
>> (run* [q]
>>   (fresh [x y]
>>  (== q [x y])
>>(project [x y]
>>   (fd/+ (* x 2) (y 3) 8
>>
>> But I get a exception:
>> "java.lang.ClassCastException: clojure.core.logic.LVar cannot be cast to
>> java.lang.Number"
>>
>> So I have two questions:
>> 1. How should I rewrite the above command to get the solutions?
>> 2. Are there any good blog posts/online presentations/etc. on
>> core.logic.fd?
>>
>>
>>
> --
> 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: solving an equation for all solutions with constraints: core.logic.fd

[David Nolen]

core.logic only currently supports solving finite domains CLP(FD),
you'll have to look elsewhere for a CLP(R) solver for now.

David

On Tue, Jun 10, 2014 at 5:30 PM, cej38  wrote:
> I picked a toy problem that was really easy to solve, figuring that once I
> had the idea down, I would be able to easily change the equation to the one
> that I am interested in solving.  In moving to my real problem I hit the
> next snag I can't use real numbers within the equation.  I note that the
> equation hasn't changed, the values of x and y are still non-negative
> integers.
>
> (run* [q]
>   (fresh [x y]
> (fd/in x y (fd/interval 0 9))
> (fd/eq
>   (= (+ (* x 3.) (* y 2.)) 8.))
> (== q [x y])))
>
> In my real problem I expect that I could have something like
>
> (run* [q]
>   (fresh [x y]
> (fd/in x y (fd/interval 0 9))
> (fd/eq
>   (= (+ (* x 3.) (* y 2.)) 8.))
> (== q [x y])))
>
> Is there away to do this?
>
> --
> 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 0.0-2234

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

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

New release version: 0.0-2234

Leiningen dependency information:

[org.clojure/clojurescript "0.0-2234"]

This release fixes a critical bug around the `case` statement. This
will be the last ClojureScript release before we move to support only
Clojure 1.6.0.

## 0.0-2234

### Fixes
* CLJS-812: Recur from case statement generated invalid JavaScript
* CLJS-811: use the correct class loader in cljs.js-deps/goog-resource
* fix fns with metadata under advanced compilation
* CLJS-809: dissoc :file metadata introduced by tools.reader 0.8.4
* mark cljs.reader vars as ^:dynamic to avoid compiler 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: ClojureScript ^:export defprotocol

[David Nolen]

On iOS is advanced compilation really necessary? :simple + :static-fns true
should suffice.

On Wednesday, June 18, 2014, Mike Fikes  wrote:

> Is there a way to indicate that a (ClojureScript) protocol is intended to
> be used from the host?
>
> Details:
>
> I can define a protocol and an implementation of it in ClojureScript using
> defprotocol and reify.
>
> I can also successfully call methods on reified instances returned to the
> host (Obj-C embedding JavaScriptCore on iOS).
>
> The method names are mangled: In addition to the expected and usual
> conversion of hyphens to underscores, the mangled names incorporate dollar
> signs ($) and arity encoding, an example of which is:
>
>   my$full$ns$MyProtocol$a_method_defined_in_this_protocol$arity$1
>
> This can be called, passing this mangled string in as the method name of 
> JSValue
> -invokeMethod:withArguments:.
>
> All cool (so long as this mangling is stable from one ClojureScript
> release to the next—but it smells like the mangling could be an
> implementation detail, subject to change).
>
> The killer is if I turn on Google Closure advanced optimizations; these
> mangled names get renamed.
>
> Is there a way to indicate the protocol names should be preserved?
> (Analogous to the way ^:export can be used on function definitions.)
>
> --
> 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 0.0-1885 (Source maps!)

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

The biggest change in this release thanks to Sean Grove - much improved
source maps. You can provide a :source-map option to the compiler to name
the source map file. Feedback on this significant enhancement welcome.

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

New release version: 0.0-1885

Leiningen dependency information:

[org.clojure/clojurescript "0.0-1885"]

*Enhancements: *
* Accurate source maps!

*Changes:*
** *cljs.core/format based on goog.string/format backed out
* set-print-fn! no longer exported

*Fixes:*
** *CLJS-588: allow upstream :foreign-libs to be used

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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 0.0-1885 (Source maps!)

[David Nolen]

1889 released, all changes are to make it easier to test the source map
functionality. I've blogged some basic instructions here
http://swannodette.github.io/2013/09/15/source-maps/

Feedback welcome!


On Sun, Sep 15, 2013 at 2:48 PM, David Nolen  wrote:

> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> The biggest change in this release thanks to Sean Grove - much improved
> source maps. You can provide a :source-map option to the compiler to name
> the source map file. Feedback on this significant enhancement welcome.
>
> README and source code: https://github.com/clojure/clojurescript
>
> New release version: 0.0-1885
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "0.0-1885"]
>
> *Enhancements: *
> * Accurate source maps!
>
> *Changes:*
> ** *cljs.core/format based on goog.string/format backed out
> * set-print-fn! no longer exported
>
> *Fixes:*
> ** *CLJS-588: allow upstream :foreign-libs to be used
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to 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 0.0-1885 (Source maps!)

[David Nolen]

Nicola Mometto also deserves quite a bit of credit, the fact that
tools.reader emits line and column information on all symbols is essential
for the accuracy of ClojureScript source maps.


On Mon, Sep 16, 2013 at 1:58 AM, Marco Munizaga  wrote:

> I'm so happy for this, I've been subscribed to that issue on Jira for a
> while now, and here it is, alive and working! Just ran some demo code and
> it looks amazing! Thanks Sean Grove and thanks David Nolen. I'll let you
> know about any bugs I find.
> On Sunday, September 15, 2013 2:48:46 PM UTC-4, David Nolen wrote:
> > ClojureScript, the Clojure compiler that emits JavaScript source code.
> >
> >
> >
> > The biggest change in this release thanks to Sean Grove - much improved
> source maps. You can provide a :source-map option to the compiler to name
> the source map file. Feedback on this significant enhancement welcome.
> >
> >
> > README and source code: https://github.com/clojure/clojurescript
> >
> >
> > New release version: 0.0-1885
> >
> >
> > Leiningen dependency information:
> >
> > [org.clojure/clojurescript "0.0-1885"]
> >
> >
> >
> >
> > Enhancements:
> >
> > * Accurate source maps!
> >
> >
> > Changes:
> >
> > * cljs.core/format based on goog.string/format backed out
> > * set-print-fn! no longer exported
> >
> >
> >
> > Fixes:
> > * CLJS-588: allow upstream :foreign-libs to be used
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 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] ANN: ClojureScript 0.0-1885 (Source maps!)

[David Nolen]

Use goog.string.format.

David


On Mon, Sep 16, 2013 at 11:35 AM, Joe Smith  wrote:

> I see that clojure.core/format is gone. Is there a replacement/alternative?
>
> ---
> Joseph Smith
> j...@uwcreations.com
> @solussd
>
>
>
>
>
>
> On Sep 16, 2013, at 7:31 AM, David Nolen  wrote:
>
> Nicola Mometto also deserves quite a bit of credit, the fact that
> tools.reader emits line and column information on all symbols is essential
> for the accuracy of ClojureScript source maps.
>
>
> On Mon, Sep 16, 2013 at 1:58 AM, Marco Munizaga wrote:
>
>> I'm so happy for this, I've been subscribed to that issue on Jira for a
>> while now, and here it is, alive and working! Just ran some demo code and
>> it looks amazing! Thanks Sean Grove and thanks David Nolen. I'll let you
>> know about any bugs I find.
>> On Sunday, September 15, 2013 2:48:46 PM UTC-4, David Nolen wrote:
>> > ClojureScript, the Clojure compiler that emits JavaScript source code.
>> >
>> >
>> >
>> > The biggest change in this release thanks to Sean Grove - much improved
>> source maps. You can provide a :source-map option to the compiler to name
>> the source map file. Feedback on this significant enhancement welcome.
>> >
>> >
>> > README and source code: https://github.com/clojure/clojurescript
>> >
>> >
>> > New release version: 0.0-1885
>> >
>> >
>> > Leiningen dependency information:
>> >
>> > [org.clojure/clojurescript "0.0-1885"]
>> >
>> >
>> >
>> >
>> > Enhancements:
>> >
>> > * Accurate source maps!
>> >
>> >
>> > Changes:
>> >
>> > * cljs.core/format based on goog.string/format backed out
>> > * set-print-fn! no longer exported
>> >
>> >
>> >
>> > Fixes:
>> > * CLJS-588: allow upstream :foreign-libs to be used
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to 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.
>>
>
>
> --
> 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 http://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/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: Weird core.async/ClojureScript not workings...

[David Nolen]

Which versions of ClojureScript and core.async are you using?

David


On Mon, Sep 16, 2013 at 5:25 PM, David Pollak  wrote:

> Howdy,
>
> I'm using core.async and ClojureScript and it seems that inside a go
> block, if/when/loop/while code is never executed.
>
> For example:
>
>   (def dog33 (go (if true (.log js/console "it's true") (.log js/console
> "it's false"
>
> prints neither "it's true" nor "it's false", but
>
>   (def dog33 (go (do (.log js/console "it's true") (.log js/console "it's
> false"
>
> prints both.
>
> I'm doing lein cljsbuild auto to generate the JavaScript.
>
> Any pointers would be appreciated.
>
> Thanks,
>
> David
>
> --
> Brick Alloy http://brickalloy. 
> Lift, the simply functional web framework http://liftweb.net
> Follow me: http://twitter.com/dpp
> Blog: http://goodstuff.im
>
>  --
> --
> 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: Weird core.async/ClojureScript not workings...

[David Nolen]

Won't work you need core.async master. The next core.async release will fix
the issue.

David


On Tue, Sep 17, 2013 at 1:17 AM, David Pollak  wrote:

> [org.clojure/clojurescript "0.0-1878"]
> [org.clojure/core.async "0.1.222.0-83d0c2-alpha"]
>
> [[lein-cljsbuild "0.3.2"]]
>
>
> On Mon, Sep 16, 2013 at 3:32 PM, David Nolen wrote:
>
>> Which versions of ClojureScript and core.async are you using?
>>
>> David
>>
>>
>> On Mon, Sep 16, 2013 at 5:25 PM, David Pollak <
>> feeder.of.the.be...@gmail.com> wrote:
>>
>>> Howdy,
>>>
>>> I'm using core.async and ClojureScript and it seems that inside a go
>>> block, if/when/loop/while code is never executed.
>>>
>>> For example:
>>>
>>>   (def dog33 (go (if true (.log js/console "it's true") (.log js/console
>>> "it's false"
>>>
>>> prints neither "it's true" nor "it's false", but
>>>
>>>   (def dog33 (go (do (.log js/console "it's true") (.log js/console
>>> "it's false"
>>>
>>> prints both.
>>>
>>> I'm doing lein cljsbuild auto to generate the JavaScript.
>>>
>>> Any pointers would be appreciated.
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> --
>>> Brick Alloy http://brickalloy. <https://telegr.am>
>>> Lift, the simply functional web framework http://liftweb.net
>>> Follow me: http://twitter.com/dpp
>>> Blog: http://goodstuff.im
>>>
>>>  --
>>> --
>>> 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.
>>
>
>
>
> --
> Brick Alloy http://brickalloy.com <https://telegr.am>
> Lift, the simply functional web framework http://liftweb.net
> Follow me: http://twitter.com/dpp
> Blog: http://goodstuff.im
>
>  --
> --
> 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: Weird core.async/ClojureScript not workings...

[David Nolen]

Works fine for me using core.async master. I just ran `lein install` from
the core.async directory and changed project.clj core.async to:

[core.async "0.1.0-SNAPSHOT"]

David


On Mon, Sep 16, 2013 at 11:29 PM, Keith Irwin  wrote:

> I'm having the same issue.
>
> Here's a project with a "timeout" loop demonstrating the problem:
>
>https://github.com/zentrope/clock
>
> Using core.async SNAPSHOT and any clojurescript release after 1859 seems
> to break along the same lines as the OP.
>
> Other elements I have going:
>
>  - cljsbuild 0.3.3
>  - prismatic 0.1.2
>
> but they don't seem to cause issues with 1859. If you've got any tips on
> using core.async master (maybe using lein's checkout feature?) I wouldn't
> mind trying that.
>
> On Sep 16, 2013, at 3:32 PM, David Nolen  wrote:
>
> Which versions of ClojureScript and core.async are you using?
>
> David
>
>
> On Mon, Sep 16, 2013 at 5:25 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>> Howdy,
>>
>> I'm using core.async and ClojureScript and it seems that inside a go
>> block, if/when/loop/while code is never executed.
>>
>> For example:
>>
>>   (def dog33 (go (if true (.log js/console "it's true") (.log js/console
>> "it's false"
>>
>> prints neither "it's true" nor "it's false", but
>>
>>   (def dog33 (go (do (.log js/console "it's true") (.log js/console "it's
>> false"
>>
>> prints both.
>>
>> I'm doing lein cljsbuild auto to generate the JavaScript.
>>
>> Any pointers would be appreciated.
>>
>> Thanks,
>>
>> David
>>
>> --
>> Brick Alloy http://brickalloy. <https://telegr.am/>
>> Lift, the simply functional web framework http://liftweb.net
>> Follow me: http://twitter.com/dpp
>> Blog: http://goodstuff.im
>>
>>
>> --
>> --
>> 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.

ANN: core.match 0.2.0-rc6

[David Nolen]

I believe this release finally eliminates all the remaining bugs around
AOT. Will likely be the final release candidate.

http://github.com/clojure/core.match

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

Re: GSoC Report: Expresso, symbolic manipulation of Algebraic Expressions in clojure

[David Nolen]

Impressive work congrats!


On Mon, Sep 23, 2013 at 11:38 AM, Maik Schünemann  wrote:

> GSoC ends today and I can announce the 0.2.0 version of the expresso [1]
> library.
> It is build on top of core.logic and core.matrix and provides symbolic
> manipulation of algebraic expressions.
>
> What's there?
> 1. An api/dsl for manipulation of algebraic expressions which doesn't get
> in your way. Expresso's expressions are
>just clojure s-expressions and can be manipulated with rich set of
> clojure sequence functions
> 2. useful manipulations for mathematical expressions: simplify,
> multiply-out, differentiate, ...
> 3. An equation solver which is capable of solving a single equation and
> multiple equations for unknowns.
> 4. An optimizer which transforms a mathematical expression to a
> semantically equivalent but performanter one
> 5. An expression compiler to compile an expression to an efficient clojure
> function
> 6. A semantic rule based translator on top of which many of expresso's
> features are implemented
>
> The code is fully documented and I wrote a tutorial and showcase of
> expresso, the expresso-tutorial [2].
>
> GSoC has been a really fun and valuable time for me. I learned a lot. Of
> course I will continue developing expresso!
> Expresso and core.matrix are the first steps in the direction of a full
> computer algebra system for clojure. I hope that it will help clojure to be
> an attractive choice for scientific computing projects in the future.
>
> Showcase:
> Here are two examples of expresso's facility to manipulate mathematical
> expressions. They can be found and are explained in the expresso-tutorial
> [2].
>
> 1. solving word problems:
>
> (solve 'blue
>   (ex (= pencils (+ green white blue red)))
>   (ex (= (/ pencils 10) green))
>   (ex (= (/ pencils 2) white))
>   (ex (= (/ pencils 4) blue))
>   (ex (= red 45))) ;=> #{{blue 75N}}
>
>
> 2. Analyzing roots and extremata of functions. This code shows how easy
> one can implement tasks involving symbolic manipulation with expresso:
>
> (defn roots
>   "returns the set of roots of the expression in regard to var"
>   [var expr]
>   (solve var (ex (= ~expr 0
>
>
> (defn extremata
>   "gets the extrema of the expression in regard to var. Returns a map with the
>keys :maxima and :minima"
>   [var expr]
>   (let [d1 (differentiate [var] expr)
> d2 (differentiate [var] d1)
> candidates (roots var d1)]
> (if (seq candidates)
>   (let [extremata
> (->> candidates
>  (map (fn [candidate] [candidate (evaluate d2 {var 
> candidate})]))
>  (remove #(== 0 (second %)))
>  (group-by #(< 0 (second %]
> {:maxima (map first (get extremata false))
>  :minima (map first (get extremata true))}
>
>
> (defn analyse-function
>   "returns a map with the :roots, the :maxima and the :minima of the 
> expression
>in regard to var"
>   [var expr]
>   (assoc (extremata var expr)
> :roots (roots var expr)))
>
> (analyse-function 'x (ex (- (** x 4) (** x 2
> ;=> {:roots #{0 -1 1},
> ;;   :maxima (0),
> ;;   :minima (0.7071067811865476 -0.7071067811865476)}
>
>
> Ideas/feedbacks etc are greatly appreciated!
> Enjoy,
> Maik
>
> [1] https://github.com/clojure-numerics/expresso
> [2] https://github.com/mschuene/expresso-tutorial
>
> --
> --
> 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.

ANN: ClojureScript 0.0-1909

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

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

New release version: 0.0-1909

Leiningen dependency information:

[org.clojure/clojurescript "0.0-1909"]

*Breaking Changes: *
* Bump data.json to 0.2.3 and tools.reader to 0.7.8

*Enhancements: *
* Use tools.reader everywhere, pass file information allowing errors at
read time to give accurate locations

*Fixes:*
** *CLJS-595: keyword invoke default bug
* CLJS-594: declare divide so accidental redeclaration is caught
* CLJS-599: keyword fn not idempotent
* CLJS-587: stack overflow on lazy seqs

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

[David Nolen]

Oops bumping data.json and tools.reader are not breaking changes! :)


On Fri, Sep 27, 2013 at 1:00 PM, David Nolen  wrote:

> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> New release version: 0.0-1909
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "0.0-1909"]
>
> *Breaking Changes: *
> * Bump data.json to 0.2.3 and tools.reader to 0.7.8
>
> *Enhancements: *
> * Use tools.reader everywhere, pass file information allowing errors at
> read time to give accurate locations
>
> *Fixes:*
> ** *CLJS-595: keyword invoke default bug
> * CLJS-594: declare divide so accidental redeclaration is caught
> * CLJS-599: keyword fn not idempotent
> * CLJS-587: stack overflow on lazy seqs
>

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

ANN: core.match 0.2.0

[David Nolen]

No change since the last release candidate.

http://github.com/clojure/core.match

Have fun!

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: [ANN] cljsfiddle.net

[David Nolen]

Wow, awesome. Yes to core.async support, there was a release yesterday with
new goodies for Clojure and ClojureScript.

David


On Sat, Sep 28, 2013 at 6:24 AM, Jonas  wrote:

> Hi
>
> I’m working on a ClojureScript playground application (
> http://cljsfiddle.net) similar to jsfiddle[1], jsbin[2] etc. The app has
> now reached a point where I’m happy to show it to a wider audience.
>
> I’m hoping cljsfiddle.net will be used for:
> * Personal/collaborative experiments
> * ClojureScript Demos
> * Teaching Clojure(Script)
> * Single page (client only) web apps (such as games)
> * etc.
>
> A short list of (current) features:
> * Write and run ClojureScript programs without leaving your browser.
> * Save your work for later or share with the rest of the ClojureScript
> community.
> * Use popular cljs libraries by ‘require’ them in your ns declaration.
> - Currently available: domina, dommy, hiccups, core.match, core.logic
> * core.async is available but will probably not work yet. I’ll be working
> on this.
> * You can also require namespaces you (or someone else) previously wrote.
> This means you can develop utility libraries specifically designed to be
> used on cljsfiddle.net. (Example: [3])
> * Link to a specific namespace showing only the final html result of your
> work (great for demo purposes and other pure-client apps). (Example: [4])
>
> I’m quite happy with how the site works and I’m looking forward to your
> feedback. If you find any bugs or other problems please file a bug report
> on github[5]. Also, any help with the UI design would be most appreciated
> as I think it can be substantially improved.
>
> The very first time you run a program on cljsfiddle it will take a while
> to compile and load all the dependencies, subsequent runs should be much
> faster thanks to HTTP caching. Once the deps are cached the
> edit/compile/run cycle should be very fast.
>
> I’ve tested the site on chrome and firefox. It will currently not work
> with firefox version 24 or older, so if you’re a firefox user you must
> upgrade to firefox 25.
>
> Happy Hacking,
> Jonas
>
> [1] http://jsfiddle.net/
> [2] http://jsbin.com/
> [3] http://cljsfiddle.net/fiddle/jonase.bezier
> [4] http://cljsfiddle.net/view/jonase.snake
> [5] http://github.com/jonase/cljsfiddle
>
>  --
> --
> 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: [ANN] cljsfiddle.net

[David Nolen]

Just gave it a spin http://cljsfiddle.net/fiddle/swannodette.test-logic

Great work. Is there anyway to turn on parentheses matching on in
CodeMirror? Even better if Code Mirror can highlight unbalanced parens.

(Using it also makes me realize that ClojureScript should really provide a
way to collect warnings as data )

David


On Sat, Sep 28, 2013 at 6:24 AM, Jonas  wrote:

> Hi
>
> I’m working on a ClojureScript playground application (
> http://cljsfiddle.net) similar to jsfiddle[1], jsbin[2] etc. The app has
> now reached a point where I’m happy to show it to a wider audience.
>
> I’m hoping cljsfiddle.net will be used for:
> * Personal/collaborative experiments
> * ClojureScript Demos
> * Teaching Clojure(Script)
> * Single page (client only) web apps (such as games)
> * etc.
>
> A short list of (current) features:
> * Write and run ClojureScript programs without leaving your browser.
> * Save your work for later or share with the rest of the ClojureScript
> community.
> * Use popular cljs libraries by ‘require’ them in your ns declaration.
> - Currently available: domina, dommy, hiccups, core.match, core.logic
> * core.async is available but will probably not work yet. I’ll be working
> on this.
> * You can also require namespaces you (or someone else) previously wrote.
> This means you can develop utility libraries specifically designed to be
> used on cljsfiddle.net. (Example: [3])
> * Link to a specific namespace showing only the final html result of your
> work (great for demo purposes and other pure-client apps). (Example: [4])
>
> I’m quite happy with how the site works and I’m looking forward to your
> feedback. If you find any bugs or other problems please file a bug report
> on github[5]. Also, any help with the UI design would be most appreciated
> as I think it can be substantially improved.
>
> The very first time you run a program on cljsfiddle it will take a while
> to compile and load all the dependencies, subsequent runs should be much
> faster thanks to HTTP caching. Once the deps are cached the
> edit/compile/run cycle should be very fast.
>
> I’ve tested the site on chrome and firefox. It will currently not work
> with firefox version 24 or older, so if you’re a firefox user you must
> upgrade to firefox 25.
>
> Happy Hacking,
> Jonas
>
> [1] http://jsfiddle.net/
> [2] http://jsbin.com/
> [3] http://cljsfiddle.net/fiddle/jonase.bezier
> [4] http://cljsfiddle.net/view/jonase.snake
> [5] http://github.com/jonase/cljsfiddle
>
>  --
> --
> 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.

ANN: ClojureScript 0.0-1913

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

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

New release version: 0.0-1913

Leiningen dependency information:

[org.clojure/clojurescript "0.0-1913"]

*Enhancements: *
* Under incremental compilation reset the namespace for the file, this way
you get var warnings for example when functions get renamed
* ns refers and uses for libs and macros are now checked - warning now
issued if var does not exist

*Fixes:*
** *CLJS-600 & CLJS-604: LazySeq regression

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: Question about vector-of

[David Nolen]

Not that I'm aware of.

On Thursday, October 10, 2013, Mark Engelberg wrote:

> (def a (conj (vector-of :long) 1 2 3)
> (inc (a 1))
>
> Is Clojure smart enough to figure out that (a 1) is a primitive long and
> call the fast primitive version of 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 '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: core.match on a set

[David Nolen]

There's currently no support for matching sets and I have no plans in the
near future. Patch welcome, it could be matched and optimized similarly to
map matching.

On Thursday, October 10, 2013, Phillip Lord wrote:

>
> I've been playing with core.match recently. One thing that I am confused
> about is, I cannot match over a set (based on membership), unless I
> convert into a map first.
>
> So, for example
>
> (defn map-set [set]
>   (into {}
> (for [k set]
>   [k k])))
>
> (let [x (map-set #{:a :b :c})]
>   (match
>[x]
>[{:a _ :b _}] 'match_a_b
>:else nil))
>
>
> returns 'match_a_b
>
> Both of these...
>
> (let [y #{:a :b :c}]
>   (match
>[y]
>[{:a _ :b _}] 'match_a_b
>:else nil))
>
> (let [z #{:a :b :c}]
>   (match
>[z]
>[#{:a :b}] 'match_a_b
>:else nil))
>
> returns nil. Am I missing something obvious?
>
> Phil
>
> --
> --
> 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: Question about vector-of

[David Nolen]

(a 1) will return a boxed value and (long (a 1)) will just cast it back to
a primitive. There is currently no way to efficiently deal with the
contents of gvecs. Their inclusion at this point is mostly about saving
memory.

In theory reducers could allow a primitive fn to do efficient work "inside".

As far as getting a particular element without boxing, I don't see a way to
do that without implementing some interface like nthLong, nthDouble etc.
Maybe invokeDynamic could help here in the future?

David


On Thu, Oct 10, 2013 at 11:38 AM, Mark Engelberg
wrote:

> So do you just do:
> (inc (long (a 1))), i.e., manually converting to long primitive?  Is there
> much overhead for that call, if it is already a primitive?
>
> To the best of my knowledge, you can't do:
> (let [^long x (a 1)] (inc x))
> because I think primitive type hints only work in function headers.  Is
> that correct?
>
> Thanks,
>
> Mark
>
>
>
>
>
> On Thu, Oct 10, 2013 at 5:09 AM, David Nolen wrote:
>
>> Not that I'm aware of.
>>
>>
>> On Thursday, October 10, 2013, Mark Engelberg wrote:
>>
>>> (def a (conj (vector-of :long) 1 2 3)
>>> (inc (a 1))
>>>
>>> Is Clojure smart enough to figure out that (a 1) is a primitive long and
>>> call the fast primitive version of 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
>>> 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: Question about vector-of

[David Nolen]

(a 1) will return a boxed value and (long (a 1)) will just cast it back to
a primitive. There is currently no way to efficiently deal with the
contents of gvecs. Their inclusion at this point is mostly about saving
memory.

In theory reducers could allow a primitive fn to do efficient work "inside".

As far as getting a particular element without boxing, I don't see a way to
do that without implementing some interface that supports nthLong,
nthDouble etc.

David


On Thu, Oct 10, 2013 at 11:38 AM, Mark Engelberg
wrote:

> So do you just do:
> (inc (long (a 1))), i.e., manually converting to long primitive?  Is there
> much overhead for that call, if it is already a primitive?
>
> To the best of my knowledge, you can't do:
> (let [^long x (a 1)] (inc x))
> because I think primitive type hints only work in function headers.  Is
> that correct?
>
> Thanks,
>
> Mark
>
>
>
>
>
> On Thu, Oct 10, 2013 at 5:09 AM, David Nolen wrote:
>
>> Not that I'm aware of.
>>
>>
>> On Thursday, October 10, 2013, Mark Engelberg wrote:
>>
>>> (def a (conj (vector-of :long) 1 2 3)
>>> (inc (a 1))
>>>
>>> Is Clojure smart enough to figure out that (a 1) is a primitive long and
>>> call the fast primitive version of 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
>>> 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: core.match on a set

[David Nolen]

The only reason it's not currently in there is I've never considered it.
The reason I have no near terms plans for it, lack of time.

On Friday, October 11, 2013, Phillip Lord wrote:

>
> Just out of curiosity why? Or am I just wierd in wanting this?
>
> I'll have a look, and see if I can offer a patch, though.
>
> Phil
>
> David Nolen > writes:
>
> > There's currently no support for matching sets and I have no plans in the
> > near future. Patch welcome, it could be matched and optimized similarly
> to
> > map matching.
> >
> > On Thursday, October 10, 2013, Phillip Lord wrote:
> >
> >>
> >> I've been playing with core.match recently. One thing that I am confused
> >> about is, I cannot match over a set (based on membership), unless I
> >> convert into a map first.
> >>
> >> So, for example
> >>
> >> (defn map-set [set]
> >>   (into {}
> >> (for [k set]
> >>   [k k])))
> >>
> >> (let [x (map-set #{:a :b :c})]
> >>   (match
> >>[x]
> >>[{:a _ :b _}] 'match_a_b
> >>:else nil))
> >>
> >>
> >> returns 'match_a_b
> >>
> >> Both of these...
> >>
> >> (let [y #{:a :b :c}]
> >>   (match
> >>[y]
> >>[{:a _ :b _}] 'match_a_b
> >>:else nil))
> >>
> >> (let [z #{:a :b :c}]
> >>   (match
> >>[z]
> >>[#{:a :b}] 'match_a_b
> >>:else nil))
> >>
> >> returns nil. Am I missing something obvious?
> >>
> >> Phil
> >>
> >> --
> >> --
> >> 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.
> >>
> >
> > --
>
> --
> Phillip Lord,   Phone: +44 (0) 191 222 7827
> Lecturer in Bioinformatics, Email:
> phillip.l...@newcastle.ac.uk 
> School of Computing Science,
> http://homepages.cs.ncl.ac.uk/phillip.lord
> Room 914 Claremont Tower,   skype: russet_apples
> Newcastle University,   twitter: phillord
> NE1 7RU
>
> --
> --
> 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.

ANN: ClojureScript 0.0-1933

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

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

New release version: 0.0-1933

Leiningen dependency information:

[org.clojure/clojurescript "0.0-1933"]

Changes:
* / in symbol now always delimits a namespace
* tools.reader 0.7.9, addresses Windows line ending convention

Enhancements:
* referred vars and macros now verified
* replace asserts with errors, now file and line location for all analyzer
and compiler errors

Bug fixes:
* CLJS 600 & 604: LazySeq regressions
* CLJS 605: Allow alias target to change when recompiling file
* CLJS 456: test case for CLJS 544
* CLJS 603: namespace and variadic function shadowing
* CLJS 566: 1 arity method for partial
* CLJS 601: multiple cases of fn arity now emits warning
* CLJS 613: unify try special form with Clojure
* CLJS 602: better error message for too many arguments to fn

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

ANN: ClojureScript 0.0-1934

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

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

New release version: 0.0-1934

Leiningen dependency information:

[org.clojure/clojurescript "0.0-1934"]

The only change in this release - eliminating spurious namespace errors.

-- 
-- 
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: No such namespace warning with Clojurescript repl

[David Nolen]

You can no longer use foo/bar to access properties, a slash now always
indicates a namespace with CLJS 1933 and up.


On Sat, Oct 19, 2013 at 12:47 PM, Greg Chapman wrote:

> I've been working through the Clojurescript tutorial here:
> https://github.com/magomimmo/modern-cljs
>
> When compiling step 2, which adds a file requiring clojure.browser.repl, I
> get a "WARNING: No such namespace: e at line 71" (in repl.cljs). The code
> in repl.cljs is:
>
>   (event/listen connection
>> :success
>> (fn [e]
>>   (net/transmit
>>repl-connection
>>:evaluate-javascript
>>(.getResponseText e/currentTarget
>>  ()
>>
>>
> which does appear to be treating the event object e as a namespace. Should
> that be changed to (.- currentTarget e) ?
>
>
>  --
> --
> 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: ANN: core.match 0.2.0

[David Nolen]

If there's something specific you would like to see based on what is
already present I'm listening.

David


On Fri, Oct 18, 2013 at 11:49 AM, François De Serres <
francois.de.ser...@gmail.com> wrote:

> Hi David,
>
> any chance to see core.match expose its compiler in the near future?
> The ability to create "matchers" at runtime (like matchure/fn-match) would
> be much welcome ;)
>
> Thankies,
> --
> François
>
> --
> --
> 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: Request for help optimising a Clojure program

[David Nolen]

I note that the Clojure version isn't being given 12gigs of RAM, is this
something you're giving to the JVM after when you run a AOTed version of
the Clojure code.

You also haven't said whether the timings for the smaller problems are
significantly different between Scala and Clojure.

David


On Tue, Oct 22, 2013 at 12:28 PM, Paul Butcher  wrote:

> I've been playing around with a generalised version of the N-Queens
> problem that handles other chess pieces. I have a Scala implementation that
> uses an eager depth-first search. Given enough RAM (around 12G - it's very
> memory hungry!) it can solve a 6x9 board with 6 pieces in around 2.5
> minutes on my MacBook Pro.
>
> I then created a Clojure version of the same algorithm with the intention
> of (eventually) using laziness to avoid the memory issue. However, the
> performance of the Clojure version is several orders of magnitude worse
> than the Scala version (I've left it running overnight on the problem that
> the Scala version solves in 2.5 minutes and it still hasn't completed).
>
> I'm struggling to see why the performance of the Clojure version is so
> much worse than the Scala. Profiling in YourKit suggests that it's spending
> 99% of its time in PersistentHashSet.cons, but I'm at a loss to explain
> why. I would be grateful for any insight.
>
> The code for the two different versions is on GitHub:
>
> https://github.com/paulbutcher/chess-scala
> https://github.com/paulbutcher/chess-clojure
>
> Notes:
>
> - I know that an exhaustive depth-first search isn't a great way to tackle
> this problem. But I'd like to understand why I see such a dramatic
> difference between the performance of the Scala and Clojure versions.
>
> - I believe that I've implemented the same algorithm in both Scala and
> Clojure - certainly they both generate the same results for small problems
> (there are 3x3 and 4x4 problems commented out in the source). But clearly I
> can't rule out the possibility that I've made a mistake in the Clojure
> implementation. If anyone can spot my stupid mistake, I'd greatly
> appreciate it.
>
> Thanks in advance for any insight that anyone can offer.
>
> --
> paul.butcher->msgCount++
>
> Snetterton, Castle Combe, Cadwell Park...
> Who says I have a one track mind?
>
> http://www.paulbutcher.com/
> LinkedIn: http://www.linkedin.com/in/paulbutcher
> MSN: p...@paulbutcher.com
> AIM: paulrabutcher
> Skype: paulrabutcher
>
>  --
> --
> 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: Request for help optimising a Clojure program

[David Nolen]

On Tue, Oct 22, 2013 at 3:11 PM, Paul Butcher  wrote:

> Yeah - I have tried giving it more RAM without any effect on the timing
> whatsoever. And I couldn't see the point of stopping people with less RAM
> than that from being able to run it :-)
>

But without enough RAM most JVMs will thrash in GC when running that code.

Saying both run in less than a second is not particularly informative for
the small problems :) Does Scala take 4ms and Clojure takes 400ms on the
small problems? That's a big difference.

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: Request for help optimising a Clojure program

[David Nolen]

Those numbers make the larger problem runtime suspect. How are you running
the Clojure version? With Lein?

On Wednesday, October 23, 2013, Paul Butcher wrote:

> On 22 Oct 2013, at 20:20, David Nolen 
> >
> wrote:
>
> On Tue, Oct 22, 2013 at 3:11 PM, Paul Butcher 
> 
> > wrote:
>
>> Yeah - I have tried giving it more RAM without any effect on the timing
>> whatsoever. And I couldn't see the point of stopping people with less RAM
>> than that from being able to run it :-)
>>
>
> But without enough RAM most JVMs will thrash in GC when running that code.
>
>
> Yes, of course. But as I said, I tried giving it more RAM (the same 12G as
> the Scala solution) and it made no difference whatsoever. In fact, YourKit
> shows me that, even after running for an hour (i.e. more than 10x longer
> than the Scala version takes to return the full solution) the Clojure
> version is still using less than 2G. Whatever is going on, it's not a
> result of a lack of RAM.
>
> Saying both run in less than a second is not particularly informative for
> the small problems :) Does Scala take 4ms and Clojure takes 400ms on the
> small problems? That's a big difference.
>
>
> Yes, of course. But my experience with small problems has been that
> differences between execution time, especially when talking about runtimes
> as dissimilar as the Clojure and Scala runtimes, are meaningless. Those
> differences tend to have more to do with startup costs and the vagaries of
> when hotspot happens to optimise things than anything fundamental.
>
> But you asked, so here it is:
>
> For Clojure, the 3x3 problem takes 7ms and the 4x4 problem takes 78ms. For
> Scala, it's 15ms and 252ms respectively.
>
> --
> paul.butcher->msgCount++
>
> Snetterton, Castle Combe, Cadwell Park...
> Who says I have a one track mind?
>
> http://www.paulbutcher.com/
> LinkedIn: http://www.linkedin.com/in/paulbutcher
> MSN: p...@paulbutcher.com  'p...@paulbutcher.com');>
> AIM: paulrabutcher
> Skype: paulrabutcher
>
> On 22 Oct 2013, at 20:20, David Nolen 
> >
> wrote:
>
> On Tue, Oct 22, 2013 at 3:11 PM, Paul Butcher 
> 
> > wrote:
>
>> Yeah - I have tried giving it more RAM without any effect on the timing
>> whatsoever. And I couldn't see the point of stopping people with less RAM
>> than that from being able to run it :-)
>>
>
> But without enough RAM most JVMs will thrash in GC when running that code.
>
> Saying both run in less than a second is not particularly informative for
> the small problems :) Does Scala take 4ms and Clojure takes 400ms on the
> small problems? That's a big difference.
>
> 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 '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+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  '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 '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@googl

Re: Request for help optimising a Clojure program

[David Nolen]

Lein doesn't use your specified JVM settings, you must override with
^:replace. It's also a good idea to set "-server" as Lein does not default
to this.

On Wednesday, October 23, 2013, Paul Butcher wrote:

> On 23 Oct 2013, at 12:21, David Nolen 
> >
> wrote:
>
> Those numbers make the larger problem runtime suspect. How are you running
> the Clojure version? With Lein?
>
>
> Yes - lein run.
>
> --
> paul.butcher->msgCount++
>
> Snetterton, Castle Combe, Cadwell Park...
> Who says I have a one track mind?
>
> http://www.paulbutcher.com/
> LinkedIn: http://www.linkedin.com/in/paulbutcher
> MSN: p...@paulbutcher.com  'p...@paulbutcher.com');>
> AIM: paulrabutcher
> Skype: paulrabutcher
>
>  --
> --
> 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: Request for help optimising a Clojure program

[David Nolen]

If set construction was 1000X worse why don't the smaller problem sizes
exhibit exactly the same issue? If the Scala version requires 12G why is
the Clojure version steady at 300M?

Aren't Scala for comprehensions optimized now into lower level loops?
Clojure for comprehensions generate lazy sequences and all the allocation
and forcing of thunks that implies.

David

On Wednesday, October 23, 2013, Paul Butcher wrote:

> On 23 Oct 2013, at 13:18, Timothy Baldridge 
> >
> wrote:
>
> Great! you have a profiler, use that. Find the hotspots, use YourKit to
> find where the .cons is being called from, find things to optimize, and go
> from there. This is exactly the same process I would use any optimizations
> I attempted.
>
>
> I fear I may have failed to convey the question I'm trying to answer.
>
> I'm sure that I could create a faster solution in Clojure - that's not the
> question I'm trying to answer though.
>
> What I'm trying to answer is why the *exact same* algorithm implemented in
> Scala is 1000x faster.
>
> As far as I know, the Scala version of the algorithm creates exactly as
> many sets and performs exactly as many set operations as the Clojure does.
> But the Clojure version is 1000x slower. That strikes me as very strange
> and worth getting to the bottom of?
>
> I have, of course, looked at the result of the profiler. And what it seems
> to be saying is that set operations in Clojure are ruinously slow. I'm not
> sure that I believe that though - I can't think of any reason why Clojure's
> sets should be 1000x slower than Scala's? So I'm asking for the help of
> this list.
>
> Of course, I can't rule out the possibility that I've failed to convert
> the Scala version to Clojure and they're actually implementing very
> different algorithms - but I've had several people look at the
> implementations and confirm that they appear to be the same. Nevertheless,
> if there is a problem there, I'd also be interested to find it as I'm sure
> that it will teach me something.
>
> --
> paul.butcher->msgCount++
>
> Snetterton, Castle Combe, Cadwell Park...
> Who says I have a one track mind?
>
> http://www.paulbutcher.com/
> LinkedIn: http://www.linkedin.com/in/paulbutcher
> MSN: p...@paulbutcher.com  'p...@paulbutcher.com');>
> AIM: paulrabutcher
> Skype: paulrabutcher
>
>  --
> --
> 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: Request for help optimising a Clojure program

[David Nolen]

The Scala code is using immutable sets.

On Wednesday, October 23, 2013, Timothy Baldridge wrote:

> From what I can tell, Clojure uses persistent hash sets inside of set.
> This can be fixed by replacing set with (into #{} data). Into uses
> transients internally and should be much faster.
>
> I don't know Scala, but from I can tell, Scala is using mutable
> collections. I think the combination of these two things (immutable
> collections plus lack of transients) could be causing some performance
> impact. I wouldn't expect it to be 1000x but it's a starting place.
>
> Timothy
>
>
> On Wed, Oct 23, 2013 at 6:36 AM, Paul Butcher 
> 
> > wrote:
>
>> On 23 Oct 2013, at 13:18, Timothy Baldridge 
>> >
>> wrote:
>>
>> Great! you have a profiler, use that. Find the hotspots, use YourKit to
>> find where the .cons is being called from, find things to optimize, and go
>> from there. This is exactly the same process I would use any optimizations
>> I attempted.
>>
>>
>> I fear I may have failed to convey the question I'm trying to answer.
>>
>> I'm sure that I could create a faster solution in Clojure - that's not
>> the question I'm trying to answer though.
>>
>> What I'm trying to answer is why the *exact same* algorithm implemented
>> in Scala is 1000x faster.
>>
>> As far as I know, the Scala version of the algorithm creates exactly as
>> many sets and performs exactly as many set operations as the Clojure does.
>> But the Clojure version is 1000x slower. That strikes me as very strange
>> and worth getting to the bottom of?
>>
>> I have, of course, looked at the result of the profiler. And what it
>> seems to be saying is that set operations in Clojure are ruinously slow.
>> I'm not sure that I believe that though - I can't think of any reason why
>> Clojure's sets should be 1000x slower than Scala's? So I'm asking for the
>> help of this list.
>>
>> Of course, I can't rule out the possibility that I've failed to convert
>> the Scala version to Clojure and they're actually implementing very
>> different algorithms - but I've had several people look at the
>> implementations and confirm that they appear to be the same. Nevertheless,
>> if there is a problem there, I'd also be interested to find it as I'm sure
>> that it will teach me something.
>>
>> --
>> paul.butcher->msgCount++
>>
>> Snetterton, Castle Combe, Cadwell Park...
>> Who says I have a one track mind?
>>
>> http://www.paulbutcher.com/
>> LinkedIn: http://www.linkedin.com/in/paulbutcher
>> MSN: p...@paulbutcher.com > 'p...@paulbutcher.com');>
>> AIM: paulrabutcher
>> Skype: paulrabutcher
>>
>>  --
>> --
>> 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.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> --
> 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 Go

Re: Request for help optimising a Clojure program

[David Nolen]

The problem here is that you're not following your Scala solution closely
enough. I suspect if you used defrecords to represent the pieces the way
that you used a class in Scala you can avoid the number of collisions for
larger problems.

Not tested much but I tried something like the following and I no longer
see hash collisions dominating in YourKit:

(defrecord Piece [name pos])

(defn piece [name  pos]
  (Piece. name pos))

(defn takes? [name [dx dy]]
  (case name
:K (and (<= dx 1) (<= dy 1))
:Q (or (zero? dx) (zero? dy) (== dx dy))
:R (or (zero? dx) (zero? dy))
:B (== dx dy)
:N (or (and (== dx 1) (== dy 2)) (and (== dx 2) (== dy 1)

(defn allows? [{name :name [px py] :pos} [x y]]
  (let [delta [(Math/abs (int (- px x))) (Math/abs (int (- py y)))]]
(and (not (and (== px x) (== py y))) (not (takes? name delta)

(defn allowed? [{cname :name cpos :pos :as cand} solution]
  (every?
(fn [{pos :pos :as piece}]
  (and (allows? piece cpos) (allows? cand pos)))
solution))

(defn solve [rows cols pieces]
  (if (empty? pieces)
#{#{}}
(set
  (let [name (first pieces)]
(for [solution (solve rows cols (rest pieces))
  x (range 0 cols)
  y (range 0 rows)
  :let [cand (piece name [x y])]
  :when (allowed? cand solution)]
  (conj solution cand))

David

On Wed, Oct 23, 2013 at 1:28 PM, Paul Butcher  wrote:

> On 23 Oct 2013, at 18:15, Andy Fingerhut  wrote:
>
> If we had a 'universal comparator', i.e. a comparison function that
> provided a total order on any pair of values that anyone would ever want to
> put into a set or use as a map key, then instead of having linked lists for
> values that collide, we could have trees like those in the implementations
> of sorted-maps and sorted-sets today.
>
>
> Wouldn't it be better to improve the way that hashes are calculated for
> vectors? A good hash function should make it unlikely that similar values
> have the same hash. The current algorithm seems to make that more likely
> than it should?
>
> --
> paul.butcher->msgCount++
>
> Snetterton, Castle Combe, Cadwell Park...
> Who says I have a one track mind?
>
> http://www.paulbutcher.com/
> LinkedIn: http://www.linkedin.com/in/paulbutcher
> MSN: p...@paulbutcher.com
> AIM: paulrabutcher
> Skype: paulrabutcher
>
>  --
> --
> 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: Request for help optimising a Clojure program

[David Nolen]

OK, it appears defrecord suffers from a problem that used to plague Scala
case classes as well - http://issues.scala-lang.org/browse/SI-2537.

David

On Thu, Oct 24, 2013 at 8:08 AM, Paul Butcher  wrote:

> On 23 Oct 2013, at 18:37, David Nolen  wrote:
>
> The problem here is that you're not following your Scala solution closely
> enough. I suspect if you used defrecords to represent the pieces the way
> that you used a class in Scala you can avoid the number of collisions for
> larger problems.
>
> Not tested much but I tried something like the following and I no longer
> see hash collisions dominating in YourKit:
>
>
> It would be lovely if it was that easy, David. However, I still see lots
> of hash collisions when using records. Here's a portion of the output from
> an implementation that's instrumented to print hash codes, similar to what
> Andy did with the vector-based implementation:
>
> "842565000: #{#chess_clojure.core.Piece{:name :Q, :pos [3 2]}
> #chess_clojure.core.Piece{:name :B, :pos [1 5]}
> #chess_clojure.core.Piece{:name :N, :pos [0 1]}
> #chess_clojure.core.Piece{:name :R, :pos [8 4]}}"
> "842565000: #{#chess_clojure.core.Piece{:name :N, :pos [0 4]}
> #chess_clojure.core.Piece{:name :Q, :pos [3 3]}
> #chess_clojure.core.Piece{:name :B, :pos [1 0]}
> #chess_clojure.core.Piece{:name :R, :pos [8 5]}}"
> "842565000: #{#chess_clojure.core.Piece{:name :N, :pos [0 4]}
> #chess_clojure.core.Piece{:name :Q, :pos [3 3]}
> #chess_clojure.core.Piece{:name :B, :pos [1 4]}
> #chess_clojure.core.Piece{:name :R, :pos [8 1]}}"
> "842565000: #{#chess_clojure.core.Piece{:name :N, :pos [0 3]}
> #chess_clojure.core.Piece{:name :Q, :pos [3 4]}
> #chess_clojure.core.Piece{:name :B, :pos [1 0]}
> #chess_clojure.core.Piece{:name :R, :pos [8 5]}}"
> "842565000: #{#chess_clojure.core.Piece{:name :N, :pos [0 3]}
> #chess_clojure.core.Piece{:name :Q, :pos [3 5]}
> #chess_clojure.core.Piece{:name :B, :pos [1 0]}
> #chess_clojure.core.Piece{:name :R, :pos [8 4]}}"
> "842565000: #{#chess_clojure.core.Piece{:name :R, :pos [0 3]}
> #chess_clojure.core.Piece{:name :Q, :pos [4 2]}
> #chess_clojure.core.Piece{:name :B, :pos [1 0]}
> #chess_clojure.core.Piece{:name :N, :pos [8 0]}}"
> "842565000: #{#chess_clojure.core.Piece{:name :R, :pos [0 3]}
> #chess_clojure.core.Piece{:name :Q, :pos [3 4]}
> #chess_clojure.core.Piece{:name :B, :pos [1 5]}
> #chess_clojure.core.Piece{:name :N, :pos [8 0]}}"
> "842565000: #{#chess_clojure.core.Piece{:name :Q, :pos [3 2]}
> #chess_clojure.core.Piece{:name :B, :pos [1 5]}
> #chess_clojure.core.Piece{:name :R, :pos [0 0]}
> #chess_clojure.core.Piece{:name :N, :pos [8 5]}}"
> "842565000: #{#chess_clojure.core.Piece{:name :Q, :pos [4 2]}
> #chess_clojure.core.Piece{:name :R, :pos [1 1]}
> #chess_clojure.core.Piece{:name :B, :pos [0 5]}
> #chess_clojure.core.Piece{:name :N, :pos [8 5]}}"
> "842565000: #{#chess_clojure.core.Piece{:name :Q, :pos [3 2]}
> #chess_clojure.core.Piece{:name :R, :pos [1 1]}
> #chess_clojure.core.Piece{:name :B, :pos [0 4]}
> #chess_clojure.core.Piece{:name :N, :pos [8 5]}}"
> "842565000: #{#chess_clojure.core.Piece{:name :R, :pos [0 3]}
> #chess_clojure.core.Piece{:name :Q, :pos [3 4]}
> #chess_clojure.core.Piece{:name :B, :pos [1 0]}
> #chess_clojure.core.Piece{:name :N, :pos [8 5]}}"
> "842565000: #{#chess_clojure.core.Piece{:name :Q, :pos [3 4]}
> #chess_clojure.core.Piece{:name :R, :pos [1 1]}
> #chess_clojure.core.Piece{:name :B, :pos [0 5]}
> #chess_clojure.core.Piece{:name :N, :pos [8 2]}}"
> "842565000: #{#chess_clojure.core.Piece{:name :Q, :pos [3 5]}
> #chess_clojure.core.Piece{:name :R, :pos [1 1]}
> #chess_clojure.core.Piece{:name :B, :pos [0 4]}
> #chess_clojure.core.Piece{:name :N, :pos [8 2]}}"
> "842565000: #{#chess_clojure.core.Piece{:name :Q, :pos [3 4]}
> #chess_clojure.core.Piece{:name :B, :pos [1 5]}
> #chess_clojure.core.Piece{:name :R, :pos [0 2]}
> #chess_clojure.core.Piece{:name :N, :pos [8 1]}}"
> "842565000: #{#chess_clojure.core.Piece{:name :Q, :pos [3 5]}
> #chess_clojure.core.Piece{:name :B, :pos [0 4]}
> #chess_clojure.core.Piece{:name :R, :pos [1 2]}
> #chess_clojure.core.Piece{:name :N, :pos [8 1]}}"
> "842565000: #{#chess_clojure.core.Piece{:name :Q, :pos [3 4]}
> #chess_clojure.core.Piece{:name :B, :pos [1 5]}
> #chess_clojure.core.Piece{:name :R, :pos [7 2]}
> #chess_clojure.core.Piece{:name :N, :pos [0 0]}}"
> "842565000: #{#chess_clojure.core.Piece{:name :Q, :pos [4 2]}
> #chess_clojure.core.Piece{:name :B, :pos [0 4]}
> #chess_clojure.core.Piece{:name :N, :pos [6 5]}
> #chess_clojure.core.Piece{:name :R

Re: Request for help optimising a Clojure program

[David Nolen]

What I suggested is far, far more conservative than anything else proposed
on this or on the dev thread.

Changing the hash implementation of sets and vectors etc. is likely to have
unintended consequences for performance -
http://www.scala-lang.org/old/node/8510.html

The original Scala code used case classes - like defrecord they provide a
lot of functionality out of the box and don't require defining hash /
equals methods. In the past Scala case classes had bad hash code
distribution, this is no longer the case.

What I'm suggesting is to leave everything else alone, but only make the
sensible change so that the Scala code can be reasonably ported to Clojure.
This simply requires giving defrecord a better hashing strategy. I suspect
we can duplicate the approach already taken by Scala for case classes.

David

On Fri, Oct 25, 2013 at 12:11 PM, Stuart Halloway  wrote:

> To save others from having to read this whole thread, is the following
> summary correct?
>
> 1. We believe that the performance issue Paul first encountered is
> substantially / entirely caused by hash collisions.
>
> 2. The hash collisions could be improved by spreading the hashes of
> numbers (and not needing to mess with hashes of collections).
>
> If the above summary is correct, then I have the following questions:
>
> a. Is the approach Scala took substantially #2 above, or something
> different / more?
>
> b. Is changing the hash codes of numbers going to break expectations on
> the Java side of things?
>
>
> On Thu, Oct 24, 2013 at 8:37 PM, Evan Gamble  wrote:
>
>> As Andy Fingerhut pointed out, since (hash [a b]) is 31*(a + 30) + (b +
>> 31) when a and b are ints, summing the hashes of 2-tuples when the values
>> are small ints, as happens when hashing sets of such 2-tuples, is quite
>> likely to lead to collisions. This particular problem could be avoided by
>> spreading the hashes of ints out to large numbers with a non-linear
>> function, not just multiplying them all by some N.
>>
>>
>> On Wednesday, October 23, 2013 5:41:15 PM UTC-7, puzzler wrote:
>>
>>> Perhaps I don't understand your point, but vector hashing is not
>>> currently the sum of hashes.  It's a more complex computation.
>>>
>>> => (hash [0 2])
>>> 963
>>> => (hash [2 0])
>>> 1023
>>> => (hash [2])
>>> 33
>>>
>>> The fact that numbers hash to themselves means that the resulting hashes
>>> are not hugely spread apart, but collisions don't seem to be as common as
>>> with sets and maps.  I'm sure it could be improved, but vector/sequence
>>> hashing doesn't strike me as a huge issue.
>>>
>>>
>>> On Wed, Oct 23, 2013 at 5:31 PM, Cedric Greevey wrote:
>>>
 There's still a problem with collisions among *vectors* though.

 I'd say the real underlying problem is that small integers hash to
 themselves. If you let N be a fairly large number satisfying GCD(N, 2^32 -
 1) = 1, then multiplying 32-bit integers by N would send nearby integers to
 widely separated ones, while inducing a permutation on nonzero integers --
 the hash space wouldn't be any smaller. That alone won't help much with the
 vector problem, since 3N + 2N = 5N just as 3 + 2 = 5, though it may help
 avoid collisions with small integers in small hash maps when the hash is
 being used modulo a small hash-table length. What might help with vectors,
 sets, and other small data structures containing integers (but would shrink
 the hash space by about half) is to additionally square the result (all
 operations being 2s-complement 32-bit integer operations with wrapping --
 Java "int" arithmetic). Now 1 and 4 won't give the same summed hashes as 3
 and 2, and 0 and 5 will be different again. You might also want to add some
 constant to avoid 0 hashing to 0.

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

ANN: ClojureScript 0.0-1978

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

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

New release version: 0.0-1978

Leiningen dependency information:

[org.clojure/clojurescript "0.0-1978"]

Changes:
* tools.reader 0.7.10

Enhancements:
* Significantly better source map support - should work with or without
Closure optimizations and should work with incremental compilation across
JVM runs. If you haven't tried the source map feature before, now's a good
time :)

Bug fixes:
CLJS-638: Keyword invoke is inconsistent with clojure
CLJS-632: use tools.reader's *alias-map* for tracking aliases instead of
Clojure namespaces
CLJS-471: prevent empty regexps from causing compiler errors
CLJS-628: *cljs-file* not bound when compiling to stdout
CLJS-634: do not call getPath on a null value
CLJS-635: Clojure consistent implementations of -rseq
CLJS-608: Stop re-seq after reaching end of string
CLJS-591: source relative path for source map
CLJS-617: double evaluation of ^not-native type-hinted expressions

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