| 2022-02-03 00:00:13 +0100 | APic | (~apic@apic.name) (Ping timeout: 256 seconds) |
| 2022-02-03 00:00:46 +0100 | Inst | (~delicacie@2601:6c4:4080:3f80:40a0:b50a:e8ed:d1eb) (Ping timeout: 245 seconds) |
| 2022-02-03 00:01:42 +0100 | APic | (apic@apic.name) |
| 2022-02-03 00:03:12 +0100 | <segfaultfizzbuzz> | hmm https://paste.rs/dYa.hs |
| 2022-02-03 00:03:21 +0100 | <segfaultfizzbuzz> | adding an import of Name does nothing for the errors |
| 2022-02-03 00:03:37 +0100 | soxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) (Ping timeout: 256 seconds) |
| 2022-02-03 00:03:49 +0100 | <segfaultfizzbuzz> | import Data.XML.Types (Name, nameLocalName, isNamed) |
| 2022-02-03 00:05:23 +0100 | <awpr> | oh, I probably should have actually looked at the type of `nameLocalName` |
| 2022-02-03 00:05:26 +0100 | <geekosaur> | that's not your biggest prolem. you're using the wrong concatMap |
| 2022-02-03 00:05:42 +0100 | <awpr> | yeah, that too, for the first error |
| 2022-02-03 00:05:54 +0100 | <maerwald> | should have used streamly xD |
| 2022-02-03 00:05:56 +0100 | rustisafungus | (~rustisafu@2602:306:cd3c:9350:cc4:c954:b25:db0a) |
| 2022-02-03 00:06:25 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-02-03 00:08:37 +0100 | segfaultfizzbuzz | (~rustisafu@2602:306:cd3c:9350:143b:3f0e:5bf:b4a8) (Ping timeout: 240 seconds) |
| 2022-02-03 00:09:26 +0100 | rustisafungus | segfaultfizzbuzz |
| 2022-02-03 00:09:47 +0100 | <segfaultfizzbuzz> | sorrry, my laptop power cable is loose, lol |
| 2022-02-03 00:15:57 +0100 | <segfaultfizzbuzz> | eh, hiding concatMap didn't do a lot to help |
| 2022-02-03 00:17:47 +0100 | <awpr> | if it didn't say "ambiguous reference" before, then hiding cannot be expected to fix it. you have to import the right one, and make sure you're referencing the right one |
| 2022-02-03 00:20:12 +0100 | <segfaultfizzbuzz> | https://paste.rs/Qje.hs |
| 2022-02-03 00:21:46 +0100 | <awpr> | a) `nameLocalName` is still a problem, that's trying to access a `Text` field of a `Name`, but the thing it's being passed to expects the entire `Name` |
| 2022-02-03 00:22:09 +0100 | Midjak | (~Midjak@may53-1-78-226-116-92.fbx.proxad.net) (Quit: This computer has gone to sleep) |
| 2022-02-03 00:22:11 +0100 | <segfaultfizzbuzz> | if i import Name it becomes unhappy,... i guess this becomes another namespace conflict thing...? |
| 2022-02-03 00:22:15 +0100 | <awpr> | it might just want to be `isNamed "img"`, depending on how the `IsString` instance works |
| 2022-02-03 00:22:56 +0100 | <segfaultfizzbuzz> | it wants an Element |
| 2022-02-03 00:22:56 +0100 | meltedbrain_y2k | (~tekserf@47.61.115.91) (Read error: Connection reset by peer) |
| 2022-02-03 00:23:31 +0100 | <segfaultfizzbuzz> | so... is this stuff not really used? am i one of like ten people to actually use this? |
| 2022-02-03 00:23:33 +0100 | haskellberryfinn | (~nut@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) |
| 2022-02-03 00:23:35 +0100 | <awpr> | no, it wants a `Name` first, and then an `Element`: `isNamed :: Name -> Element -> [Element]` |
| 2022-02-03 00:23:55 +0100 | <absentia> | segfaultfizzbuzz: it's used, irc is just slow |
| 2022-02-03 00:24:15 +0100 | <awpr> | I have no idea whether `xml-types` is used, but `conduit` is very popular (for a Haskell library) |
| 2022-02-03 00:24:18 +0100 | janus | (janus@anubis.0x90.dk) () |
| 2022-02-03 00:24:41 +0100 | <absentia> | oh wait you mean conduits |
| 2022-02-03 00:24:43 +0100 | <absentia> | haha |
| 2022-02-03 00:25:04 +0100 | <segfaultfizzbuzz> | yes i mean conduits and xml types and whatnot, because filtering based on an element seems to be one of the most basic things |
| 2022-02-03 00:25:07 +0100 | <monochrom> | The intersection of conduit users and xml-types users can be pretty small. |
| 2022-02-03 00:25:11 +0100 | <segfaultfizzbuzz> | the documentation isn't really the greatest,... heh ok |
| 2022-02-03 00:25:28 +0100 | <segfaultfizzbuzz> | anyway if i add Name to the imports, ghc is still unhappy |
| 2022-02-03 00:25:44 +0100 | <awpr> | why is adding `Name` relevant? it's not referenced in the code |
| 2022-02-03 00:26:01 +0100 | <awpr> | no reason to expect importing something you don't use would affect anything |
| 2022-02-03 00:26:11 +0100 | <segfaultfizzbuzz> | it seems that i need to say Data.Conduit.Combinators.concatMap (isNamed (Name "img")) if i am not going to use nameLocalName |
| 2022-02-03 00:26:21 +0100 | <absentia> | awpr: typeclass instances? |
| 2022-02-03 00:26:31 +0100 | <segfaultfizzbuzz> | but import Data.XML.Types (nameLocalName, Name, isNamed) doesn't make that problem go away |
| 2022-02-03 00:26:34 +0100 | <awpr> | then you're importing the typeclass instances |
| 2022-02-03 00:26:36 +0100 | <segfaultfizzbuzz> | i guess i could be completely explicit |
| 2022-02-03 00:26:45 +0100 | hueso | (~root@user/hueso) (Quit: hueso) |
| 2022-02-03 00:27:12 +0100 | <awpr> | the constructor of `Name` takes three arguments. but it has an `IsString` instance that should be easier to use, like I posted earlier |
| 2022-02-03 00:27:25 +0100 | <segfaultfizzbuzz> | this is haskell, how can it be confused that i am not adding Name to the import list when i in fact am |
| 2022-02-03 00:27:29 +0100 | <awpr> | the other problem is (reading directly from the error message here) that the earlier part of the conduit pipeline produces `Event`s, and the later part expects `Element`s |
| 2022-02-03 00:27:49 +0100 | jgeerds | (~jgeerds@55d4a547.access.ecotel.net) (Ping timeout: 240 seconds) |
| 2022-02-03 00:28:03 +0100 | <awpr> | oh, you're also not importing the data constructor `Name`, only the type `Name`. it's not confused, although it is arguably confus_ing_ |
| 2022-02-03 00:28:46 +0100 | Gurkenglas | (~Gurkengla@dslb-090-186-104-244.090.186.pools.vodafone-ip.de) (Read error: Connection reset by peer) |
| 2022-02-03 00:29:03 +0100 | <monochrom> | The syntax for importing a data constructor DC is not "import M(DC)". It is "import M(T(DC))" if T is the type name. |
| 2022-02-03 00:29:04 +0100 | Gurkenglas | (~Gurkengla@dslb-090-186-104-244.090.186.pools.vodafone-ip.de) |
| 2022-02-03 00:29:14 +0100 | hueso | (~root@user/hueso) |
| 2022-02-03 00:29:16 +0100 | <segfaultfizzbuzz> | what. lol |
| 2022-02-03 00:29:23 +0100 | <segfaultfizzbuzz> | Name(Name) ? |
| 2022-02-03 00:29:28 +0100 | <awpr> | yes |
| 2022-02-03 00:29:30 +0100 | <segfaultfizzbuzz> | lol |
| 2022-02-03 00:29:56 +0100 | <awpr> | or `Name(..)` |
| 2022-02-03 00:31:36 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-02-03 00:31:39 +0100 | bontaq` | (~user@ool-45779fe5.dyn.optonline.net) |
| 2022-02-03 00:31:58 +0100 | <awpr> | but even so, importing `Name` won't fix that snippet; it's given the wrong number of parameters |
| 2022-02-03 00:32:01 +0100 | bontaq` | bontaq |
| 2022-02-03 00:32:33 +0100 | <segfaultfizzbuzz> | i mean i am looking at the documentation and nameLocalName takes one Text argument and Name looks like it should be the same ? |
| 2022-02-03 00:33:21 +0100 | <monochrom> | Amazingly, https://www.haskell.org/tutorial/modules.html teaches this. |
| 2022-02-03 00:33:34 +0100 | <awpr> | `nameLocalName :: Name -> Text` and `Name :: Text -> Maybe Text -> Maybe Text -> Name` |
| 2022-02-03 00:33:51 +0100 | <segfaultfizzbuzz> | https://www.youtube.com/watch?v=CScRRlmvncA |
| 2022-02-03 00:34:30 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-02-03 00:38:14 +0100 | gargawel | (~kvirc@82-65-144-99.subs.proxad.net) (Ping timeout: 250 seconds) |
| 2022-02-03 00:40:32 +0100 | DNH | (~DNH@2a02:8108:1100:16d8:7cff:235a:6ff3:c21a) |
| 2022-02-03 00:40:32 +0100 | DNH | (~DNH@2a02:8108:1100:16d8:7cff:235a:6ff3:c21a) (Client Quit) |
| 2022-02-03 00:40:34 +0100 | meltedbrain_y2k | (~tekserf@47.61.115.91) |
| 2022-02-03 00:46:41 +0100 | Topsi | (~Tobias@dyndsl-095-033-017-221.ewe-ip-backbone.de) |
| 2022-02-03 00:48:38 +0100 | juhp | (~juhp@128.106.188.82) (Ping timeout: 250 seconds) |
| 2022-02-03 00:49:12 +0100 | <segfaultfizzbuzz> | should i switch to streamly? i made several attempts at simply checking whether something has a name of img and nothing works |
| 2022-02-03 00:49:41 +0100 | DNH | (~DNH@2a02:8108:1100:16d8:7cff:235a:6ff3:c21a) |
| 2022-02-03 00:49:58 +0100 | <awpr> | switching to streamly has nothing to do with the cause of this particular error. so, maybe? I don't have an established preference between the two. |
| 2022-02-03 00:50:23 +0100 | off^ | (~off@128-092-174-141.biz.spectrum.com) (Remote host closed the connection) |
| 2022-02-03 00:50:26 +0100 | <awpr> | the problem here is that the code is parsing Events and then trying to consume Elements |
| 2022-02-03 00:51:22 +0100 | pavonia | (~user@user/siracusa) |
| 2022-02-03 00:52:00 +0100 | <awpr> | so you'd either need to switch to a parser that parses Elements (which probably means giving up on streaming?) or do something more complex downstream to sift through Events to accomplish whatever you're trying to do |
| 2022-02-03 00:52:10 +0100 | wavemode | (~wavemode@c-98-223-145-19.hsd1.il.comcast.net) |
| 2022-02-03 00:52:56 +0100 | <segfaultfizzbuzz> | the .| specifies a stream direction, like |> right ? |
| 2022-02-03 00:53:13 +0100 | <segfaultfizzbuzz> | left to right |
| 2022-02-03 00:53:29 +0100 | <awpr> | effectively, yeah |
| 2022-02-03 00:54:27 +0100 | <segfaultfizzbuzz> | i mean let me see if what haskell folks say is true. so i search for element and event on hoogle and i find... https://hoogle.haskell.org/?hoogle=event+element&scope=set%3Astackage |
| 2022-02-03 00:54:50 +0100 | <awpr> | what do Haskell folks say? |
| 2022-02-03 00:54:50 +0100 | <segfaultfizzbuzz> | so i need elementFromEvents ? |
| 2022-02-03 00:55:05 +0100 | <segfaultfizzbuzz> | that i can just search on hoogle and my type transformation problems will be solved |
| 2022-02-03 00:55:38 +0100 | <monochrom> | I never said that. |
| 2022-02-03 00:55:39 +0100 | <awpr> | oh. I wouldn't say that, I rarely if ever use Hoogle. but that function looks plausible |
| 2022-02-03 00:56:01 +0100 | <awpr> | (and it constitutes giving up on streaming, at least partially, because it parses the whole document into one giant tree) |
| 2022-02-03 00:56:05 +0100 | <segfaultfizzbuzz> | elementFromEvents :: MonadThrow m => ConduitT EventPos o m (Maybe Element) rather complex type signature though |
| 2022-02-03 00:56:34 +0100 | <segfaultfizzbuzz> | ok... so... i can't do a streaming xml parse and filter then...? |
| 2022-02-03 00:56:49 +0100 | <monochrom> | "Element", "Event" are pretty popular names picked by unrelated library authors for unrelated things. |
| 2022-02-03 00:57:00 +0100 | <awpr> | eh, par for the course for Conduit functions. it's a conduit that eats all of the EventPos and builds an Element or fails |
| 2022-02-03 00:57:08 +0100 | <monochrom> | Consider the equivalent of "Test -> Run" |
| 2022-02-03 00:57:21 +0100 | <segfaultfizzbuzz> | i actually wanted to stream a zip file (i think bz2 to be exact), unzip the zip stream, parse the xml stream, grab particular elements, and then do a simple calculation on those |
| 2022-02-03 00:57:38 +0100 | <segfaultfizzbuzz> | so... give up on conduit...? |
| 2022-02-03 00:57:50 +0100 | <monochrom> | Literally all of my students (there are 50+) call their programs "test" or "run". |
| 2022-02-03 00:57:54 +0100 | <awpr> | conduit is still providing value there, in the chunk-wise streaming of compressed data and parse input |
| 2022-02-03 00:58:26 +0100 | <awpr> | that's the "partially": the whole document is loaded into memory, but there's potentially streaming throughout the parse process |
| 2022-02-03 00:58:31 +0100 | <monochrom> | I'm pretty sure every streaming library will give you type errors. |
| 2022-02-03 00:59:53 +0100 | <segfaultfizzbuzz> | i was actually partially understanding the documentation here, i think https://hackage.haskell.org/package/streamly-0.1.0/docs/Streamly-Tutorial.html |
| 2022-02-03 01:00:28 +0100 | <monochrom> | You used to partially understand conduit's documentation, too. |
| 2022-02-03 01:00:56 +0100 | <dsal> | *sigh* -- this project I'm having a problem with uses a Makefile to build. Neat, a simple entry point, I guess. The Makefile launches stack. But it's not a stack project. So stack on my machine gets confused because whatever the default is just doesn't work for me. But there's a cabal file. cabal builds it just fine and doesn't have the same strange issue the complex nix project I'm trying to import it into has. |
| 2022-02-03 01:01:04 +0100 | dsal | should add a build system to solve the problem |
| 2022-02-03 01:01:15 +0100 | <awpr> | the issue is basically that streaming a tree structure is a bit complicated, because you have to consume it as "enter an <p> tag, visit this sentence, enter an <img> tag, observe this src=_ attribute, exit an <img> tag, visit another sentence, exit a <p> tag, etc.", and no streaming library will make that not be complicated |
| 2022-02-03 01:02:27 +0100 | <segfaultfizzbuzz> | i mean,... as long as you do your computation when you hit </tag of interest>, isn't that enough ? |
| 2022-02-03 01:02:32 +0100 | <monochrom> | dsal: I would be interested in what cute name you would choose for your build system :) |
| 2022-02-03 01:02:55 +0100 | <dsal> | haha. noo... I very much don't want to introduce a build system. |
| 2022-02-03 01:02:55 +0100 | <awpr> | yeah, as long as you took care to collect the needed information from the start of the tag |
| 2022-02-03 01:03:29 +0100 | <dsal> | stack + nix = snax |
| 2022-02-03 01:03:30 +0100 | xkuru | (~xkuru@user/xkuru) (Read error: Connection reset by peer) |
| 2022-02-03 01:03:31 +0100 | <awpr> | this is still something you can do, but it's not done by the Element-oriented functions |
| 2022-02-03 01:03:34 +0100 | <DigitalKiwi> | dsl build |
| 2022-02-03 01:03:45 +0100 | <segfaultfizzbuzz> | so... i can't do this then? i have to fit the entire file into RAM in order to process? my zip file is like a terabyte and i have a dozen or so gigs of ram here |
| 2022-02-03 01:03:50 +0100 | <monochrom> | @botsnax |
| 2022-02-03 01:03:50 +0100 | <lambdabot> | :) |
| 2022-02-03 01:04:16 +0100 | <monochrom> | (The true command is @botsnack ) |
| 2022-02-03 01:04:16 +0100 | kli_ | (~kli@ip-89-177-122-45.net.upcbroadband.cz) |
| 2022-02-03 01:04:24 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-02-03 01:05:01 +0100 | <monochrom> | So lambdabot is saying it likes the name snax. :) |
| 2022-02-03 01:05:28 +0100 | <geekosaur> | https://www.schoolofhaskell.com/school/starting-with-haskell/libraries-and-frameworks/text-manipul… might be of interest |
| 2022-02-03 01:05:51 +0100 | kli_ | (~kli@ip-89-177-122-45.net.upcbroadband.cz) (Remote host closed the connection) |
| 2022-02-03 01:06:35 +0100 | <DigitalKiwi> | @botsnack |
| 2022-02-03 01:06:35 +0100 | <lambdabot> | :) |
| 2022-02-03 01:07:03 +0100 | <DigitalKiwi> | @botgiberrish |
| 2022-02-03 01:07:03 +0100 | <lambdabot> | Unknown command, try @list |
| 2022-02-03 01:07:09 +0100 | <DigitalKiwi> | :( |
| 2022-02-03 01:08:43 +0100 | <dsal> | @botulism |
| 2022-02-03 01:08:43 +0100 | <lambdabot> | Unknown command, try @list |
| 2022-02-03 01:08:53 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 256 seconds) |
| 2022-02-03 01:09:58 +0100 | <segfaultfizzbuzz> | geekosaur: this documentation is from 2013... |
| 2022-02-03 01:11:01 +0100 | <geekosaur> | and? tagsoup is stable, and has the advantage that you can pretty much ignore document structure (if any; being the web there often isn't much reliable structure, which is the point of tagsoup) |
| 2022-02-03 01:11:49 +0100 | <geekosaur> | tagsoup doesn't *need* to change much |
| 2022-02-03 01:12:20 +0100 | <awpr> | a high-level description of how to grab img tags out of the event stream manually would be like: write a Conduit `consumeOne` that `await`s an event; if it's an img tag, call a second Conduit `consumeImg` on it; else do nothing. then `consumeImg` should await the contents until it finds a "</img>", and emit an `Element` or whatever other type you want; finally, the whole consumer is `forever consumeOne` |
| 2022-02-03 01:13:44 +0100 | <awpr> | or, if you're willing to assume img tags are empty, then just `mapMaybe` the event stream looking for `EventBeginElement "img" ...` and ignore everything else |
| 2022-02-03 01:13:58 +0100 | <EvanR> | if it's not invalidated and requiring maintenance every week or two is it really compatible with the web |
| 2022-02-03 01:16:08 +0100 | <EvanR> | if usable code necessarily requires someone to hammer on it periodically, then that's a hard limit on the amount of usable code at any given time (assuming fixed amount of available programmers) |
| 2022-02-03 01:16:15 +0100 | mcgroin | (~mcgroin@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 256 seconds) |
| 2022-02-03 01:21:01 +0100 | CHUD | (~CHUD@host-80-41-89-108.as13285.net) (Ping timeout: 256 seconds) |
| 2022-02-03 01:21:36 +0100 | toshiblue | (~toshiblue@c-73-111-20-145.hsd1.il.comcast.net) (Ping timeout: 256 seconds) |
| 2022-02-03 01:24:19 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Quit: WeeChat 3.4) |
| 2022-02-03 01:25:17 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-02-03 01:28:24 +0100 | <segfaultfizzbuzz> | geekosaur: tagsoup is not stream-based, it looks like? |
| 2022-02-03 01:28:48 +0100 | <segfaultfizzbuzz> | geekosaur: so it will read the entire page into memory, parse there, and then try to operate on the fully parsed document? |
| 2022-02-03 01:29:13 +0100 | shapr | (~user@pool-173-73-44-186.washdc.fios.verizon.net) (Remote host closed the connection) |
| 2022-02-03 01:29:18 +0100 | <segfaultfizzbuzz> | awpr: i will try to understand this |
| 2022-02-03 01:29:30 +0100 | shapr | (~user@pool-173-73-44-186.washdc.fios.verizon.net) |
| 2022-02-03 01:29:51 +0100 | <segfaultfizzbuzz> | awpr: thanks for clarifying that this is beyond what can be done ergonomically (?) with streams |
| 2022-02-03 01:30:34 +0100 | alx741 | (~alx741@157.100.197.240) (Quit: alx741) |
| 2022-02-03 01:31:00 +0100 | <segfaultfizzbuzz> | so then if i can't work with a tree data structure in streams (which is more or less the simplest thing i can think of), is conduits/streams "meant" to be used on localized computations on a window of the stream? |
| 2022-02-03 01:31:06 +0100 | machinedgod | (~machinedg@24.105.81.50) (Ping timeout: 250 seconds) |
| 2022-02-03 01:32:13 +0100 | <geekosaur> | sorry, I thought this used a tagsoup conduit. in any case the tutorial I linked tells you how to search dfor specific tags with a specific attribute |
| 2022-02-03 01:32:16 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 01:32:22 +0100 | <geekosaur> | looks like it uses xml-conduit |
| 2022-02-03 01:33:03 +0100 | d0ku | (~d0ku@178.43.19.180.ipv4.supernova.orange.pl) (Remote host closed the connection) |
| 2022-02-03 01:33:56 +0100 | <awpr> | tbh I don't think this is really specifically about Haskell streaming issues, but more about incremental processing of a tree given its preorder traversal -- it'd be complicated in the same ways in any other language |
| 2022-02-03 01:33:57 +0100 | chenqisu1 | (~chenqisu1@183.217.200.249) |
| 2022-02-03 01:33:58 +0100 | <segfaultfizzbuzz> | ah my bad i just consulted the tagsoup documentation directly... i'll try this |
| 2022-02-03 01:34:06 +0100 | boxscape_ | (~boxscape_@p4ff0b9d5.dip0.t-ipconnect.de) (Quit: Connection closed) |
| 2022-02-03 01:34:51 +0100 | <geekosaur> | there *is* a conduit-tagsoup module, it turns out, but it's aged and explicitly "semi-maintained" |
| 2022-02-03 01:34:51 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 01:35:04 +0100 | <segfaultfizzbuzz> | sigh |
| 2022-02-03 01:35:15 +0100 | <segfaultfizzbuzz> | okay what do "normal" programmers use for this... some java library...? |
| 2022-02-03 01:35:17 +0100 | <geekosaur> | then again, like tagsoup itself it doesn't need much maintenance; conduit likely changes more often than tagsoup does |
| 2022-02-03 01:36:03 +0100 | <awpr> | if the task is literally extracting img tags from a compressed xml document... I'd probably use `gunzip | xsel` |
| 2022-02-03 01:36:16 +0100 | vicfred | (~vicfred@user/vicfred) (Quit: Leaving) |
| 2022-02-03 01:36:19 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-02-03 01:37:35 +0100 | <awpr> | and if it needed to be callable from Haskell, I might even consider wrapping that actual Unix pipeline up in Haskell APIs, depending on miscellaneous circumstances |
| 2022-02-03 01:38:16 +0100 | <segfaultfizzbuzz> | my goal is to use haskell here. my document isn't html, it's some weird xml document. i need to grab some elements and calculate some stuff on them |
| 2022-02-03 01:40:17 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2022-02-03 01:41:08 +0100 | <awpr> | wrapping up calls to xsel still might be a decent answer -- they've already done the hard work of sifting through XML efficiently to find specific things. or if the details of what you want to extract are simple enough (like "all of a certain kind of tag, assumed to be empty"), then the "more complicated" event stream approach might not be so bad |
| 2022-02-03 01:41:45 +0100 | haskellberryfinn | (~nut@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 256 seconds) |
| 2022-02-03 01:42:02 +0100 | <awpr> | (re-raising "or, if you're willing to assume img tags are empty, then just `mapMaybe` the event stream looking for `EventBeginElement "img" ...` and ignore everything else") |
| 2022-02-03 01:42:26 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480::41) (Ping timeout: 245 seconds) |
| 2022-02-03 01:42:40 +0100 | EsoAlgo | (~EsoAlgo@152.70.142.52) |
| 2022-02-03 01:43:22 +0100 | <awpr> | (because if you assume the tags you're looking for are empty, then the EventBeginElement has everything you need, and if you don't care where the tag is, then you don't have to look at the other events at all) |
| 2022-02-03 01:44:52 +0100 | <segfaultfizzbuzz> | my goal isn't to get the work done here as much as to try to "make use of haskell" |
| 2022-02-03 01:45:09 +0100 | <dibblego> | just use tagsoup |
| 2022-02-03 01:45:13 +0100 | <segfaultfizzbuzz> | i actually began this um, project under the apparently flawed assumption that laziness would be useful for working with streaming |
| 2022-02-03 01:45:23 +0100 | mon_aaraj | (~MonAaraj@149.255.212.24) (Ping timeout: 250 seconds) |
| 2022-02-03 01:45:32 +0100 | <segfaultfizzbuzz> | dibblego: yeah i'm trying that at the moment |
| 2022-02-03 01:45:42 +0100 | <dibblego> | ok cool |
| 2022-02-03 01:45:45 +0100 | <awpr> | (+1 to tagsoup if it does support a streaming API after all) |
| 2022-02-03 01:46:07 +0100 | <EvanR> | this is my dude, haskell for haskell's sake |
| 2022-02-03 01:46:31 +0100 | <EvanR> | pass the koolaid |
| 2022-02-03 01:46:45 +0100 | <awpr> | but yeah, unfortunately laziness is kind of just a tempting distraction to effectful streaming. good for pure streaming, though |
| 2022-02-03 01:47:20 +0100 | <geekosaur> | since tagsoup explicitly doesn't care about structure I'd think it ideal for streaming, tbh |
| 2022-02-03 01:47:22 +0100 | <segfaultfizzbuzz> | pure streaming would mean like that i am generating the data myself? |
| 2022-02-03 01:47:34 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-02-03 01:47:57 +0100 | <segfaultfizzbuzz> | so in the example here i'm working with the "With a List" section https://www.schoolofhaskell.com/school/starting-with-haskell/libraries-and-frameworks/text-manipul… |
| 2022-02-03 01:48:13 +0100 | <EvanR> | when the effect involves IO at some level, you have to reconsider your laziness |
| 2022-02-03 01:48:17 +0100 | <awpr> | yeah, that's what I meant by "pure streaming" -- streaming in the sense of describing (purely) a huge data structure, and consuming it incrementally without materializing the whole thing |
| 2022-02-03 01:48:44 +0100 | <segfaultfizzbuzz> | but the data structure is only "huge" because a computer is generating it synthetically |
| 2022-02-03 01:48:59 +0100 | <segfaultfizzbuzz> | rather than because it comes from io |
| 2022-02-03 01:49:04 +0100 | merijn | (~merijn@c-001-002-002.client.esciencecenter.eduvpn.nl) |
| 2022-02-03 01:49:14 +0100 | <EvanR> | the huge data structure was already there, the computer only chiseled away with enclosing marble |
| 2022-02-03 01:49:58 +0100 | <EvanR> | what does algorithmic vs I/O based have to do with size |
| 2022-02-03 01:50:07 +0100 | yauhsien_ | (~yauhsien@118-167-40-21.dynamic-ip.hinet.net) |
| 2022-02-03 01:50:48 +0100 | <segfaultfizzbuzz> | uh well part of the purpose of this experiment was to try to understand where laziness is beneficial in programming, and i had thought that streaming was such a situation, but now i am being told that isn't the case unless the stream is "pure" |
| 2022-02-03 01:51:12 +0100 | <dolio> | You might have to ignore anti-laziness FUD that gets spread even here. |
| 2022-02-03 01:51:24 +0100 | <dolio> | If you want to actually determine the answer to your satisfaction. |
| 2022-02-03 01:51:30 +0100 | <EvanR> | laziness can also benefit during an I/O stream, you could be consuming incrementally some generated data structure, generated from a bit of input at a time |
| 2022-02-03 01:51:46 +0100 | mvk | (~mvk@2607:fea8:5cdc:bf00::80f1) |
| 2022-02-03 01:52:00 +0100 | <segfaultfizzbuzz> | i'm uh, neither pro nor anti-lazy, just trying to understand haskell and programming better. |
| 2022-02-03 01:52:21 +0100 | <awpr> | "huge data" is the motivation to want streaming; if that huge data is the result of a pure computation, laziness might give the streaming you want, but if it's the result of many IO actions, then it's very tempting to express it with laziness, which is where you get stuff like `readFile` and other "lazy IO", but that has its drawbacks |
| 2022-02-03 01:52:31 +0100 | Gurkenglas | (~Gurkengla@dslb-090-186-104-244.090.186.pools.vodafone-ip.de) (Ping timeout: 256 seconds) |
| 2022-02-03 01:52:51 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 01:53:01 +0100 | <awpr> | explicit streaming libraries attempt to address those drawbacks without going back to materializing huge data in memory |
| 2022-02-03 01:53:13 +0100 | <segfaultfizzbuzz> | i think you mean tempting to express it without laziness for the second part there right? |
| 2022-02-03 01:53:25 +0100 | <EvanR> | no, with |
| 2022-02-03 01:53:45 +0100 | <awpr> | no, they don't try to eliminate laziness entirely, they just don't rely _solely_ on laziness |
| 2022-02-03 01:54:01 +0100 | <EvanR> | readFile does a hack to express your incremental reading as something purely lazy |
| 2022-02-03 01:54:06 +0100 | <awpr> | the laziness of `readFile` is a lie, and streaming libraries try to eliminate that lie |
| 2022-02-03 01:54:10 +0100 | <awpr> | ahh, too slow |
| 2022-02-03 01:54:18 +0100 | <dibblego> | segfaultfizzbuzz: laziness is widely understood even here, and especially not here. |
| 2022-02-03 01:54:22 +0100 | <dibblego> | *misunderstood |
| 2022-02-03 01:54:30 +0100 | <dolio> | See, this is the kind of stuff you have to ignore and just try yourself. |
| 2022-02-03 01:54:40 +0100 | finley | (~finley@2600-6c67-8b00-1fea-5c3a-1e8d-cb0f-2e95.res6.spectrum.com) |
| 2022-02-03 01:57:38 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 01:58:22 +0100 | <segfaultfizzbuzz> | lol haskell.com directs to some industrial company which does wastewater treatment plants among other things |
| 2022-02-03 01:59:21 +0100 | <monochrom> | I spread anti-silver-bullet FUDs. |
| 2022-02-03 01:59:24 +0100 | <EvanR> | obviously haskell is the shit |
| 2022-02-03 02:00:05 +0100 | <monochrom> | Laziness causes some problems and eagerness causes the opposite problems. |
| 2022-02-03 02:00:13 +0100 | <monochrom> | Every silver lining has tarnish. |
| 2022-02-03 02:00:16 +0100 | <segfaultfizzbuzz> | anyway, the With a List section of the documentation is returning nothing, i'm not sure yet whether this is because all of the websites i am trying this on are forcing me to use https or something |
| 2022-02-03 02:00:41 +0100 | <DigitalKiwi> | my boss says i'm lazy i just say i'm solving different problems :( |
| 2022-02-03 02:00:51 +0100 | <monochrom> | :) |
| 2022-02-03 02:01:12 +0100 | <monochrom> | I'm lazy too, and it turns out I do solve different problems. :) |
| 2022-02-03 02:01:51 +0100 | <monochrom> | I'm too lazy to evaluate the integrals that engineering students have to evaluate. |
| 2022-02-03 02:01:53 +0100 | <segfaultfizzbuzz> | does simpleHttp load https? |
| 2022-02-03 02:02:01 +0100 | <monochrom> | But proving that the integrals exist? YES! |
| 2022-02-03 02:02:39 +0100 | finley | (~finley@2600-6c67-8b00-1fea-5c3a-1e8d-cb0f-2e95.res6.spectrum.com) (Quit: Client closed) |
| 2022-02-03 02:03:27 +0100 | <segfaultfizzbuzz> | geekosaur: any thoughts on loading https in the link you sent? i think that might be an issue here |
| 2022-02-03 02:04:45 +0100 | <geekosaur> | still checking but I just noticed that simpleHttp loads the whole document into memory which is what you *don't* want |
| 2022-02-03 02:04:57 +0100 | lainon | (~lainon@2601:7c0:c500:4d20::ae8) |
| 2022-02-03 02:05:09 +0100 | <geekosaur> | "Note: Even though this function returns a lazy bytestring, it does not utilize lazy I/O, and therefore the entire response body will live in memory. If you want constant memory usage, you'll need to use the conduit package and http directly." |
| 2022-02-03 02:05:20 +0100 | <awpr> | that tutorial appears to use libraries that materialize the whole document, and doesn't seem to use tagsoup at all as far as I can tell |
| 2022-02-03 02:05:39 +0100 | <monochrom> | Yeah that's very strange. |
| 2022-02-03 02:06:07 +0100 | <awpr> | the comments section does not seem to be very favorable towards it :) |
| 2022-02-03 02:06:31 +0100 | <geekosaur> | but I do see you can specify `secure` if you use the `http` combinator that it recommends instead |
| 2022-02-03 02:06:55 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 256 seconds) |
| 2022-02-03 02:07:07 +0100 | <monochrom> | strange on the order of https://www.amazon.ca/Haskell-From-First-Principle/dp/0764541668/ |
| 2022-02-03 02:07:21 +0100 | <segfaultfizzbuzz> | ok so, ... tagsoup is dead in the water then |
| 2022-02-03 02:07:38 +0100 | <awpr> | I'm confused. that tutorial has nothing to do with tagsoup |
| 2022-02-03 02:07:47 +0100 | <awpr> | except the title (???) |
| 2022-02-03 02:07:55 +0100 | <awpr> | looking at the actual tagsoup library, it looks very similar to the event stream representation of xml-types |
| 2022-02-03 02:08:01 +0100 | <monochrom> | Hence the funny URL I made :) |
| 2022-02-03 02:08:24 +0100 | <wavemode> | I guess learning and growing to hate PHP is the first principle of choosing haskell |
| 2022-02-03 02:08:51 +0100 | <EvanR> | PHP was "my language" right before haskell |
| 2022-02-03 02:08:56 +0100 | <EvanR> | stark contrast |
| 2022-02-03 02:09:37 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-02-03 02:11:37 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 240 seconds) |
| 2022-02-03 02:11:58 +0100 | <EvanR> | segfaultfizzbuzz, why not forget the tutorials and mess around with tagsoup by itself to get a feel for it |
| 2022-02-03 02:12:14 +0100 | <EvanR> | or simpleHttp by itself, or whatever |
| 2022-02-03 02:12:41 +0100 | <EvanR> | combining 9 thinks and a random tutorial might work but maybe you could come at it piece by piece |
| 2022-02-03 02:13:30 +0100 | <segfaultfizzbuzz> | so it's back to conduit then if i want to do a streaming xml computation, correct? |
| 2022-02-03 02:13:47 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 02:13:52 +0100 | <EvanR> | conduit is for streaming, yes |
| 2022-02-03 02:13:56 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-02-03 02:13:57 +0100 | <EvanR> | xml or whatever else |
| 2022-02-03 02:15:12 +0100 | <Axman6> | EvanR: Did you migrate to PHP, Purescript, Haskell, Postgres? |
| 2022-02-03 02:15:23 +0100 | <segfaultfizzbuzz> | i'm finding this type tetris stuff to be excrutiating unfortunately |
| 2022-02-03 02:15:59 +0100 | DNH | (~DNH@2a02:8108:1100:16d8:7cff:235a:6ff3:c21a) (Quit: Textual IRC Client: www.textualapp.com) |
| 2022-02-03 02:16:06 +0100 | <Axman6> | is there a reason you're using simpleHttp? Surely you want to use `http` which gives you a conduit to stream the data from the request? |
| 2022-02-03 02:16:17 +0100 | <geekosaur> | the tutorial told them to use it |
| 2022-02-03 02:16:22 +0100 | <Axman6> | D: |
| 2022-02-03 02:16:33 +0100 | <geekosaur> | all hail the tutorial people have been telling them to forget about |
| 2022-02-03 02:17:03 +0100 | <monochrom> | Type tetris is everywhere in nature. |
| 2022-02-03 02:17:22 +0100 | <monochrom> | It is not like PHP actually lets you multiply a string by a boolean function. |
| 2022-02-03 02:17:24 +0100 | <segfaultfizzbuzz> | Axman6: i barely understand haskell, much less am capable of comparing haskell libraries |
| 2022-02-03 02:17:26 +0100 | <geekosaur> | and I pointed out earlier that if they wanted to use https and not have the whole document in RAM they needed to use http instead of simpleHttp, that also got ignored |
| 2022-02-03 02:17:38 +0100 | <Axman6> | segfaultfizzbuzz: these are functions in the same library |
| 2022-02-03 02:17:38 +0100 | <monochrom> | The only difference is how late you receive error messages. |
| 2022-02-03 02:17:59 +0100 | <Axman6> | https://hackage.haskell.org/package/http-conduit-2.3.8/docs/Network-HTTP-Conduit.html#v:simpleHttp see `http` below this |
| 2022-02-03 02:18:00 +0100 | <segfaultfizzbuzz> | Axman6: my goal in this project is to stream a gzipped xml document over http (actually probably https to be precise) and then grab some parts of it and do some simple calculations on those parts |
| 2022-02-03 02:18:01 +0100 | <EvanR> | segfaultfizzbuzz, self-imposed trial by fire then, props |
| 2022-02-03 02:18:37 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 02:19:27 +0100 | <EvanR> | I think the first thing I did in haskell was also HTML filtering and statistics, but offline, not web |
| 2022-02-03 02:20:16 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-166.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-02-03 02:21:42 +0100 | <segfaultfizzbuzz> | Axman6: i think i have a conduit already. if you see awpr's comments above describing an await and soforth, it looks like streaming computations on trees aren't a foremost consideration and so you need to do some gymnastics to make them work |
| 2022-02-03 02:22:17 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-02-03 02:22:17 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-02-03 02:22:17 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-02-03 02:22:23 +0100 | <awpr> | (it's not that they're not a consideration, it's that a linearized form of a tree is a weird thing to work with, independently of whether you're streaming it or not) |
| 2022-02-03 02:23:21 +0100 | merijn | (~merijn@c-001-002-002.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-02-03 02:24:18 +0100 | <geekosaur> | which is why I was going for tagsoup, it ignores the tree structure and just looks for tags |
| 2022-02-03 02:24:18 +0100 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Quit: WeeChat 3.4) |
| 2022-02-03 02:24:41 +0100 | <Axman6> | segfaultfizzbuzz: do you have some code? I haven't been folllowing along, but I'm reading the Text.XML.Stream.Parse docs now |
| 2022-02-03 02:25:34 +0100 | <awpr> | hm? the tagsoup library I'm looking at is working with the same kind of linearized tree as xml-types' Event |
| 2022-02-03 02:26:47 +0100 | <geekosaur> | https://hackage.haskell.org/package/tagstream-conduit looks interesting |
| 2022-02-03 02:27:03 +0100 | <geekosaur> | awpr, nothing in it cares about "tree" |
| 2022-02-03 02:27:12 +0100 | <awpr> | these three are all the same idea |
| 2022-02-03 02:27:14 +0100 | <geekosaur> | the elements are linearized but not structured |
| 2022-02-03 02:27:33 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-02-03 02:27:36 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Client Quit) |
| 2022-02-03 02:27:53 +0100 | <awpr> | there's still an implied tree based on the TagOpen and TagCloses, that's exactly what I mean by "linearized tree" |
| 2022-02-03 02:27:58 +0100 | <geekosaur> | that's the whole point of tag *soup*, it assumes lack of meaningful structure and just emits the content |
| 2022-02-03 02:28:18 +0100 | <geekosaur> | awpr, the reason tagsoup was written was <p><a></p></a> |
| 2022-02-03 02:28:18 +0100 | <awpr> | right, I think we're on the same page |
| 2022-02-03 02:28:33 +0100 | <geekosaur> | tags *do not nest* in the tagsoup model |
| 2022-02-03 02:28:49 +0100 | <Axman6> | gross D: |
| 2022-02-03 02:28:54 +0100 | <awpr> | they're still supposed to, it's just meant to tolerate the real-world cases when they don't |
| 2022-02-03 02:28:57 +0100 | <monochrom> | If you stick to "parseTags :: StringLike str => str -> [Tag str]" you have no tree, and in fact no check of open-close consistencies. |
| 2022-02-03 02:29:49 +0100 | <monochrom> | The stuff in Text.HTML.TagSoup.Tree is optional. And to be disregarded when inputting untrusted inputs. |
| 2022-02-03 02:31:00 +0100 | lbseale | (~ep1ctetus@user/ep1ctetus) (Read error: Connection reset by peer) |
| 2022-02-03 02:31:41 +0100 | <segfaultfizzbuzz> | Axman6: here is my most recent: https://paste.rs/oBr.hs |
| 2022-02-03 02:34:28 +0100 | <Axman6> | isNamed feels like the wrong thing to be using here... |
| 2022-02-03 02:34:43 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 02:35:24 +0100 | <awpr> | try replacing the concatMap step with `Data.Conduit.List.mapMaybe (\case EventBeginElement "img" attrs -> Just attrs; _ -> Nothing)` |
| 2022-02-03 02:35:37 +0100 | toshiblue | (~toshiblue@c-73-111-20-145.hsd1.il.comcast.net) |
| 2022-02-03 02:35:47 +0100 | <Axman6> | yeah that looks like a better start |
| 2022-02-03 02:36:10 +0100 | <awpr> | that may not be the final robust solution, but it should do something and get you started with the "not-parsed-into-a-tree" representation |
| 2022-02-03 02:36:32 +0100 | <Axman6> | that should give you a ConduitT Event [(Name, [Content])] m () |
| 2022-02-03 02:37:41 +0100 | <segfaultfizzbuzz> | ... XLambdaCase...? |
| 2022-02-03 02:38:20 +0100 | <awpr> | yes, enable that, or you can write the function out as a separate binding or however you prefer |
| 2022-02-03 02:38:20 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 02:38:36 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Quit: WeeChat 3.4) |
| 2022-02-03 02:39:19 +0100 | alp | (~alp@2a01:e0a:58b:4920:d89a:b09d:1a2b:26ba) (Ping timeout: 250 seconds) |
| 2022-02-03 02:39:27 +0100 | <monochrom> | Or good old "\x -> case x of EventBeginElement "img" attrs -> Just attrs; _ -> Nothing" |
| 2022-02-03 02:40:13 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) |
| 2022-02-03 02:41:30 +0100 | wavemode | (~wavemode@c-98-223-145-19.hsd1.il.comcast.net) (Ping timeout: 256 seconds) |
| 2022-02-03 02:42:02 +0100 | <segfaultfizzbuzz> | Axman6: hmmm, well at least zombo.com seems to fail to parse now: mystream: ParseError {errorContexts = ["open tag","'>'"], errorMessage = "Failed reading: satisfy", errorPosition = 51:8 (1070)} |
| 2022-02-03 02:43:27 +0100 | <EvanR> | zombo.com is still a thing |
| 2022-02-03 02:43:57 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 240 seconds) |
| 2022-02-03 02:44:32 +0100 | <Axman6> | @gogle Bool -> [a] -> [a] |
| 2022-02-03 02:44:33 +0100 | <lambdabot> | No Result Found. |
| 2022-02-03 02:44:58 +0100 | <Axman6> | @botsnack thanks for reading my mind lambdabot |
| 2022-02-03 02:44:58 +0100 | <lambdabot> | :) |
| 2022-02-03 02:45:08 +0100 | <monochrom> | ZomboCom was my favourite example of camel case. :) |
| 2022-02-03 02:45:27 +0100 | <awpr> | it may not be valid XML; the parser might have choked on the embedded JS |
| 2022-02-03 02:45:46 +0100 | <jackdk> | I see stack still stubbornly refuses to ship a GHC 8.10.7 snapshot with recent hashable. |
| 2022-02-03 02:46:14 +0100 | lainon | (~lainon@2601:7c0:c500:4d20::ae8) (Remote host closed the connection) |
| 2022-02-03 02:46:42 +0100 | off^ | (~off@128-092-174-141.biz.spectrum.com) |
| 2022-02-03 02:46:55 +0100 | <awpr> | actually, it looks like the parse error position points to an attribute name with no value. sounds like this page is just not sufficiently-valid XML for the parser |
| 2022-02-03 02:46:56 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2022-02-03 02:47:08 +0100 | <EvanR> | oof... |
| 2022-02-03 02:47:15 +0100 | <EvanR> | XML in name only |
| 2022-02-03 02:47:34 +0100 | <monochrom> | Is there any reason to use an XML library on HTML inputs? |
| 2022-02-03 02:47:35 +0100 | <awpr> | (that might not be a real problem since the intended real input is said to be XML. just means this isn't a good test case) |
| 2022-02-03 02:47:38 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-02-03 02:47:53 +0100 | <EvanR> | oh nvm |
| 2022-02-03 02:48:27 +0100 | <EvanR> | HTML blob in an XML hole |
| 2022-02-03 02:49:00 +0100 | off^ | (~off@128-092-174-141.biz.spectrum.com) (Remote host closed the connection) |
| 2022-02-03 02:49:02 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480::41) |
| 2022-02-03 02:49:45 +0100 | yauhsien_ | (~yauhsien@118-167-40-21.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-02-03 02:50:35 +0100 | <segfaultfizzbuzz> | lol |
| 2022-02-03 02:54:37 +0100 | vglfr | (~vglfr@88.155.15.0) (Ping timeout: 240 seconds) |
| 2022-02-03 02:54:58 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 02:56:44 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-02-03 02:59:17 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 03:02:58 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-02-03 03:06:05 +0100 | sprout_ | (~quassel@2a02:a467:ccd6:1:b9e2:b772:90e7:5a2b) |
| 2022-02-03 03:06:34 +0100 | vglfr | (~vglfr@88.155.15.0) |
| 2022-02-03 03:09:39 +0100 | sprout | (~quassel@2a02:a467:ccd6:1:6013:7539:4fef:cd22) (Ping timeout: 250 seconds) |
| 2022-02-03 03:12:57 +0100 | mvk | (~mvk@2607:fea8:5cdc:bf00::80f1) (Ping timeout: 240 seconds) |
| 2022-02-03 03:16:08 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 03:16:12 +0100 | vysn | (~vysn@user/vysn) |
| 2022-02-03 03:20:17 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 240 seconds) |
| 2022-02-03 03:21:14 +0100 | califax- | (~califax@user/califx) |
| 2022-02-03 03:21:14 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 03:23:51 +0100 | califax | (~califax@user/califx) (Ping timeout: 276 seconds) |
| 2022-02-03 03:23:52 +0100 | califax- | califax |
| 2022-02-03 03:27:51 +0100 | xff0x | (~xff0x@2001:1a81:53ac:4a00:25b:5701:e54d:ee3e) (Ping timeout: 245 seconds) |
| 2022-02-03 03:28:35 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-02-03 03:28:35 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-02-03 03:28:35 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-02-03 03:29:44 +0100 | xff0x | (~xff0x@2001:1a81:53e8:2500:a319:1c51:2e8e:9977) |
| 2022-02-03 03:33:23 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-02-03 03:34:11 +0100 | ethanN | (~ethanN@d198-53-4-47.abhsia.telus.net) |
| 2022-02-03 03:39:48 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 03:42:54 +0100 | ethanN | (~ethanN@d198-53-4-47.abhsia.telus.net) (Quit: Leaving) |
| 2022-02-03 03:48:20 +0100 | wombat871 | (~wombat875@pool-72-89-24-154.nycmny.fios.verizon.net) (Quit: WeeChat 2.2-dev) |
| 2022-02-03 03:48:50 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2022-02-03 03:49:53 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 04:01:46 +0100 | absentia | (~evocatus@24-212-138-156.cable.teksavvy.com) (Changing host) |
| 2022-02-03 04:01:46 +0100 | absentia | (~evocatus@user/absentia) |
| 2022-02-03 04:02:27 +0100 | absentia | (~evocatus@user/absentia) (Quit: WeeChat 3.4) |
| 2022-02-03 04:02:39 +0100 | evocatus | (~absentia@24-212-138-156.cable.teksavvy.com) |
| 2022-02-03 04:02:51 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) (Ping timeout: 256 seconds) |
| 2022-02-03 04:02:54 +0100 | evocatus | (~absentia@24-212-138-156.cable.teksavvy.com) (Client Quit) |
| 2022-02-03 04:03:06 +0100 | absentia | (~absentia@24-212-138-156.cable.teksavvy.com) |
| 2022-02-03 04:03:51 +0100 | absentia | (~absentia@24-212-138-156.cable.teksavvy.com) (Changing host) |
| 2022-02-03 04:03:51 +0100 | absentia | (~absentia@user/absentia) |
| 2022-02-03 04:03:57 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 240 seconds) |
| 2022-02-03 04:06:53 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 04:07:21 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-02-03 04:08:43 +0100 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-02-03 04:08:43 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2022-02-03 04:08:43 +0100 | finn_elija | FinnElija |
| 2022-02-03 04:11:29 +0100 | sprout | (~quassel@2a02:a467:ccd6:1:80b2:e90a:7da7:7a8d) |
| 2022-02-03 04:11:29 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 04:12:09 +0100 | vglfr | (~vglfr@88.155.15.0) (Ping timeout: 256 seconds) |
| 2022-02-03 04:13:37 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480::41) (Ping timeout: 240 seconds) |
| 2022-02-03 04:13:54 +0100 | mbuf | (~Shakthi@122.162.66.95) |
| 2022-02-03 04:14:31 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) |
| 2022-02-03 04:14:37 +0100 | sprout_ | (~quassel@2a02:a467:ccd6:1:b9e2:b772:90e7:5a2b) (Ping timeout: 240 seconds) |
| 2022-02-03 04:15:24 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2022-02-03 04:17:00 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-02-03 04:18:04 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Quit: WeeChat 3.4) |
| 2022-02-03 04:20:55 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) |
| 2022-02-03 04:24:35 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-02-03 04:25:20 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480:1b88:50f:dae0:9293) |
| 2022-02-03 04:25:44 +0100 | dawdler | (~dawdler@user/dawdler) |
| 2022-02-03 04:26:15 +0100 | tatarqa | (~kli@ip-89-177-122-45.net.upcbroadband.cz) (Remote host closed the connection) |
| 2022-02-03 04:26:31 +0100 | dawdler | (~dawdler@user/dawdler) (Client Quit) |
| 2022-02-03 04:27:01 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Quit: WeeChat 3.4) |
| 2022-02-03 04:29:25 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 04:31:53 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 04:33:21 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) |
| 2022-02-03 04:39:28 +0100 | dawdler | (035b60b5aa@user/dawdler) |
| 2022-02-03 04:42:08 +0100 | Topsi | (~Tobias@dyndsl-095-033-017-221.ewe-ip-backbone.de) (Read error: Connection reset by peer) |
| 2022-02-03 04:43:33 +0100 | td_ | (~td@muedsl-82-207-238-174.citykom.de) (Ping timeout: 256 seconds) |
| 2022-02-03 04:43:33 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Quit: WeeChat 3.4) |
| 2022-02-03 04:44:27 +0100 | td_ | (~td@94.134.91.183) |
| 2022-02-03 04:46:28 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) |
| 2022-02-03 04:46:57 +0100 | yauhsien_ | (~yauhsien@118-167-40-21.dynamic-ip.hinet.net) |
| 2022-02-03 04:48:35 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 04:48:55 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-02-03 04:48:55 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-02-03 04:48:55 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-02-03 04:51:17 +0100 | yauhsien_ | (~yauhsien@118-167-40-21.dynamic-ip.hinet.net) (Ping timeout: 240 seconds) |
| 2022-02-03 04:53:31 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-02-03 04:53:51 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-02-03 04:56:17 +0100 | burnsidesLlama | (~burnsides@dhcp168-027.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2022-02-03 04:56:50 +0100 | burnsidesLlama | (~burnsides@client-8-65.eduroam.oxuni.org.uk) |
| 2022-02-03 05:00:57 +0100 | burnsidesLlama | (~burnsides@client-8-65.eduroam.oxuni.org.uk) (Ping timeout: 240 seconds) |
| 2022-02-03 05:00:57 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 05:10:23 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-02-03 05:10:23 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-02-03 05:10:23 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-02-03 05:11:00 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Quit: WeeChat 3.4) |
| 2022-02-03 05:12:51 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) |
| 2022-02-03 05:15:16 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Remote host closed the connection) |
| 2022-02-03 05:15:41 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-02-03 05:17:39 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 05:18:36 +0100 | ralu | (~ralu@static.211.245.203.116.clients.your-server.de) (Ping timeout: 250 seconds) |
| 2022-02-03 05:19:26 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2022-02-03 05:20:37 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 240 seconds) |
| 2022-02-03 05:22:01 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-02-03 05:25:53 +0100 | <Axman6> | segfaultfizzbuzz: did you get anywhere with awpr's suggestion of using mapMaybe above? |
| 2022-02-03 05:30:26 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 05:30:55 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 256 seconds) |
| 2022-02-03 05:32:02 +0100 | waleee | (~waleee@2001:9b0:21d:fc00:398f:b003:b90d:acf4) (Ping timeout: 250 seconds) |
| 2022-02-03 05:36:20 +0100 | dawdler | (035b60b5aa@user/dawdler) (Remote host closed the connection) |
| 2022-02-03 05:37:13 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-02-03 05:39:17 +0100 | segfaultfizzbuzz | (~rustisafu@2602:306:cd3c:9350:cc4:c954:b25:db0a) (Ping timeout: 240 seconds) |
| 2022-02-03 05:39:58 +0100 | oscurochu | (~oscurochu@097-096-050-227.res.spectrum.com) |
| 2022-02-03 05:43:07 +0100 | raym | (~raym@user/raym) (Quit: kernel update, rebooting...) |
| 2022-02-03 05:43:57 +0100 | toshiblue | (~toshiblue@c-73-111-20-145.hsd1.il.comcast.net) (Ping timeout: 256 seconds) |
| 2022-02-03 05:45:39 +0100 | dawdler | (035b60b5aa@user/dawdler) |
| 2022-02-03 05:45:59 +0100 | oscurochu | (~oscurochu@097-096-050-227.res.spectrum.com) (Ping timeout: 256 seconds) |
| 2022-02-03 05:47:15 +0100 | raym | (~raym@user/raym) |
| 2022-02-03 05:48:09 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 05:53:20 +0100 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-02-03 05:53:21 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 06:03:57 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 240 seconds) |
| 2022-02-03 06:04:31 +0100 | vysn | (~vysn@user/vysn) (Ping timeout: 250 seconds) |
| 2022-02-03 06:05:39 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-02-03 06:11:49 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 06:13:05 +0100 | ProfSimm | (~ProfSimm@87.227.196.109) (Remote host closed the connection) |
| 2022-02-03 06:20:09 +0100 | yauhsien | (~yauhsien@118-167-40-21.dynamic-ip.hinet.net) |
| 2022-02-03 06:22:18 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 250 seconds) |
| 2022-02-03 06:24:10 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-02-03 06:24:31 +0100 | yauhsien | (~yauhsien@118-167-40-21.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-02-03 06:25:51 +0100 | zaquest | (~notzaques@5.130.79.72) |
| 2022-02-03 06:25:53 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-02-03 06:26:25 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 06:34:38 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-02-03 06:34:38 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-02-03 06:34:38 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-02-03 06:36:10 +0100 | ss4 | (~wootehfoo@user/wootehfoot) |
| 2022-02-03 06:38:23 +0100 | slowButPresent | (~slowButPr@user/slowbutpresent) (Quit: leaving) |
| 2022-02-03 06:38:35 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 256 seconds) |
| 2022-02-03 06:39:29 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-02-03 06:42:59 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 06:47:37 +0100 | notzmv | (~zmv@user/notzmv) (Ping timeout: 250 seconds) |
| 2022-02-03 06:48:15 +0100 | emf | (~emf@2620:10d:c090:400::5:b0fe) (Read error: Connection reset by peer) |
| 2022-02-03 06:50:29 +0100 | hpc | (~juzz@ip98-169-35-13.dc.dc.cox.net) (Ping timeout: 256 seconds) |
| 2022-02-03 06:50:41 +0100 | hpc | (~juzz@ip98-169-35-13.dc.dc.cox.net) |
| 2022-02-03 06:53:07 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 06:55:11 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-02-03 07:05:01 +0100 | notzmv | (~zmv@user/notzmv) |
| 2022-02-03 07:05:56 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2022-02-03 07:09:50 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-02-03 07:10:17 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 07:13:44 +0100 | gentauro | (~gentauro@user/gentauro) (Read error: Connection reset by peer) |
| 2022-02-03 07:17:47 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 256 seconds) |
| 2022-02-03 07:19:26 +0100 | gentauro | (~gentauro@user/gentauro) |
| 2022-02-03 07:22:43 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2022-02-03 07:23:17 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 07:24:15 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-02-03 07:32:41 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2022-02-03 07:36:13 +0100 | zmt00 | (~zmt00@user/zmt00) (Ping timeout: 240 seconds) |
| 2022-02-03 07:40:20 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 07:41:03 +0100 | shriekingnoise | (~shrieking@201.231.16.156) (Quit: Quit) |
| 2022-02-03 07:44:53 +0100 | _ht | (~quassel@231-169-21-31.ftth.glasoperator.nl) |
| 2022-02-03 07:46:12 +0100 | Inst | (~delicacie@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-02-03 07:46:46 +0100 | vysn | (~vysn@user/vysn) |
| 2022-02-03 07:50:14 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 07:51:47 +0100 | cynomys | (~cynomys@user/cynomys) (Ping timeout: 256 seconds) |
| 2022-02-03 07:53:19 +0100 | Midjak | (~Midjak@may53-1-78-226-116-92.fbx.proxad.net) |
| 2022-02-03 07:56:55 +0100 | Midjak | (~Midjak@may53-1-78-226-116-92.fbx.proxad.net) (Client Quit) |
| 2022-02-03 07:58:33 +0100 | whound | (~dust@2405:204:5488:ef4c:54b6:3467:52f3:e9f2) |
| 2022-02-03 07:58:34 +0100 | cynomys | (~cynomys@user/cynomys) |
| 2022-02-03 07:58:53 +0100 | sayola | (~vekto@dslb-002-201-085-116.002.201.pools.vodafone-ip.de) (Read error: Connection reset by peer) |
| 2022-02-03 08:01:19 +0100 | Jing | (~hedgehog@240e:390:7c53:a7e1:f460:9388:75e8:8181) |
| 2022-02-03 08:01:20 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-02-03 08:05:37 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 256 seconds) |
| 2022-02-03 08:06:16 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 08:10:27 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 08:11:06 +0100 | alp | (~alp@user/alp) |
| 2022-02-03 08:18:39 +0100 | Alex_test_ | (~al_test@178.34.151.37) |
| 2022-02-03 08:20:21 +0100 | Alex_test | (~al_test@178.34.151.37) (Ping timeout: 256 seconds) |
| 2022-02-03 08:25:23 +0100 | michalz | (~michalz@185.246.204.87) |
| 2022-02-03 08:25:52 +0100 | Boarders_ | (sid425905@id-425905.lymington.irccloud.com) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | JSharp | (sid4580@id-4580.lymington.irccloud.com) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | saolsen | (sid26430@id-26430.lymington.irccloud.com) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | tapas | (sid467876@id-467876.ilkley.irccloud.com) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | cbarrett | (sid192934@id-192934.helmsley.irccloud.com) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | enemeth79 | (sid309041@id-309041.lymington.irccloud.com) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | bjs | (sid190364@user/bjs) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | sclv | (sid39734@haskell/developer/sclv) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | mrianbloom | (sid350277@id-350277.ilkley.irccloud.com) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | dmj` | (sid72307@id-72307.hampstead.irccloud.com) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | acertain | (sid470584@id-470584.hampstead.irccloud.com) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | gaze___ | (sid387101@id-387101.helmsley.irccloud.com) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | hongminhee | (sid295@id-295.tinside.irccloud.com) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | whatsupdoc | (uid509081@hampstead.irccloud.com) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | asivitz | (uid178348@tinside.irccloud.com) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | econo | (uid147250@user/econo) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | cheater | (~Username@user/cheater) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | Guest6340 | (~cat@h-98-128-128-173.A351.priv.bahnhof.se) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | Sgeo | (~Sgeo@user/sgeo) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | deadmarshal | (~deadmarsh@95.38.114.110) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | xdej | (~xdej@quatramaran.salle-s.org) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | red-snail | (~snail@static.151.210.203.116.clients.your-server.de) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | hyiltiz | (~quassel@31.220.5.250) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | quintasan | (~quassel@quintasan.pl) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | cigsender | (~cigsender@74.124.58.162) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | Hafydd | (~Hafydd@user/hafydd) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | aria | (sid380617@lymington.irccloud.com) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | oats | (~thomas@user/oats) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | ncopa | (~ncopa@alpine/developer/ncopa) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | lep | (~lep@94.31.89.203) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | AlexZenon | (~alzenon@178.34.151.37) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | ft | (~ft@shell.chaostreff-dortmund.de) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | russruss | (~russruss@my.russellmcc.com) (*.net *.split) |
| 2022-02-03 08:25:52 +0100 | tv | (~tv@user/tv) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | gawen_ | (~gawen@user/gawen) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | robertm | (~robertm@lattice.rojoma.com) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | swistak | (~swistak@185.21.216.141) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | wz1000 | (~zubin@static.11.113.47.78.clients.your-server.de) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | marquis_andras | (~marquis_a@124.170.163.166) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | justGhost | (~justache@user/justache) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | mmalter | (~mmalter@88.126.10.237) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | mcglk | (~mcglk@131.191.49.120) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | Maxdamantus | (~Maxdamant@user/maxdamantus) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | stvc | (~stvc@192.241.166.39) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | cls | (~cls@chalk.lubutu.com) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | cross_ | (~cross@spitfire.i.gajendra.net) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | skewerr | (spoonm@inaba.spoonm.org) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | drewr | (~drew@user/drewr) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | fryguybob | (~fryguybob@cpe-74-67-169-145.rochester.res.rr.com) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | haskl | (~haskl@user/haskl) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | mstksg | (~jle`@cpe-23-240-75-236.socal.res.rr.com) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | xstill- | (xstill@fimu/xstill) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | xsarnik | (xsarnik@lounge.fi.muni.cz) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | amk | (~amk@109.255.169.126) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | kojo5551 | (~kojo5551@fep.grid.pub.ro) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | abrar | (~abrar@static-108-2-152-54.phlapa.fios.verizon.net) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | kmein | (~weechat@user/kmein) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | c_wraith | (~c_wraith@adjoint.us) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | statusfailed | (~statusfai@statusfailed.com) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | canta | (~canta@user/canta) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | dminuoso | (~dminuoso@user/dminuoso) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | juri_ | (~juri@178.63.35.222) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | tolt | (~weechat-h@li219-154.members.linode.com) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | mmaruseacph2 | (~mihai@198.199.100.72) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | meejah | (~meejah@rutas.meejah.ca) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | andjjj23_ | (~irc@107.170.228.47) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | neverwas | (jpneverwas@swissbox.unperson.link) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | n3t | (n3t@user/n3t) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | loonycyborg | (~loonycybo@wesnoth/developer/loonycyborg) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | drdo | (~drdo@roach0.drdo.eu) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | ByronJohnson | (~bairyn@50-250-232-19-static.hfc.comcastbusiness.net) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | carter | (sid14827@helmsley.irccloud.com) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | TMA | (~tma@twin.jikos.cz) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | hubvu_ | (sid495858@tinside.irccloud.com) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | jtmar | (~james@jtmar.me) (*.net *.split) |
| 2022-02-03 08:25:53 +0100 | kawpuh | (~kawpuh@66.42.81.80) (*.net *.split) |
| 2022-02-03 08:26:09 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-02-03 08:27:26 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 08:28:04 +0100 | whatsupdoc | (uid509081@hampstead.irccloud.com) |
| 2022-02-03 08:28:04 +0100 | asivitz | (uid178348@tinside.irccloud.com) |
| 2022-02-03 08:28:04 +0100 | econo | (uid147250@user/econo) |
| 2022-02-03 08:28:04 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2022-02-03 08:28:04 +0100 | cheater | (~Username@user/cheater) |
| 2022-02-03 08:28:04 +0100 | Guest6340 | (~cat@h-98-128-128-173.A351.priv.bahnhof.se) |
| 2022-02-03 08:28:04 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-02-03 08:28:04 +0100 | deadmarshal | (~deadmarsh@95.38.114.110) |
| 2022-02-03 08:28:04 +0100 | xdej | (~xdej@quatramaran.salle-s.org) |
| 2022-02-03 08:28:04 +0100 | red-snail | (~snail@static.151.210.203.116.clients.your-server.de) |
| 2022-02-03 08:28:04 +0100 | hyiltiz | (~quassel@31.220.5.250) |
| 2022-02-03 08:28:04 +0100 | quintasan | (~quassel@quintasan.pl) |
| 2022-02-03 08:28:04 +0100 | cigsender | (~cigsender@74.124.58.162) |
| 2022-02-03 08:28:04 +0100 | Hafydd | (~Hafydd@user/hafydd) |
| 2022-02-03 08:28:04 +0100 | aria | (sid380617@lymington.irccloud.com) |
| 2022-02-03 08:28:04 +0100 | oats | (~thomas@user/oats) |
| 2022-02-03 08:28:04 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) |
| 2022-02-03 08:28:04 +0100 | ncopa | (~ncopa@alpine/developer/ncopa) |
| 2022-02-03 08:28:04 +0100 | lep | (~lep@94.31.89.203) |
| 2022-02-03 08:28:04 +0100 | AlexZenon | (~alzenon@178.34.151.37) |
| 2022-02-03 08:28:04 +0100 | ft | (~ft@shell.chaostreff-dortmund.de) |
| 2022-02-03 08:28:04 +0100 | russruss | (~russruss@my.russellmcc.com) |
| 2022-02-03 08:28:04 +0100 | tv | (~tv@user/tv) |
| 2022-02-03 08:28:04 +0100 | gawen_ | (~gawen@user/gawen) |
| 2022-02-03 08:28:04 +0100 | robertm | (~robertm@lattice.rojoma.com) |
| 2022-02-03 08:28:04 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-02-03 08:28:04 +0100 | swistak | (~swistak@185.21.216.141) |
| 2022-02-03 08:28:04 +0100 | wz1000 | (~zubin@static.11.113.47.78.clients.your-server.de) |
| 2022-02-03 08:28:04 +0100 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) |
| 2022-02-03 08:28:04 +0100 | marquis_andras | (~marquis_a@124.170.163.166) |
| 2022-02-03 08:28:04 +0100 | justGhost | (~justache@user/justache) |
| 2022-02-03 08:28:04 +0100 | mmalter | (~mmalter@88.126.10.237) |
| 2022-02-03 08:28:04 +0100 | mcglk | (~mcglk@131.191.49.120) |
| 2022-02-03 08:28:04 +0100 | Maxdamantus | (~Maxdamant@user/maxdamantus) |
| 2022-02-03 08:28:04 +0100 | stvc | (~stvc@192.241.166.39) |
| 2022-02-03 08:28:04 +0100 | cls | (~cls@chalk.lubutu.com) |
| 2022-02-03 08:28:04 +0100 | cross_ | (~cross@spitfire.i.gajendra.net) |
| 2022-02-03 08:28:04 +0100 | skewerr | (spoonm@inaba.spoonm.org) |
| 2022-02-03 08:28:04 +0100 | drewr | (~drew@user/drewr) |
| 2022-02-03 08:28:04 +0100 | fryguybob | (~fryguybob@cpe-74-67-169-145.rochester.res.rr.com) |
| 2022-02-03 08:28:04 +0100 | haskl | (~haskl@user/haskl) |
| 2022-02-03 08:28:04 +0100 | mstksg | (~jle`@cpe-23-240-75-236.socal.res.rr.com) |
| 2022-02-03 08:28:04 +0100 | xstill- | (xstill@fimu/xstill) |
| 2022-02-03 08:28:04 +0100 | xsarnik | (xsarnik@lounge.fi.muni.cz) |
| 2022-02-03 08:28:04 +0100 | amk | (~amk@109.255.169.126) |
| 2022-02-03 08:28:04 +0100 | kojo5551 | (~kojo5551@fep.grid.pub.ro) |
| 2022-02-03 08:28:04 +0100 | abrar | (~abrar@static-108-2-152-54.phlapa.fios.verizon.net) |
| 2022-02-03 08:28:04 +0100 | kmein | (~weechat@user/kmein) |
| 2022-02-03 08:28:04 +0100 | c_wraith | (~c_wraith@adjoint.us) |
| 2022-02-03 08:28:04 +0100 | statusfailed | (~statusfai@statusfailed.com) |
| 2022-02-03 08:28:04 +0100 | canta | (~canta@user/canta) |
| 2022-02-03 08:28:04 +0100 | dminuoso | (~dminuoso@user/dminuoso) |
| 2022-02-03 08:28:04 +0100 | juri_ | (~juri@178.63.35.222) |
| 2022-02-03 08:28:04 +0100 | tolt | (~weechat-h@li219-154.members.linode.com) |
| 2022-02-03 08:28:04 +0100 | mmaruseacph2 | (~mihai@198.199.100.72) |
| 2022-02-03 08:28:04 +0100 | meejah | (~meejah@rutas.meejah.ca) |
| 2022-02-03 08:28:04 +0100 | andjjj23_ | (~irc@107.170.228.47) |
| 2022-02-03 08:28:04 +0100 | neverwas | (jpneverwas@swissbox.unperson.link) |
| 2022-02-03 08:28:04 +0100 | n3t | (n3t@user/n3t) |
| 2022-02-03 08:28:04 +0100 | loonycyborg | (~loonycybo@wesnoth/developer/loonycyborg) |
| 2022-02-03 08:28:04 +0100 | drdo | (~drdo@roach0.drdo.eu) |
| 2022-02-03 08:28:04 +0100 | ByronJohnson | (~bairyn@50-250-232-19-static.hfc.comcastbusiness.net) |
| 2022-02-03 08:28:04 +0100 | carter | (sid14827@helmsley.irccloud.com) |
| 2022-02-03 08:28:04 +0100 | TMA | (~tma@twin.jikos.cz) |
| 2022-02-03 08:28:04 +0100 | hubvu_ | (sid495858@tinside.irccloud.com) |
| 2022-02-03 08:28:04 +0100 | jtmar | (~james@jtmar.me) |
| 2022-02-03 08:28:04 +0100 | kawpuh | (~kawpuh@66.42.81.80) |
| 2022-02-03 08:28:04 +0100 | Boarders_ | (sid425905@id-425905.lymington.irccloud.com) |
| 2022-02-03 08:28:04 +0100 | JSharp | (sid4580@id-4580.lymington.irccloud.com) |
| 2022-02-03 08:28:04 +0100 | saolsen | (sid26430@id-26430.lymington.irccloud.com) |
| 2022-02-03 08:28:04 +0100 | tapas | (sid467876@id-467876.ilkley.irccloud.com) |
| 2022-02-03 08:28:04 +0100 | cbarrett | (sid192934@id-192934.helmsley.irccloud.com) |
| 2022-02-03 08:28:04 +0100 | enemeth79 | (sid309041@id-309041.lymington.irccloud.com) |
| 2022-02-03 08:28:04 +0100 | bjs | (sid190364@user/bjs) |
| 2022-02-03 08:28:04 +0100 | sclv | (sid39734@haskell/developer/sclv) |
| 2022-02-03 08:28:04 +0100 | mrianbloom | (sid350277@id-350277.ilkley.irccloud.com) |
| 2022-02-03 08:28:04 +0100 | dmj` | (sid72307@id-72307.hampstead.irccloud.com) |
| 2022-02-03 08:28:04 +0100 | acertain | (sid470584@id-470584.hampstead.irccloud.com) |
| 2022-02-03 08:28:04 +0100 | gaze___ | (sid387101@id-387101.helmsley.irccloud.com) |
| 2022-02-03 08:28:04 +0100 | hongminhee | (sid295@id-295.tinside.irccloud.com) |
| 2022-02-03 08:31:13 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-02-03 08:31:13 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 08:34:32 +0100 | Andrew | Guest110 |
| 2022-02-03 08:34:32 +0100 | Guest110 | (andrew@andrewyu.org) (Killed (molybdenum.libera.chat (Nickname regained by services))) |
| 2022-02-03 08:34:45 +0100 | Andrew_ | (andrew@andrewyu.org) |
| 2022-02-03 08:35:28 +0100 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) |
| 2022-02-03 08:36:44 +0100 | emf | (~emf@2620:10d:c090:400::5:d558) |
| 2022-02-03 08:39:57 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2022-02-03 08:41:21 +0100 | michalz2 | (~michalz2@185.246.204.87) |
| 2022-02-03 08:43:41 +0100 | fef | (~thedawn@user/thedawn) |
| 2022-02-03 08:44:47 +0100 | oscurochu | (~oscurochu@097-096-050-227.res.spectrum.com) |
| 2022-02-03 08:46:12 +0100 | adnaahm | (~adnaahm@host-97-net-64-160-119.mobilinkinfinity.net.pk) |
| 2022-02-03 08:46:29 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
| 2022-02-03 08:47:27 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 08:51:57 +0100 | _ht | (~quassel@231-169-21-31.ftth.glasoperator.nl) (Ping timeout: 240 seconds) |
| 2022-02-03 08:52:07 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 08:52:35 +0100 | _ht | (~quassel@231-169-21-31.ftth.glasoperator.nl) |
| 2022-02-03 08:52:46 +0100 | gehmehgeh | (~user@user/gehmehgeh) |
| 2022-02-03 08:52:58 +0100 | MajorBiscuit | (~MajorBisc@86-88-79-148.fixed.kpn.net) |
| 2022-02-03 08:52:59 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 256 seconds) |
| 2022-02-03 08:54:36 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-02-03 08:54:51 +0100 | coot | (~coot@213.134.190.95) |
| 2022-02-03 08:56:37 +0100 | foul_owl | (~kerry@94.140.8.105) (Ping timeout: 256 seconds) |
| 2022-02-03 08:57:19 +0100 | xkuru | (~xkuru@user/xkuru) |
| 2022-02-03 08:57:45 +0100 | MajorBiscuit | (~MajorBisc@86-88-79-148.fixed.kpn.net) (Ping timeout: 256 seconds) |
| 2022-02-03 08:59:10 +0100 | MajorBiscuit | (~MajorBisc@c-001-015-052.client.tudelft.eduvpn.nl) |
| 2022-02-03 09:01:27 +0100 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Remote host closed the connection) |
| 2022-02-03 09:01:27 +0100 | meltedbrain_y2k | (~tekserf@47.61.115.91) (Read error: Connection reset by peer) |
| 2022-02-03 09:06:33 +0100 | <dminuoso> | monochrom: I can see a few somewhat valid ones. |
| 2022-02-03 09:07:08 +0100 | <dminuoso> | When the HTML input is somewhat static/controllable and known to be parseable by your XML library, then that could be a good reason |
| 2022-02-03 09:07:29 +0100 | <dminuoso> | Heck, I've done regexp matching on XML before for the same reason |
| 2022-02-03 09:07:37 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 240 seconds) |
| 2022-02-03 09:08:28 +0100 | sprout_ | (~quassel@2a02:a467:ccd6:1:2dea:f16f:b001:1064) |
| 2022-02-03 09:08:37 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 09:09:59 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-02-03 09:11:37 +0100 | sprout | (~quassel@2a02:a467:ccd6:1:80b2:e90a:7da7:7a8d) (Ping timeout: 240 seconds) |
| 2022-02-03 09:12:20 +0100 | foul_owl | (~kerry@94.140.8.107) |
| 2022-02-03 09:12:57 +0100 | alp | (~alp@user/alp) (Ping timeout: 240 seconds) |
| 2022-02-03 09:13:20 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 09:13:36 +0100 | mcgroin | (~mcgroin@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) |
| 2022-02-03 09:14:26 +0100 | sprout | (~quassel@2a02:a467:ccd6:1:51ac:e09e:aad0:faee) |
| 2022-02-03 09:17:17 +0100 | sprout_ | (~quassel@2a02:a467:ccd6:1:2dea:f16f:b001:1064) (Ping timeout: 240 seconds) |
| 2022-02-03 09:18:06 +0100 | whound | (~dust@2405:204:5488:ef4c:54b6:3467:52f3:e9f2) (Quit: Konversation terminated!) |
| 2022-02-03 09:18:45 +0100 | Ariakenom | (~Ariakenom@h-82-196-111-63.na.cust.bahnhof.se) |
| 2022-02-03 09:20:37 +0100 | meltedbrain_y2k | (~tekserf@47.61.115.91) |
| 2022-02-03 09:20:44 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-02-03 09:25:07 +0100 | alp | (~alp@user/alp) |
| 2022-02-03 09:25:17 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 240 seconds) |
| 2022-02-03 09:27:05 +0100 | Gurkenglas | (~Gurkengla@dslb-090-186-104-244.090.186.pools.vodafone-ip.de) |
| 2022-02-03 09:27:25 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-02-03 09:28:17 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-02-03 09:29:09 +0100 | gehmehgeh | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2022-02-03 09:29:47 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 09:29:53 +0100 | gehmehgeh | (~user@user/gehmehgeh) |
| 2022-02-03 09:33:14 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 09:34:16 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:286e:ce4:a8f3:ca6f) |
| 2022-02-03 09:34:52 +0100 | oscurochu | (~oscurochu@097-096-050-227.res.spectrum.com) (Remote host closed the connection) |
| 2022-02-03 09:36:02 +0100 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-02-03 09:36:43 +0100 | glguy | (x@libera/staff/glguy) (Read error: Connection reset by peer) |
| 2022-02-03 09:37:13 +0100 | glguy | (x@libera/staff/glguy) |
| 2022-02-03 09:37:17 +0100 | emf | (~emf@2620:10d:c090:400::5:d558) (Ping timeout: 240 seconds) |
| 2022-02-03 09:38:50 +0100 | ardell | (~ardell@user/ardell) |
| 2022-02-03 09:39:37 +0100 | cyphase | (~cyphase@user/cyphase) (Ping timeout: 240 seconds) |
| 2022-02-03 09:43:09 +0100 | cyphase | (~cyphase@user/cyphase) |
| 2022-02-03 09:47:43 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-02-03 09:49:34 +0100 | ss4 | (~wootehfoo@user/wootehfoot) (Quit: Leaving) |
| 2022-02-03 09:49:48 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 09:49:50 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2022-02-03 09:49:59 +0100 | machinedgod | (~machinedg@24.105.81.50) |
| 2022-02-03 09:50:58 +0100 | nschoe | (~quassel@178.251.84.79) |
| 2022-02-03 09:51:31 +0100 | gargawel | (~kvirc@82-65-144-99.subs.proxad.net) |
| 2022-02-03 09:51:53 +0100 | max22- | (~maxime@2a01cb088335980058f4ffda4eee6f66.ipv6.abo.wanadoo.fr) |
| 2022-02-03 09:53:03 +0100 | xff0x | (~xff0x@2001:1a81:53e8:2500:a319:1c51:2e8e:9977) (Ping timeout: 256 seconds) |
| 2022-02-03 09:53:56 +0100 | xff0x | (~xff0x@2001:1a81:53e8:2500:31e6:f5f6:6492:6bc2) |
| 2022-02-03 09:54:17 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds) |
| 2022-02-03 09:54:25 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 09:54:35 +0100 | oscurochu | (~oscurochu@097-096-050-227.res.spectrum.com) |
| 2022-02-03 09:56:55 +0100 | cfricke | (~cfricke@user/cfricke) |
| 2022-02-03 09:57:56 +0100 | fendor | (~fendor@178.165.184.56.wireless.dyn.drei.com) |
| 2022-02-03 10:02:07 +0100 | jstolarek | (~jstolarek@staticline-31-183-164-222.toya.net.pl) |
| 2022-02-03 10:04:27 +0100 | x_kuru | (~xkuru@user/xkuru) |
| 2022-02-03 10:06:37 +0100 | xkuru | (~xkuru@user/xkuru) (Ping timeout: 240 seconds) |
| 2022-02-03 10:09:37 +0100 | oscurochu | (~oscurochu@097-096-050-227.res.spectrum.com) (Ping timeout: 240 seconds) |
| 2022-02-03 10:10:58 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 10:11:05 +0100 | lewisje | (~lewisje@72.49.207.113) (Quit: Leaving) |
| 2022-02-03 10:11:23 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Quit: WeeChat 3.4) |
| 2022-02-03 10:12:40 +0100 | jstolarek | (~jstolarek@staticline-31-183-164-222.toya.net.pl) (Quit: leaving) |
| 2022-02-03 10:17:41 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b))) |
| 2022-02-03 10:17:41 +0100 | allbery_b | (~geekosaur@xmonad/geekosaur) |
| 2022-02-03 10:17:44 +0100 | allbery_b | geekosaur |
| 2022-02-03 10:17:54 +0100 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2022-02-03 10:19:17 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 240 seconds) |
| 2022-02-03 10:20:25 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 10:22:22 +0100 | Andrew_ | Andrew |
| 2022-02-03 10:22:28 +0100 | Erutuon | (~Erutuon@user/erutuon) |
| 2022-02-03 10:25:27 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-02-03 10:30:15 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) (Ping timeout: 276 seconds) |
| 2022-02-03 10:31:03 +0100 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.3) |
| 2022-02-03 10:31:47 +0100 | gargawel | (~kvirc@82-65-144-99.subs.proxad.net) (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/) |
| 2022-02-03 10:31:53 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) |
| 2022-02-03 10:33:40 +0100 | ubert1 | (~Thunderbi@p200300ecdf0994a1946b5f66cf92c0df.dip0.t-ipconnect.de) |
| 2022-02-03 10:35:55 +0100 | oscurochu | (~oscurochu@097-096-050-227.res.spectrum.com) |
| 2022-02-03 10:38:37 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 10:39:00 +0100 | Jing | (~hedgehog@240e:390:7c53:a7e1:f460:9388:75e8:8181) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-02-03 10:39:31 +0100 | whatsupdoc | (uid509081@hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-02-03 10:41:45 +0100 | cfricke | (~cfricke@user/cfricke) |
| 2022-02-03 10:44:03 +0100 | adnaahm | (~adnaahm@host-97-net-64-160-119.mobilinkinfinity.net.pk) (Ping timeout: 256 seconds) |
| 2022-02-03 10:44:51 +0100 | oscurochu | (~oscurochu@097-096-050-227.res.spectrum.com) (Ping timeout: 256 seconds) |
| 2022-02-03 10:45:26 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:a148:40f0:8827:c6ab) (Remote host closed the connection) |
| 2022-02-03 10:46:57 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480:1b88:50f:dae0:9293) (Ping timeout: 240 seconds) |
| 2022-02-03 10:47:04 +0100 | jgeerds | (~jgeerds@55d4a547.access.ecotel.net) |
| 2022-02-03 10:48:05 +0100 | tinwood | (~tinwood@canonical/tinwood) (Remote host closed the connection) |
| 2022-02-03 10:49:10 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 10:50:23 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-166.elisa-laajakaista.fi) |
| 2022-02-03 10:51:06 +0100 | tinwood | (~tinwood@general.default.akavanagh.uk0.bigv.io) |
| 2022-02-03 10:51:06 +0100 | tinwood | (~tinwood@general.default.akavanagh.uk0.bigv.io) (Changing host) |
| 2022-02-03 10:51:06 +0100 | tinwood | (~tinwood@canonical/tinwood) |
| 2022-02-03 10:51:13 +0100 | adnaahm | (~adnaahm@host-83-net-67-160-119.mobilinkinfinity.net.pk) |
| 2022-02-03 10:52:16 +0100 | Akiva | (~Akiva@user/Akiva) (Ping timeout: 250 seconds) |
| 2022-02-03 10:58:09 +0100 | CiaoSen | (~Jura@p200300c95737a2002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-02-03 10:58:13 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2022-02-03 10:59:50 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-02-03 11:00:55 +0100 | __monty__ | (~toonn@user/toonn) |
| 2022-02-03 11:01:02 +0100 | oscurochu | (~oscurochu@097-096-050-227.res.spectrum.com) |
| 2022-02-03 11:02:03 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2022-02-03 11:05:32 +0100 | Jing | (~hedgehog@240e:390:7c53:a7e1:7da5:59e:42b2:ced5) |
| 2022-02-03 11:05:49 +0100 | oscurochu | (~oscurochu@097-096-050-227.res.spectrum.com) (Ping timeout: 256 seconds) |
| 2022-02-03 11:05:49 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 11:08:21 +0100 | sprout_ | (~quassel@2a02:a467:ccd6:1:a85e:5217:60c2:bcc7) |
| 2022-02-03 11:10:16 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 11:11:17 +0100 | sprout | (~quassel@2a02:a467:ccd6:1:51ac:e09e:aad0:faee) (Ping timeout: 240 seconds) |
| 2022-02-03 11:11:20 +0100 | Techcable | (~Techcable@168.235.93.147) (Remote host closed the connection) |
| 2022-02-03 11:11:53 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-02-03 11:12:53 +0100 | Techcable | (~Techcable@168.235.93.147) |
| 2022-02-03 11:13:56 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) |
| 2022-02-03 11:16:05 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-02-03 11:19:15 +0100 | haskellberryfinn | (~nut@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) |
| 2022-02-03 11:19:18 +0100 | coot | (~coot@213.134.190.95) (Quit: coot) |
| 2022-02-03 11:19:47 +0100 | coot | (~coot@213.134.190.95) |
| 2022-02-03 11:20:38 +0100 | Guest87 | (~Guest87@4.53.152.194.mga.com.pl) |
| 2022-02-03 11:25:09 +0100 | Guest87 | (~Guest87@4.53.152.194.mga.com.pl) (Client Quit) |
| 2022-02-03 11:26:29 +0100 | jgeerds | (~jgeerds@55d4a547.access.ecotel.net) (Ping timeout: 250 seconds) |
| 2022-02-03 11:26:46 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 11:28:01 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) (Remote host closed the connection) |
| 2022-02-03 11:31:21 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2022-02-03 11:33:04 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-02-03 11:33:09 +0100 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-02-03 11:33:39 +0100 | mmhat | (~mmh@55d48978.access.ecotel.net) |
| 2022-02-03 11:35:11 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) |
| 2022-02-03 11:38:18 +0100 | zaquest | (~notzaques@5.130.79.72) |
| 2022-02-03 11:39:14 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 11:39:37 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 240 seconds) |
| 2022-02-03 11:40:18 +0100 | Benzi-Junior | (~BenziJuni@dsl-149-66-61.hive.is) |
| 2022-02-03 11:44:21 +0100 | fef | (~thedawn@user/thedawn) (Ping timeout: 276 seconds) |
| 2022-02-03 11:46:18 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:4821:3bd5:6699:99c5) |
| 2022-02-03 11:48:39 +0100 | CiaoSen | (~Jura@p200300c95737a2002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-02-03 11:49:14 +0100 | DNH | (~DNH@2a02:8108:1100:16d8:a4a2:67d7:acda:e455) |
| 2022-02-03 11:50:37 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:4821:3bd5:6699:99c5) (Ping timeout: 240 seconds) |
| 2022-02-03 11:54:11 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2022-02-03 11:55:07 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 256 seconds) |
| 2022-02-03 11:55:30 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2022-02-03 11:57:15 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 12:01:55 +0100 | Inst | (~delicacie@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 256 seconds) |
| 2022-02-03 12:10:56 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 12:16:16 +0100 | oscuroch_ | (~oscurochu@097-096-050-227.res.spectrum.com) |
| 2022-02-03 12:18:01 +0100 | haskellberryfinn | (~nut@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 256 seconds) |
| 2022-02-03 12:19:07 +0100 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.3) |
| 2022-02-03 12:25:29 +0100 | oscuroch_ | (~oscurochu@097-096-050-227.res.spectrum.com) (Ping timeout: 256 seconds) |
| 2022-02-03 12:28:52 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 12:29:27 +0100 | Axma76527 | (~Axman6@user/axman6) |
| 2022-02-03 12:31:20 +0100 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 260 seconds) |
| 2022-02-03 12:31:34 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 12:36:37 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds) |
| 2022-02-03 12:38:30 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-02-03 12:43:52 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2022-02-03 12:47:06 +0100 | chenqisu1 | (~chenqisu1@183.217.200.249) (Quit: Leaving) |
| 2022-02-03 12:47:59 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 12:52:07 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 12:53:57 +0100 | alp | (~alp@user/alp) (Ping timeout: 240 seconds) |
| 2022-02-03 13:06:34 +0100 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.3) |
| 2022-02-03 13:09:54 +0100 | alp | (~alp@user/alp) |
| 2022-02-03 13:10:30 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 13:11:53 +0100 | yauhsien_ | (~yauhsien@118-167-40-21.dynamic-ip.hinet.net) |
| 2022-02-03 13:11:57 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Ping timeout: 240 seconds) |
| 2022-02-03 13:14:15 +0100 | ss4 | (~wootehfoo@user/wootehfoot) |
| 2022-02-03 13:16:43 +0100 | yauhsien_ | (~yauhsien@118-167-40-21.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-02-03 13:17:47 +0100 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2022-02-03 13:18:25 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 256 seconds) |
| 2022-02-03 13:19:28 +0100 | ss4 | (~wootehfoo@user/wootehfoot) (Quit: Leaving) |
| 2022-02-03 13:19:31 +0100 | zincy | (~zincy@2a00:23c8:970c:4801:340a:21f3:9185:5e11) |
| 2022-02-03 13:21:35 +0100 | cynomys | (~cynomys@user/cynomys) (Ping timeout: 256 seconds) |
| 2022-02-03 13:22:23 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-02-03 13:23:06 +0100 | DNH | (~DNH@2a02:8108:1100:16d8:a4a2:67d7:acda:e455) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-02-03 13:23:09 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-02-03 13:23:35 +0100 | CiaoSen | (~Jura@p200300c95737a2002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-02-03 13:25:23 +0100 | wombat875 | (~wombat875@pool-72-89-24-154.nycmny.fios.verizon.net) |
| 2022-02-03 13:26:18 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 13:26:24 +0100 | DNH | (~DNH@2a02:8108:1100:16d8:a4a2:67d7:acda:e455) |
| 2022-02-03 13:29:37 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) |
| 2022-02-03 13:30:44 +0100 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2022-02-03 13:30:44 +0100 | meltedbrain_y2k | (~tekserf@47.61.115.91) (Read error: Connection reset by peer) |
| 2022-02-03 13:31:02 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2022-02-03 13:32:01 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-02-03 13:33:14 +0100 | biberu | (~biberu@user/biberu) (Ping timeout: 268 seconds) |
| 2022-02-03 13:33:37 +0100 | wombat875 | (~wombat875@pool-72-89-24-154.nycmny.fios.verizon.net) (Ping timeout: 240 seconds) |
| 2022-02-03 13:33:42 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-02-03 13:36:00 +0100 | wombat875 | (~wombat875@pool-72-89-24-154.nycmny.fios.verizon.net) |
| 2022-02-03 13:37:01 +0100 | wombat875 | (~wombat875@pool-72-89-24-154.nycmny.fios.verizon.net) (Client Quit) |
| 2022-02-03 13:40:03 +0100 | LiaoTao | (~LiaoTao@gateway/tor-sasl/liaotao) (Ping timeout: 276 seconds) |
| 2022-02-03 13:40:37 +0100 | biberu | (~biberu@user/biberu) |
| 2022-02-03 13:41:10 +0100 | wombat875 | (~wombat875@pool-72-89-24-154.nycmny.fios.verizon.net) |
| 2022-02-03 13:43:07 +0100 | Gurkenglas | (~Gurkengla@dslb-090-186-104-244.090.186.pools.vodafone-ip.de) (Read error: Connection reset by peer) |
| 2022-02-03 13:45:38 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 13:48:08 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:7058:4e81:e6e0:f9f) |
| 2022-02-03 13:48:37 +0100 | meltedbrain_y2k | (~tekserf@47.61.115.91) |
| 2022-02-03 13:49:06 +0100 | LiaoTao | (~LiaoTao@gateway/tor-sasl/liaotao) |
| 2022-02-03 13:49:15 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 13:52:17 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:7058:4e81:e6e0:f9f) (Ping timeout: 240 seconds) |
| 2022-02-03 13:52:37 +0100 | wombat875 | (~wombat875@pool-72-89-24-154.nycmny.fios.verizon.net) (Ping timeout: 240 seconds) |
| 2022-02-03 13:53:39 +0100 | wombat875 | (~wombat875@pool-72-89-24-154.nycmny.fios.verizon.net) |
| 2022-02-03 13:56:34 +0100 | kaph | (~kaph@net-2-47-208-144.cust.vodafonedsl.it) |
| 2022-02-03 13:58:27 +0100 | Inst | (~delicacie@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-02-03 14:00:06 +0100 | zincy | (~zincy@2a00:23c8:970c:4801:340a:21f3:9185:5e11) (Remote host closed the connection) |
| 2022-02-03 14:05:48 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 14:09:51 +0100 | max22- | (~maxime@2a01cb088335980058f4ffda4eee6f66.ipv6.abo.wanadoo.fr) (Ping timeout: 250 seconds) |
| 2022-02-03 14:11:08 +0100 | fendor_ | (~fendor@178.115.38.12.wireless.dyn.drei.com) |
| 2022-02-03 14:13:57 +0100 | fendor | (~fendor@178.165.184.56.wireless.dyn.drei.com) (Ping timeout: 256 seconds) |
| 2022-02-03 14:13:57 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 14:14:29 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2022-02-03 14:15:59 +0100 | tatarqa | (~kli@ip-89-177-122-45.net.upcbroadband.cz) |
| 2022-02-03 14:16:10 +0100 | zincy | (~zincy@2a00:23c8:970c:4801:340a:21f3:9185:5e11) |
| 2022-02-03 14:20:18 +0100 | jgeerds | (~jgeerds@55d4a547.access.ecotel.net) |
| 2022-02-03 14:24:54 +0100 | Gurkenglas | (~Gurkengla@dslb-090-186-104-244.090.186.pools.vodafone-ip.de) |
| 2022-02-03 14:25:33 +0100 | zincy | (~zincy@2a00:23c8:970c:4801:340a:21f3:9185:5e11) (Remote host closed the connection) |
| 2022-02-03 14:26:12 +0100 | califax | (~califax@user/califx) (Ping timeout: 276 seconds) |
| 2022-02-03 14:32:26 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 14:32:56 +0100 | califax | (~califax@user/califx) |
| 2022-02-03 14:32:57 +0100 | biberu | (~biberu@user/biberu) (Ping timeout: 240 seconds) |
| 2022-02-03 14:35:35 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 14:35:51 +0100 | slowButPresent | (~slowButPr@user/slowbutpresent) |
| 2022-02-03 14:40:40 +0100 | biberu | (~biberu@user/biberu) |
| 2022-02-03 14:41:37 +0100 | adnaahm | (~adnaahm@host-83-net-67-160-119.mobilinkinfinity.net.pk) (Ping timeout: 240 seconds) |
| 2022-02-03 14:42:21 +0100 | adnaahm | (~adnaahm@host-251-net-67-160-119.mobilinkinfinity.net.pk) |
| 2022-02-03 14:45:36 +0100 | slack1256 | (~slack1256@186.11.97.54) |
| 2022-02-03 14:52:42 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 14:56:26 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 14:57:56 +0100 | adnaahm | (~adnaahm@host-251-net-67-160-119.mobilinkinfinity.net.pk) (Read error: Connection reset by peer) |
| 2022-02-03 15:04:23 +0100 | Inst | (~delicacie@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 256 seconds) |
| 2022-02-03 15:05:21 +0100 | Pickchea | (~private@user/pickchea) |
| 2022-02-03 15:06:21 +0100 | cfricke | (~cfricke@user/cfricke) |
| 2022-02-03 15:06:56 +0100 | ProfSimm | (~ProfSimm@87.227.196.109) |
| 2022-02-03 15:08:02 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480::41) |
| 2022-02-03 15:08:08 +0100 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.3) |
| 2022-02-03 15:12:28 +0100 | alo | (~alo@host-79-36-108-33.retail.telecomitalia.it) |
| 2022-02-03 15:12:48 +0100 | alo | (~alo@host-79-36-108-33.retail.telecomitalia.it) () |
| 2022-02-03 15:12:59 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-02-03 15:12:59 +0100 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2022-02-03 15:13:17 +0100 | slac85046 | (~slack1256@191.126.99.75) |
| 2022-02-03 15:13:27 +0100 | jespada | (~jespada@87.74.36.188) (Ping timeout: 256 seconds) |
| 2022-02-03 15:14:18 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 15:15:43 +0100 | slack1256 | (~slack1256@186.11.97.54) (Ping timeout: 256 seconds) |
| 2022-02-03 15:15:57 +0100 | Pickchea | (~private@user/pickchea) (Ping timeout: 240 seconds) |
| 2022-02-03 15:16:18 +0100 | jespada | (~jespada@87.74.36.188) |
| 2022-02-03 15:19:29 +0100 | segfaultfizzbuzz | (~rustisafu@2602:306:cd3c:9350:cc4:c954:b25:db0a) |
| 2022-02-03 15:20:45 +0100 | <segfaultfizzbuzz> | so if i have: runResourceT . runConduit $ httpSource "https://imgur.com" getResponseBody .| parseBytes def .| ::() .| printC |
| 2022-02-03 15:20:57 +0100 | <segfaultfizzbuzz> | i want ::() to have ghc spit out the expected type there |
| 2022-02-03 15:21:26 +0100 | <geekosaur> | maybe you want _ instead of ::() |
| 2022-02-03 15:22:31 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 15:22:46 +0100 | <segfaultfizzbuzz> | b0 is an ambiguous type variable...? |
| 2022-02-03 15:22:59 +0100 | <dminuoso> | segfaultfizzbuzz: Can you share the entirety of the output perhaps? |
| 2022-02-03 15:23:16 +0100 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2022-02-03 15:23:41 +0100 | <segfaultfizzbuzz> | https://paste.rs/YWA.hs |
| 2022-02-03 15:23:58 +0100 | <segfaultfizzbuzz> | basically, i have something which works in that pipeline and i want to break it out into a function |
| 2022-02-03 15:24:19 +0100 | <segfaultfizzbuzz> | but i don't know how to get haskell to tell me the type of a part of the pipeline |
| 2022-02-03 15:24:20 +0100 | <dminuoso> | Yes, this is to be expected. |
| 2022-02-03 15:24:22 +0100 | <dminuoso> | printC is a sink |
| 2022-02-03 15:24:23 +0100 | max22- | (~maxime@2a01cb0883359800569e67c9db5ecf35.ipv6.abo.wanadoo.fr) |
| 2022-02-03 15:24:37 +0100 | <dminuoso> | printC :: (Show a, MonadIO m) => ConduitT a o m () |
| 2022-02-03 15:25:28 +0100 | <dminuoso> | Consider this: |
| 2022-02-03 15:25:47 +0100 | <segfaultfizzbuzz> | so my function type signature will be UnknownType -> (a, MonadIO) ? |
| 2022-02-03 15:26:01 +0100 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) |
| 2022-02-03 15:26:06 +0100 | <Clint> | no, your function should be a conduit |
| 2022-02-03 15:26:17 +0100 | <merijn> | Clint: That's not a function, though :p |
| 2022-02-03 15:26:33 +0100 | <dminuoso> | segfaultfizzbuzz: It's just that your attempt of using typed holes to gain inference is a bit flawed. |
| 2022-02-03 15:26:39 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-02-03 15:26:39 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-02-03 15:26:39 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-02-03 15:26:49 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:286e:ce4:a8f3:ca6f) (Ping timeout: 256 seconds) |
| 2022-02-03 15:27:25 +0100 | jgeerds | (~jgeerds@55d4a547.access.ecotel.net) (Ping timeout: 250 seconds) |
| 2022-02-03 15:27:41 +0100 | <segfaultfizzbuzz> | dminuso: funamentally flawed or just how i am carrying it out? |
| 2022-02-03 15:27:44 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-02-03 15:28:05 +0100 | <dminuoso> | Fundamentally flawed |
| 2022-02-03 15:30:54 +0100 | <segfaultfizzbuzz> | so then i look at parseBytes and printC to know my function input and output type? |
| 2022-02-03 15:31:06 +0100 | rusrushal13 | (~rusrushal@2409:4056:e82:6bda:bd0e:9743:fccb:b2a0) |
| 2022-02-03 15:31:06 +0100 | <dminuoso> | printC doesnt know its output type |
| 2022-02-03 15:31:17 +0100 | <segfaultfizzbuzz> | printC takes an input type |
| 2022-02-03 15:31:22 +0100 | <segfaultfizzbuzz> | my function's output is printC's input |
| 2022-02-03 15:31:23 +0100 | <dminuoso> | And its ambiguous in its input type too |
| 2022-02-03 15:32:33 +0100 | <Clint> | presumably you know what you want to do with the output of parseBytes before you feed it to printC |
| 2022-02-03 15:34:57 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 240 seconds) |
| 2022-02-03 15:35:05 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:5722:cfcd:da3c:1af2) |
| 2022-02-03 15:36:07 +0100 | <dminuoso> | segfaultfizzbuzz: printC learns about its input and output types based on its surroundings. |
| 2022-02-03 15:36:11 +0100 | <dminuoso> | Based on inference. |
| 2022-02-03 15:36:36 +0100 | <merijn> | segfaultfizzbuzz: What GHC expects is a "ConduitT a b m r" where 'a' = whatever comes out of parsebytes and 'b' is something Showable |
| 2022-02-03 15:36:51 +0100 | <maerwald> | still fighting conduit API? :D |
| 2022-02-03 15:36:57 +0100 | <maerwald> | it is indeed unintuitive |
| 2022-02-03 15:40:22 +0100 | <segfaultfizzbuzz> | maerwald: i am just trying to give haskell an honest try, and for something more substantial than a slow recursive implementation of fib |
| 2022-02-03 15:40:47 +0100 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.3) |
| 2022-02-03 15:40:56 +0100 | <maerwald> | segfaultfizzbuzz: there are alternative approaches to streaming that are more closely tied to representing actual streams (similar to lists) |
| 2022-02-03 15:40:57 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 15:41:05 +0100 | <maerwald> | conduit doesn't represent streams, but stream processors |
| 2022-02-03 15:42:02 +0100 | <segfaultfizzbuzz> | maerwald: alternatives such as? what is a stream processor vs a stream? |
| 2022-02-03 15:42:20 +0100 | <segfaultfizzbuzz> | stream processor can produce and consume multiple streams? |
| 2022-02-03 15:42:48 +0100 | <maerwald> | lists are already streams, basically |
| 2022-02-03 15:42:54 +0100 | <geekosaur> | segfaultfizzbuzz, you're not misusing conduit. you're expecting ghc to read your mind and figure out which Showable you intend to use |
| 2022-02-03 15:43:17 +0100 | <maerwald> | conduit type is about input and output... a list doesn't have that |
| 2022-02-03 15:43:33 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 15:45:05 +0100 | <maerwald> | segfaultfizzbuzz: not sure if my blog post helps you, but I do a recap on conduit there https://hasufell.github.io/posts/2021-10-22-conduit-to-streamly.html |
| 2022-02-03 15:47:23 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-02-03 15:48:03 +0100 | <segfaultfizzbuzz> | so my function of interest is a Transformer |
| 2022-02-03 15:48:42 +0100 | <maerwald> | that would be conduits map |
| 2022-02-03 15:49:34 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:807e:5d29:47f6:b5b3) |
| 2022-02-03 15:50:21 +0100 | adnaahm | (~adnaahm@host-251-net-64-160-119.mobilinkinfinity.net.pk) |
| 2022-02-03 15:50:24 +0100 | shriekingnoise | (~shrieking@201.231.16.156) |
| 2022-02-03 15:53:37 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:807e:5d29:47f6:b5b3) (Ping timeout: 240 seconds) |
| 2022-02-03 15:54:05 +0100 | waleee | (~waleee@2001:9b0:21d:fc00:398f:b003:b90d:acf4) |
| 2022-02-03 15:55:17 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480::41) (Ping timeout: 240 seconds) |
| 2022-02-03 15:58:47 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-02-03 16:01:24 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 16:02:18 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-02-03 16:04:42 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 16:05:13 +0100 | burnsidesLlama | (~burnsides@dhcp168-042.wadham.ox.ac.uk) |
| 2022-02-03 16:07:03 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-02-03 16:07:03 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-02-03 16:07:03 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-02-03 16:08:15 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480:1b88:50f:dae0:9293) |
| 2022-02-03 16:11:29 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-02-03 16:13:17 +0100 | max22- | (~maxime@2a01cb0883359800569e67c9db5ecf35.ipv6.abo.wanadoo.fr) (Ping timeout: 256 seconds) |
| 2022-02-03 16:15:25 +0100 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2022-02-03 16:16:23 +0100 | xff0x | (~xff0x@2001:1a81:53e8:2500:31e6:f5f6:6492:6bc2) (Ping timeout: 250 seconds) |
| 2022-02-03 16:17:08 +0100 | xff0x | (~xff0x@2001:1a81:53e8:2500:a7da:afdc:1a91:3063) |
| 2022-02-03 16:17:47 +0100 | RFV | (~Thunderbi@48.red-83-57-2.dynamicip.rima-tde.net) |
| 2022-02-03 16:18:57 +0100 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 256 seconds) |
| 2022-02-03 16:20:37 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 240 seconds) |
| 2022-02-03 16:21:39 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 16:22:43 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-02-03 16:23:11 +0100 | <kuribas> | > (\(<>) -> <> + 2) 3 |
| 2022-02-03 16:23:13 +0100 | <lambdabot> | <hint>:1:11: error: parse error on input ‘<>’ |
| 2022-02-03 16:23:18 +0100 | <kuribas> | > (\(<>) -> (<>) + 2) 3 |
| 2022-02-03 16:23:19 +0100 | <lambdabot> | 5 |
| 2022-02-03 16:23:44 +0100 | <segfaultfizzbuzz> | what was that |
| 2022-02-03 16:23:59 +0100 | Alex_test_ | Alex_test |
| 2022-02-03 16:24:01 +0100 | <ski> | local binding of operator |
| 2022-02-03 16:24:30 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 16:26:49 +0100 | <kuribas> | to a constant :) |
| 2022-02-03 16:28:26 +0100 | futty14 | (~futty14@c90-143-137-255.bredband.tele2.se) |
| 2022-02-03 16:29:47 +0100 | RFV | (~Thunderbi@48.red-83-57-2.dynamicip.rima-tde.net) (Quit: RFV) |
| 2022-02-03 16:30:24 +0100 | <kuribas> | (\α -> α + 3) 2 |
| 2022-02-03 16:30:26 +0100 | <kuribas> | > (\α -> α + 3) 2 |
| 2022-02-03 16:30:27 +0100 | <lambdabot> | 5 |
| 2022-02-03 16:33:00 +0100 | <kuribas> | from now on I'll use greek symbols for all lambdas :) |
| 2022-02-03 16:33:32 +0100 | Pickchea | (~private@user/pickchea) |
| 2022-02-03 16:34:42 +0100 | <ski> | > (\((<>) :: (forall a. Num a => a)) -> (<>) <> 2) 3 |
| 2022-02-03 16:34:43 +0100 | <lambdabot> | 3 |
| 2022-02-03 16:36:25 +0100 | slac85046 | (~slack1256@191.126.99.75) (Ping timeout: 256 seconds) |
| 2022-02-03 16:36:38 +0100 | <futty14> | Asked a question in the file. I would appriciate it if someone could tell me what is wrong with my code in m2 if we assume that m1 is all correct. replit.com/@futhark14/huff#Main.hs |
| 2022-02-03 16:36:40 +0100 | <kuribas> | :t (\((<>) :: (forall a. Num a => a)) -> (<>) <> 2) 3 |
| 2022-02-03 16:36:41 +0100 | <lambdabot> | Num t => t |
| 2022-02-03 16:37:55 +0100 | <segfaultfizzbuzz> | okay so please forgive the potentially distracting question here, but if i wanted to create a haskell with the rustlike concepts of: (1) no exceptions, only errors/result types and panics (2) affine (or linear) resource management, is there anything fundamental about haskell which prevents these things from happening? |
| 2022-02-03 16:39:00 +0100 | <kuribas> | segfaultfizzbuzz: not adding something to a language is very easy :) |
| 2022-02-03 16:39:14 +0100 | slack1256 | (~slack1256@186.11.100.54) |
| 2022-02-03 16:39:36 +0100 | rusrushal13 | (~rusrushal@2409:4056:e82:6bda:bd0e:9743:fccb:b2a0) (Ping timeout: 256 seconds) |
| 2022-02-03 16:39:36 +0100 | <segfaultfizzbuzz> | i am thinking that at some point there ought to be a haskell++ |
| 2022-02-03 16:39:43 +0100 | <kuribas> | segfaultfizzbuzz: for adding linear resource and exception handling to a language, you can have a look at idris. |
| 2022-02-03 16:39:53 +0100 | <kuribas> | idris is haskell++ |
| 2022-02-03 16:41:11 +0100 | <kuribas> | in some ways at least. |
| 2022-02-03 16:41:33 +0100 | <kuribas> | I just have my doubts about using linear types for resource handling. |
| 2022-02-03 16:41:44 +0100 | <segfaultfizzbuzz> | kuribas: oh? plz explain? |
| 2022-02-03 16:41:56 +0100 | <kuribas> | idris libraries had a bug that leaked the resource. |
| 2022-02-03 16:42:11 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 16:42:12 +0100 | <segfaultfizzbuzz> | but, that's a flaw with the idris compiler then...? |
| 2022-02-03 16:42:26 +0100 | <kuribas> | no, it was a flaw in the library. |
| 2022-02-03 16:42:40 +0100 | whatif | (~user@123.180.40.237) |
| 2022-02-03 16:42:51 +0100 | <segfaultfizzbuzz> | wait, linear types don't stop leaks. leaking memory in rust is safe |
| 2022-02-03 16:43:04 +0100 | <whatif> | https://paste.tomsmeding.com/80ERN8cV why this is alway ambigous? |
| 2022-02-03 16:43:45 +0100 | <whatif> | potential instance exist, but I have `qualified` to import |
| 2022-02-03 16:43:51 +0100 | <whatif> | why this still happend |
| 2022-02-03 16:44:22 +0100 | <kuribas> | whatif: you need to add a type annotation to WST.get ... |
| 2022-02-03 16:45:05 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 16:45:21 +0100 | <lortabac> | whatif: name resolution and type inference are completely separated in Haskell |
| 2022-02-03 16:45:34 +0100 | <lortabac> | here the problem is about the types, not about the names |
| 2022-02-03 16:45:57 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-02-03 16:50:17 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:d9db:d02e:3a80:b20d) |
| 2022-02-03 16:50:35 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 256 seconds) |
| 2022-02-03 16:51:01 +0100 | <ski> | segfaultfizzbuzz : did you already look into Clean (or Mercury) ? |
| 2022-02-03 16:53:57 +0100 | <whatif> | kuribas: I don't get it, what is a type annotation to WST.get? |
| 2022-02-03 16:54:23 +0100 | Inst | (~delicacie@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-02-03 16:54:37 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:d9db:d02e:3a80:b20d) (Ping timeout: 240 seconds) |
| 2022-02-03 16:54:56 +0100 | <whatif> | WST.get has its type signature from WST |
| 2022-02-03 16:55:06 +0100 | <whatif> | why need one? |
| 2022-02-03 16:55:11 +0100 | <ski> | whatif> :t WST.get |
| 2022-02-03 16:56:33 +0100 | <whatif> | import qualified Web.Scotty.Trans as WST |
| 2022-02-03 16:56:37 +0100 | alp | (~alp@user/alp) (Ping timeout: 240 seconds) |
| 2022-02-03 16:56:59 +0100 | ski | doesn't really know Scotty |
| 2022-02-03 16:57:50 +0100 | <kuribas> | whatif: your error type variable is free. |
| 2022-02-03 16:57:52 +0100 | <ski> | anyway, it clearly doesn't know which type of Scotty error that it's supposed to look out for |
| 2022-02-03 16:57:53 +0100 | haskellberryfinn | (~nut@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) |
| 2022-02-03 16:58:05 +0100 | <ski> | you need to pin it down, one way or another |
| 2022-02-03 16:58:07 +0100 | <kuribas> | get :: (ScottyError e, MonadIO m) => RoutePattern -> ActionT e m () -> ScottyT e m () |
| 2022-02-03 16:58:35 +0100 | <ski> | (one way might be to make sure the context determines it. another is to add a type ascription, as kuribas is suggesting, which specifies it) |
| 2022-02-03 17:01:15 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 17:01:21 +0100 | Inst | (~delicacie@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 256 seconds) |
| 2022-02-03 17:04:08 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 17:05:02 +0100 | zmt00 | (~zmt00@user/zmt00) |
| 2022-02-03 17:05:57 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-02-03 17:06:51 +0100 | <whatif> | get "/" (text "hello") :: (ScottyError e, MonadIO m) => RoutePattern -> ActionT e m () -> ScottyT e m () |
| 2022-02-03 17:07:17 +0100 | <whatif> | Couldn't match expected type ‘ScottyT e0 IO ()’ with actual type ‘RoutePattern -> ActionT e1 m0 () -> ScottyT e1 m0 ()’ |
| 2022-02-03 17:07:48 +0100 | <whatif> | what type variable is free? |
| 2022-02-03 17:09:30 +0100 | <kuribas> | whatif: "e" |
| 2022-02-03 17:09:44 +0100 | <whatif> | get "/" (text "hello") :: ScottyT e m () |
| 2022-02-03 17:09:47 +0100 | <kuribas> | whatif: you want a specific type there, not a polymorphic one. |
| 2022-02-03 17:10:00 +0100 | <kuribas> | like "ScottyT () IO ()" |
| 2022-02-03 17:10:25 +0100 | <whatif> | kuribas: and why polymorphic is not ok? |
| 2022-02-03 17:11:53 +0100 | <ski> | because it doesn't know which `e' to actually pick for you |
| 2022-02-03 17:12:00 +0100 | soxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) |
| 2022-02-03 17:12:19 +0100 | <ski> | (and the program may behave in different ways, depending on which is picked) |
| 2022-02-03 17:12:37 +0100 | affine | (~hugh@2a02:1206:45a3:6340:da01:c0c6:8610:80f6) |
| 2022-02-03 17:12:52 +0100 | <segfaultfizzbuzz> | ski: no i havent looked into clean/mercury |
| 2022-02-03 17:13:06 +0100 | <affine> | given -O0 does this piece of code need a force or seq? |
| 2022-02-03 17:13:08 +0100 | <affine> | solve = uncurry max . foldl' (\(r1,r2) m -> (max r1 (r2 + m), r1)) (0,0) |
| 2022-02-03 17:13:23 +0100 | <ski> | to actually use a polymorphic value, you will have to instantiate/specialize/monomorphize it, picking some particular type(s) for the universally quantified type varibles |
| 2022-02-03 17:13:25 +0100 | <affine> | given that (r1,r2) :: (Int,INt) |
| 2022-02-03 17:13:53 +0100 | <ski> | commonly, the context around the use will determine this for you (or defer the decision to the caller of the current code, &c.) |
| 2022-02-03 17:14:11 +0100 | <merijn> | affine: Define "need"? :p |
| 2022-02-03 17:14:31 +0100 | <ski> | but the context doesn't give enough clues, and so you may need to give an explicit type ascription or signature |
| 2022-02-03 17:14:33 +0100 | <affine> | merijn a friend told me that this causes a space leak but i can't see why |
| 2022-02-03 17:14:36 +0100 | <whatif> | get "/" (text "hello") :: ScottyT () IO () |
| 2022-02-03 17:14:40 +0100 | <merijn> | affine: Ah, I can :) |
| 2022-02-03 17:14:49 +0100 | <whatif> | No instance for (ScottyError ()) arising from a use of ‘get’ |
| 2022-02-03 17:14:55 +0100 | <merijn> | affine: foldl' evaluates the accumulator to WHNF |
| 2022-02-03 17:15:07 +0100 | <merijn> | affine: The WHNF of a tuple is: tuple constructor with 2 thunks :) |
| 2022-02-03 17:15:14 +0100 | <ski> | segfaultfizzbuzz : both of them have uniqueness, for handling update-in-place of state, in a pure declarative fashion. Clean also has laziness |
| 2022-02-03 17:15:22 +0100 | <merijn> | affine: So foldl' isn't forcing the contents of the tuple (i.e. your +) |
| 2022-02-03 17:15:27 +0100 | <affine> | oh really |
| 2022-02-03 17:15:32 +0100 | <whatif> | why this `get` is so difficult to use |
| 2022-02-03 17:15:44 +0100 | <affine> | weak head normal form of k = (5+7,2+4) is just (5+7,2+4) |
| 2022-02-03 17:15:45 +0100 | <ski> | whatif : maybe look at what instances of `ScottyError' are available, if you're not sure which type to choose |
| 2022-02-03 17:16:12 +0100 | <merijn> | affine: Personally I find seq hard to use right, I'd recommend going with strictness on the lambda: i.e. "(\(!r1,!r2) m -> (max r1 (r2+ m), r1))" |
| 2022-02-03 17:16:22 +0100 | <affine> | so this does actually cause a space leak? |
| 2022-02-03 17:16:25 +0100 | <merijn> | affine: Which probably requires -XBangPatterns |
| 2022-02-03 17:16:30 +0100 | <merijn> | affine: Potentially |
| 2022-02-03 17:16:43 +0100 | <merijn> | affine: It depends how much gets inlined, if the strictness analyzer sees it, etc. |
| 2022-02-03 17:16:48 +0100 | <affine> | this is using -O0 |
| 2022-02-03 17:16:56 +0100 | <merijn> | affine: The probably, yes |
| 2022-02-03 17:17:05 +0100 | <affine> | what about levity polymorphism? |
| 2022-02-03 17:17:14 +0100 | ProfSimm | (~ProfSimm@87.227.196.109) (Remote host closed the connection) |
| 2022-02-03 17:17:16 +0100 | <affine> | unliftedtypes |
| 2022-02-03 17:17:26 +0100 | <merijn> | affine: WHNF is basically "evaluate until the first leftmost, outermost thing is a constructor (i.e. the tuple thing)" |
| 2022-02-03 17:17:53 +0100 | <merijn> | affine: That'd work, but I don't think foldl' works with that directly, so it quickly becomes messy/tricky |
| 2022-02-03 17:18:08 +0100 | <merijn> | affine: BangPatterns on the other hand is fairly straightforward :p |
| 2022-02-03 17:18:10 +0100 | max22- | (~maxime@2a01cb08833598004d3ba66ae954fefa.ipv6.abo.wanadoo.fr) |
| 2022-02-03 17:18:27 +0100 | <affine> | i thought bang patterns were just fully evaluated thunks |
| 2022-02-03 17:18:30 +0100 | <affine> | but they still have a pointer |
| 2022-02-03 17:18:37 +0100 | <affine> | so strict but still with the pointer? |
| 2022-02-03 17:18:57 +0100 | <ski> | ? |
| 2022-02-03 17:19:24 +0100 | <affine> | i'm confused about why use bang patterns over unlifted types? |
| 2022-02-03 17:19:30 +0100 | <affine> | other than awkwardness of programming |
| 2022-02-03 17:19:47 +0100 | <segfaultfizzbuzz> | ski: hm, clean jettisons monads? |
| 2022-02-03 17:20:36 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 17:20:40 +0100 | <ski> | (i dunno what you mean, by those last sentences) |
| 2022-02-03 17:20:58 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-02-03 17:23:17 +0100 | <merijn> | affine: Bang pattern forces to WHNF |
| 2022-02-03 17:23:39 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 17:23:40 +0100 | <affine> | hmm so it is weaker than unlifted types which is essentially a deep force? |
| 2022-02-03 17:23:48 +0100 | <affine> | as wHNF is not the same as lacking bottom? |
| 2022-02-03 17:23:55 +0100 | <merijn> | affine: So where foldl' forces the tuple to WHNF, "(\(!r1, !r2) m -> ..)" forces r1 and r2 to WHNF whenever the tuple is forced to WHNF |
| 2022-02-03 17:24:47 +0100 | <merijn> | affine: unlifted types don't play nice with polymorphic code/functions |
| 2022-02-03 17:25:05 +0100 | <merijn> | affine: Supporting parametric polymorphism is one of the main reasons for lifting things :p |
| 2022-02-03 17:25:06 +0100 | neverfindme | (~hayden@158.123.160.43) |
| 2022-02-03 17:25:17 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 240 seconds) |
| 2022-02-03 17:25:23 +0100 | <affine> | is that an implmentation detail? |
| 2022-02-03 17:25:33 +0100 | <affine> | could functions generalise over levity in future given a lot of compiler work?? |
| 2022-02-03 17:25:42 +0100 | <affine> | or are unlifted types more a special case if you really really need it |
| 2022-02-03 17:26:10 +0100 | <merijn> | affine: Ok, so there are, effectively, two ways/strategies for handling polymorphic code |
| 2022-02-03 17:26:44 +0100 | <merijn> | datatypes can have different sizes so you can: 1) generate separate code for every possible datatype or 2) force all datatypes to have the same type (for purposes of generic code) |
| 2022-02-03 17:27:03 +0100 | <merijn> | The first option optimises better, but bloats code size and can be tricky if you don't know all types ahead of time |
| 2022-02-03 17:27:28 +0100 | <merijn> | The second option is generally easier and compacter (but with reduced optimisation opportunity) |
| 2022-02-03 17:27:33 +0100 | <affine> | is this static vs dynamic dispatch? |
| 2022-02-03 17:27:57 +0100 | <merijn> | affine: The easiest way of making all data the same size is to replace every datatype with a pointer indirection to the data (aka boxing) |
| 2022-02-03 17:28:40 +0100 | <merijn> | (GHC has, like, 2 axes boxed/unboxed and lifted/unlifted I think? I'm a bit muddy on the details) |
| 2022-02-03 17:29:23 +0100 | <merijn> | affine: Anyway, the result is that you can't magically throw unlifted/unboxed code into any and all functions |
| 2022-02-03 17:29:37 +0100 | <affine> | ahh yes of course that makes sense |
| 2022-02-03 17:29:47 +0100 | <affine> | you can just pass along a pointer to a function which is the boxed thing |
| 2022-02-03 17:30:28 +0100 | <affine> | i suppose i'm imagining knowing the type at compiletime |
| 2022-02-03 17:30:30 +0100 | <merijn> | affine: bangpatterns/seq don't affect the representation (just evaluation) so it plays nicer in most cases than unlifted does |
| 2022-02-03 17:30:31 +0100 | <affine> | rather than say existential types |
| 2022-02-03 17:30:32 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-02-03 17:30:49 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2022-02-03 17:30:52 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-02-03 17:31:01 +0100 | ardell | (~ardell@user/ardell) (Quit: Konversation terminated!) |
| 2022-02-03 17:31:19 +0100 | <Andrew> | Since Haskell is a lazy language, I wonder if there's a way to represent radicals that's *actually accurate*. For example, is there a form of `pi' that if displayed on its own would be calculated to infinity, but would work with a function that takes an precision value and spits that precision out? I mean a function that works kind-of like `take', but works on those types? |
| 2022-02-03 17:31:49 +0100 | <affine> | why not the continued fraction representation? |
| 2022-02-03 17:32:01 +0100 | <affine> | that represents sqrt(2) perfectly |
| 2022-02-03 17:33:09 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:5722:cfcd:da3c:1af2) (Quit: WeeChat 2.8) |
| 2022-02-03 17:33:19 +0100 | <Andrew> | Hmm, nice :) |
| 2022-02-03 17:33:24 +0100 | <Andrew> | I just wonder why that isn't the default |
| 2022-02-03 17:33:30 +0100 | neverfindme | (~hayden@158.123.160.43) (Quit: Leaving) |
| 2022-02-03 17:33:58 +0100 | <merijn> | because that kinda thing is slow :p |
| 2022-02-03 17:34:07 +0100 | <geekosaur> | it's slower than machine / IEEE floats |
| 2022-02-03 17:34:39 +0100 | <Andrew> | But that's more "correct" :\ |
| 2022-02-03 17:34:51 +0100 | <ski> | Andrew : see `CReal' ? |
| 2022-02-03 17:35:06 +0100 | <kuribas> | shouldn't Data.Map be a Profunctor? |
| 2022-02-03 17:35:12 +0100 | <segfaultfizzbuzz> | Andrew: there's a closed form method of calculating any specified digit of pi |
| 2022-02-03 17:35:15 +0100 | <ski> | (i dunno if anyone has made an implementation of algebraic numbers, though, hmm ..) |
| 2022-02-03 17:35:30 +0100 | <Andrew> | Sounds like it, thanks :) |
| 2022-02-03 17:35:43 +0100 | <Andrew> | I suddenly got this idea for no apparant reason while configuring a Postfix server |
| 2022-02-03 17:35:46 +0100 | <segfaultfizzbuzz> | so you don't really need laziness, i don't think |
| 2022-02-03 17:35:52 +0100 | <ski> | > showCReal 50 pi |
| 2022-02-03 17:35:53 +0100 | <lambdabot> | "3.14159265358979323846264338327950288419716939937511" |
| 2022-02-03 17:35:59 +0100 | <ski> | > showCReal 100 pi |
| 2022-02-03 17:36:00 +0100 | <lambdabot> | "3.1415926535897932384626433832795028841971693993751058209749445923078164062... |
| 2022-02-03 17:36:01 +0100 | <merijn> | kuribas: No |
| 2022-02-03 17:36:11 +0100 | <merijn> | kuribas: Same reason Set isn't a Functor |
| 2022-02-03 17:36:16 +0100 | <Andrew> | segfaultfizzbuzz: Well, I like how laziness works in Haskell, seems quite elegant :) |
| 2022-02-03 17:36:39 +0100 | <segfaultfizzbuzz> | also note that there is absolutely no circumstance where more than 100 digits of pi would actually be necessary, except for ivory tower number theory |
| 2022-02-03 17:37:32 +0100 | <polyphem> | Andrew: standard pi has 16 siginificant digits, you have to provide your other terms with even more "precision" to be more correct , does that make sense ? |
| 2022-02-03 17:38:06 +0100 | <Andrew> | Makes sense |
| 2022-02-03 17:38:32 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-02-03 17:38:46 +0100 | califax | (~califax@user/califx) |
| 2022-02-03 17:38:58 +0100 | <polyphem> | more precise in one factor , doesnt make the whole computation more precise , if the other factors are less precise |
| 2022-02-03 17:39:19 +0100 | <segfaultfizzbuzz> | and in any circumstance where pi is actually useful to compute things it needs to be pre-calculated |
| 2022-02-03 17:39:36 +0100 | <segfaultfizzbuzz> | sounds like the opposite of where laziness would be useful |
| 2022-02-03 17:40:13 +0100 | <ski> | i suppose with laziness, precision can be demand-driven |
| 2022-02-03 17:40:37 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2022-02-03 17:40:42 +0100 | deadmarshal | (~deadmarsh@95.38.114.110) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-02-03 17:40:46 +0100 | ski | idly ponders stability of numerical algorithms |
| 2022-02-03 17:41:01 +0100 | <Andrew> | ski: That's my point |
| 2022-02-03 17:41:15 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2022-02-03 17:41:49 +0100 | sharky2 | (~bc8147f2@83.167.180.121) |
| 2022-02-03 17:41:50 +0100 | deadmarshal | (~deadmarsh@95.38.119.14) |
| 2022-02-03 17:42:13 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 17:42:18 +0100 | <segfaultfizzbuzz> | i mean, do you need deep sub-planck-scale precision? |
| 2022-02-03 17:42:30 +0100 | <carter> | if only that was useful :) |
| 2022-02-03 17:42:43 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-02-03 17:42:54 +0100 | azimut_ | (~azimut@gateway/tor-sasl/azimut) |
| 2022-02-03 17:43:15 +0100 | <segfaultfizzbuzz> | lol, quad precision smallest value looks like 2^-16382 |
| 2022-02-03 17:43:16 +0100 | int-e | drops a feather on ski in hopes of disturbing their precarious balance. |
| 2022-02-03 17:43:36 +0100 | <segfaultfizzbuzz> | lol even google reports 2^-16382 as being precisely equal to ezro |
| 2022-02-03 17:43:37 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 256 seconds) |
| 2022-02-03 17:43:48 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 276 seconds) |
| 2022-02-03 17:44:44 +0100 | adanwan_ | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-02-03 17:45:03 +0100 | <segfaultfizzbuzz> | planck length is 1.6 x 10^-35 meters which is 2^-115.5 |
| 2022-02-03 17:45:03 +0100 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-02-03 17:45:49 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 17:46:07 +0100 | <sharky2> | hi. I'm using Network.HTTP.Conduit and Network.Socket.Internal, but this doesn't work as the page I'm trying to download requires cookies. can those packages accept cookies, and if not, what package do you recommend that I use instead? |
| 2022-02-03 17:46:37 +0100 | ski | slides away from the point repeller, ends up into a meta-stable chaotic attractor |
| 2022-02-03 17:46:45 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-02-03 17:46:45 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-02-03 17:46:45 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-02-03 17:46:52 +0100 | <Andrew> | But it is not precisely zero. I know I focus too much on correctness, but whatever :) |
| 2022-02-03 17:47:01 +0100 | Andrew | closes his IRC to focus on setting up Postfix |
| 2022-02-03 17:47:09 +0100 | <sharky2> | big picture: I am writing a web scraper and I wanted to use google's I'm feeling lucky to get to the page of interest, since website I'm scraping has no searching capability. but I'm having trouble using google's I'm feeling lucky page, because it requires cookies |
| 2022-02-03 17:48:39 +0100 | axeman | (~quassel@2a02:8109:a3c0:b10:7b68:5346:f621:6fdc) |
| 2022-02-03 17:49:17 +0100 | whatif | (~user@123.180.40.237) (Ping timeout: 256 seconds) |
| 2022-02-03 17:49:29 +0100 | <segfaultfizzbuzz> | Andrew: precision on the scale you are talking about is likely a human invention rather than a reality of nature. i think we can create a compelling case that things like real numbers, actual spheres and circles, etc don't exist |
| 2022-02-03 17:49:51 +0100 | Pickchea | (~private@user/pickchea) (Ping timeout: 256 seconds) |
| 2022-02-03 17:50:12 +0100 | Andrew | swims in mathematical purity, jumps out into humanity, and sighs |
| 2022-02-03 17:50:39 +0100 | deadmarshal | (~deadmarsh@95.38.119.14) (Ping timeout: 256 seconds) |
| 2022-02-03 17:50:58 +0100 | <segfaultfizzbuzz> | i've heard that constructivism is becoming fashionable in mathematics but don't know the details there |
| 2022-02-03 17:51:00 +0100 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-02-03 17:52:45 +0100 | <segfaultfizzbuzz> | anyway so the actual practical upshot of what i was saying was: you could populate quad float precision once with the values of pi as a compile time constant and be good even for calculations which need to consider effects at the planck scale |
| 2022-02-03 17:54:16 +0100 | <segfaultfizzbuzz> | excuse me, way beyond the planck scale, whatever that means ;-) |
| 2022-02-03 17:55:09 +0100 | ski | . o O ( cancellation ) |
| 2022-02-03 17:56:13 +0100 | <segfaultfizzbuzz> | ski: what? |
| 2022-02-03 17:56:22 +0100 | mbuf | (~Shakthi@122.162.66.95) (Quit: Leaving) |
| 2022-02-03 17:57:20 +0100 | <ski> | if you have two quads which are very nearly equal, and you compute the difference, then that will only have a few significant figures |
| 2022-02-03 17:57:48 +0100 | <ski> | https://en.wikipedia.org/wiki/Catastrophic_cancellation |
| 2022-02-03 17:58:41 +0100 | meltedbrain_y2k | (~tekserf@47.61.115.91) (Read error: Connection reset by peer) |
| 2022-02-03 17:58:56 +0100 | <segfaultfizzbuzz> | okay? how is that relevant for having pi to quad precision |
| 2022-02-03 17:59:15 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2022-02-03 17:59:34 +0100 | <ski> | having just quad precision of some inputs might not be enough to get reasonable precision for the results |
| 2022-02-03 18:01:57 +0100 | <segfaultfizzbuzz> | the most precise physical measurement ever made was 14 significant digits |
| 2022-02-03 18:02:00 +0100 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-02-03 18:02:00 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2022-02-03 18:02:00 +0100 | finn_elija | FinnElija |
| 2022-02-03 18:02:17 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 18:02:32 +0100 | eayavas | (~eayavas@78.168.199.216) |
| 2022-02-03 18:02:37 +0100 | <monochrom> | Intermediate computations can benefit from more guard bits. |
| 2022-02-03 18:03:04 +0100 | <segfaultfizzbuzz> | monochrom: understood, but not eight hundred billion trillion guard bits |
| 2022-02-03 18:04:12 +0100 | <monochrom> | Then you should do numerical analysis properly to determine how many guard bits (or even better a better algorithm that doesn't need as many). As opposed to armchair opining. |
| 2022-02-03 18:04:39 +0100 | <segfaultfizzbuzz> | are there real world situations where you need to go beyond quad float precision? |
| 2022-02-03 18:04:50 +0100 | emf | (~emf@2620:10d:c090:400::5:3e0a) |
| 2022-02-03 18:04:53 +0100 | <Cale> | Also, it's possible to make use of real numbers in ways that don't correspond to physical measurements, though perhaps that's just weird. |
| 2022-02-03 18:05:08 +0100 | <monochrom> | And sometimes in lieu of a better algorithm, throwing guard bits at the problem is an interim solution. |
| 2022-02-03 18:05:09 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 18:05:23 +0100 | <segfaultfizzbuzz> | Cale: yes in genetics small probabilities, like 10^-100 can show up |
| 2022-02-03 18:05:40 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-02-03 18:05:57 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 240 seconds) |
| 2022-02-03 18:06:40 +0100 | <monochrom> | Observe how we also have 64-cores 2TB RAM 3PB SSD 4K 60" quad-head desktops for merely web devs who "clearly don't need" any of it. |
| 2022-02-03 18:06:51 +0100 | lbseale | (~ep1ctetus@user/ep1ctetus) |
| 2022-02-03 18:06:51 +0100 | <segfaultfizzbuzz> | haha |
| 2022-02-03 18:07:25 +0100 | <monochrom> | Well, they need it because they don't have better algorithms or better page layouts. |
| 2022-02-03 18:08:28 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-02-03 18:11:09 +0100 | mcgroin | (~mcgroin@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 256 seconds) |
| 2022-02-03 18:11:27 +0100 | <Cale> | monochrom: Hey, when part of your toolchain is a Haskell to Javascript compiler, you need all the performance you can get just to not spend all day waiting for builds to finish :D (actually, we mostly sidestep the builds now by running our web applications in ghci while developing and having them control the contents of the DOM via a websocket) |
| 2022-02-03 18:11:33 +0100 | alp | (~alp@user/alp) |
| 2022-02-03 18:12:07 +0100 | <monochrom> | But I was referring to those who write in javascript directly. |
| 2022-02-03 18:12:45 +0100 | <c_wraith> | I wish jsaddle actually worked in firefox |
| 2022-02-03 18:12:53 +0100 | <Cale> | c_wraith: me too |
| 2022-02-03 18:13:02 +0100 | <c_wraith> | or with firefox, as the preposition may be |
| 2022-02-03 18:13:08 +0100 | <maerwald> | why target javascript? |
| 2022-02-03 18:13:28 +0100 | <Cale> | maerwald: as opposed to webassembly? |
| 2022-02-03 18:13:44 +0100 | <monochrom> | "it's an easy target" :) |
| 2022-02-03 18:13:45 +0100 | <Cale> | It's basically just that the wasm compilers are not quite there yet. |
| 2022-02-03 18:14:04 +0100 | <Cale> | haha |
| 2022-02-03 18:14:38 +0100 | <justsomeguy> | I have this expression one = [x^y | x <- [1..5], y <- [2, undefined]]. Evaluating it results in an exception once it tries to create the second element of the resulting list [(1^2),(2^undefined)***exception. I want to write a test using Hspec to prove that it throws this particular exception. Can you point me in the right direction to start solving this? I don't know where execption handling |
| 2022-02-03 18:14:40 +0100 | <Cale> | c_wraith: I also wish jsaddle were unnecessary on desktop and mobile again, but that's probably a wish that's not coming true any time soon. |
| 2022-02-03 18:14:41 +0100 | <maerwald> | I was rather questioning that these days everything is run via electron and other bloat... even stuff that has nothing to do with websites |
| 2022-02-03 18:14:41 +0100 | <justsomeguy> | stuff lives in Haskell. |
| 2022-02-03 18:15:35 +0100 | <geekosaur> | Control.Exception but I would assume Hspec has its own ways to prove something throws a given exception |
| 2022-02-03 18:15:51 +0100 | <segfaultfizzbuzz> | ski: sorry, is there a real situation where i am subtracting a couple of numbers and need beyond a quad precision representation of pi to calculate something (even an error in the subtraction)...? |
| 2022-02-03 18:16:01 +0100 | <Cale> | justsomeguy: Exceptions thrown by evaluation of pure code (as opposed to by execution of IO) can also be quite tricky to catch in general, since you have to make sure that evaluation occurs inside the catch. |
| 2022-02-03 18:16:30 +0100 | <c_wraith> | in this particular case, you also need to ensure the exception doesn't happen someplace else. |
| 2022-02-03 18:16:34 +0100 | <segfaultfizzbuzz> | Cale: ya'll need to adopt rust's error handling techniques, except to be more opinionated about it |
| 2022-02-03 18:16:53 +0100 | <c_wraith> | so you can't just evaluate `one !! 1` and call yourself done. |
| 2022-02-03 18:17:06 +0100 | <c_wraith> | you need to pattern match much more carefully |
| 2022-02-03 18:17:17 +0100 | <justsomeguy> | Hspec has shouldThrow ( http://hspec.github.io/expectations.html ). I get some type errors when I try to use it. I'll write an example anlink to it. |
| 2022-02-03 18:17:23 +0100 | <monochrom> | In this case, "seq one ()" doesn't throw. |
| 2022-02-03 18:17:26 +0100 | meltedbrain_y2k | (~tekserf@47.61.115.91) |
| 2022-02-03 18:17:30 +0100 | <Cale> | segfaultfizzbuzz: Well, this is a natural consequence of having lazy evaluation. Really, exceptions thrown from evalation probably ought not to be caught, but it is sometimes nice to have as a last resord. |
| 2022-02-03 18:17:36 +0100 | <Cale> | resort* |
| 2022-02-03 18:17:46 +0100 | <monochrom> | You will need many ingredients. |
| 2022-02-03 18:18:12 +0100 | <monochrom> | One ingredient is Control.DeepSeq for full evaluation. |
| 2022-02-03 18:18:37 +0100 | <c_wraith> | you don't want DeepSeq here |
| 2022-02-03 18:18:55 +0100 | <c_wraith> | you want to be sure the bottom is in exactly the right place, not just somewhere |
| 2022-02-03 18:19:05 +0100 | CiaoSen | (~Jura@p200300c95737a2002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-02-03 18:19:06 +0100 | <monochrom> | Another ingredient is Control.Exception's evaluate to go back to IO to make sure evaluation is triggered, and right at the moment you want. |
| 2022-02-03 18:19:47 +0100 | <monochrom> | And then undefined is a call to error, and you find out which exception it corresponds to. |
| 2022-02-03 18:20:07 +0100 | <c_wraith> | looks like hspec provides anyErrorCall to handle that part |
| 2022-02-03 18:20:21 +0100 | <Cale> | justsomeguy: You'll probably want to use Control.Exception.evaluate |
| 2022-02-03 18:21:35 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 18:22:24 +0100 | <Cale> | justsomeguy: So as to turn your expression into an IO action which evaluates the expression and causes the exception to occur. Note however, that since your expression is a list, it can technically be evaluated without causing the exception, so you may wish to also use Control.DeepSeq.rnf on it to insist on evaluating everything deeply. |
| 2022-02-03 18:23:06 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 26.3)) |
| 2022-02-03 18:25:19 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 18:25:52 +0100 | <Cale> | Control.Exception.evaluate will only evaluate something as far as determining what its outermost data constructor is, so in your case, it will probably succeed in getting the thing as far as (1^2) : _ |
| 2022-02-03 18:26:12 +0100 | <monochrom> | _ : _ |
| 2022-02-03 18:26:24 +0100 | doyougnu | (~doyougnu@cpe-67-249-83-190.twcny.res.rr.com) (Ping timeout: 250 seconds) |
| 2022-02-03 18:26:46 +0100 | <monochrom> | % evaluate (undefined : undefined) >> putStrLn "I'm OK" |
| 2022-02-03 18:26:46 +0100 | <yahb> | monochrom: I'm OK |
| 2022-02-03 18:26:56 +0100 | <sharky2> | can newer versions of ghc/ghci report compile-time warnings for mismatched printf format string and supplied arguments? |
| 2022-02-03 18:27:13 +0100 | <Cale> | indeed |
| 2022-02-03 18:27:22 +0100 | <Cale> | sharky2: no |
| 2022-02-03 18:27:46 +0100 | <Cale> | sharky2: The printf format string is not generally known at compile time |
| 2022-02-03 18:28:05 +0100 | <Cale> | sharky2: So that's not technically possible with the approach that Text.Printf takes to it |
| 2022-02-03 18:28:12 +0100 | <sharky2> | Cale, what do you mean? it is usually used with string literal, which is known at compile time |
| 2022-02-03 18:28:24 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-02-03 18:28:42 +0100 | fef | (~thedawn@user/thedawn) |
| 2022-02-03 18:28:53 +0100 | <monochrom> | "can?" yes, "will?" very improbable. |
| 2022-02-03 18:28:57 +0100 | <Cale> | Yeah, but Text.Printf.printf isn't a TH macro or something which will consume its string at compile time. It's just an ordinary function. |
| 2022-02-03 18:29:10 +0100 | Akiva | (~Akiva@user/Akiva) |
| 2022-02-03 18:29:26 +0100 | <Cale> | It is however possible to take a different approach to writing a printf library which will typecheck everything |
| 2022-02-03 18:29:40 +0100 | <sharky2> | I am talking about implementing this at ghc/ghci level, not at printf haskell code level. this can certainly be done, just like it is done in many C and C++ compilers |
| 2022-02-03 18:29:41 +0100 | <Cale> | It's just not so easy to do that *and* use string literals |
| 2022-02-03 18:29:47 +0100 | <geekosaur> | https://hackage.haskell.org/package/typelits-printf |
| 2022-02-03 18:30:39 +0100 | <geekosaur> | and if anything, printf id discouraged, so I highly doubt any special support for it will end up in ghc |
| 2022-02-03 18:30:48 +0100 | <geekosaur> | *is discouraged |
| 2022-02-03 18:31:12 +0100 | <geekosaur> | it basiclaly exists to be a demonstration of how you can abuse typeclasses to make varargs functions |
| 2022-02-03 18:31:18 +0100 | deadmarshal | (~deadmarsh@95.38.119.14) |
| 2022-02-03 18:31:19 +0100 | tavares | (~tavares@user/tavares) |
| 2022-02-03 18:31:24 +0100 | <c_wraith> | typelits-printf is a bit old. more recent versions of GHC added a type family that should massively speed up what it does |
| 2022-02-03 18:31:28 +0100 | <Cale> | https://hackage.haskell.org/package/category-printf -- I would prefer this to Text.Printf, however, in practice, I never use this library, it is a joke. |
| 2022-02-03 18:31:32 +0100 | <dminuoso> | geekosaur: What is your preferred method of doing say `printf "%0dc" (c :: Word8)`? |
| 2022-02-03 18:31:44 +0100 | <dminuoso> | Uh sorry. "%03o" |
| 2022-02-03 18:31:48 +0100 | fef | (~thedawn@user/thedawn) (Read error: Connection reset by peer) |
| 2022-02-03 18:31:58 +0100 | coot | (~coot@213.134.190.95) (Remote host closed the connection) |
| 2022-02-03 18:32:05 +0100 | <dminuoso> | All the alternatives appear less pleasing. |
| 2022-02-03 18:32:21 +0100 | nschoe | (~quassel@178.251.84.79) (Ping timeout: 256 seconds) |
| 2022-02-03 18:32:24 +0100 | <sharky2> | well Text.Printf is part of base, and its main disadvantage could be fixed by making special checks in the ghc/ghci compiler. |
| 2022-02-03 18:32:26 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-02-03 18:33:01 +0100 | Jing | (~hedgehog@240e:390:7c53:a7e1:7da5:59e:42b2:ced5) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-02-03 18:33:28 +0100 | <sharky2> | if making printf more safe isn't a concern, why even have it in base |
| 2022-02-03 18:33:37 +0100 | <justsomeguy> | Alright, now I have a place to start looking :^). I'll peruse the hackage docs Control.Exception, deepseq's Control.DeepSeq, and hspec's Test.Hspec for now. |
| 2022-02-03 18:33:43 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 256 seconds) |
| 2022-02-03 18:34:15 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) |
| 2022-02-03 18:35:11 +0100 | <Cale> | sharky2: It's basically in base only because it made its way into base quite early on when nobody was thinking too much about package structure. I think it predates cabal even. |
| 2022-02-03 18:35:20 +0100 | <EvanR> | printf is good for quick and dirty reports |
| 2022-02-03 18:35:30 +0100 | <EvanR> | more elaborate pretty printers exist |
| 2022-02-03 18:35:34 +0100 | <Cale> | We probably can and should split it into its own package by now, as it's not actually used all that much. |
| 2022-02-03 18:35:44 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-02-03 18:35:55 +0100 | <EvanR> | speak for yourself xD |
| 2022-02-03 18:36:12 +0100 | <Cale> | The only question is: would that simplification of base actually be worth the resulting churn? |
| 2022-02-03 18:36:34 +0100 | <EvanR> | making prelude and base less useful than it already is doesn't sound good |
| 2022-02-03 18:36:49 +0100 | <sharky2> | I like using printf, alternatives tend to be clumsy and verbose. I also know flags by heart. it is just a bit frustrating and ironic that it is in a way safer to use printf in C than in haskell |
| 2022-02-03 18:37:24 +0100 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-02-03 18:37:33 +0100 | <affine> | how is it safer to use printf in c than haskell? |
| 2022-02-03 18:37:40 +0100 | <EvanR> | what you're asking for is a special compiler feature for 1 ad-hoc function in some module |
| 2022-02-03 18:37:55 +0100 | <EvanR> | that's a can of worms |
| 2022-02-03 18:38:10 +0100 | <Cale> | affine: The C compiler checks that your format string matches the arguments provided, and does not permit non-literal strings. |
| 2022-02-03 18:38:32 +0100 | <affine> | huh |
| 2022-02-03 18:38:34 +0100 | <affine> | thanks |
| 2022-02-03 18:38:48 +0100 | <Cale> | Yeah, it's one thing when that function is the way that 99% of all printing to the terminal is done in the language. Doing it for Text.Printf.printf would be insane though. |
| 2022-02-03 18:38:56 +0100 | <affine> | could printf in Haskell become n+k patterns? |
| 2022-02-03 18:39:04 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) (Remote host closed the connection) |
| 2022-02-03 18:39:04 +0100 | <affine> | a cool feature but eventually deprecated |
| 2022-02-03 18:39:17 +0100 | <EvanR> | I daresay the haskell "experiment" philosophy is to not to 1 off ad-hoc solutions to anything and only solve problems in some astounding generic way, otherwise don't bother |
| 2022-02-03 18:39:18 +0100 | <affine> | as in type checked printf |
| 2022-02-03 18:39:20 +0100 | <sharky2> | affine as Cale said, safer because some C compilers make special checks if the format string is string literal. obviously, at a language level, it is less safe to use printf in C than in haskell. |
| 2022-02-03 18:39:37 +0100 | <dminuoso> | But honestly, the lack of a printf makes certain things really poor to express in Haskell. |
| 2022-02-03 18:39:46 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2022-02-03 18:39:56 +0100 | <affine> | could you do this with template haskell? |
| 2022-02-03 18:39:58 +0100 | <dminuoso> | `printf "%03o" c` likely has no eloquent of performant equivalent. |
| 2022-02-03 18:40:05 +0100 | <Cale> | sharky2: Yeah, it's worth noting that when you mess up the arguments in Haskell, you don't end up reading memory you're not supposed to ;) |
| 2022-02-03 18:40:10 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-02-03 18:40:33 +0100 | <EvanR> | I dunno about printf being "performant" |
| 2022-02-03 18:40:46 +0100 | <EvanR> | convenient yes |
| 2022-02-03 18:40:59 +0100 | <Cale> | dminuoso: I'd probably use showOct and some padding function. |
| 2022-02-03 18:41:10 +0100 | <geekosaur> | ^ |
| 2022-02-03 18:42:12 +0100 | <geekosaur> | or showIntAtBase for an older ghc |
| 2022-02-03 18:42:33 +0100 | <EvanR> | it's not exactly "eloquent" for reasons sharky2 is saying |
| 2022-02-03 18:42:48 +0100 | <sharky2> | Cale btw I'm pretty sure you can use strings known at compile time in C's printf |
| 2022-02-03 18:42:55 +0100 | <dminuoso> | showIntAtBase is available on base-4.16.0.0 |
| 2022-02-03 18:43:01 +0100 | <sharky2> | Cale btw I'm pretty sure you can use strings that are NOT known at compile time in C's printf |
| 2022-02-03 18:43:11 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 18:43:14 +0100 | <EvanR> | you really should not though |
| 2022-02-03 18:43:15 +0100 | <dminuoso> | The thing is, there's just no pretty way to write a left pad function in Haskell. |
| 2022-02-03 18:43:26 +0100 | <affine> | how could GHC benefit from AVX512 support? I think AVX-512 has vectorised branching |
| 2022-02-03 18:43:32 +0100 | <dminuoso> | Which brings us all the way to the evil of `type String = [Char]` |
| 2022-02-03 18:43:35 +0100 | <Cale> | sharky2: You can, if you turn off the corresponding errors, but it is extremely unsafe to use with strings that might be affected by user input |
| 2022-02-03 18:43:35 +0100 | <affine> | even if no one has AVX512 |
| 2022-02-03 18:43:50 +0100 | <sharky2> | C language has no way of enforcing that a function only takes string literal. at best it might be a compile warning |
| 2022-02-03 18:43:52 +0100 | <dminuoso> | affine: There's little-to-no support for vectorization in GHC. |
| 2022-02-03 18:43:59 +0100 | <affine> | how come? |
| 2022-02-03 18:44:13 +0100 | <dminuoso> | Because only few people spend research on it |
| 2022-02-03 18:44:29 +0100 | <dminuoso> | Essentially you have to teach GHC how to use vectorized primops |
| 2022-02-03 18:44:33 +0100 | <dminuoso> | And when |
| 2022-02-03 18:45:03 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-02-03 18:45:12 +0100 | <Cale> | Yeah, there is some vectorization already iirc, but it's little more than primitives. Actually taking advantage of it is another thing. |
| 2022-02-03 18:45:14 +0100 | shapr` | (~user@pool-173-73-44-186.washdc.fios.verizon.net) |
| 2022-02-03 18:45:22 +0100 | <EvanR> | are we talking about vectorized branching to help with left padding a short string |
| 2022-02-03 18:45:29 +0100 | <affine> | no |
| 2022-02-03 18:45:30 +0100 | <EvanR> | is this node.js |
| 2022-02-03 18:45:33 +0100 | <Cale> | No, that's another discussion |
| 2022-02-03 18:45:36 +0100 | <EvanR> | oh |
| 2022-02-03 18:46:01 +0100 | <dminuoso> | You might get some local vectorization happening through LLVM if you're lucky, though. |
| 2022-02-03 18:46:07 +0100 | <Cale> | https://hackage.haskell.org/package/ghc-prim-0.8.0/docs/GHC-Prim.html#g:38 |
| 2022-02-03 18:46:30 +0100 | <affine> | i've seen this but frankly it looks painful to use |
| 2022-02-03 18:46:37 +0100 | shapr | (~user@pool-173-73-44-186.washdc.fios.verizon.net) (Ping timeout: 240 seconds) |
| 2022-02-03 18:46:52 +0100 | <Cale> | It's fairly painful to use, yes |
| 2022-02-03 18:46:53 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 18:47:28 +0100 | <dminuoso> | Cale: Last I checked GHC didn't actually make use of them outside some experimental branch that some researcher was working on. Im trying to find the author, he presented some results on Haskell Exchange 2019 if memory serves right. |
| 2022-02-03 18:47:39 +0100 | <[exa]> | affine: what instructions would the vectorized branching correspond to? |
| 2022-02-03 18:48:47 +0100 | <Cale> | dminuoso: But you can probably make use of them by hand and have them work with the LLVM backend... |
| 2022-02-03 18:48:58 +0100 | <Cale> | dminuoso: it's just, mildly painful |
| 2022-02-03 18:49:02 +0100 | <dminuoso> | Yeah absolutely. |
| 2022-02-03 18:49:12 +0100 | <dminuoso> | At that point you might as well just FFI into your intel/clang/gcc compiled code. |
| 2022-02-03 18:49:22 +0100 | <EvanR> | do any of the array libraries use these prim ops, Repa for example |
| 2022-02-03 18:49:57 +0100 | <Cale> | Not as far as I'm aware. |
| 2022-02-03 18:50:03 +0100 | <EvanR> | cool |
| 2022-02-03 18:50:08 +0100 | fef | (~thedawn@user/thedawn) |
| 2022-02-03 18:50:15 +0100 | <dminuoso> | How's that cool? Smelling an opportunity? :p |
| 2022-02-03 18:50:27 +0100 | <Cale> | https://hackage.haskell.org/package/accelerate might be a good place to consider adding support |
| 2022-02-03 18:50:34 +0100 | <affine> | i thought maybe the ternary logic? |
| 2022-02-03 18:50:42 +0100 | <affine> | [exa] |
| 2022-02-03 18:50:45 +0100 | <Cale> | actually, I wonder what accelerate-llvm-native does |
| 2022-02-03 18:51:05 +0100 | deadmarshal | (~deadmarsh@95.38.119.14) (Ping timeout: 250 seconds) |
| 2022-02-03 18:51:07 +0100 | <Cale> | I think that's just multicore |
| 2022-02-03 18:51:11 +0100 | <[exa]> | btw there is this: https://hackage.haskell.org/package/knead |
| 2022-02-03 18:51:33 +0100 | <[exa]> | affine: pick the instruction here https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#techs=AVX_512 :] |
| 2022-02-03 18:52:19 +0100 | shapr` | shapr |
| 2022-02-03 18:52:40 +0100 | <Athas> | EvanR: I think Repa predates those primops and Accelerate doesn't use primops at all in its best backends. |
| 2022-02-03 18:52:48 +0100 | <Athas> | Maybe Massiv? |
| 2022-02-03 18:53:16 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-02-03 18:53:16 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-02-03 18:53:16 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-02-03 18:54:15 +0100 | zaquest | (~notzaques@5.130.79.72) |
| 2022-02-03 18:55:54 +0100 | <EvanR> | dminuoso, at least knowing "no" is better than not knowing |
| 2022-02-03 18:56:30 +0100 | <EvanR> | I've been told ghc has no "SIMD game" |
| 2022-02-03 18:57:10 +0100 | Midjak | (~Midjak@may53-1-78-226-116-92.fbx.proxad.net) |
| 2022-02-03 18:57:51 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-02-03 18:58:27 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 250 seconds) |
| 2022-02-03 18:59:21 +0100 | <affine> | [exa] vmulps |
| 2022-02-03 18:59:38 +0100 | <affine> | like using masks instead of a branch as in branchless code |
| 2022-02-03 18:59:45 +0100 | <affine> | although that might be pointless not sure |
| 2022-02-03 18:59:51 +0100 | <affine> | it is very very specific |
| 2022-02-03 19:01:02 +0100 | <EvanR> | simd stuff would be great for software graphics purposes xD |
| 2022-02-03 19:01:29 +0100 | MajorBiscuit | (~MajorBisc@c-001-015-052.client.tudelft.eduvpn.nl) (Ping timeout: 250 seconds) |
| 2022-02-03 19:01:37 +0100 | <EvanR> | as great as GPUs are, the interface hurts purity and laziness |
| 2022-02-03 19:01:39 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) |
| 2022-02-03 19:01:50 +0100 | <[exa]> | affine: yeah ghc generally does not work with the sufficient level of data abstraction there |
| 2022-02-03 19:01:51 +0100 | <EvanR> | and haskell doesn't run on GPUs yet |
| 2022-02-03 19:02:05 +0100 | <affine> | what do you mean by 'sufficient level of data abstraction'? |
| 2022-02-03 19:02:12 +0100 | <affine> | is it laziness? |
| 2022-02-03 19:02:54 +0100 | <[exa]> | like, sufficiently big packs of floats that get mapped in precise blocks over simple operations with simple conditions that all can be processed by SIMD instructions |
| 2022-02-03 19:04:06 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) (Remote host closed the connection) |
| 2022-02-03 19:04:20 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) |
| 2022-02-03 19:04:35 +0100 | <[exa]> | the best way for autogenerating SIMD code now is AFAIK 1] loop unrolling 2] not writing loops and using an abstraction like repa where manipulating the individual tiny processing fibers is easy |
| 2022-02-03 19:04:49 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 19:04:53 +0100 | <[exa]> | (also futhark) |
| 2022-02-03 19:05:24 +0100 | <affine> | is SIMD only useful for numeric computations? it is clearly the way to go for matrices |
| 2022-02-03 19:06:02 +0100 | <affine> | i know AVX-512 makes your CPU hot. i'm not sure if there is some latency in using it |
| 2022-02-03 19:06:29 +0100 | <Cale> | affine: In theory, perhaps not, in practice, it's hard to figure out how to use for anything other than numerical computations. |
| 2022-02-03 19:06:32 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-02-03 19:07:15 +0100 | <Cale> | It's rare that you have non-numerical datastructures that are laid out in memory in a sufficiently uniform way to get any leverage |
| 2022-02-03 19:07:17 +0100 | <EvanR> | it might be hard to map high level code that expresses the idea of matrices (as opposed to a dumb N x M array of floats) to SIMD |
| 2022-02-03 19:07:23 +0100 | segfaultfizzbuzz | thinks the machine learning club underuses sparsity |
| 2022-02-03 19:07:28 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-02-03 19:07:34 +0100 | <[exa]> | yeah, if you have a huge pile of numbers that can be loaded and crunched in the blocks of 4/8/16 or something, it can make a nice 3-4x speedup against manually optimized asm code (SSE case) or even more with AVX (although I wasn't able to squeeze much more than ~4x with everything I tried) |
| 2022-02-03 19:08:22 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 19:08:25 +0100 | eayavas | (~eayavas@78.168.199.216) (Quit: WeeChat 3.4) |
| 2022-02-03 19:08:27 +0100 | <affine> | just out of curiosity what numerical things were you computing? |
| 2022-02-03 19:08:37 +0100 | futty14 | (~futty14@c90-143-137-255.bredband.tele2.se) (Ping timeout: 256 seconds) |
| 2022-02-03 19:08:40 +0100 | <affine> | in haskell* |
| 2022-02-03 19:08:43 +0100 | <koala_man> | do you count byte shuffling as numeric computation? |
| 2022-02-03 19:09:04 +0100 | <affine> | what is byte shuffling? |
| 2022-02-03 19:09:13 +0100 | <[exa]> | affine: not much in haskell directly, for me it was simplest to patch it up in C and then call from haskell |
| 2022-02-03 19:10:03 +0100 | <koala_man> | affine: e.g. converting endianness or expanding 16bit values into 32bit one (or packing them back) |
| 2022-02-03 19:10:07 +0100 | <[exa]> | anyway the last time it was some weird kind of gradient descent |
| 2022-02-03 19:10:37 +0100 | <[exa]> | ah yeah actually crunching long strings makes some minor sense with SIMD |
| 2022-02-03 19:11:32 +0100 | <[exa]> | sadly CPUs don't have much cache or memory throughput, so you usually hit the wall there very quickly |
| 2022-02-03 19:12:15 +0100 | <affine> | i learnt yesterday how few registers CPU have |
| 2022-02-03 19:12:18 +0100 | <affine> | i was totally shocked |
| 2022-02-03 19:12:24 +0100 | <dminuoso> | affine: Actually the reality is much more interesting. |
| 2022-02-03 19:12:25 +0100 | <EvanR> | that you know of |
| 2022-02-03 19:12:29 +0100 | <monochrom> | All those P-boxes, S-boxes, and "do 16 rounds of this" of a cipher may fit SIMD too. But are the data numbers? I think people will kill each other over that question. |
| 2022-02-03 19:12:31 +0100 | <dminuoso> | Physically CPUs have about 300-500 registers. |
| 2022-02-03 19:12:40 +0100 | <affine> | wait what? |
| 2022-02-03 19:12:49 +0100 | <affine> | i thought they had like 30 |
| 2022-02-03 19:12:54 +0100 | <EvanR> | you can only use registers exposed by the architecture |
| 2022-02-03 19:12:58 +0100 | <dminuoso> | So lets say they have 16 so-called architectural registers. |
| 2022-02-03 19:13:21 +0100 | <monochrom> | I thought a cache was a register file. :) |
| 2022-02-03 19:13:25 +0100 | <dminuoso> | affine: Do some research on whats called the tomasulo algorithm, |
| 2022-02-03 19:13:29 +0100 | <EvanR> | the others are used by the illuminati to spy on and compute stuff for their own nefarious purposes |
| 2022-02-03 19:13:37 +0100 | <dolio> | They're executing a lot of different instructions at once. |
| 2022-02-03 19:13:40 +0100 | <dminuoso> | It will be quite an adventure |
| 2022-02-03 19:13:43 +0100 | <monochrom> | haha EvanR |
| 2022-02-03 19:14:03 +0100 | <dolio> | So each instruction would need to have a set of registers, presumably. |
| 2022-02-03 19:14:29 +0100 | <dminuoso> | affine: CPUs can do simultaneous out-of-order execution. At peak, a modern single CPU is able to execute upwards of 8 (perhaps more on modern CPUs) instructions in special circumstances. |
| 2022-02-03 19:14:39 +0100 | <affine> | it sounds like a huge amount of performance is left on the table that compilers it could have. if they can't see all the available registers? |
| 2022-02-03 19:14:49 +0100 | <affine> | compilers could have* |
| 2022-02-03 19:15:08 +0100 | <dminuoso> | affine: Compilers do their best to produce code that is executed well on todays super scalar CPUs |
| 2022-02-03 19:15:20 +0100 | <dminuoso> | But yeah, you have much optimization potential |
| 2022-02-03 19:15:26 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) (Ping timeout: 256 seconds) |
| 2022-02-03 19:15:30 +0100 | <dminuoso> | Which is why locally well written assembly can do wonders in certain circumstances |
| 2022-02-03 19:15:43 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-02-03 19:15:49 +0100 | <affine> | i wrote assembly for the first time yesterday |
| 2022-02-03 19:15:55 +0100 | <affine> | never used a more painful language |
| 2022-02-03 19:16:05 +0100 | <affine> | other than java |
| 2022-02-03 19:16:21 +0100 | <EvanR> | there are programmers who prefer assembly, check out menuetOS xD |
| 2022-02-03 19:16:34 +0100 | <EvanR> | gui and everything |
| 2022-02-03 19:17:08 +0100 | <dminuoso> | affine: Best of all is the out of order executions. CPUs will not execute your instruction one by one, they are taken out of order and executed in whatever fashion the CPU can leverage its resources with - as long as architecturally you dont get to tell the difference. |
| 2022-02-03 19:17:10 +0100 | <dminuoso> | Fun fact now: |
| 2022-02-03 19:17:16 +0100 | <ski> | x86 is pretty painful |
| 2022-02-03 19:17:31 +0100 | DNH | (~DNH@2a02:8108:1100:16d8:a4a2:67d7:acda:e455) (Ping timeout: 250 seconds) |
| 2022-02-03 19:17:32 +0100 | <EvanR> | yes, 4 registers xD |
| 2022-02-03 19:17:43 +0100 | <affine> | i was using registers r10 and r10d as if they were unrelated |
| 2022-02-03 19:17:44 +0100 | <ski> | there are nicer architectures |
| 2022-02-03 19:17:49 +0100 | <affine> | i was super confused why nothing worked |
| 2022-02-03 19:17:55 +0100 | <dminuoso> | affine: This buys you a lot of performance. And yet, a lot of the recent CPU vulnerabilities like Spectre and friends are examples how this can still leak timings. |
| 2022-02-03 19:17:57 +0100 | soxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) (Ping timeout: 250 seconds) |
| 2022-02-03 19:18:23 +0100 | <EvanR> | did spectre leak the actual data via cache |
| 2022-02-03 19:18:29 +0100 | <EvanR> | rather than timing |
| 2022-02-03 19:18:54 +0100 | <affine> | does it make sense for CPUs to be consequential instructions? maybe a less deterministic instruction set would make sense? |
| 2022-02-03 19:18:58 +0100 | <dminuoso> | Okay that was a slight misrepresentatino, but to exfiltrate that cache you'd execute timing attacks |
| 2022-02-03 19:18:59 +0100 | <affine> | i know ARM has weak memory ordering |
| 2022-02-03 19:19:33 +0100 | <dminuoso> | Well, the clear trend in the industry is towards more cores on your silicon anyway |
| 2022-02-03 19:20:09 +0100 | <EvanR> | which translates to non-determinism |
| 2022-02-03 19:21:37 +0100 | CiaoSen | (~Jura@p200300c95737a2002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-02-03 19:22:07 +0100 | soxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) |
| 2022-02-03 19:23:57 +0100 | emf | (~emf@2620:10d:c090:400::5:3e0a) (Ping timeout: 240 seconds) |
| 2022-02-03 19:25:16 +0100 | <EvanR> | monochrom, you gotta admit "The Shadow Stack" sounds pretty ominous |
| 2022-02-03 19:25:37 +0100 | kaph | (~kaph@net-2-47-208-144.cust.vodafonedsl.it) (Ping timeout: 256 seconds) |
| 2022-02-03 19:26:26 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 19:26:36 +0100 | burnsidesLlama | (~burnsides@dhcp168-042.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2022-02-03 19:26:37 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 240 seconds) |
| 2022-02-03 19:27:03 +0100 | burnsidesLlama | (~burnsides@dhcp168-042.wadham.ox.ac.uk) |
| 2022-02-03 19:27:20 +0100 | <Athas> | affine: it depends on what you mean by "numeric", but all sorts of algorithms can be SIMD-accelerated. Searching, for example. |
| 2022-02-03 19:27:37 +0100 | <affine> | oh hi, you're the futhark guy :O |
| 2022-02-03 19:27:38 +0100 | emf | (~emf@163.114.132.7) |
| 2022-02-03 19:28:22 +0100 | zincy | (~zincy@host86-151-99-97.range86-151.btcentralplus.com) |
| 2022-02-03 19:29:04 +0100 | <dminuoso> | I have an API binding library. Say I have a data structure that maps to an API and I happened to use generics to derive the ToJSON instance, and I have a typo in a field name. |
| 2022-02-03 19:29:12 +0100 | <dminuoso> | Does fixing the field name warrant a major PVP version bump? |
| 2022-02-03 19:29:16 +0100 | <dminuoso> | I feel like its not clear. |
| 2022-02-03 19:29:17 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 19:29:36 +0100 | <Athas> | affine: true! |
| 2022-02-03 19:29:40 +0100 | <dminuoso> | It's almost but guaranteed that if you're using this field, you're already experiencing a bug since you couldn't reasonably use this field anyway |
| 2022-02-03 19:30:01 +0100 | <[exa]> | dminuoso: I'd say that no one could technically use it before because of the typo, and thus it's non breaking |
| 2022-02-03 19:30:11 +0100 | [exa] | hides from angry user mob |
| 2022-02-03 19:30:40 +0100 | <EvanR> | fixing is obviously non-breaking |
| 2022-02-03 19:31:03 +0100 | alp | (~alp@user/alp) (Ping timeout: 256 seconds) |
| 2022-02-03 19:31:24 +0100 | <dminuoso> | Alright, I think Ill go with minor version bump and give the angry user mob, should they appear, [exa]'s private phone number. |
| 2022-02-03 19:31:31 +0100 | burnsidesLlama | (~burnsides@dhcp168-042.wadham.ox.ac.uk) (Ping timeout: 256 seconds) |
| 2022-02-03 19:32:04 +0100 | <[exa]> | dminuoso: like, looking at some stats about user count would probably be the most guiding info here |
| 2022-02-03 19:32:08 +0100 | <Athas> | Is there a variant of 'bracket' where the release action is told whether an exception was thrown? |
| 2022-02-03 19:32:41 +0100 | <dminuoso> | [exa]: You likely will experience a lynch mob between a 1 and a hundred. |
| 2022-02-03 19:32:49 +0100 | <monochrom> | dminuoso: A bug fix is a point release. You can give my email address to the angry user mob. >:) |
| 2022-02-03 19:33:06 +0100 | <EvanR> | you mean, semi-catch the exception? Doesn't that violate the no-cloning theorem of exception mechanics |
| 2022-02-03 19:33:32 +0100 | <Athas> | EvanR: I just don't want to conceal the exception with one of my own. |
| 2022-02-03 19:33:52 +0100 | <dminuoso> | Athas: Then dont catch SomeException? |
| 2022-02-03 19:34:09 +0100 | <Athas> | dminuoso: but I still need to clean up, even if an exception is thrown. |
| 2022-02-03 19:34:28 +0100 | <EvanR> | that's what the close clause of the bracket is for |
| 2022-02-03 19:34:29 +0100 | <dminuoso> | Athas: Then use a separate onException internally? |
| 2022-02-03 19:34:36 +0100 | <monochrom> | Athas: bracketOnError or onException may help |
| 2022-02-03 19:34:39 +0100 | <Athas> | I have a cleanup action. If that cleanup action is run under normal circumstances, it m ay throw an exception. But if it is running during exception unwinding, then it should never throw an exception. |
| 2022-02-03 19:34:47 +0100 | <dminuoso> | It seems you want two separate exception control mechanisms here |
| 2022-02-03 19:35:07 +0100 | <Athas> | Yeah, I can probably cobble something together myself, but this feels like a problem that's easy to solve incorrectly, so I hoped someone had already done so. |
| 2022-02-03 19:35:28 +0100 | <dminuoso> | Hah, what could possibly go wrong *uninterruptibleMumble* |
| 2022-02-03 19:36:09 +0100 | <monochrom> | Indeed onException seems to be a more basic building block. bracket uses onException. |
| 2022-02-03 19:36:14 +0100 | <[exa]> | Athas: maybe your exceptions are so streamlined that they shouldn't be exceptional anymore |
| 2022-02-03 19:37:21 +0100 | <monochrom> | (And bracket achieves release-no-matter-what by repeating itself: on exception, release; on no exception, release. |
| 2022-02-03 19:37:23 +0100 | <monochrom> | ) |
| 2022-02-03 19:37:56 +0100 | <monochrom> | (What an irony that when I explain bracket I forgot to a close parenthesis heh) |
| 2022-02-03 19:37:56 +0100 | <EvanR> | exceptions possibly during cleanup is nasty business |
| 2022-02-03 19:38:30 +0100 | <EvanR> | this is probably why cleanup functions in C never return anything or fail |
| 2022-02-03 19:38:33 +0100 | <Athas> | It is. |
| 2022-02-03 19:38:48 +0100 | <Athas> | My only goal is to not clobber the message from the original exception. |
| 2022-02-03 19:38:59 +0100 | <Athas> | And the process as a whole will likely be dying soon afterwards. |
| 2022-02-03 19:42:54 +0100 | <maerwald> | do we have a strpbrk wrapper for bytestring? |
| 2022-02-03 19:43:41 +0100 | DavidMilestone | (~DavidMile@122.179.237.116) |
| 2022-02-03 19:43:54 +0100 | <dminuoso> | Mmm, not in any of the common packages |
| 2022-02-03 19:44:07 +0100 | <dminuoso> | But you can trivially FFI against this one yourself I suppose |
| 2022-02-03 19:44:42 +0100 | alp | (~alp@user/alp) |
| 2022-02-03 19:45:17 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds) |
| 2022-02-03 19:45:33 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 19:46:30 +0100 | acidsys | (~LSD@2.lsd.systems) (Excess Flood) |
| 2022-02-03 19:47:04 +0100 | acidsys | (~LSD@2.lsd.systems) |
| 2022-02-03 19:48:35 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 19:49:57 +0100 | kaph | (~kaph@net-2-47-208-144.cust.vodafonedsl.it) |
| 2022-02-03 19:51:51 +0100 | <maerwald> | I'd assume that's much faster than BS.find? |
| 2022-02-03 19:53:34 +0100 | zincy | (~zincy@host86-151-99-97.range86-151.btcentralplus.com) (Remote host closed the connection) |
| 2022-02-03 19:53:53 +0100 | <dminuoso> | BS.find is very different from strpbrk? |
| 2022-02-03 19:54:52 +0100 | <dminuoso> | Did you mean breakSubstring perhaps? |
| 2022-02-03 19:54:59 +0100 | <monochrom> | findIndex is closer. But then there is also the question of, for example, perhaps you use strpbrk but you dereference its answer right away so it's find. |
| 2022-02-03 19:55:03 +0100 | <dminuoso> | Or, no not quite |
| 2022-02-03 19:55:20 +0100 | <EvanR> | findIndex seems to be a tight loop that just does peekPtr. Does peeking entail a barrier of some sort |
| 2022-02-03 19:55:56 +0100 | econo | (uid147250@user/econo) |
| 2022-02-03 19:56:08 +0100 | ubert1 | (~Thunderbi@p200300ecdf0994a1946b5f66cf92c0df.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2022-02-03 19:56:34 +0100 | <dminuoso> | I guess whether strpbrk is faster than find or findIndex depends on the size of the conceptual character set |
| 2022-02-03 19:56:36 +0100 | <EvanR> | it does a call to an unknown function, but inlining |
| 2022-02-03 19:57:03 +0100 | <dminuoso> | If the character set is large, Id profile it - if its really small, Id profile it, but between strpbrk seems like it could be faster |
| 2022-02-03 19:57:42 +0100 | <dminuoso> | Guess strpbrk can benefit from locality of cache well |
| 2022-02-03 19:58:03 +0100 | <maerwald> | https://github.com/bminor/glibc/blob/master/string/strcspn.c |
| 2022-02-03 19:58:26 +0100 | <maerwald> | strpbrk is implemented in terms of that |
| 2022-02-03 19:58:38 +0100 | vicfred | (~vicfred@user/vicfred) |
| 2022-02-03 19:58:59 +0100 | yassernasc | (~yassernas@ec2-54-87-145-249.compute-1.amazonaws.com) |
| 2022-02-03 19:59:46 +0100 | <maerwald> | https://github.com/bminor/glibc/commit/d3496c9f4f27d3009b71be87f6108b4fed7314bd#diff-32ea539240c54… |
| 2022-02-03 20:00:08 +0100 | <maerwald> | this looks more sophisticated than a dumb for loop |
| 2022-02-03 20:00:09 +0100 | <dminuoso> | Yeah this will definitely execute fast. Seems like this could vectorize, will induce implicit cache prefetching |
| 2022-02-03 20:00:38 +0100 | <dminuoso> | I doubt the bytestring code, after going through core, cmm, and then assembly will get anything close enough,. |
| 2022-02-03 20:00:54 +0100 | <maerwald> | looks like an easy win then |
| 2022-02-03 20:01:01 +0100 | <dminuoso> | Do you pay any penalty for FFI though? |
| 2022-02-03 20:01:08 +0100 | <dminuoso> | Is there any RTS cost involved? |
| 2022-02-03 20:02:15 +0100 | burnsidesLlama | (~burnsides@dhcp168-042.wadham.ox.ac.uk) |
| 2022-02-03 20:03:54 +0100 | fresheyeball | (~fresheyeb@c-76-25-93-164.hsd1.co.comcast.net) (Quit: WeeChat 2.9) |
| 2022-02-03 20:04:34 +0100 | <monochrom> | FFI has a cost, even when no marshalling. |
| 2022-02-03 20:05:23 +0100 | <EvanR> | FFI cost in this case might be worth it since it could be doing significant work on the other side |
| 2022-02-03 20:05:44 +0100 | <monochrom> | Mostly in worrying about concurrency so there is some context switching and "this thread can't run Haskell code now, need to find another thread for that". |
| 2022-02-03 20:06:31 +0100 | <EvanR> | in before we do a deep dive on this optimization and maerwald finally decides the original task isn't even necessary anymore xD |
| 2022-02-03 20:06:55 +0100 | <maerwald> | this is definitely necessary |
| 2022-02-03 20:06:57 +0100 | <monochrom> | I wouldn't be surprised if the input size is too small for "performance" to matter. |
| 2022-02-03 20:07:10 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 20:07:17 +0100 | <maerwald> | the input size large |
| 2022-02-03 20:07:23 +0100 | <maerwald> | in an XML parser |
| 2022-02-03 20:07:35 +0100 | <maerwald> | a fork of xeno |
| 2022-02-03 20:08:02 +0100 | MatthiasG2 | (~matthias@i6DFA038C.versanet.de) |
| 2022-02-03 20:08:27 +0100 | haskellberryfinn | (~nut@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 256 seconds) |
| 2022-02-03 20:08:34 +0100 | <dminuoso> | Honestly, sometimes performance golfing is a lot of fun. |
| 2022-02-03 20:08:55 +0100 | burnsidesLlama | (~burnsides@dhcp168-042.wadham.ox.ac.uk) (Ping timeout: 256 seconds) |
| 2022-02-03 20:08:57 +0100 | vysn | (~vysn@user/vysn) (Ping timeout: 240 seconds) |
| 2022-02-03 20:09:06 +0100 | <dminuoso> | I too performance-shedded my DNS parsing library, despite only needing to match against.. 3 domain names right now |
| 2022-02-03 20:09:25 +0100 | <dminuoso> | But I feel confident in that we can scale to millions with no heavy performance penalty |
| 2022-02-03 20:10:28 +0100 | <EvanR> | I too going down a performance hole, esp the last hole at goofy golf which just keeps going and you never get your ball back |
| 2022-02-03 20:10:29 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 20:10:30 +0100 | <monochrom> | "Hi I'm reading a domain name that's 1MB long, why is Haskell taking 50MB?" |
| 2022-02-03 20:10:34 +0100 | <EvanR> | enjoy* |
| 2022-02-03 20:11:27 +0100 | <monochrom> | I enjoy the opposite golfing. |
| 2022-02-03 20:11:57 +0100 | <monochrom> | I use an n^2 algorithm where an n lg n algorithm exists, where n is the number of students. |
| 2022-02-03 20:12:26 +0100 | <monochrom> | My solution is to make homework and exams hard to decrease n. >:) |
| 2022-02-03 20:13:20 +0100 | <EvanR> | asymptotically inefficient and slow algorithms for fun and profit, get to market today while the egg heads tool around in research |
| 2022-02-03 20:14:49 +0100 | <dminuoso> | Given the influx of asymptotically inefficient implementations nowadays, I ponder about monochrom's part on that. |
| 2022-02-03 20:14:59 +0100 | <dminuoso> | Perhaps his pedagogy is misguided. |
| 2022-02-03 20:15:10 +0100 | <monochrom> | haha |
| 2022-02-03 20:16:21 +0100 | <monochrom> | Don't worry, some of my homework questions are hard precisely because "you have a 2-second limit, if you don't stay below n lg n you won't make it". |
| 2022-02-03 20:16:45 +0100 | <monochrom> | "also in a docker container that has only 10MB RAM" |
| 2022-02-03 20:16:45 +0100 | <maerwald> | I guess I know now why it wasn't implemented... strpbrk requires a null terminated string |
| 2022-02-03 20:16:58 +0100 | <maerwald> | bytestring internally is not null terminated |
| 2022-02-03 20:17:29 +0100 | Pickchea | (~private@user/pickchea) |
| 2022-02-03 20:17:46 +0100 | Hildegunst | (~luc@80.248.12.109.rev.sfr.net) |
| 2022-02-03 20:17:47 +0100 | <monochrom> | Ah I forgot the null too. |
| 2022-02-03 20:18:01 +0100 | DavidMilestone | (~DavidMile@122.179.237.116) (Quit: Client closed) |
| 2022-02-03 20:18:18 +0100 | <monochrom> | But breakSubstring is some kind of strcspn. |
| 2022-02-03 20:18:21 +0100 | <EvanR> | indeed '\0' is allowed in the body of a bytestring, luckily for general sanity |
| 2022-02-03 20:18:33 +0100 | soxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) (Ping timeout: 256 seconds) |
| 2022-02-03 20:20:26 +0100 | soxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) |
| 2022-02-03 20:20:46 +0100 | <EvanR> | but your loader might be modified to produce null terminated bytestring if inner 0 are not expected |
| 2022-02-03 20:23:27 +0100 | <maerwald> | dreams crushed by a single byte |
| 2022-02-03 20:23:57 +0100 | <monochrom> | Perhaps look for a Fortran library instead of a C library... |
| 2022-02-03 20:24:43 +0100 | <EvanR> | can we FFI to fortran? |
| 2022-02-03 20:25:10 +0100 | <dminuoso> | Absolutely |
| 2022-02-03 20:25:14 +0100 | <EvanR> | nice |
| 2022-02-03 20:25:24 +0100 | <monochrom> | Yes, it's indistinguishable from FFIing to C. |
| 2022-02-03 20:25:25 +0100 | <dminuoso> | e.g. hmatrix |
| 2022-02-03 20:25:33 +0100 | <monochrom> | Yeah, that. LAPACK. |
| 2022-02-03 20:25:35 +0100 | <dminuoso> | Which FFIs into BLAS/LAPACK |
| 2022-02-03 20:26:00 +0100 | janus | (janus@anubis.0x90.dk) |
| 2022-02-03 20:26:45 +0100 | <janus> | regarding this line, since Typeable is derivable for all types, there can be an instance for all types, right: https://github.com/GetShopTV/swagger2/blob/master/src/Data/Swagger/Internal.hs#L473 |
| 2022-02-03 20:27:00 +0100 | <janus> | but then why does it fail compilation: https://github.com/GetShopTV/swagger2/runs/5055866820?check_suite_focus=true#step:4:668 |
| 2022-02-03 20:27:18 +0100 | DavidMilestone | (~DavidMile@122.179.237.116) |
| 2022-02-03 20:27:23 +0100 | <janus> | "Could not deduce (Typeable t)" why not? you should deduce typeable for any t |
| 2022-02-03 20:28:05 +0100 | <EvanR> | not literally everything is typeable right |
| 2022-02-03 20:28:20 +0100 | <EvanR> | the universe has grown but isn't complete |
| 2022-02-03 20:28:22 +0100 | <ski> | not skolems |
| 2022-02-03 20:28:47 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 20:29:36 +0100 | <dminuoso> | Or what about non-* kinded types? |
| 2022-02-03 20:30:23 +0100 | <awpr> | it's not about _whether_ a Typeable can exist for a given type, it's about GHC needing to _have_ the Typeable instance for a given type. GHC can produce an instance on demand for any non-variable type (other than like foralls and other things that can't have typeclass instances). but if you need an instance for a type variable, it'll have to be passed in from somewhere |
| 2022-02-03 20:30:25 +0100 | DavidMilestone | (~DavidMile@122.179.237.116) (Client Quit) |
| 2022-02-03 20:30:29 +0100 | <dolio> | Isn't it kind polymorphic not? |
| 2022-02-03 20:30:31 +0100 | <dolio> | Now, even. |
| 2022-02-03 20:30:47 +0100 | <EvanR> | > typeOf 4# |
| 2022-02-03 20:30:48 +0100 | <lambdabot> | error: |
| 2022-02-03 20:30:48 +0100 | <lambdabot> | • Couldn't match a lifted type with an unlifted type |
| 2022-02-03 20:30:48 +0100 | <lambdabot> | When matching types |
| 2022-02-03 20:31:20 +0100 | <awpr> | > typeRep @Int# |
| 2022-02-03 20:31:21 +0100 | <lambdabot> | error: |
| 2022-02-03 20:31:21 +0100 | <lambdabot> | Pattern syntax in expression context: typeRep@Int# |
| 2022-02-03 20:31:21 +0100 | <lambdabot> | Did you mean to enable TypeApplications? |
| 2022-02-03 20:31:22 +0100 | <janus> | a skolem is skolem means 'skolem variable' in this context? like you can't get a Typeable if you don't know which type it actually is? like here? https://stackoverflow.com/a/12722877/309483 |
| 2022-02-03 20:31:33 +0100 | <dminuoso> | dolio: Could you even make use of that somehow? |
| 2022-02-03 20:31:45 +0100 | <janus> | dminuoso: like e.g. 'Maybe' ? |
| 2022-02-03 20:32:01 +0100 | <awpr> | % typeRep @Maybe Proxy |
| 2022-02-03 20:32:01 +0100 | <yahb> | awpr: ; <interactive>:9:16: error:; * Couldn't match expected type: Maybe a0; with actual type: Proxy t0; * In the second argument of `typeRep', namely `Proxy'; In the expression: typeRep @Maybe Proxy; In an equation for `it': it = typeRep @Maybe Proxy |
| 2022-02-03 20:32:11 +0100 | <dminuoso> | One argument too many |
| 2022-02-03 20:32:13 +0100 | <dminuoso> | % typeRep @Maybe |
| 2022-02-03 20:32:14 +0100 | <yahb> | dminuoso: ; <interactive>:10:1: error:; * No instance for (Show (Maybe a0 -> TypeRep)) arising from a use of `print'; (maybe you haven't applied a function to enough arguments?); * In a stmt of an interactive GHCi command: print it |
| 2022-02-03 20:32:18 +0100 | <dminuoso> | That looks better |
| 2022-02-03 20:32:19 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 20:32:24 +0100 | <awpr> | % typeRep @_ @Maybe Proxy |
| 2022-02-03 20:32:25 +0100 | <yahb> | awpr: Maybe |
| 2022-02-03 20:32:30 +0100 | <awpr> | % typeRep @_ @42 Proxy |
| 2022-02-03 20:32:31 +0100 | <yahb> | awpr: 42 |
| 2022-02-03 20:33:00 +0100 | <EvanR> | % typeRef @_ @Int# Proxy |
| 2022-02-03 20:33:00 +0100 | <yahb> | EvanR: ; <interactive>:13:1: error:; * Variable not in scope: typeRef :: Proxy t0 -> t; * Perhaps you meant one of these: `typeRep' (imported from Data.Data), `typeOf' (imported from Data.Data) |
| 2022-02-03 20:33:08 +0100 | <EvanR> | % typeRep @_ @Int# Proxy |
| 2022-02-03 20:33:08 +0100 | <yahb> | EvanR: Int# |
| 2022-02-03 20:33:19 +0100 | affine | (~hugh@2a02:1206:45a3:6340:da01:c0c6:8610:80f6) (Remote host closed the connection) |
| 2022-02-03 20:34:05 +0100 | Erutuon | (~Erutuon@user/erutuon) |
| 2022-02-03 20:34:25 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-02-03 20:35:01 +0100 | cynomys | (~cynomys@user/cynomys) |
| 2022-02-03 20:35:55 +0100 | Morrow_ | (~user@bzq-110-168-31-106.red.bezeqint.net) |
| 2022-02-03 20:35:59 +0100 | <janus> | so if typeRep does't error, that should mean that it finds the Typeable instance. so it seems that even though the type inside the maybe isn't found, there is still a Typeable instance |
| 2022-02-03 20:36:45 +0100 | <janus> | so not all non-* kinded types have no auto-derived Typeable, i guess |
| 2022-02-03 20:36:57 +0100 | <awpr> | not sure what "type inside the maybe" is, but `Maybe` is a thing of kind `Type -> Type`, and GHC can solve a `Typeable` for it |
| 2022-02-03 20:37:26 +0100 | <monochrom> | No, in the "typeRep @_ @Maybe Proxy" example, the "Maybe" is there as an example for a *->* kinded type. This is not "typeRep @_ @(Maybe ???) Proxy". |
| 2022-02-03 20:37:44 +0100 | <monochrom> | The type of Proxy there is literally "Proxy Maybe". Not "Proxy (Maybe ???)". |
| 2022-02-03 20:37:56 +0100 | doyougnu | (~doyougnu@cpe-67-249-83-190.twcny.res.rr.com) |
| 2022-02-03 20:37:59 +0100 | <monochrom> | See also the 42 example. |
| 2022-02-03 20:38:32 +0100 | <janus> | oh, it didn't even occur to me that 'Proxy Maybe' would even be a well-formed type :O |
| 2022-02-03 20:38:36 +0100 | <monochrom> | All of those examples are exploring non-* kinds. |
| 2022-02-03 20:39:49 +0100 | <ski> | janus : typical term would be "skolem constant (or function)", but yea |
| 2022-02-03 20:40:17 +0100 | soxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) (Ping timeout: 240 seconds) |
| 2022-02-03 20:40:45 +0100 | <ski> | "rigid variable" is another term used. other, relevant, words would be opaque/unknown/hidden/forgotten/abstract |
| 2022-02-03 20:41:25 +0100 | <monochrom> | May I throw in "existential strength" there? :) Not that it helps. |
| 2022-02-03 20:42:01 +0100 | alp | (~alp@user/alp) (Ping timeout: 250 seconds) |
| 2022-02-03 20:42:19 +0100 | <dminuoso> | Does prettyprinter have some mechanism to lpad/rpad that Im not seeing? |
| 2022-02-03 20:42:37 +0100 | <ski> | janus : the `Typeable a' instance (a dictionary record, in the dictionary passing implementation), needs to come from somewhere. if you have an existential, then you have no way (in general) of recovering what type was hidden inside it, and so the only way to get `Typeable' is to have it packed into / provided in a constraint in the existential |
| 2022-02-03 20:42:51 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2022-02-03 20:43:10 +0100 | <dminuoso> | It seems the best thing to do is use `width` and do it somehow manually |
| 2022-02-03 20:43:17 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 240 seconds) |
| 2022-02-03 20:43:18 +0100 | <dminuoso> | Perhaps Im missing some other combinator? |
| 2022-02-03 20:43:40 +0100 | <EvanR> | I wonder if school math would be easier if there was distinction between rigid variables and uhm the other kind, i.e. solve for x in x^2 = x + 1 |
| 2022-02-03 20:43:54 +0100 | <monochrom> | I think all pretty printer designs we have are around indenting and hanging, they haven't thought of padding. |
| 2022-02-03 20:44:17 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-02-03 20:44:39 +0100 | <janus> | yes, especially with the infamous dictionary i can understand how the compiler needs to 'deduce' which dictionary to actually pass in |
| 2022-02-03 20:44:56 +0100 | <monochrom> | EvanR, I think they do, and I think they mess it up. |
| 2022-02-03 20:45:08 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2022-02-03 20:45:28 +0100 | <monochrom> | Well, not messed up in the simpleton questions that appear in school homework. |
| 2022-02-03 20:46:01 +0100 | <ski> | EvanR : logic programming does make that a syntactical distinction |
| 2022-02-03 20:46:05 +0100 | <janus> | talking about a partially-applied Maybe doesn't seem like Haskell98 to me. but it doesn't seem like DataKinds either since there are no ticks |
| 2022-02-03 20:46:09 +0100 | <janus> | when was all this introduced? |
| 2022-02-03 20:46:32 +0100 | <ski> | higher-order types is Haskell98 |
| 2022-02-03 20:46:42 +0100 | <awpr> | Haskell98. `Maybe Int` talks about partially-applied `Maybe` as a subterm :) |
| 2022-02-03 20:46:45 +0100 | <monochrom> | In "solve for x in x^2 = x + 1" it's taught (more like osmosised) we have an unknown. In "prove x+x = 2x" it's taught (ditto) we have a universal-strength variable. |
| 2022-02-03 20:47:34 +0100 | <janus> | but then, if it is just concerning Haskell98, how can it be that the Swagger2 file i linked compiles in GHC 9.0 but not in 9.2? surely Haskell98 details havn't changed |
| 2022-02-03 20:47:41 +0100 | <awpr> | also `instance Monad Maybe` talks about partially-applied `Maybe` |
| 2022-02-03 20:47:41 +0100 | <ski> | `Fix Maybe' is perfectly Haskell98 |
| 2022-02-03 20:47:58 +0100 | <monochrom> | They don't really try "solve for x in x^2 = y + 1 so that the solution works for all y" or "prove there exists x such that for all y ..." so they can PCA the whole space to just "solve = unknown, prove = universal". |
| 2022-02-03 20:48:03 +0100 | <ski> | or `Fix (Either Integer)', for that matter |
| 2022-02-03 20:48:12 +0100 | segfaultfizzbuzz | (~rustisafu@2602:306:cd3c:9350:cc4:c954:b25:db0a) (Quit: Leaving) |
| 2022-02-03 20:48:47 +0100 | <janus> | oh right, my missing 'MonadFail (Either String)' instance, that is the same situation, right |
| 2022-02-03 20:48:48 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 20:48:54 +0100 | <ski> | (oh, there's also the term "indeterminate") |
| 2022-02-03 20:49:32 +0100 | <awpr> | hmm, I didn't actually look at the error. it's weird that this is happening when there seemingly _is_ a `Typeable` constraint there. feels like GHC is unconvinced that the two `t`s are the same |
| 2022-02-03 20:51:09 +0100 | <janus> | but it really could have something to do with DataKinds, couldn't it? because the deducing machinery that suceeded previously, and now fails, it needs to go through a lifted type |
| 2022-02-03 20:51:35 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-02-03 20:51:47 +0100 | <dminuoso> | monochrom: Mmm, it seems that `column` and `width` at least let me do limited rpadding. |
| 2022-02-03 20:51:47 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 20:51:50 +0100 | <dminuoso> | I think those could suffice. |
| 2022-02-03 20:51:50 +0100 | <janus> | but that it of course unrelated to the ability to talk about indeterminate types |
| 2022-02-03 20:52:18 +0100 | fef | (~thedawn@user/thedawn) (Ping timeout: 276 seconds) |
| 2022-02-03 20:53:31 +0100 | <awpr> | on 478, where is `t` even coming from? there is no `t` there, unless it's implicit via PolyKinds? |
| 2022-02-03 20:54:32 +0100 | <awpr> | this kinda feels like a compiler bug to me. it's like GHC is coming up with a variable for the parameter of `SwaggerType` and forgetting to unify it with the corresponding thing in the instance head |
| 2022-02-03 20:55:16 +0100 | <janus> | awpr: PolyKinds is not enabled as far as I can see. i don't think it's implied by any of these extensions |
| 2022-02-03 20:55:30 +0100 | <awpr> | yeah, doesn't appear to be enabled |
| 2022-02-03 20:55:59 +0100 | <monochrom> | If there is a difference between 9.0 and 9.2 for this, this can get interesting. There is some known change, yes. |
| 2022-02-03 20:56:09 +0100 | <ski> | smells like missing an FD, or a type ascription or so ? |
| 2022-02-03 20:56:24 +0100 | <awpr> | complete shot in the dark: what happens if you remove the "deriving Typeable"? it's solved automatically on demand and doesn't need to be derived |
| 2022-02-03 20:56:39 +0100 | <awpr> | and maybe the deriving is doing something weird? |
| 2022-02-03 20:57:33 +0100 | deadmarshal | (~deadmarsh@95.38.119.14) |
| 2022-02-03 20:57:34 +0100 | <awpr> | re: missing fundeps, the reason this feels so weird to me is that in the instance on line 478, there shouldn't be any type variable involved at all |
| 2022-02-03 20:57:45 +0100 | vglfr | (~vglfr@88.155.40.186) |
| 2022-02-03 20:58:11 +0100 | ski | has no idea what code we're talking about, fwiw |
| 2022-02-03 20:58:13 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) (Remote host closed the connection) |
| 2022-02-03 20:58:13 +0100 | Morrow_ | (~user@bzq-110-168-31-106.red.bezeqint.net) (Remote host closed the connection) |
| 2022-02-03 20:58:31 +0100 | <janus> | ski: https://github.com/GetShopTV/swagger2/blob/master/src/Data/Swagger/Internal.hs#L473 |
| 2022-02-03 21:00:11 +0100 | <janus> | monochrom: it does compile and pass the test suite on 9.0.2 (even though CI doesn't verify that). just tested it. |
| 2022-02-03 21:00:12 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-02-03 21:00:12 +0100 | <ski> | hm, is there any raw link ? (not on a gui browser atm) |
| 2022-02-03 21:00:35 +0100 | <janus> | ski: yes: https://raw.githubusercontent.com/GetShopTV/swagger2/master/src/Data/Swagger/Internal.hs (line 473) |
| 2022-02-03 21:01:23 +0100 | <awpr> | oh, there is a type variable |
| 2022-02-03 21:01:31 +0100 | burnsidesLlama | (~burnsides@dhcp168-042.wadham.ox.ac.uk) |
| 2022-02-03 21:01:50 +0100 | <awpr> | `SwaggerKindParamOtherSchema :: SwaggerKind t` has an invisible kind variable |
| 2022-02-03 21:02:17 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480:1b88:50f:dae0:9293) (Ping timeout: 240 seconds) |
| 2022-02-03 21:02:29 +0100 | <janus> | oh, so does that mean that line 432 "deriving instance Typeable 'SwaggerKindParamOtherSchema" is incorrect? |
| 2022-02-03 21:02:59 +0100 | <janus> | because it should derive forall t? |
| 2022-02-03 21:03:28 +0100 | <awpr> | I'm not sure how far back GHC compat is supposed to go in this codebase, but on modern GHCs that declaration is redundant at best |
| 2022-02-03 21:03:50 +0100 | <janus> | oh, so you were proposing removing 429 thorugh 433? i'll try that |
| 2022-02-03 21:04:03 +0100 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) (Quit: WeeChat 3.4) |
| 2022-02-03 21:04:04 +0100 | <awpr> | I don't think it'll fix things, I think it'll have no effect |
| 2022-02-03 21:04:39 +0100 | <awpr> | a new shot in the dark: maybe 9.2 changed Typeable s.t. it needs to represent the type's kind as well, and that makes the implicit kind variables need Typeable instances too? |
| 2022-02-03 21:04:47 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 256 seconds) |
| 2022-02-03 21:05:14 +0100 | <janus> | lol , removing those lines actually worked! o_O |
| 2022-02-03 21:05:20 +0100 | <awpr> | it ... fixed it? |
| 2022-02-03 21:05:34 +0100 | <janus> | yesssss :D hähä |
| 2022-02-03 21:05:49 +0100 | <EvanR> | more code more problems |
| 2022-02-03 21:06:07 +0100 | <janus> | so ghc devs didn't think of testing it because they wouldn't have silly code like that laying around? |
| 2022-02-03 21:06:29 +0100 | kristjansson | (sid126207@tinside.irccloud.com) (Ping timeout: 256 seconds) |
| 2022-02-03 21:06:41 +0100 | Hildegunst | (~luc@80.248.12.109.rev.sfr.net) (Quit: Reconnecting) |
| 2022-02-03 21:06:42 +0100 | <awpr> | I didn't see those instances. I think it seems plausible that they would interfere with instance resolution somehow |
| 2022-02-03 21:06:46 +0100 | juhp | (~juhp@128.106.188.82) |
| 2022-02-03 21:06:53 +0100 | Hildegunst | (~luc@80.248.12.109.rev.sfr.net) |
| 2022-02-03 21:07:56 +0100 | <janus> | well i won't report a bug because i don't really know how instance deduction is supposed to work here. |
| 2022-02-03 21:08:14 +0100 | shailangsa | (~shailangs@host86-185-98-37.range86-185.btcentralplus.com) |
| 2022-02-03 21:08:17 +0100 | <janus> | but usually it is safe to remove instances, and if it compiles, nothing could have been broken |
| 2022-02-03 21:08:28 +0100 | <awpr> | with PolyKinds disabled, that might actually be `instance Typeable ('SwaggerKindSchema @Type)`, which might prevent GHC from solving other instances |
| 2022-02-03 21:08:32 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-02-03 21:08:32 +0100 | <janus> | though i suppose that assumption is not valid for this file since it has UndecidableInstances... |
| 2022-02-03 21:08:40 +0100 | Hildegunst | (~luc@80.248.12.109.rev.sfr.net) (Client Quit) |
| 2022-02-03 21:08:45 +0100 | NiKaN | (sid385034@helmsley.irccloud.com) (Ping timeout: 256 seconds) |
| 2022-02-03 21:09:33 +0100 | NiKaN | (sid385034@id-385034.helmsley.irccloud.com) |
| 2022-02-03 21:09:57 +0100 | <awpr> | it might be worth filing a bug anyway, but it's more of "I managed to make something weird and confusing happen by manually deriving Typeable instances, maybe this should be a warning or have better errors" rather than "the compiler was wrong" |
| 2022-02-03 21:10:01 +0100 | kristjansson | (sid126207@id-126207.tinside.irccloud.com) |
| 2022-02-03 21:10:11 +0100 | briandaed | (~root@109.95.143.81.r.toneticgroup.pl) |
| 2022-02-03 21:10:27 +0100 | ProofTechnique | (sid79547@ilkley.irccloud.com) (Ping timeout: 256 seconds) |
| 2022-02-03 21:10:39 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 21:11:26 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-02-03 21:11:42 +0100 | ProofTechnique | (sid79547@id-79547.ilkley.irccloud.com) |
| 2022-02-03 21:13:43 +0100 | <janus> | i'll see if i can boil it down. in any case, thanks a lot awpr! |
| 2022-02-03 21:13:47 +0100 | <janus> | (and others) |
| 2022-02-03 21:14:22 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 21:16:57 +0100 | emf | (~emf@163.114.132.7) (Ping timeout: 240 seconds) |
| 2022-02-03 21:17:02 +0100 | mcgroin | (~mcgroin@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) |
| 2022-02-03 21:20:17 +0100 | emf | (~emf@2620:10d:c090:400::5:e4c1) |
| 2022-02-03 21:21:38 +0100 | Inst | (~delicacie@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-02-03 21:24:12 +0100 | soxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) |
| 2022-02-03 21:24:46 +0100 | zincy | (~zincy@2a00:23c8:970c:4801:340a:21f3:9185:5e11) |
| 2022-02-03 21:27:38 +0100 | yauhsie__ | (~yauhsien@61-231-25-133.dynamic-ip.hinet.net) |
| 2022-02-03 21:28:46 +0100 | Feuermagier | (~Feuermagi@user/feuermagier) |
| 2022-02-03 21:28:48 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2022-02-03 21:29:22 +0100 | zincy | (~zincy@2a00:23c8:970c:4801:340a:21f3:9185:5e11) (Remote host closed the connection) |
| 2022-02-03 21:30:17 +0100 | jespada | (~jespada@87.74.36.188) (Ping timeout: 256 seconds) |
| 2022-02-03 21:30:41 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 21:30:51 +0100 | Inst | (~delicacie@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 256 seconds) |
| 2022-02-03 21:32:19 +0100 | yauhsie__ | (~yauhsien@61-231-25-133.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-02-03 21:32:56 +0100 | _ht | (~quassel@231-169-21-31.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2022-02-03 21:33:02 +0100 | jespada | (~jespada@87.74.36.188) |
| 2022-02-03 21:33:14 +0100 | meltedbrain_y2k | (~tekserf@47.61.115.91) () |
| 2022-02-03 21:35:57 +0100 | axeman | (~quassel@2a02:8109:a3c0:b10:7b68:5346:f621:6fdc) (Ping timeout: 240 seconds) |
| 2022-02-03 21:36:51 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-02-03 21:37:29 +0100 | whatsupdoc | (uid509081@id-509081.hampstead.irccloud.com) |
| 2022-02-03 21:37:29 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 21:38:10 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 21:41:35 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 21:42:31 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-02-03 21:45:12 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480::41) |
| 2022-02-03 21:49:39 +0100 | doxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) |
| 2022-02-03 21:52:37 +0100 | soxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) (Ping timeout: 256 seconds) |
| 2022-02-03 21:56:48 +0100 | alp | (~alp@user/alp) |
| 2022-02-03 21:57:16 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2022-02-03 21:57:25 +0100 | Akiva | (~Akiva@user/Akiva) (Ping timeout: 250 seconds) |
| 2022-02-03 21:57:40 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-02-03 21:58:13 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 22:01:00 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 22:02:36 +0100 | Megant | (megant@user/megant) (Ping timeout: 268 seconds) |
| 2022-02-03 22:03:29 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 256 seconds) |
| 2022-02-03 22:04:07 +0100 | burnsidesLlama | (~burnsides@dhcp168-042.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2022-02-03 22:04:13 +0100 | Megant | (megant@user/megant) |
| 2022-02-03 22:04:38 +0100 | burnsidesLlama | (~burnsides@dhcp168-042.wadham.ox.ac.uk) |
| 2022-02-03 22:05:27 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-02-03 22:07:32 +0100 | zincy | (~zincy@2a00:23c8:970c:4801:340a:21f3:9185:5e11) |
| 2022-02-03 22:08:28 +0100 | yassernasc | (~yassernas@ec2-54-87-145-249.compute-1.amazonaws.com) (Remote host closed the connection) |
| 2022-02-03 22:08:49 +0100 | burnsidesLlama | (~burnsides@dhcp168-042.wadham.ox.ac.uk) (Ping timeout: 256 seconds) |
| 2022-02-03 22:09:06 +0100 | cynomys | (~cynomys@user/cynomys) (Quit: Lost terminal) |
| 2022-02-03 22:09:57 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 256 seconds) |
| 2022-02-03 22:10:22 +0100 | fendor_ | (~fendor@178.115.38.12.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2022-02-03 22:10:22 +0100 | briandaed | (~root@109.95.143.81.r.toneticgroup.pl) (Quit: leaving) |
| 2022-02-03 22:13:33 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) (Ping timeout: 276 seconds) |
| 2022-02-03 22:13:59 +0100 | <dminuoso> | Is there a foolproof guide of broad GHC compatibility for MonadFail in such a way to not provoke warnings on any GHC? |
| 2022-02-03 22:14:09 +0100 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2022-02-03 22:14:29 +0100 | Guest83 | (~Guest83@181.229.128.244) |
| 2022-02-03 22:14:48 +0100 | <Guest83> | better compiler for beginners |
| 2022-02-03 22:15:03 +0100 | <Guest83> | ????? |
| 2022-02-03 22:16:03 +0100 | <Cale> | Guest83: GHC is really the only practical choice at the moment. |
| 2022-02-03 22:16:03 +0100 | <ski> | compiler, or implementation ? |
| 2022-02-03 22:17:05 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 256 seconds) |
| 2022-02-03 22:17:18 +0100 | <Guest83> | for install all new |
| 2022-02-03 22:17:24 +0100 | <sm> | https://code.world and https://code.world/haskell |
| 2022-02-03 22:18:53 +0100 | slack1256 | (~slack1256@186.11.100.54) (Remote host closed the connection) |
| 2022-02-03 22:18:55 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 22:20:26 +0100 | <geekosaur> | hugs is still usable if not being developed any more |
| 2022-02-03 22:21:15 +0100 | ski | . o O ( Helium ) |
| 2022-02-03 22:21:28 +0100 | <janus> | dminuoso: if you define the MonadFail on the earliest GHC with the class, and exclude the Monad(fail) definition on the earliest GHC version that warns with that defintion, that should cover it? |
| 2022-02-03 22:22:09 +0100 | <janus> | dminuoso: you need an ifdef for the import of Control.Monad.Fail too as shown in the wiki article |
| 2022-02-03 22:22:24 +0100 | jgeerds | (~jgeerds@55d4a547.access.ecotel.net) |
| 2022-02-03 22:22:24 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 22:22:51 +0100 | <dminuoso> | janus: The wiki article has some version mismatching between the specified base versions and the GHC versions in the comments |
| 2022-02-03 22:23:09 +0100 | <dminuoso> | #if !MIN_VERSION_base(4,11,0) |
| 2022-02-03 22:23:12 +0100 | <dminuoso> | -- Monad(fail) was removed in GHC 8.8.1 |
| 2022-02-03 22:23:29 +0100 | <dminuoso> | So if I read snippets like this, I get headaches. |
| 2022-02-03 22:24:05 +0100 | <dminuoso> | (In case you're not spotting it, base-4.11.0 corresponds to GHC 8.4.1) |
| 2022-02-03 22:24:30 +0100 | <janus> | oh sorry, that looks like it was my fault :O |
| 2022-02-03 22:26:06 +0100 | <ski> | Guest83 : do you have an intro text to follow ? |
| 2022-02-03 22:27:26 +0100 | <janus> | it would be clearer if the comment and the ifdef corresponded to each other |
| 2022-02-03 22:28:23 +0100 | <janus> | but there was a transitionary period where you could define fail on Monad even though MonadFail already existed. since it would be nice to have the wiki avoid suggesting code that would warn, i should find out which versions allow you to have the code with no warning |
| 2022-02-03 22:28:44 +0100 | byorgey | (~byorgey@155.138.238.211) (Quit: leaving) |
| 2022-02-03 22:29:10 +0100 | <dminuoso> | janus: Mmm, it also seems MonadFail is exported via Prelude from some GHC version on forward as well, but its not mentioned which that is. |
| 2022-02-03 22:30:00 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2022-02-03 22:30:04 +0100 | <dminuoso> | With some creativity it could be inferred that this might be the case from 8.8.1 |
| 2022-02-03 22:31:41 +0100 | <janus> | that would be surprising since the code looks like it is older than 8.8.1 (since it referred to 7.16 when it was written) |
| 2022-02-03 22:32:04 +0100 | <janus> | if you click the link to quchen's article, that is what was copied into the wiki |
| 2022-02-03 22:32:10 +0100 | <janus> | and it talks about 7.16 |
| 2022-02-03 22:32:51 +0100 | mcgroin | (~mcgroin@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Quit: WeeChat 2.8) |
| 2022-02-03 22:33:07 +0100 | <dminuoso> | Uh, so MonadFail is exported since 7.16, while 8.0 lists `Add module Control.Monad.Fail with new class MonadFail(fail)`? |
| 2022-02-03 22:33:11 +0100 | <dminuoso> | Sorry! |
| 2022-02-03 22:33:15 +0100 | <dminuoso> | Uh, so MonadFail is exported from Prelude since 7.16, while 8.0 lists `Add module Control.Monad.Fail with new class MonadFail(fail)`? |
| 2022-02-03 22:33:53 +0100 | <dminuoso> | Do you see why the article is not quite comforting? |
| 2022-02-03 22:33:57 +0100 | <janus> | 7.16 doesn't exist, it was extrapolated |
| 2022-02-03 22:33:57 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480::41) (Ping timeout: 240 seconds) |
| 2022-02-03 22:34:15 +0100 | <dminuoso> | Ah sorry |
| 2022-02-03 22:34:23 +0100 | <dminuoso> | I misinterpreted |
| 2022-02-03 22:34:38 +0100 | <janus> | the article is confusing because the comment and the ifdef refer to different versions, because of the transitionary period |
| 2022-02-03 22:35:19 +0100 | <janus> | after work i will experiment |
| 2022-02-03 22:35:28 +0100 | <janus> | and see where the warnings appear |
| 2022-02-03 22:35:44 +0100 | <dminuoso> | Dont worry, I'll gladly do this myself. |
| 2022-02-03 22:35:58 +0100 | <dminuoso> | How about this, Ill share my findings and you adjust the wiki? |
| 2022-02-03 22:36:02 +0100 | <janus> | sure |
| 2022-02-03 22:36:57 +0100 | burnsidesLlama | (~burnsides@dhcp168-042.wadham.ox.ac.uk) |
| 2022-02-03 22:39:10 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 22:40:05 +0100 | Akiva | (~Akiva@user/Akiva) |
| 2022-02-03 22:41:21 +0100 | burnsidesLlama | (~burnsides@dhcp168-042.wadham.ox.ac.uk) (Ping timeout: 256 seconds) |
| 2022-02-03 22:45:59 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 22:46:36 +0100 | dcoutts | (~duncan@82-132-232-248.dab.02.net) |
| 2022-02-03 22:46:39 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 22:46:56 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480:1b88:50f:dae0:9293) |
| 2022-02-03 22:49:10 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 22:49:32 +0100 | Midjak | (~Midjak@may53-1-78-226-116-92.fbx.proxad.net) (Read error: Connection reset by peer) |
| 2022-02-03 22:49:52 +0100 | burnsidesLlama | (~burnsides@dhcp168-042.wadham.ox.ac.uk) |
| 2022-02-03 22:50:29 +0100 | Midjak | (~Midjak@may53-1-78-226-116-92.fbx.proxad.net) |
| 2022-02-03 22:50:45 +0100 | deadmarshal | (~deadmarsh@95.38.119.14) (Ping timeout: 256 seconds) |
| 2022-02-03 22:53:12 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-02-03 22:54:45 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 22:57:18 +0100 | byorgey | (~byorgey@155.138.238.211) |
| 2022-02-03 22:58:08 +0100 | <mrianbloom> | Is it possible to write a lens that is a simple composition over the head of a non-empty list? |
| 2022-02-03 22:58:08 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 22:58:40 +0100 | <mrianbloom> | I feel like I did this a long time ago but that library has changed a lot since then. |
| 2022-02-03 22:59:22 +0100 | <dminuoso> | mrianbloom: What do you mean by "composition over"? |
| 2022-02-03 23:00:34 +0100 | <janus> | mrianbloom did you see Control.Lens.Cons which has _head (a Traversal') |
| 2022-02-03 23:01:42 +0100 | <janus> | % :t _head |
| 2022-02-03 23:01:42 +0100 | <yahb> | janus: (Cons s s a a, Applicative f) => (a -> f a) -> s -> f s |
| 2022-02-03 23:01:44 +0100 | <dminuoso> | janus: Okay I think I know what I needed. So MonadFail is also exported via Prelude since 8.8.1 which I think is noteworthy. |
| 2022-02-03 23:01:56 +0100 | <mrianbloom> | I see, this has a Maybe type though am I correct. |
| 2022-02-03 23:02:01 +0100 | <dminuoso> | Also I just conjured up the trick of conditionally doing `#ifdef ... import Prelude hiding (fail) #endif` |
| 2022-02-03 23:02:26 +0100 | <mrianbloom> | Let me write a little example of what I'm trying to do in the repl. |
| 2022-02-03 23:03:07 +0100 | <dminuoso> | janus: _head wont work on a NonEmpty |
| 2022-02-03 23:03:28 +0100 | <dminuoso> | Or does it not? |
| 2022-02-03 23:03:32 +0100 | <Cale> | :t let headNonEmpty f (x :| xs) = fmap (\x' -> x' :| xs) (f x) in headNonEmpty |
| 2022-02-03 23:03:33 +0100 | <lambdabot> | Functor f => (t -> f t) -> NonEmpty t -> f (NonEmpty t) |
| 2022-02-03 23:03:43 +0100 | <Cale> | ^^ that's a lens |
| 2022-02-03 23:03:51 +0100 | <dminuoso> | I recall some discussion that `_head` requires unconsing, but you cant do that to a NonEmpty |
| 2022-02-03 23:04:08 +0100 | <mrianbloom> | Ahh, headNotEmpty |
| 2022-02-03 23:04:09 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-02-03 23:04:18 +0100 | <mrianbloom> | Who would have thought! |
| 2022-02-03 23:04:19 +0100 | <Cale> | mrianbloom: I just implemented that, mind |
| 2022-02-03 23:04:33 +0100 | <dminuoso> | % _headNE :: Lens' (NonEmpty a) a; _headNE f (a :| as) = (:| as) <$> f a |
| 2022-02-03 23:04:33 +0100 | <yahb> | dminuoso: ; <interactive>:19:19: error:; Not in scope: type constructor or class `NonEmpty'; Perhaps you meant `NonEmptyF' (imported from Data.Functor.Base); <interactive>:19:47: error:; Not in scope: data constructor `:|'; Perhaps you meant one of these: `Seq.:<' (imported from Data.Sequence), `:<' (imported from Control.Lens), `Seq.:>' (imported from Data.Sequence) |
| 2022-02-03 23:04:40 +0100 | <dminuoso> | % import Data.List.NonEmpty |
| 2022-02-03 23:04:40 +0100 | <yahb> | dminuoso: |
| 2022-02-03 23:04:43 +0100 | <dminuoso> | % _headNE :: Lens' (NonEmpty a) a; _headNE f (a :| as) = (:| as) <$> f a |
| 2022-02-03 23:04:43 +0100 | <yahb> | dminuoso: |
| 2022-02-03 23:05:02 +0100 | <dminuoso> | Ah but it looks the same as Cale's |
| 2022-02-03 23:05:06 +0100 | <Cale> | dminuoso: that's... yeah |
| 2022-02-03 23:05:33 +0100 | <dminuoso> | An alternative trick I just found |
| 2022-02-03 23:05:41 +0100 | <dminuoso> | % _headNE = _Wrapped . _1 |
| 2022-02-03 23:05:42 +0100 | <yahb> | dminuoso: |
| 2022-02-03 23:05:45 +0100 | <Cale> | The general pattern is you deconstruct your datastructure into a function which would replace the given thing with a new value, and the new value, and then you fmap the one over f of the other. |
| 2022-02-03 23:05:49 +0100 | alx741_ | (~alx741@157.100.197.240) |
| 2022-02-03 23:05:53 +0100 | <dminuoso> | % :t _headNE |
| 2022-02-03 23:05:54 +0100 | <yahb> | dminuoso: (Rewrapped s t, Rewrapped t s, Functor f, Field1 (Unwrapped s) (Unwrapped t) a b) => (a -> f b) -> s -> f t |
| 2022-02-03 23:05:57 +0100 | <dminuoso> | Dont mind the type! |
| 2022-02-03 23:06:11 +0100 | <Cale> | er, and the value of the thing that was in the hole, rather |
| 2022-02-03 23:06:48 +0100 | <janus> | do you need to support GHCs from before the MonadFail transition got going? if you don't, you can just avoid using Prelude.fail in general. always use it qualified |
| 2022-02-03 23:06:48 +0100 | alx741 | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 23:07:07 +0100 | <dminuoso> | janus: Im using aeson. |
| 2022-02-03 23:07:19 +0100 | <dminuoso> | Im not seeing any official way to fail a parser other than `fail` |
| 2022-02-03 23:07:54 +0100 | <ski> | any `empty' or `mzero' ? |
| 2022-02-03 23:08:14 +0100 | <dminuoso> | I guess those could work as well, but they wouldnt let me produce a diagnostic at all |
| 2022-02-03 23:08:20 +0100 | <janus> | you misunderstand. Prelude may reexport Control.Monad.MonadFail and for other versions it reexports Control.Monad(Monad(fail)). that doesn't mean you need to use it |
| 2022-02-03 23:08:26 +0100 | <dminuoso> | I like giving my users at least a very rough idea why their JSON input was rejected. |
| 2022-02-03 23:08:29 +0100 | <janus> | i am just saying you don't need to have a conditional Prelude import |
| 2022-02-03 23:09:04 +0100 | <janus> | because nobody is forcing you to use fail directly from prelude, even on the oldest versions, you could use fail imported in a qualified manner, no? |
| 2022-02-03 23:09:04 +0100 | alx741_ | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 23:09:25 +0100 | <dminuoso> | Mmm, well I have to use whatever aeson is doing I guess |
| 2022-02-03 23:09:36 +0100 | <dminuoso> | So let me look at their ifdefing |
| 2022-02-03 23:10:14 +0100 | <janus> | why would you? aeson doesn't care whether you get fail through a reexport in the Prelude module or not |
| 2022-02-03 23:10:35 +0100 | jespada | (~jespada@87.74.36.188) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-02-03 23:10:48 +0100 | <dminuoso> | Huh? Because they can easily write non-coherent instances? |
| 2022-02-03 23:11:16 +0100 | <dminuoso> | The fact that they're forcing you to use `fail` in the first place is a bit concering already |
| 2022-02-03 23:12:13 +0100 | <dminuoso> | I dont know, cant wrap my head around it |
| 2022-02-03 23:12:15 +0100 | jespada | (~jespada@87.74.36.188) |
| 2022-02-03 23:12:44 +0100 | oscurochu | (~oscurochu@097-096-050-227.res.spectrum.com) |
| 2022-02-03 23:13:24 +0100 | <janus> | if aeson is written sensibly, it doesn't matter whether you call MonadFail(fail) or Monad(fail), they should do the same |
| 2022-02-03 23:13:56 +0100 | <janus> | what do you mean by non-coherent? that those two methods don't do the same? |
| 2022-02-03 23:17:54 +0100 | <dminuoso> | Yeah |
| 2022-02-03 23:19:45 +0100 | deadmarshal | (~deadmarsh@95.38.114.73) |
| 2022-02-03 23:20:52 +0100 | michalz2 | (~michalz2@185.246.204.87) (Remote host closed the connection) |
| 2022-02-03 23:20:52 +0100 | michalz | (~michalz@185.246.204.87) (Remote host closed the connection) |
| 2022-02-03 23:20:59 +0100 | <janus> | do you need to support GHC versions from before MonadFail was created? |
| 2022-02-03 23:21:22 +0100 | <dminuoso> | No, right now 8.6 to 8.10 is fine by me |
| 2022-02-03 23:22:20 +0100 | ProfSimm | (~ProfSimm@87.227.196.109) |
| 2022-02-03 23:22:25 +0100 | <janus> | well then you can just import MonadFail qualified and always call its fail. then your constraints will also require MonadFail and your haskell library consumers will have less work in the future |
| 2022-02-03 23:23:43 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2022-02-03 23:24:31 +0100 | deadmarshal | (~deadmarsh@95.38.114.73) (Ping timeout: 256 seconds) |
| 2022-02-03 23:26:03 +0100 | alx741_ | (~alx741@157.100.197.240) |
| 2022-02-03 23:26:53 +0100 | Inst | (~delicacie@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-02-03 23:28:57 +0100 | Akiva | (~Akiva@user/Akiva) (Ping timeout: 256 seconds) |
| 2022-02-03 23:29:13 +0100 | alx741_ | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 23:30:17 +0100 | Topsi | (~Tobias@dyndsl-037-138-064-017.ewe-ip-backbone.de) |
| 2022-02-03 23:34:21 +0100 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-02-03 23:34:57 +0100 | choucavalier | (~choucaval@peanutbuttervibes.com) (WeeChat 3.4) |
| 2022-02-03 23:36:57 +0100 | alp | (~alp@user/alp) (Ping timeout: 240 seconds) |
| 2022-02-03 23:39:05 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-02-03 23:43:55 +0100 | dcoutts | (~duncan@82-132-232-248.dab.02.net) (Read error: Connection reset by peer) |
| 2022-02-03 23:43:55 +0100 | sharky2 | (~bc8147f2@83.167.180.121) (Quit: CGI:IRC (Session timeout)) |
| 2022-02-03 23:45:07 +0100 | <dminuoso> | janus: And where do I import MonadFail from qualified in 8.10? |
| 2022-02-03 23:45:45 +0100 | <dminuoso> | Oh wait Control.Monad.Fail is still there, sint it |
| 2022-02-03 23:46:18 +0100 | alx741_ | (~alx741@157.100.197.240) |
| 2022-02-03 23:46:36 +0100 | <janus> | % :m +Control.Monad.Fail |
| 2022-02-03 23:46:36 +0100 | <yahb> | janus: |
| 2022-02-03 23:46:47 +0100 | <EvanR> | :t fail |
| 2022-02-03 23:46:48 +0100 | <lambdabot> | MonadFail m => String -> m a |
| 2022-02-03 23:47:17 +0100 | <EvanR> | > fail "the answer to life universe and everything" :: Maybe Int |
| 2022-02-03 23:47:19 +0100 | <lambdabot> | Nothing |
| 2022-02-03 23:47:37 +0100 | <EvanR> | awkward |
| 2022-02-03 23:48:56 +0100 | <EvanR> | > mzero :: Either String Int |
| 2022-02-03 23:48:57 +0100 | <lambdabot> | Left "" |
| 2022-02-03 23:49:05 +0100 | alx741_ | (~alx741@157.100.197.240) (Read error: Connection reset by peer) |
| 2022-02-03 23:49:14 +0100 | <dminuoso> | It's just strange that fail takes a String at all |
| 2022-02-03 23:49:34 +0100 | <dminuoso> | Doesn't quite fit the origin of it |
| 2022-02-03 23:50:39 +0100 | <monochrom> | The origin is compiler-generated error message. |
| 2022-02-03 23:51:12 +0100 | <dminuoso> | What would the compiler insert there, exactly? |
| 2022-02-03 23:51:26 +0100 | Ariakenom | (~Ariakenom@h-82-196-111-63.na.cust.bahnhof.se) (Read error: Connection reset by peer) |
| 2022-02-03 23:51:34 +0100 | <dminuoso> | % do Just x <- Nothing; pure () |
| 2022-02-03 23:51:35 +0100 | <yahb> | dminuoso: Nothing |
| 2022-02-03 23:51:36 +0100 | <monochrom> | "do { Just x <- foo }" is desugared to "foo >>= \case Nothing -> fail "inexhaustive pattern matching etc etc"" |
| 2022-02-03 23:52:09 +0100 | <EvanR> | never knew that |
| 2022-02-03 23:52:14 +0100 | <monochrom> | % do {Just x <- return Nothing; return x} :: IO Int |
| 2022-02-03 23:52:15 +0100 | <yahb> | monochrom: *** Exception: user error (Pattern match failure in do expression at <interactive>:30:5-10) |
| 2022-02-03 23:53:02 +0100 | zincy | (~zincy@2a00:23c8:970c:4801:340a:21f3:9185:5e11) (Remote host closed the connection) |
| 2022-02-03 23:53:38 +0100 | <EvanR> | User error? I beg your pardon |
| 2022-02-03 23:53:45 +0100 | azimut_ | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-02-03 23:53:49 +0100 | <monochrom> | IO's fail is error |
| 2022-02-03 23:54:04 +0100 | <monochrom> | Maybe's fail is const Nothing. Likewise for []. |
| 2022-02-03 23:54:10 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-02-03 23:54:17 +0100 | <dminuoso> | Why is IO's fail error, when you already have IO exceptions at your disposal.. |
| 2022-02-03 23:54:21 +0100 | <maerwald> | monochrom: IO's fail is an exeption |
| 2022-02-03 23:54:31 +0100 | <EvanR> | yeah, userError |
| 2022-02-03 23:54:44 +0100 | <monochrom> | Oops yeah. |
| 2022-02-03 23:54:50 +0100 | <EvanR> | it just sounds wrong out of context xD |
| 2022-02-03 23:55:13 +0100 | <EvanR> | User only used do notation fail features provided by Compiler, don't blame me |
| 2022-02-03 23:56:39 +0100 | <monochrom> | IO is probably the only one that cares about the error message. Most other MonadFail instances really just go mzero. |
| 2022-02-03 23:56:58 +0100 | azimut_ | (~azimut@gateway/tor-sasl/azimut) |
| 2022-02-03 23:57:07 +0100 | burnsidesLlama | (~burnsides@dhcp168-042.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2022-02-03 23:57:35 +0100 | burnsidesLlama | (~burnsides@dhcp168-042.wadham.ox.ac.uk) |
| 2022-02-03 23:57:42 +0100 | <janus> | and Aeson's Parser... |
| 2022-02-03 23:57:58 +0100 | <EvanR> | > do { Right x <- Left 99; return x } :: Either String Char |
| 2022-02-03 23:58:00 +0100 | <lambdabot> | error: |
| 2022-02-03 23:58:00 +0100 | <lambdabot> | • No instance for (MonadFail (Either String)) |
| 2022-02-03 23:58:00 +0100 | <lambdabot> | arising from a do statement |
| 2022-02-03 23:58:57 +0100 | <EvanR> | MonadFailed |
| 2022-02-03 23:59:41 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-02-03 23:59:41 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-02-03 23:59:41 +0100 | wroathe | (~wroathe@user/wroathe) |