Fork me on GitHub
#aleph
<
2017-02-01
>
eslachance03:02:26

Alright. Thankfully someone can help me out before I pull my hair out. I have this very odd issue. I'm using aleph/manifold to connect to a websocket, and s/consume doesn't seem to be triggering at all and I really don't know why. Evaluating each relevant line one at a time works from the repl, just not within a function. Here's the exact line that doesn't trigger: https://github.com/eslachance/dithcord/blob/master/src/dithcord/core.clj#L121

dm306:02:41

what's the manifold version?

eslachance08:02:47

@dm3 I just have [aleph "0.4.1"]

dm311:02:26

@eslachance what does printing the stream that you consume show?

dm311:02:45

e.g.

boot.user=> (manifold.stream/stream)
<< stream: {:pending-puts 0, :drained? false, :buffer-size 0, :permanent? false, :type "manifold", :sink? true, :closed? false, :pending-takes 0, :buffer-capacity 0, :source? true} >>

dm311:02:36

after you start consuming the stream, it should have a :pending-takes 1 and :closed? should be false

dm311:02:44

and :drained? should also be false

eslachance11:02:12

When I call that function (ws-connect) it returns the session, which has the stream as a socket

eslachance11:02:29

and printing out (:socket @session) does show that stream

dm311:02:37

ws is the stream you're consuming

eslachance11:02:54

yes which I have as (swap! session assoc :socket ws)

eslachance11:02:58

let me see about drained

dm311:02:23

what happens if you just do

(let [x @(http/websocket-client "")]
  (s/consume #(println "DEBUG" %) x))
?

eslachance11:02:57

.... nothing

eslachance11:02:04

well sorry it returns nil to be precise

dm311:02:32

which means you are not receiving anything on that URL?

eslachance11:02:34

nothing else, no message, not output.

dm311:02:42

what if you try another WS client?

eslachance11:02:58

But I am though if I do

(def conn @(http/websocket-client ""))
(s/on-closed conn (fn [] (prn "closed")))
(s/consume (fn [msg] (prn msg)) conn) 
then I do get a message

eslachance11:02:26

I get a first packet, and then I get a closed message after a second or so because the websocket is expecting an identity packet

eslachance11:02:33

which, if I provide it, does work

eslachance11:02:43

So I'm receiving packets fine when I def the connection. But when I use let it doesn't work

dm311:02:09

that doesn't affect anything

eslachance11:02:27

I was previously using http.async.client , which worked fine except for the fact that it crashes the websocket on large packets (a bug in the java lib it uses)

dm311:02:49

so you have some code using aleph that works?

eslachance11:02:01

I do. those 3 lines work

eslachance11:02:23

That's the packet

dm311:02:33

and you are saying that

(let [conn @(http/websocket-client ""))]
  (s/on-closed conn (fn [] (prn "closed")))
  (s/consume (fn [msg] (prn msg)) conn))
doesn't?

eslachance12:02:22

wait a sec. no it does.

eslachance12:02:53

but...

(let [x @(http/websocket-client "")]
  (s/consume #(println "DEBUG" %) x)) 
didn't work. IT didn't print out that packet

dm312:02:15

maybe there was no packet?

dm312:02:22

try looking with wireshark or something?

eslachance12:02:32

I don't even know what that is >.<

eslachance12:02:38

but really I know this API

eslachance12:02:45

we're talkinga bout Discord here it always sends a packet

eslachance12:02:53

consistently

dm312:02:58

the URL is wrong

eslachance12:02:34

I shall take my shame and go fix the error

dm312:02:44

happens 🙂

eslachance12:02:19

Obviously, this does bring to light that aleph doesn't have an "on-error" event cough

eslachance12:02:27

(well manifold doesn't?)

dm312:02:15

it's probably closing the stream, no?

dm312:02:48

which has no definite answer

eslachance12:02:54

True, but when a websocket closes, it has a reason to close. Getting that reason would be... useful.

eslachance12:02:11

I mean we have s/on-close why not s/on-error. I feel that's expected, and consistent.

eslachance12:02:21

And also consistent with other libraries

dm312:02:48

you can contribute to the issue above

dm312:02:58

all thoughts welcome 🙂

eslachance12:02:17

Once I get this all working I'm planning a series of video tutorials on various things clojure-related in the shape of a development story for my library

eslachance12:02:55

But that's once I get it working ^_^

eslachance12:02:10

Any way to handle a zlib compressed packet? It shows up as #object["[B" 0x7282913c "[B@7282913c"] if I just print it to console, not exactly sure how to handle that

dm312:02:30

I guess you need to decompress it yourself

eslachance12:02:02

And the java interop adventure beings....

eslachance13:02:13

Wait what about byte-streams?

eslachance13:02:55

I feel like I'm so close though

"x?????0\fE??k???]?????A?t\"??K??\b??e2???vG?G???\n\rz??????B/;X/?&??\n??`??\r?Z???????z ??9?m??_?L??;?S??*8.??(?c4!8%????0?1/?}Y?B?i??\\???BY????E??\r?f??)i\fº?Z??$??u??+??2<?\r?B&\"5?1LIz?!*?Iz??,?l?`???/?????Y??t?Rh??R????y??2??+????????NGa???\r??R8?u??\b+c????*\n???k????ab??q?u?G??.\\?4?}??U?f?r???l?r"
 

eslachance23:02:02

Oh btw, @dm3 that approach did work, I included it in my project, and used the following line on the incoming packet:

(String. (byte-array (z/inflate msg))) 
(z/ being that zip.clj file)

eslachance23:02:48

Took a lot of mucking around and some help from other people but it works!