Fork me on GitHub

@dnolen hrm, could this be everything that's needed for tagged literals to work? no self-host support yet


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


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

Yehonathan Sharvit21:10:55

does somebody know why with the default eval context of eval-str - :`statement` expressions like (if 1 2 3) are nillified?

Yehonathan Sharvit21:10:24

I looked in the code of the compiler and I saw a couple of places with code like this:

Yehonathan Sharvit21:10:41

(when-not (= :statement (:context env)) 鈥)


@viebel because those are expressions


so you need to use :context :expr

Yehonathan Sharvit21:10:32

For instance:

(defmethod emit* :constant
  [{:keys [form env]}]
  (when-not (= :statement (:context env))
    (emit-wrap env (emit-constant form))))

Yehonathan Sharvit21:10:58

I know that :context :expr solves the problem

Yehonathan Sharvit21:10:26

my question is: why those expressions are ignored in :statement context? what is the rationale?


I think statements are supposed to not return anything


"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."

Yehonathan Sharvit21:10:45

what鈥檚 the point of not returning something?

Yehonathan Sharvit21:10:00

is it for optimization reason - in order not to generate code that does nothing?

Yehonathan Sharvit21:10:27

anyway, in klipse I have no workaround I can think of

Yehonathan Sharvit21:10:11

When I use :statement - which is default in klipse - expressions are nillified

Yehonathan Sharvit21:10:35

I was thinking of overriding all the emit* functions that ignore pieces of code

Yehonathan Sharvit21:10:53

For instance instead of

(defmethod emit* :constant
  [{:keys [form env]}]
  (when-not (= :statement (:context env))
    (emit-wrap env (emit-constant form))))

Yehonathan Sharvit21:10:03

I will override it by:

Yehonathan Sharvit21:10:15

(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.

Yehonathan Sharvit22:10:19

@mfikes that鈥檚 only for optimization purposes?


@viebel Seems like a reasonable interpretation. Perhaps that鈥檚 what Rich meant by 鈥渕inimize bootstrap js鈥 here

Yehonathan Sharvit22:10:24

OK. Thx @mfikes. I hope @dnolen will see this thread and give interesting insights

Yehonathan Sharvit22:10:11

Another thing related to compilation @mfikes: I found an interesting way to prevent infinite loops in boostrapped cljs

Yehonathan Sharvit22:10:40

Both in klipse and planck

(loop [x 1] (recur x))

Yehonathan Sharvit22:10:51

will stuck the process or the browser

Yehonathan Sharvit22:10:28

In planck, it鈥檚 less an issue than in KLIPSE, because you have Ctrl-C

Yehonathan Sharvit22:10:54

Anyway, I had this idea of emitting guard() function calls at interesting points of the code

Yehonathan Sharvit22:10:21

guard() will check how much time has elapsed since the beginning of the evaluation

Yehonathan Sharvit22:10:38

and if too much time has elapsed, it will throw an exception


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

Yehonathan Sharvit22:10:14

It鈥檚 very easy to make guard() read a volatile variable

Yehonathan Sharvit22:10:43

The tricky question is: where to insert the guard() calls?

Yehonathan Sharvit22:10:53

I thought about two places:

Yehonathan Sharvit22:10:07

1. before every if statement

Yehonathan Sharvit22:10:23

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.

Yehonathan Sharvit22:10:30

it seems to work and it鈥檚 not a lot of code

Yehonathan Sharvit22:10:35

I came to this idea after a discussion with @jrheard

Yehonathan Sharvit22:10:25

@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 鈥渕ode."

Yehonathan Sharvit22:10:38

If you have time to take a quick look at it鈥檇 be great - it鈥檚 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鈥檓 doing essentially same with eval.)

Yehonathan Sharvit23:10:58

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.)

Yehonathan Sharvit23:10:50

thx for your inputs