00:37:54 <esowiki> [[MyScript]] M https://esolangs.org/w/index.php?diff=70772&oldid=70448 * PythonshellDebugwindow * (+44) /* Functions */
00:45:16 <esowiki> [[Symbols]] M https://esolangs.org/w/index.php?diff=70773&oldid=63960 * PythonshellDebugwindow * (+5) /* Javascript */ fixing varName
02:05:03 -!- Phantom__Hoover has joined.
03:36:15 -!- Phantom__Hoover has quit (Ping timeout: 265 seconds).
03:49:03 -!- MDude has quit (Quit: Going offline, see ya! (www.adiirc.com)).
03:56:50 <zzo38> Why does a "cure heart" decrease your health from 121 to 100?
06:32:01 <esowiki> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=70774&oldid=70689 * Luke1337 * (-362) Undo revision 53161 by [[Special:Contributions/Luke1337|Luke1337]] ([[User talk:Luke1337|talk]])
06:40:32 <esowiki> [[Aheui]] https://esolangs.org/w/index.php?diff=70775&oldid=60033 * Luke1337 * (-120) This implementation claims to "fix" bugs but diff reveals it actually doesn't; fails test case; incorrect handling of ''; inelegant wraparound handling; outdated etc.
07:10:04 -!- Phantom__Hoover has joined.
07:50:28 <b_jonas> zzo38: maybe it drains some of your general or average health to fix a problem specifically in your heart, and you should use that spell only if you have a risk of heart problems and can afford some of the health of the rest of your body, as in your liver?
07:51:41 <b_jonas> It's like many real world medications, they can't magically add health to you, but they can redirect your body to focus to something more in exchange of something else, like in the tradeoff between antibiotics vs antihistamines.
07:53:09 <b_jonas> Antibiotics can kill a bacterial infection, but in exchange you get worse allergies, so if you have both bacterial infections and allergies it's hard to cure, which is one of the big difficulty with organ transplantation.
07:57:59 -!- cpressey has joined.
08:01:25 -!- imode has quit (Ping timeout: 264 seconds).
08:04:24 <oren> neoletters has been updated with better arabic
08:09:30 <oren> it also now includes two letters from the language "poliespo" invented by a esperantist murderer
08:14:18 <oren> specifically "overstruck p and w" and "overstruck t and v"
08:14:39 <oren> encoded at and respectively
08:29:18 <esowiki> [[User:Salpynx]] https://esolangs.org/w/index.php?diff=70776&oldid=63150 * Salpynx * (+104) /* Languages I have created */ Isthmus Cyclicus Crypticus
08:38:58 <esowiki> [[Esolang talk:Community portal]] https://esolangs.org/w/index.php?diff=70777&oldid=62050 * IFcoltransG * (+292) /* (idea)Introducing SyntaxHighlight? */ Devil's advocate
08:50:31 -!- kspalaiologos has joined.
09:34:52 -!- Lord_of_Life_ has joined.
09:36:26 -!- Lord_of_Life has quit (Ping timeout: 258 seconds).
09:36:26 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
09:48:23 -!- xelxebar has quit (Ping timeout: 240 seconds).
09:56:56 -!- arseniiv_ has joined.
10:01:27 -!- MDude has joined.
10:41:20 <cpressey> For a long time I've held this conjecture: the weakest computational class in which a self-interpreter can be written, is Turing-complete.
10:42:50 <cpressey> This was based on the observation that there is no primite-recursive function which can interpret arbitrary primitive recursive functions, and other examples like that.
10:43:11 <cpressey> But I've known this is just a conjecture, and I'm very interested in counter-examples.
10:43:55 <cpressey> And I think I found one the other day but I haven't looked into it yet.
10:45:26 <cpressey> http://compilers.cs.ucla.edu/popl16/
10:45:51 <cpressey> Which claims to be an interpreter for F_omega, written in F_omega.
10:46:33 <cpressey> Now, I also understand that F_omega is strongly normalizing, which means F_omega programs always terminate, which means F_omega is *not* Turing-complete.
10:48:10 <cpressey> Although what computability class F_omega represents, I don't know. I imagine that it is at least primitive recursive, and probably beyond primitive recursive to some degree. i.e. I would not be surprised if you could write the Ackermann function in F_omega. But again, I don't really know, yet.
10:50:30 <cpressey> I don't know much about F_omega except that it's one corner of the lambda cube. Wikipedia doesn't say much about it other than "From a computing point of view, λω is extremely strong, and has been considered as a basis for programming languages", which I guess would be consistent with this result.
10:51:14 <cpressey> Oh sorry, that's lambda_omega, not F_omega
10:51:31 <cpressey> WP says even less about F_omega.
10:52:18 <cpressey> What the heck is lambda_omega anyway.
10:53:36 <cpressey> Uh, sounds like F_omega and lambda_omega could be the same thing?
10:54:55 <cpressey> I guess I should try to read the papers.
11:12:12 -!- xelxebar has joined.
11:18:36 -!- cpressey has quit (Quit: WeeChat 1.9.1).
11:23:59 -!- tromp has quit (Read error: Connection reset by peer).
11:24:13 -!- tromp has joined.
12:28:46 -!- cpressey has joined.
12:37:17 <cpressey> There is another, much older result related to that conjecture I mentioned earlier, which is this: there's a CFL that's "CFL-complete" in the sense that it's as least as complex to parse it, as it is to parse any other CFL. But I don't know if that counts as "universal" in the same sense as a self-interpreter does. It's certainly similar in some ways though.
12:39:15 <cpressey> Pretty sure that result was by Greibach in the 1970's though I can't find my notes on it atm.
12:47:53 <cpressey> Aha, found it: https://epubs.siam.org/doi/10.1137/0202025
12:50:09 <cpressey> IIRC, the CFG constructed in that paper takes a string and a description of a CFG and accepts iff the given CFG accepts the string.
12:50:43 <cpressey> Which sounds like a "universal CFG" to me.
12:56:18 <HackEso> olist 1199: shachaf oerjan Sgeo FireFly boily nortti b_jonas
12:57:48 -!- rain1 has joined.
13:14:51 -!- kiedtl has quit (Quit: Leaving).
13:17:04 -!- xelxebar has quit (Remote host closed the connection).
13:18:00 -!- xelxebar has joined.
13:20:36 <esowiki> [[EGSHEL]] M https://esolangs.org/w/index.php?diff=70778&oldid=68935 * LegionMammal978 * (-10) fixed link
13:22:17 <tromp> int-e: I think I properly fixed the proof for the generalized W rule, see latest commit
13:38:31 <esowiki> [[ESOPUNK]] M https://esolangs.org/w/index.php?diff=70779&oldid=58027 * LegionMammal978 * (+2) /* Interpreters */ updated link
13:44:49 -!- ais523 has joined.
13:45:06 <ais523> <cpressey> For a long time I've held this conjecture: the weakest computational class in which a self-interpreter can be written, is Turing-complete. ← what about "the language where all programs do nothing"? that can self-interpret
13:45:11 -!- kritixilithos has joined.
13:45:14 <ais523> and has a very weak computational class
13:45:24 <ais523> I think the question needs to be formulated more precisely, but am not sure how
13:45:58 -!- birdt has joined.
13:47:05 <int-e> Nah that's probably just false... there seems nothing in a self-interpreter that makes a language more expressive than it already is.
13:47:16 <int-e> (You can add it as a primitive if all else fails.)
13:47:44 <esowiki> [[ETalk]] M https://esolangs.org/w/index.php?diff=70780&oldid=13379 * LegionMammal978 * (+14) fixed title
13:48:03 -!- birdt has quit (Quit: Fucking off.).
13:48:30 <ais523> ah right, "weak language + self-interpreting primitive" makes for another good counterexample
13:49:03 <ais523> I was also going to mention things like Easy but I think that's naturally TC
13:49:16 <ais523> given that it embeds BF
13:51:44 <int-e> I'm not saying it's not an interesting question though. Also the question of what adding self-interpretation does to a model of computation may be interesting, too. For example, it seems that PR (primitive recursion) + interpreter for PR (with a sane encoding for functions that can be manipulated with primitive recursive functions) goes beyond PR (because it escapes the leveling restriction).
13:53:18 <HackEso> olist is update notification for the webcomic Order of the Stick. http://www.giantitp.com/comics/ootslatest.html
13:53:57 <int-e> (Actually, if we call that PR'... PR' is not obviously capable of self-interpretation. I suspect it's not...)
13:55:00 <int-e> kspalaiologos: there's a few of those
13:55:52 <HackEso> Update notification for the webcomic Homestuck.
13:55:56 <HackEso> Non-update notification for the webcomic Super Mega.
13:56:06 <HackEso> FireFlist* \ aglist* \ bardsworthlist* \ bobadventureslist* \ calesyta2016list* \ danddreclist* \ don'taskdon'ttelllist@ \ dontaskdonttelllist* \ ehlist* \ emptylist* \ erflist* \ flist* \ idealist* \ ioccclist* \ keenlist* \ list* \ listen* \ listlist* \ llist* \ makelist* \ makelistlist* \ minimalist* \ mlist* \ olist* \ pbflist* \ slist* \ smlist* \ stylist* \ testlist* \ xkcdwhatiflist* \ ysaclist*
13:56:18 <HackEso> listlistlist? No such file or directory
13:56:52 <int-e> `? calesyta2016list
13:56:53 <HackEso> calesyta2016list? ¯\(°_o)/¯
13:57:00 <int-e> this one can probably be removed :P
13:57:31 <HackEso> hbrl? No such file or directory
13:57:40 <int-e> `hurl ../bin/mlist
13:57:41 <HackEso> https://hack.esolangs.org/repo/log/tip/bin/mlist
13:59:37 <cpressey> int-e: in "the language where all programs do nothing", all programs are self-interpreters. You could add "non-trivial" to exclude this.
14:01:25 <int-e> "mlist" is obscure... https://esolangs.org/logs/2013-03-03.html#lRj ... I don't get it.
14:01:48 <int-e> cpressey: ais523 made that point; I actually made it non-trivial.
14:01:53 <cpressey> And much like how we can forbid "cheating quines" like 10 LIST 10 in BASIC, we can forbid any language that has a "self-interpret instruction".
14:02:15 <int-e> that's hard though
14:02:29 <cpressey> Any language where you have a self-interpret instruction, but it's not *obviously* a self-interpret instruction, is fair game
14:03:41 <cpressey> int-e: I was alluding to the technical meaning of "non-trivial" like it's used in Rice's theorem, but yes, ok, whatever, it's not important
14:04:01 <int-e> There's a huge spectrum between strange machines that accidentally can interpret your language to something like a bytecode interpreter to interpreting the language itself.
14:04:54 <int-e> Arguably you want to draw the line between the first two categories, and that seems to be very hard to capture formally to me.
14:05:18 <cpressey> I'd be interested to know what languages F_omega can and can't recognize
14:05:54 <cpressey> It must be more than PR, but less than RE
14:06:15 <int-e> (I should probably know this)
14:06:33 <int-e> eg https://en.wikipedia.org/wiki/System_F#System_F%CF%89
14:08:07 <cpressey> Ah, there's also an implementation of Coq in Coq, which (assuming it's legit and not cheating somehow) suggests a similar thing might stand for that other corner of the lambda cube
14:10:28 <b_jonas> cpressey: in "http://www.madore.org/~david/weblog/d.2017-08-18.2460.html" the article that defines the (0) esolang, David Madore explains how you should define "self-interpreter" in a language that can't self-interpret in a traditional sense, like one that has only the power of primitive recursive
14:11:48 <b_jonas> in particular, if you restrict (0) to integer inputs, it's exactly as powerful as primitive recursive (BLoop), but he needs more generality than that there
14:13:37 <b_jonas> namely he wants to know what the easiest way is to prove that certain of those languages are equipowerful, and their computational complexity isn't as well known as the primitive recursive or the turing complete thing, and the only proof he knows is a really difficult one via such a full interpreter, which is annoying
14:21:48 <int-e> cpressey: Does it show that though? You'd have to check what kind of axioms the formalization uses.
14:25:57 <cpressey> int-e: That's what I meant by "assuming it's legit". I was in fact assuming it was invoking some kind of cheat, until I came across the F_omega self-interpreter paper - now I'm not so sure.
14:26:54 <cpressey> Well, I'm not convinced the F_omega thing isn't cheating somehow too. But I really just need to sit down and read it.
14:28:49 -!- rain1 has quit (Quit: Lost terminal).
14:38:36 <cpressey> int-e: Wait though. Say you have an interpreter for language L, and L is in computational class C. Then you add a self-interpret instruction to L to obtain L'. L' might no longer be in computational class C. So you haven't shown anything about computational class C by doing this.
14:39:02 <cpressey> (This is in response to your "That's probably just false".)
14:39:10 <int-e> Been down that path (see PR' above)
14:39:47 <int-e> Obviously the self-interpreter should take itself into account. This /may/ push it into RE territory.
14:40:31 <int-e> (because at least naively it involves some sort of fixed point)
14:41:14 <cpressey> OK, yes. I was thinking "add to L an instruction that interprets L programs", that's not quite the same thing
14:42:02 <int-e> Yes, there are lots of knobs to tweak here.
14:47:24 <esowiki> [[Element]] M https://esolangs.org/w/index.php?diff=70781&oldid=69991 * LegionMammal978 * (-20) /* Interpreter */ fixed link
14:56:08 -!- MDude has quit (Ping timeout: 258 seconds).
14:56:26 -!- MDude has joined.
15:05:23 <ais523> I find it hard to see how Coq could self-interpret, assuming it's consistent
15:05:35 <ais523> if it's consistent it can't typecheck itself, thus it can't prove a Coq program is total
15:05:51 <ais523> this means that you can't prove that the self-interpreter itself exits, so the program as a whole won't typecheck
15:07:41 <int-e> isn't type checking still decidable
15:08:27 <ais523> int-e: yes, but you need something more powerful than the CoC itself to decide it
15:08:44 <b_jonas> ais523: see above, there's an alternate definition for self-interpreter that works for self-interpreters in languages like BLoop
15:08:59 <esowiki> [[Asm2bf]] https://esolangs.org/w/index.php?diff=70782&oldid=70106 * Palaiologos * (+540) up-to-date stuff
15:09:26 <ais523> b_jonas: I'm really slow at reading French though
15:09:28 <b_jonas> ais523: basically you define a function that takes a program and a number, and the function interprets the program except it stops after as many steps as that number
15:09:33 <ais523> and need to look up words sometimes
15:09:46 <ais523> b_jonas: ah right, the "run this program for this many steps" function
15:09:52 <ais523> that's much easier to implement than a true self-interpreter
15:10:17 <int-e> Hmm, do the inductive definitions add power?
15:10:20 <ais523> kspalaiologos: aren't there six general-purpose registers now?
15:10:30 <ais523> the article still says four, and then names six of them
15:10:55 -!- arseniiv has joined.
15:11:02 <esowiki> [[Asm2bf]] https://esolangs.org/w/index.php?diff=70783&oldid=70782 * Palaiologos * (-1)
15:11:09 <ais523> it's OK, I just thought I'd let you know the mistake while you're around to fix it
15:11:34 <ais523> a long time ago I was writing my own asm-for-BF, and a gcc backend to targe it
15:11:45 <ais523> but the code has been lost, I think, due to gcc being too large to fit in my backups
15:11:54 <ais523> also I remember I stalled trying to find a good multiplication algorithm
15:12:23 <ais523> the ISA was very bf-specific, it contained instructions like tadd x, y (which sets x to x + y and y to 0)
15:12:38 <kspalaiologos> also I've made a c=>brainfuck compiler before supporting C89, but it outputs too big binaries to be reasonable
15:12:41 <ais523> and the stack pointer was magical
15:12:44 -!- arseniiv_ has quit (Ping timeout: 265 seconds).
15:13:05 <ais523> anyway, gcc wasn't as flexible as I wanted, it made too many assumptions which weren't correct in a BF context
15:13:20 <ais523> kspalaiologos: I think you do if you want to work with gcc's backend
15:13:27 <ais523> it's quite hard to get pre-existing C compilers to implement recursion without one
15:13:36 <ais523> (even though it is of course theoretically possible, they just aren't set up to use alternative methods)
15:13:44 <kspalaiologos> outputs simple yet beautifully small 8086 assembly
15:14:11 <kspalaiologos> so you can like do [sp-5] to get 5th element from the top
15:14:12 <ais523> oh, the stack pointer as a non-accessible register
15:14:14 <ais523> I think I did it like that too
15:14:36 <ais523> I had 64 general-purpose registers because general-purpose registers are cheap in BF
15:14:47 <ais523> (I was targeting a BF interpreter that used RLE optimization internally)
15:14:58 <kspalaiologos> I've split the memory into permagen with registers and temps, stack of definable size and peek/poke taperam
15:15:24 <kspalaiologos> now I'm working on general fixes involving infrastructure to make it more welcoming to beginners (although there aren't any)
15:15:39 <ais523> my split was GP registers, followed by interleaved stack and heap and temps
15:15:57 <ais523> (most of the temps were for navigational purposes, to remember where you were when moving between GP registers and stack/heap)
15:15:58 <kspalaiologos> my stack and taperam are actually separate from each other
15:16:17 <kspalaiologos> as far as I remember my permagen is just 20 brainfuck cells big
15:16:37 <kspalaiologos> and soon I plan on creating a virtual machine that would hint the brainfuck interpreter about the assembly code so you can debug asm2bf eaisly and test your programs
15:17:00 <ais523> I vaguely remember a point in the code where I multiplied something by 128 to determine whether it was odd or even
15:17:06 <ais523> so I assume I was targetting 8-bit wrapping
15:17:24 <kspalaiologos> my ISA assumes 16-bit cells, but it runs just fine on smaller cells aswell
15:17:52 <kspalaiologos> because it becomes a bit hairy if you run an 8bit interpreter, because you can index just 256b of taperam
15:18:25 <kspalaiologos> but I've got a bconv program that translated 16-bit compiliant bf code to 8bit compiliant one
15:18:28 <ais523> I used multiple consecutive cells to hold addresses
15:18:32 <ais523> just like real CPUs do
15:18:49 <kspalaiologos> ^ we don't use segment:offset adressing since 90's :p
15:19:18 <ais523> well, we still use multiple consecutive bytes to hold our 64-bit addresses
15:19:18 <esowiki> [[RarVM]] M https://esolangs.org/w/index.php?diff=70784&oldid=68928 * LegionMammal978 * (+14) fixed title
15:19:33 <ais523> hmm, now I'm wondering what the fastest algorithm to seek to a cell by number is
15:20:04 <ais523> you'd want to drag the number with you rather than going back each time to decrement it
15:20:12 -!- imode has joined.
15:20:36 <kspalaiologos> but I'll make a VM that will execute these programs faster
15:20:50 <kspalaiologos> so it doesn't bother me at all, because it works as brainfuck and VM is just a performance perk
15:21:03 <kspalaiologos> the same will go with my to-malbolge-private-compiler-suite
15:22:24 <ais523> another thing I've been thinking about is SSA compilation of counter machines (including balanced parts of brainfuck programs)
15:22:27 <ais523> or arguably "decompilation"
15:22:47 <kspalaiologos> but never got to creating such a tool to perform this
15:23:09 <kspalaiologos> because I laid a lot of requirements (like the brainfuck to 2/3 register counter machine compiler)
15:23:43 <ais523> I started, but got stuck because I didn't have clear enough rules for what was allowed to refer to what and what changed in the PHI nodes
15:24:01 <ais523> http://nethack4.org/pastebin/ssapmmn.tar.gz if you (or anyone else) is interested
15:24:18 <ais523> kspalaiologos: well, the point of SSA is that nothing ever changes, you create new variables rather than overwriting old ones
15:24:31 <ais523> but if the program contains any loops, at some point you have to overwrite an old variable with a new value
15:24:37 <ais523> because you only have finitely many
15:24:58 <ais523> and a phi node is one of the tricks used to do that, it defines a variable to mean one of two different things depending on the history of the code's control flow
15:25:17 <kspalaiologos> how do you want to analize the control flow history
15:25:28 <ais523> I don't think I understand it well enough to implement it correctly :-D
15:26:10 <ais523> but if you view things at the asm level, it's as simple as putting a phi node at a goto target and checking to see whether you got there via goto or via falling into it
15:26:22 <kspalaiologos> also I wonder is there a C interpreter for rle-based brainfuck already
15:26:31 <ais523> there are loads, I think
15:26:38 <kspalaiologos> because rn I'm decompressing the code and then running it but it's stupid very
15:26:42 <ais523> the problem being that there are /so many/ BF interpreters that finding the right one is hard
15:27:29 <ais523> you could probably just modify a BF Joust interpreter, RLE is part of the spec in BF Joust (although timing is also part of the spec so they will loop over RLEd sections one command at a time)
15:27:41 <ais523> the bigger problem would be finding an optimizing interpreter that takes RLE as input
15:30:42 <ais523> I've been meaning at some point to redo SSAPMMN but with more rigorous rules for how the internal asm-like format works, and accepting languages like BF, The Waterfall Model, etc., not just PMMN
15:50:50 <b_jonas> ais523: Bill Buzbee's retargeting a C compiler to Magic-1 is like that. Magic-1 has an accumulator instr set, sort of like 6502, so he lied to the compiler that there are 8 gp registers, but those are actually in memory
15:50:58 <b_jonas> http://www.homebrewcpu.com/
15:51:43 <b_jonas> only Magic-1 does not have zero-page addressing
15:51:53 <esowiki> [[EnilKode]] https://esolangs.org/w/index.php?diff=70785&oldid=69288 * EnilKoder * (-41)
15:58:40 <kspalaiologos> when implementing Subleq to Brainfuck translator/interpreter (yes)
16:11:01 -!- diverger has quit (Ping timeout: 264 seconds).
16:13:27 -!- diverger has joined.
16:23:39 -!- Phantom__Hoover has quit (Ping timeout: 260 seconds).
16:41:08 -!- cpressey has quit (Quit: WeeChat 1.9.1).
16:56:03 -!- xelxebar has quit (Write error: Connection reset by peer).
16:56:49 -!- xelxebar has joined.
17:12:03 -!- xelxebar has quit (Ping timeout: 240 seconds).
17:14:01 -!- xelxebar has joined.
17:28:37 -!- tromp has quit (Ping timeout: 260 seconds).
17:29:39 -!- tromp has joined.
17:58:25 -!- sprocklem has quit (Ping timeout: 264 seconds).
17:59:37 -!- sprocklem has joined.
17:59:39 <esowiki> [[First.go]] M https://esolangs.org/w/index.php?diff=70786&oldid=55956 * LegionMammal978 * (+14) fixed title
18:05:22 <int-e> tromp: https://int-e.eu/~bf3/AIT/ is what I've been playing with (Kolmogorov complexity with open (self-delimited) inputs). The equivalent of pairup is 853 bits at the moment; I think that's not too bad compared to the 657.
18:06:37 <int-e> tromp: I'll look at the proof over the weekend. I think I want to have a look at the April Ponder This challenge first.
18:10:05 <tromp> i should look at that Ponder too
18:15:00 -!- FreeFull has quit (Quit: reboting).
18:17:20 <int-e> tromp: you might enjoy https://int-e.eu/~bf3/AIT/I1_c.lam which is a 71 bit length function (which is a bit shorter than what I've found in the AIT repo).
18:50:29 -!- ARCUN has joined.
18:54:45 <esowiki> [[FuckbeEs]] M https://esolangs.org/w/index.php?diff=70787&oldid=53228 * LegionMammal978 * (+14) fixed title
19:02:43 -!- noomy has changed nick to MoonyTheDwarf.
19:03:05 -!- kmc has changed nick to kmcallister.
19:03:07 -!- kmcallister has changed nick to kmc.
19:03:07 -!- MoonyTheDwarf has changed nick to noomy.
19:05:02 <ais523> b_jonas: if the registers are actually in memory, why not have lots of them? register spills are a disaster in such an architecture because you're copying things from one memory location to another for no good reason
19:05:22 <ais523> and providing additional registers in such an architecture is very cheap
19:05:51 <ais523> in RLE'd BF, providing additional registers is actually free because seeking to a fixed address has a constant cost regardless of the distance
19:06:06 <kspalaiologos> I mean if you're keen on making zillions of registers, then go ahead and index the whole tape
19:06:16 <kspalaiologos> but remember that you need a stack and taperam going
19:06:57 <ais523> if the memory addresses have fixed locations on the tape then that's fine
19:07:04 <ais523> but I don't see a reason why they necessarily would
19:07:23 <kspalaiologos> and if you're feeling eccentric enough, they can be nested
19:07:50 <ais523> I think I can see an argument for a zero-register construction
19:08:05 <ais523> I can't see an argument for a construction that has a number of general-purpose registers that's greater than zero, but small, though
19:08:45 <kspalaiologos> and I think it's surely enough, at least for the time being
19:08:58 <kspalaiologos> I'm sure I'll extend it the later day, but remember that RLE'd brainfuck ain't a standard
19:09:16 <kspalaiologos> I've gone exactly through the same mindset as you, so my C compiler produces a 12MB brainfuck binary :v)
19:09:32 <kspalaiologos> *"binary" <- not a binary actually, just the output file
19:10:09 <kspalaiologos> I plan on adding a register or two for effective adresses
19:10:17 <kspalaiologos> and a couple of registers for the floating point operations
19:11:01 <ais523> how do you implement multiplication, btw? just a repeated addition loop?
19:11:14 <ais523> part of my motivation for using an 8-bit tape was to prevent operations like that being very slow
19:11:38 <ais523> right, that looks like a repeated addition loop to me
19:11:44 <ais523> I felt that that wouldn't have the sort of performance I wanted
19:11:53 <kspalaiologos> what more do you want, I doubt one can do something about it
19:12:05 <kspalaiologos> and if it's actually possible to do that in a better way
19:12:39 <ais523> I'm not sure you can do something about it, either
19:12:48 <ais523> this is the point at which I gave up on my C-to-BF compiler
19:12:55 <ais523> because i couldn't find a solution to this that I was satisfied with
19:13:22 <ais523> ofc, optimizing BF compilers will recognise that sort of multiply and optimize it out anyway
19:13:30 <ais523> so maybe it isn't a real issue in practice
19:14:25 <spruit11> Anyone here who could support an arxiv submission of an Egel paper of mine?
19:14:30 <ais523> why can't I worry about BF performance?
19:14:51 <ais523> spruit11: oerjan is the first name that comes to mind, but isn't here at the moment
19:15:14 <ais523> of course, it would rather depend on how eso the paper was
19:15:32 <ais523> fizzie might be able to? not sure
19:15:39 <kspalaiologos> I mean - brainfuck isn't the best language for writing at least mildly performant applications in it's pure form
19:15:49 <kspalaiologos> and to do something more interesting and fast you have to extend it
19:16:00 <ais523> kspalaiologos: I see programming as communication, you're trying to tell a computer (or another human) what you mean
19:16:04 <spruit11> @tell oerjan Could, or would, you be so kind to support an arxiv submission of a paper I wrote?
19:16:34 <ais523> and that allows for optimization at both ends of the computation, both for the person writing it, and for the computer understanding it
19:16:58 <ais523> BF is a particularly simple form of programming, but a fully general one, so getting humans to be able to express ideas more efficiently, and computers to be able to understand and run them more efficiently, seems valuable
19:17:29 <ais523> I care about OISCs too!
19:17:44 <kspalaiologos> I used to have a very similliar mindset on programming back in the day
19:17:53 <ais523> actually, most of the esolangs I care about are either a) simpler than BF in some senses, or else b) particularly interesting ways of conveying information about what you mean
19:18:47 <ais523> Brachylog is one of my favourite languages
19:19:03 <ais523> it gets further than most languages at allowing you to express the problem, rather than having to describe a solution to it
19:19:59 <ais523> right, given a description of the problem, it attempts to determine a solution to it without being explicitly told an algorithm
19:20:04 -!- ARCUN has quit (Remote host closed the connection).
19:20:09 <ais523> it isn't perfect at doing this, but it's better than most non-esolangs and almost all esolangs
19:20:27 <ais523> this has made it a particularly good language for programming competitions
19:20:43 <ais523> normal Prolog is also pretty good at this, but it's rather low-level
19:20:58 <ais523> and you often have to pay attention to how it works internally to make your programs work
19:21:29 <ais523> yes, Brachylog incorporates at least one (a constraint solver for integer arithmetic)
19:21:37 <kspalaiologos> that not necessairly make the engine create an O(N^N^N^N^N^N) solution
19:21:37 <ais523> also, its standard library just understands more concepts
19:21:48 <ais523> oh, performance is, of course, a huge issue when doing this sort of thing :-D
19:22:39 <HackEso> 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 \ true.
19:22:47 <kspalaiologos> because I'm starting to find the potential for this
19:22:49 <ais523> the thing is, Brachylog already knows what a factorial is
19:23:08 <kspalaiologos> man, for example one could solve like logical riddles or something like that using prolog
19:23:31 <kspalaiologos> and it would be ten times more amazing if it fit on my TI-83+
19:23:58 <HackEso> 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 \ true.
19:24:07 <ais523> there, that's without using the builtin
19:24:17 <ais523> "product of all the numbers from 1 to 100 inclusive"
19:24:59 <ais523> `! brachylog ⟦₁×93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000&w
19:25:10 <ais523> see, you can't do /that/ from the definition in most languages
19:25:16 <ais523> and the performance still seemed to be pretty good
19:25:26 <ais523> `! brachylog ⟦₁×93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000001&w
19:25:32 <ais523> just curious as to whether it realises that's impossible
19:25:39 <kspalaiologos> can you write a program that calculates factorial of 1,000 and displays how many digits does it have?
19:25:40 <ais523> this is one of the biggest problems with Brachylog
19:26:39 <ais523> I'm basically 100% sure it actually calculated every digit, then counted them
19:26:46 <ais523> rather than doing anything to optimize the calculation
19:27:29 <ais523> Brachylog's biggest downside is that it the algorithms it uses look only locally, it knows what it's doing for each individual command in the program but looks at them in order and doesn't handle any sort of long-range optimization
19:28:51 <ais523> the syntax takes a bit of getting used to, too, but that's common with esolangs
19:29:19 <kspalaiologos> Brachylog: Real time: 1.940 s C: Real time: 0.286 s
19:29:36 <kspalaiologos> I mean that's understandable that it took around 10 times more time
19:30:01 <ais523> what bignum library is the C program using?
19:30:05 <ais523> I'd expect that to dominate the time
19:30:23 <ais523> oh, then the C program is probably just calculating the low 32/64 bits
19:30:25 <kspalaiologos> I just wrote a tiny multiplication algorithm over char array
19:30:38 <ais523> ah, so a handrolled bignum library
19:31:50 <ais523> anyway, it's clear to me that a "more intelligent" brachylog-alike could realise that 100!+1 is not the factorial of any number (e.g. by realising the factorial function is increasing)
19:32:20 <ais523> but our current declarative languages aren't up to the task of realising that and will keep brute-forcing possibilities for ever larger numbers forever
19:32:25 <kspalaiologos> I'd train an AI to solve these riddles for me because it's more probable
19:32:45 <ais523> hmm, /isn't/ this training an AI to solve riddles for you, in a way?
19:33:14 <kspalaiologos> also the AI has been trained manually by prolog developers
19:33:37 <esowiki> [[Special:Log/newusers]] create * Galapagos * New user account
19:33:50 <ais523> there's a difference between strong AI, which figures things out itself from training data
19:34:00 <ais523> and weak AI which has more things hardcoded and is more specialised to one particular job
19:35:11 <kspalaiologos> but never got around to learning it, because the sources are a bit uncomprehendable
19:35:23 <kspalaiologos> and even if the sources, there was no one to learn me it
19:35:37 <ais523> well, CS theory is my job
19:35:43 <ais523> but it's a very big field, and I'm only interested in parts of it
19:36:06 <HackEso> 1280) <ais523> hmm, I just remembered that I was formally trained to tune harps
19:36:17 <ais523> kspalaiologos: I was formally trained to tune harps, that doesn't mean it's my current job (or indeed that I've ever done it for money)
19:36:29 <ais523> it's more just a random fact
19:37:14 <esowiki> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=70788&oldid=70774 * Galapagos * (+254) /* Introductions */
19:37:24 <ais523> in my case, it's more like monetising my esolang knowledge
19:37:33 <ais523> when a CS researcher comes up with an idea for a new style of programming
19:37:38 <ais523> they need someone to test it out and see if it could work
19:37:57 <ais523> and, well, there aren't that many people who are up for programming in newly invented languages, especially if they have to implement the language too
19:38:09 <kspalaiologos> so you're essentially a guinea pig for CS researchers?
19:38:20 <ais523> right, or was; my current job's drifted away a bit from that
19:38:29 <kspalaiologos> one can't write Brainfuck-based casino software forever :p
19:38:55 <HackEso> kspalaiologos is a brainfuck addict and a late night Perl hacker. He's secretly disassembling brainfuck code for a casino that lost the source code. Apparently knows the secret of Malbolge.
19:39:09 <ais523> hmm, this implies that the casino compiled to BF
19:39:14 <ais523> which seems like an odd thing to do
19:39:26 <ais523> (otherwise, their BF code would /be/ the source code)
19:40:25 <ais523> I love the idea that BF is fulfilling a similar role in industry as BANCStar
19:40:41 <ais523> or I should say "commerce", casinos aren't very industrial
19:41:07 <ais523> it's basically a (really terrible) bytecode format that was used as the backend for some sort of commercial GUI program
19:41:19 <ais523> but the frontend that compiled to it was bad enough that people started programming in BANCStar directly
19:41:39 <ais523> it's generally considered one of the worst programming languages to exist, other than ones which were intentionally created as bad (maybe even then, because it has less of an excuse)
19:41:58 <ais523> the issue is that because it was a commercial product, nobody seems quite clear on the specs
19:42:05 <ais523> it is way worse than COBOL or JavaScript
19:42:32 <ais523> https://esolangs.org/wiki/BANCStar
19:43:50 <ais523> <Wikipedia> BANCStar is a specialist computer programming language for financial applications.[citation needed] The language is an internal language for the National Financial Computer Services, Inc (later Broadway & Seymour) BANCStar application, which is software to automate the operations of a bank branch
19:45:08 <ais523> actually, BANCStar was the name of the software written in it, but became attached to the language itself somehow
19:45:21 <ais523> the language itself was originally called "screen code" but it isn't a very memorable or searchable name
19:45:43 <ais523> it was intended to write user interfaces for banks, we don't know all that much beyond that though
19:46:21 <zzo38> Some things have been figured out by looking at the existing programs, although some things are unknown, and some people (including myself) disagree about the ideas of what some of the commands are supposed to mean.
19:47:01 <ais523> I mean, it makes /slightly/ more sense as a bytecode format than a programming language, but it's clearly terribly designed for either role
19:48:19 <ais523> anyway, your casino programmer probably compiled to BF in the hope that the casino wouldn't then be able to fire them
19:48:25 <ais523> because nobody would be able to do anything with the resulting code
19:48:39 <kspalaiologos> they wanted to have a Brainfuck or Malbolge solution
19:48:46 <ais523> so maybe BANCStar has a similar purpose? it looks like the sort of thing that would only be created by a large collaboration though
19:49:03 <ais523> I would think using BF or Malbolge would be security through obscurity more than anything else
19:49:25 <ais523> raw uncommented BF isn't that much harder to understand than raw uncommented machine code
19:50:09 <zzo38> I think BANCStar was legitimate, and may have been originally designed to write the code directly but the designer decided it wasn't very good for that purpose and so made the screen generator instead and then never documented the code.
19:50:39 <zzo38> (Of course I don't know, so, I just guess.)
19:50:40 <kspalaiologos> would there be a person willing to reverse enginner it?
19:50:46 <kmc> what's this about a casino using bf?
19:51:00 <ais523> kspalaiologos: there are definitely people who would try just for the challenge, I'm not sure how far they'd get before giving up
19:51:11 <ais523> note that I believe that Malbolge is considerably easier to read than it is to write
19:51:36 <ais523> because the hardest part in Malbolge is making everything fit together so that it's encryption-stable and keeping control of the C and D pointers
19:51:45 <ais523> and a reader doesn't have to do that, only a writer
19:52:20 <kspalaiologos> a decent safe malbolge program would be around 10MB
19:52:36 <ais523> most of it would be no-ops, though, wouldn't it?
19:52:54 <ais523> or, well, you can't put a stable no-op everywhere
19:53:11 <ais523> so I guess much of it is code that doesn't do anything but is not obviously a no-op
19:53:26 <kspalaiologos> we need to distinguish malbolge code and a bit optimized malbolge code
19:54:39 <ais523> that's a good point, though, distinguishing padding from useful code is going to be hard without prior knowledge of which is which
19:56:02 <kspalaiologos> you can view some malbolge samples and get a taste of this
19:56:11 <kspalaiologos> https://github.com/KrzysztofSzewczyk/codegolf-submissions
19:56:20 <ais523> I haven't found a good environment for reading Malbolge yet
19:56:33 <ais523> raw Malbolge is hard to read, normalized Malbolge doesn't contain all the information you'd need and doesn't really help much
19:58:49 <ais523> anyway, something like https://github.com/KrzysztofSzewczyk/codegolf-submissions/blob/master/60106.mb, I can tell that it's pretty NOP-heavy even without normalizing
19:59:34 <ais523> also, that appears to be not Malbolge, but rather HTML-escaped Malbolge
20:00:00 -!- kritixilithos has quit (Remote host closed the connection).
20:00:07 <ais523> but not everywhere, some lines aren't escaped
20:00:38 <ais523> now I'm curious as to how that happened
20:02:13 <ais523> they aren't long slides
20:02:24 <ais523> more, you have 20 commands in a row and perhaps 14/15 of them are nops
20:02:48 <ais523> I think, at least, it's a pain working out which of the 8 sequences a given reverse-ASCII sequence is
20:03:09 <ais523> I must be one of the few people who tries to sightread Malbolge, and it's mostly just to confirm it as Malbolge and get a feeling of the shape of the code
20:03:26 <ais523> I haven't gotten very far programming in it, I mostly just help beginners on Stack Overflow
20:03:37 <kspalaiologos> you help beginners program malbolge on stackoverflow
20:03:49 <ais523> (the idea is to fix whatever misconception they had that was making them think it was easier than it actually is, then they give up)
20:04:00 -!- kspalaiologos has quit (Quit: Leaving).
20:04:23 <zzo38> My guess is that command 3100 in BANCStar means that if the condition isn't true then it is an error and you have to rekey the input.
20:04:45 <zzo38> (This guess is based on how the command is used in the known programs.)
20:05:32 <ais523> zzo38: I'm just intrigued that BANCStar manages to be /so/ horrible it drives a brainfuck and Malbolge developer away in horror
20:06:00 <ais523> although I guess neither brainfuck nor Malbolge was designed to be a bad language (although neither was BANCStar…)
20:06:09 <ais523> Malbolge was designed to be hard to program in, which is different from being bad
20:06:29 <ais523> I forget the exact goal brainfuck was optimizing for, but it was something related to size or simplicity
20:07:11 <tromp> int-e: I read your AIT notes. excellent research! your note say that I1_f uses KO(t|s) but I guess you mean KO(t|s*) ?
20:08:04 <int-e> tromp: KO(t|u) is defined in terms of u^* just like Chaitin does.
20:08:32 <tromp> the main advantage of my KP is that such a thm with KP(t|s) instead of KP(t|s*) would be rather trivial. Ah, Ok. I thought it better to make the * explicit
20:09:03 <int-e> Which is a bit awkward, but it is what makes the other direction of the symmetry of information tick.
20:09:31 -!- Bowserinator has changed nick to Rutherfordium.
20:09:35 -!- Rutherfordium has changed nick to Bowserinator.
20:09:36 <tromp> an implicit * is just too confusing though
20:09:52 <int-e> As I said, I'm just following Chaitin there.
20:09:59 <tromp> and doesn't allow you to express the simple version
20:10:37 <int-e> I might change it. Maybe.
20:10:39 <tromp> i know, but I think this is one place where Chaitin should not be followed:)
20:11:19 <esowiki> [[PlusOrMinus 2]] M https://esolangs.org/w/index.php?diff=70789&oldid=70768 * PythonshellDebugwindow * (+50) /* Commands */ output
20:11:57 <tromp> I quite like your KO version too. But I'm not ready to replace KP with it. Maybe they should live side by side:-)
20:12:41 <tromp> you will get a different halting probability. a simpler one. so that is one point in favor of yours
20:13:17 <int-e> Chaitin's u^* is a bit of a red herring actually... what is essential for the second part of the symmetry of information is knowing both H(u) and u.
20:13:51 <int-e> (Because H(u) gives you a baseline for the probability P(u))
20:16:18 <tromp> btw, in a fit of optimism (about @w correctness and my manual proofs) I added BB(33) and BB(34) to OEIS
20:16:32 <ais523> what's the OEIS sequence number?
20:16:51 <ais523> ah, found it, http://oeis.org/A333479
20:16:52 <tromp> https://oeis.org/A333479
20:19:04 <ais523> that sequence grows surprisingly slowly
20:19:22 <ais523> at least to start with
20:19:33 <tromp> I suspect BB(35) = 38127987424941
20:19:34 <ais523> being a busy beaver sequence, it won't be long before it grows at rates too fast to comprehend or describe
20:19:56 <ais523> ah, that's more like it :-D
20:20:18 <ais523> what function is being approximately computed? or is it not easy to tell?
20:20:28 <ais523> most small busy beaver numbers "summarize" well
20:20:30 <tromp> we have BB(53) being an exponential tower with well over 256 levels
20:20:50 <ais523> `` printf "%x" 38127987424941
20:21:20 <int-e> tromp: Hmm, are you collecting those lower bounds somewhere?
20:21:50 <tromp> the math overflow has some, and this one I added as note in my OEIS draft
20:23:27 <ais523> ah right, I associated that wrong
20:23:47 <tromp> size(church_n) = 5*n+6
20:24:32 <int-e> Ah, 3^3^3, of course.
20:24:46 <ais523> brachylog isn't very good at reassociating things
20:24:56 <ais523> and I keep getting , versus ; versus : confused
20:25:20 <ais523> `! brachylog 3^₂₇×₅+₆w
20:25:40 <int-e> `` dc <<<'3dd^^5*6+p'
20:25:45 <ais523> fwiw, I figured out there was a pattern from the hexadecimal
20:26:12 <ais523> it looked a lot like it was something multiplied by 5, based on what digits resulted
20:26:16 <int-e> `` dc <<<'16o3dd^^5*6+p'
20:26:18 <ais523> `` printf "%x" $((38127987424941/5))
20:26:39 <ais523> although I'm not sure that helped, now it just looks random :-D
20:27:21 <int-e> I had an advantage... I already knew the 5n+6 part.
20:28:21 <tromp> 3-powers are bound to look random in binary:(
20:29:30 <ais523> 2-powers seemed likely to show up before 3-powers, perhaps not though
20:30:19 <ais523> anyway, on another topic: what does the fastest possible FizzBuzz look like?
20:30:37 <ais523> I have a suspicion that you might not generate it in order
20:30:54 <ais523> (the aim here is to output the longest FizzBuzz sequence you can in, say, 1 second or 10 seconds)
20:31:03 <tromp> yes, BB(4) corresponds to 2^2^2^2
20:32:16 <ais523> ah right, and that isn't on OEIS yet
20:32:34 <ais523> 65536 is possibly the non-small number that most commonly appears in busy beavers
20:32:52 <ais523> because there are a lot of different ways to construct it and it thus appears in a lot of different fast-growing sequences
20:32:54 <tromp> pretty awesome to have two consecutive comprehensible busy beaver numbers
20:33:38 <tromp> they're awaiting approval
20:34:00 <int-e> Well there's https://oeis.org/draft/A333479
20:35:09 <int-e> So we can see what you're doing if we want to :)
20:35:43 <int-e> Oh apparently that link format is not easily discoverable without an OEIS account.
20:42:53 <tromp> TMs describable in 35 bits only reach a busy beaver value of 13 :-(
20:44:59 <tromp> and those describable in 46 bits likely reach only 4098
20:45:57 <int-e> TMs are awkward to program
20:46:13 <tromp> a brainfuck busy beaver would struggle similarly
20:46:17 <ais523> by contrast, Brachylog reaches a program whose halting status is unknown in 24 bits
20:46:54 <tromp> sounds worthy of a blog post!
20:47:19 <ais523> https://codegolf.stackexchange.com/questions/97004/does-the-code-terminate/177438#177438
20:47:44 <int-e> I mean, if you look at how we program TMs in practice, the number of states is a fair measure of program size. There's a lot of messy behavior outside the fragment we actually have a chance of understanding well enough for actual programming.
20:47:51 -!- ArthurStrong has joined.
20:48:48 <int-e> BLC also has a lot of garbage programs, of course, but the programmable fragment feels bigger.
20:49:54 <int-e> I can compute 0.291652 now, time for bed.
20:50:10 <ais523> golfing languages aim to maximise the size of the programmable fragment, more or less by definition, so you'd expect them to hit unknown BB values faster
20:50:17 <esowiki> [[PlusOrMinus 2]] M https://esolangs.org/w/index.php?diff=70790&oldid=70789 * PythonshellDebugwindow * (+0) /* Examples */
20:51:07 <ais523> this particular program is weird, though, it's using string operators on numbers and generates the Smarandache sequence
20:51:34 <ais523> which is a weird sequence because every element checked so far is composite, even though there doesn't seem to be any particular reason why it should be
20:53:37 <ais523> someone did a busy-beaver-like search in number theory, too, and the simplest statement that neither they nor their program could prove true or false was "there are infinitely many prime numbers of the form x²-2"
20:54:18 <int-e> (the number 0.291652 is from http://www.research.ibm.com/haifa/ponderthis/challenges/April2020.html )
20:54:23 <ais523> but that can't easily be converted into a program that searches for a counterexample, you'd need a proof both ways
20:58:02 <tromp> that statement seems no simpler than goldbach's conjecture
21:00:24 <ais523> tromp: simpler in terms of the number of primitives needed to express it in the language they were using
21:01:06 <tromp> they were able to prove it could not be expressed more concisely?
21:01:22 <tromp> or maybe just by best effort?
21:01:41 <tromp> what language was that?
21:03:48 -!- mra90 has joined.
21:03:52 <tromp> must be a language with universal and existential quantifiers...
21:16:20 -!- ski has joined.
21:22:51 <ais523> tromp: peano arithmetic with universal and existential quantifiers
21:23:14 <ais523> the brute-force search found a few statements that were all effectively equivalent to each other
21:23:23 <ais523> and there was nothing simpler that couldn't be easily proven true or false
21:34:50 <esowiki> [[Special:Log/newusers]] create * Hdjensofjfnen * New user account
21:36:20 <esowiki> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=70791&oldid=70788 * Hdjensofjfnen * (+158)
21:37:48 -!- Cale has quit (Remote host closed the connection).
21:37:55 -!- Lord_of_Life_ has joined.
21:38:10 -!- Lord_of_Life has quit (Ping timeout: 256 seconds).
21:38:20 -!- ArthurStrong has quit (Quit: leaving).
21:39:09 <esowiki> [[Truth-machine]] https://esolangs.org/w/index.php?diff=70792&oldid=70741 * Hdjensofjfnen * (+28)
21:39:13 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
21:47:41 <esowiki> [[Truth-machine]] https://esolangs.org/w/index.php?diff=70793&oldid=70792 * Hdjensofjfnen * (+43) /* Hexagony */
22:15:47 -!- FreeFull has joined.
22:22:44 -!- Cale has joined.
22:38:01 -!- arseniiv has quit (Ping timeout: 264 seconds).
22:50:23 <esowiki> [[Talk:INTERCAL]] https://esolangs.org/w/index.php?diff=70794&oldid=35649 * Ais523 * (+287) /* Binary operators */ this actually happened
23:07:39 -!- Bowserinator has quit (Quit: Blame iczero something happened).
23:07:42 -!- noomy has quit (Quit: Bye!).
23:07:46 -!- wlp1s1 has quit (Excess Flood).
23:09:49 -!- Bowserinator has joined.
23:10:04 -!- moony has joined.
23:10:33 -!- iczero has joined.
23:12:15 -!- iczero has quit (Excess Flood).
23:13:28 -!- iczero has joined.
23:29:36 -!- kspalaiologos has joined.
23:30:27 <kspalaiologos> I've been interrupted three times now so the second has became around 3 hours
23:31:09 <kspalaiologos> They had three very interesting topic though so I couldn't resist
23:31:30 <kspalaiologos> Wrecking 1300's in chess, chernobyl disaster and my mental health
23:31:48 -!- tromp has quit (Remote host closed the connection).
23:47:22 -!- kspalaiologos has quit (Ping timeout: 256 seconds).
23:50:31 -!- ais523 has quit (Quit: sorry for my connection).
23:50:45 -!- ais523 has joined.
23:55:32 <esowiki> [[User:JonoCode9374]] https://esolangs.org/w/index.php?diff=70795&oldid=70766 * JonoCode9374 * (+20) /* Languages I like */