Hot reload

[waralex]

Proposed in this PR:

• Hot reloading support
• Defining the application path by the path to the executable file
• The name argument in dash() has been deleted

Dash for Python's "hot-reloading" feature is described in plotly/dash#66, plotly/dash#362, and plotly/dash-renderer#73.

Supporting this as in the Python and R implementations would require

• creating a hash at app initialization, and regenerating it on file change
• adding a route to serve the hash
• front-end hot reloading (including ability to refresh layout only when CSS updates occur, as well as formatting the JSON response with a modified file manifest)
• back-end hot reloading (reload the app, restart HTTP.jl)
• adding parameters for the dev tools UI: dev_tools_hot_reload, dev_tools_hot_reload_interval, dev_tools_hot_reload_watch_interval, dev_tools_silence_routes_logging
• integration test for "hard" (restart backend app, reload frontend) reloading
• integration test for "soft" (CSS only = layout refresh) reloading

On the Python side, we use the Flask debug reloader to reset the hash. We would need to find a comparable approach using HTTP.jl instead.

[rpkyle]

@waralex I also wanted to mention that we seem to handle interrupts within the REPL a little differently (or Julia does) than those sent while a process is invoked from the CLI:

rpkyle$ julia test.jl [ Info: Running on http://127.0.0.1:8050^C
signal (2): Interrupt:2
in expression starting at /private/tmp/testapp/test.jl:27
fatal: error thrown and no exception handler available.
InterruptException()
kevent at /usr/lib/system/libsystem_kernel.dylib (unknown line)
unknown function (ip:0x0)
Allocations:18621645 (Pool:18617092; Big:4553); GC:18
jl_mutex_unlock at /Users/julia/buildbot/worker/package_macos64/build/src/./locks.h:143 [inlined]
jl_task_get_next at /Users/julia/buildbot/worker/package_macos64/build/src/partr.c:451
signal (15): Terminated:15
in expression starting at /private/tmp/testapp/test.jl:27

I'm not sure why this interrupt isn't caught by the exception handler you've already written, but it would be good to provide our own custom message (like HTTP.jl stopped at http://127.0.0.1:8050) rather than this scary looking error. 🙂

[rpkyle]

@waralex I'm not sure if it's related to the revised reloading approach, but I'm seeing an intermittent error related to Servers.jl on page load. We aren't handling the exception right now, so the error dump that appears (IOError: stream is closed or unusable) is pretty gnarly:

rpkyle$ julia test_reload.jl [ Info: Running on http://127.0.0.1:8050
┌ Error: error handling request
│ exception =
│ IOError: stream is closed or unusable
│ Stacktrace:
│ [1] check_open at ./stream.jl:328 [inlined]
│ [2] uv_write_async(::Sockets.TCPSocket, ::Ptr{UInt8}, ::UInt64) at ./stream.jl:961
│ [3] uv_write(::Sockets.TCPSocket, ::Ptr{UInt8}, ::UInt64) at ./stream.jl:924
│ [4] unsafe_write(::Sockets.TCPSocket, ::Ptr{UInt8}, ::UInt64) at ./stream.jl:1007
│ [5] unsafe_write at /Users/rpkyle/.julia/packages/HTTP/GkPBm/src/ConnectionPool.jl:174 [inlined]
│ [6] unsafe_write at ./io.jl:593 [inlined]
│ [7] write at ./io.jl:616 [inlined]
│ [8] startwrite(::HTTP.Streams.Stream{HTTP.Messages.Request,HTTP.ConnectionPool.Transaction{Sockets.TCPSocket}}) at /Users/rpkyle/.julia/packages/HTTP/GkPBm/src/Streams.jl:87
│ [9] handle(::HTTP.Handlers.RequestHandlerFunction{Dash.var"#52#53"{Array{String,1},Int64,HTTP.Handlers.RequestHandlerFunction{Dash.var"#49#50"{Dash.Router,Dash.HandlerState}}}}, ::HTTP.Streams.Stream{HTTP.Messages.Request,HTTP.ConnectionPool.Transaction{Sockets.TCPSocket}}) at /Users/rpkyle/.julia/packages/HTTP/GkPBm/src/Handlers.jl:278
│ [10] #4 at /Users/rpkyle/.julia/packages/HTTP/GkPBm/src/Handlers.jl:345 [inlined]
│ [11] macro expansion at /Users/rpkyle/.julia/packages/HTTP/GkPBm/src/Servers.jl:367 [inlined]
│ [12] (::HTTP.Servers.var"#13#14"{HTTP.Handlers.var"#4#5"{HTTP.Handlers.RequestHandlerFunction{Dash.var"#52#53"{Array{String,1},Int64,HTTP.Handlers.RequestHandlerFunction{Dash.var"#49#50"{Dash.Router,Dash.HandlerState}}}}},HTTP.ConnectionPool.Transaction{Sockets.TCPSocket},HTTP.Streams.Stream{HTTP.Messages.Request,HTTP.ConnectionPool.Transaction{Sockets.TCPSocket}}})() at ./task.jl:358
└ @ HTTP.Servers ~/.julia/packages/HTTP/GkPBm/src/Servers.jl:373

[waralex]

@rpkyle

[ Info: Running on http://127.0.0.1:8050
┌ Error: error handling request
│ exception =

Apparently, this should be solved in the future PR with logging and exception handling. The error itself most likely occurs when the client close the connection before receiving a response from the server

[waralex]

@rpkyle

I'm not sure why this interrupt isn't caught by the exception handler you've already written, but it would be good to provide our own custom message (like HTTP.jl stopped at http://127.0.0.1:8050) rather than this scary looking error.

I have refused to use ccall(:jl_exit_on_sigint, Cvoid, (Cint,), 0) yet because it is not documented and its behavior is very strange and not very clear to me. So, unfortunately, I will not be able to display custom exit message yet. Julia will just immediately kill the process on the sigint signal.

[rpkyle]

@waralex Great, I think this is OK to merge into dev, pending two minor comments:

• we currently have an @warn message for hot reloading on L139 of src/Dash.jl, but an error with a similar message on L6 of src/utils/hot_restart.jl. Is this OK? We could exit the hot_restart.jl function after throwing a @warn there, it doesn't have to be an error to interrupt function execution since it's wrapped in if ...end, we can back out within that statement if we wish.
• this feature needs a CHANGELOG.md entry, as do all new features 🙂 I'll commit the current CHANGELOG.md revision from dev to this branch, so you can do that.

Otherwise, when done, I'd say 💃 . LGTM!

[rpkyle]

Suggested change

	error("hot restart is disabled for intereactive sessions")
	error("hot restart is disabled for interactive sessions")

[waralex]

we currently have an @warn message for hot reloading on L139 of src/Dash.jl, but an error with a similar message on L6 of src/utils/hot_restart.jl. Is this OK? We could exit the hot_restart.jl function after throwing a @warn there, it doesn't have to be an error to interrupt function execution since it's wrapped in if ...end, we can back out within that statement if we wish.

The difference is that in src/Dest.jl we show the warning and execute the if / else branch that doesn't use the hot_restart function
An error in hot_restart is a protection against misuse of this function. If this function is called from REPL, there is no way to continue execution of the program normally, so we throw an exception

[waralex]

this feature needs a CHANGELOG.md entry, as do all new features 🙂 I'll commit the current CHANGELOG.md revision from dev to this branch, so you can do that.

done in 921e3e4

[rpkyle]

Labeler failure is likely related to ongoing GitHub issues this afternoon, so will merge as soon as CI test passes; no failures upon disabling Labeler.