Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 .. 5022
— 502,152 events total
2020-11-11 10:11:03 <merijn> Because now anything that functions can't be turned into is ruled out
2020-11-11 10:11:25 <merijn> bqv: Category is in that sense more interesting
2020-11-11 10:11:33 <merijn> :t (Control.Category..)
2020-11-11 10:11:34 <lambdabot> forall k (cat :: k -> k -> *) (b :: k) (c :: k) (a :: k). Category cat => cat b c -> cat a b -> cat a c
2020-11-11 10:11:38 <merijn> oof
2020-11-11 10:11:46 <merijn> I forgot about the kind polymorphism
2020-11-11 10:11:54 <bqv> Ha
2020-11-11 10:11:58 <merijn> Pretend everything before the . is missing ;)
2020-11-11 10:12:03 <bqv> Very generic
2020-11-11 10:12:04 <merijn> :t Control.Category.id
2020-11-11 10:12:05 <lambdabot> forall k (cat :: k -> k -> *) (a :: k). Category cat => cat a a
2020-11-11 10:12:15 <dminuoso> asheshambasta: So ghc-pkg is the database for "available packages"
2020-11-11 10:12:23 <dminuoso> you can register packages there, etc
2020-11-11 10:12:37 <dminuoso> it's how manual ghc and cabal v1- worked
2020-11-11 10:12:39 × alp quits (~alp@2a01:e0a:58b:4920:7dab:bd6a:30b1:7abd) (Ping timeout: 272 seconds)
2020-11-11 10:12:45 <merijn> so you have (simplified): 'id :: Category cat => cat a a' and '(.) :: Category cat => cat b c -> cat a b -> cat a c'
2020-11-11 10:13:10 <dminuoso> cabal v2- still uses this interface, but instead of maintaining this "global package database", cabal v2- generates a sort of transient package database based on its build plan, and tells ghc to use that instead.
2020-11-11 10:13:10 <merijn> bqv: That's like half the composition stuff of Arrow, without needing to support functions
2020-11-11 10:13:23 <bqv> Yeah, that makes sense
2020-11-11 10:13:37 <dminuoso> asheshambasta: it seems as if the build planning consults ghc-pkg, which I think is strange because you're using new-style
2020-11-11 10:13:40 <merijn> bqv: Do you know about contravariant functors?
2020-11-11 10:13:52 <bqv> Yeah, via profunctors
2020-11-11 10:14:26 × coot quits (~coot@37.30.49.253.nat.umts.dynamic.t-mobile.pl) (Remote host closed the connection)
2020-11-11 10:14:31 → coco joins (~coco@212-51-146-87.fiber7.init7.net)
2020-11-11 10:14:34 <merijn> bqv: Right, so profunctors are basically contravariant on one side and functors on the other side (which also mirrors a bunch of Arrow stuff, but again, without 'arr')
2020-11-11 10:15:06 <merijn> bqv: So you can get most (all?) of the functionality of Arrow by mixing Category + Profunctor, but now you don't have to deal with that PITA 'arr'
2020-11-11 10:15:14 × raichoo quits (~raichoo@213.240.178.58) (Quit: Lost terminal)
2020-11-11 10:15:32 <bqv> Neat. So it's totally deprecated
2020-11-11 10:15:37 → coot joins (~coot@37.30.49.253.nat.umts.dynamic.t-mobile.pl)
2020-11-11 10:16:03 <merijn> Aside from some niche FRP libraries I don't think any modern/widely used library uses it
2020-11-11 10:16:23 <dminuoso> asheshambasta: out of curiosity, if you use v2-repl instead of new-repl, does it still give the same errors?
2020-11-11 10:16:47 <bqv> Heh
2020-11-11 10:17:54 <asheshambasta> dminuoso: seems like it, yeah
2020-11-11 10:18:30 → Aquazi joins (uid312403@gateway/web/irccloud.com/x-gthhcxtxtvdrftco)
2020-11-11 10:19:03 <dminuoso> asheshambasta: Seems like that's the regular behavior then
2020-11-11 10:19:09 <dminuoso> asheshambasta: do you use cabal v1- anywhere?
2020-11-11 10:21:32 <dminuoso> asheshambasta: Anyhow. As an immediate hotfix, nuke/rename your ~/.ghc/{version}/environments/
2020-11-11 10:21:40 <dminuoso> And stop using cabal v1- I guess
2020-11-11 10:21:58 <dminuoso> It's possible there is a more eloquent hotfix, possibly via cabal.project.local where you specify a custom package.db
2020-11-11 10:23:01 × Sanchayan quits (~Sanchayan@122.181.216.76) (Quit: leaving)
2020-11-11 10:23:22 <dminuoso> Im not actually sure what the right thing is, whether this is a bug, etc. At the very least I'd perhaps file an issue on cabal for documentation.
2020-11-11 10:23:53 <dminuoso> (Naively it seems unreasonable for cabal v2-* to consider the ghc-pkg database for its build plan)
2020-11-11 10:24:06 <dminuoso> It does so in 3.2.0.0 as well, I checked.
2020-11-11 10:24:39 <dminuoso> Because by doing so, it's not really nix-style. cabal should *dictate* the package.db, not amend it.
2020-11-11 10:25:08 → LKoen joins (~LKoen@77.174.9.109.rev.sfr.net)
2020-11-11 10:25:27 <merijn> dminuoso: Actually, v2 *intentionally* disregards the package database
2020-11-11 10:25:35 <dminuoso> merijn: evidently not?
2020-11-11 10:25:39 <merijn> v1 used to consider it
2020-11-11 10:26:02 <dminuoso> `cabal v2-build` specifically interrogates ghc-pkg before build planning
2020-11-11 10:26:07 <dminuoso> Just run with -v3 in your projects and see
2020-11-11 10:26:32 <merijn> The fact that it consults it doesn't mean it's used for buildplan resolution
2020-11-11 10:27:32 <asheshambasta> dminuoso: should running `cabal v2-update` have an adverse effect on the system as a whole within `nix-shell`?
2020-11-11 10:27:40 <dminuoso> asheshambasta: yeah
2020-11-11 10:27:43 <asheshambasta> It seems like the packages that used to build earlier no longer build for me
2020-11-11 10:27:47 × bitmagie quits (~Thunderbi@200116b8060ca30071501286c6dd94a1.dip.versatel-1u1.de) (Quit: bitmagie)
2020-11-11 10:27:49 × mmohammadi9812 quits (~mmohammad@80.210.53.226) (Ping timeout: 264 seconds)
2020-11-11 10:27:55 <dminuoso> asheshambasta: two things:
2020-11-11 10:28:04 <dminuoso> a) that means you were lazy on your constraints
2020-11-11 10:28:11 <dminuoso> b) cabal told you how to restore to the old index state
2020-11-11 10:28:35 <dminuoso> (when you ran `cabal v2-update`)
2020-11-11 10:28:44 → mmohammadi9812 joins (~mmohammad@5.117.38.198)
2020-11-11 10:29:03 <asheshambasta> dminuoso: what can be done to fix it?
2020-11-11 10:29:10 <tomsmeding> b)
2020-11-11 10:30:05 <dminuoso> merijn: you're right though, Im making an educated guess that this is the cause
2020-11-11 10:30:12 <asheshambasta> dminuoso: well, I ran `nix-shell --run 'cabal v2-update'` and then upon realising that this could cause issues, I killed it before it finished. It seems it had enough time to do some damage.
2020-11-11 10:30:32 <dminuoso> merijn: but the fact that ghc-pkgs happens to list two entries for http-types, and the fact that the solver keeps talking about "installed-" packages..
2020-11-11 10:30:37 <dminuoso> It's an educated guess.
2020-11-11 10:30:55 <asheshambasta> dminuoso, tomsmeding: for `b`, what can be done? Cabal doesnt' seem to be telling me how to restore the old state.
2020-11-11 10:31:04 <dminuoso> asheshambasta: you should have let it run its course.
2020-11-11 10:31:18 <dminuoso> asheshambasta: try running it again, and see if cabal state is healthy enough to report how to revert it
2020-11-11 10:31:31 <dminuoso> if not, you have to bite the bullet and update your constraints
2020-11-11 10:31:37 <dminuoso> but, you should be doing this anyway :)
2020-11-11 10:31:49 <asheshambasta> or maybe this is unrelated though, I can run `nix-shell --run 'cabal new-repl' ` in other packages, just not in ~/.xmonad anymore (cannot find xmonad-contrib for some reason)
2020-11-11 10:32:41 <asheshambasta> What does cabal v2-update do exactly? It seems to be calling hackage to update some index, but within a nix environment, do you want it to talk to hackage directly?
2020-11-11 10:33:08 <dminuoso> asheshambasta: the nix-shell merely provides cabal-install the binary
2020-11-11 10:33:13 <dminuoso> beyond that, there's nothing nixy about it
2020-11-11 10:34:08 <tomsmeding> where does cabal even store the previous index states
2020-11-11 10:34:30 <merijn> tomsmeding: It doesn't, the index is append only
2020-11-11 10:34:37 <merijn> tomsmeding: So storing the previous index makes no sense
2020-11-11 10:34:55 <merijn> tomsmeding: You can just "ignore the last part of the index" and achieve the same effect
2020-11-11 10:35:03 <tomsmeding> makes sense
2020-11-11 10:35:09 <dminuoso> asheshambasta: so there's two thoughts here:
2020-11-11 10:35:21 <merijn> tomsmeding: In fact, that's literally what the index-state entry in cabal.project does :p
2020-11-11 10:35:33 <merijn> It simply skips all entries after a certain timestamp
2020-11-11 10:35:45 <tomsmeding> can't you then run the cabal update command with a random timestamp just before the concerned update command
2020-11-11 10:35:54 <dminuoso> asheshambasta: either you want nix, but then you have to use `nix` instead of `cabal-install`. Then you could use callCabal2nix with shellFor (giving you interactive shells)
2020-11-11 10:36:24 <dminuoso> asheshambasta: Or you want to do this with cabal. In order to get semi-deterministic builds, you have to either pin all versions - or if you're fine with automatic PVP conform updates, keep PVP conform package version constraints.
2020-11-11 10:36:42 <dminuoso> If you maintain clean version constraints, `cabal v2-update` is fine
2020-11-11 10:36:57 <dminuoso> (A good mind model could be to regularly run `cabal v2-update`, forcing yourself to adhere to proper constraints.
2020-11-11 10:37:06 <dminuoso> And if your dependencies suck in that regard, dont use brittle dependencies.
2020-11-11 10:37:52 <bqv> The nix shell might be a haskell shell, in which case all remote stores will be disabled in cabal
2020-11-11 10:38:02 <dminuoso> bqv: no
2020-11-11 10:38:14 <dminuoso> nix-shell merely sets up an environment with packages present.
2020-11-11 10:38:39 <bqv> dminuoso: and environment variables
2020-11-11 10:38:46 <dminuoso> Say `nix-shell -p ghc` ensures that you have a shell with a ghc in path. Roughly, nix-shell will synthesize a bin/ directory, containing symlinks to /nix/store
2020-11-11 10:38:56 <dminuoso> And put that bin/ directory onto your PATH
2020-11-11 10:39:05 <dminuoso> (There's a few more involved things, but roughly that's the extend of it)
2020-11-11 10:39:18 <bqv> Don't forget the environment variables. Enter a ghc shell, it sets NIX_GHC etc.
2020-11-11 10:39:28 <dminuoso> If you want *pinning*, you have to go the nix + callCabal2nix + shellFor route
2020-11-11 10:39:40 <bqv> Thats what I meant
←Prev  Next→
Page 1 .. 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 .. 5022

All times are in UTC.