Experimental IRC log happs-2007-11-23

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.

00:08:47<perspectivet>so is happs getting close-ish to something that might be considered a 1.0 release? Stable API, that sort of thing.
00:34:38<Saizan>perspectivet: i fixed the endianMismatch bug, basically i was writing as little endian and reading as big endian, now i fixed it to little endian.
00:34:59<Saizan>we should CPP-it depending on the arch i suppose
00:39:34<davidL>when will HAppS.State.EventTH be fixed?
00:44:21<perspectivet>CPP-it?
00:44:37<perspectivet>Saizan: great though.
00:45:32<perspectivet>Saizan: I've started working on a command line performance and test program
00:46:27<perspectivet>performance testing will be pretty coarse compared with the standard profiling stuf but should be pretty decent over large test counts
00:47:16<perspectivet>I'll mail it for review and pushing when I've got something useful running
00:47:25<perspectivet>probably by tomorrow
00:48:06<Saizan>k, thanks
00:48:19<perspectivet>I'll probably also do a c++ version of the same functionality along with that so we have a "native" spread benchmark
00:48:37<perspectivet>c++ version won't be done by tomorrow though.
00:48:50<Saizan>CPP i mean use some compile tipe CPP #ifdef to set things based on the arch
00:49:25<Saizan>have you seen if some of the c examples can be used as benchmarks?
00:50:27<perspectivet>I haven't seen anything that can do configurable test counts or anything like that.
00:50:42<perspectivet>I'll take a look shortly though.
01:15:51<Saizan>perspectivet: what do you think of instead of having a Chan on both sides, have a ReadEnd and a WriteEnd and make only the former accessible to the user?
01:25:25<perspectivet>That seems fine. So far I've only used the Chan for reading messages.
01:26:00<perspectivet>and I'm using send for "writing"
01:26:25<Saizan>yesh, writeChan will only confuse other readers
01:26:32<Saizan>*would
01:27:24<perspectivet>and you'd still maintain the startReceive/stopReceive semantics?
01:36:32<Saizan>do you find them useful? i initially thought about using stopReceive in disconnect, but the exception raised on the closure of the handle seems to do the right thing by itself
01:38:39<Saizan>stopReceive can be used to avoid building a long list of unused messages if the program knows it won't consume them for a while
18:04:35<perspectivet>watching alexj's talk at BAFP. Good stuff.
18:39:11<perspectivet>Saizan: continuing on from last night, the startReceive/stopReceive is useful.
18:51:01<Saizan>cool :), care to elaborate?
18:51:27<perspectivet>17:27 <perspectivet> and you'd still maintain the
18:51:27<perspectivet> startReceive/stopReceive semantics?
18:51:27<perspectivet>17:36 <Saizan> do you find them useful? i initially thought about
18:51:27<perspectivet> using stopReceive in disconnect, but the exception
18:51:27<perspectivet> raised on the closure of the handle seems to do the
18:51:28<perspectivet> right thing by itself
18:51:30<perspectivet>17:38 <Saizan> stopReceive can be used to avoid building a long list
18:51:32<perspectivet> of unused messages if the program knows it won't
18:51:34<perspectivet> consume them for a while
18:51:36<perspectivet>ugh sorry
18:52:11<perspectivet>mostly I think they're important for the latter reason
18:52:21<Saizan>ah ok
18:52:23<perspectivet>give the application programmer a bit more control
18:53:29<Saizan>so better make them not block when the receiver is yet started/stopped
18:54:25<perspectivet>the readChan, you mean?
18:54:42<Saizan>no, startReceive and soptReceive
18:55:15<perspectivet>ah, right, the "receiver" function
18:56:26<Saizan>yes, started/stopped was referring to the receiver loop
18:57:44<perspectivet>yeah they should probably return a Bool indicating whether the receiver received the command.
19:02:59<Saizan>i'm going to make a Spread.Client module that exports just the API, and make the others modules hidden
19:03:17<perspectivet>ok, sounds good
19:03:44<perspectivet>let me know when it's pushed
19:04:16<Saizan>k
19:11:37<perspectivet>Saizan: so I looked at the C spread client examples
19:11:46<perspectivet>there are a few in there that would be useful for testing
19:14:12<perspectivet>I'll make my perftest programs interoperate and replace spflooder and a modified version of sprecv
19:15:48<perspectivet>initially anyway
19:19:03<Saizan>looks good
19:20:21<perspectivet>sorry, slight change to that plan, spflooder is all that is needed for a basic load test.
19:20:48<perspectivet>It is both a single group client and a batch sender
19:36:42<Saizan>pushed, but i'm not sure if reexporting the modules is the best, maybe it's nicer if Client reexports the symbols directly
19:40:54<perspectivet>Yeah, I'm not sure what the best choice is wrt that
19:51:59<cedricshock>HAppS/State/Util.hs:58:1:
19:51:59<cedricshock> lexical error at character 'i'
19:54:51<alexj>cedrickshock: lemmih just pushed a fix.
20:08:20<Saizan>perspectivet: do you happen to own a big-endian machine? e.g. ppc
20:23:06<perspectivet>yes
20:23:50<perspectivet>I was going to test on a few platform combinations once I've got hspflooder working
20:28:42<perspectivet>but I'll have to wait until monday to do that because all that stuff is at my office.
20:34:46<Saizan>ok
20:56:22<cedricshock>?hoogle liftM

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