--- Log opened Thu Jun 25 00:00:28 2009
00:18 < mae> haskelldb? :)
00:18 < mae> or better yet
00:19 < mae> a combination of openFile and appendFile :)
00:48 < mae> so, who wants to race / test sendfile? :D
00:52 < mae> kfish: sendfile-0.2 released with offset + count
00:52 < mae> http://hackage.haskell.org/package/sendfile-0.2
00:59  * kfish gets
01:37  * mae tries to grasp the monadic support for quickcheck
01:37 < mae> i wanna make a decent test suite for senfile
01:37 < mae> sendfile
01:56 < kfish> like comparing against stdio?
01:58 < kfish> on a related note, do you know which haskell library would support setsockopt(), to set TCP_CORK?
02:01 < kfish> hmm, not listed in Network.Socket.SocketOption
02:22 < mae> hmm
02:22 < mae> network has that i think
02:24 < mae> tibbe: hi!
02:26 < mae> kfish: the only builtin network stuff AFAIK is here: http://hackage.haskell.org/packages/archive/network/
02:26 < tibbe> mae: hi :)
02:26 < mae> tibbe: did you see my sendfile lib?
02:26 < tibbe> mae: yes I think I did, cool stuff
02:26 < mae> great
02:26 < mae> if you can, test it out and let me know of any issues
02:26 < mae> i was hoping you could use it with hyena
02:26 < tibbe> I would like to integrate it into either network/network-bytestring
02:27 < mae> didn't you say you were also working on gather for network?
02:27 < tibbe> mae: hyena already uses network-bytestring to get e.g. writev
02:27 < tibbe> I already have gather writes which are the most important
02:27 < mae> tibbe: does it work on windows?
02:27 < tibbe> yes
02:27 < mae> oh, i thought you hadn't implemented windows
02:27 < tibbe> sendFile is the only thing that is unix only at the moment in network-bytestring
02:28 < tibbe> but I intend to have that fixed before the next release
02:28 < tibbe> mae: someone else contributed patches ;)
02:28 < mae> tibbe: yeah, semantically, as I think we discussed before, sendfile doesn't belong in bytestring
02:28 < mae> I was thinking Network.SendFile
02:28 < mae> and eventually Network
02:28 < mae> err
02:28 < mae> it can be in network
02:28 < tibbe> yes
02:28 < mae> when it stabilizes
02:28 < mae> but I want to get more platforms under the belt and develop more bohemian until then.
02:28 < tibbe> semantically String doesn't belong in Network
02:28 < mae> : )
02:29 < tibbe> hence network-bytestring
02:29 < mae> sure it does
02:29 < tibbe> no, it's not a type for binary data!
02:29 < mae> well technically
02:29 < mae> sendfile can be used to send to any handle
02:29 < mae> :
02:29 < mae> : \
02:29 < mae> i haven't tested this with windows yet
02:29 < mae> but as far as I know this can be done there too
02:29 < mae> so really
02:29 < mae> System.IO.SendFile
02:29 < mae> : )
02:30 < tibbe> heh
02:30 < tibbe> there was a discussion about this on haskell-cafe
02:30 < mae> last year right?
02:30 < tibbe> about the problems of onthologies
02:30 < mae> i think i saw that
02:31 < tibbe> I actually think sendFile only works for sockets on some platforms
02:31 < tibbe> although I could be wrong
02:31 < mae> yeah that is true
02:31 < mae> but in windows, a socket is "int"
02:31 < mae> and is a what unix calls a file descriptor
02:31 < mae> a file handle is void *
02:31 < tibbe> "The TransmitFile function transmits file data over a connected socket handle. This function uses the operating system's cache manager to retrieve the file data, and provides high-performance file data transfer over sockets."
02:32 < mae> and also the msdn docs say that you can treat a file as a socket (go figure) instead
02:32 < mae> after all, windows networking was based on bsd
02:33 < mae> tibbe: read this http://msdn.microsoft.com/en-us/library/ms740522(VS.85).aspx
02:33 < mae> winsock2 means that a file can be accessed with a socket :)
02:33 < mae> winsock2 is windows 2000 +
02:34 < tibbe> hmm interesting
02:34 < tibbe> I would expect to find sendFile under Network
02:35 < tibbe> (i.e. it's not called copy file)
02:35 < mae> what is confusing though is that
02:35 < mae> Socket handle
02:35 < mae> is different than SOCKET
02:35 < mae> (which transmitfile uses)
02:35 < mae> SOCKET = int
02:35 < mae> its all very confusing
02:35 < mae> I at first tried to implement a hSendFile
02:35 < mae> but TransmitFile only accepts a HANDLE for infile
02:36 < mae> and the haskell Handle only stores a fd (int)
02:36 < mae> this fd can be used interchangeably with SOCKET
02:36 < mae> but a HANDLE cannot be
02:36 < mae> yeah and instead of seek
02:36 < mae> you got SetFilePointer
02:36 < mae> its all very freaky
02:37 < mae> but it works ok?!
02:37 < mae> and opening a file handle twice isn't that big of a sacrifice in the name of portability
02:37 < mae> especially since I am opening it with windows-specific CreateFile with sequential read hints and whatnot that the documentation recommends
02:37 < mae> (for perf)
02:38 < mae> (opening the handle twice meaning once for getting filesize, another time for sendfile)
02:45 < mae> ok ttyl
15:49 < ac> I'm having some trouble understanding happstack's type signatures. What's a WebT and a ServerPartT?
15:50 < ac> what does the type "Escape Response" represent? I understand NoHandle, but why is the other option in Result "Ok (Response -> Response) a"?
16:03 < ac> Why isn't simpleHTTP of type: simpleHTTP :: Conf -> (Request -> IO Response) -> IO ()
16:03 < ac> ?
16:07 < mightybyte> ac: The ToMessage class allows arbitrary types to be converted to a response.
16:08 < mightybyte> ac: simpleHTTP takes a conf and a ServerPartT computation that returns one of these response-generating data items.
16:09 < ac> mightybyte: what's the purpose of ServerPartT? And why a list of them? I understand what it does (I think: first element in list that returns a non-NoHandle response is served), but that seems like unneeded complexity
16:09 < mightybyte> ServerPartT is a monadic container for processing requests and generating responses
16:10 < ac> why not: simpleHTTP :: (ToMessage a) => Conf -> (Request -> IO a) -> IO () -- ? (please excuse my newbie questions)
16:10 < mightybyte> ServerPartT is somewhat complicated, but at it's heart it's a Reader Request monad.
16:11 < mightybyte> Because ServerPartT provides convenience functions for operating on the request data.
16:12 < ac> @hoogle ServerPartT
16:12 < ac> (is there no lambdabot here?)
16:12 < mightybyte> http://happstack.com/docs/0.2/index.html
16:12 < mightybyte> No
16:12 < ac> ;)
16:13 < mightybyte> That's the top-level page for Happstack docs.
16:13 < gcollins> ServerPartT also has stuff for filtering responses, validating responses (IMO that stuff is a little unnecessary), short-circuiting responses (either returning early or declining to produce a response), and Monoid/MonadPlus instances for gluing serverparts together
16:14 < ac> using Monoid/MonadPlus for that seems a little ad-hoc to me
16:15 < gcollins> nooooo, not at all
16:15 < gcollins> that's the best part
16:15 < ac> seems weird/inefficient to start evaluating every possible response until a non-NoHandle appears
16:16 < gcollins> not really -- you can decide pretty quickly whether you want to handle the request or not
16:16 < ac> I'd want only one ServerPartT and just do a little flow control based on the request URL
16:16 < gcollins> also you could write a custom piece of switching middleware if you were worried about performance
16:17 < mightybyte> ac: How else would you do it?  Look the uri up in a map to get the correct function?
16:17 < ac> mightybyte: basically
16:17 < mightybyte> Well, a map doesn't give you quite as much power.
16:18 < gcollins> the good thing about ServerPartT is that they compose
16:18 < mightybyte> And if you don't use a map, the alternative would be an if-else string (to describe as an imperative paradigm)
16:18 < ac> see I'm trying to understand the happstack philosophy, and what exactly that power is
16:18 < mightybyte> Happstack's HTTP functionality works well, but IMO that's not the compelling power.
16:18 < ac> my background in web programming is Apache + Perl/PHP :-/
16:19 < ac> (+ MySQL)
16:19 < mightybyte> I consider it's state system to be the real gem.
16:19 < gcollins> ac: a better comparison would be java servlets
16:19 < mightybyte> Although the HTTP functionality can be used completely independantly of its state.
16:19 < gcollins> state is nifty but still very "experimental"
16:20 < ac> mightybyte: yeah, that's why I chose to use happstack, because the macid system looked interesting. I haven't even gotten to that point yet, I'm still trying to figure out the basics of the HTTP server
16:20 < mightybyte> It does quite well on small websites.
16:21 < mightybyte> ac: I've got some introductory material at http://softwaresimply.blogspot.com that gives the basics of both HTTP and state.
16:21 < ac> I don't feel like I'm smart enough for the benifits of happstack to be useful for me :-P
16:21 < mightybyte> It doesn't go into great depth, but it should get you started.
16:21 < mightybyte> Heh
16:22 < gcollins> it's not that you're not smart enough, happstack's still over-complicated and under-documented
16:22 < mightybyte> It provides a clean way to use Haskell's type system for your state.
16:23 < ac> mightybyte: thanks for the link. I'm checking it out
16:23 < mightybyte> You really don't have to be all that smart to *use* happstack...at least not any smarter than you need to be to program in haskell.
16:24 < gcollins> ...lol
16:24 < ac> that's encouraging. I can program in Haskell just fine, it seems
16:24 < mightybyte> While gcollins's criticisms have some validity, it's still relatively straightforward to use happstack without understanding what's going on under the hood.
16:25 < ac> I like to understand what's going on under the hood a little bit
16:25 < gcollins> me too
16:25 < gcollins> the HTTP stuff isn't really that bad
16:25 < mightybyte> I do too, but I kind of ignored that when I was starting out with happstack.
16:25 < gcollins> once you go over it a couple of times
16:25 < gcollins> state i find impenetrable
16:25 < ac> this line is awesome: $(deriveSerialize ''BlogState)
16:25 < ac> that's why I'm using happstack
16:25 < mightybyte> Oh yeah
16:26 < ac> I've always hated the duplicity in SQL schema definitions and the data layer in a typical ORM type system
16:26 < ac> ORM/MVC
16:26 < mightybyte> The fact that it's TH makes it a little opaque, but the end result to the user is really nice.
16:26  * gcollins hates ORM in any of its myriad forms
16:26 < ac> yeah, it's ugly
16:27 < ac> I've written my own basic ORM system, and used a few, and disliked all of it
16:27 < mightybyte> Well then it sounds like you've come to the right place.
16:27 < gcollins> i would much rather code a data layer by hand, at least then i know that it'd be done correctly & efficiently
16:28 < ac> what's the story with the Component class?
16:28 < gcollins> i've heard too many stories about ORMs generating really crappy SQL
16:28 < mightybyte> I'd rather avoid all that boilerplate.
16:28 < mightybyte> Component is the basic unit of transactionality.
16:28 < mightybyte> I've actually been thinking about another blog post about Component.
16:28 < gcollins> please!
16:28  * gcollins would read that for sure
16:28 < ac> me too
16:29 < gcollins> if you do a good job of explaining what's going on we should put your explanation in the source comments also
16:29 < mightybyte> After writing an almost 5000 line site in happstack, I've decided that you want as many components as possible.
16:30 < mightybyte> You cannot operate on multiple components in one transaction.
16:30 < gcollins> btw, can we get haddocks for 0.3.2 put up on the website?
16:30 < gcollins> who do we have to ping to do that? mae?
16:31 < mightybyte> But within that restriction, separating components greatly eases change to your data model.
16:31 < mightybyte> Yeah, I've not been involved in any of that.
16:32 < ac> mightybyte: so a Component is like a table if you were using a SQL database?
16:32 < gcollins> mightybyte: if you could write a blog post about the correct way to do versioning / migration in happstack-state, that'd also be awesome
16:32 < mightybyte> Also, someone (I think it was stepcut) recently mentioned on the mailing list that splitting Components across different machines is a cheap and easy way to do basic sharding.
16:33 < gcollins> you might actually be the heaviest user of this stuff
16:33 < mightybyte> gcollins: There is one
16:33 < mightybyte> I probably am...or at least close to it.
16:33 < gcollins> what's your blog address?
16:33 < ac> mightybyte: yeah, I had the same thought when I was idly thinking about scaling a happstack program
16:33 < ac> mightybyte: user data goes on one machine, post data goes on another, etc
16:33 < mightybyte> http://softwaresimply.blogspot.com  (it's linked from happstack.com)
16:33 < gcollins> ac: that kind of data decomposition will only take you so far
16:34 < mightybyte> gcollins: right
16:34 < mightybyte> ...but it's a start
16:34 < ac> yeah, eventually I figured I'd have to create databases using TokyoCabinet or something
16:34  * gcollins nods vigorously
16:34 < gcollins> tokyo cabinet is the best thing since sliced bread
16:34 < mightybyte> ac: Hmm, I'm not sure that I'd liken it to a table, but that could be a reasonable analogy.
16:35 < mightybyte> ac: Are RDBMS tables the unit of transactions as well?
16:35  * mightybyte shows his lack of experience with databases.
16:35 < ac> hrm... a transaction is just a collection of SQL statements
16:36 < gcollins> mightybyte: no, SQL transactions can cross tables
16:36 < ac> but that collection of statements typically only operates on one table
16:36 < mightybyte> ac: Ok, then I'd say that a Component probably has no good analog in RDBMSs
16:36 < ac> yeah, they can
16:36 < gcollins> to understand SQL transactions you need to grok the "transaction log" as a mental model
16:36 < mightybyte> The most important thing about Components is that they are they boundary for transactions, and that they can be easily composed.
16:36 < gcollins> it's not that hard
16:37 < mightybyte> s/they boundary/the boundary/
16:37 < ac> is there a forms library that can easily be used with happstack that manages things like maintaining text in input fields, validating, showing results of validation to user, etc?
16:38 < mightybyte> Fine-grained components really pay off when you need to do migrations.
16:38 < ac> because in my experience that's often the biggest pain-in-the-ass aspect of web development
16:38 < mightybyte> ac: Yes, I make heavy use of it.
16:38 < mightybyte> formlets
16:38 < jmcarthur_work> i've not tried formlets yet but heard really good things about it
16:38 < ac> excellent. I was hoping that's what formlets does. I haven't taken time to look over the API yet
16:38 < mightybyte> http://github.com/chriseidhof/formlets/tree/master
16:39 < mightybyte> I have a few of my own mods here http://github.com/mightybyte/formlets/tree/master
16:39 < ac> see this is why I love writing things in Haskell. Typically people way smarter than me have made an amazing set of libraries for doing exactly what I want to do
16:39 < mightybyte> I would almost say that my site makes more use of formlets than it does happstack
16:40  * gcollins kind of wishes happstack was using git on github instead of darcs
16:40  * mightybyte agrees
16:40 < mightybyte> But don't let Thomas hear that. :)
16:40 < gcollins> :)
16:41 < mightybyte> ac: I do have a bunch of formlets-related private code that is important to what I'm doing.
16:41 < gcollins> don't get me wrong, i like darcs, but i like git a lot better
16:41 < mightybyte> ac: It gets the job done for now, but there are some significant shortcomings.
16:41 < ac> mightybyte: are you going to write a replacement/improvement of formlets?
16:41 < jmcarthur_work> i'm always so torn between darcs and git. there are things that i like about both that the other doesn't have
16:42 < mightybyte> One of these days I'll get around to fixing them, but I've got too many other things to do right now.
16:42 < ac> mightybyte: I've tried to write a library for doing the same thing in other languages. It's a hard problem
16:42 < mightybyte> Yeah, but I think it's quite solvable in Haskell.
16:43 < ac> yeah. How does formlets store the state? Does it use a viewstate mechanism like .NE?
16:43 < ac> .NET I mean
16:43 < gcollins> jmcarthur_work: i find darcs a lot more "awkward" to use, but a lot of that is my unfamiliarity with it
16:43 < mightybyte> For me, formlets falls short in it's support for variable length lists.
16:43 < jmcarthur_work> gcollins, i did at first, as well, compared to git
16:43 < jmcarthur_work> but they really are simply different models
16:44 < mightybyte> Boy, it's been awhile.  You should probably just look at the formlets code.
16:44 < mightybyte> ac: Are you talking about during form generation or submit handling?
16:44 < gcollins> off to the hardware store, bbl
16:45 < ac> mightybyte: submit handling. Like if you fill out a form, navigate to a different page, then come back to the form, does it maintain the values of the input fields?
16:45 < mightybyte> Oh, no.
16:45 < ac> ASP.NET does that with the ViewState
16:45 < ac> it's quite nifty
16:46  * mightybyte has never used anything else
16:46 < mightybyte> My recent work with Happstack is actually the first significant web development I've done...other than a bit of PHP many moons ago.
16:46 < ac> I've hand rolled that sort of thing by sticking every input field in to the user's session, but that's a real pain if done manually
16:47 < mightybyte> Yeah, formlets is orthogonal to that problem.
16:48 < ac> does your auth framework simply make another Component for user's sessions?
16:49 < ac> or does it not use happstack's State
16:49 < mightybyte> Yes, it uses a separate component.
16:50 < mightybyte> This allows a user to just add ":+: Auth" to their main state component's dependencies, and they're off and running.
16:50 < ac> hmm. I don't understand Component dependencies yet
16:51  * ac eats solidsnack 
16:51 < mightybyte> When you add Auth to a component's dependencies, you automatically get access to all of Auth's state manipulation methods.
16:51  * otacon Snack? Snack?! Snaaaaaaaaaaaaaaaaaaaaaaaa....
16:52 < gwern> metal gear 5: snack eater
16:56 < ac> so back to my original question: What convenience functions does ServerPartT provide?
16:57 < mightybyte> Much of them I haven't used.
16:58 < mightybyte> http://www.haskell.org/haskellwiki/HAppS_tutorial2
16:58 < mightybyte> That page is old, but some of it still applies.
16:59 < mightybyte> dir, path, methodSP, withData, anyRequest
16:59 < mightybyte> multi is OBE
16:59 < mightybyte> ...replaced by msum.
17:00 < mightybyte> The best thing is to browse the documentation here http://happstack.com/docs/0.2/happstack-server/0.2/Happstack-Server-SimpleHTTP.html
17:03 < ac> mightybyte: yeah I was looking at the SimpleHTP docs. It seems like the kind of thing that makes perfect sense to who wrote it, but is a little puzzling without the whole picture
17:04 < mightybyte> Yeah.  I've never used any of the filtering stuff.
17:05 < mightybyte> But you want pretty much everything to operate in ServerPartT
17:08 < mightybyte> Here are the main functions I use: ok, notFound, addCookie, dir, methodSP, path, withDataFn, uriRest, and various look functions
17:10 < ac>  all the auth functions in happstack are for HTTP level authentication I assume?
17:11 < mightybyte> No, cookie level
17:11 < mightybyte> Oh, in happstack...yes.
17:11 < ac> your Auth deals with cookie level
17:11 < mightybyte> Right.
17:11 < mightybyte> I've never used the HTTP auth stuff.
17:13 < ac> it's basically never used for user auth because it's not very flexible. It's frequently used for easily limiting a whole site to a group of beta testers, for example though
17:17 < jmcarthur_work> HTTP is great... if you never want to log out
17:18 < jmcarthur_work> :(
17:18 < jmcarthur_work> HTTP auth, i mean
17:18 < jmcarthur_work> well, and you can log out by forcing a reauth, but the user has to understand to hit cancel
17:19 < jmcarthur_work> it's a shame, because HTTP auth is more RESTful, if one cares about such things
17:19 < ac> and it has the ugly problem of forcing you to authenticate before you see any rendered HTML
17:19 < jmcarthur_work> i don't think that's so horrible
17:20 < jmcarthur_work> err
17:20 < jmcarthur_work> i misinterpreted
17:20 < jmcarthur_work> yes, i agree
17:20 < jmcarthur_work> well, you could have rendered HTML without data and then populate it with data via AJAX after logging in if you want, i guess
17:21 < jmcarthur_work> but that isn't elegant at all
17:21 < jmcarthur_work> in my opinion
17:21 < ac> huh, I guess an AJAX request could have HTTP level auth. Yeah, they really screwed that up. I think HTTP is a horrible protocol
17:22 < jmcarthur_work> i don't think it's horrible... just could be better in key ways
17:22 < jmcarthur_work> it wasn't designed for some of the things we use it for nowadays
17:22 < ac> yeah. I don't actually think it's horrible. It's used for tons of stuff, so it must've gotten some things right
17:23 < jmcarthur_work> it's ingenious, for its time
17:23 < ac> it's just a little sad that it's beeing used for IM applications now. It's so not designed for that
17:23 < jmcarthur_work> ... what IM applications?
17:24 < jmcarthur_work> oh, you mean the in-browser ajax things?
17:24 < ac> yeah
17:24 < jmcarthur_work> ugh, yeah
17:24 < jmcarthur_work> wrong
17:24 < jmcarthur_work> on the other hand... it would be awesome for a web browser to include an XMPP client
17:24 < ac> but I think most people using instant messaging programs are using browser based ones now
17:24 < jmcarthur_work> that you can connect to servers by javascript loaded in a web page
17:25 < jmcarthur_work> really?!
17:25 < jmcarthur_work> i've not seen anybody using a browser based one
17:25 < ac> lots of people use Gmail and Facebook
17:25 < jmcarthur_work> hmm... i guess you are right about that
17:26 < jmcarthur_work> i was thinking of things like going to a page specifically to log into AIM and stuff
17:26 < ac> those exist too. I imagine tons of people at work use services like that
17:26 < jmcarthur_work> yes, they do exist, i just haven't seen them used too often
17:27 < ac> and now Google Wave is implemented over HTTP :-P
17:28 < mightybyte> Speaking of XMPP, have you heard of Hemlock?
17:29 < ac> nope
17:29  * jmcarthur_work looks up Hemlock
17:29 < jmcarthur_work> XMPP + Flash?
17:29 < ac> me too
17:29 < jmcarthur_work> ugh
17:30 < ac> is there any reason not to use simpleHTTP?
17:30 < mightybyte> Not that I know of.
17:30 < mightybyte> ...unless you don't like the interface SimpleHTTP provides.
17:30 < ac> but it provides all the functionality of happstack's web server?
17:31 < mightybyte> There has been some talk about memory usage problems.
17:31 < ac> hmm, I'll worry about that later obviously
17:31 < mightybyte> ...and substituting a left-fold enumerator (Hyena style) web server on the back end.
17:31 < mightybyte> ac: Everything that I've needed.
17:32 < mightybyte> I think there have been some problems with the server sending large files.
17:32 < mightybyte> Laziness kind of bites you in those situations.
17:33 < jmcarthur_work> that's because laziness and IO don't mix
17:33 < mightybyte> Sometimes they're nice.
17:33 < jmcarthur_work> convenient
17:34 < mightybyte> Yeah
17:34 < jmcarthur_work> but convenience is not why haskell originated
17:34 < jmcarthur_work> and look where it got us!
17:34 < mightybyte> Heh
17:34 < mightybyte> Why did Haskell originate?
17:34 < jmcarthur_work> as a standard language for functional programming research in academia
17:35 < jmcarthur_work> incorporating some of the latest ideas at the time
17:35 < mightybyte> Well it just so happens that functional programming rocks
17:35 < jmcarthur_work> consider haskell before monads were applied...
17:35 < mightybyte> True
17:36 < jmcarthur_work> those early pioneers didn't give in to the beckons of unsafe side effects. they kept at it until they found a better abstraction
17:36 < jmcarthur_work> i try to take a similar approach to lazy io today
17:36 < jmcarthur_work> and to the io monad, really, as i don't think it is perfect
17:36 < ac> yeah, the IO monad can probably be improved
17:36 < mightybyte> Well, I've got to go.
17:37 < mightybyte> Later.
17:37 < jmcarthur_work> see ya
17:37 < ac> mightybyte: thanks for the help
17:37 < jmcarthur_work> ac, some are trying to replace the io monad completely! frp is one example of such a venture
17:37 < ac> I really should explore some of the FRP libraries
17:37 < jmcarthur_work> it goes beyond IO, too, but IO is the biggest target
17:38 < jmcarthur_work> my opinion is that they aren't ready for embracing by the masses yet
17:38 < jmcarthur_work> but i'm working on that ;)
17:39 < ac> interesting ideas though. Hieroglyph looks really interesting
17:40 < ac> as well as flux and reactive-fieldtrip
17:40 < jmcarthur_work> reactive is definitely the one i would try if i was just starting
17:41 < jmcarthur_work> just fyi ;)
17:41 < jmcarthur_work> it has some odd implementation problems though, mostly due to a few GHC bugs
17:41 < ac> are there any 2d UI libraries coupled with reactive?
17:41 < jmcarthur_work> by UI do you mean like a GUI toolkit, or do you just mean graphics?
17:42 < ac> just a way to handle keyboard/mouse input and draw text and shapes
17:42 < jmcarthur_work> ah, i think you should look at reactive-glut and reactive fieldtrip
17:42 < jmcarthur_work> *reactive-fieldtrip
17:42 < jmcarthur_work> glut for the inputs and a graphics buffer, fieldtrip for the composable graphics
17:42 < ac> I have to say that's a pretty good library name
17:43 < jmcarthur_work> fieldtrip is orthogonal to reactive, btw. i think reactive-fieldtrip is just some convenience stuff
17:43 < ac> yeah, that's what the cabal descriptions say
17:44 < jmcarthur_work> if you want a decent description of the design concepts behind reactive, you should read http://conal.net/papers/push-pull-frp/
17:45 < jmcarthur_work> it's a very approachable paper
17:46 < ac> cool
17:48 < ac> this may be the first computer science paper I've looked at that I feel like I could understand
17:49 < jmcarthur_work> conal is very good at explaining himself
18:53 < ac> why is it that in mightybyte's blog post the Happstack modules are all Happstack.*, but in my installation they're HAppS.*?
18:53 < ac> I'm sure I installed happstack and not HAppS
18:54 < tommd> ac: I'd question that seeing as Happstack (Back to version 0.2.1) uses the 'Happstack' namespace.
18:54 < ac> grrr
18:55 < tommd> You can confirm this by looking at the source or the Haddock documents.
18:55 < ac> ghc-pkg list shows happstack-server, -state, -data, etc are all installed
18:55 < tommd> ac: Does it show that HaPPS is not installed?
18:56 < tommd> If HAppS is installed then that would be why you have the modules...
18:56 < ac> it's not installed. I used cabal install for everything
18:56 < tommd> Oh, and it appears that Happstack 0.1 used the HAppS namespace - do you need to upgrade?
18:56 < ac> should I?
18:57 < ac> 0.1 is the current version in hackage, right?
18:57 < tommd> I would - its not like 0.1 is getting any better (and more and more changes keep happening, making it harder to upgrade later)
18:57 < tommd> ac: No, 0.3.2 is out
18:58 < ac> weird. Just ran cabal install happstack-server and it's installing 0.3.2. I thought I did the same thing a couple days ago and I got 0.1
18:59 < ac> glad I'm doing this now and not after I've written a bunch of code
18:59 < tommd> Perhaps you hadn't done a 'cabal update' in a long time?  Glad your moving forward though!
18:59 < tommd> remember that cabal doesn't automatically (and annoyingly) update the package list - unlike most Linux distros package managers.
19:00 < leshp_resident> word out
19:00 < leshp_resident> some are using happs
19:00 < leshp_resident> how is web with cfunctional programming?
19:00 < leshp_resident> cool?
19:01 < tommd> Are you a bot or do you just like to say 'word out' frequently?
19:01 < ac> leshp_resident: uhm... I haven't honestly started, I've just been reading APIs and examples, but I'd say it's a little mind expanding
19:04 < leshp_resident> oh?
19:04 < ac> hrm, looks like the port of nullConf was changed from 5000 to 8000
19:04 < leshp_resident> how is it nicer than LAMP
19:05 < leshp_resident> ?
20:01 < gwern> leshp_resident: everything is in one language; there isn't the overhead of marshalling and connecting multiple systems with vastly different semantics
20:08 < gwern> leshp_resident: but you know we have tutorials and videos explaining this sort of thing
20:08 < gwern> leshp_resident: it'd be good if you went through those first
23:57 < ac> mightybyte: you around?
--- Log closed Fri Jun 26 00:00:30 2009