Experimental IRC log happs-2007-11-20

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:27<davidL>is there an easy way to update all the darcs HAppS repos all at once?
00:15:43<alexj__>you could probably write a script that does it.
00:15:50<alexj__>but why do you want to?
00:18:01<davidL>more importantly, why is bytestring in the dependency list, that's in base
00:19:15<Igloo>Not in GHC 6.8.1
00:21:11<davidL>does that mean it won't build it 6.6.1?
00:21:56<davidL>s/build it/build with/
00:46:50<Igloo>I'm afraid not
00:47:27<davidL>k, thanks
03:20:11<iseff>hello
03:20:44<iseff>i was wondering... in 0.9.1... how to get access to the headers of a request?
03:21:03<iseff>i can't seem to find the answer to this anywhere
03:24:50<iseff>anyone around?
03:30:52<iseff>in fact, more generally, is there just a way to get at the Request object now that I'm missing?
04:59:09<nburlett>hey all, the PDF is missing for the slides from Alex Jacobson's talk
04:59:15<nburlett>http://happs.org/slides.pdf
06:15:19<shapr>Uh oh
06:19:42<nburlett>indeed.. every time I try to learn about HAppS, something goes wrong :-<
06:19:52<shapr>:-(
06:20:13<nburlett>the blog example has been broken every time I try it
06:20:38<nburlett>and apparently now it requires ghc 6.8.1 ?
06:21:18<shapr>yup
06:21:22<nburlett>crud
06:21:24<shapr>Still broken though, I think.
06:21:44<nburlett>oh well, I guess I get to find something else to work on
06:21:57<nburlett>(ghc 6.8.1 doesn't work on PPC Mac OS X 10.5)
06:30:07<perspectivet>6.8.1 doesn't build from source?
06:30:19<perspectivet>on PPC Mac OS X 10.5
06:31:38<nburlett>perspectivet: yes
06:31:43<nburlett>http://hackage.haskell.org/trac/ghc/ticket/1843
06:33:58<perspectivet>damn, good to know.
06:34:24<nburlett>yeah, sucks ;-<
06:34:41<perspectivet>looks like they're shooting to fix it quick though.
06:34:47<perspectivet>6.8.2 target milestone
06:35:40<nburlett>woo :->
07:01:42<nburlett>good night
16:31:57<Sizur>do we have happs working for 6.8.1 already?
16:33:53<Sizur>guys?
16:37:06<Sizur>nvm, just read the post. will have to wait a little more :)
16:41:11<shapr>Sizur: Yeah, the repos are 6.8.1 compatible
16:44:58<Sizur>wait, i read alex post and the way i understand it is that 6.8.1 are different repos that are not public yet
16:45:00<Sizur>right?
16:56:02<shapr>Um, I don't think so.
16:56:35<shapr>I could be wrong, but I think the current repos are 6.8.1, and build fine.
16:56:42<Sizur>thanks
16:56:46<Sizur>i'll try at home
16:56:59<shapr>Sure
16:57:03<shapr>argh, mischan
16:57:35<shapr>Moral of that story is.. don't try to have more than four conversations at the same time.
16:59:02<Sizur>if you are a male that is
16:59:22<Sizur>my wife has 5 without sweat
17:00:13<shapr>haha
18:52:39<perspectivet>Saizan: did you get my patch?
18:53:08<Saizan>perspectivet: yes
18:53:23<Saizan>but i don't get the modification to putAuthNames
18:53:54<Saizan>the C code sends a buffer of length MAX_AUTH_NAME * MAX_AUTH_METHODS, right?
18:54:27<Saizan>ah, btw, putPadded has a bug where it ignores the second argument
18:56:16<perspectivet>yes, IIRC the buffer should be padded to length MAX_AUTH_NAME *
18:56:16<perspectivet> MAX_AUTH_METHODS
18:56:55<perspectivet>but the mod I put in there is wrong, now that I look at it again
18:57:04<Saizan>ah ok.
18:57:22<Saizan>with your version you get a length of MAX_AUTH_NAME * MAX_AUTH_METHODS^2
18:57:32<perspectivet>yeah, oops
18:57:54<Saizan>i think puthAuthNames was right, but putPadded bugged
18:58:01<perspectivet>ok
18:58:56<perspectivet>both of those probably explain why the join message was ending my spread session
18:59:08<perspectivet>at least part of it.
18:59:22<Saizan>mmh, join shouldn't use that code
18:59:37<perspectivet>It uses putPadded
19:00:16<perspectivet>But yeah, putAuthNames is only used by connect
19:01:50<Saizan>ah, via putGroup
19:02:09<Saizan>nullAuthMethod is required?
19:04:55<perspectivet>I put that in early on before I understood all the code.
19:05:26<perspectivet>I didn't look at checkAuths to see if it was strictly necessary
19:07:08<Saizan>but the C code sends a "NULL" authname if the user didn't set one?
19:08:52<perspectivet>I believe it needs to be sent to the server, yes.
19:11:27<perspectivet>checkAuths does need a (Handle -> IO Bool) not to fail, right?
19:11:58<Saizan>right
19:12:34<perspectivet>so yes, nullAuthMethod is required :)
19:13:07<Saizan>well if you just pass checkAuths the empty list it does nothing :)
19:13:34<perspectivet>but you still need to pass "NULL" to the server
19:13:49<Saizan>ok
19:14:46<perspectivet>I think connect is set up correctly to handle additional auth methods, but I looked at more involved auth methods to verify that
19:14:48<Saizan>so we could check for an empty authlist in Conf, instead of expose nullAuthMethod
19:15:27<perspectivet>yeah, that's probably cleaner
19:16:22<perspectivet>BTW, the desiredName in Conf isn't technically a PrivateGroup is it
19:16:26<perspectivet>?
19:16:39<Saizan>why not?
19:17:07<Saizan>it's what you want your connection to have as privategroup
19:17:44<perspectivet>well, your true privategroup is returned by spread and passed to receiver
19:19:37<Saizan>sure
19:19:55<Saizan>what type would you use? it was natural for me to use the same one
19:20:25<perspectivet>well something similar
19:20:46<perspectivet>I was more thinking of this issue
19:20:59<perspectivet>MAX_PRIVATE_NAME 10
19:21:00<perspectivet>
19:21:00<perspectivet>#define MAX_GROUP_NAME (1+MAX_PRIVATE_NAME+1+MAX_PROC_NAME)
19:21:07<perspectivet>sorry for the barf
19:22:02<perspectivet>shouldn't the type conversion routines be specific to one of those two constants
19:22:31<Saizan>type conversion between?
19:22:57<perspectivet>PrivateName -> ByteString
19:23:09<perspectivet>PrivateGroup -> ByteString
19:23:21<perspectivet>Both truncate to diff lengths
19:23:26<perspectivet>of bytestring
19:23:46<perspectivet>dunno, I'm newish to haskell
19:23:55<Saizan>do i have PrivateName?
19:24:20<perspectivet>I'm thinking so
19:24:38<perspectivet>You don't currently
19:25:20<perspectivet>but it seems to be the way to go from the little I understand of Haskell idioms
19:25:28<perspectivet>idioms/design
19:25:32<Saizan>i have Group and mkGroup that truncates to MAX_GROUP_NAME, and PrivateGroup and mkPrivateGroup that truncates to MAX_PRIVATE_NAME
19:25:52<Saizan>i'm not sure what PrivateName should represent
19:28:20<perspectivet>hmm, that's probably a bug then because the string returned by the server is up to MAX_GROUP_NAME in length
19:29:19<perspectivet>that may be why the join is failing actually
19:30:14<Saizan>geez, so i send a MAX_PRIVATE_NAME string and i get back a MAX_GROUP_NAME one? very nice
19:30:26<perspectivet>yeah
19:30:57<perspectivet>BTW, before we get any further, I just thought I should extend thanks for ripping out this code
19:31:25<Saizan>"ripping"?
19:31:33<perspectivet>cranking?
19:32:00<perspectivet>ah, ok, s/ripping out/producing/
19:32:08<perspectivet>I've probably learned more haskell in the last couple of days than I have in the last couple of months.
19:33:13<Saizan>hehe, no problem :)
19:33:48<Saizan>not that my style is so clean as others'
19:35:10<perspectivet>no, but you definitely pack the code in tight
19:35:33<perspectivet>lots of nice little idioms I don't in many places
19:37:41<Saizan>:)
19:38:38<perspectivet>so from what I've seen in testing the code with my patch should connect and sptmonitor registers a session for that connection
19:39:00<perspectivet>then attempting to "join" a group terminates that session
19:39:27<perspectivet>the private name fix might be enough to fix that.
19:40:34<Saizan>yes, i should just pack the string gives back in the constructor without any check
19:41:04<Saizan>+the server
19:41:15<perspectivet>it's probably worth checking just from a security standpoint
19:47:36<Saizan>ah, btw, why did you change the check in mkGroup? similar bug?
19:51:15<perspectivet>the test was removing all non-alphabetical characters. I think we want the opposite fo that.
19:51:44<perspectivet>as for the lower bound being 22 rather than 36...
19:53:30<perspectivet>ah right, I was playing with the effect private group names (which include 2 # chars) would have on the connection protocol
19:53:41<perspectivet>it should be 36, not 22
19:53:43<Saizan>mmh, i just followed the java code there
19:54:04<Saizan>ah, so it was you trying to feed bad data?:)
19:54:16<perspectivet>yes :)
19:55:14<perspectivet>but I believe my test is correct if you use 36 rather than 22 as the lower bound
19:55:41<Saizan>could you use darcs for the next patch? so i can apply it directly and darcs also lets you pick diffs more selectively
19:56:15<perspectivet>darcs to push or darcs to generate?
19:56:42<Saizan>generate
19:56:49<perspectivet>ah, you want darcs record instead of darcs diff
19:56:58<Saizan>ah, yes :)
19:57:21<perspectivet>my bad, should have looked at those options more closely
19:57:24<perspectivet>no prob
20:04:14<perspectivet>I'll probably test these changes at some point today
20:04:47<Saizan>pushed what we've discussed
20:04:47<perspectivet>did you push those changes in?
20:04:50<perspectivet>ok
20:05:02<perspectivet>pulling
20:12:20<perspectivet>do you want me to make the private name + private group changes
20:18:48<Saizan>i thought i did them already, but if you've a better design go ahead
20:19:03<perspectivet>ok
20:19:53<perspectivet>PrivateGroups are still mAX_PRIVATE_NAME in length which my main concern
20:31:38<perspectivet>oh, oops I guess it doesn't, but it still makes sense to type that to allow the compiler to protect you a bit
20:46:18<Saizan>yep, i should write a tighter interface, probably adding a type for desiredName in Conf as you proposed is the simplest way
20:46:44<Saizan>s/i/we/
21:00:44<perspectivet>I'm working on that now.
23:16:01<shapr>ACTION snores quietly, waiting for cabal to build
23:17:14<Saizan>shapr: does happs and its deps now build on 6.8?
23:17:53<alexj>saizan, as of an hour ago, largely yes.
23:18:05<alexj>HAppS-Begin builds with the current searchpath.
23:18:28<Saizan>how did it end with haxml?
23:19:19<cedricshock>My HAppS-Begin has been building for the last half-hour of CPU time...
23:20:04<cedricshock>I had to add -XEmptyDataDecls and -XMultiParamTypeClasses to get it to build.
23:21:13<alexj>cedricshock: I just updated searchpath to default to using -fglasgow-exts so you don't need to deal with that.
23:22:16<cedricshock>Excellent!
23:22:28<sjanssen>alexj: aren't LANGUAGE pragmas in source files that use extensions better?
23:22:37<shapr>Saizan: I think so, it built for me earlier.
23:22:54<shapr>I had to install crypto by hand since the hackage versions is missing some deps.
23:23:16<alexj>sjanssen: I just posted a rant on this issue to the ghc list.
23:23:44<sjanssen>alexj: .ehs is an interesting idea
23:23:52<sjanssen>alexj: though LANGUAGE has certain advantages
23:24:12<sjanssen>eg. I can easily tell whether a file will work in older version of GHC
23:24:30<alexj>sjanssen: LANGUAGE seems pointless because the compiler can infer which extensions are used and tell you if you want to know.
23:25:01<Saizan>alexj: not a compiler that doesn't support that extension
23:25:11<shapr>ehs?
23:25:40<alexj>so, if you package a file for use somewhere else, run it through something that tells you which extensions are used.
23:26:14<alexj>I bet it is relatively trivial to make that functionality available via a web browser once someone implements that function.
23:29:52<sjanssen>alexj: note that Cabal allows you to enable language features for all modules in a package
23:31:35<alexj>yeah, so now you have information spread out randomly between source files and cabal files and if you want to build/debug via ghci you have a problem.
23:32:12<sjanssen>true
23:32:26<cedricshock>It is my belief that everything needed for a source file should be specified (somehow) in the source file.
23:34:08<alexj>cerdickshock: it is because the compiler can infer the relevant features.
23:34:41<alexj>cedrickshock: there just doesn't seem to be a good reason to impose that pain on users.
23:35:18<cedricshock>alexj: Yeah, I hate boilerplate too.
23:35:51<sjanssen>I consider LANGUAGE to be more documentation than code
23:36:25<cedricshock>Most of what's needed for any program (the language itself) is inferred from the file.
23:36:56<cedricshock>sjanssen: And documentation is frequently generated so that it's gotten right.
23:38:46<cedricshock>If something requires an extension a compiler doesn't have it's going to fail whether or not the compiler knows what the extension it doesn't have is called. It's just a matter of what someone will see when trying to use another compiler.
23:39:46<cedricshock>If the extensions, like imported modules, can't be inferred then they need to be stated explicitly so that a human or compiler can figure out what's going on.
23:41:43<Saizan>you can't know if the code need an extension or if it's just broken, with a compiler that doesn't support it
23:42:16<Saizan>just how you can't know which package the module Foo you import comes from, so we've build-depends in cabal.
23:45:53<alexj>if oyu don't know whether the code works then there is no reason to assume the language header is correct.
23:46:14<alexj>moreover there is nothing that prevents the language pragma to define more extensions than the file actually uses.
23:46:42<cedricshock>Saizan: Exactly. In practice the compiler that doesn't know about the extension is likely to be very unhelpful (ghc 6.6 series just says "cannot parse LANGUAGE pragma", failing to say what extension it doesn't have).
23:47:35<sjanssen>cedricshock: that's a compiler bug
23:49:07<cedricshock>I'm just saying LANGUAGE pragma beats specifying things outside of the source, and less boilerplate beats more boilerplate.
23:51:08<cedricshock>About how long does HAppS-Begin take to build?
23:52:10<alexj>I'm saying that if LANGUAGE pragmas are documentation then they should be optional.
23:53:31<Saizan>cedricshock: are you using sp with runghc? sure that the server is not already running?
23:54:01<cedricshock>Saizan: I have no idea. It's eating lots of CPU...
23:55:42<cedricshock>Hmm. 127.0.0.1:8000 says, "hello world". I feel stupid...
23:56:52<cedricshock>Now why does that take 700 MB of memory and 80% of my processor?

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