This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-07-29
Channels
- # admin-announcements (48)
- # announcements (1)
- # beginners (80)
- # boot (150)
- # cljs-dev (12)
- # clojure (133)
- # clojure-dev (1)
- # clojure-italy (27)
- # clojure-japan (1)
- # clojure-russia (77)
- # clojurescript (236)
- # clojutre (3)
- # code-reviews (1)
- # core-async (14)
- # core-logic (4)
- # core-matrix (15)
- # cursive (5)
- # datomic (30)
- # editors (16)
- # events (1)
- # hoplon (1)
- # ldnclj (17)
- # off-topic (30)
- # om (2)
- # onyx (47)
- # reagent (8)
In case you were curios about bootstrapped ClojureScript and macros, they’re for real. https://youtu.be/0uEx-hpMHhU
we've got about 12 of us going through Clojure for the Brave and True together in LivingSocial right now, and I am hoping to have one of those weekly sessions be about clojurescript
mfikes: you cheated! normally videos require some editing to get that kind of repl startup time :)
@nullptr To be fair, it takes up to a full second for the JavaScript runtime to complete initializing on my computer, and perhaps 1/2 s on a modern iMac. But, that time might as well be a tree falling in the woods for that kind of use.
@dnolen: I ran script/build
in master, and it created the release tag r2
looks like its possible for tags to collide since they count up from the most recent major.minor version?
@shaunlebron: good catch fixed
Anyone know why goog.net.Jsonp evaluates to nil? Importing it doesn’t seem to make much of a difference.
Seems to be the same for others as well, e.g. goog.net.Ipv6Address, but not for goog.net.XhrIo.
I thought the Google Closure lib was just available without any special incantations.
@dnolen: I need to do a call using Jsonp, because unfortunately the API doesn’t support Cors. So I looked at this gist: https://gist.github.com/dsosby/1823881
But I get the errror: ExceptionInfo #<TypeError: goog.net.Jsonp is not a function> clojure.core/ex-info (core.clj:4403)
@casperc: right I’m not asking for that much context. Just what your import looks like.
I tried your version also, with no difference. (:import [http://goog.net Jsonp]) as well when using the sort name.
@casperc: ClojureScript is bundled with specific versions of Google Closure Library, did you try 3308?
GCL isn’t a versioned thing, so we create an artifact for it occasionally when we release ClojureScript
@bensu there’s really not much value in importing records in ClojureScript, :require
+ :refer
works.
while on the surface this would seem like a compatibility benefit to support it - this is not the case
we explored this and it’s more or less a disaster because of how Closure namespaces work.
@dnolen: ok, I'll look for the best place to document this, since it is confusing. The best source for :import
advice was your blog which contains a big "Don't use :import for non Google Closure Compiler"
@dnolen: this problem appears when using cljc
, maybe that is what we should cover, "Using cljc"
@bensu: FWIW, this is consistent with what David’s saying: https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure#namespaces
@bensu: Yeah, it sounds like :import
is for and only for importing Google Closure classes.
It is also copied here: https://github.com/clojure/clojurescript/blob/fa0da846e6f30eec330fac9e2ac8aced2660d20f/src/main/clojure/cljs/repl.cljc#L976
There are some general guidelines on how to transition/use cljc: https://github.com/clojure/clojurescript/wiki/Using-cljc
Cool. On a related note, I wish the normative content of Rafel Spacejer's post were in the Wiki somewhere. http://www.spacjer.com/blog/2014/09/12/clojurescript-javascript-interop/
So we’re nearing a release, one way to help out is just to build with master and try it in your own projects
I’ve already gave some simple things I have lying around like Om examples a shot, no issues. Also went through the beginning steps of the Quick Start, similarly no issues.
I'm getting errors from ./script/build
at git --no-replace-objects describe --match v$MAJOR.$MINOR
since it can't find 1.7
It might not be the compiler's fault but I'm seeing breaking changes with prismatic/schema.core
and prismatic/om-tools
. Both in my code (whenever I use one of their macros without requiring implicit ns dependencies) and in their library, which doesn't compile under 1.7.10
.
ClojureScript error reporting improved so they may very well have code that gets caught out
it might. I'm seeing WARNING: Use of undeclared Var schema.core/Any
for all their vars, which is probably macros calling namespaces that where not required
and Don't know how to create ISeq from: clojure.lang.Symbol {:tag :cljs/analysis-error}
around analyze-seq
and analyze-seq
OK I just cut a pre-release ClojureScript 1.7.10 for testing purposes so people don’t have to build themslves
@dnolen: when testing on other projects, do you have a way to avoid building on each compiler change?
@bensu like I said Cursive helps a lot here, I can set breakpoints in ClojureScript source even when building some other project.
@dnolen: are you publishing 1.7.10 to maven?
nvm, unpublished pre-release
@dnolen: is maven slow to update then? I’m not seeing it: http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.clojure%22%20AND%20a%3A%22clojurescript%22
alright, readying the cljs-api-docs
building that from a cljs.jar
results in a Caused by: java.lang.IllegalArgumentException: Don't know how to create ISeq from: clojure.lang.Symbol
"Whoa that GitHub Gist link contains 3 files! Are you sure you want us to import all of them?"
@bensu: I’m not even sure if that’s really all that clear - the fact that we internally use clojure.core
is not something to be relied upon.
if there’s a simple fix I’m OK that, but it’s also the case that Schema is just busted here
I meant "the cause for the exception is clear". It's still an open question where does the bug reside.
@dnolen: I missed your comment and spent 30 mins looking at parse-type
, I'll try master now
@bensu I wouldn’t bother with that the bug just seems unlikely - so more likely an unintentional side-effect of a change to macro-resolution
pretty smooth. can't wait to find a legitimate excuse to put cljs.js
somewhere, support/troubleshooting?
I agree, it's not for your web-app users, but I still want to use it. we need to make an in-browser dev environment, a la Elm
you can repl @ http://clojurescript.net/
so a component of my product at work is coming down the pipe that I have the opportunity to build in cljs
but i am worried about the infancy of cljs in this soon-to-be-production environment
i suppose this is a valid question for @angusiguess since you built a component with it, but its not client facing
Talked about some of the patterns and antipatterns of using om particularly.
But Circle uses cljs in prod, so too does Prismatic.
samueldev: i can’t think of any technical concerns. cljs is well suited to big enterprise scale projects. biggest concern would be anti-cljs people on the team, or people who might be inclined to delete the “weird stuff” after you move on...
oh, well, that works in your favor! i’d be interested to hear more about their objections — i’m a former cljs skeptic working on a talk about it
but if we do end up going with cljs for this component, they will likely jump into this channel at which point ill direct them your way 😉
As it is, I'm having a lot of trouble convincing other frontend devs to use react instead of writing spaghetti jQuery code
top 3 would probably be — improved/simplified tooling, react / immediate mode ui, modules support
if people are at the point in their knowledge and preference of frontend tools where jQuery spaghetti messes are their go-to
they are likely a ways off from understanding some of the finer points of architecting something intelligently, much less understanding the merits of a functional paradigm
@dhkl having a sort of jquery v.s. react idioms would probably go a long way towards convincing people of the merit (and viability)
@samueldev you don't think there's hope at all? 😛
the technology should fit the problem — jquery is perfect reasonable for many cases, though an SPA isn’t one of them
i have a macro which generates a function call from a namespace normally not required in cljs code which uses the macro. how can my macro require that namespace?
@akiel: That's an interesting question. While require
is a function in Clojure, it is a REPL special in ClojureScript. I'm academically curious if a goog.require
can be emitted anywhere in the code. You can also take a peek at how require
is implemented in cljs.repl
on top of the ns
special form.
@akiel: This reminds me a bit of how Sean Grove successfully made use of the source
REPL functionality in some deployed code (Gamma?)
@mfikes: can you please look at my concrete problem in https://github.com/alexanderkiel/async-error
there I have throw-err in the async-error.helper ns which I have to require in cljs but not in clj
@akiel: if a macro needs a run time thing you need to document to the user that they have to require the runtime bits
hi @dnolen with my little async-error lib I try to put your <? thing into a small lib which everyone can use
@dnolen: is the trick to use :include-macros true and have a cljs file with :require-macros and then a clj file with the macros. all same ns.
@akiel: I’m looking at your code. You are saying that async-error.helper
needs to only be required when async-error.core
is being required from ClojureScript code?
@mfikes: yes, I say this already in the readme, but than you also have to require the hleper ns
nice cljc file: https://github.com/alexanderkiel/async-error/blob/master/src/async_error/core.cljc
I am using bootstrap, and bootstrap needs jquery, Should I use jquery as a cljsjs package or add a script tag in the template ?
@lazy-lambda: both should work
I know but what is the best-practice ?
I am never going to use jquery in my cljs code
I’d go with cljsjs. If you have other Clojurescript things that depend on cljsjs/jquery you don’t end up with it twice that way.
I just want to make bootstrap happy
probably does not matter if you never use it from cljs
Okay thanks
If you need core.async error handling in Clojure(Script) I have 0.1 of https://github.com/alexanderkiel/async-error
I prefer not using Jquery with Bootstrap, works just fine
You can implement most of Boostrap JS stuff with just few lines of cljs, when needed
performance wise there are differences, e.g. you save an http request (cljsjs) or you might load it straight from the cache (loading jQ from popular CDN)
@akiel: I see you went with simply bringing the helper function into the async-error.core
namespace. But I’m still puzzled as to why things don’t work. I tried a simple experiment with Planck that coves the salient aspect of require-macros
on a namespace that itself requires a helper function from another namespace and it works for me (at least in bootstrapped ClojureScript): https://gist.github.com/mfikes/edfb5cc28114e53be188
@akiel: My guess is ClojureScript’s use of Clojure to compile macro namespaces causes bootstrapped to behave a little more like what you want in this case.
@mfikes: I also required the helper ns from core but it did not work - it worked only on Clojure
@akiel: I’m gonna revise and try my small example with non-bootstrapped ClojureScript.
@akiel: Definitely. I’m now curious if what I’m seeing is an unexpected consequence of bootstrapped ClojureScript being pure ClojureScript.
@mfikes: I just don’t know. but I think it should be one goal to equal on the macro thing in Clojure and ClojureScript. I totally support the idea of a hosted language, but inside the language, things should work the same.
@akiel: It works fine in non-bootstrapped ClojureScript. I updated the gist: https://gist.github.com/mfikes/edfb5cc28114e53be188
@akiel: So, I’m still puzzled why you had to explicitly require the helper namespace. Hmm.
@mfikes: can I go back to it tomorrow? I’m just a bit tired at the very end of the day.
http://stackoverflow.com/questions/31481396/uncaught-typeerror-illegal-invocation-when-trying-to-support-cross-browser-pr I asked the previous question on SO and haven't received a very good answer yet. What is the best way to abstract browser prefixes when making native function calls?
@mfikes: hi mike, does figwheel current support react native?
we can put aside the repl, tried ambly, it’s awesome
@tiensonqin: Figwheel uses WebSockets right? So, there is a possibility that you can set up React Native using a WebView (which it supports; it’s one of its executor types) and then maybe Figwheel would work against that. But… I suspect Figwheel might require more than just WebSockets.
@tiensonqin: If you don’t need the full goodness that is Figwheel, but simply want code to be reloaded into React Native for a namespace, see http://blog.fikesfarm.com/posts/2015-05-30-poor-mans-figwheel-for-ambly.html
@mfikes: I saw that, could i load multiple namespaces?
@tiensonqin: I did that with React Native for nearly an hour in this (2-minute) video: https://youtu.be/Ci4uviG8S0o
@mfikes I’m currently looking this!
tiensonqin: I suppose you could, in :watch-fn
just explicitly load all of the namespaces in your project, in an appropriate topological sort.
@dnolen: I just watched the Demand-Drive Arch video and at the end someone asked you about odata. I have worked somewhat with odata and I would describe it as ideally a richer and faster way to do REST Apis. It does allow you to go against the DB directly, It does have some recursive ability(if I remember right). It does not allow batching of multiple types of data and the syntax for recursion you used it way better than odata stuff. It also does allow a uniform way to do some nice filters. As a concept it is interesting but the tooling around it was the problem for us.
@mikes ok, will try it, thanks for your help and contribution for the community.
sorry, s/mikes/mfikes
@tiensonqin: Thanks! By trying things out, you will invariably end up helping tremendously as well. (We need more people banging at this stuff.)
@mfikes, yeah, I’d like to, thank you, man!