| 2024-07-28 00:00:07 +0200 | <Inst> | https://revisecs.csuk.io/download/004-an-algorithm-a-day-pdf/?wpdmdl=12151&refresh=66a521afd5db917… |
| 2024-07-28 00:03:28 +0200 | <Inst> | the joke is that it just assignns variables without visible IO of any kind, it could easily be replaced simply by a random prompt with sanitization that terminates |
| 2024-07-28 00:03:53 +0200 | <Inst> | but speaking of this, let's say, I main :: IO Int |
| 2024-07-28 00:03:56 +0200 | <Inst> | and pure 4 |
| 2024-07-28 00:04:01 +0200 | <Inst> | is the 4 ever evaluated? |
| 2024-07-28 00:04:05 +0200 | <geekosaur> | no |
| 2024-07-28 00:05:02 +0200 | <geekosaur> | https://play.haskell.org/saved/cfZzXPy8 |
| 2024-07-28 00:05:23 +0200 | <monochrom> | "input(“Enter your dog’s age: ”)" is visible I/O for me. |
| 2024-07-28 00:05:59 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-28 00:08:12 +0200 | <Inst> | yeah, but the computation is superfluous |
| 2024-07-28 00:08:43 +0200 | <geekosaur> | (see https://github.com/ghc-proposals/ghc-proposals/pull/631) |
| 2024-07-28 00:09:50 +0200 | <monochrom> | They are either just missing one output call or assuming that there is more code afterwards that uses the variables. Why are you nitpicking? |
| 2024-07-28 00:10:16 +0200 | <monochrom> | Could you stop wasting my time nitpicking this or should I just put you on /ignore ? |
| 2024-07-28 00:14:19 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2024-07-28 00:15:21 +0200 | tomsmeding | (~tomsmedin@2a01:4f8:c0c:5e5e::2) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2024-07-28 00:15:28 +0200 | jinsun | (~jinsun@user/jinsun) (Read error: Connection reset by peer) |
| 2024-07-28 00:15:55 +0200 | tomsmeding | (~tomsmedin@static.21.109.88.23.clients.your-server.de) |
| 2024-07-28 00:19:13 +0200 | ircbrowse_tom | (~ircbrowse@user/tomsmeding/bot/ircbrowse-tom) |
| 2024-07-28 00:22:05 +0200 | jinsun | (~jinsun@user/jinsun) |
| 2024-07-28 00:23:05 +0200 | <Inst> | well, apologies for the spam, then |
| 2024-07-28 00:41:01 +0200 | dtman34 | (~dtman34@c-174-53-203-90.hsd1.mn.comcast.net) |
| 2024-07-28 00:43:56 +0200 | <Inst> | geekosaur: ideally, on that proposal, main should have been able to return some form of data that could be piped into another program |
| 2024-07-28 00:44:35 +0200 | tjbc | (~tjbc@user/fliife) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-07-28 00:44:43 +0200 | <Inst> | i was thinking about main >>= foo, but since you start from main, you'll never be able to actually use the result of main |
| 2024-07-28 00:45:18 +0200 | <geekosaur> | the original intent was that for very simple programs you could `main = … >> main` |
| 2024-07-28 00:45:27 +0200 | <geekosaur> | but I don't think anyone ever used that |
| 2024-07-28 00:47:37 +0200 | <Inst> | i suppose you could fork IO to get main to terminate and be able to use the result value |
| 2024-07-28 00:50:57 +0200 | <c_wraith> | threads created by forkIO are terminated when main ends |
| 2024-07-28 00:52:15 +0200 | <geekosaur> | (and if the RTS didn't do this, the OS would; the main thread is special, since it's the process) |
| 2024-07-28 00:53:43 +0200 | <c_wraith> | That's still an RTS detail. in contrast, java programs stay active when main ends if there's a non-daemon thread running. That's a java runtime detail. |
| 2024-07-28 00:53:45 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Quit: ChaiTRex) |
| 2024-07-28 00:54:16 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2024-07-28 01:16:56 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb1421aec5076afe4c64.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2024-07-28 01:18:39 +0200 | sindu | (~sindu@83-243-191-191.fth.tafjordconnect.net) (Ping timeout: 276 seconds) |
| 2024-07-28 01:20:07 +0200 | pavonia | (~user@user/siracusa) |
| 2024-07-28 01:27:19 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2024-07-28 01:27:26 +0200 | prolic_ | (~sasa@181.122.138.24) |
| 2024-07-28 01:27:49 +0200 | fliife | (~fliife@user/fliife) |
| 2024-07-28 01:29:00 +0200 | prolic_ | (~sasa@181.122.138.24) (Remote host closed the connection) |
| 2024-07-28 01:29:36 +0200 | bolivood | (~bolivood@2a0d:6fc2:5d11:200:dac:74e5:33ad:6838) (Ping timeout: 272 seconds) |
| 2024-07-28 01:30:41 +0200 | fliife | (~fliife@user/fliife) (Quit: ZNC - https://znc.in) |
| 2024-07-28 01:32:40 +0200 | tjbc | (~tjbc@user/fliife) |
| 2024-07-28 01:32:42 +0200 | bolivood | (~bolivood@2a0d:6fc2:5d11:200:d189:8884:fd00:6a5d) |
| 2024-07-28 01:34:53 +0200 | <monochrom> | I bet theoretically the committee thought that one could have even "main >>= \x -> ..." for non-trivial x. In particular in the REPL if you have "main = pure 4" the REPL evals and prints that 4 too. (I used to use that with HUnit.) |
| 2024-07-28 01:34:54 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-07-28 01:35:10 +0200 | <monochrom> | But of course by now we pretty much realize that no one will miss it. :) |
| 2024-07-28 01:35:57 +0200 | <monochrom> | (I no longer use that feature, too.) |
| 2024-07-28 01:40:07 +0200 | <Inst> | iirc the module and dependency system in Haskell wasn't that carefully designed, right? It was sort of an afterthought? |
| 2024-07-28 01:40:29 +0200 | <Inst> | conceptually you could have two libraries with main as their interface |
| 2024-07-28 01:40:40 +0200 | <Inst> | that could be run standalone, but could also provide useful return values |
| 2024-07-28 01:40:55 +0200 | tjbc | (~tjbc@user/fliife) (Quit: ZNC - https://znc.in) |
| 2024-07-28 01:41:37 +0200 | tjbc | (~tjbc@user/fliife) |
| 2024-07-28 01:41:54 +0200 | <geekosaur> | not even conceptually. nothing prevents it except that ghc makes assumptions about module `Main` (or whatever module is identified by `-main-is`) |
| 2024-07-28 01:41:57 +0200 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2024-07-28 01:49:42 +0200 | <Inst> | I guess it just wasn't that useful to chain together side effects in that way |
| 2024-07-28 02:02:07 +0200 | <geekosaur> | `main` isn't special. you can always access some other module's `main` qualified |
| 2024-07-28 02:02:20 +0200 | <geekosaur> | module `Main` is special (check the Report) |
| 2024-07-28 02:02:52 +0200 | <geekosaur> | (and `main` in some other module can have any type) |
| 2024-07-28 02:04:58 +0200 | <Inst> | no, but let's say you have some package that has Main somewhere, under Main is, with module Main (iirc this is compulsory) |
| 2024-07-28 02:05:23 +0200 | <Inst> | there's no way to differentiate between this module Main and the actual module Main you're using, no? |
| 2024-07-28 02:06:03 +0200 | <geekosaur> | no, but module Main is considered reserved — libraries are expected not to use it |
| 2024-07-28 02:06:49 +0200 | <Inst> | ancient |
| 2024-07-28 02:06:57 +0200 | <geekosaur> | ghc allows you to change this, by using `-main-is` to point to a different module as the main module (and optionally a different binding within that module, provided its type unifies with `IO a`) |
| 2024-07-28 02:06:58 +0200 | <Inst> | oh well |
| 2024-07-28 02:07:00 +0200 | <Inst> | https://stackoverflow.com/questions/27591266/telling-cabal-where-the-main-module-is |
| 2024-07-28 02:07:30 +0200 | <geekosaur> | also note that a cabal file's "main-is" is subtly different from ghc's -main-is |
| 2024-07-28 02:08:43 +0200 | <Inst> | main-is afaik has to point to a file containing module Main, right? |
| 2024-07-28 02:09:45 +0200 | <Inst> | yeah, there are more recent responses on that stackexchange |
| 2024-07-28 02:09:57 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 248 seconds) |
| 2024-07-28 02:10:54 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2024-07-28 02:12:39 +0200 | <geekosaur> | (libraries *could* meaningfully do that kind of thing, though, specifically to allow use of Haskell plugins via FFI from C etc.; see hs_init() (https://downloads.haskell.org/ghc/9.10.1/docs/users_guide/exts/ffi.html#using-your-own-main) |
| 2024-07-28 02:25:11 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-07-28 02:37:27 +0200 | Guest|44 | (~Guest|44@218.159.198.13) |
| 2024-07-28 02:44:29 +0200 | tomku | (~tomku@user/tomku) (Ping timeout: 260 seconds) |
| 2024-07-28 02:45:08 +0200 | Guest|44 | (~Guest|44@218.159.198.13) (Quit: Connection closed) |
| 2024-07-28 02:55:09 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 260 seconds) |
| 2024-07-28 02:57:00 +0200 | bolivood | (~bolivood@2a0d:6fc2:5d11:200:d189:8884:fd00:6a5d) (Ping timeout: 272 seconds) |
| 2024-07-28 03:13:43 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-28 03:15:00 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-07-28 03:19:04 +0200 | ystael | (~ystael@user/ystael) (Ping timeout: 260 seconds) |
| 2024-07-28 03:24:29 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-07-28 03:34:01 +0200 | Guest|44 | (~Guest|44@218.159.198.13) |
| 2024-07-28 03:43:12 +0200 | itaipu | (~itaipu@168.121.98.250) (Ping timeout: 252 seconds) |
| 2024-07-28 03:56:32 +0200 | itaipu | (~itaipu@168.121.98.206) |
| 2024-07-28 03:56:46 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-07-28 03:58:01 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-07-28 04:05:03 +0200 | op_4 | (~tslil@user/op-4/x-9116473) (Remote host closed the connection) |
| 2024-07-28 04:05:34 +0200 | op_4 | (~tslil@user/op-4/x-9116473) |
| 2024-07-28 04:11:24 +0200 | td_ | (~td@i53870913.versanet.de) (Ping timeout: 260 seconds) |
| 2024-07-28 04:13:00 +0200 | td_ | (~td@i5387090A.versanet.de) |
| 2024-07-28 04:19:44 +0200 | Guest|44 | (~Guest|44@218.159.198.13) (Quit: Connection closed) |
| 2024-07-28 04:21:24 +0200 | tomku | (~tomku@user/tomku) |
| 2024-07-28 04:36:03 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2024-07-28 04:36:40 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2024-07-28 04:39:13 +0200 | manwithluck | (manwithluc@gateway/vpn/protonvpn/manwithluck) (Ping timeout: 248 seconds) |
| 2024-07-28 04:39:52 +0200 | manwithluck | (manwithluc@gateway/vpn/protonvpn/manwithluck) |
| 2024-07-28 04:42:57 +0200 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) (Ping timeout: 248 seconds) |
| 2024-07-28 04:44:13 +0200 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) |
| 2024-07-28 05:03:20 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-07-28 05:06:43 +0200 | sindu | (~sindu@83-243-191-191.fth.tafjordconnect.net) |
| 2024-07-28 05:08:41 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 255 seconds) |
| 2024-07-28 05:22:09 +0200 | sindu | (~sindu@83-243-191-191.fth.tafjordconnect.net) (Ping timeout: 260 seconds) |
| 2024-07-28 05:31:43 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2024-07-28 05:32:51 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-07-28 05:44:51 +0200 | aforemny_ | (~aforemny@i59F516E4.versanet.de) |
| 2024-07-28 05:45:36 +0200 | aforemny | (~aforemny@2001:9e8:6cde:f100:f13d:7189:cb6f:5d03) (Ping timeout: 244 seconds) |
| 2024-07-28 05:56:19 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-07-28 06:28:21 +0200 | xff0x | (~xff0x@2405:6580:b080:900:8b26:ef3c:7f31:7c41) (Ping timeout: 265 seconds) |
| 2024-07-28 06:39:42 +0200 | xff0x | (~xff0x@2405:6580:b080:900:333f:570b:ae7a:3a3d) |
| 2024-07-28 06:47:49 +0200 | Guest36 | (~Guest85@78.135.8.93) |
| 2024-07-28 07:06:15 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-07-28 07:06:45 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-28 07:09:59 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-28 07:10:00 +0200 | <Guest36> | I was working through the Functional Pearl, Probabilistic Functional Programming. It's a nice paper. There is a `selectP :: (Num prob, Ord prob) => T prob a -> prob -> a` which seems reasonable to me. For this question let's say `prob` is `Float` and `T prob a` is `[(Float, a)]`. The implementation of `selectP` looks at the head of the distribution |
| 2024-07-28 07:10:01 +0200 | <Guest36> | and if the outcome's probability, say `q`, is greater than the 2nd arg (ie, probability as a `float`), say `p`, it recurses over the tail of the distribution but with `p-q`. Can someone give some intuition on what that is achieving (there is no specified ordering of distribution elements by their probability, afaics, the `Ord` constraint seems to |
| 2024-07-28 07:10:01 +0200 | <Guest36> | be only for the `p<=q` test)? |
| 2024-07-28 07:10:40 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Client Quit) |
| 2024-07-28 07:16:57 +0200 | <Guest36> | If it was the case that the distribution is known to be unaggregated (ie the same outcome can appear more than once), and the list grouped equivalent outcomes together, then maybe it would make a bit more sense to me, but still not porperly, because it would always return the first outcome that is more likely to occur than `p`. |
| 2024-07-28 07:17:29 +0200 | <mauke> | https://web.engr.oregonstate.edu/~erwig/papers/PFP_JFP06.pdf |
| 2024-07-28 07:17:35 +0200 | <Guest36> | yes |
| 2024-07-28 07:17:55 +0200 | <Guest36> | and I am looking at the code for probability-0.2.8 |
| 2024-07-28 07:19:05 +0200 | <glguy> | If all the probabilities in the list add up to N and your random number is in the range 0-N you're getting a weighted sampling of the elements in the list |
| 2024-07-28 07:19:07 +0200 | <Guest36> | (which is newer than the paper's downloadable code tar) |
| 2024-07-28 07:19:19 +0200 | <Guest36> | OK |
| 2024-07-28 07:20:38 +0200 | <Guest36> | if the list is not ordered, you would eat up `p` at each step and then choose some outcome which might have nothing to do with the ones that ate up most of your `p` |
| 2024-07-28 07:20:55 +0200 | <glguy> | The order wouldn't matter |
| 2024-07-28 07:21:09 +0200 | <Guest36> | that's the bit I don't see, I suppose |
| 2024-07-28 07:21:10 +0200 | <glguy> | Because of the p-q part you mentioned |
| 2024-07-28 07:21:27 +0200 | <Guest36> | `p-q` is what I mean by eat |
| 2024-07-28 07:21:41 +0200 | <Guest36> | *eat up |
| 2024-07-28 07:22:03 +0200 | <Guest36> | am I thinking incorrectly? |
| 2024-07-28 07:22:20 +0200 | <glguy> | It's the sum of the probabilities that matters, not the order |
| 2024-07-28 07:23:08 +0200 | <Guest36> | right, but you are jumping over outcomes that did some of the eating up of p |
| 2024-07-28 07:23:14 +0200 | <glguy> | So if you've got probabilities 1,1,2,3. Pick a number between 0 and 7 |
| 2024-07-28 07:23:28 +0200 | <glguy> | The first 0-1 are for the first element |
| 2024-07-28 07:23:54 +0200 | <glguy> | 1-2 for the next, 2-4 will pick the third, 4-7 the last |
| 2024-07-28 07:24:09 +0200 | <glguy> | With a tie breaking rule for exact matches |
| 2024-07-28 07:24:23 +0200 | billchenchina- | (~billchenc@210.110.131.60) |
| 2024-07-28 07:24:41 +0200 | <Guest36> | right, but if the order was different you would get a different outcome returned, no? |
| 2024-07-28 07:25:12 +0200 | <glguy> | You'd get the same distribution |
| 2024-07-28 07:25:53 +0200 | <glguy> | You'd get different values for different random indexes, but that doesn't matter |
| 2024-07-28 07:25:55 +0200 | <Guest36> | so, we are returning an `a` (outcome) |
| 2024-07-28 07:26:16 +0200 | <Guest36> | not a distrubution |
| 2024-07-28 07:26:37 +0200 | <glguy> | But you'd have the same likelihood of each outcome |
| 2024-07-28 07:26:45 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) (Ping timeout: 248 seconds) |
| 2024-07-28 07:26:51 +0200 | <glguy> | It's a distribution of outcomes |
| 2024-07-28 07:27:22 +0200 | <Guest36> | I was trying it out in VSCode with HLS |
| 2024-07-28 07:27:22 +0200 | <Guest36> | ``` |
| 2024-07-28 07:27:23 +0200 | <Guest36> | -- >>> [scanP x [(1, 0.6), (2, 0.1), (3, 0.2)] | x <- [0.5, 0.6, 0.7, 0.8, 0.9]] |
| 2024-07-28 07:27:23 +0200 | <Guest36> | -- [1,1,2,3,3] |
| 2024-07-28 07:27:24 +0200 | <Guest36> | ``` |
| 2024-07-28 07:27:39 +0200 | <Guest36> | where `selectP` just calls `scanP` |
| 2024-07-28 07:28:09 +0200 | <Guest36> | but I still don't understand what it is acheiving |
| 2024-07-28 07:29:03 +0200 | <glguy> | It's choosing one element from a finite list of elements |
| 2024-07-28 07:29:13 +0200 | <glguy> | Not necessarily uniformly |
| 2024-07-28 07:29:25 +0200 | <Guest36> | if we had to write a 1 line doc comment, or whatever we call that in haskell, for `selectP` what precisely would it say? |
| 2024-07-28 07:29:58 +0200 | <glguy> | Element an element from a weighted finite distribution |
| 2024-07-28 07:30:00 +0200 | <Guest36> | there is something that, to me, is not apparent just from the types |
| 2024-07-28 07:30:42 +0200 | <glguy> | Select an element from* |
| 2024-07-28 07:31:18 +0200 | <Guest36> | but what does the `p` signify, if you are just traversing the list until you at up `p`? |
| 2024-07-28 07:31:40 +0200 | <glguy> | The weight |
| 2024-07-28 07:32:22 +0200 | <glguy> | If one element's p is twice as much as another's then it's twice as likely to be selected |
| 2024-07-28 07:32:36 +0200 | <Guest36> | let's say the distribution is both aggregated and normalised (ie each outcome is unique and the total probability is 1( |
| 2024-07-28 07:33:03 +0200 | <glguy> | Ok |
| 2024-07-28 07:33:53 +0200 | <Guest36> | "If one element's p is twice as much as another's then it's twice as likely to be selected" that might be what I don't find obvious, because that "big one" ,ight be at the end of the list, and it will never get reached if the complement is > p |
| 2024-07-28 07:34:41 +0200 | <mauke> | imagine selectP's second argument ranges from 0 to 1, continuously, uniformly |
| 2024-07-28 07:34:57 +0200 | <Guest36> | so the accidental ordering would be significant |
| 2024-07-28 07:34:58 +0200 | <Guest36> | OK |
| 2024-07-28 07:35:24 +0200 | <glguy> | Just think about the simple case : 1/3 and 2/3 |
| 2024-07-28 07:35:31 +0200 | <Guest36> | OK |
| 2024-07-28 07:35:46 +0200 | <glguy> | Order then ascendinh |
| 2024-07-28 07:36:10 +0200 | <Guest36> | but that is what is missing, iiuc - there is no implied ordering |
| 2024-07-28 07:36:10 +0200 | <glguy> | 1/3 of the time you pick the first element, leaving the second for the other 2/3 |
| 2024-07-28 07:36:26 +0200 | <glguy> | Ok now order them the other way |
| 2024-07-28 07:36:35 +0200 | <Guest36> | ohh!!! |
| 2024-07-28 07:36:37 +0200 | <glguy> | 2/3 of the time you pick the first element |
| 2024-07-28 07:36:38 +0200 | <Guest36> | yes |
| 2024-07-28 07:36:45 +0200 | <Guest36> | nice example, thanks |
| 2024-07-28 07:37:22 +0200 | <mauke> | I need some wooden blocks to illustrate this |
| 2024-07-28 07:37:42 +0200 | <glguy> | Yeah, pictures > text here |
| 2024-07-28 07:37:45 +0200 | <Guest36> | so, as you previously said, the distribution of returned outcomes is the same |
| 2024-07-28 07:38:32 +0200 | <mauke> | each outcome gets an associated color and a block of that color |
| 2024-07-28 07:38:46 +0200 | <mauke> | the probability of the outcome corresponds to the length of the block |
| 2024-07-28 07:38:57 +0200 | <Guest36> | nice |
| 2024-07-28 07:39:08 +0200 | <mauke> | you stack the blocks up (and because probabilities are normalized, the stack has total length 1) |
| 2024-07-28 07:39:41 +0200 | <mauke> | then you pick a random distance between 0 and 1 and see which color you land on |
| 2024-07-28 07:39:56 +0200 | <Guest36> | not normailsed and not aggregated would not change anything, if my intuition is now better! |
| 2024-07-28 07:40:27 +0200 | <Guest36> | precisely because the orsed does not matter, as you have both demonstrated |
| 2024-07-28 07:42:45 +0200 | <Guest36> | mauke I think the next sentence is the key but is missing (because it is "probably" obvious to most) - if you repeat this repeatedly, you will get a distribution of outcomes consistent with the original distribution |
| 2024-07-28 07:44:40 +0200 | <mauke> | yes, that's important |
| 2024-07-28 07:44:52 +0200 | <mauke> | that's why I started with "imagine selectP's second argument ranges from 0 to 1, continuously, uniformly" |
| 2024-07-28 07:44:59 +0200 | <Guest36> | right |
| 2024-07-28 07:45:18 +0200 | <mauke> | if you only look at an individual result, it makes no sense |
| 2024-07-28 07:45:53 +0200 | <Guest36> | exactly - so I can only see a meaningful use for it in the _random_ sampling |
| 2024-07-28 07:46:44 +0200 | <Guest36> | where you want to approximate, for example, because the transitions explode exponentially |
| 2024-07-28 07:50:48 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2024-07-28 07:55:00 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) (Read error: Connection reset by peer) |
| 2024-07-28 07:57:36 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) |
| 2024-07-28 07:57:43 +0200 | Inst | (~Inst@user/Inst) (Ping timeout: 264 seconds) |
| 2024-07-28 07:59:42 +0200 | <Guest36> | btw, also just watched the first few minutes of https://www.youtube.com/watch?v=LHlZNYFraAs which seems to start off covering similar material to the paper |
| 2024-07-28 07:59:44 +0200 | Enrico63 | (~Enrico63@81.109.143.226) |
| 2024-07-28 08:04:02 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2024-07-28 08:04:32 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2024-07-28 08:12:12 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-07-28 08:20:52 +0200 | Midjak | (~MarciZ@82.66.147.146) |
| 2024-07-28 08:33:25 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) (Ping timeout: 248 seconds) |
| 2024-07-28 08:33:46 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) |
| 2024-07-28 08:44:22 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) (Ping timeout: 244 seconds) |
| 2024-07-28 08:47:34 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) |
| 2024-07-28 08:52:53 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-28 08:56:39 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-07-28 09:00:02 +0200 | tt123109783 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) (Quit: The Lounge - https://thelounge.chat) |
| 2024-07-28 09:01:34 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-07-28 09:02:38 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-28 09:03:09 +0200 | tt123109783 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) |
| 2024-07-28 09:04:28 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-07-28 09:04:42 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-28 09:08:15 +0200 | rosco | (~rosco@125.235.232.224) |
| 2024-07-28 09:21:05 +0200 | Enrico63 | (~Enrico63@81.109.143.226) (Ping timeout: 256 seconds) |
| 2024-07-28 09:31:47 +0200 | billchenchina- | (~billchenc@210.110.131.60) (Remote host closed the connection) |
| 2024-07-28 09:33:13 +0200 | random-jellyfish | (~developer@2a02:2f04:11e:c600:779f:e83c:9dc:b111) |
| 2024-07-28 09:33:13 +0200 | random-jellyfish | (~developer@2a02:2f04:11e:c600:779f:e83c:9dc:b111) (Changing host) |
| 2024-07-28 09:33:13 +0200 | random-jellyfish | (~developer@user/random-jellyfish) |
| 2024-07-28 09:33:48 +0200 | random-jellyfish | (~developer@user/random-jellyfish) (Remote host closed the connection) |
| 2024-07-28 09:38:16 +0200 | rosco | (~rosco@125.235.232.224) (Quit: Lost terminal) |
| 2024-07-28 09:42:08 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb26f8bec10a4528cded.dip0.t-ipconnect.de) |
| 2024-07-28 09:44:48 +0200 | billchenchina- | (~billchenc@223.39.249.79) |
| 2024-07-28 09:45:57 +0200 | billchenchina- | (~billchenc@223.39.249.79) (Max SendQ exceeded) |
| 2024-07-28 09:46:34 +0200 | billchenchina- | (~billchenc@223.39.249.79) |
| 2024-07-28 09:46:38 +0200 | billchenchina- | (~billchenc@223.39.249.79) (Read error: Connection reset by peer) |
| 2024-07-28 09:47:14 +0200 | billchenchina- | (~billchenc@223.39.249.79) |
| 2024-07-28 09:52:07 +0200 | Midjak | (~MarciZ@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2024-07-28 09:54:52 +0200 | billchenchina- | (~billchenc@223.39.249.79) (Quit: Leaving) |
| 2024-07-28 09:57:54 +0200 | Guest36 | (~Guest85@78.135.8.93) (Quit: Client closed) |
| 2024-07-28 10:01:11 +0200 | aforemny | (~aforemny@2001:9e8:6cff:de00:eb46:da28:87cf:ea64) |
| 2024-07-28 10:01:42 +0200 | billchenchina- | (~billchenc@223.39.249.79) |
| 2024-07-28 10:01:59 +0200 | aforemny_ | (~aforemny@i59F516E4.versanet.de) (Ping timeout: 260 seconds) |
| 2024-07-28 10:08:23 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-07-28 10:10:12 +0200 | euphores | (~SASL_euph@user/euphores) (Ping timeout: 272 seconds) |
| 2024-07-28 10:13:34 +0200 | aforemny_ | (~aforemny@i59F516D5.versanet.de) |
| 2024-07-28 10:14:33 +0200 | aforemny | (~aforemny@2001:9e8:6cff:de00:eb46:da28:87cf:ea64) (Ping timeout: 265 seconds) |
| 2024-07-28 10:21:17 +0200 | bolivood | (~bolivood@2a0d:6fc2:5d11:200:f40e:2cee:2d7a:1389) |
| 2024-07-28 10:22:03 +0200 | aforemny_ | (~aforemny@i59F516D5.versanet.de) (Ping timeout: 245 seconds) |
| 2024-07-28 10:23:43 +0200 | aforemny | (~aforemny@2001:9e8:6cc0:600:cc61:be70:932b:db06) |
| 2024-07-28 10:25:07 +0200 | lockywolf | (~lockywolf@public.lockywolf.net) (Ping timeout: 244 seconds) |
| 2024-07-28 10:30:38 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-07-28 10:34:33 +0200 | mhatta | (~mhatta@www21123ui.sakura.ne.jp) (Quit: ZNC 1.9.1+deb1 - https://znc.in) |
| 2024-07-28 10:35:25 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-07-28 10:50:14 +0200 | __monty__ | (~toonn@user/toonn) |
| 2024-07-28 10:53:50 +0200 | billchenchina- | (~billchenc@223.39.249.79) (Ping timeout: 255 seconds) |
| 2024-07-28 10:55:06 +0200 | billchenchina- | (~billchenc@118.47.143.29) |
| 2024-07-28 11:04:10 +0200 | billchenchina- | (~billchenc@118.47.143.29) (Remote host closed the connection) |
| 2024-07-28 11:07:03 +0200 | sp1ff | (~user@c-73-11-70-111.hsd1.wa.comcast.net) (Remote host closed the connection) |
| 2024-07-28 11:09:25 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) (Ping timeout: 252 seconds) |
| 2024-07-28 11:12:17 +0200 | hayk | (~hayk@141.136.90.108) |
| 2024-07-28 11:12:21 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-07-28 11:13:30 +0200 | `2jt` | (~user@46.6.57.213) |
| 2024-07-28 11:14:39 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 2024-07-28 11:15:06 +0200 | `2jt` | (~user@46.6.57.213) (Client Quit) |
| 2024-07-28 11:15:52 +0200 | hayk | (~hayk@141.136.90.108) (Quit: hayk) |
| 2024-07-28 11:16:25 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) |
| 2024-07-28 11:16:37 +0200 | hayk | (~hayk@141.136.90.108) |
| 2024-07-28 11:19:29 +0200 | sroso | (~sroso@user/SrOso) |
| 2024-07-28 11:21:21 +0200 | hayk | (~hayk@141.136.90.108) (Quit: hayk) |
| 2024-07-28 11:27:51 +0200 | target_i | (~target_i@user/target-i/x-6023099) |
| 2024-07-28 11:27:55 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-07-28 11:46:57 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) |
| 2024-07-28 11:51:39 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) (Ping timeout: 260 seconds) |
| 2024-07-28 11:56:53 +0200 | euphores | (~SASL_euph@user/euphores) (Remote host closed the connection) |
| 2024-07-28 12:06:28 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-07-28 12:06:39 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-07-28 12:08:47 +0200 | califax | (~califax@user/califx) |
| 2024-07-28 12:11:12 +0200 | andrea_r | (~user@93-49-96-212.ip366.fastwebnet.it) |
| 2024-07-28 12:13:27 +0200 | michalz | (~michalz@185.246.207.222) |
| 2024-07-28 12:27:24 +0200 | bolivood | (~bolivood@2a0d:6fc2:5d11:200:f40e:2cee:2d7a:1389) (Ping timeout: 260 seconds) |
| 2024-07-28 12:28:32 +0200 | Midjak | (~MarciZ@82.66.147.146) |
| 2024-07-28 12:29:05 +0200 | hueso | (~root@user/hueso) (Ping timeout: 248 seconds) |
| 2024-07-28 12:29:25 +0200 | bolivood | (~bolivood@2a0d:6fc2:5d11:200:640e:d7d:9ee3:bd0) |
| 2024-07-28 12:30:13 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-07-28 12:32:24 +0200 | GoldsteinQ | (~goldstein@goldstein.rs) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-07-28 12:36:05 +0200 | GoldsteinQ | (~goldstein@goldstein.rs) |
| 2024-07-28 12:38:37 +0200 | michalz | (~michalz@185.246.207.222) (Remote host closed the connection) |
| 2024-07-28 12:40:15 +0200 | hueso | (~root@user/hueso) |
| 2024-07-28 12:41:04 +0200 | CiaoSen | (~Jura@2a05:5800:205:1000:e6b9:7aff:fe80:3d03) |
| 2024-07-28 12:41:14 +0200 | michalz | (~michalz@185.246.207.197) |
| 2024-07-28 12:47:15 +0200 | Square2 | (~Square@user/square) (Ping timeout: 252 seconds) |
| 2024-07-28 13:04:12 +0200 | bolivood | (~bolivood@2a0d:6fc2:5d11:200:640e:d7d:9ee3:bd0) (Ping timeout: 265 seconds) |
| 2024-07-28 13:22:25 +0200 | bolivood | (~bolivood@2a0d:6fc2:5d11:200:dda7:803d:d0e7:4256) |
| 2024-07-28 13:23:32 +0200 | CiaoSen | (~Jura@2a05:5800:205:1000:e6b9:7aff:fe80:3d03) (Ping timeout: 265 seconds) |
| 2024-07-28 13:25:20 +0200 | sroso | (~sroso@user/SrOso) (Quit: Leaving :)) |
| 2024-07-28 13:26:54 +0200 | michalz | (~michalz@185.246.207.197) (Ping timeout: 260 seconds) |
| 2024-07-28 13:26:55 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb26f8bec10a4528cded.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2024-07-28 13:39:01 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) (Ping timeout: 248 seconds) |
| 2024-07-28 13:39:23 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) |
| 2024-07-28 13:41:08 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-28 13:53:14 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-07-28 13:54:33 +0200 | misterfish | (~misterfis@84.53.85.146) (Read error: Connection reset by peer) |
| 2024-07-28 13:59:12 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-07-28 14:04:27 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-07-28 14:07:37 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-07-28 14:08:51 +0200 | euleritian | (~euleritia@dynamic-176-006-130-041.176.6.pool.telefonica.de) |
| 2024-07-28 14:10:42 +0200 | CrunchyFlakes | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) |
| 2024-07-28 14:18:14 +0200 | CrunchyFlakes | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) (Ping timeout: 260 seconds) |
| 2024-07-28 14:20:12 +0200 | bolivood | (~bolivood@2a0d:6fc2:5d11:200:dda7:803d:d0e7:4256) (Ping timeout: 244 seconds) |
| 2024-07-28 14:23:33 +0200 | CrunchyFlakes | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) |
| 2024-07-28 14:33:21 +0200 | michalz | (~michalz@185.246.207.217) |
| 2024-07-28 14:44:18 +0200 | itaipu | (~itaipu@168.121.98.206) (Ping timeout: 252 seconds) |
| 2024-07-28 14:48:25 +0200 | tabaqui | (~root@87.200.123.114) |
| 2024-07-28 14:48:30 +0200 | tabaqui | (~root@87.200.123.114) (Client Quit) |
| 2024-07-28 14:49:25 +0200 | tabaqui | (~root@87.200.123.114) |
| 2024-07-28 14:51:54 +0200 | visilii_ | (~visilii@213.24.125.104) (Ping timeout: 260 seconds) |
| 2024-07-28 14:52:58 +0200 | euleritian | (~euleritia@dynamic-176-006-130-041.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-28 14:53:16 +0200 | euleritian | (~euleritia@77.22.252.56) |
| 2024-07-28 14:57:12 +0200 | Inst | (~Inst@user/Inst) |
| 2024-07-28 14:57:35 +0200 | itaipu | (~itaipu@168.121.98.206) |
| 2024-07-28 15:21:27 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-28 15:33:17 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 255 seconds) |
| 2024-07-28 15:35:03 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-07-28 15:42:15 +0200 | AlexZenon | (~alzenon@94.233.241.102) (Ping timeout: 265 seconds) |
| 2024-07-28 15:44:40 +0200 | petrichor | (~znc-user@user/petrichor) (Ping timeout: 265 seconds) |
| 2024-07-28 15:56:10 +0200 | AlexZenon | (~alzenon@94.233.241.102) |
| 2024-07-28 16:05:46 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-07-28 16:06:10 +0200 | AlexZenon | (~alzenon@94.233.241.102) (Quit: ;-) |
| 2024-07-28 16:07:13 +0200 | AlexNoo | (~AlexNoo@94.233.241.102) (Quit: Leaving) |
| 2024-07-28 16:10:54 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-07-28 16:16:49 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb26bd154e804722854a.dip0.t-ipconnect.de) |
| 2024-07-28 16:17:04 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) (Ping timeout: 252 seconds) |
| 2024-07-28 16:18:15 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-07-28 16:21:09 +0200 | euleritian | (~euleritia@77.22.252.56) (Ping timeout: 248 seconds) |
| 2024-07-28 16:21:26 +0200 | euleritian | (~euleritia@dynamic-176-006-130-041.176.6.pool.telefonica.de) |
| 2024-07-28 16:25:11 +0200 | euleritian | (~euleritia@dynamic-176-006-130-041.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-28 16:25:33 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-28 16:38:09 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 248 seconds) |
| 2024-07-28 16:38:23 +0200 | euleritian | (~euleritia@dynamic-176-006-130-041.176.6.pool.telefonica.de) |
| 2024-07-28 16:44:21 +0200 | AlexZenon | (~alzenon@94.233.241.102) |
| 2024-07-28 16:44:32 +0200 | AlexNoo | (~AlexNoo@94.233.241.102) |
| 2024-07-28 16:47:25 +0200 | AlexNoo_ | (~AlexNoo@94.233.241.102) |
| 2024-07-28 16:47:43 +0200 | AlexZenon_2 | (~alzenon@94.233.241.102) |
| 2024-07-28 16:48:15 +0200 | euleritian | (~euleritia@dynamic-176-006-130-041.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-28 16:48:35 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-28 16:51:29 +0200 | AlexZenon | (~alzenon@94.233.241.102) (Ping timeout: 260 seconds) |
| 2024-07-28 16:51:43 +0200 | AlexNoo | (~AlexNoo@94.233.241.102) (Ping timeout: 264 seconds) |
| 2024-07-28 16:52:38 +0200 | AlexZenon | (~alzenon@94.233.241.102) |
| 2024-07-28 16:53:09 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 248 seconds) |
| 2024-07-28 16:53:39 +0200 | euleritian | (~euleritia@dynamic-176-006-130-041.176.6.pool.telefonica.de) |
| 2024-07-28 16:56:08 +0200 | danza | (~danza@user/danza) |
| 2024-07-28 16:56:44 +0200 | sssgemooo | (~sssgemooo@syn-069-203-107-019.res.spectrum.com) |
| 2024-07-28 16:58:02 +0200 | <sssgemooo> | Are there specific libraries to optimize audio Graphs? Which Graph library would allow some flexibility to adapt it? |
| 2024-07-28 16:58:29 +0200 | AlexZenon | (~alzenon@94.233.241.102) (Quit: ;-) |
| 2024-07-28 16:59:23 +0200 | AlexNoo_ | AlexNoo |
| 2024-07-28 17:02:36 +0200 | <sssgemooo> | https://hackage.haskell.org/package/hsc3-0.20/docs/Sound-Sc3-Ugen-Graph-Transform.html |
| 2024-07-28 17:15:36 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-07-28 17:19:21 +0200 | euleritian | (~euleritia@dynamic-176-006-130-041.176.6.pool.telefonica.de) (Ping timeout: 276 seconds) |
| 2024-07-28 17:21:17 +0200 | euleritian | (~euleritia@dynamic-176-000-159-039.176.0.pool.telefonica.de) |
| 2024-07-28 17:45:36 +0200 | jerg | (~jerg@2001:a61:2510:4100::bb0) |
| 2024-07-28 17:48:34 +0200 | sindu | (~sindu@83-243-191-191.fth.tafjordconnect.net) |
| 2024-07-28 17:52:13 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-07-28 18:01:32 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-28 18:03:26 +0200 | placidusax | (~user@user/meritamen) |
| 2024-07-28 18:04:11 +0200 | placidusax | (~user@user/meritamen) () |
| 2024-07-28 18:11:36 +0200 | euleritian | (~euleritia@dynamic-176-000-159-039.176.0.pool.telefonica.de) (Ping timeout: 265 seconds) |
| 2024-07-28 18:18:30 +0200 | sindu | (~sindu@83-243-191-191.fth.tafjordconnect.net) (Ping timeout: 276 seconds) |
| 2024-07-28 18:24:44 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 255 seconds) |
| 2024-07-28 18:26:45 +0200 | danza | (~danza@user/danza) (Quit: gotta go) |
| 2024-07-28 18:30:14 +0200 | jerg | (~jerg@2001:a61:2510:4100::bb0) (Ping timeout: 260 seconds) |
| 2024-07-28 18:31:50 +0200 | sssgemooo | (~sssgemooo@syn-069-203-107-019.res.spectrum.com) (Quit: Client closed) |
| 2024-07-28 18:38:55 +0200 | jerg | (~jerg@2001:a61:2510:4100::bb0) |
| 2024-07-28 18:46:47 +0200 | AlexZenon_2 | (~alzenon@94.233.241.102) (Quit: ;-) |
| 2024-07-28 18:48:21 +0200 | AlexNoo | (~AlexNoo@94.233.241.102) (Quit: Leaving) |
| 2024-07-28 18:52:47 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-28 18:57:02 +0200 | joeyadams | (~joeyadams@2603:6010:5100:2ed:9a0f:48a9:a53e:e82f) |
| 2024-07-28 19:00:04 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2024-07-28 19:00:29 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2024-07-28 19:05:35 +0200 | Square2 | (~Square@user/square) |
| 2024-07-28 19:06:23 +0200 | euleritian | (~euleritia@dynamic-176-000-159-039.176.0.pool.telefonica.de) |
| 2024-07-28 19:09:10 +0200 | abrar | (~abrar@pool-72-78-199-167.phlapa.fios.verizon.net) (Quit: WeeChat 4.2.1) |
| 2024-07-28 19:09:42 +0200 | abrar | (~abrar@pool-72-78-199-167.phlapa.fios.verizon.net) |
| 2024-07-28 19:16:08 +0200 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
| 2024-07-28 19:16:33 +0200 | Inst | (~Inst@user/Inst) |
| 2024-07-28 19:20:15 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-28 19:20:43 +0200 | AlexZenon | (~alzenon@94.233.241.102) |
| 2024-07-28 19:20:50 +0200 | AlexNoo | (~AlexNoo@94.233.241.102) |
| 2024-07-28 19:21:46 +0200 | AlexZenon_2 | (~alzenon@94.233.241.102) |
| 2024-07-28 19:24:18 +0200 | bolivood | (~bolivood@2a0d:6fc2:5d11:200:bd4c:6a06:416e:add9) |
| 2024-07-28 19:26:20 +0200 | AlexZenon_2 | (~alzenon@94.233.241.102) (Quit: ;-) |
| 2024-07-28 19:30:38 +0200 | joeyadams | (~joeyadams@2603:6010:5100:2ed:9a0f:48a9:a53e:e82f) (Quit: Leaving) |
| 2024-07-28 19:37:02 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-07-28 19:39:27 +0200 | jerg | (~jerg@2001:a61:2510:4100::bb0) (Ping timeout: 252 seconds) |
| 2024-07-28 19:44:59 +0200 | hayk | (~hayk@141.136.90.108) |
| 2024-07-28 19:47:12 +0200 | euleritian | (~euleritia@dynamic-176-000-159-039.176.0.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-28 19:47:29 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-28 19:55:25 +0200 | ss4 | (~wootehfoo@user/wootehfoot) |
| 2024-07-28 19:58:47 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 255 seconds) |
| 2024-07-28 20:05:33 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) |
| 2024-07-28 20:42:36 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-28 20:46:10 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-28 20:51:25 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-07-28 21:05:55 +0200 | Enrico63 | (~Enrico63@81.109.143.226) |
| 2024-07-28 21:17:05 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-07-28 21:24:09 +0200 | Enrico63 | (~Enrico63@81.109.143.226) (Ping timeout: 256 seconds) |
| 2024-07-28 21:25:59 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-28 21:29:25 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-07-28 21:36:37 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-28 21:47:00 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-07-28 21:47:25 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) |
| 2024-07-28 21:50:07 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-28 21:52:04 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) (Ping timeout: 260 seconds) |
| 2024-07-28 21:54:45 +0200 | ss4 | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-07-28 21:56:05 +0200 | Square2 | (~Square@user/square) (Ping timeout: 248 seconds) |
| 2024-07-28 22:03:39 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-28 22:06:54 +0200 | CiaoSen | (~Jura@2a05:5800:205:1000:e6b9:7aff:fe80:3d03) |
| 2024-07-28 22:16:07 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-28 22:20:05 +0200 | hayk | (~hayk@141.136.90.108) (Ping timeout: 255 seconds) |
| 2024-07-28 22:29:39 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-28 22:38:42 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) |
| 2024-07-28 22:38:49 +0200 | Midjak | (~MarciZ@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2024-07-28 22:39:03 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-07-28 22:42:52 +0200 | hayk | (~hayk@141.136.90.108) |
| 2024-07-28 22:57:59 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 260 seconds) |
| 2024-07-28 23:05:32 +0200 | Guest43 | (~Guest43@154.118.69.187) |
| 2024-07-28 23:08:15 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) (Quit: Leaving) |
| 2024-07-28 23:24:14 +0200 | oo_miguel | (~Thunderbi@78.10.207.46) (Ping timeout: 252 seconds) |
| 2024-07-28 23:30:22 +0200 | pavonia | (~user@user/siracusa) |
| 2024-07-28 23:31:19 +0200 | CiaoSen | (~Jura@2a05:5800:205:1000:e6b9:7aff:fe80:3d03) (Ping timeout: 264 seconds) |
| 2024-07-28 23:32:13 +0200 | Guest43 | (~Guest43@154.118.69.187) (Quit: Client closed) |
| 2024-07-28 23:40:02 +0200 | michalz | (~michalz@185.246.207.217) (Remote host closed the connection) |
| 2024-07-28 23:41:26 +0200 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2024-07-28 23:42:07 +0200 | Guest67 | (~Guest67@126.188.73.86.rev.sfr.net) |
| 2024-07-28 23:43:17 +0200 | Guest67 | (~Guest67@126.188.73.86.rev.sfr.net) (Client Quit) |
| 2024-07-28 23:49:19 +0200 | Square2 | (~Square@user/square) |