Fork me on GitHub
#cljs-dev
<
2017-02-27
>
dnolen14:02:41

@shaun-mahood did you try the patch? If you did please say so on the ticket - this is how we know we should proceed - thanks

dnolen14:02:02

@rmuslimov ah got it thanks for the clarification

shaun-mahood15:02:05

@dnolen: Exactly what I was wondering, thanks! I'll give it a try today.

dnolen15:02:32

@shaun-mahood is your CA submitted?

dnolen15:02:48

ah I see it is

shaun-mahood15:02:42

I was overly ambitious when I started learning Clojure :)

anmonteiro16:02:24

FWIW I think the async issue has been acknowledged as a Closure Compiler bug https://github.com/google/closure-compiler/issues/2336

shaun-mahood17:02:05

Following the “building the compiler” guide on the wiki and trying to build a version of CLJS that can be used in the same manner as the CLJS quickstart, there’s nowhere that tells you that you need to build an uberjar to use it that way. I couldn’t find anything on http://clojurescript.org for like this, would it be better for me to update the wiki with a bit more info or is there another location that is more current? I would also be happy to try moving the developer of the wiki to http://clojurescript.org if that’s a goal.

dnolen18:02:49

hrm I think developer centric stuff may make sense to keep on the GitHub repro

shaun-mahood18:02:56

Sounds good, I’ll add a bit there then.

anmonteiro21:02:55

@dnolen is there a reason why ”arguments” is not listed as reserved in cljs.core but is in cljs.analyzer? https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs#L10561

anmonteiro21:02:00

or just an overlook?

dnolen21:02:37

probably just an oversight

anmonteiro21:02:57

OK to include it in this patch where I add await? http://dev.clojure.org/jira/browse/CLJS-1956

anmonteiro22:02:44

updated CLJS-1956 with a new patch adding arguments and constructor to cljs.core/js-reserved in addition to await to be in parity with what the analyzer has

mhuebert22:02:52

@dnolen I played around with the js/dirname issue in nodejs today. discovered by accident that it is defined when the main-cli-fn is executed:

(ns dirname.core
  (:require [cljs.nodejs :as node]))

(node/enable-util-print!)

(println "This will be nil:" js/__dirname)

(defn init []
  (println "This is the accurate dirname:" js/__dirname))

(set! *main-cli-fn* init)

dnolen22:02:24

@mhuebert right that’s what I was saying

dnolen22:02:33

it’ll be set when the file loads, but lost afterwards

mhuebert22:02:23

ok. I didn’t realize that meant it would not be set while the file is loading

mhuebert22:02:34

only when the init fn is called

dnolen22:02:08

I just made this - should be simple enough

dnolen22:02:14

I can’t see a case where this isn’t satisfactory

anmonteiro22:02:28

@dnolen @mhuebert FWIW, there might be a slightly better way to set __dirname and __filename though I don’t know if it’s applicable in this case: https://github.com/anmonteiro/lumo/blob/master/src/js/cljs.js#L20-L31

thheller22:02:39

uhm no one reacted last time I posted this but I recently rewrote the node.js support in shadow-build

thheller22:02:46

not saying that you should be using that

anmonteiro22:02:59

I had some headaches with Lumo and the approach I pasted solved it

mhuebert22:02:02

ok. i was having trouble with relative nodejs/require statements

thheller22:02:22

left a little note to myself to see how those __filename and __dirname actually come into existence in node

thheller22:02:35

so your code is basically wrapped in the code above

anmonteiro22:02:34

that’s actually how Node.js sets up __dirname and __filename 🙂

mhuebert22:02:37

@thheller oh that’s cool

thheller22:02:40

no they don't?

thheller22:02:48

NativeModule.wrapper = [
  '(function (exports, require, module, __filename, __dirname) { ',
  '\n});'
];
this is

thheller22:02:14

the link you posted is for eval

thheller22:02:16

not require

anmonteiro22:02:19

depends on what you’re evaluating

anmonteiro22:02:57

right, what I posted is for evaluating a script

mhuebert22:02:01

@anmonteiro thanks for that as well

anmonteiro22:02:16

I didn’t see the require constraint above

mhuebert22:02:23

I unfortunately have to sign off now but will be looking into this again tomorrow

anmonteiro22:02:48

feel free to ping me, I have gone through the way Node.js bootstraps itself a few times by now

thheller22:02:57

I wanted to know where __filename actually came from

anmonteiro22:02:21

__dirname is actually derived from __filename, that’s what I gathered

anmonteiro22:02:34

with path.dirname

thheller22:02:54

nah I meant technically, because it was never on global or anything

thheller22:02:07

but I only tested require never eval

anmonteiro22:02:07

yeah, it’s local to the module

thheller22:02:39

but its actually pretty straightforward

thheller22:02:24

also how node achieves isolation of modules so they don't interfere with each other

thheller22:02:40

as mhuebert pointed out .. if you put __filename on global and remove it afterwards, it is gone if you reach the point where you call a function

thheller22:02:54

not that you should ever be using that really

dnolen22:02:02

@thheller didn’t have time to look at that before - it does look interesting

dnolen22:02:22

but also just automatically treating those as constants seems fine

mhuebert23:02:40

@dnolen: that ticket looks good to me, should make for predictable use of relative nodejs/require expressions which is all I am using this for.

anmonteiro23:02:47

^ looks like they’re not very amenable to fixing the regression, hrm

bronsa10:02:34

anmonteiro: or start munging local names?