Fork me on GitHub
#clojurescript
<
2015-07-29
>
mfikes00:07:05

In case you were curios about bootstrapped ClojureScript and macros, they’re for real. simple_smile https://youtu.be/0uEx-hpMHhU

mikepence01:07:12

great stuff, as usual @mfikes

mikepence01:07:12

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

nullptr01:07:58

mfikes: you cheated! normally videos require some editing to get that kind of repl startup time :)

mfikes01:07:52

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

shaunlebron03:07:29

@dnolen: I ran script/build in master, and it created the release tag r2

shaunlebron03:07:25

looks like its possible for tags to collide since they count up from the most recent major.minor version?

dnolen11:07:09

@shaunlebron: good catch fixed

casperc12:07:19

Anyone know why goog.net.Jsonp evaluates to nil? Importing it doesn’t seem to make much of a difference.

casperc12:07:30

Seems to be the same for others as well, e.g. goog.net.Ipv6Address, but not for goog.net.XhrIo.

casperc12:07:03

I thought the Google Closure lib was just available without any special incantations.

dnolen12:07:11

@casperc: not enough information

dnolen12:07:19

what are you actually trying?

casperc12:07:28

@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

casperc12:07:22

But I get the errror: ExceptionInfo #<TypeError: goog.net.Jsonp is not a function> clojure.core/ex-info (core.clj:4403)

casperc12:07:42

Which seems to be from the fact that goog.net.Jsonp evaluated to nil

dnolen12:07:00

@casperc: right I’m not asking for that much context. Just what your import looks like.

casperc12:07:21

