This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-13
Channels
- # bangalore-clj (1)
- # beginners (40)
- # boot (22)
- # clara (19)
- # cljs-dev (265)
- # clojure (160)
- # clojure-dev (6)
- # clojure-italy (5)
- # clojure-russia (47)
- # clojure-spec (10)
- # clojure-uk (63)
- # clojurescript (88)
- # core-async (8)
- # cursive (54)
- # datomic (48)
- # emacs (32)
- # garden (3)
- # graphql (29)
- # hoplon (54)
- # jobs (1)
- # klipse (4)
- # luminus (5)
- # lumo (21)
- # mount (5)
- # off-topic (16)
- # om (2)
- # pedestal (10)
- # play-clj (1)
- # portkey (32)
- # re-frame (21)
- # reagent (48)
- # rum (1)
- # spacemacs (4)
- # sql (3)
- # unrepl (5)
it’s impressive what we did in the last 12 days though: https://github.com/clojure/clojurescript/compare/r1.9.671...HEAD
since the last release
w-o-w
@dnolen fixed the :rename
support for JS modules in CLJS-2217. But please apply CLJS-2220 before because CLJS-2217 depends on the test NS that it introduces
Testing master right now. Should code splitting work with :npm-deps
?
Getting No :out-file for IJavaScript #cljs.closure.JavaScriptFile
error
works fine under adv optimizations, but not with :none
@roman01la make something minimal file an issue
@juhoteperi does :global-exports
have the same :rename
support issue?
@dnolen I think @anmonteiro's patch fixed global-export also
But it doesn't have a test
@juhoteperi thanks noted on the issue
yesterday’s post did pretty well, pretty much double the traffic from the code splitting post
David, can you share the post url again?
@viebel we always post under /news https://clojurescript.org/news/news
one interesting data point is that Quick Start appears to get ~4000 views a month and the engagement numbers are quite high, average time on page is nearly three minutes. I definitely think there is a pretty big engagement opportunity here by providing a “Try It” page with bootstrapped REPL.
I really like the above idea, bootstrap is one of those things that make people go "Ooooh" 😄
The replumb library (driving http://clojurescript.io) is probably a good starting point, in terms of maturity, I’d speculate
Hmm… http://clojurescript.io is on 1.8.40
@mfikes no I haven't had time to update replumb
and it actually failed at its goal
I don't think many folks needed to have a common lib for that
the largest bootstrap applications (planck, lumo, klipse) all use custom implementations
So, if Quick Start had a bootstrapped REPL Try It link, it could be a bespoke one built for it.
yeah it’s not that hard, I don’t think we need a third party project for this 🙂 Probably we’ll just need some help from Alex Miller about building the ClojureScript we need and getting it copied to the right place when we deploy.
I think you are right, though, if there were a big Try It! button in the menubar on the Quick Start page (that essentially looks like Get Started! button on the main page), lots of people would immediately get a taste of it 🙂
@dnolen I'm happy to add the global exports tests either with that patch or as a follow-up
I'm more interested in the feedback for CLJS-2220
i.e. do we want to rely on :npm-deps for running runtime tests
I see no problem with it but thought you might have opinions
@anmonteiro no opinions other than this seems necessary? 🙂
Great
Yesterday's post is featured in this week's Node Weekly that goes out to 37k subscribers: http://nodeweekly.com/issues/196
@dnolen augmented CLJS-2217 with tests for rename + global exports
(just leaving another note to please apply CLJS-2220 before CLJS-2217)
@anmonteiro all your patches are applied
@dnolen there’s still a trivial one that enables JSC under test-simple
again https://dev.clojure.org/jira/browse/CLJS-2219
I think there are no problems enabling it again, and running test-simple
was useful to figure out the module stuff was working before adding externs
@anmonteiro applied
@mfikes perhaps we should go live with yours tomorrow, @juhoteperi’s on Monday, and I will do a final post on :global-exports
on Wednedsay before EuroClojure?
@anmonteiro Dunno if you are aware, unit tests failing
There is a little ambiguity as to when it started failing: https://github.com/mfikes/clojurescript/commits/master
hrm.. works on my machine™
let me dig
I know the fix
fixing
looking at https://github.com/clojure/clojurescript/wiki/Building-the-compiler, what is the right thing to build on canary? script/build or script/uberjar?
lein test
is also showing things like:
actual: java.lang.IllegalArgumentException: No implementation of method: :-find-sources of protocol: #'cljs.closure/Compilable found for class: cljs.build.api$inputs$reify__6717
just needed to fix travis.yml
@dnolen ok, thanks, I’m going to add some new options to that script, need to run maven in batch mode and make it less verbose (hitting travis output limits), all will be optional driven by env flags
@anmonteiro that patch looks unnecessarily large?
fixed now
ran a bad command
@dnolen 1 insertion, 1 deletion now
that’s more like it
I wonder if somehow including "assert"
in native-node-modules
is causing the self host tests under node to wig out. Hrm.
undeclared warning in self-host: https://dev.clojure.org/jira/browse/CLJS-2223
thanks CI
yeah, assert might be a problem hrm
I think we should just remove it from the native-node-modules
list
@dnolen thoughts?
@anmonteiro I don’t understand why it’s problem?
I think we’re compiling the self-host/ self-parity test runners with :target :nodejs
and assert
is somehow taking precedence in resolve
?
may actually not be a good assumption
let me repro locally and I’ll have more info
meanwhile CLJS-2223 fixes a warning in self-host
agreed, looking into it
it may show the module as fn support is broken (we need to guard - should only work if :require’d)
that’s definitely the problem btw
@dnolen I don’t know if we can move these to the final branch?
we need to bottom out somewhere
I think user-defined vars should take precedence, so move those up?
I’ll gather more info and get back to you
I’m talking about the :else
branch in resolve-var
for context
I didn’t see the core-name?
call
heh, it’s funny how much you can remember when you’ve been working on this stuff too long 😛
definitely
@dnolen just to confirm, in that last case order should be: 1. core name 2. user-defined (current ns) 3. module
oops got those wrong
exactly
thanks
I’ve updated the aget
post https://github.com/clojure/clojurescript-site/pull/101 to reflect the latest patch in https://dev.clojure.org/jira/browse/CLJS-2198, set with a tentative date for tomorrow release, etc.
@dnolen I’ve confirmed (somewhat manually) that the -v11
patch in CLJS-2198 doesn’t cause the build to fail. I suppose if the stuff discussed above is sorted first, I can re-baseline and attach a -v12
@darwin If working on Canary, just wanted to let you know I sorted the Planck build failures. TL;DR: Planck master should build fine with ClojureScript master.
btw. canary is able to build clojurescript jar, now figuring out how to determine what was actually built and how to “upload” it somewhere: https://travis-ci.org/cljs-oss/canary/builds/253347045
the idea is to have another branch “builds” or similar, which will be used as a storage for all jars, at least for now
I’m glad we found out the resolve bug before the release
this was actually here before, and it’s a pretty bad bug 😛
submitting the patch soon, I have fix & test
we don’t ever do just npm install
do we?
we’ll always install the required deps
I took it literally 🙂
getting a bunch of aget
warnings with master but I think this is expected
@anmonteiro The only ones that are expected are logs associated with the tests that cause them. (Which we can probably squelch if we mess with js/console)
is cljs.array-access-test
supposed to throw a number of errors?
running test-self-parity
Yes… I think it is too noisy. It goes down a path that calls js/console.warn
and maybe we can block those for the duration of that test namespace
I don’t mind
as long as I get 0 errors 0 failures
in the end 🙂
found CLJS-2226 from a HN comment 😛
will be useful for orgs to support @org/package-name
format
some other people already publishing packages with those names too
@anmonteiro is there any cleanup we should do? https://dev.clojure.org/jira/browse/CLJS-2206
not off the top of my head
I think @juhoteperi deleted every remain of missing-js-modules
agreed
I’m loathe to really look at any new or other outstanding tickets as this release will undoubtably create some churn
I think CLJS-1955 was also slated for this release
your decision whether it makes it or not
hah yeah 🙂
@anmonteiro needs a rebase
on it
@dnolen replaced the patch
@dnolen when are you thinking about releasing the next version?
I’d love to kick the tires on all this stuff during the next week
before releasing
sounds good to me
I just want the weekend to play with it 🙂
and bring Lumo up to date with all the new stuff
(and submit any patches that may be needed to make string-requires work there)
also now that we have a unified :require
for non true foreign libs, indexing JS requires and doing basic usage validation is starting to sound compelling
what is the React Native Packager problem?
we could probably solve that sooner .. ModuleLoader
is a thing in Closure, we could provide one for RN
It essentially gets in between you and React Native, causing issues. One was that it translates JavaScript using a Facebook-proprietary include mechanism.
agreed
Part of my issue with the React Native Packager is actually just a lack of knowledge about it
@mfikes I’d be happy to pair with you to get some of that stuff figured out someday
right. introduce as few variables as possible
added some issues https://github.com/clojure/clojurescript-site/issues
Btw, re EuroClojure, anyone here going to attend?
Still undecided myself, the timing is quite inconvenient.
@dnolen ooops forgot about this https://dev.clojure.org/jira/browse/CLJS-2228
@juhoteperi wat? 🙂
It is middle of Finnish summer vacation
I don't have much problem with that myself, but many will have plans with families etc so much less Finns will be attending this year than usual
And, it might be easier for users of the feature to squelch chunks of code on their own.
It is good we have a week to bang on all of this stuff (it takes a while to polish the corners and get the ergonomics right)
I’m digging into using this stuff with core.async, and I’m thinking that core.async might be right and the new diagnostic wrong. The tag list is [objects number]
. Need to figure out what objects
is.
@dnolen Adding objects
to the symbol set here https://github.com/clojure/clojurescript/blob/bc28ddd68f0d4c769cdc9986d559dd60eb41be0c/src/main/clojure/cljs/analyzer.cljc#L2999 made core.async
build without triggering warnings
Cool. The only remaining warnings I see now appear all be legit. For example: https://github.com/bhauman/lein-figwheel/blob/f772e351a2e2a260cdeca6a4958fb3643507a2f2/support/src/figwheel/client/socket.cljs#L8 causes this diagnostic
WARNING: cljs.core/aget, arguments must be an array followed by numeric indices, got [js string] instead (consider goog.object/get for object access) at line 8 target/ios/figwheel/client/socket.cljs
In this case window
is Object but what if it was Array? The compiler can't know what is the type of of js/
var??
@juhoteperi we allow js
stuff to pass
Oh right
@dnolen Master seems to be inappropriately emitting disgnostics for any
now. For example:
WARNING: cljs.core/aget, arguments must be an array followed by numeric indices, got [any number] instead at line 84 target/ios/cljs/core/async/impl/timers.cljs
@dnolen Master is good. This is with a project using Om Next as well (no static diagnostics triggered). I also tested a Reagent project (no static diagnostics there either).
I left Bruce a gift https://github.com/bhauman/lein-figwheel/issues/572