Fork me on GitHub
#cljs-dev
<
2018-02-13
>
dnolen02:02:17

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

dnolen02:02:55

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

dnolen02:02:12

going to stop logging the random Node.js REPL port

dnolen02:02:38

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

mfikes12:02:33

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

dnolen12:02:32

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

dnolen12:02:53

that’s more important than an annoying icon

dnolen12:02:18

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

dnolen12:02:37

(not JavaFX)

dnolen12:02:46

but all JS happening on one thread

mfikes12:02:00

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

dnolen12:02:08

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

mfikes12:02:00

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

mfikes12:02:51

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

dnolen12:02:25

Platform.runLater does that

dnolen12:02:44

the Timer stuff just sets up seperate thread for timing

dnolen12:02:00

but the fn will run on the FX thread

mfikes12:02:06

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

dnolen12:02:22

Yes, not desirable even if it worked

dnolen13:02:54

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

dnolen13:02:40

@mfikes pushed to master

juhoteperi13:02:34

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

dnolen13:02:50

@juhoteperi yeah that’s what I was thinking

dnolen13:02:02

an OS X quirk

dnolen13:02:21

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

dnolen13:02:03

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

dnolen13:02:01

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

mfikes14:02:52

Confirmed no icon on Windows 10

r0man14:02:09

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

dnolen14:02:27

@r0man go for it, thanks!

mfikes14:02:56

Confirmed no icon on Ubuntu Linux 14.04 Desktop

mfikes14:02:07

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

dnolen14:02:18

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

dnolen14:02:44

-b or something

bhauman14:02:39

your referring to (figwheel/start)?

bhauman14:02:56

or the figwheel-sidecar.main?

dnolen14:02:07

sidecar.main

dnolen14:02:25

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

dnolen14:02:38

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

dnolen14:02:40

it’s all boilerplate

dnolen14:02:48

when they’re trying it out

dnolen14:02:10

with clj it’d be particularly slick

dnolen14:02:21

deps.edn and then a short command line thing

dnolen14:02:32

huh, but I guess technically this already works

bhauman14:02:36

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

dnolen14:02:49

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

mfikes14:02:21

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

dnolen14:02:29

oops thanks

dnolen14:02:35

so maybe we don’t need -b?

bhauman14:02:40

yeah so it compiles what it finds

dnolen14:02:41

for the simple cases

bhauman14:02:03

I could use the -b for sure though

dnolen14:02:21

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

bhauman14:02:21

I could then compose over cljs.main much easier

bhauman14:02:14

I would have to think about it some more

dnolen14:02:33

to clarify a bit what I did

dnolen14:02:59

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

dnolen15:02:25

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

dnolen15:02:43

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

dnolen15:02:06

(to prevent cache invalidation etc.)

dnolen15:02:29

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

dnolen15:02:40

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

bhauman15:02:47

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

dnolen15:02:53

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

bhauman15:02:54

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

mfikes15:02:14

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.

bhauman15:02:41

and the -b option takes a build-id

dnolen15:02:25

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

dnolen15:02:34

happy to make that reusable a la cljs.repl

dnolen15:02:04

could make the dispatch stuff open?

bhauman15:02:04

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

bhauman15:02:17

I will comeback when I have thought about it more

r0man16:02:59

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

r0man16:02:16

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

r0man16:02:25

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

r0man16:02:42

Is this still true?

dnolen16:02:30

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

r0man16:02:08

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

dnolen16:02:19

I’ll fix the docstring now

r0man16:02:35

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

dnolen16:02:27

docstring fixed in master

dnolen16:02:30

thanks for catching that

dnolen16:02:19

@r0man so I don’t understand your report

dnolen16:02:33

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

dnolen16:02:13

the page must include the base script

dnolen16:02:50

you should include what markup you are using in your report

r0man16:02:12

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

r0man16:02:33

ok, I'll add the markup

dnolen16:02:35

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

dnolen16:02:49

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

dnolen16:02:53

or clarify what you mean?

r0man16:02:39

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.

dnolen16:02:59

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

dnolen16:02:34

what are the contents of out/cljs_base.js?

dnolen16:02:42

might be large so probably wanna paste

r0man16:02:58

cljs_base.js is small

r0man16:02:02

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

dnolen16:02:33

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

r0man16:02:07

what's wrong with it?

dnolen16:02:03

every file in base should be in there

dnolen16:02:15

explicitly goog.required

dnolen16:02:40

so somehow you’re getting the wrong base file

dnolen16:02:18

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

dnolen16:02:30

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

dnolen16:02:39

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

dnolen16:02:33

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

dnolen17:02:57

it absolutely needs to work this way because of orphans

dnolen17:02:07

things that belong in your build that you never require

dnolen17:02:13

I’m pretty sure you reported that problem 🙂

r0man17:02:19

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?

dnolen17:02:33

@r0man what I’m saying is

dnolen17:02:42

cljs_base.js ensures that under :none

dnolen17:02:45

you don’t have to do anything

dnolen17:02:16

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

dnolen17:02:43

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

r0man17:02:30

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

dnolen17:02:23

@r0man not suggesting you’re doing anything wrong

dnolen17:02:41

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

r0man17:02:25

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

dnolen20:02:00

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?

dnolen23:02:37

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

dnolen23:02:53

can add -w src for autobuilding

dnolen23:02:02

and -l advanced for advanced compilation