2025/01/26

2025-01-26 00:00:06 +0100aaronv(~aaronv@user/aaronv) (Remote host closed the connection)
2025-01-26 00:00:26 +0100aaronv(~aaronv@user/aaronv) aaronv
2025-01-26 00:01:34 +0100wootehfoot(~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer)
2025-01-26 00:07:09 +0100machinedgod(~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod
2025-01-26 00:07:50 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 00:09:20 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net)
2025-01-26 00:14:27 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-26 00:14:38 +0100JuanDaugherty(~juan@user/JuanDaugherty) JuanDaugherty
2025-01-26 00:15:41 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-01-26 00:17:41 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 248 seconds)
2025-01-26 00:20:01 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 244 seconds)
2025-01-26 00:26:02 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 00:26:59 +0100fp1(~Thunderbi@87-94-148-3.rev.dnainternet.fi) fp
2025-01-26 00:27:28 +0100JuanDaughertyColinRobinson
2025-01-26 00:30:04 +0100target_i(~target_i@user/target-i/x-6023099) (Quit: leaving)
2025-01-26 00:30:54 +0100 <fp1> How do you compose parsers together with megaparsec? I'm presently trying to, within my own parser, get a string out of the stream and then parse that and return the result. But I can't apply a parser directly to a string, like =string "foo" theStringIJustMade=, so I don't really know how to proceed
2025-01-26 00:30:58 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-26 00:31:44 +0100 <c_wraith> you use Functor, Applicative, Alternative, and Monad
2025-01-26 00:33:07 +0100 <c_wraith> (do note, though, that if you need a fixed-length string to match the parser, megaparsec doesn't support that nicely)
2025-01-26 00:33:59 +0100hiredman(~hiredman@frontier1.downey.family) (Quit: Lost terminal)
2025-01-26 00:34:54 +0100ColinRobinsonJuanDaugherty
2025-01-26 00:35:17 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 248 seconds)
2025-01-26 00:40:34 +0100JuanDaughertyLycurgus
2025-01-26 00:41:02 +0100Lycurgus(~juan@user/JuanDaugherty) (Changing host)
2025-01-26 00:41:02 +0100Lycurgus(~juan@user/Lycurgus) Lycurgus
2025-01-26 00:41:50 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 00:42:34 +0100 <haskellbridge> <sm> you can run megaparsec recursively, optionally with the current position preserved so your error messages are still good
2025-01-26 00:42:42 +0100sawilagar(~sawilagar@user/sawilagar) (Ping timeout: 248 seconds)
2025-01-26 00:42:58 +0100 <c_wraith> You can, but you usually don't need to.
2025-01-26 00:43:28 +0100 <c_wraith> You should start by figuring out why the compositional interfaces don't work first. Matching a fixed-length string is one case where they don't.
2025-01-26 00:43:30 +0100 <haskellbridge> <sm> if you can avoid it, it's better
2025-01-26 00:45:08 +0100 <haskellbridge> <sm> what do you mean by matching a fixed length string c_wraith ?
2025-01-26 00:45:21 +0100 <fp1> So it seems that Applicative might be what I want, but I can't seem to understand how to use it. I tried =parse ((string "foo") <$ (string "foobar")) "" "text foobar"=, but that's a compile error, seemingly upset by the type of "foo" not being Tokens s0, which doesn't make much sense to me
2025-01-26 00:45:54 +0100 <c_wraith> sm: like if you have length-delimited fields in a data structure. you see the number 50, the next 50 bytes have to match a sub-structure.
2025-01-26 00:46:25 +0100 <haskellbridge> <sm> fp1: you can use ` (backtick, not equals), to quote literal text here
2025-01-26 00:46:35 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2025-01-26 00:46:36 +0100 <fp1> kk
2025-01-26 00:48:15 +0100 <haskellbridge> <sm> fp1: tell us again what the higher goal is maybe ?
2025-01-26 00:49:20 +0100hueso(~root@user/hueso) (Quit: hueso)
2025-01-26 00:49:26 +0100 <c_wraith> fp1: I don't think <$ is the operation you want
2025-01-26 00:49:38 +0100 <c_wraith> :t (<$)
2025-01-26 00:49:38 +0100 <lambdabot> Functor f => a -> f b -> f a
2025-01-26 00:49:56 +0100 <c_wraith> Note that its first argument *isn't* of type `f a`. It's just `a`
2025-01-26 00:50:03 +0100 <fp1> So the goal is to parse scheme character literals, which is <characterLiteral> ::= "#\\" ("space" | "newline" | any non-whitespace character) Lookahead<delimiter>
2025-01-26 00:50:49 +0100 <juri_> ok, i now have an attention mechanism, written in haskell.
2025-01-26 00:50:56 +0100 <haskellbridge> <sm> I would write it out the long way first, in a do block. That's usually easier
2025-01-26 00:51:17 +0100 <c_wraith> fp1: consider: parse (do { foo <- string "foo" ; bar <- string "bar" ; pure (foo ++ bar) }) "" "foobar"
2025-01-26 00:51:46 +0100 <c_wraith> And then consider what happens if you change the last line of the do block
2025-01-26 00:55:16 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 00:56:55 +0100 <fp1> Yes, I've been writing everything in a do block. The trouble I have is I have something like `do { string <- someTill (satisfy (not . isSpace)) (lookAhead delimiter); { parse string to get the character out or error } }`. The trouble I have is, how do I run parsers on `string`? I have the parsers I would run, but not the context to run them
2025-01-26 00:57:27 +0100 <c_wraith> you don't need to lookahead
2025-01-26 00:57:33 +0100 <c_wraith> You can just match on an alternation
2025-01-26 00:57:45 +0100 <fp1> what does that mean
2025-01-26 00:57:46 +0100 <c_wraith> like (string "foo" <|> string "bar")
2025-01-26 00:58:13 +0100 <fp1> but wouldn't that consume the delimiter?
2025-01-26 00:58:24 +0100 <c_wraith> so... store it
2025-01-26 00:58:27 +0100aaronv(~aaronv@user/aaronv) (Ping timeout: 252 seconds)
2025-01-26 00:59:21 +0100 <fp1> But that just solves a problem that I don't have with a lookahead
2025-01-26 00:59:55 +0100 <c_wraith> But it also solves the problem of not being able to parse the result of it
2025-01-26 01:00:17 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds)
2025-01-26 01:00:41 +0100 <fp1> Sorry, what are you suggesting? Maybe I'm just not following
2025-01-26 01:01:10 +0100 <c_wraith> I'm suggesting that instead of looking ahead, just parsing what you are looking for.
2025-01-26 01:01:22 +0100hueso(~root@user/hueso) hueso
2025-01-26 01:01:49 +0100 <c_wraith> Unfortunately, megaparsec makes that a bit painful as you need to understand how to use try
2025-01-26 01:02:10 +0100 <c_wraith> megaparsec is a kind of advanced library
2025-01-26 01:04:05 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-01-26 01:04:35 +0100 <haskellbridge> <sm> what's wrong with https://paste.tomsmeding.com/b45DGFRM (generated code)
2025-01-26 01:08:39 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 252 seconds)
2025-01-26 01:09:35 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 01:09:57 +0100machinedgod(~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 248 seconds)
2025-01-26 01:10:51 +0100haritzondo(~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk)
2025-01-26 01:10:56 +0100haritz(~hrtz@user/haritz) (Read error: Connection reset by peer)
2025-01-26 01:11:04 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 01:12:04 +0100Lycurgus(~juan@user/Lycurgus) (Quit: praxis.meansofproduction.biz (juan@acm.org))
2025-01-26 01:12:58 +0100ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds)
2025-01-26 01:14:51 +0100 <fp1> So the problem is that it fails to reject invalid input. `#\aa` should fail because "aa" isn't a named character and it's not a single character terminated by a delimiter. Same for `#\spaceq`.
2025-01-26 01:15:12 +0100 <fp1> and indeed in that sample, it succeeds on #\aa
2025-01-26 01:15:24 +0100 <c_wraith> so add an eof
2025-01-26 01:15:47 +0100 <c_wraith> *that* isn't composable, so you typically don't do it inside a normal parser
2025-01-26 01:15:48 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-26 01:16:04 +0100 <fp1> but it might not be the end of the file, it might be in the middle of an expression
2025-01-26 01:16:20 +0100 <c_wraith> which is why you add the eof to the runner, not the parser
2025-01-26 01:16:40 +0100 <c_wraith> the thing is that parse succeeds if there's unconsumed input
2025-01-26 01:17:18 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net)
2025-01-26 01:17:28 +0100 <monochrom> Yes, at the outermost parser, you need a final eof check.
2025-01-26 01:17:30 +0100 <c_wraith> If you want to ensure all input is consumed, change that to parse (schemeCharLiteral <* eof) ""
2025-01-26 01:18:06 +0100 <monochrom> In fact, not at what you consider the outermost parser, but rather add one more new level above.
2025-01-26 01:18:31 +0100 <c_wraith> honestly, I'm surprised there isn't a parseAll or something
2025-01-26 01:18:41 +0100tabaqui(~root@167.71.80.236) (Quit: WeeChat 4.4.3)
2025-01-26 01:19:17 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 01:19:28 +0100 <c_wraith> It's weird that parse doesn't flag unconsumed input in its success case at all. Very un-haskell to not return critical information like that.
2025-01-26 01:20:00 +0100 <fp1> Wouldn't that still admit an incorrect input if it's not adjacent to the EOF? As far as I can tell, that would just give #\aa -> [Character 'a', Identifier "a"]
2025-01-26 01:20:13 +0100 <c_wraith> Nothing is looping the parser
2025-01-26 01:20:18 +0100 <monochrom> Perhaps in anticipation that different people have different requirements of valid beginnings and valid endings.
2025-01-26 01:21:25 +0100 <monochrom> If you then say provide a combinator that let people supply their begin parser and end parser, then it already exists, it's called between.
2025-01-26 01:21:42 +0100 <monochrom> generalizedParseAll = between
2025-01-26 01:23:30 +0100 <haskellbridge> <sm> @fp1 what would you like to happen if it sees #\ followed by something invalid - terminate the whole parse with an error ?
2025-01-26 01:23:40 +0100 <fp1> Yes
2025-01-26 01:23:55 +0100tabaqui(~root@167.71.80.236) (Client Quit)
2025-01-26 01:24:21 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 01:24:26 +0100 <c_wraith> Oh. I found the bug in the OrdPSQ stuff. Someone tried to optimize the code from the paper, and the optimization was wrong.
2025-01-26 01:24:59 +0100tabaqui(~root@167.71.80.236) (Client Quit)
2025-01-26 01:25:11 +0100 <c_wraith> Changing back to the code in the paper makes it balance monotonic inserts correctly.
2025-01-26 01:25:41 +0100 <monochrom> I do that once in a while too. Both programs and math proofs. "I think I have a simpler way to prove this... [15 minutes later] oh wait I'm moron"
2025-01-26 01:26:07 +0100 <haskellbridge> <sm> I think you add a final catchall case, and there you can: 1. just call error if ending the program is fine, or 2. throw an exception, which you'll catch by running the parser with runExceptT
2025-01-26 01:26:51 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 01:27:42 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 244 seconds)
2025-01-26 01:27:44 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 01:29:56 +0100aaronv(~aaronv@user/aaronv) aaronv
2025-01-26 01:30:19 +0100 <fp1> Maybe I misunderstood what you meant by terminate the whole parse with an error, because that sounds quite heavy (though maybe I'm wrong). The error here is just a regular invalid token error, akin to a binary literal 0b11002. My assumption is that the correct thing to do in this case is to return Left { ... } as Megaparsec typically does
2025-01-26 01:30:43 +0100tabaqui(~root@167.71.80.236) (Client Quit)
2025-01-26 01:30:53 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 01:31:13 +0100 <geekosaur> that is "terminate the whole parse with an error"
2025-01-26 01:31:50 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2025-01-26 01:32:02 +0100 <fp1> Ok, that's good then, I've learned something
2025-01-26 01:33:22 +0100 <haskellbridge> <sm> well there's degrees of termination. If you just fail the current micro parser, megaparsec is free to keep trying alternatives in the levels above. If you want megaparsec to give up entirely so your program can report an error.. megaparsec doesn't make this super easy; you have to combine it with the Except monad
2025-01-26 01:33:27 +0100 <geekosaur> well, actually it's not quite that: things like <|> can "intercept" it and try something else instead, but if the Left isn't handled by a higher level parser, the parse terminates
2025-01-26 01:35:44 +0100 <monochrom> Most "errors" are supposed to be interceptible and the callers are supposed to be allowed to try alternatives.
2025-01-26 01:36:13 +0100tabaqui(~root@167.71.80.236) (Quit: WeeChat 4.4.3)
2025-01-26 01:36:14 +0100 <monochrom> The notion of "I must crash the whole system here and now, and it is non-maskable" is so last century.
2025-01-26 01:36:23 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 01:37:04 +0100 <monochrom> The last time I heard someone wanting that was in the 1990s on a BBS (remember that?) someone asked "how can my program force a system reboot? I'm trying to prank my friend"
2025-01-26 01:37:34 +0100tabaqui(~root@167.71.80.236) (Client Quit)
2025-01-26 01:37:55 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 01:41:44 +0100 <haskellbridge> <sm> sometimes you want to keep trying, othertimes when you see obvious malformed input you want to force an error.
2025-01-26 01:41:57 +0100Pozyomka(~pyon@user/pyon) (Ping timeout: 248 seconds)
2025-01-26 01:42:22 +0100 <haskellbridge> <sm> (failing to do so will likely produce misleading wrong errors)
2025-01-26 01:42:37 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 01:42:59 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net)
2025-01-26 01:44:00 +0100 <monochrom> That just means the grammar and the parser just needs to refrain from intercepting the error and trying alternatives.
2025-01-26 01:44:47 +0100 <monochrom> And that's good news, because you get a correct program by writing less code!
2025-01-26 01:45:48 +0100 <monochrom> Or even better, you can fix bugs by deleting code!
2025-01-26 01:47:18 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 246 seconds)
2025-01-26 01:49:26 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-26 01:50:10 +0100fp1(~Thunderbi@87-94-148-3.rev.dnainternet.fi) (Ping timeout: 252 seconds)
2025-01-26 01:50:30 +0100 <haskellbridge> <sm> some formats aren't that easy to describe I think
2025-01-26 01:51:45 +0100 <haskellbridge> <sm> you really can't practically have a single comprehensive tree of alternatives that handle every possible situation optimally
2025-01-26 01:52:45 +0100 <haskellbridge> <sm> I mean conceptually it's there, but practically it can't be build reliably and economically
2025-01-26 01:53:50 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-01-26 01:58:24 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 265 seconds)
2025-01-26 01:58:39 +0100 <yin> i think something strange is going on. when adding no version constraints to a dependency, cabal assumes the most recent version it can find, right?
2025-01-26 01:58:52 +0100 <haskellbridge> <sm> not always
2025-01-26 01:59:00 +0100 <c_wraith> it assumes the most recent it can solve with the other dependencies
2025-01-26 01:59:19 +0100 <haskellbridge> <sm> the only way to know for sure is inspect the plan with --dry-run
2025-01-26 02:00:41 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 02:01:19 +0100 <sclv> it may be there’s a solution with pkg a older or one with pkg b older. in that case the solver is deterministic about which is picked but in a way which seems potentially arbitrary to the end user as well
2025-01-26 02:03:49 +0100 <yin> hmm... i've been building this project with an unrestrained dependency for weeks and now seemingly out of the blue it tries to use version 1.0.0.0
2025-01-26 02:03:52 +0100 <yin> https://paste.jrvieira.com/1737853333495
2025-01-26 02:03:59 +0100 <yin> it's ansi-terminal-game
2025-01-26 02:04:16 +0100 <c_wraith> did you do a cabal update?
2025-01-26 02:04:29 +0100 <yin> i think i did recently, yes
2025-01-26 02:04:56 +0100 <c_wraith> additional information can make it choose differently
2025-01-26 02:05:21 +0100 <yin> i find no reason why it would choose 1.0.0.0 of this specific library
2025-01-26 02:05:24 +0100 <yin> but i get it
2025-01-26 02:05:25 +0100 <haskellbridge> <sm> that's the nature of using a dynamic solver, if you want repeatability you have to pin it down
2025-01-26 02:05:34 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-26 02:05:34 +0100 <yin> always constrain your dependencies
2025-01-26 02:05:45 +0100 <haskellbridge> <sm> usually we don't notice because things seem stable
2025-01-26 02:06:29 +0100aaronv(~aaronv@user/aaronv) (Quit: Leaving)
2025-01-26 02:06:47 +0100 <yin> can anyone point me to the docs on cabal freeze?
2025-01-26 02:07:19 +0100 <haskellbridge> <sm> https://cabal.readthedocs.io/en/stable/cabal-commands.html#cabal-freeze
2025-01-26 02:08:50 +0100 <yin> ty
2025-01-26 02:09:41 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net)
2025-01-26 02:11:46 +0100 <geekosaur> often things like that happen because an added constraint to another dependency excludes newer versions of the other for some reason. I have in particular seen this happen because of a wrong/overly restrictive constraint on the other library which causes the solver to look for a version without the constraint
2025-01-26 02:12:53 +0100 <geekosaur> you need to carefully inspect the solver output to catch this kind of thing, possibly running with a manual `--constraint=` excluding the older versions so the solver will give you a reason why it won't use the newer ones
2025-01-26 02:14:21 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 276 seconds)
2025-01-26 02:14:40 +0100 <geekosaur> in particular, it looks like 0.1.0.0 simply omits constraints for everything except base, which is pretty suspicious
2025-01-26 02:15:27 +0100 <geekosaur> so trying to build with --constraint='ansi-terminal-game > 1' should get the solver to tell you what's wrong, hopefully
2025-01-26 02:15:27 +0100tabaqui(~root@167.71.80.236) (Quit: WeeChat 4.4.3)
2025-01-26 02:15:44 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 02:16:28 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 02:16:41 +0100 <haskellbridge> <sm> yeah. The solver isn't always good at explaining to a human what happened, you have to coax it (this applies to stack too, even though the plans there are more static)
2025-01-26 02:16:45 +0100tabaqui(~root@167.71.80.236) (Client Quit)
2025-01-26 02:17:16 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 02:17:20 +0100tabaqui(~root@167.71.80.236) (Client Quit)
2025-01-26 02:17:21 +0100 <geekosaur> in this case it won't say anything at all, it'll just pick the unconstrained version. it should output an actual error with the --constraint, so you have something to work from
2025-01-26 02:17:34 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 02:17:51 +0100 <geekosaur> otherwise you need to run cabal with -v3 or somesuch to find out why the solver rejected every other version, since it eventually found a working plan
2025-01-26 02:17:54 +0100tabaqui(~root@167.71.80.236) (Client Quit)
2025-01-26 02:17:59 +0100 <geekosaur> well, "working"
2025-01-26 02:18:37 +0100 <yin> seems like the culprit was random-1.3.0
2025-01-26 02:18:58 +0100 <sclv> yeah often when you get a totally old version of a pkg its because their first version had no constraints lol. this is one reason revisions are important!
2025-01-26 02:20:29 +0100 <haskellbridge> <sm> idea for a safety belt: warn and fail by default if any package version more than 1y older than its latest release is selected
2025-01-26 02:22:11 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 02:22:15 +0100tabaqui(~root@167.71.80.236) (Client Quit)
2025-01-26 02:23:21 +0100 <yin> ouch. there's our unconstrained depenedncies https://hackage.haskell.org/package/ansi-terminal-game-0.1.0.0
2025-01-26 02:23:47 +0100 <geekosaur> only base, which hackage checks for
2025-01-26 02:23:50 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 02:24:14 +0100tabaqui(~root@167.71.80.236) (Client Quit)
2025-01-26 02:24:29 +0100 <geekosaur> first thing I noticed when I pulled it up to try to see why it would have been picked
2025-01-26 02:24:44 +0100 <geekosaur> "yeh, that'd do it"
2025-01-26 02:25:00 +0100otto_s(~user@p5de2f342.dip0.t-ipconnect.de) (Ping timeout: 252 seconds)
2025-01-26 02:25:00 +0100 <yin> geekosaur: oh i messed that. yeah, thanks for the heads up
2025-01-26 02:25:21 +0100 <yin> is there something the maintainer can do about it?
2025-01-26 02:25:26 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2025-01-26 02:25:39 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-26 02:25:56 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Client Quit)
2025-01-26 02:26:00 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 02:26:04 +0100 <geekosaur> they can do a metadata update to add revision information
2025-01-26 02:26:31 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 02:26:32 +0100 <geekosaur> https://hackage.haskell.org/package/ansi-terminal-game/maintain ("edit package information" on the Hackage page)
2025-01-26 02:26:37 +0100 <haskellbridge> <sm> yes, they can add bounds via a revision. It's f-a in #haskell-game. But should they ?
2025-01-26 02:26:40 +0100otto_s(~user@p5de2f856.dip0.t-ipconnect.de)
2025-01-26 02:26:53 +0100 <geekosaur> I'd say yes, as this is just a bit of a trap
2025-01-26 02:27:10 +0100 <haskellbridge> <sm> is a-t-g failing to compile with its deps ?
2025-01-26 02:27:13 +0100 <geekosaur> doesn't matter how fancy a constraint solver is, bad constraints will mess it up
2025-01-26 02:27:30 +0100igemnace(~igemnace@user/igemnace) (Quit: ZNC 1.9.0+deb2build3 - https://znc.in)
2025-01-26 02:27:40 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net)
2025-01-26 02:28:31 +0100 <haskellbridge> <sm> the bounds are very minimal, but they're not wrong, from what I read
2025-01-26 02:28:36 +0100 <geekosaur> more likely something else will fail to compile with the ancient a-t-g, which says it's a proof of concept
2025-01-26 02:29:34 +0100igemnace(~igemnace@user/igemnace) igemnace
2025-01-26 02:29:34 +0100 <geekosaur> I note 0.2.0.0 not only has constraints, it has more dependencies which suggests more functionality
2025-01-26 02:30:52 +0100Square(~Square@user/square) (Ping timeout: 272 seconds)
2025-01-26 02:31:06 +0100tabaqui(~root@167.71.80.236) (Client Quit)
2025-01-26 02:31:06 +0100 <haskellbridge> <sm> taking that to the extreme, it means every version of every package on hackage should specify all bounds defensively (with corresponding massive increase in busywork and install failures), so that people can keep using a dynamic solver and treat it like a repeatable one
2025-01-26 02:31:09 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-26 02:32:00 +0100 <geekosaur> that's an old, old argument
2025-01-26 02:32:15 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 252 seconds)
2025-01-26 02:32:19 +0100 <geekosaur> some folks insist on minimal constraints, some on conservative, some on tight/maximal
2025-01-26 02:32:37 +0100Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.)
2025-01-26 02:32:52 +0100 <haskellbridge> <sm> ok, but I think it's a true statement right ? is anyone advocating for that ?
2025-01-26 02:32:57 +0100 <geekosaur> each has failure modes, sometimes quite public (an early release of `text` caused a lot of breakage, for example)
2025-01-26 02:33:04 +0100 <geekosaur> some do
2025-01-26 02:33:13 +0100 <geekosaur> like I said, this argument's been going on for a long time
2025-01-26 02:33:44 +0100 <haskellbridge> <sm> I think it's more practical to use smarter tools
2025-01-26 02:33:50 +0100 <c_wraith> stackage is all about specifying exactly one version for each package
2025-01-26 02:33:58 +0100 <c_wraith> no ranges. nothing to solve.
2025-01-26 02:34:01 +0100 <haskellbridge> <sm> perfect total bounds on all of hackage is unachievable
2025-01-26 02:34:30 +0100 <haskellbridge> <sm> so tools shouldn't expect that. Some kind of hybrid approach at least is needed
2025-01-26 02:34:52 +0100 <c_wraith> There was a thing when stack was first introduced where people using it stopped putting version bounds on their libraries on hackage. That broke everything.
2025-01-26 02:34:58 +0100 <c_wraith> Fortunately, they got better.
2025-01-26 02:36:57 +0100 <yin> > geekosaur some folks insist on minimal constraints, some on conservative, some on tight/maximal
2025-01-26 02:36:58 +0100 <lambdabot> <hint>:1:51: error: parse error on input ‘,’
2025-01-26 02:37:05 +0100 <yin> isn't that what semver is all about?
2025-01-26 02:37:22 +0100 <yin> (i know we don't use it, supposedly)
2025-01-26 02:37:32 +0100 <c_wraith> the pvp is just expanded semver.
2025-01-26 02:37:36 +0100otto_s(~user@p5de2f856.dip0.t-ipconnect.de) (Quit: leaving)
2025-01-26 02:37:37 +0100 <geekosaur> semver is about how you set your version, not how you specify what versions of dependencies you work with
2025-01-26 02:37:41 +0100 <c_wraith> They have the same issue
2025-01-26 02:37:52 +0100otto_s(~user@p5de2f856.dip0.t-ipconnect.de)
2025-01-26 02:38:07 +0100 <c_wraith> Which is.... yeah, that. How exhaustively are you going to test the range of your dependencies that you work with?
2025-01-26 02:38:23 +0100 <geekosaur> and yes, in the end you have the same issue: follow it strictly and spend all your time playing version whack-a-mole, or follow it loosely and break the world when the wrong dependency changes
2025-01-26 02:39:16 +0100 <geekosaur> and there often doesn't seem to be a happy middle: whatever strategy you choose, it has failure modes
2025-01-26 02:40:25 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net)
2025-01-26 02:40:29 +0100 <haskellbridge> <sm> c_wraith: nothing to solve you say.. except when you ask it to put a foot outside of the snapshot (pretty common, eg with new ghc versions), then it has to do some solvin', with similar UX issues
2025-01-26 02:41:11 +0100 <c_wraith> well that's the reality of using stack, but that's not the marketing promise
2025-01-26 02:41:45 +0100 <jackdk> stackage is kinda self-justifying in that it encourages people to upload packages with no bounds at all, and only rely on snapshots. I think that's very damaging, not least to the solver that produces the snapshots in the first place
2025-01-26 02:41:59 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 02:42:00 +0100 <haskellbridge> <sm> there's no marketing saying otherwise. Obviously only packages within the snapshot benefit from the snapshot's compatibility guarantee
2025-01-26 02:42:16 +0100 <haskellbridge> <sm> yin: I'd be interested to see your project's cabal file(s)
2025-01-26 02:42:34 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-01-26 02:42:50 +0100 <haskellbridge> <sm> jackdk: people don't do that much, because they get shouted at
2025-01-26 02:43:21 +0100 <haskellbridge> <sm> and if they do, it doesn't break everything - it breaks their package and things depending on it - so it's self correcting I'd say
2025-01-26 02:43:29 +0100 <yin> sm: https://paste.jrvieira.com/1737855804443
2025-01-26 02:44:35 +0100 <haskellbridge> <sm> thanks. So looking at this practically, it seems to me your package is dramatically under specifying bounds, so you should expect it to fail to build right with cabal sometimes
2025-01-26 02:44:53 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 248 seconds)
2025-01-26 02:45:14 +0100 <yin> sm: i sometimes avoid bounds while developing :)
2025-01-26 02:45:33 +0100 <haskellbridge> <sm> absolutely fine, nothing wrong with that
2025-01-26 02:45:57 +0100 <yin> one benefit is that interesting stuff like this happens and i always learn a bit
2025-01-26 02:46:08 +0100 <haskellbridge> <sm> and now you know how to diagnose and solve the occasional glitch :)
2025-01-26 02:46:17 +0100 <yin> yes, tyvm
2025-01-26 02:46:54 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 260 seconds)
2025-01-26 02:46:54 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2025-01-26 02:47:14 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 02:48:44 +0100tabaqui(~root@167.71.80.236) (Client Quit)
2025-01-26 02:49:00 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 02:49:05 +0100tabaqui(~root@167.71.80.236) (Remote host closed the connection)
2025-01-26 02:50:19 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 02:52:40 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net)
2025-01-26 02:52:52 +0100tabaqui(~root@167.71.80.236) (Remote host closed the connection)
2025-01-26 02:56:34 +0100 <haskellbridge> <sm> stop me if I'm becoming a bore, but...
2025-01-26 02:56:34 +0100 <haskellbridge> we were talking earlier about cabal freeze. This might be an example of where that's too heavy handed. The lighter approach of just adding a few guiding constraints, on the deps likely to cause problems - in this case, simply >1 on ansi-terminal-game - was enough at least for now. The right approach depends on the needs of the project
2025-01-26 02:56:54 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 252 seconds)
2025-01-26 02:57:49 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 02:58:07 +0100 <yin> oh sure, i used cabal freeze as a lazy way to see which constraints were being solved :)
2025-01-26 02:58:41 +0100 <yin> i was editing my project's constraints and playing with freeze and gen-bounds
2025-01-26 02:58:58 +0100 <haskellbridge> <sm> cabal build --dry-run [--constraint ...] FTW
2025-01-26 03:00:31 +0100 <yin> i thought it was too much noise :x
2025-01-26 03:00:35 +0100 <haskellbridge> <sm> and sometimes an --allow-newer or so
2025-01-26 03:01:21 +0100ezzieyguywuf(~Unknown@user/ezzieyguywuf) (Quit: Lost terminal)
2025-01-26 03:01:27 +0100 <haskellbridge> <sm> probably someone will train an LLM to be good at this
2025-01-26 03:02:22 +0100sprotte24(~sprotte24@p200300d16f1a11001925fb087a37c132.dip0.t-ipconnect.de) (Quit: Leaving)
2025-01-26 03:02:46 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-26 03:04:25 +0100 <yin> (i mean too much noise with -v, too quiet wihout)
2025-01-26 03:04:42 +0100Pozyomka(~pyon@user/pyon) pyon
2025-01-26 03:04:46 +0100 <haskellbridge> <sm> oh yea, that's frustrating. stack is the same
2025-01-26 03:05:28 +0100 <yin> cabal gen-bounds was just right
2025-01-26 03:09:00 +0100ft(~ft@p3e9bcfa2.dip0.t-ipconnect.de) (Ping timeout: 252 seconds)
2025-01-26 03:10:43 +0100ft(~ft@p3e9bcd97.dip0.t-ipconnect.de) ft
2025-01-26 03:13:33 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 03:18:29 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds)
2025-01-26 03:23:57 +0100acidjnk(~acidjnk@p200300d6e7283f82584cd550442beef5.dip0.t-ipconnect.de) (Ping timeout: 252 seconds)
2025-01-26 03:29:22 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 03:31:19 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-01-26 03:34:17 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2025-01-26 03:34:40 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net)
2025-01-26 03:35:19 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 244 seconds)
2025-01-26 03:38:29 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 03:38:31 +0100tabaqui(~root@167.71.80.236) (Client Quit)
2025-01-26 03:39:16 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 272 seconds)
2025-01-26 03:43:06 +0100vanishingideal(~vanishing@user/vanishingideal) (Ping timeout: 252 seconds)
2025-01-26 03:45:10 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 03:50:04 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-26 04:00:57 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 04:02:05 +0100ezzieyguywuf(~Unknown@user/ezzieyguywuf) ezzieyguywuf
2025-01-26 04:05:02 +0100op_4(~tslil@user/op-4/x-9116473) (Remote host closed the connection)
2025-01-26 04:05:33 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2025-01-26 04:05:33 +0100op_4(~tslil@user/op-4/x-9116473) op_4
2025-01-26 04:09:20 +0100califax(~califax@user/califx) (Remote host closed the connection)
2025-01-26 04:09:36 +0100califax(~califax@user/califx) califx
2025-01-26 04:16:45 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 04:19:43 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-01-26 04:21:18 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2025-01-26 04:22:00 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 04:24:01 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 248 seconds)
2025-01-26 04:26:44 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-26 04:30:37 +0100mhatta(~mhatta@www21123ui.sakura.ne.jp) (Remote host closed the connection)
2025-01-26 04:32:28 +0100mhatta(~mhatta@www21123ui.sakura.ne.jp)
2025-01-26 04:37:42 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 04:44:33 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2025-01-26 04:51:52 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 04:56:00 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 05:00:51 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2025-01-26 05:01:25 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 05:03:02 +0100tabaqui1(~root@87.200.129.102) tabaqui
2025-01-26 05:03:18 +0100tabaqui(~root@167.71.80.236) (Quit: WeeChat 4.4.3)
2025-01-26 05:06:06 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2025-01-26 05:06:58 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net)
2025-01-26 05:08:09 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-01-26 05:10:14 +0100pointlessslippe1(~pointless@62.106.85.17) (Read error: Connection reset by peer)
2025-01-26 05:11:25 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 244 seconds)
2025-01-26 05:12:34 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 252 seconds)
2025-01-26 05:14:15 +0100pointlessslippe1(~pointless@62.106.85.17) pointlessslippe1
2025-01-26 05:17:06 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 05:22:06 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-26 05:22:32 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 05:22:34 +0100tabaqui(~root@167.71.80.236) (Client Quit)
2025-01-26 05:24:45 +0100Midjak(~MarciZ@82.66.147.146) (Quit: This computer has gone to sleep)
2025-01-26 05:30:07 +0100aforemny_(~aforemny@2001:9e8:6ce1:cf00:b6f1:625c:54b4:a44b) aforemny
2025-01-26 05:31:15 +0100aforemny(~aforemny@2001:9e8:6cc1:a100:8787:3cb3:35e4:a6f8) (Ping timeout: 252 seconds)
2025-01-26 05:32:54 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 05:37:50 +0100aaronv(~aaronv@user/aaronv) aaronv
2025-01-26 05:37:55 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 05:38:58 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-26 05:41:43 +0100tabaqui(~root@167.71.80.236) (Client Quit)
2025-01-26 05:48:04 +0100tabaqui(~root@167.71.80.236) tabaqui
2025-01-26 05:49:49 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 05:52:54 +0100tabaqui1(~root@87.200.129.102) (Ping timeout: 252 seconds)
2025-01-26 05:54:44 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2025-01-26 05:57:13 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-01-26 05:59:33 +0100hiredman(~hiredman@frontier1.downey.family) hiredman
2025-01-26 06:00:15 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net)
2025-01-26 06:01:27 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2025-01-26 06:01:51 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 276 seconds)
2025-01-26 06:04:38 +0100simplystuart(~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 252 seconds)
2025-01-26 06:05:17 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 06:09:33 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-01-26 06:10:08 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-26 06:10:54 +0100tabaqui1(~root@87.200.129.102) tabaqui
2025-01-26 06:12:48 +0100Guest2(~Guest2@78.135.8.93)
2025-01-26 06:15:16 +0100tabaqui1(~root@87.200.129.102) (Ping timeout: 252 seconds)
2025-01-26 06:19:31 +0100 <Guest2> #haskell-ghcup says try here as well, please let me know if this is off-topic ...
2025-01-26 06:19:32 +0100 <Guest2> ... following the instructions to install ghcup on linux with the given `curl` command.
2025-01-26 06:19:32 +0100 <Guest2> It seems there is a problem with versions *suggestion 3. also did not work) and that something is hard-coding `/home/xxx` instead of using `$HOME`.
2025-01-26 06:19:33 +0100 <Guest2> ```
2025-01-26 06:19:33 +0100 <Guest2> [ Warn ] [GHCup-00110] ghc-9.4.8 is already installed; if you really want to reinstall it, you may want to run 'ghcup install ghc --force 9.4.8'
2025-01-26 06:19:34 +0100 <Guest2> [ Warn ] GHC-9.4.8 appears to have no corresponding HLS-2.0.0.1 binary.
2025-01-26 06:19:34 +0100 <Guest2> [ ... ] Haskell IDE support may not work.
2025-01-26 06:19:35 +0100 <Guest2> [ ... ] You can try to either:
2025-01-26 06:19:35 +0100 <Guest2> [ ... ] 1. Install a different HLS version (e.g. downgrade for older GHCs)
2025-01-26 06:19:36 +0100 <Guest2> [ ... ] 2. Install and set one of the following GHCs: [9.6.2, 9.4.5, 9.2.8, 9.2.7, 9.0.2, 8.10.7]
2025-01-26 06:19:36 +0100 <Guest2> [ ... ] 3. Let GHCup compile HLS for you, e.g. run: ghcup compile hls -g 2.0.0.1 --ghc 9.4.8 --cabal-update
2025-01-26 06:19:37 +0100 <Guest2> [ ... ] (see https://www.haskell.org/ghcup/guide/#hls for more information)
2025-01-26 06:19:37 +0100 <Guest2> [ Info ] GHC 9.4.8 successfully set as default version
2025-01-26 06:19:38 +0100 <Guest2> [ Warn ] [GHCup-00110] cabal-3.12.1.0 is already installed; if you really want to reinstall it, you may want to run 'ghcup install cabal --force 3.12.1.0'
2025-01-26 06:19:39 +0100 <Guest2> "cabal update --ignore-project" failed!
2025-01-26 06:19:39 +0100 <Guest2> ```
2025-01-26 06:19:40 +0100 <Guest2> Is there, ideally, a simple, single line command I can run that will just do everything correctly (presumably something like the given curl command, but with some param for version and user home) rather than me absolutely naively trying to fix things piecemeal and inevitably spending hours making things worse before I even get as far as trying out
2025-01-26 06:19:40 +0100 <Guest2> the language in some editor or VSCode?
2025-01-26 06:20:15 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-01-26 06:21:05 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-26 06:21:06 +0100 <haskellbridge> <bdub> What happens when you run ghcup tui
2025-01-26 06:21:16 +0100 <Guest2> I'll try
2025-01-26 06:21:56 +0100 <Guest2> should i just go with defaults again?
2025-01-26 06:22:16 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2025-01-26 06:22:21 +0100 <haskellbridge> <bdub> yeah unless your trying to do something with a specific version
2025-01-26 06:22:38 +0100 <Guest2> no, anything that works will be fine
2025-01-26 06:23:13 +0100 <haskellbridge> <bdub> Your error shows ghc is already installed
2025-01-26 06:23:29 +0100 <Guest2> it must have been installed on the first try of the curl command
2025-01-26 06:23:36 +0100 <haskellbridge> <bdub> I think so
2025-01-26 06:24:05 +0100 <Guest2> but HLS fails, and the something seems to make assumptions about where the home directory is, which also fails
2025-01-26 06:25:03 +0100 <haskellbridge> <bdub> ahhh I see, I have seen that before but still never had issues working w/ Haskell
2025-01-26 06:25:07 +0100 <Guest2> the tui seems have have gone further. Is there an easy way to test the full installation?
2025-01-26 06:25:11 +0100 <haskellbridge> <bdub> Maybe someone else has advice
2025-01-26 06:25:46 +0100 <haskellbridge> <bdub> The tui helps you manage different versions
2025-01-26 06:25:48 +0100 <Guest2> this has already been helpful haskellbridge, thank you!
2025-01-26 06:25:51 +0100 <haskellbridge> <bdub> double green checkmarks = default
2025-01-26 06:25:58 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Client Quit)
2025-01-26 06:26:00 +0100 <haskellbridge> <bdub> single green means installed but not set
2025-01-26 06:26:29 +0100 <Guest2> is there a quick way to test if the HLS was installed?
2025-01-26 06:27:02 +0100 <haskellbridge> <bdub> What does the tui show, what versions of HLS
2025-01-26 06:27:16 +0100 <haskellbridge> <bdub> https://kf8nh.com/_heisenbridge/media/matrix.org/PkyTiZODspDgyALmTyNRPPpk/l_0MiJlemVo/image.png
2025-01-26 06:27:44 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-26 06:32:16 +0100 <Guest2> does the tui update PATH, or shoudl I do that manually before starting up the editor/VSCode?
2025-01-26 06:35:27 +0100 <haskellbridge> <bdub> When you ran the installer it should have asked you a few questions, like append or prepend path etc
2025-01-26 06:35:56 +0100 <Guest2> yes, it did, but tui did not
2025-01-26 06:36:31 +0100 <Guest2> and I think the non-tui version broke before it got as far as editing .bashrc
2025-01-26 06:36:50 +0100 <Guest2> I am not even sure ,bashrc is the right place on fedora
2025-01-26 06:38:22 +0100 <haskellbridge> <bdub> I am unfamiliar w/ Fedora :(