Differences

This shows you the differences between two versions of the page.

Link to this comparison view

irc:1444082400 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[05:25:56] *** ChanServ sets mode: +o temporalfox
 +
 +[08:39:45] *** ChanServ sets mode: +o purplefox
 +
 +[09:52:12] <​cescoffier>​ guys, vertx-web build is failing because of : Build timed out (after 15 minutes). Marking the build as aborted.
 +
 +[09:52:25] <​cescoffier>​ will increase the timeout.
 +
 +[09:56:21] <​purplefox>​ why is taking so long?
 +
 +[09:57:43] <​cescoffier>​ we have several module resolving the yard gem
 +
 +[09:57:57] <​cescoffier>​ we need to have a look to this
 +
 +[09:58:31] <​purplefox>​ ah the doc generation
 +
 +[09:59:16] <​purplefox>​ i think we should really look at moving all doc gen to a separate project after 3.1 as we discussed
 +
 +[10:01:20] <​cescoffier>​ yes, that would make things much faster
 +
 +[10:03:17] <​cescoffier>​ purplefox: we are dealing with a few things about the new eventbus.js,​ once done, we should be able to start the release
 +
 +[10:03:25] <​cescoffier>​ we would need the release notes
 +
 +[10:03:44] <​purplefox>​ are we going to put the notes in the release?
 +
 +[10:04:31] <​purplefox>​ i'll do the release notes
 +
 +[10:04:37] <​purplefox>​ also I want to look at https://​github.com/​eclipse/​vert.x/​pull/​1157
 +
 +[10:04:40] <​purplefox>​ maybe we include it too
 +
 +[10:15:07] <​cescoffier>​ purplefox: do you want me to review it ?
 +
 +[10:15:43] <​purplefox>​ i'm doing it. there are a few issues with it still, but I'm correcting those myself
 +
 +[10:18:41] <​temporalfox>​ if you include this, please annotate the enum with @VertxGen and add doc
 +
 +[10:24:13] <​purplefox>​ he already did that
 +
 +[10:28:02] <​temporalfox>​ cool
 +
 +[10:36:02] <​purplefox>​ temporalfox:​ ok all done
 +
 +[10:38:55] <​pmlopes>​ @temporalfox i've a PR on jsproxygen that runs all test using the real vertx-eventbus.js
 +
 +[10:38:56] <​pmlopes>​ https://​github.com/​vert-x3/​vertx-service-proxy/​pull/​27
 +
 +[10:39:18] <​temporalfox>​ ok
 +
 +[10:39:30] <​temporalfox>​ how does it work ?
 +
 +[10:39:43] <​temporalfox>​ that makes me more comfortable given that we did not have real test of proxy creation
 +
 +[10:40:06] <​temporalfox>​ it's nashorn based ?
 +
 +[10:40:43] <​temporalfox>​ I see
 +
 +[10:40:43] <​temporalfox>​ var SockJS = require('​sockjs-client'​);​
 +
 +[10:40:52] <​temporalfox>​ how does it use a sockjs client in the tests ?
 +
 +[10:40:58] <​pmlopes>​ the same script works on nashorn, node and browsers, the trick was that i've created a stub of the sockjs-client to use the real eventbus
 +
 +[10:41:25] <​temporalfox>​ I see
 +
 +[10:41:35] <​temporalfox>​ it reuses parts of the previous bus.js
 +
 +[10:41:59] <​temporalfox>​ good job
 +
 +[10:42:11] <​pmlopes>​ the stub uses exactly the same API as the real implementation so i just map the calls to the eventbus and return the raw strings to vertx-eventbus.js and it then handles it
 +
 +[10:42:47] <​temporalfox>​ do you use the same in vert.x web ?
 +
 +[10:44:06] <​pmlopes>​ yes exactly the same
 +
 +[10:44:21] <​pmlopes>​ oh you mean to test it on vert.x web?
 +
 +[10:44:28] <​pmlopes>​ not yet but that is the plan
 +
 +[10:46:25] <​temporalfox>​ yes
 +
 +[10:57:30] <​cescoffier>​ temporalfox,​ purplefox what about https://​github.com/​vert-x3/​issues/​issues/​45
 +
 +[10:57:56] <​temporalfox>​ yes I said I would take care of it, but it slept in my schedule
 +
 +[10:58:17] <​temporalfox>​ I can do it before release
 +
 +[10:58:28] <​purplefox>​ it's a doc issue i think
 +
 +[10:58:40] <​purplefox>​ btw vertx-shell is failing on CI
 +
 +[10:58:55] <​temporalfox>​ CI has transient issues
 +
 +[10:59:00] <​temporalfox>​ we need to double check
 +
 +[10:59:08] <​temporalfox>​ vertx-rx and another one were failed yesterday
 +
 +[10:59:34] <​temporalfox>​ I'm running it again
 +
 +[11:00:04] <​purplefox>​ temporalfox:​ hmm, doesn'​t look like a CI issue, it's a failing test
 +
 +[11:00:08] <​temporalfox>​ yes
 +
 +[11:00:09] <​purplefox>​ maybe a race condition there?
 +
 +[11:00:18] <​temporalfox>​ I was thinking about that indeed
 +
 +[11:00:33] <​purplefox>​ CI is often very good for finding race conditions in code :)
 +
 +[11:00:37] <​temporalfox>​ indeed
 +
 +[11:00:48] <​temporalfox>​ and such race conditions are one of our worst enemy :-)
 +
 +[11:01:29] <​temporalfox>​ I see the problem
 +
 +[11:01:47] <​temporalfox>​ it may be a vertx problem
 +
 +[11:02:04] <​purplefox>​ How does the command registry get closed?
 +
 +[11:02:21] <​temporalfox>​ the command registry deploys a verticle in vertx
 +
 +[11:02:27] <​temporalfox>​ to be notified of vertx close
 +
 +[11:02:43] <​temporalfox>​ so the test assumes that the close callback has all verticles undeployed
 +
 +[11:03:09] <​temporalfox>​ CommandRegistry does
 +
 +[11:03:10] <​temporalfox> ​    ​vertx.deployVerticle(this,​ ar -> {
 +
 +[11:03:10] <​temporalfox> ​      if (!ar.succeeded()) {
 +
 +[11:03:10] <​temporalfox> ​        ​registries.remove(vertx);​
 +
 +[11:03:10] <​temporalfox> ​      }
 +
 +[11:03:10] <​temporalfox> ​    });
 +
 +[11:03:20] <​temporalfox>​ and
 +
 +[11:03:27] <​temporalfox> ​  ​public void stop() throws Exception {
 +
 +[11:03:28] <​temporalfox> ​    ​closed = true;
 +
 +[11:03:28] <​temporalfox> ​    ​registries.remove(vertx);​
 +
 +[11:03:28] <​temporalfox> ​  }
 +
 +[11:03:55] <​temporalfox>​ and the test does not seem wrong to me
 +
 +[11:06:56] <​purplefox>​ doesn'​t that test exit without waiting for close to occur?
 +
 +[11:07:14] <​purplefox>​ if i add a countdownlatch it seems to pass every time
 +
 +[11:07:53] <​temporalfox>​ context.asyncAssertSuccess should prevent exit
 +
 +[11:08:53] <​purplefox>​ If I change it to this it passes every time for me:
 +
 +[11:08:54] <​purplefox>​ https://​gist.github.com/​purplefox/​4b72f8b891d846ce68a6
 +
 +[11:09:03] <​purplefox>​ without those changes it fails most times for me (in IDE)
 +
 +[11:09:13] <​temporalfox>​ otherwise it fails for you ?
 +
 +[11:09:16] <​purplefox>​ yes
 +
 +[11:09:43] <​temporalfox>​ ok then please change it this way and I'll investigate
 +
 +[11:12:22] <​temporalfox>​ locally it fails sometimes
 +
 +[11:12:25] <​temporalfox>​ I've added some logging
 +
 +[11:12:30] <​temporalfox>​ when it passes it prints
 +
 +[11:12:33] <​temporalfox>​ closed
 +
 +[11:12:33] <​temporalfox>​ removed
 +
 +[11:12:33] <​temporalfox>​ done
 +
 +[11:12:38] <​temporalfox>​ when it fails
 +
 +[11:12:38] <​temporalfox>​ closed
 +
 +[11:12:38] <​temporalfox>​ done
 +
 +[11:12:52] <​temporalfox>​ "​removed"​ is the verticle undeployment
 +
 +[11:13:00] <​temporalfox>​ so there is something unclear
 +
 +[11:13:01] <​temporalfox>​ to me
 +
 +[11:13:15] <​temporalfox>​ it means that when it fails "​stop"​ has not been called on the verticle
 +
 +[11:16:14] <​temporalfox>​ ah I see the issue
 +
 +[11:16:16] <​temporalfox>​ I think
 +
 +[11:16:20] <​temporalfox>​ the problem is above
 +
 +[11:16:24] <​temporalfox> ​    ​CommandRegistryImpl registry = (CommandRegistryImpl) CommandRegistry.get(vertx);​
 +
 +[11:16:29] <​temporalfox>​ does deploy the verticle
 +
 +[11:16:37] <​temporalfox>​ but it may close vertx before the verticle is deployed
 +
 +[11:16:47] <​temporalfox>​ in this case the verticle is not stopped
 +
 +[11:19:34] <​temporalfox>​ prb solved ^^
 +
 +[11:24:37] <​purplefox>​ hmm it seems to me the get() method should be async. otherwise you can return an uninitialised instance
 +
 +[11:25:16] <​purplefox>​ btw... why does it need to be a verticle?
 +
 +[11:31:51] <​purplefox>​ cescoffier: is vertx3-examples-it used any more?
 +
 +[11:38:43] <​cescoffier>​ yes
 +
 +[11:38:43] <​cescoffier>​ it's the one automating the examples
 +
 +[11:41:01] <​purplefox>​ ok, it's failing on CI
 +
 +[11:41:02] <​cescoffier>​ yes
 +
 +[11:41:04] <​cescoffier>​ right now it's because the stack artifact looks corrupted
 +
 +[11:41:13] <​cescoffier>​ and before it was because of some failing ITs
 +
 +[11:41:31] <​cescoffier>​ I also run it everyday on my machine
 +
 +[11:41:38] <​cescoffier>​ (on mac, linux and windows)
 +
 +[11:42:31] <​cescoffier>​ "​metrics#​groovy.metrics#​groovy,​ metrics#​java.metrics#​java,​ metrics#​js.metrics#​js,​ metrics#​ruby.metrics#​ruby"​ were broken because of the new vertx-eventbus.js
 +
 +[11:43:07] <​cescoffier>​ while this one "​sync-mongo#​java.sync-mongo#​java"​ was a missing dependency
 +
 +[11:44:26] <​purplefox>​ what is sync-mongo?
 +
 +[11:44:42] <​cescoffier>​ the vertx-sync example using the mongo client
 +
 +[11:45:21] <​cescoffier>​ (you implemented it ;-))
 +
 +[11:47:28] <​purplefox>​ sorry, just didn't recognise the syntax you used above
 +
 +[11:47:39] <​cescoffier>​ it's my syntax
 +
 +[11:48:03] <​cescoffier>​ just a way to identify the example and the "​execution"​ of this example (java, js, groovy....)
 +
 +[11:48:38] <​cescoffier>​ the maven plugin running the example use this syntax in the generated reports
 +
 +[11:49:08] <​cescoffier>​ for instance net-echo#​ruby is the echo example using the Net client and server in ruby
 +
 +[11:50:48] <​cescoffier>​ (this syntax is far from perfect, I just needed something easy when I implemented the plugin)
 +
 +[12:23:48] <​purplefox>​ cescoffier: pmlopes: have you seen jhipster: http://​jhipster.github.io/​tech_stack.html ?
 +
 +[12:24:14] <​purplefox>​ I was thinking maybe we could ddo something similar with vert.x,
 +
 +[12:48:40] <​pmlopes>​ yes jhipster is like mean.io for node, i see it as a stack and a scafolding tool
 +
 +[13:06:12] <​purplefox>​ yeah, it would be cool if we had a simple way of bootstrapping an end-end vert.x application with front-end too so users could get started quixkly
 +
 +[13:09:02] <​purplefox>​ pmlopes: cescoffier: release notes is going to be a pain - should we list every change in every component of the official stack?
 +
 +[13:50:56] <​pmlopes>​ i don't the wiki were we have the API changes would be enough, otherwise it will be a huge list of changes and i don't see the benefit of it, but that's my opinion...
 +
 +[14:01:24] <​purplefox>​ yeah, i've never been a huge fan of long release notes. who actually reads them?
 +
 +[14:02:53] <​cescoffier>​ purplefox: sorry was out for lunch
 +
 +[14:02:53] <​cescoffier>​ so yes I know jhipster
 +
 +[14:02:59] <​cescoffier>​ and yes we could do something like that with vert.x
 +
 +[14:03:01] <​cescoffier>​ release notes: I'm pretty sure I can get something using the github api
 +
 +[14:03:01] <​cescoffier>​ give me 30 minutes
 +
 +[14:03:13] <​cescoffier>​ oupsy, I should not have updated the bower repo this morning....
 +
 +[14:04:00] <​cescoffier>​ all examples are ok
 +
 +[14:04:05] <​purplefox>​ you mean a list of commits from the git log??
 +
 +[14:04:31] <​cescoffier>​ nope, the gihub API and get the issue and PR
 +
 +[14:04:40] <​cescoffier>​ for each component since the last release
 +
 +[14:05:08] <​cescoffier>​ It's what I do for Wisdom.... will just adapt the script to support all our repositories
 +
 +[14:05:32] <​cescoffier>​ we would just need to remove duplicates, but that's would be much easier no ?
 +
 +[14:12:56] <​cescoffier>​ purplefox: https://​api.github.com/​repos/​eclipse/​vert.x/​issues?​state=closed&​since=2015-06-23T19:​00:​00Z
 +
 +[14:13:08] <​cescoffier>​ this would give you all closed issues on vert.x core since the last released
 +
 +[14:14:51] <​cescoffier>​ purplefox: for PRs: https://​api.github.com/​repos/​eclipse/​vert.x/​pulls?​state=closed&​since=2015-06-23T19:​00:​00Z
 +
 +[14:42:47] <amr> can i just pass a MongoClient instance around when i want to reuse it a few times
 +
 +[14:42:58] <amr> or do i need to new up some more?
 +
 +[15:14:16] <amr> also, can i use vertx'​s futures?
 +
 +[15:41:37] <​cescoffier>​ purplefox: here are the release note for core: https://​gist.github.com/​cescoffier/​3f6074769b6499b2bb5f
 +
 +[15:42:44] <​purplefox>​ ok that's pretty nice
 +
 +[15:42:57] <​purplefox>​ could we aggregate them for all the official projects?
 +
 +[15:49:33] <​purplefox>​ cescoffier: i've just kicked off examples-it on CI as it hasn't run for a while
 +
 +[15:49:46] <​cescoffier>​ this morning ?
 +
 +[15:49:54] <​cescoffier>​ I've run them at lunch
 +
 +[15:50:27] <​cescoffier>​ it's normal to have failure as the NPM and bower artifacts are not yet in sync
 +
 +[15:50:46] <​cescoffier>​ the rest of the examples were all fine (on linux, windows and mac)
 +
 +[15:50:56] <​purplefox>​ i guess I'm a little confused. aren't we supposed to have all green on CI before a release?
 +
 +[15:52:42] <​purplefox>​ if it's not useful to have that build on CI we should remove it (although I prefer not to rely on private runs on people'​s machines)
 +
 +[15:54:00] <​purplefox>​ it's currently failing with this:
 +
 +[15:54:13] <​purplefox>​ Could not resolve dependencies for project io.vertx:​vertx-integration-test-maven-plugin:​maven-plugin:​3.1.0-SNAPSHOT:​ Could not find artifact io.vertx:​vertx-stack-dist:​zip:​full:​3.1.0-SNAPSHOT
 +
 +[15:56:37] <​cescoffier>​ corrupted artifact
 +
 +[15:56:42] <​cescoffier>​ I don't know from where this is coming
 +
 +[15:56:51] <​cescoffier>​ something internal to cloudbees
 +
 +[15:57:07] <​cescoffier>​ this job is not a canari build telling you about the state of the system
 +
 +[15:57:15] <​cescoffier>​ it generate reports.
 +
 +[15:57:44] <​cescoffier>​ and as we are close to a release, some of our example do not work anymore as they depends on not yet updated artifacts (NPM and bower)
 +
 +[15:58:28] <​cescoffier>​ I can make it green/blue if you want :-)
 +
 +[15:59:25] <​purplefox>​ can you elaborate on what you mean by not yet updated artifacts (npm and bower) ?
 +
 +[16:00:14] <​purplefox>​ i can't see a report on CI
 +
 +[16:00:32] <​cescoffier>​ yes, you can't see the report because of the stack artifact that is not there
 +
 +[16:00:46] <​cescoffier>​ so, some examples use the NPM and bower package
 +
 +[16:00:48] <​purplefox>​ so how can we tell if things are ok?
 +
 +[16:01:01] * purplefox confused
 +
 +[16:01:02] <​cescoffier>​ these packages are not yet published as it will be after the release
 +
 +[16:01:09] <​cescoffier>​ things are OK
 +
 +[16:01:20] <​purplefox>​ which packages?
 +
 +[16:01:26] <​cescoffier>​ I wrote it there a 14:04 :-)
 +
 +[16:01:38] <​cescoffier>​ NPM and Bower package embedding the vertxbus.js
 +
 +[16:01:58] <​purplefox>​ i saw you said that, but that wasn't enough information for me to unsderstand what those things are
 +
 +[16:02:01] <​cescoffier>​ there are still providing the vertxbus 3.0.0
 +
 +[16:02:07] <​cescoffier>​ and not 3.1.0
 +
 +[16:02:31] <​cescoffier>​ don't worry, if something would have been broken here, I would have reported the issue
 +
 +[16:02:41] <​cescoffier>​ as I did this morning for the vertxbus.js client
 +
 +[16:02:52] <​cescoffier>​ this job is misleading
 +
 +[16:02:59] <​cescoffier>​ I will move it to another tab ;-)
 +
 +[16:03:17] <​purplefox>​ so how do i know if the examples are ok without seeing a report?
 +
 +[16:04:07] <​cescoffier>​ because this is not the only CI executing them
 +
 +[16:04:18] <​cescoffier>​ my linux CI, and windows one are also executing this job
 +
 +[16:04:29] <​cescoffier>​ pmlopes: can you check and report the "​won'​t fix element from https://​gist.github.com/​cescoffier/​7e8a41aeaa35fcb44734
 +
 +[16:05:21] <​purplefox>​ ok but I don't like to rely on private CI runs...
 +
 +[16:05:33] <​cescoffier>​ have in windows CI would be nice
 +
 +[16:05:37] <​purplefox>​ how does it work privately but fails publicly?
 +
 +[16:05:38] <​cescoffier>​ but pricey
 +
 +[16:06:04] <​cescoffier>​ the current failure is weird, and I seriously have no idea from where it comes
 +
 +[16:06:09] <​cescoffier>​ it cannot resolve the vertx-stack
 +
 +[16:06:20] <​cescoffier>​ which works on my CIs
 +
 +[16:06:20] <​purplefox>​ have you tried deleting the workspace?
 +
 +[16:06:29] <​purplefox>​ i will do this
 +
 +[16:06:31] <​cescoffier>​ the workspace and maven repo are deleted every time
 +
 +[16:07:24] <​cescoffier>​ BTW: the report of the previous build are therE: https://​vertx.ci.cloudbees.com/​view/​vert.x-3/​job/​vertx3-examples-it/​243/​
 +
 +[16:08:51] <​cescoffier>​ and there: https://​vertx.ci.cloudbees.com/​view/​vert.x-3/​job/​vertx3-examples-it/​243/​testReport/​
 +
 +[16:11:07] <​cescoffier>​ oh, you restarted the job
 +
 +[16:11:10] <​cescoffier>​ it won't work
 +
 +[16:11:13] <​cescoffier>​ well already failed
 +
 +[16:11:21] <​cescoffier>​ the vertx-stack artifact is missing from the repo
 +
 +[16:12:09] <​purplefox>​ I wonder why it's trying to look in the cloudbees private repo. that artifact is on oss.sonatype
 +
 +[16:13:25] <​purplefox>​ weird, did it ever work?
 +
 +[16:14:01] <​cescoffier>​ yes that the tricky thing
 +
 +[16:14:05] <​cescoffier>​ it works sometimes
 +
 +[16:14:14] <​cescoffier>​ I've no idea from where this is coming
 +
 +[16:14:48] <​purplefox>​ one thing to notice - if you look in oss.sonatype there are no actual -SNAPSHOT artifacts, only timestamped
 +
 +[16:15:32] <​purplefox>​ oh well...
 +
 +[16:15:42] <​purplefox>​ if you're happy then let's make an exception this time
 +
 +[16:16:03] <​purplefox>​ it might be an idea to open a ticket with support at cloudbees dot com though
 +
 +[16:21:48] <​cescoffier>​ ah ah I'm forcing the repo, let's check
 +
 +[16:22:30] <​cescoffier>​ that's notmal there are only timestamps artifacts, it's the oss.sonatype repo policy
 +
 +[16:22:45] <​cescoffier>​ ok, by forcing the repo, it works
 +
 +[16:23:13] <​cescoffier>​ howver it will be red again, because of the web tests that need to be skipped (NPM/Bower issue)
 +
 +[16:29:43] <​purplefox>​ what's the process for getting the npm/bower stuff updated?
 +
 +[16:34:22] <​cescoffier>​ after the release
 +
 +[16:34:40] <​cescoffier>​ we need to publish to NPM and bower
 +
 +[16:34:56] <​cescoffier>​ NPM: you need a special account and do a npm publish
 +
 +[16:35:08] <​cescoffier>​ Bower, you just need to create a tag with the right version
 +
 +[16:35:29] <​cescoffier>​ webjar: I don't know if it's going to be automatic or not, it relies on the NPM package
 +
 +[16:44:51] <​cescoffier>​ pmlopes: I've made some cleanup
 +
 +[16:44:52] <​cescoffier>​ https://​gist.github.com/​cescoffier/​7e8a41aeaa35fcb44734
 +
 +[17:10:59] <​cescoffier>​ purplefox: here are the release notes: https://​github.com/​vert-x3/​wiki/​wiki/​3.1-Release-Notes
 +
 +[17:11:49] <​purplefox>​ cescoffier: looks nice :)
 +
 +[17:12:18] <​cescoffier>​ julien has checked them
 +
 +[17:12:30] <​cescoffier>​ but it would be good if paulo can check the web ones
 +
 +[17:14:21] <​cescoffier>​ so, on my side, it's ok
 +
 +[17:35:43] <​purplefox>​ cescoffier: pmlopes: temporalfox:​ ok, so what's the plan - are we going to do it today, or tomorrow (it's getting a bit late now)?
 +
 +[17:35:55] <​temporalfox>​ rather tomorrow
 +
 +[17:36:01] <​temporalfox>​ I need to release termd tonight
 +
 +[17:36:03] <​purplefox>​ +1
 +
 +[17:36:06] <​temporalfox>​ I waited last minute
 +
 +[17:36:15] <​temporalfox>​ to handle issues with termd
 +
 +[17:36:31] <​purplefox>​ ok good.
 +
 +[17:36:40] <​purplefox>​ so tomorrow we just need to build everything and push right?
 +
 +[17:36:50] <​temporalfox>​ kind of :-)
 +
 +[17:36:57] <​temporalfox>​ there are several phases
 +
 +[17:37:07] <​temporalfox>​ build + push will handle the jars
 +
 +[17:37:07] <​purplefox>​ what i mean is.. there are no outstanding code changes :)
 +
 +[17:37:13] <​purplefox>​ (other than termd)
 +
 +[17:37:17] <​temporalfox>​ yes nobody should push
 +
 +[17:37:31] <​temporalfox>​ then after jars we need to do the bintray
 +
 +[17:37:34] <​temporalfox>​ eclipse
 +
 +[17:37:38] <​temporalfox>​ npm
 +
 +[17:37:40] <​temporalfox>​ etc...
 +
 +[17:43:38] <​cescoffier>​ youhou !
 +
 +[17:43:49] <​cescoffier>​ tomorrow is the day I need to remember all my password ;-)
 +
 +[17:45:59] <​temporalfox>​ yes
 +
 +[17:46:05] <​temporalfox>​ and Thursday I can upgrade my OS
 +
 +[17:46:23] <​temporalfox>​ haven'​t done that for a while
 +
 +[19:10:51] <​pmlopes>​ Sorry guys i was away +1 for tomorrow
 +
 +[20:08:34] <​temporalfox>​ termd 1.0.0 has been released on should be on central
 +
 +[20:43:20] <amr> whats' the best way to new up a new future? Future.factory.future() ?
 +
 +[20:49:20] *** ChanServ sets mode: +o purplefox
 +
 +[20:53:00] <​pmlopes>​ @purplefox @temporalfox if you have trouble sleeping i just pushed the tcp bridge :| I also add a nodejs client that uses the same API as the SockJS client
 +
 +[21:20:55] <​temporalfox>​ pmlopes so the tcp bridge working with the jsproxygen ?
 +
 +[23:24:15] *** ChanServ sets mode: +o purplefox