Logs: freenode/#haskell
| 2020-09-18 19:08:25 | <hyiltiz> | oh a table of file names and hashes alongside the actual files? |
| 2020-09-18 19:08:29 | <exarkun> | hyiltiz: Why do you need to embed the hash in the file? |
| 2020-09-18 19:08:40 | <geekosaur> | since stack's own RTS won't spot it that way |
| 2020-09-18 19:08:42 | <monochrom> | The syntax --ghc-options=+RTS does not require you to escape +RTS, i.e., stack does not swallow/interpret "+RTS" for itself. |
| 2020-09-18 19:09:00 | <merijn> | tomsmeding, geekosaur: Or, here's a crazy idea, just use -- |
| 2020-09-18 19:09:08 | <hyiltiz> | then, I can look for the hash to find the file of interest (among say 10^6 files, each hashed with an embeddable hash) |
| 2020-09-18 19:09:11 | <merijn> | The RTS will ignore all +RTS options after -- |
| 2020-09-18 19:09:22 | × | alp quits (~alp@88.126.45.36) (Remote host closed the connection) |
| 2020-09-18 19:09:23 | <merijn> | In the great unix tradition of not consuming flags after -- |
| 2020-09-18 19:09:41 | <hyiltiz> | but application aside, I am more interested in the feasibility/solutions of the X=hash(X++Y) equation above |
| 2020-09-18 19:09:56 | <geekosaur> | but then there are possibly stack options to be passed |
| 2020-09-18 19:09:59 | <monochrom> | I have doubt about the semantics of -- in this case though. |
| 2020-09-18 19:10:22 | × | mpereira quits (~mpereira@2a02:810d:f40:d96:d572:7a06:140c:5191) (Ping timeout: 260 seconds) |
| 2020-09-18 19:10:29 | <geekosaur> | which is why the RTS has its own "--RTS" so it doesn't also turn off arbitrary option parsing |
| 2020-09-18 19:10:29 | → | gestone joins (~gestone@c-73-97-137-216.hsd1.wa.comcast.net) |
| 2020-09-18 19:10:31 | <monochrom> | For simple programs the semantics of -- is accordingly simple. |
| 2020-09-18 19:10:35 | <merijn> | monochrom: I don't, because I know it works |
| 2020-09-18 19:10:41 | <monochrom> | OK! |
| 2020-09-18 19:10:49 | <exarkun> | hyiltiz: It has differing degrees of feasibility depending on the hash function you pick. But in general I don't see the value. |
| 2020-09-18 19:10:54 | <merijn> | monochrom: I use it to pass +RTS flags when using "cabal run" |
| 2020-09-18 19:11:09 | <monochrom> | but this is "stack build", not even "stack run" |
| 2020-09-18 19:11:12 | <tomsmeding> | merijn: I want to pass options to GHC through stack |
| 2020-09-18 19:11:13 | × | blackfield quits (~blackfiel@unaffiliated/blackfield) (Quit: see you) |
| 2020-09-18 19:11:27 | × | fendor quits (~fendor@77.119.131.164.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2020-09-18 19:11:32 | × | Saten-san quits (~Saten-san@ip-83-134-68-193.dsl.scarlet.be) (Quit: WeeChat 2.8) |
| 2020-09-18 19:11:34 | <tomsmeding> | I am thoroughly confused now what --ghc-options expects |
| 2020-09-18 19:11:41 | × | bennofs quits (~quassel@dslb-188-106-228-057.188.106.pools.vodafone-ip.de) (Ping timeout: 260 seconds) |
| 2020-09-18 19:11:49 | × | seanvert quits (~user@177.84.244.242) (Ping timeout: 260 seconds) |
| 2020-09-18 19:12:18 | <hyiltiz> | exarkun: I can't think of any function to pick from that could satisfy that equation (some kinda fixed point to bootstrapping; not sure how to describe that equation with words) |
| 2020-09-18 19:12:20 | <geekosaur> | as is typical for long options, they can take parameters which are either combined (--foo=bar) or separate (--foo bar) |
| 2020-09-18 19:12:22 | <merijn> | tomsmeding: The real answer is "--ghc-options" isn't generally used to pass RTS options to ghc and I doubt stack really supports that well |
| 2020-09-18 19:12:24 | <sm[m]> | I've always done --ghc-options='-some -ghc -options' to be safe |
| 2020-09-18 19:12:36 | <tomsmeding> | sm[m]: it splits on spaces? |
| 2020-09-18 19:12:39 | <geekosaur> | the = version can be useful in cases where the parameter looks like an option |
| 2020-09-18 19:12:40 | <hyiltiz> | monochrom pointed out that CRC isnt actually the solution to that eq. |
| 2020-09-18 19:12:44 | <tomsmeding> | what if you want to pass an option to GHC that contains spaces? |
| 2020-09-18 19:12:55 | <merijn> | tomsmeding: With cabal I'd just define a shell script that does 'ghc +RTS my options -RTS "$@"' |
| 2020-09-18 19:13:04 | <merijn> | And then point cabal at the shell script |
| 2020-09-18 19:13:05 | <exarkun> | hyiltiz: hash x = 0 |
| 2020-09-18 19:13:14 | <merijn> | But that probably doesn't work with stack |
| 2020-09-18 19:13:14 | <sm[m]> | tomsmeding: dunno the details but I have the impression it works. I believe you about --RTS.. was it in the stack user guide ? I didn't find it in stack --help |
| 2020-09-18 19:13:28 | <tomsmeding> | sm[m]: ghc +RTS --help |
| 2020-09-18 19:13:39 | → | jespada joins (~jespada@90.254.241.6) |
| 2020-09-18 19:13:47 | × | jedws quits (~jedws@101.184.170.244) (Ping timeout: 240 seconds) |
| 2020-09-18 19:13:47 | <tomsmeding> | it's to prevent the RTS of the 'stack' executable from interpreting them |
| 2020-09-18 19:14:16 | <tomsmeding> | I sincerely hope that to stack, '--ghc-options ABC' is the same as '--ghc-options -v' is the same as '--ghc-options +RTS', mutatis mutandis |
| 2020-09-18 19:14:23 | <sm[m]> | ah, tricksy.. so --RTS is another of those hidden flags supported by all GHC-built executables |
| 2020-09-18 19:14:23 | <sm[m]> | thanks |
| 2020-09-18 19:14:45 | × | gestone quits (~gestone@c-73-97-137-216.hsd1.wa.comcast.net) (Ping timeout: 240 seconds) |
| 2020-09-18 19:14:52 | <sm[m]> | stack build --ghc-options='+RTS -M500m -RTS' <- is the kind of syntax I usually use |
| 2020-09-18 19:14:54 | <hyiltiz> | exarkun: Ok, so the hash function doesn't have to be cryptographically secure, but it should at least map slightly different Ys into vastly different Xs; so a trivial hash x = 0 isn't really an interesting solution |
| 2020-09-18 19:15:19 | <exarkun> | hyiltiz: interesting is in the eye of the beholder :) |
| 2020-09-18 19:15:36 | <sm[m]> | tomsmeding: and if in doubt I would definitely add -v to verify |
| 2020-09-18 19:15:47 | <tomsmeding> | okay the plot thickens |
| 2020-09-18 19:15:59 | <tomsmeding> | the options you give to --ghc-options are _actually_ first passed to a Setup executable somewhere |
| 2020-09-18 19:16:07 | <tomsmeding> | which then interprets those +RTS options |
| 2020-09-18 19:16:14 | <tomsmeding> | they don't even reach ghc |
| 2020-09-18 19:16:21 | <tomsmeding> | and no, --ghc-options=--RTS before it doesn't help :p |
| 2020-09-18 19:16:28 | <hyiltiz> | I just defined what "interesting" means: as a hash function, it has to a) at least map slightly different Ys into vastly different Xs most of the time; b) unhashing (Y->X) is hard. |
| 2020-09-18 19:16:42 | <hyiltiz> | but I agree; beauty beholds |
| 2020-09-18 19:16:46 | <monochrom> | This is what's wrong with 5 layers of abstractions. Every layer wants to have a say. |
| 2020-09-18 19:16:49 | <geekosaur> | so you need to embed another… wat. wonder if it's actually an executable then |
| 2020-09-18 19:17:07 | → | Bluuuhu joins (a@46.128.9.226) |
| 2020-09-18 19:17:09 | <geekosaur> | or if it's runghc-d which means still another level needed |
| 2020-09-18 19:17:19 | <geekosaur> | fuuuuuun |
| 2020-09-18 19:17:34 | <geekosaur> | (possibly 2 but I think 1) |
| 2020-09-18 19:17:39 | × | Bluuuhu quits (a@46.128.9.226) (Client Quit) |
| 2020-09-18 19:18:07 | → | Bluuu joins (a@46.128.9.226) |
| 2020-09-18 19:18:14 | <tomsmeding> | $ stack build --RTS --ghc-options=--RTS --ghc-options=+RTS --ghc-options=-s --ghc-options=-RTS |
| 2020-09-18 19:18:18 | × | Bluuu quits (a@46.128.9.226) (Client Quit) |
| 2020-09-18 19:18:20 | <tomsmeding> | Cabal-simple_mPHDZzAJ_3.0.1.0_ghc-8.8.4: Unrecognised build target '+RTS'. |
| 2020-09-18 19:18:21 | <monochrom> | Reminds me that in emacs regex I have to say like \\\\( for parenthesis. |
| 2020-09-18 19:18:22 | <tomsmeding> | I don't even know |
| 2020-09-18 19:18:43 | <merijn> | Here's a crazy idea |
| 2020-09-18 19:18:45 | <tomsmeding> | (-s is my test flag since it should give visible output) |
| 2020-09-18 19:18:56 | <tomsmeding> | replace $(which ghc) with a shell script? |
| 2020-09-18 19:18:57 | <tomsmeding> | yes |
| 2020-09-18 19:18:57 | <merijn> | Why do you not write this stuff inside the ghc-options field of your cabal file |
| 2020-09-18 19:19:22 | <tomsmeding> | because I want to use those flags to build a dependency of my project |
| 2020-09-18 19:19:26 | <tomsmeding> | aeson, to be specific |
| 2020-09-18 19:19:32 | <tomsmeding> | so I don't control its cabal file :) |
| 2020-09-18 19:20:01 | <geekosaur> | were this a cabal project, you could use cabal.project to do it I think |
| 2020-09-18 19:20:02 | <monochrom> | Some kind of cabal.project.local file can help you. You can add a clause for "how to build aeson". |
| 2020-09-18 19:20:08 | <merijn> | I was gonna write "so add them to cabal.project.local", but that's probably not helpful with stack |
| 2020-09-18 19:20:18 | × | Faker quits (bad2e42c@186.210.228.44) (Remote host closed the connection) |
| 2020-09-18 19:20:18 | <merijn> | geekosaur, monochrom: Hah, same mistake |
| 2020-09-18 19:20:19 | <monochrom> | For stack I don't know but I think there is a counterpart. |
| 2020-09-18 19:20:22 | <geekosaur> | yeh, sorry, cabal.project.local |
| 2020-09-18 19:20:40 | <merijn> | tomsmeding: Stack hates you :) |
| 2020-09-18 19:20:57 | <koz_> | merijn: This. |
| 2020-09-18 19:21:10 | <tomsmeding> | I figured :p |
| 2020-09-18 19:22:38 | × | Lowl3v3l quits (~Lowl3v3l@dslb-090-186-188-115.090.186.pools.vodafone-ip.de) (Remote host closed the connection) |
| 2020-09-18 19:23:04 | → | Lowl3v3l joins (~Lowl3v3l@dslb-090-186-188-115.090.186.pools.vodafone-ip.de) |
| 2020-09-18 19:23:33 | <tomsmeding> | ah I see, with that command the Setup executable gets the following flags: |
| 2020-09-18 19:23:34 | <tomsmeding> | --ghc-options --RTS --ghc-options +RTS --ghc-options -s --ghc-options -RTS |
| 2020-09-18 19:24:02 | <tomsmeding> | the --RTS gets eaten by Setup's RTS, then the 2nd --ghc-options is a ghc option, and +RTS is taken as a build target |
| 2020-09-18 19:24:03 | × | jneira[m] quits (~jneira@38.red-193-152-116.dynamicip.rima-tde.net) (Read error: Connection reset by peer) |
| 2020-09-18 19:24:09 | <tomsmeding> | I'm not even sure whether it's possible to do this |
| 2020-09-18 19:24:10 | → | jneira[m] joins (~jneira@80.30.101.206) |
| 2020-09-18 19:24:42 | <tomsmeding> | oh! |
All times are in UTC.