[ClojureScript] Possible bug in cljs.js

2016-02-27 Thread Nikita Beloglazov 
Hello

Playing with bootstrapped cljs I noticed that :analyze-deps doesn't work
correctly. Setting it to false doesn't make any effect and deps are still
being analyzed. I checked source code and it seems like :analyze-deps and
:load-macros are always true regardless what you provide:

For example:
https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/js.cljs#L225
:*load-macros* (or (:load-macros opts) true)
:*analyze-deps* (or (:analyze-deps opts) true)

Both these variables are always truthy. I think correct version is
(:load-macros opts true) instead of using or in this case unless it is
intentionally written this way to "disable" :load-macros/:analyze-deps
options.

Thanks,
Nikita

-- 
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 clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] [ANN] kvlt 0.1.0: JVM/Node/browser HTTP client

2016-02-27 Thread Moe Aboulkheir 
kvlt is an HTTP client library which runs on the JVM, Node & in browser,
including support for server-sent events and websockets.

Github project page 
Documentation & examples 

*Motivation*: while there exist dual-targeted HTTP clients, Node
compatibility doesn't appear to be a concern.  Further, related
functionality - websockets & server-sent events - isn't available uniformly
across clj+cljs, and the Clojurescript implementations are tied to APIs
which don't exist on Node out of the box.

kvlt uses Aleph  on the JVM, and Google
Closure's XHR abstraction
 in
Clojurescript, with a third-party Node module providing an XHR
implementation when running off-browser.  The same pattern is used for
websockets/SSE (emulating browser APIs with third-party modules).

Responses can be consumed using either promises (via promesa
), or core.async, with the latter being
used to represent websocket connections/SSE streams.

Take care,
Moe

-- 
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 clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] Re: [:ann] urania: a library for elegant and efficient remote data access

2016-02-27 Thread Alejandro Gómez 
On Sat, Feb 27, 2016, at 17:13, Teemu Kaukoranta wrote:
> I'm curious how exactly is this different from Muse? What made you create
> another project that to mee loks very similar?

Great question, there are many differences between urania and muse.
First of all, the patches to Muse that fixed some issues have been
merged. I moved away from core.async as the result type since there is
no way to signal errors in channels, refactored the code and added a few
more tests, fixing a couple bugs along the way. I also changed some
design decissions, like adding an `-identity` function to data sources
and not try to infer it, or eliminating some differences between Clojure
and ClojureScript.

I also plan to actively mantain and develop the library further.

Hope to have answered your question.

Yours,

Alejandro

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

-- 
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 clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] Re: [:ann] urania: a library for elegant and efficient remote data access

2016-02-27 Thread Teemu Kaukoranta 
On Saturday, 27 February 2016 12:16:20 UTC+2, Alejandro Gómez  wrote:
> The library is based in the initial work in Muse
> by Alexey Kachayev but has evolved on its own. It also borrows heavily
> from the Haskell Haxl library, and is meant for the same purpose.

I'm curious how exactly is this different from Muse? What made you create 
another project that to mee loks very similar?

-- 
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 clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] Re: Om.Next <=> GraphQL/Relay

2016-02-27 Thread Marc Fawzi 
To close the loop on the Limitations part of my GraphQL/Relay conceptual
ealuation :)

Limitations

Query resolution in GraphQL is defined in the schema, which implements data
model transformations that maybe evaluated as part of the the query, e.g.
OrderBy, InRange, hasSomeRelation etc.

This carries the interesting implication that GraphQL cannot be used (on
its own) to support the kind of cient-defined queries that require ad-hoc
model transformations. An example would be an app that allows the user to
slice and dice her data in an arbitrary fashion.

Here are the responses I got to the above:

[image: twitter response]


If we stop thinking of GraphQL as a Graph Query Language in the Graph DB
sense, which it's not, and instead think of it as Graph-y RPC Language then
it makes sense to use a Query DSL. The confusion beginners often have is
with the idea implied by GraphQL, i.e. a graph query language. The chosen
name is GraphQL where Q stands for "Query" but in reality it's a "Graph-y
RPC Language" or "Graph-based Extensible API Protocol."

>><<

*So my question is do we have something similar or better than
GraphQL/Relay in the Clojure/Script world? Om.Next/Datomic?  or is that a
very different model? asking naively since I've not had a chance to play
with Om.Next/Datomic yet, but is there a reason to? Can it be better than
the GraphQL/Relay combination? If so, in what ways?*



On Thu, Feb 25, 2016 at 6:19 PM, Marc Fawzi  wrote:

