00:01:21 <mightybyte> It's pretty new.
00:01:36 <mightybyte> Big changes that are not backwards compatible.
00:02:02 <stepkut> it's not just big changes -- but different goals and fundamentals
00:03:05 <stepkut> ... like if GHC 8.0 was strict by default and allowed IO everywhere
00:03:18 <stepkut> might still be good.. but wouldn't be the same thing anymore
06:21:57 <LambdaDusk> good morning
14:47:03 <donri> stepcut: web-routes darcs-2?
14:47:55 <stepcut> donri: not yet
14:48:15 <stepcut> donri: in a few hours
14:49:14 <donri> aye
14:49:20 <donri> can i record more patches before that?
14:49:25 <stepcut> yup
14:49:51 <stepcut> I would like to work out the exact rules we want so that the urls don't keep changing
14:50:27 <stepcut> Like, FooURL -> foo-url, seems nice. But not sure what the conflict resolution for FooURL and FooUrl would be
14:50:59 <stepcut> compile time rejection seems ok in some ways because that just seems like a bad idea in the first place
14:52:06 <stepcut> but maybe there is a reasonable rule for disambiguation
14:53:13 <donri> i was thinking: first convert each constructor by the simple rule (FooURL -> foo-u-r-l) then do a second pass and convert foo-u-r-l to foo-url if that's not already taken
14:57:37 <stepcut> actually.. I think I am starting to like rejection more
14:57:44 <stepcut> because there is value in stable url names
14:58:07 <stepcut> not sure that you want adding or removing a constructor to also affect the rendering of other routes?
14:59:34 <donri> true
15:01:22 <stepcut> I can not think of a practical example where you would need the constructor names to be the same, differing only in captilization
15:02:25 <donri> exactly
15:03:02 <donri> maybe between different types but that doesn't matter right?
15:06:20 <donri> only if you mount sitemaps at the same root in which case you can get conflicts already anyway
15:11:38 <niez> hi, I have some experience with python and django, now I'm trying to use Haskell for web development, the Happstack documentation is all about templates and routes, where can I find informations about database?
15:12:25 <Lemmih> I would tell you about AcidState but you probably want something more traditional.
15:13:17 <stepcut> niez: there is also a section on acid-state --which is like a database. If you want to use a traditional database-- there is not special you need to do as far as happstack is concerned, so you would need to consult the documentation for the database library
15:16:03 <niez> ok, why?
15:16:45 <stepcut> why what ?
15:17:36 <donri> there are numerous libraries for talking to traditional/external databases in haskell, they should work with happstack "out of the box"
15:19:55 <donri> http://hackage.haskell.org/packages/archive/pkg-list.html#cat:database -- i just use acid-state so i don't really know which ones here are popular/good
15:19:55 <niez> why acid-state?
15:21:23 <donri> it's fast, easy to use, powerful and flexible and offers strong ACID guarantees. yay!
15:21:33 <niez> has it a server? does it support replication?
15:22:08 <niez> how can I query from other languages?
15:22:14 <donri> a client/server backend exists, no replication yet (that gsoc wasn't accepted :()
15:23:04 <donri> it's not optimal for use from other languages. you could use it to implement such a database yourself with some JSON RPC or something... but if you have that need maybe acid-state isn't the best option.
15:25:50 <niez> is it like object databases for object-oriented languages?
15:25:58 <donri> if you want something like the django orm, maybe "persistent" is the closest package
15:26:36 <donri> yes, acid-state is sort of like the zodb in python or prevayler for java
15:27:02 <donri> more like the latter since it's in-memory (like redis)
15:55:35 <stepkut> acid-state was, in-fact, very much inspired by prevayler
15:55:59 <stepkut> the acid-state project was not accept for GSoC because Lemmih got a full-time job for the summer and did not apply
15:56:06 <stepkut> so... now he has to do it for freeee! :p
15:56:15 <donri> :D
16:09:03 <stepkut> not sure how I feel about having a separate line for each LANGUAGE pragma
16:09:19 <stepkut> what is the advantage?
16:17:21 <donri> easier to scan, easier to sort, easier to remove one
16:17:59 <donri> no need to wrap to keep the pragma from getting very long
16:18:15 <stepkut> My feeling is a try to ignore those as much as possible and want them to take up as list space as possible..
16:18:30 <donri> but yes i see the disadvantages too
16:19:09 <stepkut> it's not a huge deal either way
16:19:14 <donri> for apps i tend to put them in .cabal instead
16:19:21 <donri> duno if there are disadvantages to that for libs
16:19:38 <stepkut> I put them in the .hs files because it makes it easier to load the files into ghci
16:19:46 <donri> you can override those with NoBla pragmas in individual files
16:19:52 <donri> ah
16:20:00 <donri> cabal-dev ghci ;)
16:20:06 <donri> soon cabal repl
16:20:34 <stepkut> sure, but putting the LANGUAGE pragmas makes it work for everyone
16:20:39 <stepkut> not just people with smart tools
16:20:44 <donri> in deed
16:21:06 <donri> easier to move code between projects etc too if all the info is in the file
16:21:11 <stepkut> given the fact that you aren't excited about having them in the .hs file in the first place, it seems you would want to minimize their presence as much as possible
16:21:23 <donri> same for imports vs having some NoImplicitPrelude thing
16:21:47 <donri> duno, i don't really feel strongly about it either way :)
16:22:28 <donri> mainly it's easier for me to add pragmas as separate lines due to shortcuts i have in vim, so the code ends up looking like that
16:22:43 <stepkut> :)
16:23:07 <donri> not that adding exts to an existing pragma is difficult
16:24:30 <donri> sometimes my OCD breaks through the medication and i feel an obsessive need to keep such things sorted :P
16:26:48 <donri> in other news happstack-server will be packaged for fedora soon, for better or worse, but might provide some publicity ;)
16:33:46 <stepkut> I do usually sort the extensions.. but just all on one line :)
16:37:10 <stepkut> ACTION is hacking on the haddock documents for happstack-clientsession
19:41:23 <stepkut> donri: so it looks like there are a few places where we allow the SessionData type to leak out of ClientSession.. not sure if that is bad or not
19:41:30 <stepkut> like, runClientSessionT :: ClientSessionT sessionData m a -> SessionConf -> m (a, SessionData sessionData)
20:41:36 <donri> stepcut: bad i'd say
20:41:53 <donri> can't we just use execStateT?
20:42:04 <stepkut> runClientSessionT :: ClientSessionT sessionData m a -> SessionConf -> m (a, SessionData sessionData)
20:42:25 <stepkut> we could turn that into, Maybe sessionData
20:42:37 <stepkut> but then they lose useful information..
20:43:04 <donri> why would you want to return sessionData at all
20:43:25 <stepkut> if you don't want to use withSessionClientT then you need someway to find out what happened in the end..
20:44:12 <stepkut> that case is not too bad, because it does not give the use the ability to mess around with the SessionData wrapper while inside ClientSessionT.. which is where things would be most likely to break
20:44:18 <donri> oh i see
20:45:40 <stepkut> back in 20
20:46:15 <stepkut> mapClientStateT and mapSessionStateT also expose the session data, though we can use a forall to ensure they can't do anything to it
20:46:20 <donri> docs for mkSessionConf are outdated unless you fixed that
20:46:30 <stepkut> mapSessionStateT :: (forall s. m (a, s) -> n (b, s)) -> SessionStateT s m a -> SessionStateT s n b
20:46:43 <stepkut> back in 20 mins.
20:46:45 <donri> k
20:47:18 <stepkut> I did update it.. but it is still out of date :)
20:47:46 <stepkut> this is why all the examples in the crash course can exactly be run.. to make sure they still compile
20:48:20 <donri> we could do that for haddocks with doctest
20:48:34 <stepkut> ah
20:48:37 <stepkut> let's do that
20:48:50 <stepkut> i have a bunch of commits, I will do a big commit in 40 mins
20:48:56 <donri> it can lead to rather large examples, which may or may not be a good thing
20:49:12 <stepkut> yeah
20:49:17 <stepkut> we should at least doctest the example in the header
20:49:23 <stepkut> bbiab.
20:49:33 <donri> also it's for REPLs
20:49:40 <donri> not multiline code blocks
21:35:44 <tazjin> Did I imagine that some changelog said a "noExpires" function for setting content-expiry headers was added?
21:35:49 <tazjin> Because I can't seem to find that again
21:35:58 <stepkut> tazjin: it was added.. one moment
21:36:19 <donri> tazjin: neverExpires
21:36:33 <tazjin> Ahh, thanks
21:39:09 <donri> stepkut: did you get my messages about overloaded strings and default?
21:40:56 <stepkut> donri: yes.. but it doesn't seem to be helping
21:41:12 <donri> oh?
21:41:15 <stepkut> one moment
21:52:35 <hpaste_> stepcut pasted OverloadedStrings + EmbedAsAttr + Default still doesn't work at http://hpaste.org/67607
21:57:51 <donri> weird error
21:57:57 <donri> overlapping instances messing things up maybe?
21:58:25 <stepkut> could be
21:58:42 <stepkut> but, clearly a monomophic type would be nicer here
21:59:27 <stepkut> seems like there was some agreement that monomorphic overloaded strings literals would be nice. Now the argument has moved onto whether you should allow IsString instances for things that need to be parsed and may have parse errors
21:59:51 <stepkut> and whether to check those parse errors at compile time
21:59:52 <donri> should use QQ for that IMO
22:00:00 <stepkut> yeah that is what SPJ said too :)
22:00:15 <stepkut> I think I am fine with that
22:00:16 <donri> hm is it really "foo" that messes things up or is it "p" and/or "id"?
22:00:25 <donri> those become string literals after trhsx
22:00:43 <stepkut> the "p" is fine because genElement takes a String argument (well a Name argument, which is a wrapper around String)
22:01:25 <stepkut> if you have hsx < 0.10, then the 'hello' will also cause trouble, but in >= 0.10 it outputs ("hello" :: String)
22:01:35 <stepkut> though.. we might wish that was an option to trhsx
22:01:54 <stepkut> we can do the same thing for asAttr to fix the problem there as well
22:02:00 <donri> i think it's the "id" that messes things up
22:02:22 <stepkut> I suspect it is both
22:02:31 <stepkut> both the "id" and the "foo"
22:02:31 <tazjin> Cabal's giving me this strange "cabal: Couldn't read cabal file "ixset/1.0.3/ixset.cabal"" error, do either of you have any ideas what could be causing that?
22:02:32 <donri> removing the attr makes it work, changing the attr to a number still fails
22:02:43 <stepkut> you can add an explicit type signature for the "foo" but not the "id"
22:02:53 <donri> hm true, if the default worked it would work for id too
22:03:23 <stepkut> unless you do let attrs = [("id","foo")] :: [(String, String)] in <p attrs>hello</p>
22:03:24 <donri> tazjin: yes, upgrade cabal :)
22:03:50 <donri> stepkut: maybe was a bad idea to release ixset with that cabal requirement
22:04:15 <tazjin> donri: You sure? It's, which is the same as on my other box (where everything still works fine)
22:04:42 <donri> tazjin: you probably didn't cabal update recently on the other box
22:05:28 <stepkut> cabal >= 1.10 ? I don't even remember why.. maybe I can lower it
22:05:34 <stepkut> oh..
22:05:36 <stepkut> no I can't
22:05:40 <stepkut> because it has tests built in
22:05:43 <donri> it's the detailed test interface
22:05:50 <tazjin> I'm upgrading, lets see
22:06:12 <donri> stepkut: you actually need to make it higher i think...
22:06:29 <stepkut> donri: oh ?
22:06:40 <donri> well, detailed is new in 1.14 i think
22:06:46 <stepkut> ACTION has no idea how to know
22:07:03 <donri> usually cabal will tell you... but maybe not for the "type"
22:07:08 <stepkut> yeah
22:12:17 <donri> tests/Data/IxSet/Tests.hs:181:20: Not in scope: `@/='
22:12:27 <donri> also why do i get that when trying to run the tests
22:12:56 <tazjin> Dependency hell is so frustrating
22:13:14 <tazjin> whenever I have to deal with this I feel like just wiping everything because that would probably be faster
22:13:19 <donri> tazjin: what you're having isn't really dep hell
22:13:24 <tazjin> Now it is
22:13:28 <stepkut> oh hmm
22:13:58 <tazjin> cabal-install depends on unix- which depends on base >=4.2 && <4.4
22:14:01 <tazjin> but I have 4.4.1
22:15:04 <stepkut> I started to add @/=, but then there was some ambiguity as to what it should do.. which the tests uncovered
22:15:04 <stepkut> so apparently I revered IxSet.hs but not the tests
22:15:04 <donri> heh
22:15:17 <donri> tazjin: cabal install cabal-install-0.14.0
22:15:34 <stepkut> donri: pushed a patch for the ixset tests
22:20:24 <donri> stepkut: maybe we'll need scoutess to test with different cabals too... :P
22:20:35 <donri> though, different platforms should sort of imply that?
22:20:39 <donri> haskell platform
22:20:49 <stepkut> that's what I am thinking.. different HP should get pretty good coverage
22:29:53 <stepkut> apparently using detailed-0.9 was a bad idea all around, and we should wait until detailed-1.0
22:41:22 <dcoutts> stepkut: if you're using it as a test for scoutess then that may be a different matter
22:41:43 <dcoutts> I mean if you want to do a tech preview of detailed test reporting then you may wan to try it
22:41:58 <stepkut> well, right now it is just a test in ixset that was causing someone install trouble
22:42:09 <dcoutts> what I meant was that at this stage few people would want to write packages using the interface
22:42:40 <dcoutts> but if you're trying out your infrastructure for build reporting, then a prototype with the detailed test interface would make sense
22:42:56 <dcoutts> so long as the plan involves switching to the final interface when that's released
22:43:40 <dcoutts> stepkut: ok, if it's a particular package test suite, then my previous advice stands
22:43:46 <stepkut> yeah
22:44:21 <stepkut> for scoutess detailed does sound nice, but right now I am just trying to make ixset easier to cabal install
22:57:15 <stepkut> donri: I pushed a patch to happstack-clientsession.
22:57:58 <stepkut> donri: The module header needs some help. Not sure what else is left. But I think it is close to ready for another release.
22:59:13 <stepkut> we should put a very stripped down version of demo.hs in the header I think. Some that declares the session type, derives a lens, modifies the session, and calls withClientSessionT
23:05:38 <donri> bedtime :)
23:06:38 <stepkut> :)