proofofkeags_ has quit [Ping timeout: 260 seconds]
gluegadget has quit [Ping timeout: 260 seconds]
hamishmack has quit [Read error: Connection reset by peer]
dmj` has quit [Read error: Connection reset by peer]
hamishmack has joined #haskell.nix
gluegadget has joined #haskell.nix
dmj` has joined #haskell.nix
dmj` has quit [Excess Flood]
dmj` has joined #haskell.nix
hekkaidekapus has quit [Ping timeout: 240 seconds]
hekkaidekapus has joined #haskell.nix
codygman has joined #haskell.nix
codygman has quit [Ping timeout: 268 seconds]
codygman has joined #haskell.nix
codygman has quit [Ping timeout: 240 seconds]
codygman has joined #haskell.nix
acarrico has quit [Ping timeout: 240 seconds]
<typetetris>
michaelpj: I use `strings` to check that I guess its in the rpath somehow. Need to research how to extract and display the rpath stuff from an executable again.
<typetetris>
BTW: is nix-tools repository still part of the whole thing?
<angerman>
typetetris: rpath on macOS or linux?
<angerman>
otool will do on macOS
<angerman>
technically mach-o containers. readelf can display them for elf containers I think. Not sure if ldd (or lld?) will show the rpath values.
<typetetris>
`readelf -d` did it for me.
<typetetris>
michaelpj: To get a materialized `hoogle` for `shellFor`: One way could be to create a new argument `hoogle` (or some such) to `shellFor` which is then handed to the `hoogleLocal` call inside shell-for.nix as `hoogle` argument. At the moment the `hoogle` parameter of `hoogleLocal` has the value `pkgs.buildPackages.haskell-nix.tool compiler.nix-name "hoogle"`.
<typetetris>
or as a quick fix, just include a materialization of that. It doesn't need to be build with the projects choosen compiler, does it?
<typetetris>
or simply it `tools` contain `hoogle` just use that.
<typetetris>
I will provide a pr for that.
<michaelpj>
typetetris: yeah, at least making it overridable is sensible
<michaelpj>
I don't know if it needs to use the project's GHC, but generally we do that to avoid you having to download more GHCs than you might expect ;)
<typetetris>
Yes. What do you think about just taking the hoogle provided in `tools` for `shellFor`?
<typetetris>
So if `hoogle` present in `tools` use that otherwise the default?
<michaelpj>
in a way that makes sense, since it is a shell tool, but it's a bit "action at a distance" for my taste. You make `hoogle` materialized by adding it in some *other* place?
<michaelpj>
also, I'm looking at how the hoogle stuff is set up, and it is.... not the way I would have expected
<michaelpj>
it imports some hoogle Nix definition from nixpkgs???
<michaelpj>
oh, at least the definition of the hoogle package is via haskell.nix
<typetetris>
Yes, but that is just an expression, that creates a hoogle db with the hoogle provided as an argument to that expression.
<michaelpj>
yeah, it's not as wild as I first thought
<typetetris>
It would be great to have the same ease of use, like the tools thing. So I would take the value of the `hoogle` parameter and use it with `haskell-nix.tool`. If one really needs to provide his own patched version of hoogle, a separate parameter could be added, I think.
fendor has joined #haskell.nix
<typetetris>
Is there a contributer guideline? For example about formatting? Or just use nixpkgs-fmt?
<typetetris>
nope, no nixpkgs-fmt
<angerman>
typetetris: it's pretty loose. If there's format related issues to be addressed someone will point them out in review. Quite unlikely though.
__monty__ has joined #haskell.nix
<__monty__>
Is there a way to add an upper bound on a dependency of a hackage-package?
<typetetris>
Can I build the docs in local checkout of haskell.nix to see how my changes look?
<__monty__>
Hmm, actually, the package on hackage has already been revised. Does haskell.nix not respect revisions?
codygman has quit [Read error: Connection reset by peer]
codygman has joined #haskell.nix
fendor_ has joined #haskell.nix
fendor_ has quit [Client Quit]
<__monty__>
My index-state is newer than when the package was revised so it *should* respect the revision, no?
codygman has quit [Ping timeout: 240 seconds]
<michaelpj>
yes
codygman has joined #haskell.nix
<__monty__>
Hmm, what's my first step in troubleshooting this? I guess I'll try without passing index-state.
<michaelpj>
__monty__: does it work in cabal?
<__monty__>
Nope, didn't help, so I'm not incapable of comparing dates, good to know.
<michaelpj>
always step 1 :)
<__monty__>
Hmm, I haven't installed a package using cabal for ages. How do I install something from hackage? v2-install claims I haven't specified a package server.
<michaelpj>
uhm
<__monty__>
I'll just add it as a dep of a project.
<michaelpj>
I mean does your project build with cabal, or does it complain about the bounds issue?
<__monty__>
It's not my project, just a package on hackage.
<michaelpj>
oh I see
<michaelpj>
are you passing `index-state` to `hackage-package`? If so, and it's after the revision, I would expect the revision to take account
<__monty__>
Yes I am, and it doesn't seem to be respecting the constraint. It's selecting strict 0.4.
<michaelpj>
*be taken into account
<michaelpj>
weird
<michaelpj>
anyway, you can pass in `configureArgs` which will be passed to `cabal` when we build the plan, so you can put something like `--constraint=yadda yadda`
<__monty__>
Hmm, could my haskell.nix revision (from a couple days ago) be pinning some old hackage data?
<michaelpj>
you do need hackage.nix to be at least as new as the index-state you want
<michaelpj>
if you're not pinning `hackage.nix` separately, then you're getting it via haskell.nix, so *that* needs to be at least as new as the index state you want
<michaelpj>
I think you should get a warning in that case but I'm not sure
<__monty__>
I'll try with master, though the rev I'm on is only 2 commits old.
<michaelpj>
I highly recommend pinning hackage.nix separately
<__monty__>
Hmm, but index-state should basically be identical to pinning, no? Modulo using an index-state that's newer than your version of the index.
<michaelpj>
`hackage.nix` is a nix reqiurement of all the hackage data. If you pin an index-state that's newer than hackage.nix, we simply don't have data for it
<michaelpj>
s/requirement/representation
<__monty__>
Yeah, but if hackage.nix is newer than your index-state cabal should still ignore any newer data, right?
codygman has quit [Read error: Connection reset by peer]
<michaelpj>
yes
<michaelpj>
hackage.nix :: Map<Date, HackageData>
<michaelpj>
essentially
codygman has joined #haskell.nix
<__monty__>
Then I'm gonna be lazy about it and not pin hackage.nix : )
<__monty__>
configureArgs does seem to be working so it really looks like haskell.nix isn't picking up on the revision.
<michaelpj>
that is weird
<__monty__>
The constraint is only present in one executable stanza. Does haskell.nix do something funky when merging constraints from multiple stanzas?
acarrico has joined #haskell.nix
<michaelpj>
not afaik
<michaelpj>
we configure for the whole project, I think
<__monty__>
I'll open an issue?
<michaelpj>
go for it
hsyl20 has joined #haskell.nix
orcus has joined #haskell.nix
brprice has joined #haskell.nix
<brprice>
I'm getting crashes using -fexternal-interpreter with ghc-8.10.2 from haskell.nix but not with the one from nixpkgs-unstable. Any ideas what's going on (or, what's the correct location to report it as a bug)?