Fork me on GitHub
#clojurescript
<
2015-09-09
>
venantius00:09:34

would be awesome to see this tossed on heroku somewher

venantius00:09:44

<— loves demos

mfikes00:09:58

@thosmos: Nice! You're using :module-type :commonjs :)

thosmos00:09:13

mfikes: yes! boot-cljs still throws an error on :optimizations :advanced and I'm not sure which layer that's at, but at least dev mode works

thosmos00:09:51

@venantius: the built files are in the repo so you can run it straight from the repo without building if you want

dnolen03:09:00

@thosmos yeah you will still need to supply your own externs

thosmos03:09:26

@dnolen: ok, I see, hence the presence of auto-externs generation on the todo list

danielcompton04:09:12

Is there any documentation for the formatters that Google Closure string format takes? I can’t see anything apart from the source.

dnolen04:09:10

@danielcompton: the source is all there is

scriptor04:09:41

what are some possible reasons a source-map wouldn't be outputted?

scriptor04:09:08

I have :source-map set to the target path and :optimizations set to :simple (all in project.clj)

thosmos04:09:54

@dnolen: is this still the latest progress on externs inference? https://github.com/clojure/clojurescript/compare/master...mneise:CLJS-1074 What's the plan now that Maria is back in work and school?

maria05:09:06

@thosmos: The current plan is, that I will continue to work on the externs inference task 😉

thosmos05:09:32

@maria: Excellent! Glad to hear that!

thosmos05:09:20

Thanks for all you've already done too. I'm impressed.

bhagany05:09:31

well, I am pretty happy, and everyone I know is asleep, so you good people get to hear about it.

bhagany05:09:58

I just wrote a bunch of clojurescript that, once it compiled, worked absolutely perfectly on the first try. I consider this a personal milestone.

bhagany06:09:14

The code in question uses AWS Lambda on Node to create and serialize a Datascript database to S3, using Transit. Super pleased. Thanks to everyone for building some fantastic tools.

bhagany06:09:01