> Didn't take me long before I zoomed in on the dark side of GraphQL :) like
> a magnet
>
> See under "Limitations"
>
> https://gist.github.com/idibidiart/49a095b6bc528638f34f
>
> Sent from my iPhone
>
> On Feb 19, 2016, at 8:41 PM, Marc Fawzi  wrote:
>
>
> So, I'm having great fun playing with an in-house implementation of the
> GraphQL spec (extended to do more, and some custom-y things) and I wanted
> to share the rational for our adoption of GraphQL/Relay with the
> Clojure/Script in hope that I can see how it differs from Om.Next + Datomic
> (or whatever Om.Next uses on the backend) from enlightened folks
>
> For me this kind of 'deep architecture' is unattainable via things like
> Reagent/Reframe and Om.Next is probably (I'm thinking out loud here) the
> closest option for those of us who like to stay within the Clojure/Script
> ecosystem.
>
> Please feel free to take this post apart
>
> https://gist.github.com/idibidiart/49a095b6bc528638f34f
>
> and let us know if we're missing anything.
>
> I focused on Redux + Reselect in my critique but the same applies to
> Reframe, which is what Redux/Reselect aims to mimic in the JS world.
>
> Also, for another perspective on this topic of comparing advances in JS to
> state of the art in ClojureScript, someone from the GraphQL team tweeted
> this last week, and so I feel obliged to include it, although I've yet to
> read it myself (life is short)
>
>
> http://hueypetersen.com/posts/2016/02/13/om-next-from-a-relay-graphql-perspective/
>
> Cheers
>
> Marc
>
>

-- 
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 clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] [:ann] urania: a library for elegant and efficient remote data access

2016-02-27 Thread Alejandro Gómez 
Hello everyone,

I'm happy to announce the first release of urania, a library for making
fetching data from remote sources such as databases or HTTP services
elegant and efficient. The library is based in the initial work in Muse
by Alexey Kachayev but has evolved on its own. It also borrows heavily
from the Haskell Haxl library, and is meant for the same purpose.

Future plans include a pluggable type for using it with other
error-aware asynchronous abstractions such as manifold deferreds and a
let-like macro for declaring data fetches.

As always, any feedback is appreciated!

Urania on GitHub: https://github.com/funcool/urania
Urania docs: http://funcool.github.io/urania/latest/
Muse on GitHub: https://github.com/kachayev/muse
Haxl on GitHub: https://github.com/facebook/Haxl

Yours,

Alejandro

-- 
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 clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

Re: [ClojureScript] Re: ClojureScript and multi-page website

2016-02-27 Thread Thomas Heller 
If you want you can try shadow-build. It supports modules all the way (ie. 
:none). It has some figwheel-ish features (REPL, live-reload) but basically no 
documentation, so a little patience is required. It is pretty simple, just very 
different from other build tools.

See:
https://github.com/thheller/shadow-build
https://github.com/thheller/shadow-build-example

Happy to help if you have any questions.

Cheers,
/thomas

On Saturday, February 27, 2016 at 3:47:34 AM UTC+1, J David Eisenberg wrote:
> On Friday, February 26, 2016 at 5:30:45 PM UTC-8, Francis Avila wrote:
> > And obviously when I said "websockets" above I meant "webworkers"!
> 
> It works just great; thanks. Sadly, it doesn't seem to be compatible with 
> figwheel, as figwheel requires :optimizations :none, but :modules requires 
> :optimizations :simple
> 
> > 
> > 
> > On Fri, Feb 26, 2016 at 7:29 PM, Francis Avila  wrote:
> > 
> > Don't forget the reference documentation: 
> > https://github.com/clojure/clojurescript/wiki/Compiler-Options#modules
> > 
> > 
> > 
> > 
> > On Fri, Feb 26, 2016 at 6:07 PM, J David Eisenberg  
> > wrote:
> > On Friday, February 26, 2016 at 2:52:28 PM UTC-8, Francis Avila wrote:
> > 
> > > I think what you want are multiple Google Closure modules: 
> > > http://swannodette.github.io/2015/02/23/hello-google-closure-modules/
> > 
> > >
> > 
> > > Make a single project for all pages, place each page's entry point into a 
> > > separate namespace and an independent module, and then on each html page 
> > > include the common module followed by the page-specific module. The 
> > > Closure (not cloJure!) compiler will work out the js dependency graph and 
> > > move code among the files optimally so you only have as much javascript 
> > > per page as you need.
> > 
> > >
> > 
> > > This technique also works great with websockets: have browser-thread 
> > > entrypoints in their own module and websocket entry points in another 
> > > module. If you make sure the websocket entry points can't reach code that 
> > > uses browser objects (like document or window) everything will Just Work.
> > 
> > 
> > 
> > Thank you; it seems that this will do what I want, and the article about it 
> > arrived JIT. :)
> > 
> > 
> > 
> > 
> > 
> > >
> > 
> > > On Friday, February 26, 2016 at 3:31:23 PM UTC-6, J David Eisenberg wrote:
> > 
> > > > I'm working on a web site which, for various reasons, achieves its 
> > > > purpose best with multiple pages rather than as a single-page app. All 
> > > > the pages will need to share some code in common.
> > 
> > > >
> > 
> > > > In a plain vanilla JS environment, I could do something like this on 
> > > > page1.html:
> > 
> > > >
> > 
> > > > 
> > 
> > > > 
> > 
> > > >
> > 
> > > > and something similar on page2.html (with