Clojurians
#cljs-dev
<
2016-09-27
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

anmonteiro13:09:28

@dnolen Don’t mean to rush you at all, just wanted to put this patch on your radar in case it’s not there yet Really excited for its possibilities http://dev.clojure.org/jira/browse/CLJS-1782

dnolen14:09:30

@anmonteiro sorry I need to review that one more closely will probably have to wait to Friday but I will put it at the front of my queue

anmonteiro14:09:00

that works great, thanks!

viebel14:09:35

@anmonteiro Can you elaborate about why currently when a namespace requires its own macros, there is an infinite loop?

anmonteiro14:09:15

@viebel have you tried the minimal example in that issue in e.g. Planck?

viebel14:09:34

Yeah. I mean: what is the explanation for that behaviour?

anmonteiro14:09:08

the problem is that if you have the foo.core namespace, and you require its own macros, the foo.core$macros namespace will also try to require its own macros and so on

anmonteiro14:09:23

that results in an infinite loop

anmonteiro14:09:12

but there’s no such thing as a $macros namespace requiring its own macros, which is what my patch addresses

viebel14:09:25

Oh. I see: in boostraped cljs, the reader conditional interprets #?(:cljs as true

anmonteiro14:09:36

@viebel yeah, that’s the problem

anmonteiro14:09:43

macros are not evaluated in Clojure

anmonteiro14:09:51

because, oh well, self-hosted ¯\(ツ)

viebel14:09:51

@anmonteiro I hope your patch will be merge soon. It will make much easier to port clojurescript libs

anmonteiro14:09:26

this problem doesn’t happen when you have e.g. a .cljs file and a .cljc file however

viebel14:09:35

Is there a particular lib that might be supported with your patch - without any code modification?

anmonteiro14:09:00

it’s really specific to the case where you have a single .cljc file that you want to share between Clojure/ClojureScript/Self-hosted

anmonteiro14:09:06

which becomes amazing.

anmonteiro14:09:12

@viebel yes, Om Next

anmonteiro14:09:30

after the server-side rendering patch it runs into this issue

anmonteiro14:09:36

I tested it with my patch and it works great

viebel14:09:52

WONDERFUL:sunglasses::clap:

anmonteiro14:09:53

which is a rather cool sign

viebel14:09:55

I remember that a couple of months ago, I tried to load https://github.com/tonsky/datascript/ in KLIPSE and I had the “infinite loop” problem

viebel14:09:02

Did u try it?

anmonteiro14:09:05

well, let’s give it a try!

anmonteiro14:09:31

mind putting together a snippet?

anmonteiro14:09:03

IDK, a snippet that works in JVM CLJS

anmonteiro14:09:12

that I can try locally with my patch in self-hosted

anmonteiro14:09:18

e.g. which namespace to load etc

viebel14:09:20

OK. Will send u one soon

anmonteiro14:09:24

I have never used datascript extensively

anmonteiro14:09:10

@viebel nah doesn’t work

anmonteiro14:09:17

because all macros are under :clj conditionals

anmonteiro14:09:15

it’ll require some changes

viebel14:09:46

Why is it a problem that the macros are under :clj conditionals?

anmonteiro14:09:39

because bootstrapped CLJS won’t read :clj conditionals

anmonteiro14:09:59

there’s no :clj reader in bootstrapped cljs AFAIK

viebel14:09:45

You mean that the codes under :clj will never get evaluated - in bootstraped cljs?

anmonteiro14:09:01

not even read

anmonteiro15:09:13

@dnolen there’s no cljs.core/num, is this intended or an oversight?

anmonteiro15:09:35

only meant for parity with Clojure

dnolen15:09:55

what does that do?

anmonteiro15:09:10

Coerce to Number

anmonteiro15:09:18

I also wasn’t aware it existed until just now

anmonteiro15:09:49

I don’t know if it’s supposed to exist or not, but given that unchecked-int exists, I asked

dnolen15:09:53

hrm but what is the implementation?

