01:18:44 <jonkri> hey everyone :)
01:20:49 <stepkut> \o/
01:42:41 <Entroacceptor> jonkri_: it's in the middle of the night, don't be so joyous ;)
02:33:31 <jonkri_> Entroacceptor: :D
10:19:29 <donri> Palmik: in empty, storeNextID is 1, why not minBound?
10:19:53 <donri> seems a bit wasteful to skip half the range of int :)
10:32:51 <donri> as for portability i think safecopy serializes int as integer?
10:34:59 <donri> or not sure, that wouldn't help for decoding a 64 bit integer on a 32 bit system... perhaps default nextID to the 32 bit minbound? you could still insert more than maxBound, though
10:41:47 <donri> ...then again, things like ixset are serialized using fromList/toList, so Bounded Int is only a runtime concern
10:42:17 <donri> unless you run out of ints decoding a Store :)
14:55:18 <Palmik> donri, hmm, I guess I could use minBound, yes. Currently I do not check whether i have run out of IDs, not what what the best course of action would be in such case. I do not like the idea of returning "Either" from all function just because of that.
14:56:03 <Palmik> s/not what what the best course/not sure what the best course/
14:56:13 <donri> yea. could just use Integer instead, but that means no Int{Map,Set}
14:58:30 <Palmik> Hmm, I could try that. Right now I'm working on some benchmarks (first for 1D keys (comparison with Map, IntMap, IxSet and HiggsSet)), then I could check how it would impact the performance.
15:03:41 <donri> cool
15:20:22 <donri> intmap is a different data structure underneath than a map int right?
15:21:08 <donri> big-endian patricia trees vs size balanced binary trees
15:21:30 <donri> so, supposedly someone found the performance difference worth it
15:25:45 <donri> btw data-store size claims O(1) but actually calls intmap size which claims O(n)
15:27:06 <Palmik> Hmm, I assumed it was O(1), I will fixt it, thanks.
15:27:44 <Palmik> Yes, they are different underneath, the question is how it would impair data-store.
15:27:47 <donri> you'd think so, but alas, not so!
17:15:58 <Palmik> Hmm, I wonder how I should organize the benchmark. Should I sort it first by method then by container or first by container then by method. The way criterion generates benchmarks, using the first method you can easily compare the relevant performance (lookup/Map and lookup/Store columns will be next to each other, but they will also have the same color).
17:22:02 <Palmik> But that a just a detail.
18:11:23 <donri> i'd say the former, but might depend on the situation
18:12:40 <donri> it seems more interesting to compare individual operations rather than overall performance of each container without a reference point
20:17:28 <donri> stepcut: http://hub.darcs.net/dag/boomerang/patch/20121015201834-6eb02
20:18:03 <stepcut> I fail to understand why that change is good
20:18:38 <donri> explained in the new haddock for derivePP
20:18:56 <donri> we discussed this long ago, you agreed then ;)
20:19:04 <stepcut> hmm
20:19:22 <stepcut> I guess that is sensible
20:20:02 <donri> and IMHO not just nitpicking; i think it's easier to understand what it does this way, and easier to be confused the old way
20:20:17 <stepcut> yeah
20:21:07 <donri> i went with "make" because it's what "lens" calls them; yesod seems to prefer "mk"
20:21:18 <stepcut> and makeAcidic
20:21:32 <donri> ah good point
20:22:52 <donri> i think we also discussed renaming PrinterParser (and thus i suppose this TH function) to something like "Boomerang" as well ...
20:23:03 <donri> perhaps decide on that before releasing this patch!
20:23:26 <donri> makeBoomerangs
20:24:56 <donri> i'm tempted to say i'd like "makeRouters" but that's specific to web-routes-boomerang, really
20:26:46 <stepcut> yeah
20:26:57 <stepcut> I am not pleased with PrinterParser
20:27:15 <stepcut> the name probably predates coming up with the name Boomerange
20:27:21 <stepcut> Boomerang
20:27:22 <donri> ah
20:27:39 <donri> mkZwaluws
20:27:44 <donri> purrrfect
20:27:53 <stepcut> there is also a type called PrinterParser that we would need to change
20:27:59 <stepcut> but might as well change everything at once
20:28:10 <stepcut> and we can still provide a type alias since it is just a rename ?
20:28:22 <donri> yep
20:28:30 <donri> i wonder if you can mark type synonyms DEPRECATED :D
20:29:05 <donri> and yea i meant the PrinterParser type not just the TH function
20:30:18 <donri> "Syntax" is another possible name, in lieu with "invertible-syntax", a PrinterParser defines syntax in both directions
20:30:26 <donri> but i prefer "Boomerang", methinks
20:31:06 <donri> apparently invertible-syntax has a type class it calls Syntax
20:35:51 <donri> stepcut: i'll make a patch renaming to Boomerang?
20:36:00 <stepcut> sounds good
20:44:41 <donri> stepcut: not sure we can back-compat the constructor, though?
20:44:47 <donri> data Boomerang = Boomerang ...
20:45:06 <stepcut> the constructor.. probably not
20:45:16 <stepcut> for application, yes, but not pattern matching
20:45:18 <donri> but not very important anyway, most code will just reference the type?
20:45:34 <stepcut> I was more concerned about the type constructor than the data constructors
20:45:37 <stepcut> yeah
20:55:51 <donri> stepcut: how about making the fixity of <> match the one in base? i'm making it re-export from base if available
20:56:13 <stepcut> or.. maybe we don't need <> now that there is one in base?
20:56:17 <donri> you have infixr 8, base has infixr 6
20:56:19 <stepcut> or are they not compatible?
20:56:40 <donri> well, the one in base is new in 4.5 which is at least ghc 7.2, maybe even 7.4
20:57:03 <stepcut> I am in favor of match base.. I probably copied that fixity from zwaluw
20:57:05 <donri> but they're exactly the same except for the precedence
20:57:18 <donri> will things break horribly though? :)
20:57:38 <stepcut> i don't care, as long as it is more correct :)
20:57:50 <stepcut> plus I want to break some other stuff
20:58:00 <stepcut> well, maybe
20:58:20 <stepcut> we need some way to indicate that a route is successful, even if it does not parse all the segments
20:58:32 <stepcut> for things like serveDirectory, which will use the unconsumed pieces
20:59:39 <stepcut> the 'easy' solution is to make the default be that unconsumed paths are ok, and then you have to add an explicit thing when you want to check that everything was consumed
20:59:57 <stepcut> but, in practice, you generally do want everything consumed, so that is not very friendly
21:00:12 <stepcut> wanting to leave things unconsumed is the special case
21:01:18 <donri> want me to change the source-repo to hub while i'm at it? :)
21:02:38 <stepcut> yup
21:02:46 <stepcut> i thought you did already
21:02:53 <stepcut> I guess that was just for web-routes-th though ;)
21:03:26 <donri> i did it with all web-routes packages, but boomerang is a separate repo
21:04:21 <donri> alright; http://hub.darcs.net/dag/boomerang/changes
21:07:22 <donri> $ runghc Example.lhs
21:07:22 <donri> Text/Boomerang/Combinators.hs:21:0:
21:07:22 <donri>      error: missing binary operator before token "("
21:07:22 <donri> phase `C pre-processor' failed (exitcode = 1)
21:07:31 <donri> is that supposed to work with LANGUAGE CPP?
21:08:16 <stepkut> maybe with, runghc -idist/build/autogen Example.lhs?
21:10:10 <donri> nope
21:10:18 <donri> but it works if I cd out of the boomerang repo
21:10:23 <stepkut> ah
21:10:33 <donri> seems it prefers the Text dir over the ghc-pkg installation
21:12:09 <stepkut> yes
21:12:46 <donri> runghc -i Example.lhs  # works too
21:13:08 <stepkut> :)
21:15:52 <donri> so i've finally figured out that what you meant about generics being runtime vs th being compile-time isn't about type safety but about performance
21:16:01 <donri> with th you hardcode mappings, with generics you translate things at runtime
21:16:34 <donri> but i think generics provide stronger type safety, because th is untyped and also allows you to do basically anything, whereas generics is very narrow in scope
21:16:52 <stepkut> but the generate TH still gets type-checked
21:17:42 <stepkut> but, at the stage where TH is untyped.. things are pretty annoying
21:17:44 <donri> in deed, but it's still wider in scope so it might do something completely unrelated to the task, and also the code generated could depend on parameters, or even arbitrary IO
21:18:00 <stepkut> SPJ said someone should try to figure out how to do it better ;)
21:18:04 <donri> so you could get build failures for TH code that the maintainer/author of the TH code never expected
21:19:04 <donri> well, in the particular case of instance derivation, i say generics is the better how to do it :)
21:20:22 <stepkut> generics or Generics ?
21:20:32 <donri> GHC.Generics
21:20:43 <donri> and -XDefaultSignatures
21:20:50 <stepkut> well.. that is what it is invented for, right ?
21:20:59 <donri> pretty much, yep
21:21:11 <stepkut> so, one would hope it is a better choice :)
21:21:15 <donri> :D
21:22:43 <donri> so i'm hoping to add support to the PathInfo and SafeCopy classes
21:22:57 <donri> but first, i must master generics!
21:23:35 <stepkut> nice
21:24:01 <stepkut> using TH to create instances is certainly a pain
21:25:00 <donri> from a user perspective, using generics might be more painful... LANGUAGE DeriveGeneric, depend on ghc-prim, import GHC.Generics (Generic), derive (Generic), instance Foo Bar
21:25:11 <donri> although we could re-export the Generic class
21:25:45 <donri> that would kill step 2 and 3
21:27:39 <donri> on the other hand, I like writing, instance SafeCopy Thing where version = 2; kind = extension, instead of, deriveSafeCopy 2 ''extension ''Thing
21:27:46 <donri> 'extension, even
21:28:09 <stepkut> yeah
21:28:15 <stepkut> that would be nice
21:28:32 <donri> a small win could also be that it's easier to refactor into a custom SafeCopy instance if ever you want to
21:28:34 <stepkut> then people wouldn't complain about it using template haskell ;)
21:28:44 <donri> and that! mission critical!
21:28:51 <stepkut> !
21:29:02 <donri> (...then they start to whine about generics...)
21:29:19 <stepkut> whiners gotta whine
21:34:40 <donri> also: generics work under -XSafe, TH doesn't. could be useful for things like clckwrks plugins
21:35:26 <donri> and: generics are type checked with -fno-code, whereas TH isn't run at all. that flag is useful in IDEs and editors
21:35:36 <stepkut> ooo
21:35:40 <stepkut> fun
21:36:51 <donri> they also say TH compiles slow, but sadly DeriveGeneric is also slow :(
21:37:03 <stepkut> :)
21:42:04 <stepkut> boomerang is on hub.darcs.net now, btw
21:45:01 <donri> fork you, i did!
21:46:25 <stepkut> :)