Newest at the top
2025-07-15 23:16:27 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) dtman34 |
2025-07-15 23:15:37 +0200 | Fijxu | (~Fijxu@user/fijxu) (Quit: XD!!) |
2025-07-15 23:13:29 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
2025-07-15 23:12:57 +0200 | falafel | (~falafel@2a0c:5a87:3104:8f01::f709) falafel |
2025-07-15 23:09:20 +0200 | <geekosaur> | (`select()` provides a timeout. it's not even implemented on most OSes, and when it is it isn't very reliable; often the only useful timeout is 0 for a quick poll) |
2025-07-15 23:08:49 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-07-15 23:08:40 +0200 | <geekosaur> | non-threaded probably relies on it playing nicely with `select()`, which… good luck with that |
2025-07-15 23:04:49 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 248 seconds) |
2025-07-15 23:01:52 +0200 | takuan | (~takuan@d8D86B9E9.access.telenet.be) (Remote host closed the connection) |
2025-07-15 22:58:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
2025-07-15 22:56:16 +0200 | Philonous | (~Philonous@user/philonous) Philonous |
2025-07-15 22:55:56 +0200 | Philonous | (~Philonous@user/philonous) (Server closed connection) |
2025-07-15 22:54:23 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
2025-07-15 22:53:25 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-07-15 22:50:58 +0200 | notzmv | (~umar@user/notzmv) (Ping timeout: 248 seconds) |
2025-07-15 22:50:48 +0200 | <EvanR> | threaded being more responsive by a lot |
2025-07-15 22:50:39 +0200 | <EvanR> | jle`, I noticed a distinct difference in responsiveness between threaded and non-threaded |
2025-07-15 22:42:26 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-07-15 22:41:53 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 248 seconds) |
2025-07-15 22:38:42 +0200 | michalz | (~michalz@185.246.207.197) (Remote host closed the connection) |
2025-07-15 22:38:01 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-07-15 22:34:24 +0200 | dutchie | (~dutchie@user/dutchie) dutchie |
2025-07-15 22:34:14 +0200 | tromp | (~textual@2001:1c00:3487:1b00:207a:b700:e4:7b01) |
2025-07-15 22:33:03 +0200 | dutchie | (~dutchie@user/dutchie) (Remote host closed the connection) |
2025-07-15 22:26:59 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
2025-07-15 22:26:20 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
2025-07-15 22:20:23 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
2025-07-15 22:19:57 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-07-15 22:17:53 +0200 | <jle`> | is there a rough estimate on how accurate/precise Control.Concurrent.threadDelay aims to be? the input is in microseconds but ie would we expect a meaningful difference between 1_000_000 and 1_000_010 |
2025-07-15 22:15:05 +0200 | trickard_ | trickard |
2025-07-15 22:09:04 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-07-15 22:07:40 +0200 | caubert | (~caubert@user/caubert) caubert |
2025-07-15 22:06:17 +0200 | <ski> | ("Erlog" by rvirding at <https://github.com/rvirding/erlog> is a Prolog interpreter implemented in Erlang, by one of the original Erlang people) |
2025-07-15 22:06:16 +0200 | <ski> | er |
2025-07-15 22:05:49 +0200 | <ski> | ("" by rvirding at < and for Erlang. Contribute to rvirding/erlog development by creating an account on GitHub.> is a Prolog interpreter implemented in Erlang, by one of the original Erlang people) |
2025-07-15 22:05:17 +0200 | dutchie | (~dutchie@user/dutchie) dutchie |
2025-07-15 22:04:36 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-07-15 22:03:06 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) dtman34 |
2025-07-15 22:01:57 +0200 | dutchie | (~dutchie@user/dutchie) (Ping timeout: 248 seconds) |
2025-07-15 21:59:51 +0200 | <ski> | (Erlang was originally implemented in Prolog) |
2025-07-15 21:58:00 +0200 | <ski> | claimes not both of `m' and `n' can hold, but acts like a query, asking to prove `m' and `n' (by assuming its negation, and trying to derive a contradiction, the empty clause `:-')) |
2025-07-15 21:57:54 +0200 | <ski> | in Prolog, the Horn clause notation `p :- a,b,c' (`p', if `a' and `b' and `c') actually comes from the "disjunction-of-possibly-negated literals" notation `p,-a,-b,-c', where the `,' means "or" (and the previous `:' is a separation between positive and negative literals) (a Horn Clause is a Clause with at most one positive (unnegated) literal. with zero, `:- m,n', alternatively `?- m,n' strictly speaking |
2025-07-15 21:55:16 +0200 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
2025-07-15 21:53:43 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
2025-07-15 21:53:21 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
2025-07-15 21:53:09 +0200 | <ski> | darkling : yes, `;' is "or" (disjunction) in Prolog, and `,' is "and" (conjunction). Erlang also separates multiple defining clauses of the same function with `;', which, logically speaking, makes less sense (`foos([ ]) -> ok; foos([X|Xs]) -> foo(X),foos(Xs).' is supposed to claim that both clauses hold true ..) |
2025-07-15 21:52:12 +0200 | caubert | (~caubert@user/caubert) (Ping timeout: 252 seconds) |
2025-07-15 21:51:29 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Read error: Connection reset by peer) |
2025-07-15 21:51:25 +0200 | <__monty__> | There didn't use to be so many options for in depth Haskell chatting I suppose. |
2025-07-15 21:50:52 +0200 | <__monty__> | Has ups and downs in activity. |