Re: Satisfies? seems strangely slow

2015-01-24 Thread Tassilo Horn 
Fluid Dynamics  writes:

Hi!

> One approach is to have a first-class-edges? method in the mother
> graph protocol.  Another is to have such a method in IEdges and extend
> that to Object with first-class-edges? returning false and the other
> IEdges-specific methods throwing IllegalStateExceptions, as well as to
> "true" IEdges subtypes with the first returning true and the rest
> doing whatever they should do.

In this scenario, I don't see a benefit other than that I don't need to
use satisfies? which is no problem at all in my case (it's only called
once, so I don't care about its performance).  And default impls have
the negative side effect that they make debugging harder.  E.g., now if
some code calls (proto-method foo) where foo intentionally doesn't
support the protocol I get an error.  With a default impl it won't fail
and either no errors pop up or they pop up at other places.

Of course, default impls could throw IllegalStateExceptions with proper
messages but IMHO the usual protocol dispatch "no IFoo method impl for
class Bar" error is good enough.

Bye,
Tassilo

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

2015-01-24 Thread 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-2719

Leiningen dependency information:

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

ClojureScript is not an island, like Clojure on the JVM, ClojureScript
embraces the many benefits provided by the host. However this goal
has been hampered by another goal - the compilation stragey. Google
Closure Compiler offers superior optimization and minification for
ClojureScript while simultaneously making it considerably more
difficult to integrate non-Closure compatible libraries. Using popular
libraries like jQuery, React or D3 is an error prone process: "which
extern did I forget?", "which script tag did I miss for development?",
"are these script tags in dependency order?".

No more. 0.0-2719 delivers full support for non-Closure compatible
libraries through some less known features that have been lurking
around for almost three years - `deps.cljs` and the :foreign-libs
compiler option.

`deps.cljs` is a simple EDN file provided at the root of a JAR that
describes additional build information for the ClojureScript
compiler. For example here is the `deps.cljs` for the React JAR I
maintain:

{
 :foreign-libs [{:file "react/react.js"
 :file-min "react/react.min.js"
 :provides ["com.facebook.React"]}
{:file "react/react_with_addons.js"
 :file-min "react/react_with_addons.min.js"
 :provides ["com.facebook.ReactWithAddons"]}]
 :externs ["react/externs/react.js"]
}

This file provides all the information ClojureScript needs to
correctly manage the foreign dependency for you under all compilation
modes and REPLs.

In a REPL:

   cljs.user> (require 'com.facebook.React)
   cljs.user> (. js/React
(renderToString
  (. js/React (DOM.div nil "Hello!"

In your project:

   (ns foo.bar
 (:require com.facebook.React))

   (enable-console-print!)

   (println
 (. js/React
   (renderToString
 (. js/React (DOM.div nil "Hello!")

The above works under all compilation modes. There is no need to
include React as a script tag under development, there is no need to put
script tags in dependency order, there is no need to add React to
:preamble under :advanced, and there is no need to explicitly provide
:externs.

All that is required is that JavaScript libraries be packaged in JARs
with a `deps.cljs`.

Some of you might reasonably ask why not a tool like Bower for this
instead?  Bower requires an additional dependency on Node.js. While
ClojureScript embraces Node.js as a useful target it is not a
requirement to be productive. Bower manages dependencies, but in the
Clojure world we have already embraced Maven for this task and have
done the same for ClojureScript. Finally Bower does not address the
problem of loading libraries at runtime. This is challenging to do -
some JavaScript libraries adopt CommonJS, some AMD, and the most
popular ones make no assumptions at all allowing users to simply use
script tags as they have done for nearly two decades. The above
solution addresses the issue for all ClojureScript users by
eliminating paralysis of choice. Finally none of the above
precludes Bower usage in any way whatsoever.

This new feature addresses a long outstanding pain point with
ClojureScript development. All that is required is that we take the
time to properly package up the most popular JavaScript libraries that
fill gaps not currently served by exising ClojureScript and Google
Closure Library functionality.

Please kick the tires and feedback is most welcome. This feature
touched many bits of code so there are likely to be wrinkles and we want
to get these ironed out as quickly as possible.

## 0.0-2719

### Changes
* Full support for foreign dependencies
* CLJS-985: make ex-info not lose stack information
* CLJS-984: Update Node.js REPL support to use public API
* CLJS-963: do not bother computing goog/dep.js under :none

### Fixes
* CLJS-982: Var derefing should respect Clojure semantics
* CLJS-980: ClojureScript REPL stacktraces overrun prompt in many cases
* CLJS-979: ClojureScript REPL needs error handling for the special
functions
* CLJS-971: :reload should work for require-macros special fn
* CLJS-980: ClojureScript REPL stacktraces overrun prompt in many cases
* CLJS-979: ClojureScript REPL needs error handling for the special
functions
* CLJS-971: :reload should work for require-macros special fn
* CLJS-936: Multi arity bitwise operators
* CLJS-962: fix inconsistent hashing of empty collections

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroup

[ANN] Introducing 'Phoenix' - a new library for declarative configuration and wiring of Component-based systems

2015-01-24 Thread James Henderson 
Hi all,

I've just released Phoenix - a library for declarative configuration and 
wiring of Component-based systems. Phoenix came out of a number of 
discussions at ClojureX, thank you to all involved for their suggestions 
and feedback :)

https://github.com/james-henderson/phoenix

If you’ve written a traditional Component-based system, you’ve probably 
experienced having to create and maintain a plethora of ‘system.clj’, 
‘dev.clj’, ‘user.clj’ etc type namespaces in order to wire-up the system, 
set up configuration-based switches, and duplicate the code to 
start/stop/reload the system. Phoenix removes the need for all of this, 
replacing it with one (or more, if you choose) EDN declaration of how your 
system should be wired up. It should also compose well with any other 
Components you (or anyone else) may have already written.

For a sample project, you can run 'lein new phoenix-webapp ', 
then 'cd ' and 'lein dev'. Once the nREPL is up, running '
(phoenix/reload!)' will stop the system, reload any namespaces, and restart 
the system.

Phoenix is just one possible way of wiring up such a system - I understand 
that there are a fair few ideas floating around out there at the moment! 
I'd be really interested to hear your thoughts - whether it be 'this is 
mostly right, but I wouldn't do that part like that', or 'you've gone about 
this completely the wrong way, because ...' - let me know!

Cheers,

James

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

2015-01-24 Thread Frozenlock 
Amazing, thanks a lot!

On Monday, January 19, 2015 at 7:18:35 AM UTC-5, JUAN ANTONIO Ruz wrote:
>
> Hi folks,
>
> just sharing here [milesian/system-diagrams 
> ] a tool to get real time 
> system visualisations of your internal protocol calls in 
> stuartsierra/component based systems 
>
> You can find a couple of snapshots and instructions to use it in your 
> current system here: 
> https://github.com/milesian/system-diagrams
>
> ** Pay attention that all changes and dependencies required in your 
> current project only are necessaries in dev mode. So you don't need to 
> change anything in /src folder and all dependencies are added in :profiles 
> :dev :dependencies
>
> ** Due that it's stuartsierra/component based you can use it with your 
> juxt/modular  or danielsz/system 
>  apps too
>
> Hope it was useful
> Juan 
>
> http://tangrammer.github.io/
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ClojureScript] Re: ANN: ClojureScript 0.0-2719, JavaScript Dependencies

2015-01-24 Thread David Nolen 
On Sat, Jan 24, 2015 at 10:43 AM, Martin Klepsch <
martinklep...@googlemail.com> wrote:

> A general question/concern I'd like to voice in that context is that
> this change makes it hard to split JS preamble from our compiled
> Clojurescript.  Given that the Clojurescript code might change on a
> daily basis and the preamble mostly stays the same this forces users
> to re-download our (unchanged) JS dependencies over and over again,
> while caching them would have provided us with much better performance.
>

I understand the desire/need for splitting out foreign deps but this should
be addressed separately with the coming Google Closure Module support

David

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: ClojureScript 0.0-2719, JavaScript Dependencies

2015-01-24 Thread Khalid Jebbari 
A question (maybe stupid/obvious) : why do you need to declare the "min" 
version of js lib ? The normal version + the extern file is all that's 
needed to compress the file with the Closure Compiler, no ?

Thanks by way, this means moving towards better integration with (the 
jungle that is) the javascript ecosystem (npm, bower, AMD, SystemJS, ES6, 
and who knows what...)

On Saturday, January 24, 2015 at 4:10:29 PM UTC+1, 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-2719
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "0.0-2719"]
>
> ClojureScript is not an island, like Clojure on the JVM, ClojureScript
> embraces the many benefits provided by the host. However this goal
> has been hampered by another goal - the compilation stragey. Google
> Closure Compiler offers superior optimization and minification for
> ClojureScript while simultaneously making it considerably more
> difficult to integrate non-Closure compatible libraries. Using popular
> libraries like jQuery, React or D3 is an error prone process: "which
> extern did I forget?", "which script tag did I miss for development?",
> "are these script tags in dependency order?".
>
> No more. 0.0-2719 delivers full support for non-Closure compatible
> libraries through some less known features that have been lurking
> around for almost three years - `deps.cljs` and the :foreign-libs
> compiler option.
>
> `deps.cljs` is a simple EDN file provided at the root of a JAR that
> describes additional build information for the ClojureScript
> compiler. For example here is the `deps.cljs` for the React JAR I
> maintain:
>
> {
>  :foreign-libs [{:file "react/react.js"
>  :file-min "react/react.min.js"
>  :provides ["com.facebook.React"]}
> {:file "react/react_with_addons.js"
>  :file-min "react/react_with_addons.min.js"
>  :provides ["com.facebook.ReactWithAddons"]}]
>  :externs ["react/externs/react.js"]
> }
>
> This file provides all the information ClojureScript needs to
> correctly manage the foreign dependency for you under all compilation
> modes and REPLs.
>
> In a REPL:
>
>cljs.user> (require 'com.facebook.React)
>cljs.user> (. js/React 
> (renderToString 
>   (. js/React (DOM.div nil "Hello!"
>
> In your project:
>
>(ns foo.bar
>  (:require com.facebook.React))
>
>(enable-console-print!)
>
>(println
>  (. js/React
>(renderToString
>  (. js/React (DOM.div nil "Hello!")
>
> The above works under all compilation modes. There is no need to
> include React as a script tag under development, there is no need to put
> script tags in dependency order, there is no need to add React to
> :preamble under :advanced, and there is no need to explicitly provide
> :externs.
>
> All that is required is that JavaScript libraries be packaged in JARs
> with a `deps.cljs`.
>
> Some of you might reasonably ask why not a tool like Bower for this
> instead?  Bower requires an additional dependency on Node.js. While
> ClojureScript embraces Node.js as a useful target it is not a
> requirement to be productive. Bower manages dependencies, but in the
> Clojure world we have already embraced Maven for this task and have
> done the same for ClojureScript. Finally Bower does not address the
> problem of loading libraries at runtime. This is challenging to do -
> some JavaScript libraries adopt CommonJS, some AMD, and the most
> popular ones make no assumptions at all allowing users to simply use
> script tags as they have done for nearly two decades. The above
> solution addresses the issue for all ClojureScript users by
> eliminating paralysis of choice. Finally none of the above
> precludes Bower usage in any way whatsoever.
>
> This new feature addresses a long outstanding pain point with
> ClojureScript development. All that is required is that we take the
> time to properly package up the most popular JavaScript libraries that
> fill gaps not currently served by exising ClojureScript and Google
> Closure Library functionality.
>
> Please kick the tires and feedback is most welcome. This feature
> touched many bits of code so there are likely to be wrinkles and we want
> to get these ironed out as quickly as possible.
>
> ## 0.0-2719
>
> ### Changes
> * Full support for foreign dependencies
> * CLJS-985: make ex-info not lose stack information
> * CLJS-984: Update Node.js REPL support to use public API
> * CLJS-963: do not bother computing goog/dep.js under :none
>
> ### Fixes
> * CLJS-982: Var derefing should respect Clojure semantics
> * CLJS-980: ClojureScript REPL stacktraces overrun prompt in many cases
> * CLJS-979: ClojureScript REPL needs error handling for the special 
> functions
> * CLJS-971: :reload should work for require-macros

Re: ANN: ClojureScript 0.0-2719, JavaScript Dependencies

2015-01-24 Thread David Nolen 
On Sat, Jan 24, 2015 at 11:01 AM, Khalid Jebbari 
wrote:

> A question (maybe stupid/obvious) : why do you need to declare the "min"
> version of js lib ? The normal version + the extern file is all that's
> needed to compress the file with the Closure Compiler, no ?
>

Declaring the minified version is completely optional.

JavaScript libraries generally ship minified versions so why not leverage
it? Including the un-minified version into the Closure Compiler build is
usually asking for trouble (I encountered problems with React in the past)
and just slows down advanced builds by having more JavaScript to process,
especially large libraries like React (>30KLOC).

David

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: ClojureScript 0.0-2719, JavaScript Dependencies

2015-01-24 Thread Bruce Hauman 
Great stuff! This will smooth things out quite a bit. 

I spent far too much time just yesterday trying to get an advanced build 
working right.

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.

Re: ANN: ClojureScript 0.0-2719, JavaScript Dependencies

2015-01-24 Thread Martin Klepsch 
David, thanks for making those improvements to Clojurescript, they'll
make things a lot easier in the future.

In the realm of Boot we started working on CLJSJS as an effort to
package up and ship popular Javascript libraries for use in Clojurescript 
[1].

While these packages have only been compatible with a Boot-based
Clojurescript build chain we fully intend to make them work with this
new approach to handle external Javascript libraries.

That said a bunch of libraries are already in place, we tracked down
extern files etc, so the changes to make them compatible should be
rather small. Contributions are very welcome. I hope to get one of the
libs compatible tomorrow so the migration path for the others is
clear.

A general question/concern I'd like to voice in that context is that
this change makes it hard to split JS preamble from our compiled
Clojurescript.  Given that the Clojurescript code might change on a
daily basis and the preamble mostly stays the same this forces users
to re-download our (unchanged) JS dependencies over and over again,
while caching them would have provided us with much better performance.

[1] https://github.com/cljsjs



On Saturday, January 24, 2015 at 4:10:29 PM UTC+1, 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-2719
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "0.0-2719"]
>
> ClojureScript is not an island, like Clojure on the JVM, ClojureScript
> embraces the many benefits provided by the host. However this goal
> has been hampered by another goal - the compilation stragey. Google
> Closure Compiler offers superior optimization and minification for
> ClojureScript while simultaneously making it considerably more
> difficult to integrate non-Closure compatible libraries. Using popular
> libraries like jQuery, React or D3 is an error prone process: "which
> extern did I forget?", "which script tag did I miss for development?",
> "are these script tags in dependency order?".
>
> No more. 0.0-2719 delivers full support for non-Closure compatible
> libraries through some less known features that have been lurking
> around for almost three years - `deps.cljs` and the :foreign-libs
> compiler option.
>
> `deps.cljs` is a simple EDN file provided at the root of a JAR that
> describes additional build information for the ClojureScript
> compiler. For example here is the `deps.cljs` for the React JAR I
> maintain:
>
> {
>  :foreign-libs [{:file "react/react.js"
>  :file-min "react/react.min.js"
>  :provides ["com.facebook.React"]}
> {:file "react/react_with_addons.js"
>  :file-min "react/react_with_addons.min.js"
>  :provides ["com.facebook.ReactWithAddons"]}]
>  :externs ["react/externs/react.js"]
> }
>
> This file provides all the information ClojureScript needs to
> correctly manage the foreign dependency for you under all compilation
> modes and REPLs.
>
> In a REPL:
>
>cljs.user> (require 'com.facebook.React)
>cljs.user> (. js/React 
> (renderToString 
>   (. js/React (DOM.div nil "Hello!"
>
> In your project:
>
>(ns foo.bar
>  (:require com.facebook.React))
>
>(enable-console-print!)
>
>(println
>  (. js/React
>(renderToString
>  (. js/React (DOM.div nil "Hello!")
>
> The above works under all compilation modes. There is no need to
> include React as a script tag under development, there is no need to put
> script tags in dependency order, there is no need to add React to
> :preamble under :advanced, and there is no need to explicitly provide
> :externs.
>
> All that is required is that JavaScript libraries be packaged in JARs
> with a `deps.cljs`.
>
> Some of you might reasonably ask why not a tool like Bower for this
> instead?  Bower requires an additional dependency on Node.js. While
> ClojureScript embraces Node.js as a useful target it is not a
> requirement to be productive. Bower manages dependencies, but in the
> Clojure world we have already embraced Maven for this task and have
> done the same for ClojureScript. Finally Bower does not address the
> problem of loading libraries at runtime. This is challenging to do -
> some JavaScript libraries adopt CommonJS, some AMD, and the most
> popular ones make no assumptions at all allowing users to simply use
> script tags as they have done for nearly two decades. The above
> solution addresses the issue for all ClojureScript users by
> eliminating paralysis of choice. Finally none of the above
> precludes Bower usage in any way whatsoever.
>
> This new feature addresses a long outstanding pain point with
> ClojureScript development. All that is required is that we take the
> time to properly package up the most popular JavaScript libraries that
> fill gaps not currently served b

Re: [ClojureScript] Re: ANN: ClojureScript 0.0-2719, JavaScript Dependencies

2015-01-24 Thread Daniel Kersten 
Thanks David for your continued hard work - another fantastic release. This
looks really good and solves real problems.

On Sat, 24 Jan 2015 16:09 David Nolen  wrote:

> On Sat, Jan 24, 2015 at 11:01 AM, Khalid Jebbari  > wrote:
>
>> A question (maybe stupid/obvious) : why do you need to declare the "min"
>> version of js lib ? The normal version + the extern file is all that's
>> needed to compress the file with the Closure Compiler, no ?
>>
>
> Declaring the minified version is completely optional.
>
> JavaScript libraries generally ship minified versions so why not leverage
> it? Including the un-minified version into the Closure Compiler build is
> usually asking for trouble (I encountered problems with React in the past)
> and just slows down advanced builds by having more JavaScript to process,
> especially large libraries like React (>30KLOC).
>
> David
>
> --
> 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.

ANN: Om 0.8.2

2015-01-24 Thread David Nolen 
The dependency information has changed:

[org.omcljs/om "0.8.2"]

The release depends on ClojureScript 0.0-2719 as it leverages the new
foreign dependency functionality to simplify development and production
builds.

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/d/optout.

Re: [ClojureScript] ANN: ClojureScript 0.0-2719, JavaScript Dependencies

2015-01-24 Thread Moritz Ulrich 
David Nolen  writes:

> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> New release version: 0.0-2719
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "0.0-2719"]
>
> ClojureScript is not an island, like Clojure on the JVM, ClojureScript
> embraces the many benefits provided by the host. However this goal
> has been hampered by another goal - the compilation stragey. Google
> Closure Compiler offers superior optimization and minification for
> ClojureScript while simultaneously making it considerably more
> difficult to integrate non-Closure compatible libraries. Using popular
> libraries like jQuery, React or D3 is an error prone process: "which
> extern did I forget?", "which script tag did I miss for development?",
> "are these script tags in dependency order?".
>
> No more. 0.0-2719 delivers full support for non-Closure compatible
> libraries through some less known features that have been lurking
> around for almost three years - `deps.cljs` and the :foreign-libs
> compiler option.
>
> `deps.cljs` is a simple EDN file provided at the root of a JAR that
> describes additional build information for the ClojureScript
> compiler. For example here is the `deps.cljs` for the React JAR I
> maintain:
>
> {
>  :foreign-libs [{:file "react/react.js"
>  :file-min "react/react.min.js"
>  :provides ["com.facebook.React"]}
> {:file "react/react_with_addons.js"
>  :file-min "react/react_with_addons.min.js"
>  :provides ["com.facebook.ReactWithAddons"]}]
>  :externs ["react/externs/react.js"]
> }
>
> This file provides all the information ClojureScript needs to
> correctly manage the foreign dependency for you under all compilation
> modes and REPLs.
>
> In a REPL:
>
>cljs.user> (require 'com.facebook.React)
>cljs.user> (. js/React
> (renderToString
>   (. js/React (DOM.div nil "Hello!"
>
> In your project:
>
>(ns foo.bar
>  (:require com.facebook.React))
>
>(enable-console-print!)
>
>(println
>  (. js/React
>(renderToString
>  (. js/React (DOM.div nil "Hello!")
>
> The above works under all compilation modes. There is no need to
> include React as a script tag under development, there is no need to put
> script tags in dependency order, there is no need to add React to
> :preamble under :advanced, and there is no need to explicitly provide
> :externs.
>
> All that is required is that JavaScript libraries be packaged in JARs
> with a `deps.cljs`.
>
> Some of you might reasonably ask why not a tool like Bower for this
> instead?  Bower requires an additional dependency on Node.js. While
> ClojureScript embraces Node.js as a useful target it is not a
> requirement to be productive. Bower manages dependencies, but in the
> Clojure world we have already embraced Maven for this task and have
> done the same for ClojureScript. Finally Bower does not address the
> problem of loading libraries at runtime. This is challenging to do -
> some JavaScript libraries adopt CommonJS, some AMD, and the most
> popular ones make no assumptions at all allowing users to simply use
> script tags as they have done for nearly two decades. The above
> solution addresses the issue for all ClojureScript users by
> eliminating paralysis of choice. Finally none of the above
> precludes Bower usage in any way whatsoever.
>
> This new feature addresses a long outstanding pain point with
> ClojureScript development. All that is required is that we take the
> time to properly package up the most popular JavaScript libraries that
> fill gaps not currently served by exising ClojureScript and Google
> Closure Library functionality.
>
> Please kick the tires and feedback is most welcome. This feature
> touched many bits of code so there are likely to be wrinkles and we want
> to get these ironed out as quickly as possible.
>
> ## 0.0-2719
>
> ### Changes
> * Full support for foreign dependencies
> * CLJS-985: make ex-info not lose stack information
> * CLJS-984: Update Node.js REPL support to use public API
> * CLJS-963: do not bother computing goog/dep.js under :none
>
> ### Fixes
> * CLJS-982: Var derefing should respect Clojure semantics
> * CLJS-980: ClojureScript REPL stacktraces overrun prompt in many cases
> * CLJS-979: ClojureScript REPL needs error handling for the special
> functions
> * CLJS-971: :reload should work for require-macros special fn
> * CLJS-980: ClojureScript REPL stacktraces overrun prompt in many cases
> * CLJS-979: ClojureScript REPL needs error handling for the special
> functions
> * CLJS-971: :reload should work for require-macros special fn
> * CLJS-936: Multi arity bitwise operators
> * CLJS-962: fix inconsistent hashing of empty collections
>
> -- 
> Note that posts from new members are moderated - please be patient with your 
> firs

Re: ANN: ClojureScript 0.0-2719, JavaScript Dependencies

2015-01-24 Thread David Nolen 
Some further explanation on packaging JavaScript libraries for
ClojureScript consumption
https://github.com/clojure/clojurescript/wiki/Foreign-Dependencies

On Sat, Jan 24, 2015 at 10:10 AM, 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-2719
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "0.0-2719"]
>
> ClojureScript is not an island, like Clojure on the JVM, ClojureScript
> embraces the many benefits provided by the host. However this goal
> has been hampered by another goal - the compilation stragey. Google
> Closure Compiler offers superior optimization and minification for
> ClojureScript while simultaneously making it considerably more
> difficult to integrate non-Closure compatible libraries. Using popular
> libraries like jQuery, React or D3 is an error prone process: "which
> extern did I forget?", "which script tag did I miss for development?",
> "are these script tags in dependency order?".
>
> No more. 0.0-2719 delivers full support for non-Closure compatible
> libraries through some less known features that have been lurking
> around for almost three years - `deps.cljs` and the :foreign-libs
> compiler option.
>
> `deps.cljs` is a simple EDN file provided at the root of a JAR that
> describes additional build information for the ClojureScript
> compiler. For example here is the `deps.cljs` for the React JAR I
> maintain:
>
> {
>  :foreign-libs [{:file "react/react.js"
>  :file-min "react/react.min.js"
>  :provides ["com.facebook.React"]}
> {:file "react/react_with_addons.js"
>  :file-min "react/react_with_addons.min.js"
>  :provides ["com.facebook.ReactWithAddons"]}]
>  :externs ["react/externs/react.js"]
> }
>
> This file provides all the information ClojureScript needs to
> correctly manage the foreign dependency for you under all compilation
> modes and REPLs.
>
> In a REPL:
>
>cljs.user> (require 'com.facebook.React)
>cljs.user> (. js/React
> (renderToString
>   (. js/React (DOM.div nil "Hello!"
>
> In your project:
>
>(ns foo.bar
>  (:require com.facebook.React))
>
>(enable-console-print!)
>
>(println
>  (. js/React
>(renderToString
>  (. js/React (DOM.div nil "Hello!")
>
> The above works under all compilation modes. There is no need to
> include React as a script tag under development, there is no need to put
> script tags in dependency order, there is no need to add React to
> :preamble under :advanced, and there is no need to explicitly provide
> :externs.
>
> All that is required is that JavaScript libraries be packaged in JARs
> with a `deps.cljs`.
>
> Some of you might reasonably ask why not a tool like Bower for this
> instead?  Bower requires an additional dependency on Node.js. While
> ClojureScript embraces Node.js as a useful target it is not a
> requirement to be productive. Bower manages dependencies, but in the
> Clojure world we have already embraced Maven for this task and have
> done the same for ClojureScript. Finally Bower does not address the
> problem of loading libraries at runtime. This is challenging to do -
> some JavaScript libraries adopt CommonJS, some AMD, and the most
> popular ones make no assumptions at all allowing users to simply use
> script tags as they have done for nearly two decades. The above
> solution addresses the issue for all ClojureScript users by
> eliminating paralysis of choice. Finally none of the above
> precludes Bower usage in any way whatsoever.
>
> This new feature addresses a long outstanding pain point with
> ClojureScript development. All that is required is that we take the
> time to properly package up the most popular JavaScript libraries that
> fill gaps not currently served by exising ClojureScript and Google
> Closure Library functionality.
>
> Please kick the tires and feedback is most welcome. This feature
> touched many bits of code so there are likely to be wrinkles and we want
> to get these ironed out as quickly as possible.
>
> ## 0.0-2719
>
> ### Changes
> * Full support for foreign dependencies
> * CLJS-985: make ex-info not lose stack information
> * CLJS-984: Update Node.js REPL support to use public API
> * CLJS-963: do not bother computing goog/dep.js under :none
>
> ### Fixes
> * CLJS-982: Var derefing should respect Clojure semantics
> * CLJS-980: ClojureScript REPL stacktraces overrun prompt in many cases
> * CLJS-979: ClojureScript REPL needs error handling for the special
> functions
> * CLJS-971: :reload should work for require-macros special fn
> * CLJS-980: ClojureScript REPL stacktraces overrun prompt in many cases
> * CLJS-979: ClojureScript REPL needs error handling for the special
> functions
> * CLJS-971: :reload should work for require-macros special fn
> * CLJS

Re: Testing macros that throw errors at compile time?

2015-01-24 Thread Scott Rabin 
Thanks Ben & Michael, that works!

On Thursday, January 22, 2015 at 5:08:31 PM UTC-8, Michael Blume wrote:
>
> macroexpand-1 is a good start, I'd also recommend using the (is (thrown? 
> ...)) special form, so
>
> (is (thrown? IllegalArgumentException (macroexpend-1 '(my-macro 
> (ill-formed-arguments ...)
>
> On Thu Jan 22 2015 at 5:05:36 PM Ben Wolfson  > wrote:
>
>> (try (macroexpand-1 '(my-macro (ill-formed-arguments ...)))
>>   false ;; shouldn't get here
>>   (catch Exception _ true)) ;; whole expression should be true
>>
>> As long as you know that the *right* exception is being thrown.
>>
>> On Thu, Jan 22, 2015 at 4:41 PM, Scott Rabin > > wrote:
>>
>>> We have a few macros in my employer's codebase that throw compile-time 
>>> errors when you've given them invalid configurations, and have generally 
>>> simply tested the result of these macros and not necessarily the direct 
>>> expansion of said macros. What we would like to do is *test* that the 
>>> macro blows up; but unfortunately, since this happens before tests are run, 
>>> the result is that the compiler just complains at you instead of telling 
>>> you that a specific test failed.
>>>
>>> Is there a decent way to test for thrown exceptions from macros other 
>>> than writing a few cases and saying "well, if the tests didn't even run, 
>>> it's not right!"?
>>>
>>> -- 
>>> 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.
>>>
>>
>>
>>
>> -- 
>> Ben Wolfson
>> "Human kind has used its intelligence to vary the flavour of drinks, 
>> which may be sweet, aromatic, fermented or spirit-based. ... Family and 
>> social life also offer numerous other occasions to consume drinks for 
>> pleasure." [Larousse, "Drink" entry]
>>
>>  -- 
>> 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.

[ANN] Buddy 0.3.0: Security library for clojure.

2015-01-24 Thread Andrey Antukh 
Hi!

I am happy to announce a new release of buddy (security library for
Clojure).

Since 0.3.0, buddy is split from monolithic library in four modules:

- buddy-core: Cryptographyc api.
- buddy-sign: High level message signing
- buddy-auth: Authentication and Authorization facilities for ring based
web apps.
- buddy-hashers: Collection of password hashers.

Relevant changes on some modules:

buddy-hashers:

- Code refactored in more extensible way (based on multimethods)
- Unify in one namespace. Now, independently of hasher you should import
only one namespace.
- Hasher verification autodetects the hasher that should be used for verify
the password.
- Add pbkdf2+sha256 and pbkdf-sha3_256

buddy-auth:
- Add support for more extensible way to raise unauthorized exception based
on slingshot and clojure protocols.
- Add clout syntax and some other little improvements from
https://github.com/yogthos/ring-access-rules
- Bugfixes on some backends related to headers parsing.
- Add better examples.

Other two modules does not includes new changes or has small and not
relevant ones after library splitting.

Github:
https://github.com/funcool/buddy-core
https://github.com/funcool/buddy-auth
https://github.com/funcool/buddy-hashers
https://github.com/funcool/buddy-sign

Documentation:
https://funcool.github.io/buddy-core/latest/
https://funcool.github.io/buddy-auth/latest/
https://funcool.github.io/buddy-hashers/latest/
https://funcool.github.io/buddy-sign/latest/

Since this release, each module will evolve independently. I thing, that
this approach will help users to include only the necessary parts from
buddy instead of including one monolithic library.

Cheers.
Andrey
-- 
Andrey Antukh - Андрей Антух -  / 
http://www.niwi.be 
https://github.com/niwibe

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

Help: Instantiating a known record from an unknown namespace

2015-01-24 Thread Elric Erkose 
Hello,

I have an app which specifies a protocol and a record name. At runtime, it 
searches the classpath for files implementing the specification and creates 
a map of namespace to instance for each. Before I implemented the protocol, 
I just specified function names. I was able to lookup the function names 
and call them. After I switched to using a protocol, I get a 
CompilerException.

Here's the question: How do I instantiate a known record from an unknown 
namespace?

Here is the sample code. Thanks for you help.

```clojure
(ns proto)

(defprotocol Proto
  (meth [this]))

;; use clojure.tools.namespace.find to locate the namespace.
;; for simplicity, we just def it here.
(def that 'rec)

(require that)

;; the symbol "Rec" is part of the specification
(let [inst (ns-resolve that (symbol "Rec"))]
  (when (class? inst)
(println "inst:" (type inst) inst)
;; => java.lang.Class rec.Rec

(println "meth:" (meth (new rec.Rec)))
;; => it works when I know it.

;; uncomment this for a CompilerException
;;(println "meth:" (meth (new inst)))
;; => CompilerException java.lang.IllegalArgumentException:
;;  Unable to resolve classname: inst, compiling:(proto.clj:21:28)
))
```

```clojure
(ns rec
  (:require proto))

(defrecord Rec []
  proto.Proto
  (meth [this] "it works when I know 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.

Re: ANN: ClojureScript 0.0-2719, JavaScript Dependencies

2015-01-24 Thread David Nolen 
I just cut 0.0-2723. The significant change is an often requested feature -
that script inclusion for :none be the same as other build settings. This
is finally supported if you provide a :main entry specifying a namespace.

{:main hello-world.core
 :output-to "hello_world.js"
 :output-dir "out"
 :optimizations :none
 :source-map true}

Then your markup just needs:



Same as :advanced.

David

On Sat, Jan 24, 2015 at 10:10 AM, 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-2719
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "0.0-2719"]
>
> ClojureScript is not an island, like Clojure on the JVM, ClojureScript
> embraces the many benefits provided by the host. However this goal
> has been hampered by another goal - the compilation stragey. Google
> Closure Compiler offers superior optimization and minification for
> ClojureScript while simultaneously making it considerably more
> difficult to integrate non-Closure compatible libraries. Using popular
> libraries like jQuery, React or D3 is an error prone process: "which
> extern did I forget?", "which script tag did I miss for development?",
> "are these script tags in dependency order?".
>
> No more. 0.0-2719 delivers full support for non-Closure compatible
> libraries through some less known features that have been lurking
> around for almost three years - `deps.cljs` and the :foreign-libs
> compiler option.
>
> `deps.cljs` is a simple EDN file provided at the root of a JAR that
> describes additional build information for the ClojureScript
> compiler. For example here is the `deps.cljs` for the React JAR I
> maintain:
>
> {
>  :foreign-libs [{:file "react/react.js"
>  :file-min "react/react.min.js"
>  :provides ["com.facebook.React"]}
> {:file "react/react_with_addons.js"
>  :file-min "react/react_with_addons.min.js"
>  :provides ["com.facebook.ReactWithAddons"]}]
>  :externs ["react/externs/react.js"]
> }
>
> This file provides all the information ClojureScript needs to
> correctly manage the foreign dependency for you under all compilation
> modes and REPLs.
>
> In a REPL:
>
>cljs.user> (require 'com.facebook.React)
>cljs.user> (. js/React
> (renderToString
>   (. js/React (DOM.div nil "Hello!"
>
> In your project:
>
>(ns foo.bar
>  (:require com.facebook.React))
>
>(enable-console-print!)
>
>(println
>  (. js/React
>(renderToString
>  (. js/React (DOM.div nil "Hello!")
>
> The above works under all compilation modes. There is no need to
> include React as a script tag under development, there is no need to put
> script tags in dependency order, there is no need to add React to
> :preamble under :advanced, and there is no need to explicitly provide
> :externs.
>
> All that is required is that JavaScript libraries be packaged in JARs
> with a `deps.cljs`.
>
> Some of you might reasonably ask why not a tool like Bower for this
> instead?  Bower requires an additional dependency on Node.js. While
> ClojureScript embraces Node.js as a useful target it is not a
> requirement to be productive. Bower manages dependencies, but in the
> Clojure world we have already embraced Maven for this task and have
> done the same for ClojureScript. Finally Bower does not address the
> problem of loading libraries at runtime. This is challenging to do -
> some JavaScript libraries adopt CommonJS, some AMD, and the most
> popular ones make no assumptions at all allowing users to simply use
> script tags as they have done for nearly two decades. The above
> solution addresses the issue for all ClojureScript users by
> eliminating paralysis of choice. Finally none of the above
> precludes Bower usage in any way whatsoever.
>
> This new feature addresses a long outstanding pain point with
> ClojureScript development. All that is required is that we take the
> time to properly package up the most popular JavaScript libraries that
> fill gaps not currently served by exising ClojureScript and Google
> Closure Library functionality.
>
> Please kick the tires and feedback is most welcome. This feature
> touched many bits of code so there are likely to be wrinkles and we want
> to get these ironed out as quickly as possible.
>
> ## 0.0-2719
>
> ### Changes
> * Full support for foreign dependencies
> * CLJS-985: make ex-info not lose stack information
> * CLJS-984: Update Node.js REPL support to use public API
> * CLJS-963: do not bother computing goog/dep.js under :none
>
> ### Fixes
> * CLJS-982: Var derefing should respect Clojure semantics
> * CLJS-980: ClojureScript REPL stacktraces overrun prompt in many cases
> * CLJS-979: ClojureScript REPL needs error handling for the special
> functions
> * CLJS-971: :reload should work for require-macro

Re: ANN: ClojureScript 0.0-2719, JavaScript Dependencies

2015-01-24 Thread David Nolen 
And just cut 0.0-2725 to address a Node.js target support regression.

David

On Sat, Jan 24, 2015 at 10:10 AM, 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-2719
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "0.0-2719"]
>
> ClojureScript is not an island, like Clojure on the JVM, ClojureScript
> embraces the many benefits provided by the host. However this goal
> has been hampered by another goal - the compilation stragey. Google
> Closure Compiler offers superior optimization and minification for
> ClojureScript while simultaneously making it considerably more
> difficult to integrate non-Closure compatible libraries. Using popular
> libraries like jQuery, React or D3 is an error prone process: "which
> extern did I forget?", "which script tag did I miss for development?",
> "are these script tags in dependency order?".
>
> No more. 0.0-2719 delivers full support for non-Closure compatible
> libraries through some less known features that have been lurking
> around for almost three years - `deps.cljs` and the :foreign-libs
> compiler option.
>
> `deps.cljs` is a simple EDN file provided at the root of a JAR that
> describes additional build information for the ClojureScript
> compiler. For example here is the `deps.cljs` for the React JAR I
> maintain:
>
> {
>  :foreign-libs [{:file "react/react.js"
>  :file-min "react/react.min.js"
>  :provides ["com.facebook.React"]}
> {:file "react/react_with_addons.js"
>  :file-min "react/react_with_addons.min.js"
>  :provides ["com.facebook.ReactWithAddons"]}]
>  :externs ["react/externs/react.js"]
> }
>
> This file provides all the information ClojureScript needs to
> correctly manage the foreign dependency for you under all compilation
> modes and REPLs.
>
> In a REPL:
>
>cljs.user> (require 'com.facebook.React)
>cljs.user> (. js/React
> (renderToString
>   (. js/React (DOM.div nil "Hello!"
>
> In your project:
>
>(ns foo.bar
>  (:require com.facebook.React))
>
>(enable-console-print!)
>
>(println
>  (. js/React
>(renderToString
>  (. js/React (DOM.div nil "Hello!")
>
> The above works under all compilation modes. There is no need to
> include React as a script tag under development, there is no need to put
> script tags in dependency order, there is no need to add React to
> :preamble under :advanced, and there is no need to explicitly provide
> :externs.
>
> All that is required is that JavaScript libraries be packaged in JARs
> with a `deps.cljs`.
>
> Some of you might reasonably ask why not a tool like Bower for this
> instead?  Bower requires an additional dependency on Node.js. While
> ClojureScript embraces Node.js as a useful target it is not a
> requirement to be productive. Bower manages dependencies, but in the
> Clojure world we have already embraced Maven for this task and have
> done the same for ClojureScript. Finally Bower does not address the
> problem of loading libraries at runtime. This is challenging to do -
> some JavaScript libraries adopt CommonJS, some AMD, and the most
> popular ones make no assumptions at all allowing users to simply use
> script tags as they have done for nearly two decades. The above
> solution addresses the issue for all ClojureScript users by
> eliminating paralysis of choice. Finally none of the above
> precludes Bower usage in any way whatsoever.
>
> This new feature addresses a long outstanding pain point with
> ClojureScript development. All that is required is that we take the
> time to properly package up the most popular JavaScript libraries that
> fill gaps not currently served by exising ClojureScript and Google
> Closure Library functionality.
>
> Please kick the tires and feedback is most welcome. This feature
> touched many bits of code so there are likely to be wrinkles and we want
> to get these ironed out as quickly as possible.
>
> ## 0.0-2719
>
> ### Changes
> * Full support for foreign dependencies
> * CLJS-985: make ex-info not lose stack information
> * CLJS-984: Update Node.js REPL support to use public API
> * CLJS-963: do not bother computing goog/dep.js under :none
>
> ### Fixes
> * CLJS-982: Var derefing should respect Clojure semantics
> * CLJS-980: ClojureScript REPL stacktraces overrun prompt in many cases
> * CLJS-979: ClojureScript REPL needs error handling for the special
> functions
> * CLJS-971: :reload should work for require-macros special fn
> * CLJS-980: ClojureScript REPL stacktraces overrun prompt in many cases
> * CLJS-979: ClojureScript REPL needs error handling for the special
> functions
> * CLJS-971: :reload should work for require-macros special fn
> * CLJS-936: Multi arity bitwise operators
> * CLJS-962: fix inconsistent hashing of e

Re: Clojurescript to target JVM?

2015-01-24 Thread Gerrit Begher 
Hi Sam;

I'm currently trying to get some functions written in clojure(-script) 
running on Android, wrapping them in a java class generated by rhino. 

Currently, I'm stuck at overcoming the 64k limit. Could you explain the 
splitting process in some greater detail?

All the best,
Gerrit

PS ~ Any eta on Lambdroid?

Am Samstag, 22. November 2014 04:18:21 UTC+1 schrieb Sam Beran:
>
> The code is still half-baked, but in leu of a blog post or code, I can 
> summarize my reasoning and approach:
>
>
> *ClojureScript is Designed With UI Responsiveness In Mind*
>
> At present, JVM Clojure is not currently suitable for Android development.
>  Since Android applications are structured around ephemeral Activities, 
> any startup penalty over 250 ms is simply unacceptable. Current benchmarks 
> [1] are showing 2-5 seconds of startup time, and I have seen no 
> straightforward advice on how to achieve an order-of-magnitude increase in 
> startup performance. ClojureScript (and JavaScript) is designed from the 
> ground up with startup speed in mind. ClojureScript can be used to create 
> responsive user interfaces on Android. 
>
>
> *Selecting a Host Runtime*
>
> In order to run ClojureScript on Android, I considered the following 
> options for host runtimes:
>
>- *Android WebView * - we can achieve reasonable startup times with a 
>WebView, however any data must be serialized and deserialized in order to 
>communicate between a WebView and Java. Even worse, any long-running 
> object 
>lifecycles must be manually managed, since we cannot rely on garbage 
>collection to maintain object references between the host VM and those of 
>the WebView.
>- *V8 (JNI) - *I briefly considered compiling a V8 runtime to host 
>ClojureScript. Startup speed would probably outperform the WebView. This 
>would be a lot of work to develop a nice bridging mechanism. Object 
>lifecycle management is better than WebView, but still not ideal. With no 
>C++ or JNI background, I could tell very quickly that this would not be a 
>"weekend project".
>- *Rhino* - Rhino is a lightweight JavaScript runtime for the JVM. 
>Execution speed is not fast, and since Rhino is not actively maintained, 
> it 
>will probably never support ES6 - not huge concerns for ClojureScript. 
>Since Rhino is a pure-Java runtime, there is very little overhead when 
>communicating between JS<-> Java, and Java GC can be used to maintain 
>object lifecycles.
>- *Nashorn *- the successor to rhino. Not an option until Android 
>supports InvokeDynamic.[2]
>
>
>
> *Achieving Fast Startup on Rhino*
>
> When I initially ran ClojureScript on Rhino, Startup speed was around 8-10 
> seconds - even worse than JVM Clojure! Some quick measurements indicated 
> that the bulk of the time was spent with Rhino parsing the JS sources for 
> cljs/core.js. I was pleased to discover that Rhino supports bytecode 
> precompilation via the jsc utility [3]. I was able to precompile the 
> ClojureScript output to bytecode, and achieve *much faster startup - 
> around 150ms on device*. This is well within the target performance 
> range, and is fast enough to eliminate any noticeable UI lag. 
>
> One hurdle I ran into is the 64k method size limit for Java classes. Since 
> jsc compiles all .js files to a single method in a Java class, compiling 
> cljs/core.js caused errors when compiling to bytecode. I was able to get 
> around this by splitting the JS files in half during the build process 
> until they were small enough to compile. *I have since implemented some 
> optimizations which bring the startup overhead of ClojureScript down to < 
> 100 ms.*
>
>
> *Pure ClojureScript Android Applications*
>
> Since I am precompiling the ClojureScript sources, I can also generate 
> Java classes using ClojureScript macros. Here is an example of an Android 
> Activity written in ClojureScript. This activity is compiled to Java in a 
> similar manner to Clojure's gen-class mechanism: 
>
> (ns cljs-hello.core
> (:require-macros [lambdroid.compile :refer [java-class]]))
>
> (java-class
> {:name "io.lambdroid.MyActivity"
>  :extends android.app.Activity})
>
> (defn ^:override onCreate [this ^android.os.Bundle state]
>   (.onCreate this state)
>   (.setContentView this io.lambdroid.R.layout/activity_hello_world)
>   (.setText (.findViewById this io.lambdroid.R.id/message 
> )
> "Hello From ClojureScript"))
>
>
> Note that this generated activity class is created by Android directly and 
> has full access to Android asset bundles, so users of this library *will 
> not need to write any Java whatsoever* .
>
>
> *Next Steps*
>
> There are a few things I still need to do before releasing code:
>
>
>- Extract build logic into Gradle plugin - it is currently just some 
>build scripts in an example app.
>- Build an Android REPL that can run in the context of the current 
>

Re: Help: Instantiating a known record from an unknown namespace

2015-01-24 Thread Fluid Dynamics 
On Saturday, January 24, 2015 at 1:43:15 PM UTC-5, Elric Erkose wrote:
>
> Hello,
>
> I have an app which specifies a protocol and a record name. At runtime, it 
> searches the classpath for files implementing the specification and creates 
> a map of namespace to instance for each. Before I implemented the protocol, 
> I just specified function names. I was able to lookup the function names 
> and call them. After I switched to using a protocol, I get a 
> CompilerException.
>
> Here's the question: How do I instantiate a known record from an unknown 
> namespace?
>
> Here is the sample code. Thanks for you help.
>
> ```clojure
> (ns proto)
>
> (defprotocol Proto
>   (meth [this]))
>
> ;; use clojure.tools.namespace.find to locate the namespace.
> ;; for simplicity, we just def it here.
> (def that 'rec)
>
> (require that)
>
> ;; the symbol "Rec" is part of the specification
> (let [inst (ns-resolve that (symbol "Rec"))]
>   (when (class? inst)
> (println "inst:" (type inst) inst)
> ;; => java.lang.Class rec.Rec
> 
> (println "meth:" (meth (new rec.Rec)))
> ;; => it works when I know it.
>
> ;; uncomment this for a CompilerException
> ;;(println "meth:" (meth (new inst)))
> ;; => CompilerException java.lang.IllegalArgumentException:
> ;;  Unable to resolve classname: inst, compiling:(proto.clj:21:28)
> ))
> ```
>
> ```clojure
> (ns rec
>   (:require proto))
>
> (defrecord Rec []
>   proto.Proto
>   (meth [this] "it works when I know it"))
> ```
>

The new special form doesn't evaluate its argument, so "inst" results in 
looking for a classname of "inst", not whatever inst is bound to. (eval 
`(new ~inst)) might work though. 

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

2015-01-24 Thread Moritz Ulrich 
Fluid Dynamics  writes:

> On Saturday, January 24, 2015 at 1:43:15 PM UTC-5, Elric Erkose wrote:
>>
>> Hello,
>>
>> I have an app which specifies a protocol and a record name. At runtime, it 
>> searches the classpath for files implementing the specification and creates 
>> a map of namespace to instance for each. Before I implemented the protocol, 
>> I just specified function names. I was able to lookup the function names 
>> and call them. After I switched to using a protocol, I get a 
>> CompilerException.
>>
>> Here's the question: How do I instantiate a known record from an unknown 
>> namespace?
>>
>> Here is the sample code. Thanks for you help.
>>
>> ```clojure
>> (ns proto)
>>
>> (defprotocol Proto
>>   (meth [this]))
>>
>> ;; use clojure.tools.namespace.find to locate the namespace.
>> ;; for simplicity, we just def it here.
>> (def that 'rec)
>>
>> (require that)
>>
>> ;; the symbol "Rec" is part of the specification
>> (let [inst (ns-resolve that (symbol "Rec"))]
>>   (when (class? inst)
>> (println "inst:" (type inst) inst)
>> ;; => java.lang.Class rec.Rec
>> 
>> (println "meth:" (meth (new rec.Rec)))
>> ;; => it works when I know it.
>>
>> ;; uncomment this for a CompilerException
>> ;;(println "meth:" (meth (new inst)))
>> ;; => CompilerException java.lang.IllegalArgumentException:
>> ;;  Unable to resolve classname: inst, compiling:(proto.clj:21:28)
>> ))
>> ```
>>
>> ```clojure
>> (ns rec
>>   (:require proto))
>>
>> (defrecord Rec []
>>   proto.Proto
>>   (meth [this] "it works when I know it"))
>> ```
>>
>
> The new special form doesn't evaluate its argument, so "inst" results in 
> looking for a classname of "inst", not whatever inst is bound to. (eval 
> `(new ~inst)) might work though. 
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" 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.


Using `eval' here is like shooting sparrows with cannons. While I
despise the latter and wouldn't help with that, a better solution for
the former is the `newInstance' method of java.lang.Class:

(let [c java.lang.String]
  (.newInstance c)) 
; => ""

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


signature.asc
Description: PGP signature

Re: Help: Instantiating a known record from an unknown namespace

2015-01-24 Thread Elric Erkose 
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.

Re: ANN: ClojureScript 0.0-2719, JavaScript Dependencies

2015-01-24 Thread David Nolen 
Just cut 0.0-2727 to fix an issue around the new :main support.
ClojureScript now supports an :asset-path option to control how the :main
script imports other scripts in order to respect whatever asset
configuration you may have set up for your web server.

David

On Sat, Jan 24, 2015 at 4:22 PM, David Nolen  wrote:

> And just cut 0.0-2725 to address a Node.js target support regression.
>
> David
>
> On Sat, Jan 24, 2015 at 10:10 AM, 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-2719
>>
>> Leiningen dependency information:
>>
>> [org.clojure/clojurescript "0.0-2719"]
>>
>> ClojureScript is not an island, like Clojure on the JVM, ClojureScript
>> embraces the many benefits provided by the host. However this goal
>> has been hampered by another goal - the compilation stragey. Google
>> Closure Compiler offers superior optimization and minification for
>> ClojureScript while simultaneously making it considerably more
>> difficult to integrate non-Closure compatible libraries. Using popular
>> libraries like jQuery, React or D3 is an error prone process: "which
>> extern did I forget?", "which script tag did I miss for development?",
>> "are these script tags in dependency order?".
>>
>> No more. 0.0-2719 delivers full support for non-Closure compatible
>> libraries through some less known features that have been lurking
>> around for almost three years - `deps.cljs` and the :foreign-libs
>> compiler option.
>>
>> `deps.cljs` is a simple EDN file provided at the root of a JAR that
>> describes additional build information for the ClojureScript
>> compiler. For example here is the `deps.cljs` for the React JAR I
>> maintain:
>>
>> {
>>  :foreign-libs [{:file "react/react.js"
>>  :file-min "react/react.min.js"
>>  :provides ["com.facebook.React"]}
>> {:file "react/react_with_addons.js"
>>  :file-min "react/react_with_addons.min.js"
>>  :provides ["com.facebook.ReactWithAddons"]}]
>>  :externs ["react/externs/react.js"]
>> }
>>
>> This file provides all the information ClojureScript needs to
>> correctly manage the foreign dependency for you under all compilation
>> modes and REPLs.
>>
>> In a REPL:
>>
>>cljs.user> (require 'com.facebook.React)
>>cljs.user> (. js/React
>> (renderToString
>>   (. js/React (DOM.div nil "Hello!"
>>
>> In your project:
>>
>>(ns foo.bar
>>  (:require com.facebook.React))
>>
>>(enable-console-print!)
>>
>>(println
>>  (. js/React
>>(renderToString
>>  (. js/React (DOM.div nil "Hello!")
>>
>> The above works under all compilation modes. There is no need to
>> include React as a script tag under development, there is no need to put
>> script tags in dependency order, there is no need to add React to
>> :preamble under :advanced, and there is no need to explicitly provide
>> :externs.
>>
>> All that is required is that JavaScript libraries be packaged in JARs
>> with a `deps.cljs`.
>>
>> Some of you might reasonably ask why not a tool like Bower for this
>> instead?  Bower requires an additional dependency on Node.js. While
>> ClojureScript embraces Node.js as a useful target it is not a
>> requirement to be productive. Bower manages dependencies, but in the
>> Clojure world we have already embraced Maven for this task and have
>> done the same for ClojureScript. Finally Bower does not address the
>> problem of loading libraries at runtime. This is challenging to do -
>> some JavaScript libraries adopt CommonJS, some AMD, and the most
>> popular ones make no assumptions at all allowing users to simply use
>> script tags as they have done for nearly two decades. The above
>> solution addresses the issue for all ClojureScript users by
>> eliminating paralysis of choice. Finally none of the above
>> precludes Bower usage in any way whatsoever.
>>
>> This new feature addresses a long outstanding pain point with
>> ClojureScript development. All that is required is that we take the
>> time to properly package up the most popular JavaScript libraries that
>> fill gaps not currently served by exising ClojureScript and Google
>> Closure Library functionality.
>>
>> Please kick the tires and feedback is most welcome. This feature
>> touched many bits of code so there are likely to be wrinkles and we want
>> to get these ironed out as quickly as possible.
>>
>> ## 0.0-2719
>>
>> ### Changes
>> * Full support for foreign dependencies
>> * CLJS-985: make ex-info not lose stack information
>> * CLJS-984: Update Node.js REPL support to use public API
>> * CLJS-963: do not bother computing goog/dep.js under :none
>>
>> ### Fixes
>> * CLJS-982: Var derefing should respect Clojure semantics
>> * CLJS-980: ClojureScript REPL stacktraces overrun prompt in many cases
>> * CLJS-979: C

Re: Clojurescript to target JVM?

2015-01-24 Thread Alan Moore 
inline...

On Thursday, January 15, 2015 at 8:47:34 AM UTC-8, Adam Clements wrote:
>
> I've been looking at getting my startup time down on my Clojure on android 
> app (it needs to be at least an order of magnitude smaller before I can 
> ship), and revisited this as a potential candidate. The biggest friction 
> point was that I would have to change which libraries I use and revisit all 
> the java interop to make it work nicely as clojurescript.
>
>>
>>- 
>> * V8 (JNI) - *I briefly considered compiling a V8 runtime to host 
>>ClojureScript. Startup speed would probably outperform the WebView. This 
>>would be a lot of work to develop a nice bridging mechanism. Object 
>>lifecycle management is better than WebView, but still not ideal. With no 
>>C++ or JNI background, I could tell very quickly that this would not be a 
>>"weekend project".
>>
>> You might want to check out duktape:

http://duktape.org/

It claims ES5 and some preliminary features from ES6. It is an interpreter 
so it will be slower than V8 but it would only take a day or two to get it 
going. Duktape is part of the IOT effort by the AllSeen Aliance (Linux 
Foundation) and has lots of support so I'm guessing it will be a viable 
tool for some time to come:

https://allseenalliance.org/
https://wiki.allseenalliance.org/_media/training/programming_alljoyn.js.pdf

The startup performance might be sufficient for your needs - TBD. If it 
doesn't work you are only out a weekend :-) 

I could help you with the C++ part (my day job is embedded systems C++) and 
I have been wanting to give duktape a try with ClojureScript anyway.

Take care.

Alan

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

2015-01-24 Thread Makoto H. 
I am update om to 0.8.2, then:require causes an error.

(ns om-app.hello
  (:require [om.core :as om :include-macros true]
[om.dom :as dom :include-macros true]
)
)

clojure.lang.ExceptionInfo: No such namespace: com.facebook.React at line 1 
file:/maven/.m2/repository/org/omcljs/om/0.8.2/om-0.8.2.jar!/om/dom.cljs {:tag 
:cljs/analysis-error, :file 
"file:/maven/.m2/repository/org/omcljs/om/0.8.2/om-0.8.2.jar!/om/dom.cljs", 
:line 1, :column 1}

I declared cljs and om libs in project.clj as follows:

[org.clojure/clojurescript "0.0-2727" :scope "provided"]
[org.omcljs/om "0.8.2"]
;;[org.om/om "0.8.1"]

The om 0.8.1 works fine.
Is there any suggestion ?

Makoto

> The dependency information has changed:
> 
> 
> [org.omcljs/om "0.8.2"]
> 
> 
> 
> The release depends on ClojureScript 0.0-2719 as it leverages the new foreign 
> dependency functionality to simplify development and production builds.
> 
> 
> 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/d/optout.