Clojurians
#cljs-dev
<
2018-01-24
>

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

athos10:01:28

Hi, I saw cljs.core.specs.alpha ns being added in the repo, but that doesn't seem to be included in the latest released CLJS jar. Is it intended?

thheller10:01:19

@athos there has not been a release that includes this yet

athos10:01:53

Haha, right:sweat_smile: I thought 1.9.946 was released after that.

rauh12:01:45

Should CLJS accept more values for compare? The JS standard says that if an object has a valueOf function it needs to return a primitive value. So as long as the types are the same and they both have a valueOf fn they can be passed to garr/defaultCompare. Probably not an issue for many, this just came up in Datascript which is used by some JS folks... (which uses compare a lot)

dnolen14:01:46

@rauh sure file a ticket

richiardiandrea16:01:53

I have run across David's post about combining JS generators and channels and found it fascinating (thanks!) especially in lumo where andare takes a while to compile. I was wondering if there is a way for ClojureScript to emit generator functions (or objects) - the GCC should support compiling them down. Sorry if it's an old question :smiley:

richiardiandrea17:01:20

no I can't apparently

thheller17:01:58

CLJS emits ES3 so there is no official way to use ES7 features

richiardiandrea17:01:28

@thheller GCC accepts ES6 in input though (aren't generators ES6?)

thheller17:01:46

besides that the go macro does pretty much the same thing the closure compiler does to generator funcs

richiardiandrea17:01:11

I know, but as I wrote above, andare is pretty slow to compile because of all the macros

richiardiandrea17:01:26

so for me there is value in using an alternative

thheller17:01:42

pretty sure andare still is faster than using CLJS+Closure to optimize?

richiardiandrea17:01:00

not sure I understand the last sentence :smile:

thheller17:01:12

but why is compile time the issue? runtime should be all that matters no?

richiardiandrea17:01:34

No well, I am producing JS, in a self-host like lumo

richiardiandrea17:01:50

I compile down and macros are slow to compile

richiardiandrea17:01:58

you can cache of course

richiardiandrea17:01:35

still, directly use JS libraries like js.csp would be waaay faster

thheller17:01:02

what are you building where compile time is the main problem?

richiardiandrea17:01:07

I in "exploratory" mode, if compile time can be reduced and I can obtain the same behaviors, that's a win

richiardiandrea17:01:15

if not, I will go back using andare

richiardiandrea17:01:38

also, in JS-centric work-places they don't like compile time :smile:

thheller17:01:16

I played with a few JS tools the last few days and I can say that CLJS compiler is just as fast as many JS tools or even faster

thheller17:01:52

webpack in particular is slow compared to CLJS … IF you properly deal with startup time

richiardiandrea17:01:28

right, we use node server side so no webpack

thheller17:01:45

I don’t buy the speed argument anymore :stuck_out_tongue:

richiardiandrea17:01:14

note that "compile time" is also valid in the REPL in lumo because of its self-hosted nature

thheller17:01:48

well yeah self-hosted is slower but it should work fine in lumo with proper caching no?

richiardiandrea17:01:03

yep, as I said, just exploring...On another note, and not directed to you Thomas in particular I don't like to answer questions without motivation. If a colleague asks me "Can we use generators in ClojureScript", I try to find a reason...technical maybe...and I don't like to just say, no you can't, go use andare :smile:

richiardiandrea17:01:39

I need to politically handle things like language adoption here

richiardiandrea17:01:49

that's also part of the issue maybe :wink:

thheller17:01:04

ok, that argument I can understand but just dismissing what CLJS provides based on compile time seems counter productive

richiardiandrea17:01:41

agree with you, and probably I should have added both motivations in there...anyways not a big deal, I will answer "go use andare" anyways :smile:

thheller17:01:22

the issue with generators is that CLJS sometimes generates extra functions to isolate scope and such

thheller17:01:57

that breaks with generator functions if they don’t expect that

thheller17:01:25

I think doseq and for do that a lot

richiardiandrea17:01:47

uhm ok, I tried but it does not seem to be there:

cljs.user=> (new js/GeneratorFunction "test1" "test2")
GeneratorFunction is not defined
	 (evalmachine.<anonymous>:1:1)
	 ContextifyScript.Script.runInThisContext (vm.cljs:50:33)
	 Object.runInThisContext (vm.cljs:152:38)

richiardiandrea17:01:56

thanks for your explanation

thheller18:01:59

IIRC generators just return objects that have a next function, similar to lazy-seq

richiardiandrea18:01:24

yep I was reading that today

richiardiandrea18:01:15

the REPL probably does not "read" ES6, don't even know how to enable that actually

thheller18:01:22

so from an interop perspective do you want to pass an object to JS to acts like a generator

thheller18:01:29

or consume one via CLJS?

richiardiandrea18:01:08

I need to pass a GeneratorFunction to JS code called within CLJS

rauh18:01:08

@richiardiandrea Pretty sure you can just pass them an es6 iterable which we support for all collections.

richiardiandrea18:01:12

so this works:

cljs.user=> (.constructor (.getPrototypeOf js/Object (js* "function*(){}")))
Evaluating (.constructor (.getPrototypeOf js/Object (js* "function*(){}")))
Object.getPrototypeOf(function*(){}).constructor()
#object[anonymous]

rauh18:01:30

You wouldn't use their go, you'd have to use spawn, go will first invoke the fn

richiardiandrea18:01:47

yep thanks it's cool that I can do that :wink:

richiardiandrea18:01:17

probably not worth ending up in core, it is one line basically, I can live with it :wink:

thheller18:01:59

I don’t think there is anything special about GeneratorFunction other than that its a function you cannot new.