Experimental IRC log happs-2008-03-04

Available formats: content-negotiated html turtle (see SIOC for the vocabulary)

Back to channel and daily index: content-negotiated html turtle

These logs are provided as an experiment in indexing discussions using IRCHub.py, Irc2RDF.hs, and SIOC.

01:03:30<dbpatterson>mightybyte mentioned that arrays were bad, that they were copied on every lookup - so that means strings are bad too, right? is it ever advisable to use strings in HAppS?
01:07:46<Saizan>not lookups, but updates
01:08:10<Saizan>and and strings are not implemented as arrays
01:08:40<Saizan>ByteString are, sometimes, but you usually don't update single elements in a ByteString
01:08:56<dbpatterson>internally you mean?, the strings are not [Char]?
01:09:16<dbpatterson>so if I have a long string of text, how best should I be representing it in state?
01:09:25<dbpatterson>would a bytestring be better than a string?
01:09:46<Saizan>[Char] is a _list_ not an array
01:09:47<dbpatterson>or should I just work on caching the responses to improve performance?
01:10:05<dbpatterson>Saizan: oh, sorry... I'm still very much in C land :(
01:10:45<Saizan>i'd reccomend profiling before making performance decisions, ByteString generally use less memory though
01:28:17<dbpatterson>is this indicative of any specific error: HTTP request failed with: <socket: 180>: hPutBuf: resource vanished (Broken pipe) (and this is for tons of sockets, not just 180)?
01:29:20<dbpatterson>is this an OS error, or a HAppS error?
15:45:04<mightybyte>When sharding is implemented, will it be possible to shard in multiple dimensions?
15:53:13<mightybyte>Or, stated differently, what will be sharded? A component, or the top-level state entry point?
19:25:08<JoeHallett>I have a question about using the IO monad with HAppS.
19:25:28<JoeHallett>main = simpleHTTP nullConf { port = 8080 } impl
19:25:28<JoeHallett>impl = [ dir "plUpload" plUpload ]
19:25:28<JoeHallett>plUpload = [ anyRequest $ ok $ toResponse $ unsafePerformIO $ return
19:25:28<JoeHallett>"PLUpload message" ]
19:25:59<JoeHallett>Sorry about that.
19:27:24<JoeHallett>I would like to write something like:
19:27:32<JoeHallett>main = simpleHTTP nullConf { port = 8080 } impl
19:27:46<JoeHallett>impl = [ dir "plUpload" plUpload ]
19:27:58<JoeHallett>plUpload = [ anyRequest $ ok $ toResponse $ unsafePerformIO $ return
19:27:58<JoeHallett>"PLUpload message" ]
19:28:17<JoeHallett>Hopefully that's readable.
19:28:46<JoeHallett>But, I don't want to use unsafePerformIO. Is there a better way?
19:30:13<mightybyte>JoeHallett: I'm not the best person to answer, but I think you should be able to just do normal, safe IO without any problem.
19:36:22<JoeHallett>Thanks for the response! However, when I remove the "unsafePerformIO" I get a type error. I'm trying to figure out what that error is now.
19:39:55<mightybyte>Try plUpload = [ anyRequest $ ok $ toResponse $ unsafePerformIO $ ""PLUpload message" ]
19:40:10<mightybyte>Basically, just remove the return.
19:40:21<mightybyte>Oops, too many double quotes there.
19:46:25<JoeHallett>That doesn't work, but if I remove both the "unsafePerformIO" and the "return" then it will compile successfully.
19:47:48<JoeHallett>However, I included a return because I want to replace "return "PLUpload message"" with a function call that returns something in the IO monad.
19:58:43<mightybyte>Oh, I'm sorry, I meant to also remove the unsafePerformIO and the return.
19:59:07<mightybyte>Just go ahead and write a dummy function that stores some data in a file using safe IO.
20:00:06<mightybyte>Then you should be able to put that in the place of the return...
20:12:41<JoeHallett>But, then I'd still need the unsafePerformIO, right? That's what I'd like to get rid of.
20:16:17<mightybyte>mightybyte: I'm too new to Haskell to know for sure. But I was under the impression that you wouldn't need to.
20:16:28<mightybyte>Er, JoeHallett: ^^^
20:18:49<mightybyte>ACTION gets up for a moment. Talking to self is a sure sign of needing to clear one's head.
22:05:28<fxr>anybody using fastcgi?

Back to channel and daily index: content-negotiated html turtle