This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-09-09
Channels
- # admin-announcements (23)
- # beginners (7)
- # boot (6)
- # clara (1)
- # cljs-dev (2)
- # clojure (89)
- # clojure-argentina (1)
- # clojure-australia (5)
- # clojure-brasil (4)
- # clojure-denmark (2)
- # clojure-france (1)
- # clojure-italy (1)
- # clojure-japan (9)
- # clojure-nl (13)
- # clojure-russia (1)
- # clojurescript (248)
- # clojurex (3)
- # clojutre (3)
- # core-async (2)
- # datomic (6)
- # devcards (19)
- # devops (1)
- # events (1)
- # funcool (9)
- # hoplon (74)
- # ldnclj (53)
- # melbourne (3)
- # off-topic (25)
- # onyx (36)
- # reagent (8)
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
@venantius: the built files are in the repo so you can run it straight from the repo without building if you want
Is there any documentation for the formatters that Google Closure string format takes? I can’t see anything apart from the source.
@danielcompton: the source is all there is
I have :source-map set to the target path and :optimizations set to :simple (all in project.clj
)
@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?
@thosmos: The current plan is, that I will continue to work on the externs inference task 😉
well, I am pretty happy, and everyone I know is asleep, so you good people get to hear about it.
I just wrote a bunch of clojurescript that, once it compiled, worked absolutely perfectly on the first try. I consider this a personal milestone.
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.
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
Needs a CMS-ish thing, but rarely gets used. I'm going for the cheapest solution, and figured "serverless" is the way to go
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.
Anyone using figwheel around here? I’m having trouble with javascript errors causing figwheel to throw a java exception, it seems
@venantius: Nice write up by @onetom on boot/hoplon : https://news.ycombinator.com/item?id=10191254
@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.
Any figwheel gurus here?
So I have a web app I'm trying to retrofit with figwheel. Oh, I see you now, @bhauman
@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
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.
@jmckitrick: alrighty you don't need to use the figwheel server
@jmckitrick: stick with you server
@bhauman: ok, I'll start there.
@jmckitrick: when you launch figwheel is will launch its server purely for communication
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?
@bhauman: Meaning setting up entry points...
@jmckitrick: yeah if you really have 5 different builds with different entry points yeah you will need 5 opt none builds
@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.
@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?
Cool, I'll give that a shot.
and after that is working you should just be able to do a lien clean and then add :figwheel true
to the build config.
@bhauman: Thanks for the help, I'll let you know how it works....
@jmckitrick: thanks!! I'm glad the talk helped! Gives me more motivation to work on my next one.
@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. Great presentation style as well, I really enjoyed it.
@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
@bhauman: Will do. I'll check in later....
@chenglou: So I’ve npm install
ed 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?
Make sure all build artifacts are gone. And make sure the connect script is gone as well
mm, yeah, clean-builds
from within figwheel cleaned things up, lein clean
was not sufficient … thanks
dnolen @chenglou: So in the case of ReactMotion expecting require, I assume I need to preprocess it away
@chenglou: You’re probably thinking of http://mneise.github.io/posts/2015-07-08-week-6.html
But that uses the closure compiler’s system to convert :commonjs
modules into something consumable by closure
@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
@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
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.
@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
note also that by supplying a script you can do things programmatically (to list all files) instead of jumping through declarative hoops
@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?
@jaen at least that’s what I remember, otherwise I would just do this programmatically.
To all figwheel users: request for comment https://github.com/bhauman/lein-figwheel/issues/232
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?
@venantius: In response to the figwheel repl comments. Its really not the figwheel REPL
figwheel uses the clojurescript repl and provides a connection to an eval environment.
I appreciated your post @venantius . I’ve encountered some of those issues more so than others
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
@bhauman: what would be interesting would be to enumerate the cases where dirty things aren’t recompiled
many the of changes the in last six months were pushing to avoid cold builds as much as possible.
@jaen I think it’s safer to keep it bare bones until people kick the tires a lot more.
@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.
and but I see weird stuff that is always just a clean away, and its normally from a cold build
changing figwheel versions is just another case of the something ClojureScript also has to handle
@dnolen: I was just looking for an example because personally I haven't seen it happen
re: switching Figwheel versions, I’m open to the idea of passing in additional meta to compile-file
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.
@bhauman: re slow :recompile-dependents
this will get fixed when we land @juhoteperi enhancements
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
@raymcdermott: you can use the REST service.
@raymcdermott: not really sure what you mean by that
@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
@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
yeah, same. I maintain vim-lamdify, which is far simpler than fireplace, and its more than enough vimscript for me.
@dnolen: Clojurescript compiler doesn't yet accept ES6 for :language-in
, is that correct?
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
@csmith: I have two vim clj plugins that I need to bring into line with cljs support
not having access to this on write yet in clojurescript kills me https://github.com/venantius/vim-cljfmt
ah yeah. I have = pulling from something ATM, not sure if vim-clojure or what. Kinda mostly works but not the same
hah sorry. = in normal mode is usually bound to the auto-indent rules of the syntax that’s loaded.
@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...
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
@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.
@jaen fixed https://github.com/clojure/clojurescript/commit/dc999f01d569f7b5a869e2c65408fdb3676c2936
@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
@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
@dnolen: in other words it would be nice to have a web client that could access a datomic DB
@raymcdermott: the rest interface is your only option really
@raymcdermott: I haven’t followed the REST based tooling around Datomic, might want to inquire in the #C03RZMDSH channel
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?
@grav as long your graph isn’t incredibly massive, graphviz should work, I’m assuming you just need to pass arrays + objects
So I’d just include the js dependency from a script tag, and then invoke it using js interop?
@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
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
If you need anything else to figure out what's wrong then just tell me and I'll try to provide more
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
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?
since they don’t validate you may get weird errors since the warnings aren’t designed to handle this case
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?
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.
So it seems this flag does not let me ingest ES6, or I'm making some other kind of error I'm not seeing.
@jaen what source here has let
? at the moment this the typical doing too many things at once I dislike
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.
@jaen you would think, but you never know and all the options can create subtle bugs as experience has shown
@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.
@jaen :import
is only for importing Google Closure classes so you can eliminate that from the list of things to consider
@jaen I would modify your example to be simpler, only interested in interaction between :commonjs
and :require
@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.
@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
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
@jaen: these things always need tire-kicking, until people actually try it out won’t actually get finished
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 ;
@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
@jaen: You could submit a patch for this, if @dnolen is not already on it? Or I am also happy to fix this 😉
@maria fixed part of the issue, https://github.com/clojure/clojurescript/commit/cc953d4be7b4a256fd5eae783f9106a2929a4126
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
we don’t convert the file to ES3 which is the probably the right default unless overridden by the user
hrm it does bring up another interesting question - the language in and out setting should probably be specifiable at the module level?
I suppose so, it makes sense to to use ES6 language level only for files that need that.
then people can package up JS libs unmodified and debug the original source same as they do ClojureScript
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
@jaen preferable to defer to Closure for ES6. Was only really interested in Babel for JSX or other various plugins.
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"]}]
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?
@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
Hm, but React Native is not released for Android yet, so I'd rather look towards something with Phonegap
I think this might have been this repo - https://github.com/enterlab/cordevicljs
@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.