09:16:30 <Lemmih> yay, new version of safecopy.
09:56:05 <HugoDaniel> :D
14:10:52 <stepcut> Lemmih: what's better about it ?
14:14:50 <Lemmih> stepcut: You can derive SafeCopy even when using TypeFamilies.
14:15:18 <Lemmih> We're using SafeCopy + TypeFamilies at work and it annoyed the hell out of me.
14:16:31 <Lemmih> *sigh* The new bytestring builder is so neat. I hope I can get to use it soon.
14:23:53 <Lemmih> Slow code: 0.56s
14:24:04 <Lemmih> Queue: 0.34s
14:24:09 <Lemmih> Optimal: 0.10s
14:25:39 <Lemmih> Slow code: 4.63G allocated
14:25:55 <Lemmih> Queue: 0.92G allocated
14:26:18 <Lemmih> Optimal: 0.35G allocated
15:45:08 <stepcut> heh
16:15:51 <Palmik> Hi, I was thinking about the query interface. There are two approaches that come to mind: (1) either the user will wrote somthing like (Proxy :: Proxy UserAge) @> 'some value approriate type' (2) or this UserAge @> 'some value of approriate type'. The seond one looks better, but it has some disadvantages. In (1) UserAge is type synonym for type level natural number, in (2) UserAge is contructor of new type (like data UserAge = UserAge) that has the
16:15:52 <Palmik> type level natural associated with it.
16:17:41 <Palmik> So in (1) user does not have to deal with possibly confusing extensions but the interface is not as clean (you could do something like sUserAge = Proxy :: Proxy (S (S .. Z)) though), in (2) the user has to define some type family instances to get (probably) cleaner API.
16:21:28 <Palmik> I will probably use the (1) internally, since one can easily add the (2) approach on top of that.
16:21:40 <Palmik> So in the end, I can easily offer both interfaces.
16:48:26 <stepkut> Palmik: neat!
17:01:38 <donri> Palmik: if you're using proxies, maybe use the tagged package
17:02:10 <stepkut> yeah
18:22:10 <stepkut> hmm. readFromFay does not seem to be working correctly
18:38:40 <evancz> hello?
18:39:07 <evancz> I am curious about serving files based on their absolute path
18:39:25 <evancz> specifically, my package needs to serve a .js file with every request
18:39:43 <evancz> the .js file is in some far off corner of cabal
18:39:59 <evancz> how do I refer to the file?
18:51:16 <donri> stepcut: https://plus.google.com/110988559818762092753/posts/V9EuZGkGbqh anything to add?
18:56:21 <donri> evancz: are you shipping the js file with your cabal package?
18:56:35 <evancz> with a related package
18:56:45 <evancz> so the js file is the runtime system of Elm
18:56:51 <evancz> so packaged with Elm package
18:56:57 <donri> ah right you're the Elm guy :)
18:57:00 <evancz> it needs to get served from elm-server
18:57:03 <evancz> yep :)
18:57:10 <evancz> hello!
18:57:30 <donri> i think you'd need to export the Paths_elm API in some way or another
18:57:43 <evancz> yeah, i've got that going already
18:57:52 <donri> either by making it an exposed-module, or by exporting some wrapper API from an exposed module
18:57:53 <evancz> the elm compiler actually uses it
18:58:22 <evancz> the trouble is that when I go to serve the file obtained through Paths_elm, it is an absolute path
18:58:36 <evancz> and Chrome (at least) does not know what to do with it
18:59:49 <donri> ah, you probably want to use serveFile or serveDirectory
19:00:12 <evancz> they will know what to do with an absolute path?
19:00:31 <alpounet> donri, yay for the hub.darcs.net link :p
19:00:34 <donri> certainly
19:00:46 <donri> absolute path is probably better than relative, even
19:00:56 <alpounet> but i found Liam's comment a bit agressive and not necessarily correct
19:01:26 <evancz> ok, cool!
19:01:29 <evancz> I'll give it a try
19:01:46 <evancz> I am using serveDirectory now, but I have some weird logic in the way
19:01:58 <evancz> I'll report back in a bit :)
19:02:10 <donri> bbl dinner
19:03:23 <evancz> ok, later!
19:20:19 <evancz> yay, got it working!
19:20:22 <evancz> Thanks a lot!
21:58:52 <dcoutts_> Lemmih: glad you like the new bytestring builder monoid
21:59:45 <stepkut> will switching to binary help improve the error messages when you forget to create a migration instance?
22:02:37 <Lemmih> Nope.
22:02:55 <Lemmih> Aren't the error messages pretty good?
22:04:13 <Lemmih> They should be something like: Found a <type> of version <version> but I don't know about that particular version.
22:04:18 <stepkut> no, they are horrible
22:04:53 <Lemmih> Oh, you mean when you edit a datatype without keeping the old version around?
22:05:08 <stepkut> yeah, when you screw up
22:05:36 <stepkut> you have hundreds of datatypes and an error that says something useless like, 'unexpected end of input' or something
22:05:53 <stepkut> given zero clue as to which type got fowled up
22:06:15 <Lemmih> Well, maybe you shouldn't screw up, then.
22:06:17 <stepkut> Main: too few bytes
22:06:17 <stepkut> From:	demandInput
22:06:19 <Lemmih> Easy fix.
22:06:27 <stepkut> no.. that fix is really hard
22:06:38 <stepkut> if I didn't screw up I wouldn't need a type system and could just use python :p
22:07:24 <Lemmih> Yeah, types are stupid as well. That's why I use unsafeCoerce in acid-state.
22:07:27 <stepkut> seems like cereal could do a better job reporting the error, and then safecopy could catch that exception and rethrow it with more context, and acid-state could do the same?
22:07:51 <Lemmih> Hm.
22:08:09 <Lemmih> Can we add state or a writer to the parser?
22:08:16 <Lemmih> And get a stack-trace that way.
22:11:47 <Lemmih> Hm.
22:12:06 <Lemmih> I know a way. I think.
22:12:28 <Lemmih> Fret not, dear underling. I will take care of this.
22:12:37 <stepkut> awesome!
22:13:09 <stepkut> it's the #1 complaint I get about acid-state from active users
22:13:46 <stepkut> people that don't use it have different concerns :)
22:13:56 <Lemmih> We have active users?
22:15:42 <stepkut> yup
22:16:05 <stepkut> pretty soon nearly all Haskell users will be indirect users :)
22:17:18 <Lemmih> Yes, yes. The plan is unfolding.
22:17:38 <stepkut> :)
22:17:54 <Lemmih> soon they will all be under our control! Mwuhahaha!
22:18:08 <stepkut> =)
22:19:21 <alpounet> well, the haskell world kind of relies on acid-state
22:19:25 <alpounet> cf hackage2
22:23:14 <donri> alpounet: yea that's what they're laughing evilishly about