This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-14
Channels
- # aleph (2)
- # atlanta-clojurians (5)
- # beginners (38)
- # boot (2)
- # bristol-clojurians (1)
- # cider (31)
- # clara (8)
- # cljs-dev (136)
- # cljsrn (4)
- # clojure (86)
- # clojure-china (1)
- # clojure-greece (1)
- # clojure-italy (24)
- # clojure-nl (1)
- # clojure-spec (21)
- # clojure-uk (19)
- # clojurescript (68)
- # community-development (28)
- # core-async (35)
- # core-logic (4)
- # cursive (1)
- # data-science (1)
- # datascript (1)
- # datomic (46)
- # events (1)
- # figwheel (6)
- # fulcro (11)
- # graphql (3)
- # hoplon (1)
- # jobs (6)
- # jobs-discuss (94)
- # keechma (3)
- # luminus (4)
- # lumo (7)
- # mount (6)
- # off-topic (24)
- # onyx (6)
- # parinfer (31)
- # portkey (3)
- # programming-beginners (16)
- # re-frame (20)
- # reagent (69)
- # remote-jobs (4)
- # ring-swagger (25)
- # schema (1)
- # shadow-cljs (151)
- # spacemacs (2)
- # sql (14)
- # tools-deps (16)
- # uncomplicate (5)
- # unrepl (35)
- # vim (1)
- # yada (72)
Is there a ticket to follow for this?
@juhoteperi’s suggestion to add newlines would work out nicely for self-hosted ClojureScript in that it would "just work"
until the debugger stops being line based, it’s not going to be significant enhancement
but if someone wants to try and experiment and show there’s is a significant experience delta - that’s great
After several months of seeing these in every maria build, I’m wondering if we can do something about these warnings:
------ WARNING #1 --------------------------------------------------------------
File: cljs/spec/test/alpha$macros.cljc:113:35
--------------------------------------------------------------------------------
110 | ([xs]
111 | `(instrument ~xs nil))
112 | ([sym-or-syms opts]
113 | (let [syms (sym-or-syms->syms (eval sym-or-syms))
-----------------------------------------^--------------------------------------
Use of undeclared Var cljs.spec.test.alpha$macros/eval
--------------------------------------------------------------------------------
114 | opts-sym (gensym "opts")]
115 | `(let [~opts-sym ~opts]
116 | (reduce
117 | (fn [ret# [_# f#]]
--------------------------------------------------------------------------------
according to this discussion https://clojurians-log.clojureverse.org/lumo/2017-08-02.html, this is expected because we set!
eval from somewhere else.
would it work to just (declare eval)
in that namespace?hrm probably not a good idea - we could declare eval
which does nothing in cljs.core
for this case
@kommen try master, your test.edn
thing takes ~78ms to validate even on a slow machine like mine
well, I guess the tools.deps migration with the ability to use git deps is paying off already
I wonder, for the eval
problem: If the compiler is compiling all of the source in a directory, if it could skip any .cljc
file for which there is a .cljs
file. This would be consistent with the rule for require
where it must load a .cljs
file in preference to a .cljc
file. (Which differs from the rule for require-macros
.)
I suppose that is fairly close; it misses the possibility that there might be a .cljs
file somewhere else in the classpath.
I could try an experimental patch to see if it resolves this without breaking anything. Unless we know it won’t work for some reason.
I dunno, I think in this case the fact that we use eval
and it’s missing seems like a problem for that ns
in fact maybe eval
should call *eval*
should be a thing which throws if not bound to something
Yeah, that’s how Planck and Lumo skate by, they have defined a synchronous eval, and monkey patch that namespace so that eval
is defined in there.
Cool. I’ve often wondered if compiling that .cljc
file as ClojureScript might accidentally overwrite the output that you would get for .cljs
. Perhaps we have been getting lucky all along in that it gets compiled first. Dunno.
Anyway, https://dev.clojure.org/jira/browse/CLJS-2660 ^
@dnolen Saw your note. Cool. I was also pondering promoting this version of eval
from the test namespace into the cljs.js
namespace as the overridable default for that environment. https://github.com/clojure/clojurescript/blob/master/src/test/self/self_parity/test.cljs#L293
This might be too much change in public API, but just pondering that it might simplify things.
As usual, willing to try an exploratory patch for consideration. No worries if rejected after seeing what it looks like.
@mfikes default should throw. But cljs.js could set! to this test thing we have as you’re suggesting
I guess benefit of stalling on some things for a couple years - it’s much clearer that something is a good idea or not 🙂
that is pretty cool, and I guess it means that cljsjs.js
users have a pretty easy way to try things now
Yeah. I’m adding lots of tests to ensure things work out. Some wild runtime things are evaluated in this test namespace https://github.com/mfikes/clojurescript/blob/bf264dc790e077b4d330eeae3045e6477f84f8db/src/test/cljs/cljs/eval_test.cljs
which ensures less name churn between advanced builds thus proper vendorization if you’re using :modules
Captured :stable-names
so we don’t forget https://github.com/clojure/clojurescript-site/pull/156#issuecomment-373045518
@dnolen If you are merging patches, this is simple fix: https://dev.clojure.org/jira/browse/CLJS-2658
@juhoteperi applied
@dnolen thanks
will try to tackle that on Friday and hopefully that can make it into the next release
@juhoteperi re: React, you’re talking about the latest React right? Seems like minor tweaks though?
Yes, I sent PR to fix this: https://github.com/facebook/react/pull/12370
https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#nocollapse should also fix that is a less hacky way
I think that wouldn't work as React CJS bundles are already minified: https://unpkg.com/[email protected]/cjs/react-dom-server.node.production.min.js
React 16 node packages don't contain any other but CJS bundles 😕
It only affects React-dom/server + optimizations
i.e. Reagent test suite with optimizations
They have two open PRs to build bundles using GCC so maybe they'll do that eventually
well I’m getting more excited about :npm-deps
- it seems like more & more stuff is working
made a little thing to kick the tires on Java-WebSocket: https://gist.github.com/johnmn3/a845f2bf67ad877d957bccd7f9cefe8c
@mhuebert There is now a patch in https://dev.clojure.org/jira/browse/CLJS-2660 If you end up with some free time at some point, it would be nice to know if it causes the eval
warning to go away for you.
thanks for the patch! and the instructions for deps
, that was really simple to test.
it threw the expected warnings for the eval
function I had defined in my own namespace -- with this patch applied I could change that now to (set! *eval* ...)
or exclude eval in the ns declaration.
The patch does a (set! *eval* ...)
in the cljs.js
namespace so you end up with a functioning cljs.core/eval
in the self-hosted case
Long running operations hang the browser, so I think so. I think I'm falling in love with Maria, btw 🙂
Oh, I just looked at the code @mhuebert. You may be able to ultimately delete Maria's eval
and just use cljs.core/eval
, given that cljs.js
sets up one for you. (Depending on what Maria is really doing in its eval
.)
In other words @mhuebert the scope of CLJS-2600 was expanded a little so that by default if you are using self-hosted ClojureScript, you get a functioning eval
.
our eval is indeed wrapped with a bit of extra stuff. we log intermediate steps, like the compiled-js, which lets us trace a user function back to the cell & time it was produced, and do some extra resolving of position info in the case of errors
OK @mhuebert since cljs.js
does a set!
, a good test would be to, perhaps right after Maria's eval
is defined, to do a set!
there to ensure that Maria's is the one that ends up being used within the app.
I haven’t followed all the latest cljs.js developments, had a lot of work the last few months but am getting back into it now
This should work, as maria.eval
requires cljs.js
and it can then mutate a little further with its own set!
ok. I’ll have to look at this, our eval functions weren’t really designed for user-space but rather to evaluate our code cells, hence the logging and what not. If users want to call eval
it probably makes sense to let them use the most “normal” version
do I recall correctly that you have mentioned somewhere an easy way of testing patches like this with deps?
Yes, @mhuebert I have the patch in a branch. Just a sec and I’ll give you the right coordinates.
@mhuebert This has CLJS-2660 applied in it:
{:deps {org.clojure/clojurescript {:git/url "" :sha "ec281b735b5c3e1a80f1cc46f8996aba45d13987"}}}
and is also based of a recent master (1.10)We just need to convince tools.deps.alpha
to add a :with-patches ["
and we’ll be in a whole different place 🙂
that's an awesome idea Mike
well...the other side is clj --create-jira-ticket
😄
@dnolen yeah, a fun little addition would be to make it a cljc file and allow the client side to launch with cljs.main 🙂
I assume the http connection would "upgrade" to ws somewhere around here: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/repl/server.clj#L202
@john actually I don’t necessarily see a reason to do that, if we support websockets I think it should be fully decoupled from the webserver
I think most of work here is going to be making sure it’s easy to integrate with Ring, Pedestal or whatever
So something akin to weasel's server: https://github.com/tomjakubowski/weasel/blob/master/src/clj/weasel/repl/websocket.clj
:stable-names
added to a section in http://_1.10.xxx Release_ and as a compiler option PR
https://gist.github.com/mfikes/bdbe214f03abac88ae384adb1ac26490
If we have a cljs.core/eval
sitting there, someone will ask whether it works in regular ClojureScript. Of course it doesn’t but you can trick yourself into making one that evidently works in a REPL if you require cljs.js
: https://gist.github.com/mfikes/8fcff361937d5a2880aa2520d44233d0
I keep getting what appears to be spurious analysis errors clojure.lang.Keyword cannot be cast to clojure.lang.IAtom
I'm in a cljc file and its the clojurescript compiler giving me these errors on 1.10.145
To summarise the discussion about AOT cache, closure defines, and macros: Doing any kind of environment based compilation is unsafe with the new AOT cache, instead you should closure-defines which will safely invalidate/use the correct cache
What about :external-config
, is that still safe to use?
And will different closure-defines for a single JAR (say dev vs prod) invalidate a cache, or add a second cache entry for each?
https://github.com/mfikes/clojurescript-site/blob/issue-183/content/news/2018-03-12-shared-aot-cache.adoc was helpful
@danielcompton closure defines do not affect the compilation of a single .cljs file, so it doesn't affect cache in any way
Ah, I was thinking about advanced compilation where the defines are substituted, but that happens as a later stage right?
What about :external-config?
no idea, not a thing in CLJS. probably breaks the cache if used by macros in any way
@danielcompton :external-config
is not safe to use, search for prior discussions here
Ok, I assumed it was a native ClojureScript feature, but it's not?
no, it is not, we were abusing the fact, that compiler options is an open map, and we can access it in macros
Ohhhhh
AFAIK there is no way how to safely use user-specified configuration in macros with enabled :aot-cache
Yeah, I'm working on this with https://github.com/Day8/re-frame-debux/commit/144c9236969294c847fe7e3442a6d9b890f2f807, and I'm relying on Closure DCE to remove the code in advanced compilation
and using closure-defines for the config
LGTM, good luck and let us know how it went - I’m still a bit skeptical. DCE is a complex beast and does not work when you cross some complexity threshold, also it is a moving target and each new closure compiler version could behave differently in this regard.
Maybe you should write some tests and make sure closure defines configured DCE elided code you expected.
Yeah I'm going to write some tests on this. I found I had to hide the Closure-define behind a boolean typed function for the DCE to work. I have found it eliminates the traced function, I need to do some more work on removing it entirely form the app (will have a separate JAR dependency which isn't in the prod build to ensure this)
instead of a separate JAR I would also consider using modules and loading optional code dynamically behind the :closure-define flag
@danielcompton if you are on the 1.10.x versions you shouldn't need any of the type-hinting ceremony around the DCE goog-define. https://dev.clojure.org/jira/browse/CLJS-1439 now automatically type hints as boolean
.
Excellent, was just thinking about opening a ticket for this when I was going through all of that work