This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-29
Channels
- # bangalore-clj (2)
- # beginners (22)
- # boot (28)
- # cljs-dev (91)
- # cljsrn (4)
- # clojure (30)
- # clojure-austin (8)
- # clojure-conj (4)
- # clojure-japan (1)
- # clojure-russia (3)
- # clojure-spec (9)
- # clojure-uk (8)
- # clojurescript (42)
- # cursive (2)
- # editors (1)
- # hoplon (16)
- # klipse (91)
- # lein-figwheel (1)
- # luminus (9)
- # off-topic (4)
- # om (83)
- # onyx (29)
- # perun (6)
- # re-frame (17)
- # spacemacs (6)
- # untangled (1)
- # vim (5)
@dnolen did you have time to look at http://dev.clojure.org/jira/browse/MATCH-116
@dnolen hrm, could this be everything that's needed for tagged literals to work? no self-host support yet https://github.com/anmonteiro/clojurescript/commit/e905d3bafa1530697d617fa77cc4174c1049296f
Been testing the Closure npm support.. and.. this will need some work still 😄
React depends on fbjs and corejs, and those include some crazy code
Perhaps those can safely be skipped, not sure
The module processing will try to process all files in foreign-deps, and will fail if single file can't be processed
Even if that file is not required by anything
@juhoteperi "crazy code" that Closure still doesn't understand?
But I'll start with trying to use some simpler npm module
hmm, success, kind of
(ns circle-color.core
(:require [object-assign]))
(js/console.log (js/module$cljsjs_npm$object_assign$index #js {:foo 0} #js {:bar 1}))
Had to use js/
as I don't think it is possible to refer to the function exported in object-assign root
Though in this case it probably works because object-assign
name is defined by deps.cljs entry
Oh, the Closure npm require resolving works for files inside node_modules
Though I guess that makes some sense
I think that's what they intended by implementing the node resolution algorithm 🙂
For example file resources/public/js/libs/Circle.js
can't use npm modules
but could probably use the generated Closure module name
I'm not following
The file path doesn't contain node_modules
So the npm module logic is not used
This is one dependency of fbjs that causes problems
but there are 85 processing errors with React, and that is without core-js which causes Exception
@juhoteperi what if you use the browserified stuff?
(I know it's not the purpose of the experiment, but still..)
I'd presume then everything works as previously as there won't be npm modules
hrm there still is
react-dom
-> react
ah ok
I had to change that require to be ./react
I think it will need mock package.json
oh but you'll run into the same problems, nevermind
does somebody know why with the default eval context of eval-str
- :`statement` expressions like (if 1 2 3)
are nillified?
I looked in the code of the compiler and I saw a couple of places with code like this:
(when-not (= :statement (:context env)) …)
@viebel because those are expressions
so you need to use :context :expr
For instance:
(defmethod emit* :constant
[{:keys [form env]}]
(when-not (= :statement (:context env))
(emit-wrap env (emit-constant form))))
I know that :context :expr
solves the problem
my question is: why those expressions are ignored in :statement context? what is the rationale?
I think statements are supposed to not return anything
what do u mean?
"The :context basically tells the compiler if the return value is required (:statement vs. :expr). A :statement does not need to return something and "if" in javascript does not return something."
what’s the point of not returning something?
is it for optimization reason - in order not to generate code that does nothing?
anyway, in klipse I have no workaround I can think of
When I use :statement
- which is default in klipse - expressions are nillified http://app.klipse.tech/?cljs_in=(let%20%5Ba%204%5D%0A%20%20(if%20(%3E%20a%202)%203))
And when I use :expr
, I cannot evaluate more that one expression http://app.klipse.tech/?cljs_in=(def%20a)%0A(if%20(%3E%20a%202)%203)&eval-context=expr
I was thinking of overriding all the emit*
functions that ignore pieces of code
For instance instead of
(defmethod emit* :constant
[{:keys [form env]}]
(when-not (= :statement (:context env))
(emit-wrap env (emit-constant form))))
I will override it by:
(defmethod emit* :constant
[{:keys [form env]}]
(emit-wrap env (emit-constant form)))
@viebel Consider (do 1 (prn 2) 3 4)
. As an optimization, the constants 1
and 3
are elided.
@mfikes that’s only for optimization purposes?
@viebel Seems like a reasonable interpretation. Perhaps that’s what Rich meant by “minimize bootstrap js” here https://github.com/clojure/clojurescript/commit/86ad57839aa471b03d17c7ce1418736c7e9c7388
OK. Thx @mfikes. I hope @dnolen will see this thread and give interesting insights
Another thing related to compilation @mfikes: I found an interesting way to prevent infinite loops in boostrapped cljs
Both in klipse and planck
(loop [x 1] (recur x))
will stuck the process or the browser
In planck, it’s less an issue than in KLIPSE, because you have Ctrl-C
Anyway, I had this idea of emitting guard()
function calls at interesting points of the code
guard()
will check how much time has elapsed since the beginning of the evaluation
and if too much time has elapsed, it will throw an exception
what do u think @mfikes ?
If you could get guard()
to read some volatile variable that you could set, then you could cooperatively interrupt evaluation, perhaps in the spirit of https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/middleware/interruptible_eval.clj#L265
It’s very easy to make guard()
read a volatile variable
The tricky question is: where to insert the guard()
calls?
I thought about two places:
1. before every if
statement
2. before continue
emitted be recur
If you sort that out, you could propose a useful compiler mode. Perhaps it would be well-received if not too complicated.
I have a wip pull request in klipse https://github.com/viebel/klipse/pull/131/files
it seems to work and it’s not a lot of code
I came to this idea after a discussion with @jrheard
@mfikes what do u mean by a useful compiler mode? a flag to cljs.js/eval
?
A general compiler flag, or perhaps a REPL option flag. For example, :def-emits-var
was deemed sufficiently useful to take on the complexity of essentially a different “mode."
If you have time to take a quick look at https://github.com/viebel/klipse/pull/131/files it’d be great - it’s just a couple of lines
Opinion: Interruptibility of accidentally long-running computations during dev, if achievable without excessive compiler complexity, and without harming dev perf, might pass muster.
@viebel Since you can do it outside of the compiler, you can spend some time learning if it works. 🙂 (I’m doing essentially same with eval
.)
Can u think of other interesting hooks beside if
and continue
?
No. This is one of those things that I think you can either spend time analyzing thoroughly, or you can just accumulate some time with it. (Or both.)
Will do both
thx for your inputs