Fork me on GitHub
Slack Archive

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

2020-05-14

Channels

#cljs-dev
<
2020-05-14
>
dnolen16:05:38

small thing but -c -r now feeds the compiler state to the repl

bhauman16:05:17

@dnolen there is another less critical but persistent error I’m seeing, and that is xhrio/send always throws a missing var warning from the compiler in situations that it never has before.

bhauman16:05:53

well not situations, on initial compile

dnolen16:05:16

we resolve type hints - but given all the inference going on the compiler we were too agressive

dnolen16:05:33

since there are many things we can't know about even if the type might be "known"

bhauman16:05:53

sounds right

dnolen16:05:20

so maybe you found a case this somehow misses, I could repro locally after that change

bhauman16:05:23

and send is on the XhrIo Object not the protocol

dnolen16:05:44

xhrio/send right the REPL probably doesn't use that

dnolen16:05:40

@bhauman maybe make a little minimal thing?

dnolen16:05:46

it shouldn't be too hard

bhauman16:05:39

oh for now I’m just using js interop

bhauman16:05:45

to get around the warning

bhauman16:05:05

to not confuse folks

dnolen16:05:19

like what is the minimal repro?

bhauman16:05:33

oh I getcha

dnolen16:05:35

(:require [goog.XhrIo :as xhrio])

dnolen16:05:43

(xhrio/send ...)

bhauman16:05:35

yeah next time I’ll minimal it 😉

bhauman16:05:51

I’m rusty

dnolen17:05:05

I'm pondering a bit to making the standard browser REPL a bit more useful, so that people (beginners really) don't immediately feel the need to make a jump to something else - you had some thoughts here @bhauman - I'm wondering if it's really anything more than basic hot loading - no whistles - & some better strategy for for mime-types / encoding

dnolen17:05:43

not interested in encroaching on all the other great tools, rather if somebody starts with brower REPL they could hack on something cool for a while and not worry about other decisions

bhauman17:05:10

yeah sounds good, if you want to brainstorm a bit I’m happy to participate

bhauman17:05:40

it would take me a minute to get back into that mindset

dnolen17:05:57

@bhauman ok no rush, just throwing it out there

dnolen17:05:34

I got hot-loading working in Krell (sans macros) and it was a pretty small effort, and given that hot-reloading is so ubiquitous

dnolen17:05:50

it's not really an special feature to support anymore

bhauman17:05:00

if I remember correctly the REPL connection failed after 20 or 30 evals

dnolen17:05:27

@bhauman hrm that probably old days?

bhauman17:05:32

so I did have some thoughts about supporting hot reloading in a general way

dnolen17:05:47

I spent a lot of time working on the REPL connection, so I don't recall seeing anything like that

dnolen17:05:09

but it's true that one thing that's missing is reconnect if something goes wrong

dnolen17:05:20

i.e. close the browser, reopen etc.

dnolen17:05:50

which address any failures too if they still exist

bhauman17:05:51

I did have some thoughts about supporting reload in a more general way in the compiler

bhauman17:05:13

in a pretty simple way

bhauman17:05:40

If the compiler could output a changes.edn file

dnolen17:05:40

not particularly interested in putting it into the compiler since that doesn't seem necessary

dnolen17:05:04

unless you have some advantages you can enumerate

dnolen17:05:19

ClojureScript now has a pretty fancy module graph thing

dnolen17:05:24

it was needed for code splitting

dnolen17:05:40

you can trivially take a namespace and compute all if it's deps from anywhere

dnolen17:05:45

direct or full

bhauman17:05:08

from the client?

dnolen17:05:50

I mean it could be .cljc

dnolen17:05:58

the graph stuff doesn't know anything about files or anything else

bhauman17:05:14

if the compiler emitted the changes in a file, creating a client that does reloads would be trivial

bhauman17:05:36

it could literally just poll the file

bhauman17:05:43

no push, no websockets

bhauman17:05:20

and anyone could write a simple client

dnolen17:05:55

hrm right, I see - simplify REPL implementations they just serve files

bhauman17:05:44

yes you could do that for the repl as well

bhauman17:05:11

now its nice to have push for performance, but we definitely suffer from the complexity

dnolen17:05:05

this changes file - how does the client know they don't already have it?

bhauman17:05:31

timestamp in the file

dnolen17:05:55

seems to implies local storage at least on the client?

bhauman17:05:27

there is state on the client anyway

dnolen17:05:47

oh I guess the assumption here is that client starts at time T

dnolen17:05:54

only during the REPL session do you care

dnolen17:05:14

i.e. reloads etc don't matter because T gets reset

bhauman17:05:14

yep you don’t want to eval twice

bhauman17:05:22

changes file could have the files to be reloaded in the proper order

dnolen17:05:39

I agree that this is trivial since you can aggregate this in compile-file for the case where we actually do work

bhauman17:05:23

I’ve been sitting on this idea for like 3 years 🙂

dnolen17:05:25

make a ticket - it seems harmless to try it and put it behind a flag for people to experiment w/

dnolen17:05:35

patch would be welcome too

bhauman17:05:43

we could also provide other helpful information for tooling as well, but I’d have to think it through

dnolen17:05:25

sure, but for now just a vector of namespaces/paths that changed would be enough

dnolen17:05:47

would be great to try this first w/ browser REPL

dnolen17:05:56

since I really didn't want to build a file watcher or find one

dnolen17:05:07

so it's aligned w/ what I'm pondering too

💯 12
Alex Miller (Clojure team)17:05:40

just fyi, the JDK has a file watcher in it now

😮 4
dnolen18:05:21

yeah we already use the JDK watcher for watched builds - it's not that good

dnolen18:05:37

with Krell I ended going w/ directory-watcher which is faster on OS X

dnolen18:05:48

but for browser REPL I'm w/ Bruce, I don't think we need all that machinery