@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

@rmuslimov ah got it thanks for the clarification

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

@shaun-mahood is your CA submitted?

ah I see it is

I was overly ambitious when I started learning Clojure :)

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

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.

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

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

@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

or just an overlook?

probably just an oversight

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

go for it

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

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

@mhuebert right that’s what I was saying

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

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

only when the init fn is called

@mhuebert http://dev.clojure.org/jira/browse/CLJS-1959

I just made this - should be simple enough

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

@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

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

not saying that you should be using that

https://github.com/thheller/shadow-build/blob/master/doc/node.md#nodejs-platform-internals

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

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

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

so your code is basically wrapped in the code above

yeah

@thheller stole it from https://github.com/nodejs/node/blob/master/lib/internal/bootstrap_node.js#L374

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

@thheller oh that’s cool

no they don't?

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

the link you posted is for eval

not require

depends on what you’re evaluating

right, what I posted is for evaluating a script

@anmonteiro thanks for that as well

I didn’t see the require constraint above

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

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

I wanted to know where __filename actually came from

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

with path.dirname

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

oh right

but I only tested require never eval

yeah, it’s local to the module

(or script)

but its actually pretty straightforward

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

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

not that you should ever be using that really

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

but also just automatically treating those as constants seems fine

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

https://github.com/google/closure-compiler/issues/2336#issuecomment-282894620

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

the alternative would be just changing the name of this variable https://github.com/clojure/core.async/blob/master/src/main/clojure/cljs/core/async.cljs#L270