2016-12-07 09:58:42 +0000ircbrowse(~chrisdone@unaffiliated/chrisdone)
2016-12-07 10:04:17 +0000 <refold> given that phaskell/chatlog died again, there's now http://ircbrowse.net/browse/hackage
2016-12-07 10:18:50 +0000 <refold> for old logs, go to https://phabricator.haskell.org/chatlog/channel/4/
2016-12-07 10:56:11 +0000mpickering(sid78412@gateway/web/irccloud.com/x-kpadwynjljraqlfb) ()
2016-12-07 10:56:41 +0000mpickering(sid78412@gateway/web/irccloud.com/x-gwnxrohkvwhidduo)
2016-12-07 12:43:00 +0000phadej_phadej
2016-12-07 13:37:58 +0000edsko(~quassel@23.27.206.197) (Ping timeout: 245 seconds)
2016-12-07 17:14:08 +0000edvorg(~edvorg@host-46-50-214-114.bbcustomer.zsttk.net)
2016-12-07 17:28:19 +0000 <ezyang> hvr: Because whenever I edit a cabal file, the tooling is too dumb to know which part of the cabal file I edited, and reruns depsolving
2016-12-07 17:36:29 +0000 <hvr> refold: so I guess I should be more careful when I bash Stack? ;-)
2016-12-07 17:37:08 +0000 <hvr> ezyang: tbh, that doesn't sound like a showstopper to me
2016-12-07 17:37:14 +0000 <refold> hvr: can't remember you doing it in this channel actually :-)
2016-12-07 17:37:29 +0000 <hvr> refold: you're not always present =)
2016-12-07 17:38:30 +0000 <ezyang> it's not. But it's really annoying
2016-12-07 17:38:34 +0000 <hvr> ezyang: that feature would mostly intersting to auto-gen'ed packages like amazonka, haskell-gi etc
2016-12-07 17:38:58 +0000 <hvr> or other complex packages which have already enough annoyances to cope with
2016-12-07 17:43:47 +0000 <ezyang> sure...
2016-12-07 17:44:06 +0000 <ezyang> unrelated to this: I'm experimenting with a new style of writing CPP code which maximizes the amount of code that gets typechecked by the compiler
2016-12-07 17:44:20 +0000 <ezyang> but I'm trying to decide how to handle FFI definitions
2016-12-07 17:44:43 +0000 <ezyang> what I would like is to declare the top-level type of the declaration (e.g., nsGetEnviron :: IO (Ptr (Ptr OSString)))
2016-12-07 17:45:04 +0000 <ezyang> and then later either give a foreign import, or specify it as undefined, but that's not allowed
2016-12-07 17:45:53 +0000 <ezyang> so I have two options: (1) push the type signature inside the ifdef (then you have to keep it synchronized), or (2) give the FFI import a different name, and then set nsGetEnviron = nsGetEnviron', keeping type outside
2016-12-07 17:46:18 +0000 <ezyang> illustration of second approach: http://lpaste.net/349636
2016-12-07 17:46:22 +0000 <ezyang> Question: is this too weird?!
2016-12-07 18:05:20 +0000 <alanz> ezyang: " the tooling is too dumb to know which part of the cabal file I edited": why not store a simple parsed representation of it, then check for each target in the file if anything has changed? Or is that too simplistic?
2016-12-07 18:06:23 +0000 <hvr> ezyang: been there myself btw :-)
2016-12-07 18:08:04 +0000 <ezyang> alanz: It's a good idea
2016-12-07 18:08:21 +0000 <ezyang> the current recomp framework is... too dumb to be able to handle this. Shake would handle it transparently
2016-12-07 18:12:04 +0000slackircbot(~nobody@ec2-52-23-198-104.compute-1.amazonaws.com) (Remote host closed the connection)
2016-12-07 18:12:07 +0000hvr(~hvr@haskell/developer/hvr) (Remote host closed the connection)
2016-12-07 18:12:07 +0000slackircbot(~nobody@ec2-52-23-198-104.compute-1.amazonaws.com)
2016-12-07 18:15:32 +0000hvr(~hvr@h081217016230.dyn.cm.kabsi.at)
2016-12-07 18:15:32 +0000hvr(~hvr@h081217016230.dyn.cm.kabsi.at) (Changing host)
2016-12-07 18:15:32 +0000hvr(~hvr@haskell/developer/hvr)
2016-12-07 18:19:48 +0000 <alanz> ezyang: the stored info might help tools like ghc-mod too
2016-12-07 19:13:52 +0000edvorg(~edvorg@host-46-50-214-114.bbcustomer.zsttk.net) (Ping timeout: 265 seconds)
2016-12-07 20:39:08 +0000hamishmack(~hamishmac@121.73.30.206) (Quit: hamishmack)
2016-12-07 20:40:35 +0000refold(~refold@188.172.147.158) (Remote host closed the connection)
2016-12-07 20:44:05 +0000yhhko(~tulcod@unaffiliated/tulcod)
2016-12-07 21:48:13 +0000hamishmack(~hamishmac@202-21-137-106.wlgcl1.acsdata.co.nz)
2016-12-07 22:24:02 +0000yhhko(~tulcod@unaffiliated/tulcod) (Quit: Leaving)
2016-12-07 23:32:41 +0000edsko(~quassel@23.27.206.197)
2016-12-07 23:37:33 +0000ddere(uid110888@gateway/web/irccloud.com/x-sfcufwxeybiieufe)
2016-12-07 23:40:13 +0000danpalmer(uid121480@gateway/web/irccloud.com/x-bsxbyrbutdehojgr)
2016-12-07 23:46:09 +0000edsko(~quassel@23.27.206.197) (Remote host closed the connection)
2016-12-08 00:47:25 +0000begriffs(~begriffs@104.156.228.70)
2016-12-08 01:42:49 +0000danpalmer(uid121480@gateway/web/irccloud.com/x-bsxbyrbutdehojgr) (Quit: Connection closed for inactivity)
2016-12-08 02:02:56 +0000edsko(~quassel@23.27.206.197)
2016-12-08 02:25:19 +0000hamishmack(~hamishmac@202-21-137-106.wlgcl1.acsdata.co.nz) (Read error: Connection reset by peer)
2016-12-08 02:41:19 +0000begriffs(~begriffs@104.156.228.70) (Quit: Leaving...)
2016-12-08 02:41:29 +0000refold(~refold@188.172.156.156)
2016-12-08 03:44:24 +0000hamishmack(~hamishmac@121.73.30.206)
2016-12-08 03:57:38 +0000lspitzner(~lspitzner@p4FCCD039.dip0.t-ipconnect.de) (Ping timeout: 264 seconds)
2016-12-08 03:58:30 +0000hexagoxel(~hexagoxel@p200300798F207100021E33FFFE2231E9.dip0.t-ipconnect.de) (Ping timeout: 258 seconds)
2016-12-08 03:59:58 +0000lspitzner(~lspitzner@p200300798F1D4500021E33FFFE2231E9.dip0.t-ipconnect.de)
2016-12-08 04:04:00 +0000hexagoxel(~hexagoxel@p4FCCDED9.dip0.t-ipconnect.de)
2016-12-08 04:47:02 +0000dcoutts_implements "cabal new-* all" target syntax
2016-12-08 04:47:14 +0000 <dcoutts_> e.g. cabal new-build all, new-test all etc
2016-12-08 04:47:40 +0000 <dcoutts_> hvr: adding unit-id syntax would be quite doable
2016-12-08 04:48:12 +0000 <dcoutts_> happy with "cabal new-build unitid:thelongunitidname-x8402e7a5c812... " ?
2016-12-08 04:48:21 +0000 <dcoutts_> ie unitid as a namespace qualifier
2016-12-08 04:48:44 +0000 <dcoutts_> since there does not need to be a convenient short form in that case
2016-12-08 04:51:00 +0000 <ezyang> is thelongunitidname-x8402e7a5c812 a valid component name? it is right?
2016-12-08 04:58:35 +0000 <dcoutts_> ezyang: I believe so yes
2016-12-08 04:58:59 +0000 <dcoutts_> or indeed a package name
2016-12-08 04:59:49 +0000 <dcoutts_> ezyang: so yes in principle 'unitid:thelon...' is ambigious with a package named 'unitid' containing a component 'thelon...'
2016-12-08 04:59:54 +0000 <ezyang> yeah...
2016-12-08 04:59:57 +0000 <dcoutts_> but we have way of handing that
2016-12-08 05:00:24 +0000 <dcoutts_> the strategy for all these things is ever longer and more pedantic qualification
2016-12-08 05:00:52 +0000 <ezyang> dcoutts_: I think for a machine programmable interface, it's important for the common use case to also be unambiguous in all situations
2016-12-08 05:00:58 +0000 <dcoutts_> and the target cli code knows when things are actually ambigious and will suggest all the alternatives
2016-12-08 05:01:09 +0000 <ezyang> less important for user interface, but very important when people program, because that translates into intermittent failure
2016-12-08 05:01:19 +0000 <dcoutts_> ezyang: yes it's important that there be a most-qualified form that tools can use
2016-12-08 05:01:35 +0000 <dcoutts_> but I don't think that has to be the same as the short forms that humans want to use for convenience
2016-12-08 05:01:53 +0000 <ezyang> dcoutts_: Well, I think there's an important social component
2016-12-08 05:02:12 +0000 <dcoutts_> this is a matter of documentation I think, to make clear what the cumbersome fully-qualified syntax is
2016-12-08 05:02:14 +0000 <dcoutts_> for tools
2016-12-08 05:02:15 +0000 <ezyang> because humans tend to use what they know
2016-12-08 05:03:05 +0000 <dcoutts_> ezyang: I'm not sure what you're suggesting exactly
2016-12-08 05:03:13 +0000 <ezyang> Like, can you seriously say with a straight face, that no one is ever going to use the short easy human-readable syntax from a script?
2016-12-08 05:03:27 +0000 <dcoutts_> no I can't say that
2016-12-08 05:03:51 +0000 <dcoutts_> but does that mean I think it's worth forcing everyone all the time to use more long-winded forms?
2016-12-08 05:03:56 +0000 <dcoutts_> well no
2016-12-08 05:04:44 +0000 <ezyang> yeah, so I don't have concrete suggestions
2016-12-08 05:05:26 +0000 <ezyang> OK, maybe I do
2016-12-08 05:05:32 +0000 <ezyang> which is to syntactically distinguish between the forms
2016-12-08 05:06:38 +0000 <dcoutts_> but that is forcing people to add distinctions in the typical case when they're not necessary
2016-12-08 05:06:57 +0000 <dcoutts_> e.g. a hypothetical syntax @foo vs $foo for example
2016-12-08 05:07:00 +0000 <dcoutts_> rather than just foo
2016-12-08 05:07:08 +0000 <dcoutts_> for a package or component named that
2016-12-08 05:07:18 +0000 <dcoutts_> or indeed a directory or module
2016-12-08 05:08:22 +0000 <dcoutts_> the argument a user would make is: why do you make me write stuff that can be inferred automatically
2016-12-08 05:09:05 +0000 <dcoutts_> and they will likely not look very kindly on us saying "oh but what if you wrote a script and didn't think about it"
2016-12-08 05:09:45 +0000 <ezyang> well, if we're on the subject
2016-12-08 05:09:51 +0000 <ezyang> why bother asking the user to write unitid: at all
2016-12-08 05:10:21 +0000 <dcoutts_> oh well, unitid is not needed by "real" users, only hvr's scripts
2016-12-08 05:10:39 +0000 <dcoutts_> so it doesn't need a convenient short form
2016-12-08 05:10:43 +0000 <ezyang> I think there is utility to being able to look at a string identifier and being able to tell what it is denoting, without any extra info
2016-12-08 05:10:58 +0000 <dcoutts_> there is utility in that
2016-12-08 05:11:15 +0000 <dcoutts_> but it has to be balanced against the fact that users have to type these things all the time