anmonteiro15:09:19

(defn num
  "Coerce to Number"
  {:tag Number
   :inline (fn  [x] `(. clojure.lang.Numbers (num ~x)))
   :added "1.0"}
  [x] (. clojure.lang.Numbers (num x)))

anmonteiro15:09:22

not easily portable

anmonteiro15:09:40

maybe something like (js/Number x)

dnolen15:09:00

so I guess it dispatches to NumberType/parseTYPE

dnolen15:09:28

I don’t know that is supposed to do then

anmonteiro15:09:48

it just casts the argument to java.lang.Number

dnolen15:09:14

I don’t know this doesn’t seem very useful

anmonteiro15:09:41

@dnolen I agree, my asking was only related to API parity with Clojure

dnolen15:09:34

I just don’t know what it should do

dnolen15:09:44

I’d rather add the last few remaining things if we actually need them

anmonteiro15:09:12

what I suggested earlier (js/Number x) wouldn’t really mimic the Clojure version anyway

dnolen15:09:39

btw, after some more thought, yes I do like the loading the same file for macros patch idea

anmonteiro15:09:43

boot.user=> (num "3.3")

java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Number
cljs.user=> (js/Number "3.3")
3.3

dnolen15:09:49

will clean up a lot of ClojureScript/Clojure nses

anmonteiro15:09:07

@dnolen awesome, glad to hear

juhoteperi18:09:03

New Closure compiler version, this one again breaks APIs compared to previous version :smile:

juhoteperi18:09:47

(or maybe I just have a problem the new dep)

juhoteperi19:09:34

It was just a problem with Intellij/Cursive not seeing the new dep

anmonteiro19:09:22

@juhoteperi have you made progress with the upgrade to the new GCC?

juhoteperi19:09:48

Haven't had time to look at this for some time, looking now

anmonteiro19:09:50

cool, have fun!

juhoteperi20:09:56

Phew, finally some progress

juhoteperi20:09:29

Looks like the root Node used to call toSource is called with the original (?) node instead of the node in transpiled AST

juhoteperi20:09:48

calling toSource version of closure compiler without node param returns the processed code

juhoteperi20:09:57

but it returns the code for all nodes (e.g. all different files)

juhoteperi21:09:46

Looks like I got the correct processed source written to disk now

juhoteperi21:09:53

for some reason the Closure module information is not yet read from the processed file

juhoteperi21:09:29

Oh, it's because js-deps/load-library is memoized globally

juhoteperi21:09:10

Probably works normally, but when testing from repl it remembers the old broken file

juhoteperi21:09:00

quite hacky still, as convert-js-module is called for each ijs, instead of once per module-type

domkm21:09:35

Why doesn't transit-cljs extend its types to be IComparable? The issue I'm running into is that DataScript is attempting to compare a bigints and is blowing up. (I didn't see a Transit channel so forgive me if this isn't an appropriate topic.)

dnolen21:09:12

@domkm no particular reason though it seems to me you can fix one yourself, the right place to bring this up is the GitHub transit-cljs repo

domkm21:09:13

Okay, thanks @dnolen. I was mistakenly under the impression that those were read-only repos. I'll open an issue.

juhoteperi22:09:09

Contains still several FIXME notes which need to be addressed

juhoteperi22:09:51

I tried to load React npm package and got 250 lines of ERROR: JSC_COMMONJS_MODULE_LOAD_ERROR. Failed to load module "react/lib/ReactTransitionGroup" at cljsjs.npm/react-addons-transition-group/index.js line 1 : 17 and 250 of WARNING: JSC_BAD_JSDOC_ANNOTATION. Parse error. illegal use of unknown JSDoc tag "providesModule"; ignoring it at cljsjs.npm/react/lib/AutoFocusUtils.js line 9 : 3

juhoteperi22:09:20

But old Closure compiler just threw NPE so this is lot more promising :slightly_smiling_face:

dnolen22:09:20

right I think you can suppress those warnings too