(I'd mention your names, but I assume that that would be annoying)

thosmos06:09:00

@bhagany: That sounds great. Is your work open source by any chance?

bhagany06:09:57

It's pretty tied in to the current project, but if there's interest in the Lambda/Datascript/S3 thing, I'd definitely abstract that out https://github.com/bhagany/thisonesforthegirls

bhagany06:09:11

It's a rewrite of a site I put up for my mother-in-law ~10 years ago

bhagany06:09:50

Needs a CMS-ish thing, but rarely gets used. I'm going for the cheapest solution, and figured "serverless" is the way to go

bhagany06:09:03

Also, not done yet, but what's there works

bhagany06:09:36

To put my happy feelings about this in context - this was my first time using: cljs on node, Lambda, core.async, Datascript, transducers, and Transit. And it all just came together really well.

grav07:09:54

Anyone using figwheel around here? I’m having trouble with javascript errors causing figwheel to throw a java exception, it seems

grav07:09:55

okay, solved it. had to exclude some stuff from dependencies. will submit bugreport

bhauman15:09:18

@bhagany: awesome! I did something similar but I went straight to S3 using a token generated by the server. But of course its harder to validate the data you are shipping. Did you turn on versioning for the s3 bucket? That can save you some pain.

jmckitrick15:09:23

Any figwheel gurus here?

akiva15:09:39

I was hoping that would happen.

jmckitrick15:09:11

So I have a web app I'm trying to retrofit with figwheel. Oh, I see you now, @bhauman simple_smile

bhagany15:09:35

@bhauman - I haven't turned on versioning, but I don't think I'll need it for this use case. I'm pretty sure nobody has attempted any db access in like 5 years, so I'm not too worried about data loss because of no locking or something like that

jmckitrick15:09:39

The first issue is it's a SPA with a couple of pages. So the first issue is getting the page I want to be served through figwheel. Right now, I have a ring server that matches the route and serves the html as a resource.

bhagany15:09:53

@bhauman I have thought about making it more like a real db though simple_smile

bhauman15:09:37

@bhagany: yeah but its cheap as dirt, and it makes recovery effortless.

bhagany15:09:53

@bhauman: you have a strong point there

bhauman15:09:22

@jmckitrick: alrighty you don't need to use the figwheel server

bhagany15:09:37

@bhauman: versioning is on simple_smile

bhauman15:09:38

@jmckitrick: stick with you server

bhauman15:09:52

@bhagany: that was tough eh???

jmckitrick15:09:55

@bhauman: ok, I'll start there.

bhagany15:09:12

@bhauman: I'm sure I'll be smarting from the effort all day

bhauman15:09:27

@jmckitrick: when you launch figwheel is will launch its server purely for communication

jmckitrick15:09:20

Also, @bhauman, all my code is currently rolled into one js file with a different entry point for the 5 pages of the app, and it's all optimized. So I think I need to make each of those pages run with no optimizations first, correct?

jmckitrick15:09:53

@bhauman: Meaning setting up entry points...

bhauman15:09:49

@jmckitrick: yeah if you really have 5 different builds with different entry points yeah you will need 5 opt none builds

bhauman15:09:21

but I would start with one

bhauman15:09:29

and get it going first

jmckitrick15:09:39

@bhauman: It's just one build, and each page pulls in the result. Each just has a different entry point to set up the react content.

jmckitrick15:09:17

@bhauman: yes, that's the plan. So you suggest using the original server/port for viewing content, and get one page working with no optimizations, correct?

jmckitrick15:09:07

Cool, I'll give that a shot.

bhauman15:09:09

I would get the opt none build working, sounds like you are going to do that,

bhauman15:09:58

and after that is working you should just be able to do a lien clean and then add :figwheel true to the build config.

bhauman15:09:23

hopefully 😉

jmckitrick15:09:41

@bhauman: Thanks for the help, I'll let you know how it works....

bhauman15:09:04

@jmckitrick: thanks!! I'm glad the talk helped! Gives me more motivation to work on my next one.

jmckitrick15:09:25

@bhauman: I tried figwheel a several months ago, and got stuck. Did a search recently after watching 'parens of the dead'. Watched your video. Rediscovered my enthusiasm. simple_smile Great presentation style as well, I really enjoyed it.

bhauman15:09:24

@jmckitrick: thanks! Well I hope your experience is better this time. Don't forget to look at the Quick Start https://github.com/bhauman/lein-figwheel/wiki/Quick-Start it will probably help

jmckitrick15:09:57

@bhauman: Will do. I'll check in later....

sgrove15:09:31

@chenglou: So I’ve npm installed react-motion. Looking at its source files in node_modules, it doesn’t look like it relies on babel, but it does expect require and exports to be defined - which aren’t for the browser, so I’m getting “Undefined reference blablabla`. Do I need to pre-process the lib/react-motion.js with webpack to get a version that works, and will its dependency on React conflict with the one that google closure is going to pull in from cljsjs?

chenglou15:09:59

how does cljs interop with node.js requires?

sgrove15:09:59

It doesn’t exist unless you’re using cljs with node.js

sgrove15:09:34

(I think, @dnolen knows way more about it than I do)

bhauman15:09:14

@nullptr I'm assuming you did a clean build.

nullptr15:09:47

is lein clean sufficient, or should i do some manual cleaning?

dnolen16:09:42

@chenglou: it doesn't. You can either call it directly or preprocess it away.

bhauman16:09:50

Make sure all build artifacts are gone. And make sure the connect script is gone as well

nullptr16:09:10

mm, yeah, clean-builds from within figwheel cleaned things up, lein clean was not sufficient … thanks

sgrove16:09:17

dnolen @chenglou: So in the case of ReactMotion expecting require, I assume I need to preprocess it away

chenglou16:09:20

really? I thought there was some story on integration with UMD

chenglou16:09:47

or is cljs only working with closure compiler modules now still

chenglou16:09:05

@sgrove: yeah RM requires are just like another other npm module require

chenglou16:09:14

I don't do anything special

sgrove16:09:36

But that uses the closure compiler’s system to convert :commonjs modules into something consumable by closure

sgrove16:09:45

@chenglou: Yeah, I assume RM does everything the up-to-date standard way, that’s one of the reasons why I’d like to use it as an example of how to get cljs and js/npm stuff to interop

sgrove16:09:09

@maria @dnolen: No hurry, but if you get a chance to look at my attempt to consume ReactMotion and see anything obvious I’m doing incorrectly, would appreciate a heads up https://gist.github.com/sgrove/117c8df0841719d26782

jaen16:09:26

Oh, you're trying to consume a modular library with Clojurescript; I'm curious if you can manage to do it without the preprocess step, since I've been wanting to do that with MaterialUI and kinda gave up when I would have to list all files by hand.

dnolen16:09:00

@sgrove: sorry I don’t personally have the patience to look at anything involving cljsbuild, please supply a build script example that you’re having trouble with

dnolen16:09:26

note also that by supplying a script you can do things programmatically (to list all files) instead of jumping through declarative hoops

jaen16:09:01

@dnolen: have been curious about that for a while looking at the GsoC project - is this "gather all files by hand and plug them into :foreign-libs" the intended way for it to work, or is something like "supply module root and the cljs compiler will take it from there" planned at some point?

dnolen16:09:53

@jaen so :libs can be made to work

sgrove16:09:33

@dnolen: When I get a chance, I’ll convert it to a build script

dnolen16:09:08

@sgrove: happy to take a look when you get around to it

sgrove16:09:18

Thanks, appreciated

dnolen16:09:39

@jaen at least that’s what I remember, otherwise I would just do this programmatically.

dnolen16:09:23

there’s an opportunity for 3rd party build tools to supply helpers and such

dnolen16:09:30

but people should just know how this stuff works first

jaen17:09:03

I see, so generally it's going to stay as barebones as it is and hopefully someone will write something to avoid the boilerplate on top, am I getting that right?

venantius17:09:54

@onetom thanks for the extremely detailed comment on the HN post

venantius17:09:08

looks like quite a few links to follow simple_smile

bhauman17:09:19

@venantius: In response to the figwheel repl comments. Its really not the figwheel REPL

bhauman17:09:50

figwheel uses the clojurescript repl and provides a connection to an eval environment.

bhauman17:09:44

also I really agree with @yogothos response

csmith17:09:32

I appreciated your post @venantius . I’ve encountered some of those issues more so than others

csmith17:09:32

A big piece of it I think is that vim-fireplace is sort of opaque. Satisfies the 90% case for JVM Clojure but not so much CLJS

dnolen17:09:10

@bhauman: what would be interesting would be to enumerate the cases where dirty things aren’t recompiled

dnolen17:09:30

note that Figwheel opts out of a big one, :recompile-dependents

dnolen17:09:52

many the of changes the in last six months were pushing to avoid cold builds as much as possible.

dnolen17:09:00

@jaen I think it’s safer to keep it bare bones until people kick the tires a lot more.

bhauman17:09:51

@dnolen: I hear you here. It doesn't seem like :recompile-dependents is the culprit here, but it may very well be. I definitely have a problem with folks changing figwheel versions. Is there really anything in opt :none that :recompile-dependents affects.

dnolen17:09:26

@bhauman: if you turn off :recompile-dependents then you are OK with corrupted builds

bhauman17:09:33

and but I see weird stuff that is always just a clean away, and its normally from a cold build

bhauman17:09:49

@dnolen: but in opt :none?

dnolen17:09:02

@bhauman: it doesn’t matter what optimization setting

bhauman17:09:06

actually I don't see weird stuff ever

dnolen17:09:12

if you don’t set :recompile-dependents you can corrupt the build

bhauman17:09:15

but I do in issues

dnolen17:09:04

changing figwheel versions is just another case of the something ClojureScript also has to handle

bhauman17:09:08

@dnolen: I was just looking for an example because personally I haven't seen it happen

dnolen17:09:23

@bhauman: it’s trivial to corrupt a build w/o it

dnolen17:09:36

that’s why I added it, because people were reporting trivial corruptions

bhauman17:09:07

@dnolen: well thats a good first step then to change that default

dnolen17:09:36

re: switching Figwheel versions, I’m open to the idea of passing in additional meta to compile-file

bhauman17:09:42

especially on first compile 😉

bhauman17:09:49

just kidding

dnolen17:09:49

then you can tag a file in a custom way

dnolen17:09:23

but in general just blowing away the build is a bad answer

dnolen17:09:36

I’d rather see everyone spend effort on reporting vectors to corruption

dnolen17:09:39

and addressing them

bhauman17:09:57

@dnolen: alright, I'm down with that

dnolen17:09:37

I’m not saying we can prevent every case, but I’d prefer if it was the path of last resort for all build tools.

dnolen17:09:47

unlike today where people reach for it all the time

dnolen17:09:53

and have no idea what went wrong.

dnolen17:09:30

@bhauman: re slow :recompile-dependents this will get fixed when we land @juhoteperi enhancements

dnolen17:09:58

won’t be slow at all anymore, and compilation should be quite a bit faster overall, maybe 20-30% since we’ll have a deterministic build order

bhauman17:09:18

very very cool

genRaiy17:09:53

hi guys… does anyone have a cljs way to browse datomic?

roberto18:09:00

@raymcdermott: you can use the REST service.

dnolen18:09:04

@raymcdermott: not really sure what you mean by that

venantius18:09:59

@bhauman: yeah, that’s sort of what I figured out after you and I talked yesterday. bit more work to follow on me understanding the ways in which the Cljs repl is different from a standard lein repl

venantius18:09:35

@csmith: absolutely; I also get the impression that tim pope isn’t interested in / working on cljs and so doesn’t really care about it that much

csmith18:09:55

yeah, same. I maintain vim-lamdify, which is far simpler than fireplace, and its more than enough vimscript for me.

jaen18:09:30

@dnolen: Clojurescript compiler doesn't yet accept ES6 for :language-in, is that correct?

csmith18:09:03

so it feels like we’re all hoping to lean on the one person that might do it, but they don’t want to. Can’t say I blame ‘em

venantius18:09:12

@csmith: I have two vim clj plugins that I need to bring into line with cljs support

venantius18:09:23

I can feel the pain of at least one of them not working even now

venantius18:09:58

not having access to this on write yet in clojurescript kills me https://github.com/venantius/vim-cljfmt

csmith18:09:37

ah yeah. I have = pulling from something ATM, not sure if vim-clojure or what. Kinda mostly works but not the same

venantius18:09:36

I can’t parse what you just said 😛

csmith18:09:21

hah sorry. = in normal mode is usually bound to the auto-indent rules of the syntax that’s loaded.

dnolen18:09:54

@jaen it can, that’s all Google Closure stuff

jaen18:09:17

@dnolen: then maybe I'm missing something, but when I tried setting :language-in :ecmascript6 in compiler options I've still gotten warnings like invalid param name args...

jaen18:09:34

And this code here https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L178-L188 suggests it doesn't take :ecmascript6 as a valid parameter

dnolen18:09:03

@jaen oh oops, yeah I guess we don’t expose that yet.

jaen18:09:52

Would adding a similar line there be enough, or is something else needed?

jaen18:09:29

sgrove's question made my try compiling MaterialUI with cljs again ; f

jaen18:09:59

@dnolen: nice, thanks. I think I tried adding that by myself last time I was playing with MaterialUI, but I don't think it worked, so maybe I messed something up when building the compiler or something.

genRaiy19:09:55

@dnolen: i mean I would like JS / CLJS database bindings… at the moment AFAIK the only console is on the local JVM, in other words I need a local datomic install to browse a cloud based datomic DB

jaen19:09:25

@dnolen: I must be doing something wrong, I've cloned the cljs repo, ran ./script/build, took the resulting clojurescript-1.7.133-aot.jar and used the with the quickstart way of compilation, and yet when I changed a var to a let in React I get

ERROR: ES6_FEATURE. this language feature is only supported in es6 mode: let declarations. Use --language_in=ECMASCRIPT6 or ECMASCRIPT6_STRICT to enable ES6 features. at node_modules/react/dist/react.js line 38 : 0

dnolen19:09:55

@jaen need to see your build script

genRaiy19:09:21

@dnolen: in other words it would be nice to have a web client that could access a datomic DB

dnolen19:09:34

@raymcdermott: the rest interface is your only option really

genRaiy19:09:34

@dnolen: fair enough, do you know if there are any tools built over that yet?

dnolen19:09:09

@raymcdermott: I haven’t followed the REST based tooling around Datomic, might want to inquire in the #C03RZMDSH channel

genRaiy19:09:33

@dnolen: will do - thanks

grav19:09:32

I’d like to visualize a tree structure using cljs. A javascript implementation of graphviz (dot) is one option, but I haven't found one that is cljs compatible. Any suggestions?

dnolen19:09:36

@grav as long your graph isn’t incredibly massive, graphviz should work, I’m assuming you just need to pass arrays + objects

dnolen19:09:43

this one of the cases where clj->js is useful

grav19:09:34

So I’d just include the js dependency from a script tag, and then invoke it using js interop?

jaen19:09:53

@dnolen: here - https://gist.github.com/jaen/9ee710c04b5f1aeb8917 - sorry it took so long, wanted to simplify it somehow from sgrove's example I started with

jaen19:09:43

Basically what I did is just modify one var into a let in node_modules/react/dist/react.js and I got the error, even though :language-in is set to ES6

jaen19:09:18

If you need anything else to figure out what's wrong then just tell me and I'll try to provide more

dnolen19:09:47

@jaen I think you want to set :language-out to :ecmascript3 or just drop that option

jaen19:09:49

But that means I can not ingest ES6 code then, yes?

dnolen19:09:23

@jaen :language-in is for ingestion

jaen19:09:45

Ah, right, you said out, my bad

dnolen19:09:08

I’m pretty sure the valid -out options are more restricted but we’re just following Closure convention here, any enum value may be supplied for -in -out

dnolen19:09:17

so we’re not validating

jaen19:09:43

But if I set the language to ES6 then why do I get warnings from Closure that let can be used with ES6 mode only?

dnolen19:09:29

since they don’t validate you may get weird errors since the warnings aren’t designed to handle this case

dnolen19:09:38

I’m pretty sure I made this exact same mistake at the command line once

jaen19:09:31

I'm kind of confused now - if :language-in is not used to set language level accepted by GClosure for Clojurescript compilation, then what is it used for?

jaen19:09:55

I probably can't read

jaen19:09:05

> Configure the input and output languages for the closure library.

jaen19:09:14

So this only affects the Closure JS library and nothing else?

dnolen19:09:42

@jaen I don’t know what you mean

dnolen19:09:55

in your example set :language-in leave :language-out alone

jaen19:09:06

Yes, I've corrected to what you said, set :language-in to :ecmascript6 and removed :language-out. And it still do get the error complaining about let not being available at current language level and prompting me to use ES6 flag.

jaen19:09:27

So it seems this flag does not let me ingest ES6, or I'm making some other kind of error I'm not seeing.

dnolen19:09:03

@jaen what source here has let? at the moment this the typical doing too many things at once I dislike

dnolen19:09:16

eliminate react, eliminate foreign libs, elimination react motion

dnolen19:09:29

this are all unnecessary complications to testing whether let is going to work

dnolen19:09:41

then we can add those things back and see if there is a broken combination

dnolen19:09:04

and that will tell us what needs fixing if anything

jaen19:09:32

Well, I pared this down to just React before I even sent the gist, because I figured reaction motion is just noise, but sure I'll try to distil that further.

jaen19:09:08

I'm probably not the most organised person around, so sorry about that '

dnolen19:09:16

@jaen you would think, but you never know and all the options can create subtle bugs as experience has shown simple_smile

jaen20:09:42

@dnolen: this is as simple as I could get it - https://github.com/jaen/cljs-es6-errors ; you have two commits here - first where I don't use :module-type option for the foreign lib and load it with an :import clause, and there's no errors in either case and it works. And the second comit uses :module-type :commonjs option (and :require instead of :import) and this fails with errors regarding language level. It behaves as if module conversion didn't take into account the specified language level. Hopefully that's enough to go on.

dnolen21:09:14

@jaen :import is only for importing Google Closure classes so you can eliminate that from the list of things to consider

dnolen21:09:55

@jaen I would modify your example to be simpler, only interested in interaction between :commonjs and :require

sgrove21:09:43

Oh, thanks for diving into this @jaen!

jaen21:09:07

@dnolen: the :import is #_'d out in the HEAD of the repo, so it's exactly only the :module-type thing, but I removed that for clarity and commited anyway.

jaen21:09:39

@sgrove: no problem, it's something I banged my head against with https://github.com/callemall/material-ui so I figured I may as well try again

jaen21:09:30

I mean, I could do what this guy is doing here - https://github.com/taylorSando/om-material-ui/tree/master/build-mui - but I figured with Maria's work maybe I could get away with just Clojurescript compiler doing it

jaen21:09:49

Seems it's not quite there yet (or I'm doing something wrong)

dnolen22:09:41

@jaen: these things always need tire-kicking, until people actually try it out won’t actually get finished simple_smile

jaen22:09:11

Hah, that's for sure. I didn't bother reporting that the first time this came up because I figured I was doing something wrong that the change analogous to the one you did just now wrt :language-in didn't help, but since I noticed someone else was interested in getting this working, I figured I might get on the bandwagon as well P ;

maria22:09:46

@jaen: yes, you are right, module conversion doesn't take the :language-in option into consideration yet. So far, it only sets :closure-warnings, :pretty-print and :closure-extra-annotations. https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1284

maria22:09:35

@jaen: You could submit a patch for this, if @dnolen is not already on it? simple_smile Or I am also happy to fix this 😉

dnolen22:09:42

but it does bring up an interesting thing we don’t actually handle which is that while we compile away the ES6 or CommonJS module syntax

dnolen22:09:03

we don’t convert the file to ES3 which is the probably the right default unless overridden by the user

dnolen22:09:14

in ClojureScript we always output ES3 for maximum compatibility

dnolen22:09:23

hrm it does bring up another interesting question - the language in and out setting should probably be specifiable at the module level?

jaen22:09:24

I suppose so, it makes sense to to use ES6 language level only for files that need that.

dnolen22:09:08

needs mulling over, but I suspect this is probably the right way to go

dnolen22:09:30

then people can package up JS libs unmodified and debug the original source same as they do ClojureScript

jaen22:09:00

@dnolen: 1.7.134 gets rids of warnings for me, thanks for the fix

dnolen22:09:17

@jaen yes, so that will work in modern browsers, but it doesn’t compile away ES6

dnolen22:09:29

or modern JS environments rather

jaen22:09:22

Yes, but I've noticed you're working on getting Babel to work, so the result of module preprocessing can be feed into that if someone has to target a non-ES6 environment

jaen22:09:35

At least I imagine it could work like that

dnolen22:09:05

@jaen preferable to defer to Closure for ES6. Was only really interested in Babel for JSX or other various plugins.

dnolen22:09:36

gotta run, but things to think about and things to work on! simple_smile

jaen22:09:51

As for the ticket, that seems like a good direction, I hoped that at some point I could just do :foreign-libs [{:lib "path/to/some/commonjs/lib/root/" :module-type :commonjs :provides ["ThatLib"]}]

jaen22:09:21

So if there is anything moving in that direction I can try to help (time permitting)

jaen22:09:44

@dnolen: right, I imagine sticking to one tool as much as possible makes sense

potetm23:09:34

So I just had somebody ask about cljs on Android, and I thought someone on here might know the state of that project. Maybe @mfikes?

maria23:09:07

@potetm: There is also this post here from mfikes http://blog.fikesfarm.com/posts/2015-07-15-clojurescript-on-android.html and also Replicator (https://github.com/tahmidsadik112/Replicator) which is a ClojureScript REPL for Android

jaen23:09:32

Hm, but React Native is not released for Android yet, so I'd rather look towards something with Phonegap

jaen23:09:57

I've seen a nice example app using that, but can't remember the repos name

jaen23:09:39

I think this might have been this repo - https://github.com/enterlab/cordevicljs

maria23:09:14

@jaen: Regarding module processing and js preprocessing with Babel: The way it currently works is that we first do the preprocessing and then the module conversion. The reason for this is, that in case a module makes use of JSX and we would try to convert it, Google Closure would complain.

jaen23:09:16

@maria: right, that totally makes sense, since I don't think GClosure speaks JSX