(import '[goog.net.Jsonp]) i guess or (import ‘[goog.net.Jsonp])

bensu12:07:49

@casperc: you mean (:import [goog.net.Jsonp]) in the ns form?

casperc12:07:29

I was experimenting from the REPL, but isn’t what I wrote equivalent?

casperc13:07:34

I tried your version also, with no difference. (:import [http://goog.net Jsonp]) as well when using the sort name.

dnolen13:07:54

@casperc: what version of ClojureScript?

casperc13:07:56

@dnolen: [org.clojure/clojurescript "0.0-3211”] and [org.clojure/clojure "1.6.0"]

casperc13:07:31

From the Chrome console: goog.net.Jsonp => undefined

casperc13:07:44

goog.net.XhrIo => goog.net.XhrIo(opt_xmlHttpFactory)

casperc13:07:00

So I guess it is just not loaded for whatever reason.

dnolen13:07:38

@casperc: ClojureScript is bundled with specific versions of Google Closure Library, did you try 3308?

dnolen13:07:05

or rather ClojureScript depends on specific versions of GCL

casperc13:07:10

@dnolen: Yeah I just did. Still seeing the same.

casperc13:07:24

And Clojure 1.7.0

dnolen13:07:54

@casperc: then those things haven’t made into a GCL release that we’ve cut.

dnolen13:07:52

GCL isn’t a versioned thing, so we create an artifact for it occasionally when we release ClojureScript

casperc13:07:12

@dnolen: Ah ok, that would explain it I guess.

dnolen13:07:33

@bensu there’s really not much value in importing records in ClojureScript, :require + :refer works.

dnolen13:07:22

while on the surface this would seem like a compatibility benefit to support it - this is not the case

dnolen13:07:44

we explored this and it’s more or less a disaster because of how Closure namespaces work.

bensu13:07:10

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

dnolen13:07:30

@bensu yes this should be clarified on the wiki if it isn’t there.

dnolen13:07:40

:import is only for Google Closure Library

bensu13:07:42

@dnolen: this problem appears when using cljc, maybe that is what we should cover, "Using cljc"

dnolen13:07:10

@bensu I really don’t see how this is cljc specific

dnolen13:07:56

@bensu but yes, something worth replicating if someone makes a “Using cljc” page

bensu13:07:58

@mfikes: I'm right there, wondering if a clause should be added simple_smile

mfikes13:07:58

@bensu: Yeah, it sounds like :import is for and only for importing Google Closure classes.

bensu13:07:05

@dnolen: the problem is not cljc specific, but how one gets there is.

bensu13:07:17

@mfikes: my thoughs exaclty

bensu13:07:42

@dnolen: I'll start the cljc wiki page to avoid cluttering the rest of the docs.

bensu14:07:58

There are some general guidelines on how to transition/use cljc: https://github.com/clojure/clojurescript/wiki/Using-cljc

mfikes14:07:29

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/

dnolen15:07:37

So we’re nearing a release, one way to help out is just to build with master and try it in your own projects

dnolen15:07:16

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.

kamn15:07:08

Is there a place to report success/failures?

dnolen15:07:17

let me know here first and we can figure out if it’s a real bug or not

bensu15:07:47

@dnolen: is ./script/build still how we should build?

bensu15:07:01

I'm getting errors from ./script/build at git --no-replace-objects describe --match v$MAJOR.$MINOR since it can't find 1.7

bensu15:07:45

sorry for the noise, I just forgot to git pull origin --tags

bensu15:07:07

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.

dnolen15:07:00

@bensu: I don’t know anything about Prismatic Schema, but what is the error?

dnolen15:07:20

ClojureScript error reporting improved so they may very well have code that gets caught out

dnolen15:07:40

and if that’s the case that’s a Schema bug

bensu15:07:28

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

dnolen15:07:03

yeah not going to fix that

dnolen15:07:12

more accurate warnings are a good thing

bensu15:07:22

and Don't know how to create ISeq from: clojure.lang.Symbol {:tag :cljs/analysis-error} around analyze-seq and analyze-seq

dnolen15:07:23

we constantly find new problematic code everytime we improve them.

bensu15:07:39

analyze-do sorry

bensu15:07:07

I'm tracking the exception to see how does the offending expression looks like.

dnolen15:07:18

@bensu that seems more problematic, but yeah need more information.

bensu15:07:45

yeah of course, I'll be back with a better story.

dnolen15:07:53

OK I just cut a pre-release ClojureScript 1.7.10 for testing purposes so people don’t have to build themslves

bensu16:07:57

@dnolen: when testing on other projects, do you have a way to avoid building on each compiler change?

dnolen16:07:10

@bensu if you get a reproducer go ahead and file an issue

dnolen16:07:18

@bensu: no that’s how I do it.

bensu16:07:28

ok, your productivity is even more impressing than previously thought.

dnolen16:07:22

@bensu like I said Cursive helps a lot here, I can set breakpoints in ClojureScript source even when building some other project.

shaunlebron16:07:54

@dnolen: are you publishing 1.7.10 to maven?

shaunlebron16:07:52

nvm, unpublished pre-release

dnolen16:07:41

no published

dnolen16:07:46

pre-releases are published

dnolen16:07:48

yeah can take a while

shaunlebron16:07:17

alright, readying the cljs-api-docs

bensu16:07:18

@dnolen: the cause is using clojure.core/defrecord

bensu16:07:14

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

bensu16:07:00

I'll see if I can find where it throws in the analyzer

dnolen16:07:05

@bensu: snippet plus stacktrace is generally more useful than snippet

dnolen16:07:20

also can we share gists for stuff like this, Slack’s code pasting is … suboptimal

bensu16:07:08

hahahaha it is a gist, with a stacktrace, but slack decided to show it as a snippet

dnolen16:07:33

what an abomination

bensu16:07:43

"Whoa that GitHub Gist link contains 3 files! Are you sure you want us to import all of them?"

bensu16:07:55

when it was one file, it went ahead.

bensu16:07:18

in any case, the problem is clear, I'll have to find where it is happening

dnolen16:07:57

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

dnolen16:07:16

if there’s a simple fix I’m OK that, but it’s also the case that Schema is just busted here

dnolen16:07:39

emitting clojure.core and expecting that to work … no way

bensu16:07:10

I meant "the cause for the exception is clear". It's still an open question where does the bug reside.

dnolen17:07:50

@bensu I see the likely culprit, let me fix this and can you try master?

dnolen17:07:40

@bensu try master when you get the chance, thanks!

bensu17:07:05

@dnolen: I missed your comment and spent 30 mins looking at parse-type, I'll try master now

dnolen17:07:36

@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

dnolen17:07:43

I’ve changed master to the old behavior for ClojureScript JVM

bensu17:07:07

it worked (it commpiles without error)

bensu17:07:32

I'll go back to my project and continue trying it there

dnolen17:07:06

@bensu: awesome glad to hear it works. Thanks!

bensu17:07:43

@dnolen: It worked on a 5k LOC project with 15 deps

bensu17:07:03

I'm happy.

dnolen17:07:03

@bensu sweet! Thanks for the confirmation

bensu17:07:39

no problem

bensu17:07:35

pretty smooth. can't wait to find a legitimate excuse to put cljs.js somewhere, support/troubleshooting? simple_smile

dnolen17:07:21

@bensu lol yeah I don’t think it’s an app thing 😛

dnolen17:07:42

putting together a blogpost about it, should get people’s wheels spinning

dnolen17:07:51

will include evaluable expressions inline in the post

dnolen17:07:15

or “web app” thing I should say

bensu17:07:31

that's right! we can now make repls everywhere. @mfikes is living the dream.

bensu17:07:25

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

dnolen17:07:36

@bensu: for JSBin or JSFiddle like thing game changer for the obvious reasons simple_smile

dnolen17:07:03

or CLJSPerf or whatever

bensu17:07:03

@dnolen: for mind blowing blog posts also.

kamn17:07:24

devcards/ interactive docs

mikepence18:07:54

I am especially interested in node + cljs

mikepence18:07:02

and in d3 + cljs on the client side

samueldev18:07:32

so a component of my product at work is coming down the pipe that I have the opportunity to build in cljs

samueldev18:07:46

specifically a realtime dashboard full of graphs

samueldev18:07:01

ill have to make a cljs wrapper for our graph library of choice...

samueldev18:07:22

but i am worried about the infancy of cljs in this soon-to-be-production environment

samueldev18:07:36

any of you gents have anything in prod? any challenges / concerns / regrets?

samueldev18:07:56

big enterprise scale prod

samueldev18:07:08

i suppose this is a valid question for @angusiguess since you built a component with it, but its not client facing

samueldev18:07:10

is the difference

angusiguess18:07:50

Talked about some of the patterns and antipatterns of using om particularly.

angusiguess18:07:26

But Circle uses cljs in prod, so too does Prismatic.

samueldev18:07:29

thanks angus I'll check it out simple_smile

nullptr18:07:40

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

samueldev18:07:04

our entire backend is clojure

samueldev18:07:17

there are certainly some anti-clojure/anti-cljs people on the frontend though

samueldev18:07:26

who... hopefully be willing to try it before dismissing it

nullptr18:07:56

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

samueldev18:07:19

haha ill try and remember to document them for you

samueldev18:07:42

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 😉

dhkl18:07:06

@nullptr what changed your mind about cljs?

nullptr18:07:33

dhkl: in short, the incredible progress made over the past 18-24 months

dhkl18:07:57

As it is, I'm having a lot of trouble convincing other frontend devs to use react instead of writing spaghetti jQuery code

nullptr18:07:05

top 3 would probably be — improved/simplified tooling, react / immediate mode ui, modules support

nullptr18:07:01

lots of other smaller stuff too — cljsjs, figwheel, transit, the list goes on

nullptr18:07:11

crazy how much better the cljs story is today than 2 years ago

kamn19:07:30

@nullptr: when/where are you giving that talk?

nullptr19:07:40

i submitted the talk for conj, but would do it anywhere that wants a cljs talk

samueldev19:07:18

@dhkl: in my experience as a FED

samueldev19:07:45

if people are at the point in their knowledge and preference of frontend tools where jQuery spaghetti messes are their go-to

samueldev19:07:23

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

dhkl19:07:37

Indeed. It's still an uphill battle for me to spread that realization out

samueldev19:07:49

left 2 jobs now in your situation

samueldev19:07:57

you should consider doing the same 😉 (we're hiring!)

shaunxcode19:07:56

@dhkl having a sort of jquery v.s. react idioms would probably go a long way towards convincing people of the merit (and viability)

dhkl19:07:57

@samueldev you don't think there's hope at all? 😛

nullptr19:07:01

the technology should fit the problem — jquery is perfect reasonable for many cases, though an SPA isn’t one of them

akiel19:07:31

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?

mfikes19:07:01

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

mfikes19:07:25

I guess your macro is not statically calling into the same namespace each time.

mfikes19:07:58

@akiel: This reminds me a bit of how Sean Grove successfully made use of the source REPL functionality in some deployed code (Gamma?)

akiel19:07:49

@mfikes: can you please look at my concrete problem in https://github.com/alexanderkiel/async-error

dnolen19:07:18

@akiel: there’s really no way to accomplish that

akiel19:07:24

there I have throw-err in the async-error.helper ns which I have to require in cljs but not in clj

dnolen19:07:39

@akiel: if a macro needs a run time thing you need to document to the user that they have to require the runtime bits

dnolen19:07:10

the alternative is to not present the macro as a separate thing at all a la om.dom

akiel19:07:21

hi @dnolen with my little async-error lib I try to put your <? thing into a small lib which everyone can use

dnolen19:07:59

@akiel: ok that’s a solveable problem, look at how om.dom works

dnolen19:07:09

pretty sure there’s something about this in the wiki somewhere

akiel19:07:23

ok I’ll have a look

akiel20:07:12

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

mfikes20:07:13

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

akiel20:07:56

@mfikes: no async-error.core is never required in cljs it’s onlt required as macros

akiel20:07:24

async-error.core has only macros relevant for cljs

akiel20:07:04

but I currently playing with putting throw-err in core and use :include-macros true

mfikes20:07:05

@akiel: In ClojureScript code you would use (:require-macros async-error.core)

akiel20:07:46

@mfikes: yes, I say this already in the readme, but than you also have to require the hleper ns

mfikes20:07:01

Ahh, let me read your readme.

mfikes20:07:08

@akiel: Oh that’s interesting. I see what you are saying now.

akiel20:07:02

ok it works now with (:require [async-error.core :refer-macros [go-try <?]])

lazy-lambda21:07:08

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-lambda21:07:45

I know but what is the best-practice ?

lazy-lambda21:07:13

I am never going to use jquery in my cljs code

martinklepsch21:07:21

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.

lazy-lambda21:07:21

I just want to make bootstrap happy

martinklepsch21:07:04

probably does not matter if you never use it from cljs

akiel21:07:56

If you need core.async error handling in Clojure(Script) I have 0.1 of https://github.com/alexanderkiel/async-error

juhoteperi21:07:58

I prefer not using Jquery with Bootstrap, works just fine

juhoteperi21:07:15

You can implement most of Boostrap JS stuff with just few lines of cljs, when needed

martinklepsch21:07:27

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)

dnolen21:07:23

More rationale that I couldn’t get into about Om Next in this talk

nullptr21:07:35

(the audio improves at ~2m30s)

mfikes21:07:14

@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

mfikes21:07:43

Perhaps I’ve been living in boostrapped too much lately.

mfikes21:07:17

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

akiel21:07:35

@mfikes: I also required the helper ns from core but it did not work - it worked only on Clojure

mfikes21:07:23

@akiel: I’m gonna revise and try my small example with non-bootstrapped ClojureScript.

akiel21:07:33

@mfikes: I do not use bootstrapped CLJS - I tested with normal cljsbuild and figwheel

mfikes21:07:31

@akiel: Definitely. I’m now curious if what I’m seeing is an unexpected consequence of bootstrapped ClojureScript being pure ClojureScript.

akiel21:07:19

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

mfikes21:07:41

@akiel: It works fine in non-bootstrapped ClojureScript. I updated the gist: https://gist.github.com/mfikes/edfb5cc28114e53be188

mfikes21:07:07

@akiel: So, I’m still puzzled why you had to explicitly require the helper namespace. Hmm.

akiel21:07:38

@mfikes: can I go back to it tomorrow? I’m just a bit tired at the very end of the day.

mfikes21:07:12

@akiel: Oh wow. Europe. Indeed.

akiel21:07:15

yes Germany simple_smile

mfikes21:07:08

Gute Nacht, then!

samedhi22:07:57

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?

tiensonqin23:07:20

@mfikes: hi mike, does figwheel current support react native?

tiensonqin23:07:23

we can put aside the repl, tried ambly, it’s awesome

mfikes23:07:03

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

mfikes23:07:47

@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

tiensonqin23:07:09

@mfikes: I saw that, could i load multiple namespaces?

mfikes23:07:16

@tiensonqin: I did that with React Native for nearly an hour in this (2-minute) video: https://youtu.be/Ci4uviG8S0o

tiensonqin23:07:17

@mfikes I’m currently looking this!

jhsu23:07:22

oh cool, thanks for sharing

mfikes23:07:43

tiensonqin: I suppose you could, in :watch-fn just explicitly load all of the namespaces in your project, in an appropriate topological sort.

kamn23:07:21

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

tiensonqin23:07:56

@mikes ok, will try it, thanks for your help and contribution for the community.

tiensonqin23:07:50

sorry, s/mikes/mfikes

mfikes23:07:51

@tiensonqin: Thanks! By trying things out, you will invariably end up helping tremendously as well. (We need more people banging at this stuff.)

tiensonqin23:07:41

@mfikes, yeah, I’d like to, thank you, man!