< 1605659347 129434 :LKoen!~LKoen@9.253.88.92.rev.sfr.net QUIT :Quit: “It’s only logical. First you learn to talk, then you learn to think. Too bad it’s not the other way round.” < 1605659667 980346 :Melvar!~melvar@dslb-178-007-125-116.178.007.pools.vodafone-ip.de QUIT :Ping timeout: 256 seconds > 1605660694 800030 PRIVMSG #esoteric :14[[07Jasp14]]4 M10 02https://esolangs.org/w/index.php?diff=78742&oldid=40623 5* 03PythonshellDebugwindow 5* (+49) 10/* External resources */ cats and dogs < 1605661026 510771 :Melvar!~melvar@dslb-088-070-034-125.088.070.pools.vodafone-ip.de JOIN :#esoteric < 1605663118 396524 :Lord_of_Life_!~Lord@46.217.217.18 JOIN :#esoteric < 1605663185 88032 :Lord_of_Life!~Lord@46.217.219.70 QUIT :Ping timeout: 240 seconds < 1605663861 980719 :FreeFull!~freefull@defocus/sausage-lover QUIT : > 1605665440 183582 PRIVMSG #esoteric :14[[07LolKek14]]4 M10 02https://esolangs.org/w/index.php?diff=78743&oldid=74774 5* 03PythonshellDebugwindow 5* (+0) 10Correct to better match initial wording > 1605678138 852028 PRIVMSG #esoteric :14[[07NDBall14]]4 10 02https://esolangs.org/w/index.php?diff=78744&oldid=78354 5* 03Razetime 5* (+10) 10/* Interpriters */ < 1605682370 793573 :imode!~linear@unaffiliated/imode QUIT :Ping timeout: 256 seconds < 1605683454 792077 :imode!~linear@unaffiliated/imode JOIN :#esoteric < 1605683476 717774 :imode!~linear@unaffiliated/imode QUIT :Client Quit < 1605683490 983379 :imode!~linear@unaffiliated/imode JOIN :#esoteric > 1605689425 36320 PRIVMSG #esoteric :14[[07NDBall14]]4 10 02https://esolangs.org/w/index.php?diff=78745&oldid=78744 5* 03Aspwil 5* (+647) 10/* Instructions */ < 1605689645 36253 :sprocklem!~sprocklem@unaffiliated/sprocklem QUIT :Ping timeout: 240 seconds < 1605689656 469785 :Sgeo!~Sgeo@ool-18b982ad.dyn.optonline.net QUIT :Read error: Connection reset by peer < 1605690442 252057 :delta23!~deltaepsi@d179-68-39-184.evv.wideopenwest.com QUIT :Quit: Leaving < 1605691151 980537 :imode!~linear@unaffiliated/imode QUIT :Ping timeout: 256 seconds < 1605691741 418992 :sprocklem!~sprocklem@unaffiliated/sprocklem JOIN :#esoteric < 1605694023 33863 :Arcorann__!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net QUIT :Read error: Connection reset by peer < 1605695382 454586 :TheLie!~TheLie@business-24-134-17-157.pool2.vodafone-ip.de JOIN :#esoteric < 1605695700 365914 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net JOIN :#esoteric < 1605695762 525538 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net QUIT :Read error: Connection reset by peer < 1605696673 157664 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net JOIN :#esoteric < 1605697496 348431 :sprocklem!~sprocklem@unaffiliated/sprocklem QUIT :Ping timeout: 240 seconds < 1605697605 581842 :LKoen!~LKoen@169.244.88.92.rev.sfr.net JOIN :#esoteric > 1605705778 193623 PRIVMSG #esoteric :14[[07Chem14]]4 M10 02https://esolangs.org/w/index.php?diff=78746&oldid=60867 5* 03PythonshellDebugwindow 5* (+157) 10/* Hello World #2 */ catd > 1605705784 540129 PRIVMSG #esoteric :14[[07Lisparser14]]4 M10 02https://esolangs.org/w/index.php?diff=78747&oldid=78587 5* 03Hakerh400 5* (+1) 10 < 1605705881 256431 :TheLie!~TheLie@business-24-134-17-157.pool2.vodafone-ip.de QUIT :Remote host closed the connection > 1605706006 941069 PRIVMSG #esoteric :14[[07Hashes14]]4 M10 02https://esolangs.org/w/index.php?diff=78748&oldid=42652 5* 03PythonshellDebugwindow 5* (+52) 10I suppose this is a language > 1605706495 171044 PRIVMSG #esoteric :14[[07~ATH14]]4 M10 02https://esolangs.org/w/index.php?diff=78749&oldid=74934 5* 03PythonshellDebugwindow 5* (+1) 10/* Nested loops */ Add semicolon > 1605706572 587031 PRIVMSG #esoteric :14[[07~ATH14]]4 M10 02https://esolangs.org/w/index.php?diff=78750&oldid=78749 5* 03PythonshellDebugwindow 5* (-1) 10/* Examples */ remove semicolon < 1605706808 111904 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :Somehow the name of ~ATH always makes me think of the AT modem hangup command, ATH0 (or +++ATH0 in some contexts), even though I expect there really isn't a c onnection. < 1605706833 656782 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :(Just like there apparently isn't a connection between the "c" and "onnection" in "c onnection"...) < 1605708034 866470 :LKoen!~LKoen@169.244.88.92.rev.sfr.net QUIT :Quit: “It’s only logical. First you learn to talk, then you learn to think. Too bad it’s not the other way round.” < 1605709485 43519 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net QUIT :Ping timeout: 240 seconds < 1605710109 138343 :LKoen!~LKoen@169.244.88.92.rev.sfr.net JOIN :#esoteric < 1605711604 639530 :LKoen!~LKoen@169.244.88.92.rev.sfr.net QUIT :Read error: Connection reset by peer < 1605711639 500500 :LKoen!~LKoen@169.244.88.92.rev.sfr.net JOIN :#esoteric < 1605712268 376242 :Sgeo!~Sgeo@ool-18b982ad.dyn.optonline.net JOIN :#esoteric < 1605714090 277854 :TheLie!~TheLie@2a02:8106:215:3300:7285:c2ff:fe0b:917f JOIN :#esoteric < 1605717984 339005 :TheLie!~TheLie@2a02:8106:215:3300:7285:c2ff:fe0b:917f QUIT :Remote host closed the connection < 1605718102 558566 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :you know how like half a decade ago, suddenly everyone and everything called Isis started to have an unfortunate name for none of the fault of the namer, because of recent news? well a lot of things and even some people are named "Corona" or "Korona" and are now suffering the same fate. < 1605718150 548006 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :and there's not much we can do about this besides designing all systems to assume that what was a canonical name can become merely a synonym in the future. YES, I'M LOOKING AT YOU, UNICODE CHARACTER DATABASE. < 1605718645 608339 :LKoen!~LKoen@169.244.88.92.rev.sfr.net QUIT :Remote host closed the connection < 1605718984 903268 :LKoen!~LKoen@169.244.88.92.rev.sfr.net JOIN :#esoteric < 1605722404 843931 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :There are also other kind of corona viruses; the modern kind isn't the only kind. < 1605722829 714955 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :Reputedly the same happened to the given name "Adolf" back in the world war < 1605722858 471045 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :I just wish something like this would happen to one of the annoying overused names like "Athene"/"Athena" or "Széchenyi". < 1605722865 749368 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :I mean if it has to happen at all < 1605723280 39541 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Words/names can have other meanings too so they can still be used. < 1605723381 139447 :int-e!~noone@int-e.eu PRIVMSG #esoteric :fungot: do you prefer your characters singed or unsinged? < 1605723382 457224 :fungot!~fungot@unaffiliated/fizzie/bot/fungot PRIVMSG #esoteric :int-e: madam president, our debate is timely, and mrs jackson's point on amendment 12 which may change relations with turkey, we are not concerned with the serious environmental problems faced by small and medium-sized enterprises, and, finally, mr president of the fnord newspaper. i should like to thank my group, the liberals, myself included, voted for the report on monitoring the application of interim measures are quite str < 1605724018 383918 :FreeFull!~freefull@defocus/sausage-lover JOIN :#esoteric < 1605724038 64581 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :int-e: I prefer them as possibly neither, like in the C standard: eg. I think it's allowed that they compare unsigned but still cause undefined behavior on an unsigned overflow < 1605724181 98114 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :one reason why we can deal with this easily is that we can just use unsigned char or signed char everywhere that it matters, because the standard gracefully guarantees that the pointers char *, unsigned char *, signed char *, and their const versions have the same representation, so you can safely cast a char ** to an unsigned char **, not only a char * to an unsigned char *. you can't just cast a char < 1605724187 590899 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :*** to an unsigned char *** safely, but at that point you'd be using structs, and pointers to structs also all have the same representation. < 1605724196 454398 :int-e!~noone@int-e.eu PRIVMSG #esoteric :but that doesn't answer the question < 1605724213 997228 :rain1!~rain1@unaffiliated/rain1 QUIT :Quit: Leaving < 1605724238 994663 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :alas nothing is guaranteed about functions or pointers to functions, you can't even change a pointer argument to const and call it that way. < 1605724259 750424 :int-e!~noone@int-e.eu PRIVMSG #esoteric :(note the spelling) < 1605724267 347781 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :int-e: ok, in that case, I prefer if char is signed by default, but characters are unsigned < 1605724412 794000 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :oh, that reminds me < 1605724494 392145 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :zzo38: is there some way to represent for unicode characters as integers that isn't just the UCS character code, but is optimized for working with utf-8 strings so that you have to do fewer shifts when you put or get a character to/from a string? < 1605724555 614320 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :I always specify signed char or unsigned char if it matters, but sometimes I only need numbers 0 to 127 or some smaller range, so it doesn't matter. < 1605724578 510794 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :I was wondering about this because rust is specified to be able to use any representation the compiler wants for its built-in char type, and it could be something like this. it still needs to be able to convert between the UCS code and its char type, because it has "as" casts that do that. < 1605724596 26654 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :no wait, I think "as" casts don't do that < 1605724624 493109 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :so it doesn't even need those, except in some library functions that deal with utf-16 or utf-32 < 1605724639 301258 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :b_jonas: If you are limited to UTF-8-G (standard Unicode range), then you might avoid shifting by just putting the four bytes together in a 32-bit field, I suppose < 1605724643 739931 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :hmm I'm not sure, let me check < 1605724696 324252 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :(or UTF-8-M it is called, not UTF-8-G) < 1605724782 871092 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :it looks like the rust "as" operator can cast from char to UCS code point... but possibly not backwards? I don't know < 1605724813 622579 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :zzo38: something like that, but which way do you align it and what endianness do you interpret the utf-8? < 1605724839 374069 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :utf-8 is natively big-endian, but you could want to interpret it as little-endian if that's the native endianness < 1605724913 707290 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :b_jonas: I don't think it's allowed (in C) for `char` to be unsigned but cause undefined behavior on overflow. < 1605724919 353188 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :It's implementation-defined whether plain `char` is signed or unsigned, but once that choice is made (and documented, which is a requirement for implementation-defined behavior too), it's required to behave just like any other signed or unsigned type. < 1605724934 590648 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :fizzie: hmm. < 1605724938 962254 :Lord_of_Life_!~Lord@46.217.217.18 NICK :Lord_of_Life < 1605724943 749499 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Either way you will probably have to copy the individual bytes, although how you do that (and what alignment is required) may depend on the computer, I think < 1605724948 189462 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :fizzie: I'll look it up. < 1605724955 810896 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :C11 6.2.5p15: "The implementation shall define `char` to have the same range, representation, *and behavior* as either `signed char` or `unsigned char`." < 1605724984 450984 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :(It remains a distinct type, but I think the "and behavior" will also cover behavior on overflow.) < 1605725001 874295 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :ok < 1605725231 532800 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Some programs expect text to be a sequence of Unicode codepoints encoded as UTF-8, even if the text isn't Unicode. This makes it necessary to implement conversion to allow them to be stored in a format which is not invalid UTF-8. < 1605725319 451723 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :Although it's also true that `char` is not included in the category of /unsigned integer types/, and the overflow rule explicitly says "a computation involving unsigned operands", so maybe there's a little bit of ambiguity of interpretation there on what exactly "same range, representation, and behavior" means. Since it's clearly not all-encompassing, because the types are still distinct at least in < 1605725325 450705 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :terms of not being compatible types. < 1605725512 55144 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :(Some programs furthermore expect there to be no null characters, so this is also necessary to work around similarly in some cases.) < 1605725620 511006 :imode!~linear@unaffiliated/imode JOIN :#esoteric < 1605725769 947013 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :fizzie: yes, that's what I was confused about, because paragraph 9 there says "A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo [...]." < 1605725793 65694 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :so that seems like it doesn't apply to char, but then they throw in that "behaves the same" that I didn't notice < 1605725913 938599 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :zzo38: yeah. like embedding binary data into xml. it's ugly. < 1605726494 80762 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :I rather like python's solution, where it defines an extension of utf-8 that can decode any byte string to a string of "characters", in a reversible way, where 128 of the surrogates count as "characters" and python allows them in most character string operations. you can even encode those character strings to an extension of utf-16 (which can contain those 128 surrogates unpaired) and back and it's < 1605726500 87568 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :still round-trip compatible. < 1605726623 727614 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :one drawback of this is that if you want to extend this to one of those unofficial utf-8 variants with a larger range of characters possible, then the extended utf-8 encoding will be necessarily slightly incompatible with the extended utf-8 encoding for smaller range of characters. but even this is an incompatibility that isn't too ugly. < 1605726678 649598 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :the best use for this is to manipulate character strings internally only, inputting and outputting utf-8 or utf-16 etc only, to gracefully handle inputs that contain strings that are supposed to be utf-8 but aren't. < 1605727431 545728 :sprocklem!~sprocklem@unaffiliated/sprocklem JOIN :#esoteric < 1605728343 430729 :sprocklem!~sprocklem@unaffiliated/sprocklem QUIT :Ping timeout: 260 seconds < 1605728381 381805 :sprocklem!~sprocklem@unaffiliated/sprocklem JOIN :#esoteric < 1605728912 115884 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :While this is helpful if the text is expected to be Unicode text, I think that it is not a good idea in general; better would be for most things to assume data is a stream of 8-bit characters, and then have a function to reinterpret it as UTF-8 in case that is what it is. < 1605729175 135824 :deltaepsilon23!~deltaepsi@d179-68-39-184.evv.wideopenwest.com JOIN :#esoteric < 1605729190 771506 :deltaepsilon23!~deltaepsi@d179-68-39-184.evv.wideopenwest.com NICK :delta23 < 1605729333 986031 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca QUIT :Ping timeout: 256 seconds < 1605729554 792133 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca JOIN :#esoteric < 1605729904 342094 :TheLie!~TheLie@business-24-134-17-157.pool2.vodafone-ip.de JOIN :#esoteric < 1605730585 791531 :imode!~linear@unaffiliated/imode PRIVMSG #esoteric :I agree. I'm struggling to figure out whether I should add string literals to my language, or should I force users to work in lists of numbers. and if I add literals, what encoding. < 1605730696 973940 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :My own suggestion is to add string literals which are just strings of 8-bit characters. Their interpretation is up to the program; some functions may interpret them as UTF-8, but not all will. < 1605730744 282605 :imode!~linear@unaffiliated/imode PRIVMSG #esoteric :what happens when someone inserts a multibyte character into their source file, then. < 1605730784 861878 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Outside of a string literal or comment, it is an error. Inside of a string literal, it is treated as the sequence of bytes that has been entered. < 1605730822 277211 :imode!~linear@unaffiliated/imode PRIVMSG #esoteric :eh. I'm almost in favor of just forcing you to use numbers instead. < 1605732591 203808 :imode!~linear@unaffiliated/imode PRIVMSG #esoteric :the problem is that I want it to be expressive. technically nothing stops you from doing something like ( 72 101 108 108 111 44 32 119 111 114 108 100 33 ) "Hello,\sworld!" define ! < 1605732623 670274 :imode!~linear@unaffiliated/imode PRIVMSG #esoteric :but you can't write the literals directly, you'd need to define them as a symbol first. everything is a function that can be executed, even unknown symbols. < 1605732661 816481 :imode!~linear@unaffiliated/imode PRIVMSG #esoteric :all things are separated by some kind of whitespace, the brackets are actually defined in terms of repeated composition and equality. < 1605732786 526676 :imode!~linear@unaffiliated/imode PRIVMSG #esoteric :symbols by themselves don't have structure to them, and shouldn't have a structure to them. so strings should "reduce" to something smaller, like quotations of numbers. this forces you to think about encoding: what if something doesn't use UTF-8? you're going to have to do something like the above anyway. > 1605733099 869357 PRIVMSG #esoteric :14[[07Dot14]]4 M10 02https://esolangs.org/w/index.php?diff=78751&oldid=32444 5* 03PythonshellDebugwindow 5* (+24) 10/* Step-by-Step example */ feline < 1605733475 2133 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :I still think that byte strings would work. If you need to, then I suppose you might have a "utf8" command, so that after the string literal you can write utf8 and then it converts into the list of Unicode code points rather than the raw byte values, I suppose. < 1605734616 231398 :imode!~linear@unaffiliated/imode PRIVMSG #esoteric :it also means extra work for the parser. < 1605734718 314754 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Well, yes, it would have to parse string literals, just as much as, it would also have to parse numbers, comments, etc. < 1605734903 924400 :imode!~linear@unaffiliated/imode PRIVMSG #esoteric :not really. sorry, should've specified: my language is concatenative. the most I do for parsing is split on whitespace. < 1605734987 135730 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :The other way is like how Forth is doing, I suppose. < 1605735044 483418 :imode!~linear@unaffiliated/imode PRIVMSG #esoteric :yeah, define parsing words. < 1605735829 736305 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :zzo38: yes, it's only useful when the text is expected to be utf-8, but that is common. if you don't know the encoding, then you treat it as a byte string, or as iso-8859-1 encoded if you wish. < 1605735919 464144 :b_jonas!~x@catv-176-63-12-45.catv.broadband.hu PRIVMSG #esoteric :but when I work with inputs and outputs some of which are encoded utf-8 and others are encoded utf-16-le, I need to be able to read input as utf-8 so I can match strings between the two sorts of input and output it as either encoding. < 1605735993 142091 :TheLie!~TheLie@business-24-134-17-157.pool2.vodafone-ip.de QUIT :Remote host closed the connection < 1605736263 94099 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :OK < 1605738387 351701 :Lymia!lymia@magical.girl.lyrical.lymia.moe QUIT :Ping timeout: 260 seconds < 1605738441 907294 :user3456_!user3456@gateway/shell/insomnia247/x-anembnlwrgsujsgf JOIN :#esoteric < 1605738456 927723 :Lymia!lymia@magical.girl.lyrical.lymia.moe JOIN :#esoteric < 1605738492 444988 :user3456!user3456@gateway/shell/insomnia247/x-crvcpihfznovnyeh QUIT :Ping timeout: 260 seconds < 1605741285 386307 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net JOIN :#esoteric < 1605742125 45253 :delta23!~deltaepsi@d179-68-39-184.evv.wideopenwest.com QUIT :Ping timeout: 240 seconds < 1605743542 170652 :delta23!~deltaepsi@d179-68-39-184.evv.wideopenwest.com JOIN :#esoteric