Newest at the top
| 2024-05-13 22:31:31 +0200 | pavonia | (~user@user/siracusa) |
| 2024-05-13 22:30:00 +0200 | todi | (~todi@p57803331.dip0.t-ipconnect.de) |
| 2024-05-13 22:29:46 +0200 | <Ryan54> | This doesn't seem to work unfortunately. Does conduit not allow you to produce a stream of streams during the pipeline and concatenate them together? I couldn't tell if ConduitT had a MonoFoldable instance. |
| 2024-05-13 22:29:46 +0200 | <Ryan54> | .| mapM_C (liftIO . print) |
| 2024-05-13 22:29:45 +0200 | <Ryan54> | .| concatC |
| 2024-05-13 22:29:45 +0200 | <Ryan54> | .| concatMapMC (waitForQuery env) |
| 2024-05-13 22:29:44 +0200 | <Ryan54> | .| mapMC (startQuery env query) |
| 2024-05-13 22:29:44 +0200 | <Ryan54> | I have a conduit that's calling that based on an input stream: someTextSource |
| 2024-05-13 22:29:43 +0200 | <Ryan54> | -- given an environment and uuid, return a stream of results" (MonadResource m) => Env -> UUID -> ConduitT () [[Maybe Text]] m () |
| 2024-05-13 22:29:43 +0200 | <Ryan54> | Hey all, looking for some help handling a nested Conduit and wondering if I'm going about it wrong. I have a function someFunc that calls paginate on an aws resource, so the signature is |
| 2024-05-13 22:26:33 +0200 | sawilagar | (~sawilagar@user/sawilagar) |
| 2024-05-13 22:24:50 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-05-13 22:24:46 +0200 | Ryan54 | (~Ryan@2601:602:8b00:b0f0:598b:fb7d:e718:eb36) |
| 2024-05-13 22:14:16 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-05-13 22:12:33 +0200 | todi | (~todi@p57803331.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2024-05-13 21:59:23 +0200 | philopsos | (~caecilius@user/philopsos) |
| 2024-05-13 21:56:52 +0200 | philopsos1 | (~caecilius@user/philopsos) (Ping timeout: 246 seconds) |
| 2024-05-13 21:54:25 +0200 | robosexual | (~spaceoyst@5.167.241.127) (Quit: Konversation terminated!) |
| 2024-05-13 21:50:21 +0200 | yin | (~yin@user/zero) (Quit: leaving) |
| 2024-05-13 21:50:11 +0200 | <mauke> | monochrom: in my version of the puzzle, it is very possible that neither box contains the key since all the information you have about the situation came from me |
| 2024-05-13 21:49:56 +0200 | <monochrom> | It's why my really pragmatic choices are starving to death or blowing to death. |
| 2024-05-13 21:49:26 +0200 | <mauke> | hah. "None of the doors actually lead out." |
| 2024-05-13 21:49:17 +0200 | <monochrom> | Yeah I was ready to believe that the lunatic has one more locked room outside my current locked room. |
| 2024-05-13 21:48:29 +0200 | <int-e> | Oh and I also love this take on this general type of puzzle: https://xkcd.com/246/ |
| 2024-05-13 21:48:07 +0200 | <monochrom> | Then you need to appeal to Penrose and hope that your brain has a Geiger counter built-in. |
| 2024-05-13 21:47:52 +0200 | <dolio> | If that's the analogy, then aren't you the one assuming that the program does have undefined behavior even though it doesn't? |
| 2024-05-13 21:47:38 +0200 | <monochrom> | The lunatic didn't give you a Geiger counter, so you probably can't. :) |
| 2024-05-13 21:47:33 +0200 | <EvanR> | like quantum suicide |
| 2024-05-13 21:47:04 +0200 | <EvanR> | i didn't follow the entire discussion but can I fork two processes each opens one of the boxes |
| 2024-05-13 21:46:44 +0200 | <mauke> | similarly, the compiler doesn't worry about it because it is then the programmer's fault |
| 2024-05-13 21:46:28 +0200 | <int-e> | (and many others) |
| 2024-05-13 21:46:27 +0200 | <mauke> | <monochrom> But I don't worry about it because it is then the question's fault. |
| 2024-05-13 21:46:24 +0200 | <int-e> | cf. Gödel |
| 2024-05-13 21:46:14 +0200 | <int-e> | Eh I wouldn't call it blind trust. |
| 2024-05-13 21:45:47 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-05-13 21:45:32 +0200 | <mauke> | and mathematicians are C compilers that blindly assume UB can never happen :-) |
| 2024-05-13 21:45:27 +0200 | <monochrom> | FSVO "like". |
| 2024-05-13 21:45:08 +0200 | <mauke> | this is like the C standard and undefined behavior |
| 2024-05-13 21:44:59 +0200 | <mauke> | ooh, I know what this is |
| 2024-05-13 21:44:43 +0200 | <int-e> | (I feel that a complete solution to the original problem should exhibit a model. Or both :)) |
| 2024-05-13 21:44:37 +0200 | <monochrom> | But I don't worry about it because it is then the question's fault. |
| 2024-05-13 21:44:37 +0200 | rekahsoft | (~rekahsoft@184.148.6.204) |
| 2024-05-13 21:43:50 +0200 | <monochrom> | You are right, but since your version contains a contradiction (equivalently a fixed point equation that has no solution), every complete proof system will prove the same nonsense. This means even natural deduction is vulnerable. |
| 2024-05-13 21:43:40 +0200 | <int-e> | It's not. It's just assumed that the assumptions are consistent, and in your case they aren't. |
| 2024-05-13 21:40:54 +0200 | <mauke> | but what makes this derivation different from the "proof" in the paper? |
| 2024-05-13 21:40:21 +0200 | <mauke> | I consider this derivation defective because you can't just plug some (possibly contradictory) statements into a formula, derive a result according to some logical rules, and then call it a day |
| 2024-05-13 21:39:15 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-13 21:39:05 +0200 | <mauke> | yes :-) |
| 2024-05-13 21:38:57 +0200 | <int-e> | mauke: You can also prove that the portrait is in the silver casket, so you get two portraits! |
| 2024-05-13 21:37:40 +0200 | <monochrom> | My supervisor (that would be the Hehner mentioned in the paper) changed that to the less morbid: The teacher says there is a surprise test this week. :) |