Experimental IRC log happs-2007-09-30

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.

05:59:20<stepcut>what do I do if I one of my data types instead $( deriveAll ) uses a data type from the standard libraries that is not a member of Typeable et al ?
06:00:10<shapr>I think I hacked up some stub instances for syb-with-class for IxSet.
06:00:21<stepcut>specifically, one of the date types -- looks like the blog app just does getClockTime >>= \(TOD seconds _) -> ...
06:00:54<shapr>I also wish we could directly persist the various time types.
06:01:03<shapr>I don't remember exactly why I couldn't do it though.
06:01:12<shapr>Probably that :-)
06:02:21<stepcut>:p
06:02:37<stepcut>seconds is plenty enough resolution for me for now, so I'll just use the same hack
06:02:47<stepcut>but, I figure a similar problem will come up in the future
06:05:54<stepcut>in other news, IxSet is sweet!
06:08:03<shapr>:-)
06:11:37<stepcut>you just define your algebraic data types, stick in a few $deriveAll and $inferIxSet lines, and then you do, putStrLn $ toString $ fs @= jessicaId, and you have your queries results as xml :-)
06:12:33<stepcut>but I think getLTE and getGTE are broken :-/
06:12:47<shapr> write a qc prop?
06:13:35<stepcut>yeah, I was go to make a patch, and a qc prop
06:14:18<stepcut>should be something simple like, getLTE == getEQ `union` getLT :)
06:15:24<stepcut>ACTION gets back to hacking
09:00:15<bakert_>So readM2 is just for getting numbers out, and Strings need to look elsewhere?
09:01:49<bakert_>So in fact to get a String from a POST body I can say:
09:02:12<bakert_>var <- lookMb2 return req "var"
09:02:19<bakert_>instead of (for an Int)
09:02:34<bakert_>var <- lookMb readM req "var"
09:02:50<bakert_>(sorry ignore that extra 2 on lookMb ... i am pasting from my versions :) )
09:03:13<bakert_>or is that overkill?
09:03:46<bakert_>Something to do with that B constructor on the rqBody part of the Request record. Binary? ByteString?
09:03:58<bakert_>that's why I need lookMb?
11:00:57<bakert>So storing information in a database is out, and storing Haskell state variables magically in HAppS is in?
11:01:07<bakert>What about if you want to do something else with that data?
12:45:14<bakert>total spammage as i'm sure you're all on #haskell anyway, but i wrote a happs tutorial thingy for those as ignorant as i was yesterday: : http://bluebones.net/2007/09/simple-haskell-web-programming-with-happs/
12:46:48<tuukkah>#haskell is too high-volume :-)
12:47:51<tuukkah>and tutorials are good
12:51:42<bakert>well, being as dim as i am i couldn't really make any sense of the existing one.
12:51:57<bakert>tuukkah: do you think i could link to mine from the existing tutorial (it's a wiki page) or is that just cheeky?
12:52:52<tuukkah>i meant *more* tutorials is good :-) thanks for your effort!
12:52:58<tuukkah>sure
12:53:08<tuukkah>although isn't the wiki page for haskell 0.8.8?
13:09:21<tuukkah>actually, you don't mention in the tutorial which version of happs you discuss
13:10:11<bakert>tuukkah: good point. i should do that. i actually couldn't get the "stable" version to install so went with darcs latest.
13:11:05<bakert>tuukkah: i meant, should i put a link to my page as an "alternative" on the existing tutorial page, rather than replacing it! something like "if you are an inexperienced haskell progammer it might help you to look at .... "???
13:11:53<tuukkah>darcs latest is also ambiguous, as the world is turning towards 0.9.1
13:13:53<tuukkah>but in any case, a link from the wiki page would be good as long as you state the audience and the happs version
13:29:06<bakert>tuukkah: well the cabal file says 0.8.8, but then so does the cabal file of the version that i couldn't build :(
13:29:11<bakert>do you think i can trust it?
13:31:47<tuukkah>it's 0.8.8 plus unstable development
13:32:08<tuukkah>the 0.9.1 cabal files say 0.9.1
13:33:35<vegai>bakert: as far as I can tell, HAppS state saving still has quite nasty problems for large datasets
13:33:51<vegai>so I would suppose databases are not completely out yet
13:34:53<bakert>vegai: oh really. i was just trying to get in the HAppS vibe. i've approached it a couple of times before and given up. so this time i decided i was definitely going to get something going come hell or high water. as for using it for something "real" or large scale ... i'm a long way off that :)
13:35:07<bakert>that tutorial just freaks me out though.
13:36:09<vegai>say, if your state is 1GB and you change 1 byte, the whole state gets written again to disc
13:39:55<bakert>that's not great
13:39:56<bakert>:)
13:40:18<tuukkah>an understatement :-)
13:51:31<vegai>I wonder if the backend could be replaced to use something like git
13:52:21<vegai>or darcs if you insist on NIH :P
13:53:51<tuukkah>nih - wasn't darcs there first?
13:55:23<vegai>NIH = Not Invented (in) Haskell, didn't you know?
13:55:25<vegai>ACTION smirks.
13:55:47<tuukkah>ok =)
13:56:28<tuukkah>i'd expect git and darcs to have problems with 1 gig files too
13:56:31<Saizan>well state serialization has changed a lot in 0.9.1, no?
13:56:46<tuukkah>Saizan, for better or for xml ?-)
13:57:14<Saizan>i mean with sharding/multimaster etc..
13:59:18<tuukkah>Saizan, can those be used locally to fix vegai's issue?
14:00:51<Saizan>i don't really know
14:03:26<vegai>perhaps the strategy will be to just offload that crap to S3 and let them worry about it :P
14:03:41<vegai>EC2<->S3 is free anyway...
15:02:21<bakert>So tell me, if I mush my brain around a bit more and learn happs 0.9.1 it will be worth it, right? Gimme a little hope, eh?
15:04:44<tuukkah>of course depends on your goals, but in general i expect it to be worth it
15:10:40<bakert>My goal is to understand some new ways of thinking about programming that go on to be useful to me at least once in building something practical :)
15:11:13<bakert>Best of all would be if Haskell was amazing and HAppS was a brilliant way to write web apps. But I'll settle for learning something along the way.
15:11:16<bakert>:)
15:13:02<tuukkah>in that case, happs is definitely worth it :-)
15:20:17<bakert>HAppS is really wedded to the whole XML => XSLT => XHTML thing then eh?
15:20:27<bakert>I have to say that gives me the heebie jeebies
15:20:55<tuukkah>luckily we don't *have* to use xslt
15:21:48<bakert>cool. i think i'll leave that side of things for another day and concentrate on porting my tutorial to 0.9.1
15:36:22<bakert>Hmm, so
15:36:31<bakert>p runhaskell -ihaskell haskell/Main.hs sp runhaskell -ihaskell haskell/Main.hs
15:36:34<bakert>or even
15:36:36<bakert>sp runhaskell -ihaskell haskell/Main.hs sp runhaskell -ihaskell haskell/Main.hs
15:36:43<bakert>seems to hang after issuing a bunch of warnings
15:37:16<bakert>is that normal? does whatever it is doing take a very long time?
15:38:55<Saizan>bakert: does the server work?
15:39:22<bakert>oh i seeeee! Sorry Saizan i am being retarded.
15:39:33<bakert>I thought this was some kind of preparatory step.
15:39:39<bakert>rather than "run server"
15:39:40<bakert>doh.
15:39:44<bakert>thanks :)
15:39:57<Saizan>np :)
15:40:34<bakert>Good question raised: http://programming.reddit.com/info/2v1n4/comments/c2v2op
15:40:49<bakert>To which I'm afraid I don't know the answer. Is there some kind of migration thing?
15:41:28<Saizan>0.9.1 has support for state migration
15:41:53<Saizan>see State.hs and State/*.hs in HAppS-Begin
15:42:39<Saizan>it's just a matter of specifying the old version and a migration function
15:42:54<bakert>cool
15:42:59<Saizan>in a class
17:45:07<stepcut>hrm, HAppS 0.9.1 XML converter turns a list of Strings into a list of CData, but XSL does not have access to the seperate CData items, it just merges them into one big string :-(
17:46:18<stepcut>actually, it's not just strings, If I do, data MyType = MyType Int String, the Int and String will be put into adjacent CData elements, and get merged together by xslt
17:46:20<tuukkah>stepcut, already complained about by nomeata
17:46:28<stepcut>sweet!
17:46:37<stepcut>I don't really have a work around in mind though :-/
17:46:44<stepcut>I take that back
17:47:06<stepcut>I have a work around (just newtype everything), a fix is less obvious :)
17:47:21<tuukkah>his code should be here: http://darcs.nomeata.de/latutman/
17:48:59<stepcut>In my data time, I have a timestamp represented as a the number of seconds since unix epoch. I need to convert that into a string before displaying it to the user.
17:49:26<stepcut>Currently my code looks something like, ok =<< getEntries
17:49:42<stepcut>where I just rely on ok to convert the IxSet into XML with no intervention
17:51:13<stepcut>I am thinking of instead changing it to, do { entries <- getEntries ; ok $ fixDate $ toXml entries }
17:51:33<stepcut>where fixDate would walk over the XML data, and convert any timestamp nodes into string representations
17:51:54<stepcut>but, I wonder if I am missing some cooler way of doing things :)
17:52:26<tuukkah>you could have fixDate *before* toXml
17:53:16<stepcut>tuukkah: hrm, true. At first I thought I could not do that, because I can seem to use the date types in an IxSet, but since I am just converting to a String, that should work
17:53:44<tuukkah>or do the conversion in xslt =)
17:54:01<stepcut>tuukkah: could not find any good way to go from epoch time -> string in xslt
17:54:46<tuukkah>xml means trouble
17:55:39<stepcut>I wonder what the benefits of doing the conversion before toXml would be
17:58:29<stepcut>well, for one, after the Xml convesion, the epoch time is a String instead of an Int

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