@mfikes I worked through pretty much all the cljs.main you reported

re: Nashorn bootstrap, I couldn’t get that to work, I left a comment about CLJS-2517, core.async has a branch so it’s easier to see what I’m talking about

going to stop logging the random Node.js REPL port

yeah just verified that master (1.9.1069) works for testing core.async, but fails after CLJS-2517 patch

@dnolen Thanks—I’ll try to see what is going on. I’ve seen similar core.async test issues with running the Andare tests with Planck on Linux, and I’m wondering if there is either some race, or an ordering expectation that is also not met there (perhaps they share a common root explanation).

@mfikes perhaps but more importantly I think we need to preserve the right semantic

that’s more important than an annoying icon

I’m not 100% sure, but believe that the everything happens on the JavaFX thread which is what you want

(not JavaFX)

but all JS happening on one thread

Yeah, perhaps there is something important with the way Jim Laskey set that up

you would have to setup your own UI-style single threaded event loop

Perhaps the Java Timer thread callbacks come in at any time on any thread and Jim used JavaFX to serialize them to the JS thread or somesuch

If true, yes, perhaps a mini-non-JFX event loop implementation could achieve the same

Platform.runLater does that

the Timer stuff just sets up seperate thread for timing

but the fn will run on the FX thread

Yeah, thinking about it more… there probably isn’t a bridge between Timer and Nashorn, and you end up driving Nashorn in a multithreaded way with the change I made

Yes, not desirable even if it worked

@mfikes I figured out how to suppress the icon in OS X at least - I’m not sure about Linux / Windows

Ahh cool.

@mfikes pushed to master

Nice

@dnolen (System/setProperty "java.awt.headless" "true") should be "cross-platform", though I think other platforms don't show icon in this case anyway

@juhoteperi yeah that’s what I was thinking

an OS X quirk

@mfikes we could probably do our own simple event loop, but I’m not really sure it’s worth the effort

@juhoteperi it would nice to get a confirm on Linux / Window to see if that snippet is actually required

I can also do that later today on my other machine, though I probably need to update my Linux setup

Confirmed no icon on Windows 10

@dnolen Hi David, I put together a minimal example based on the code splitting guide that demonstartes the issue I am having with the module loader. Should I add this example to JIRA as a patch and we discuss from there?

@r0man go for it, thanks!

Confirmed no icon on Ubuntu Linux 14.04 Desktop

But, perhaps https://dev.clojure.org/jira/browse/CLJS-2518 is related to the icon supression approach. Will check

@bhauman hrm I hadn’t even really thought about how this simplifies things for beginners (duh!), we could skip the build script

-b or something

your referring to (figwheel/start)?

or the figwheel-sidecar.main?

sidecar.main

we could have a standard way to run REPLs & run builds

yes!!

most people don’t want to or need to fiddle w/ build options

it’s all boilerplate

when they’re trying it out

with clj it’d be particularly slick

deps.edn and then a short command line thing

huh, but I guess technically this already works

well you are the one who suggested the main a while back 🙂

java -jar cljs.main -m my.main.ns

java -jar cljs.jar -m my.main.ns

oops thanks

so maybe we don’t need -b?

yeah so it compiles what it finds

for the simple cases

I could use the -b for sure though

@bhauman what would it do? i.e. what options would it take

I could then compose over cljs.main much easier

I would have to think about it some more

to clarify a bit what I did

with -m I just use all the defaults, REPL chooses :output-dir

however if you ran a build, compiler now dumps cljsc_opts EDN into the :output-dir

then if you pass -o we’ll read that out so we can use the original build options

(to prevent cache invalidation etc.)

it seemed good enough for what I was trying to solve - not sure if there are better more useful ideas here

trying to pass all compiler options via flags seemed sub-optimal

yeah, but it would be good to have the option, I'm thinking for tooling and running tests

yeah maybe write up what you’re thinking? I hadn’t looked much further than replicating clojure.main options

I keep thinking that build-ids are a good thing and that a top level dev.cljsc_opts is a good idea

Yeah, Lumo and Planck have a lot of compiler options flags, and it gets tedious. But, conversely, it makes it very easy, to, say, enable an option.

and the -b option takes a build-id

@bhauman if all you’re looking for is way to reuse cljs.cli cljs.main then just drop some ideas

happy to make that reusable a la cljs.repl

could make the dispatch stuff open?

I will have to spend some time with it. I was just looking for some wisdom, as I just recently started thinking about this.

I will comeback when I have thought about it more

k

@dnolen I added a ticket for the problem with the module loader here: https://dev.clojure.org/jira/browse/CLJS-2519 The patch contains an example project based on the code splitting guide.

The doc string of the set-loaded fn of the module loader mentions this:

"Note that calls to this function will be automatically generated as the final expression for known :modules entry points that require the cljs.loader namespace."

Is this still true?

@r0man not true if you write code that expects that it won’t work

ok, I'm using set-loaded myself, as described in the guide

I’ll fix the docstring now

was just wondering and didn't find anything that emits set-loaded calls

docstring fixed in master

thanks for catching that

cool

@r0man so I don’t understand your report

it’s not possible that :cljs-base is not fully loaded

the page must include the base script

you should include what markup you are using in your report

the page includes cljs_base.js, but for some reason the shared namespace isn't loaded

ok, I'll add the markup

even though not all files in :cljs-base have been loaded and evaluated yet

maybe change your report to remove the speculation so I’m not looking for the wrong things 🙂

or clarify what you mean?

What I'm observing is that even though the shared namespace "code.split.d" is assigned to :cljs-base it is undefined on page load.

@r0man under none there should be a require for every entry in base

what are the contents of out/cljs_base.js?

might be large so probably wanna paste

cljs_base.js is small

the entry which is not loaded from :clj-base is required in my modules B and C. just not in A.

@r0man yes but the important thing is that your cljs_base.js is wrong 🙂

what's wrong with it?

every file in base should be in there

explicitly goog.required

so somehow you’re getting the wrong base file

I notice your passing :modules to REPL ctor and you’re using :watch

maybe they do or don’t matter, but I would not consider it minimal

I would remove all that stuff from your patch before I look at it

@r0man https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1615-L1622

if you don’t see tens and tens of requires something went wrong

it absolutely needs to work this way because of orphans

things that belong in your build that you never require

I’m pretty sure you reported that problem 🙂

ok, so at the point :cljs-base is marked as loaded all those files should be loaded and evaluated. they areN#t loaded later somehow with the module managers batch loader?

@r0man what I’m saying is

cljs_base.js ensures that under :none

you don’t have to do anything

if every single entry isn’t required there, then it won’t work

@r0man try the guide and look at the contents and compare

Hmm, I think I'm requiring the namespaces correctly. I'll remove the :watch and the :modules from the repl constructor.

@r0man not suggesting you’re doing anything wrong

I’m just saying that the fact the base JS file is bad will probably lead us to the problem

yes, I'm digging into this at the moment ..

Hrm with -w for watch and and a flag for for optimization level we could replace all the custom scripts in the Quick Start I think?

I have this working now java -cp cljs.jar:src cljs.main -js node -v -o out/main.js -c foo.core

can add -w src for autobuilding

and -l advanced for advanced compilation

Maybe -O ? 😄