WilliButz has quit [Remote host closed the connection]
<infinisil>
(repeating in this channel): That vim-hm line can be changed to `config.mine.vim.extraPlugins or []`
<infinisil>
Arguably tryEval reasonably only catches throw's, as that's an intentional user-facing error by the programmer, indicating that something went wrong, but the code can handle it
<infinisil>
On the other hand, things like missing attributes are the programmers fault because the code couldn't handle all the input it was passed
<infinisil>
And the code should be changed to handle that better
<infinisil>
Though I'm not sure if there would be a problem if tryEval was changed to catch all errors
<evanjs>
yeah that seems to work fine (on one of the nixos machines at least :P)
<evanjs>
I'm used to "error handling" in Rust so I'm not unfamiliar with a billion different ways to handle exceptions haha
<infinisil>
Hmm, what if there was `builtins.try <expr> <handler>`
<evanjs>
ooooo
<infinisil>
Or maybe it should be builtins.catch
<evanjs>
yeah, I guess when I initially saw tryEval, my mind jumped to e.g. generic try/catch
<infinisil>
So e.g. `builtins.catch (throw "hi") (e: e)` returns "hi"
<infinisil>
The function in the second argument would get the value that's being throw'n
<evanjs>
yeah that sounds pretty straightforward. yeah, map and map_err in Rust (e.g. for Hyper and etc) comes to mind
<infinisil>
This would also allow more introspectable errors. E.g. you could `builtins.catch (throw { isSomeError = true; __toString = _: "some error"; }) (e: if e ? isSomeError then "is some error" else toString e)
<infinisil>
evanjs: Short explanation of map/map_err for a non-crustacian?
<MichaelRaskin>
Then you need introspecting errors to lead to eventual failure, though
<infinisil>
Though I know how to read rust types I guess
<infinisil>
MichaelRaskin: I'm thinking builtins.catch would also only work for throw's and abort's
<MichaelRaskin>
Otherwise which error gets thrown first becomes an interesting evaluation non-determinism
<MichaelRaskin>
The problem is: imagine you have two throws on the path to success
<MichaelRaskin>
Evaluation order is currently impossible to observe
<infinisil>
MichaelRaskin: I don't think that's a problem though. The purity of languages only has to hold for the successful case
<infinisil>
Oh
<infinisil>
Yeah no I get what you mean
<MichaelRaskin>
tryEval _is_ used for cases where the end result is a succesful evaluation!
nbathum has joined #nix-lang
<evanjs>
yeah I wasn't sure if that was the best example, just the first thing off the top of my head haha
<infinisil>
Yea
<MichaelRaskin>
I don't actually remember; I definitely initially implemented tryEval to catch more and it was patched to catch less
<infinisil>
Hm yeah so I guess builtins.tryEval is actually pure, but the builtins.catch I proposed wouldn't be
<MichaelRaskin>
Returning errors has been discussed since then, I think
<infinisil>
Or maybe rather just some convenient `do` notation
<infinisil>
pie_ mentioned to me that he wanted to use builtins.tryEval for writing a Nix testing tool, but that didn't work well because it didn't catch most problems
<evanjs>
which is basically where I'm coming from as well. I had no clue it's only wired to catch a few specific errors
<evanjs>
I was approaching it as if it was a generic try/catch sort of thing
<infinisil>
I guess the problem stands that a proper tryEval would be impure. Because for any sort of useful error reporting you'd need to actually get the error, which as we discovered earlier is impure
<infinisil>
So I'm not sure if trying to test Nix from within Nix is a good idea
<infinisil>
Maybe you could write a derivation that runs tests though
<evanjs>
pffft what, it's not general purpose? :P
<infinisil>
Hehe
<infinisil>
I've been writing more nixpkgs lib tests recently
<evanjs>
and yeah, maybe not, but I definitely think there are some cases that are simple/common enough to merit being handled in a cleaner fashion
<infinisil>
And I kind of wish there was a better way to do that
<infinisil>
Because currently there's just a bash script that runs `nix-instantiate`
<infinisil>
And there's lib/tests/misc.nix which you can `nix-instantiate --eval --strict` to see if it outputs []
<infinisil>
If it doesn't, it shows the stuff that failed
<infinisil>
(just checks whether two expressions are the same with `==`
<infinisil>
So if you want to test proper error messages you need to use the bash script. If not, you can use the misc.nix
<infinisil>
But both are about equally painful to write
<MichaelRaskin>
infinisil: I guess nowadays one could add a stronger tryEval as a plugin
<pie_>
talking to infinisil elsewhere, summary of my pov on tryeval:
<pie_>
<pie_> infinisil: iirc i specifically wanted tryeval for writing test suites or something
<pie_>
<pie_> theres no (citation needed) reason why it shouldnt work
<pie_>
<pie_> like, you can argue for either side (tryeval is warranted/not) but at the end of the day we have tryeval and it sucks :P
<pie_>
<pie_> anyway i havent thought through this particularly well, im just approaching this from the POV of my usecase
<pie_>
<pie_> where a coding error shouldnt abort the entire tester
<pie_>
<pie_> the summary is i think my usecase is valid and from what i saw in the thread that one time the "only" thing preventing it from working properly is someone doing the work
<MichaelRaskin>
tryEval seems to be still used in Nixpkgs Hydra jobs, so extending it for pure-debug case … has some drawbacks
<pie_>
there is also either a pr or an issue somewhere about making tryeval work for the other 18 out of 20 exceptions that it doesnt work with
* pie_
didnt checks scroll
<MichaelRaskin>
For the record: work has been done specifically to nerf tryEval
<MichaelRaskin>
First version caught everything
<pie_>
maybe have it parametrized like python exception
<pie_>
MichaelRaskin: what do you mean by extending it having drawbacks?
<pie_>
infinisil: if theres anything useful in the discussion here, might be useful to write it up a bit somewhere
<pie_>
otherwise its just lost in irc log
<MichaelRaskin>
Well, people now have ideas that some thing are too broken to even complete evaluation on Hydra
<pie_>
im not sure what that means but it raises the point about whether the interpreter can even survive a failure:
<pie_>
,?
<MichaelRaskin>
REalistically it can
<pie_>
theoretically i dont see why it couldnt but idk if in practice its written such
<MichaelRaskin>
But Eelco said that it should not
<pie_>
so we need interpreter sandboxes :P
<infinisil>
So, what exactly are the use cases of a better tryEval?
<pie_>
didnt clever do somehting with forking() the interpreter at some point? :P
<MichaelRaskin>
Now that sounds like a fragile trick
<pie_>
im probably misremembering soemthing completely unrelated
<infinisil>
MichaelRaskin: Do you perhaps have a ready link to the tryEval nerfing?
<MichaelRaskin>
Let me see…
<pie_>
probably not that many references to it in nixpkgs and nix
<infinisil>
"tryEval shouldn't catch all exceptions of type Error, since not all of them leave the evaluator in a continuable state. Also, it should be less chatty."
<infinisil>
Interesting
<evanjs>
so does it currently handle all errors that _do_ leave the evaluator in a continuable state?
<infinisil>
Wondering the same
<infinisil>
Maybe it could be extended to a bigger set of catchable errors