make test fail

[et44]

On Mac OS X 10.6.8 with Xcode 4.2 build 4C177, build test failed.
(dunno if this is enough to go on - thanks for any help!)
-- Also failed on Mac OS X 10.7.3 with 4.2 build 4D199

See https://gist.github.com/1820894 for console output.

[mikelikespie]

@et44 I pushed a fix that will resolve this. I have only tested on 10.7. If you run into this again, try rm -rf .env

Please reopen this if you still experience issues.

[et44]

very much appreciate the work you're doing and the quick reply.

On Feb 13, 2012, at 2:18 PM, Mike Lewis wrote:

@et44 I pushed a fix that will resolve this. I have only tested on 10.7. If you run into this again, try rm -rf .env

Please reopen this if you still experience issues.

---

Reply to this email directly or view it on GitHub:
#6 (comment)

[et44]

just fyi, i had to rm .env but make finished and the tests ran. tnx again.

On Feb 13, 2012, at 2:18 PM, Mike Lewis wrote:

@et44 I pushed a fix that will resolve this. I have only tested on 10.7. If you run into this again, try rm -rf .env

Please reopen this if you still experience issues.

---

Reply to this email directly or view it on GitHub:
#6 (comment)

[et44]

sorry to bug you. the python chat server starts, and the testchat app in the simulator says it's connected, and it does append chat sentCells to its tableview, but a browser (Safari 5.1.2) opened to localhost:9000 seems to hang. the info_div on the browser page only displays "status: connecting..." - never updates to "status: connected to gateway" (per proxy.js), and Submit updates the page but not the (iPhone 5.0 Simulator) app, or vice-versa from the app to the browser. am I missing something obvious?

On Feb 13, 2012, at 2:18 PM, Mike Lewis wrote:

@et44 I pushed a fix that will resolve this. I have only tested on 10.7. If you run into this again, try rm -rf .env

Please reopen this if you still experience issues.

---

Reply to this email directly or view it on GitHub:
#6 (comment)

[mikelikespie]

I've only tested it in Chrome. Can you tell me if Chrome works? If not, I
will take a look.

Thanks,
Mike

Michael Lewis
lolrus.org
mikelikespie@gmail.com

On Mon, Feb 13, 2012 at 4:34 PM, et44 <
reply@reply.github.com

wrote:

sorry to bug you. the python chat server starts, and the testchat app in
the simulator says it's connected, and it does append chat sentCells to its
tableview, but a browser (Safari 5.1.2) opened to localhost:9000 seems to
hang. the info_div on the browser page only displays "status:
connecting..." - never updates to "status: connected to gateway" (per
proxy.js), and Submit updates the page but not the (iPhone 5.0 Simulator)
app, or vice-versa from the app to the browser. am I missing something
obvious?

On Feb 13, 2012, at 2:18 PM, Mike Lewis wrote:

@et44 I pushed a fix that will resolve this. I have only tested on
10.7. If you run into this again, try rm -rf .env

Please reopen this if you still experience issues.

---

Reply to this email directly or view it on GitHub:
#6 (comment)

---

Reply to this email directly or view it on GitHub:
#6 (comment)

[et44]

yeah, works in chrome, tnx. thought I had tried it but realized i only tried safari and firefox - same problem with both.

hope this doesn't piss you off but i'm wondering if the socketrocket cocoa would work just as well with a node.js server with socket.io? I've been fiddling with express/mongodb and ASIHTTPRequest the last few days and i've got some basic stuff working, but i suck at javascript only somewhat less than python which i've never looked at before. i looked through the SRWebSocket class - it is wayyy over my head. I'm trying to get multiple iOS devices to work with shared data using json without polling. your chat server works awesome and the SRWebSocketDelegate implementation in TCViewController is really minimal and clean. using your library on the ios client side seems like a breeze. it looks like your python server largely leverages tornado, and it would take me a lot longer to get up to speed with python than javascript if node/socket.io would work.

On Feb 13, 2012, at 6:10 PM, Mike Lewis wrote:

I've only tested it in Chrome. Can you tell me if Chrome works? If not, I
will take a look.

Thanks,
Mike

Michael Lewis
lolrus.org
mikelikespie@gmail.com

On Mon, Feb 13, 2012 at 4:34 PM, et44 <
reply@reply.github.com

wrote:

sorry to bug you. the python chat server starts, and the testchat app in
the simulator says it's connected, and it does append chat sentCells to its
tableview, but a browser (Safari 5.1.2) opened to localhost:9000 seems to
hang. the info_div on the browser page only displays "status:
connecting..." - never updates to "status: connected to gateway" (per
proxy.js), and Submit updates the page but not the (iPhone 5.0 Simulator)
app, or vice-versa from the app to the browser. am I missing something
obvious?

On Feb 13, 2012, at 2:18 PM, Mike Lewis wrote:

@et44 I pushed a fix that will resolve this. I have only tested on
10.7. If you run into this again, try rm -rf .env

Please reopen this if you still experience issues.

---

Reply to this email directly or view it on GitHub:
#6 (comment)

---

Reply to this email directly or view it on GitHub:
#6 (comment)

---

Reply to this email directly or view it on GitHub:
#6 (comment)

[zaphoyd]

By default tornado.websocket only supports RFC6455. Safari uses the older draft76/00 protocol. There is an option in tornado to enable support for older protocols: http://www.tornadoweb.org/documentation/websocket.html (see the warning box)

The javascript test client only creates an unprefixed WebSocket connection (https://github.com/square/SocketRocket/blob/master/TestChatServer/static/proxy.js#L13). This will not work in FireFox as before version 11 (i.e. all non RFC6455 implementations) were prefixed as MozWebSocket. It can be made to work in older FireFox's by checking whether either one is available and using the appropriate one.

et44: SocketRocket client should work with any WebSocket server, not just python ones. I have it running against my own server written in C++. Node.js shouldn't be a problem as long as you can arrange the server to speak RFC6455 websocket.