00:03:53 <donri> but then you have to run the effects to get the content type
00:04:15 <donri> if the 'a' can differ we can use proxies or whatever to inspect the content type first
00:05:16 <stepkut> if you can know the content type for the 'a' alone, then you don't have to run the part
00:07:03 <donri> but that's useless if it's the same 'a' for JSON and HTML?
00:10:11 <hpaste> stepcut pasted “selectRep / provideRep proof-of-concept for Happstack” at http://hpaste.org/83880
00:11:21 <stepkut> to make that happen for real, the selectRep function needs to actually follow the spec
00:11:38 <stepkut> though, what it does now is probably good enough in practice
00:12:45 <stepkut> but, it would be better to provide some reusable functions for parsing the accept headers and matching on available content types that we can provide and correctly find the best match
00:12:45 <donri> oic, well i was aiming for not needing provideRep, or only needing provideRep :)
00:14:25 <hpaste> donri annotated “selectRep / provideRep proof-of-concept for Happstack” with “imaginary api” at http://hpaste.org/83880#a83881
00:15:11 <stepkut> if we had the type, toResponse :: a -> m Response, instead of, toResponse :: a -> Response, then it would be easier to avoid needing selectRep
00:16:32 <stepkut> ah, one moment
00:16:44 <donri> (is it just for me hpaste is 100% width always now?)
00:17:18 <stepkut> seems to be
00:38:26 <stepkut> well, to do it correctly, the accepts would need to stick what they provide into a writer or something
00:39:29 <stepkut> and.. it is not clear to me what happens if you put a 'return foo' after the last accept
00:40:22 <stepkut> also.. if you have no accepts.. then you are getting into snapland, where you could have part that forgets to return a response?
00:44:14 <donri> stepkut: optimally that should result in a 406. AFAIK you can still get into that in current happstack since () is an instance of ToMessage?
03:52:10 <stepkut> yeah.. not sure I approve of, instance ToMessage ()
05:25:01 <stepkut> oh.. hmm.. I think that if you can describe your grammar via ABNF.. then you don't need a monadic parser to parse it.. a monad allows one parser combinator to depend on the result of another parser combinator.. but ABNF does not have any way to express that type of thing?
07:30:09 <srhb> I don't like that my app will just silently fail to update the state if a datatype _inside_ my main AppState has not had makeAcidic run on it.
07:30:13 <srhb> Is there a way to change that?
08:40:48 <mm_freak_> srhb: make AppState acidic?  of course only making acidic isn't enough, you actually have to use acid-state transactions
09:57:39 <srhb> mm_freak_: Point being if I make AttState acidic, and say it has a field posts :: posts, which itself is Posts { nextPostId :: PostId, posts :: IxSet Post } -- but I forget to use makeAcidic on Posts, my app will just silently fail to update Posts. Even though my updates update AppState.
09:58:28 <srhb> Ie everything works just fine if I use makeAcidic on Posts, too.
09:59:12 <srhb> s/AttState/AppState
10:14:05 <mm_freak_> srhb: that's not correct…  you only need to derive SafeCopy for your subrecords
10:14:10 <mm_freak_> something else is going wrong
10:14:36 <srhb> I'll have to cook up a minimal example, then. If I comment out the makeAcidic for Posts, it fails silently. If I comment it in, it works.
10:14:39 <srhb> I would expect an error here.
10:14:53 <srhb> What I don't get is how it fails silently. *whine*
10:15:12 <mm_freak_> at least i can't confirm that…  i make only my outermost type acidic and the rest gets SafeCopy instances
10:15:42 <srhb> Well, that's weird.
10:15:47 <mm_freak_> srhb: i'm assuming that you have only a single application state reference
10:16:02 <srhb> Right, I pass it into my handlers as an argument
10:16:16 <mm_freak_> well, it could be a bug
10:16:31 <mm_freak_> but it would be quite a weird bug, because the acidicness of subrecords isn't used anywhere
10:16:41 <srhb> I'm gonna assume I made the bug then, until I can reproduce it with a minimal example.
10:16:53 <mm_freak_> how do you define the subrecord in AppState?
10:17:12 <mm_freak_> _asConfig :: Config?
10:17:31 <srhb> data AppState = AppState { statePosts :: Posts }
10:17:58 <mm_freak_> and Posts is not a type alias?
10:18:24 <srhb> no, data Posts = Posts { nextPostId :: PostId, posts :: IxSet Post }
10:18:43 <mm_freak_> then i can't explain that behavior
10:18:52 <mm_freak_> i can only note that it doesn't happen for me and it sounds like a bug
10:19:00 <srhb> Right. I'll cook up a minimal example later. Good to know it's not intended to happen like that.
10:19:07 <srhb> It felt like all the good arguments just fell away. :P
10:19:33 <mm_freak_> =)
10:19:40 <mm_freak_> i hope you report it
10:20:30 <mm_freak_> srhb: btw, you said that Posts doesn't behave acidicly…  what does that mean?
10:21:27 <mm_freak_> i can't even discern the nature of your problem…  the whole problem doesn't seem to make sense
10:21:45 <mm_freak_> acid-state doesn't know anything about Posts until you create a checkpoint
10:23:56 <srhb> mm_freak_: Did I say that? I don't know what that means either :P
10:24:25 <mm_freak_> ah, you said it fails to update your state
10:24:28 <srhb> Probably that my update looks like Update AppState ()
10:24:31 <mm_freak_> so it fails to update /anything/?
10:24:47 <srhb> No, strangely nextPostId seems to get updates
10:24:49 <srhb> but posts does not
10:25:23 <mm_freak_> at runtime?  or doesn't it not log the updates?
10:25:51 <srhb> At runtime. I don't know how to tell if it logs the updates aside from having my runtime display what's stored
10:26:10 <mm_freak_> by looking at the transaction log files
10:26:14 <mm_freak_> they are plaintext
10:26:20 <srhb> Oh.
10:27:27 <srhb> I can check that.
10:27:50 <mm_freak_> could you paste your transaction?
10:27:58 <srhb> When I figure out how :-)
10:28:12 <mm_freak_> no, i mean the transaction code =)
10:28:14 <mm_freak_> not the log
10:28:40 <srhb> Once I clean it up, yes. It's a bit sensitive right now.
10:28:48 <srhb> I'll come back later with it, thank you for the help/.
10:28:59 <mm_freak_> sure
12:53:45 <srhb> I narrowed down the problem. In the initial state, I had posts = ixSet [] rather than posts = empty. Peculiarly, this means silent fail on the first startup of the application (when it creates state/), but in subsequent startups it works fine, only the counter starts at a "wrong place" if it was incremented in the previous startup.
12:55:26 <srhb> and no, makeAcidic does nothing to change the issue. That was my mistake. Bad debugging skills, clearly. :(
13:02:25 <donri> srhb: ixSet [] is an IxSet with no indices
13:02:39 <donri> i agree it's a bit confusing and ixset is lacking in static safety
13:02:49 <srhb> Yes. A type error had been nice. :)
13:03:01 <srhb> It's even more confusing that it works subsequently.
13:03:12 <donri> use tables instead ;)
13:03:16 <srhb> What are tables?
13:03:23 <donri> @hackage tables
13:03:23 <lambdabot> http://hackage.haskell.org/package/tables
13:03:45 <srhb> Since it wasn't in the crash course I assumed it wasn't the Happstack way.
13:04:08 <donri> the crash course predates lens/tables
13:04:11 <srhb> I see.
13:04:17 <srhb> So tables is the way to go now. Thanks.
13:04:23 <srhb> Free lenses? Makes me happy. :)
13:04:55 <donri> also tables is young. quite a bit of boilerplate involved because there's no TH, and a bug that makes certain queries return empty
13:05:03 <srhb> Okay, that's a bit worrying :P
13:05:19 <donri> hopefully the later will resolve soon
13:05:23 <donri> latter
13:05:41 <srhb> Only when ekmett thinks lens is done. Expect that to happen anytime soon? ;)
13:06:36 <donri> FSVO done it's already done
13:06:47 <donri> i think the only bigger plan currently is a TH overhaul
13:07:07 <srhb> Okay. So let me get this straight, I keep acid-state and start storing things in a Table instead of an IxSet?
13:07:18 <donri> yep
13:07:23 <srhb> Alright, I'll have a go at it.
13:07:29 <donri> you can even keep your data because both serialize as lists on disk
13:08:02 <srhb> I don't have any data so I probably won't bother figuring out how to do that just yet :P
13:08:05 <donri> see https://github.com/ekmett/tables/blob/master/examples/Foo.hs
13:08:09 <srhb> Thanks!
13:08:26 <donri> well it has a SafeCopy instance so it does it for you
13:09:01 <srhb> Oh.
13:09:03 <donri> as you see there in Tabular it's a lot more boilerplate than ixset at the moment
13:09:25 <donri> 'fetch' corresponds to the list of 'ixFun', the rest is boilerplate! :D
13:09:25 <srhb> Yes. The example is also lacking comments.
13:09:29 <srhb> Ah.
13:09:41 <donri> yea it's not well documented at the moment
13:09:42 <srhb> Ok, so that's where the type safety comes from.
13:10:25 <donri> well, not really. you could make something very similar to ixset in API with more type safety
13:10:49 <donri> the extra boilerplate in tables is because it has more features, but no TH to generate the boilerplate for you just yet
13:12:30 <srhb> Right. So I'll basically just have to delete the boilerplate later on and replace it with a TH call
13:14:47 <donri> something like that yeah
13:15:15 <donri> or keep the boilerplate. i doubt the manual API would be removed
13:15:50 <donri> my main point is that it's a bit tedious to write your Tabular instance, and a bit tedious to update it adding new indices
13:16:22 <donri> so expect some frustration ;)
13:16:42 <donri> but tables is safer, faster, more featureful and supports lens properly
13:17:28 <srhb> Yeah. Hm. NOt sure I'm ready for the frustration. Then again, this error with IxSet was incredibly frustrating.
13:18:51 <donri> yeah, you could just wait for tables to stabilize a bit. shouldn't be that hard to port ixset code to tables later
13:19:23 <donri> i just did such a port, mostly the code shrank except for the Tabular code vs the previous Indexable
13:19:45 <srhb> *nods*
16:58:50 <stepcut> yeah, that behavior of IxSet is pretty obnoxious.. though, the only behavior of that type that I recall.. it shows up one other way though
16:59:45 <stepcut> you need to make sure that the first index in your ixset exists for all values that could be inserted in the ixset or entries will be silently dropped
17:00:32 <stepcut> IxSet is kind of crappy.. but gets the job done once you know its quirks. Still.. it is surprising that until recently, it was the *only* multi-indexed set type available for Haskell after all these years
17:01:01 <stepcut> now we have tables and data-store as well, but neither are quite done
17:35:12 <srhb> stepcut: Well, even seeing them on the horizon makes me much more happy. That was really icky. :P
17:35:23 <stepcut> yeah
17:35:35 <stepcut> IxSet itself could be also be improved
17:35:50 <srhb> I mean yeah, I fucked up, it was my mistake... But I'm learning Haskell because I know I make mistakes.
17:36:13 <stepcut> there is no reason we could not create a more type-safe interface over the current IxSet implementation.. someone just needs to volunteer
17:36:26 <srhb> Sadly I've no idea where I should start.
17:36:29 <donri> also you wanted fromList [] (or empty, which is the same thing)
17:36:32 <srhb> And it feels like tables is nicer.
17:36:35 <donri> confusing that ixSet [] has the right type though
17:36:44 <srhb> donri: Yes, empty fixed everything.
17:37:14 <srhb> I've no idea where I got the ixSet [] idea from. Really.
17:38:38 <srhb> I might try tables when there's a TH generator, or maybe when there's a more commented example of how to write the instances and what the various things there do.
17:39:36 <donri> srhb: well most of it is mechanical boilerplate that writes itself and you don't need to know why it's there ;)
17:39:50 <srhb> I assume I need to be smart about what to index though.
17:40:39 <donri> sure. you define the types of your indices in the Key data family and the functions to compute the indices with 'fetch'
17:40:53 <donri> the rest is basically boilerplate around that Key type
17:41:04 <srhb> Okay. Doesn't sound too difficult.
17:41:28 <srhb> I should probably understand what a data family is first :P
17:42:40 <donri> type families are to types what type classes are to values
17:42:48 <donri> a data family is just a data type family
17:43:18 <srhb> Aye, I found the haskellwiki page. I'm reading it through.
17:44:12 <donri> also might want to read up on GADTs since they're also used in Tabular
17:44:24 <donri> but, not sure you actually need to understand these things to use tables ;)
17:44:33 <donri> not that it hurts to learn
17:45:33 <srhb> Well, I obviously want to become a Haskell superstar, so a little theoretical background seems nice. :-)
17:46:38 <donri> \o/
18:14:42 <stepcut> maybe I should put hyperdrive on github, and give commit access to tons of people and see what happens
18:15:13 <stepcut> it's like an advertising campaign.. because it keeps showing up in peoples github news feeds
19:09:07 <stepkut> hmm. how do you feel about a look like this for the happstack.com homepage, http://cdn1.1stwebdesigner.com/wp-content/uploads/2012/05/Screen-Shot-2012-05-10-at-3.36.jpg
19:11:19 <donri> looks good, assuming we have useful links in the fat footer and the banner on the front page isn't too random
19:11:46 <bergmark_> no stock photo please:<
19:11:47 <stepkut> another option wouldbe something with white and orange, http://cdn.sixrevisions.com/0148-09_halo.jpg
19:11:58 <stepkut> I don't like that particular design..
19:12:07 <bergmark_> no that one is way too noisy
19:12:18 <stepkut> bergmark_: which one?
19:12:33 <bergmark_> the orange one
19:12:43 <stepkut> the design on the white+orange one is horrid.. but I am wondering about the idea of white + bits of orange
19:12:54 <bergmark_> silk colors :>
19:13:32 <stepkut> still not great but, http://www.net-kit.com/wp-content/uploads/2011/03/create-light-and-sleek-website-template.jpg
19:13:58 <stepkut> white+blue is obviously quite popular.. but that is also what makes it less desirable
19:14:25 <stepkut> personally, i like white+black+green.. but that doesn't mean everyone will :)
19:15:36 <bergmark_> well the color choice isn't that important as long as it matches well
19:16:14 <stepkut> no so sure about that
19:17:35 <bergmark_> i like the apple one the most out of those
19:17:36 <stepkut> "Unarguably one of the most important aspects of any design is its colors. "
19:17:45 <stepkut> yeah, that apple one is pretty nice
19:18:00 <stepkut> I can replace the apple with a fuzzy H :)
19:37:58 <srhb> Happlestack
19:38:28 <srhb> Just make it the codename for the next big release and you can excuse any design choice involving green.
19:38:43 <srhb> Unfortunately it means you'll have to think up colourful word plays for all eternity.
20:19:39 <alpounet> why is there no happstore btw? that should exist.
20:31:02 <bergmark> what's this! fpco are going all alternative http://hackage.haskell.org/package/web-fpco
20:35:15 <donri> i wish they'd have talked to us, i was asking them about that. we could easily add that to happstack-server directly
20:35:50 <stepkut> they did talk to me
20:35:58 <donri> oh
20:36:02 <stepkut> not sure I want to add that to happstack-server directly :)
20:36:03 <donri> nice that they're adding support anyway
20:36:29 <stepkut> As you know, I have been porting the crash course to use pandoc+markdown
20:36:38 <donri> well we could have a envConf or something, doesn't need to be fpco specific
20:37:17 <stepkut> after talking to them, it seems like I should be able to put the new happstack crash course on SoH and make the examples interact, but also be able to still produce a PDF, etc
20:37:26 <donri> cool!
20:38:19 <stepkut> the PORT env variable makes sense for their needs.. but, in general, being able to set only one parameter of your configuration via the environment seems a bit odd
20:38:30 <stepkut> and calling it PORT seems like a really poor choice of names
20:38:45 <donri> do they have an api or such for uploading docs? would be nice to keep things in a darcs repo as well
20:38:55 <stepkut> though I can see how it might be nice to be able to set HAPPSTACK_DEFAULT_PORT, in case 8000 is used for something else on your system
20:39:05 <donri> heh true
20:39:13 <stepkut> I dunno.. I assume they at least have some web form you can POST to
20:39:32 <stepkut> and I am using shake.. so hacking something to POST the pages would be fine
20:39:38 <donri> cool
20:39:54 <stepkut> or maybe SoH can automatically pull from a git repo (a darcs repo would be hoping for too much)
20:40:07 <donri> it's great that they provide this service, but still, it's their proprietary service and with no guarantees really
20:40:08 <stepkut> anyway, I won't have time to investigate more until the end of the week
20:40:14 <stepkut> sure
20:40:20 <donri> so having the docs in darcs as well makes sense methinks
20:40:41 <stepkut> that is why I intend to be able to publish the same docs via other mechanisms as well
20:40:49 <donri> aye
20:40:58 <donri> does this mean happstack is in stackage now? soon?
20:40:59 <stepkut> and I don't intend to sign over the copyrights or anything
20:41:07 <stepkut> it will be, if it is not already
20:41:09 <donri> :)
20:45:59 <alpounet> <bergmark> what's this! fpco are going all alternative http://hackage.haskell.org/package/web-fpco <<< also, having this depend on both happstack-server and snap-core instead of two separate packages or smith, wasn't the best idea ever
20:52:10 <donri> alpounet: not really a problem, it's for stackage which would have both of those already anyway
21:03:33 <levi> Nice, is that web-fpco thing up on their active SoH system now?
21:04:27 <donri> don't think so
21:27:43 <bergmark> stepkut: you need to pull request stackage if you want to be included
22:07:33 <donri> do you still need to build haskell-platform from source to work on stackage
22:10:21 <bergmark> i think so
22:10:31 <bergmark> i didn't get it to build i think.. :P
22:10:46 <bergmark> oh it was probably because of cabal-dev