Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HandlerFunction not defined #24

Open
gavin-kelly-1 opened this issue Mar 5, 2019 · 5 comments
Open

HandlerFunction not defined #24

gavin-kelly-1 opened this issue Mar 5, 2019 · 5 comments

Comments

@gavin-kelly-1
Copy link

HTTP.register!(router[],method,route,HTTP.HandlerFunction(handler))

This is probably a failure in my setup, but I'm failing to get Pages.start() to work (in julia 1.0.3) when I'm bundling it up in a fresh container.

using Pages;
Pages.start();

gives UndefVarError: HandlerFunction not defined

relevant lines of pkg status are
[cd3eb016] + HTTP v0.8.0
[7c165e09] + Pages v0.2.2

Any help gratefully received - many thanks.

@EricForgy
Copy link
Owner

EricForgy commented Mar 5, 2019

Hi @macroscian 👋

Good timing. It's been a while since I looked at this, but coincidentally, I was just updating some stuff.

Yeah. The issue is that HTTP v0.8 was quite a change from v0.7. I'll try to push something to master soon and see if that helps you 🙏

Edit: Pushed 😊

@EricForgy
Copy link
Owner

EricForgy commented Mar 5, 2019

The version I just pushed to master is a bit of change too 😅🙏

One thing I liked about this package was the ability to change routes on the fly even when the server is running. When I switched to using HTTP.Router (mostly because it has support for variable / parametric routes, I lost that ability.

Now, I am moving back to my original router, which, for the time being, means variable / parametric routes will not work. Were you relying on that?

I'd like to add parametric routes back at some point. If you need them, I could make it a priority.

@EricForgy
Copy link
Owner

I haven't updated the docs yet, but there are no Get or Post methods anymore.

If you want a POST, it is now like this:

Endpoint("/post/endpoint",POST) do request::HTTP.Request
    # process the `POST`
end

The default method is GET, so if you just want a normal GET method, it is still:

Endpoint("/get/endpoint") do request::HTTP.Request
    # process the `GET`
end

Please let me know if you have any problems.

I want to tag a version, but I still need to test the WebSocket stuff. The way I like to test WebSockets is with PlotlyJS, but PlotlyJS has a dependency on WebSockets.jl and WebSockets.jl doesn't work for HTTP v0.8, so I'm currently trying to fix THAT so I can test my websocket stuff 😅

@gavin-kelly-1
Copy link
Author

That's brilliant as ever, thanks Eric. Serving the files now works great, but I did notice something odd about websockets. I've put the Julia error log below - it tracks back to a loop in julia that updates a javascript progress bar thus:
Pages.message("/uv_damage", client_id, "script", "progress(\"$scen\",\"$i\")")
It runs fine for a while, and then the browser reports an ERR_EMPTY_RESPONSE, though I don't think I'm sending an empty response, as the scen and i variables are always set. I'll double check it's not something stupid I've done, and temporarily remove the progress bar to check things run through without it.

Personally, I don't use parametric routing, so don't prioritise it (or anything else!) on my behalf. -Thx.

Error: error handling request
│ exception =
│ ArgumentError: stream is closed or unusable
│ Stacktrace:
│ [1] check_open at ./stream.jl:256 [inlined]
│ [2] uv_write_async(::Sockets.TCPSocket, ::Ptr{UInt8}, ::UInt64) at ./stream.jl:804
│ [3] uv_write(::Sockets.TCPSocket, ::Ptr{UInt8}, ::UInt64) at ./stream.jl:778
│ [4] unsafe_write(::Sockets.TCPSocket, ::Ptr{UInt8}, ::UInt64) at ./stream.jl:834
│ [5] unsafe_write at /root/.julia/packages/HTTP/GN0Te/src/ConnectionPool.jl:132 [inlined]
│ [6] unsafe_write at ./io.jl:509 [inlined]
│ [7] macro expansion at ./gcutils.jl:87 [inlined]
│ [8] write at ./io.jl:532 [inlined]
│ [9] wswrite(::HTTP.WebSockets.WebSocket{HTTP.ConnectionPool.Transaction{Sockets.TCPSocket}}, ::UInt8, ::Array{UInt8,1}) at /root/.julia/packages/HTTP/GN0Te/src/WebSockets.jl:201
│ [10] wswrite at /root/.julia/packages/HTTP/GN0Te/src/WebSockets.jl:183 [inlined]
│ [11] unsafe_write at /root/.julia/packages/HTTP/GN0Te/src/WebSockets.jl:153 [inlined]
│ [12] macro expansion at ./gcutils.jl:87 [inlined]
│ [13] write(::HTTP.WebSockets.WebSocket{HTTP.ConnectionPool.Transaction{Sockets.TCPSocket}}, ::String) at ./strings/io.jl:164
│ [14] message(::String, ::Dict{String,String}) at /root/.julia/packages/Pages/cPMFY/src/api.jl:47
│ [15] message(::String, ::String, ::String, ::String) at /root/.julia/packages/Pages/cPMFY/src/api.jl:51
│ [16] #main#51(::String, ::Function, ::Array{Dict{String,Any},1}, ::Array{Dict{String,Any},1}, ::Dict{String,Any}) at /root/.julia/packages/uv_damage/dY97m/src/uv_damage.jl:150

@EricForgy
Copy link
Owner

EricForgy commented Mar 5, 2019

Oh man! Was afraid there could be some problems with websockets. I'm squashing 10s of issues on WebSockets.jl trying to upgrade it to HTTP v0.8 and then I'll be able to dig in and try to see what is going on.

Your issues sounds like it might be HTTP related. You might check to see if there is a relevant outstanding issue there until I can have a look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants