< 1697241602 259384 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net QUIT :Client Quit < 1697241753 646 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :gah, FortyTwo was here and gone before I noticed < 1697241761 613136 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net JOIN #esolangs * :[https://web.libera.chat] FortyTwoBB < 1697241764 477710 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hi FortyTwoBB < 1697241769 559409 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :https://esolangs.org/wiki/Flooding_Waterfall_Model < 1697241776 276030 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :hi apparently flooding is TC? < 1697241778 586631 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yep < 1697241785 579734 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :how does that work? < 1697241792 585898 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can't meaningfully store data in the quantity of tokens, but you can store it in the amount of damage marked on them < 1697241808 146682 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :because that is fantastic news < 1697241829 448396 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there's a summary on the wiki page, and I wrote a compiler into Flooding Waterfall Model (and an interpreter for the language) to make sure it worked < 1697241835 484792 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :oh? but the damage is done the same very tick? < 1697241840 516687 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :every* < 1697241845 167780 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it depends on when the first token was made < 1697241852 940088 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because when the oldest token dies, they all die < 1697241876 686862 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so, if you have say 1000 tokens, the tokens die 1000 ticks after the first token was made < 1697241889 362 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and by changing the timing of the first token you can store information, even though the number of tokens is fixed < 1697241965 881838 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :ok? but you can only create tokens when others die, so being a few ticks earlier or later is not easy to control right? < 1697241980 339629 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it does need controlling, but it wasn't too bad to control it < 1697241988 391242 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there are two basic ideas < 1697242013 118890 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one is that we split the creature types into two groups, and alternate between the two groups: most of the time, either all the tokens belong to one group or all the tokens belong to the other < 1697242043 729907 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(so each creature type spends a lot of time with no creatures at all, other than the one used for halting) < 1697242072 327170 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :sure < 1697242085 306104 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if we have, say, one Ape makes two Beasts, and one Beast makes three Cats, then the fact that a group empties means that the number of tokens of any given type is always known – it's just a linear equation, so we have a recurrence relation < 1697242136 367344 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :call one change from one group to the other a "cycle" < 1697242140 658623 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :yeah a cycle of linked types making each other < 1697242163 991587 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :because the apes need to be made from something < 1697242165 138490 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :then, the number of tokens of any given type can be made to be some constant b, to the power of the number of cycles, plus a number that follows a repeating pattern from one cycle to the next < 1697242236 207722 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the way you do that is to have some "baseline" types which follow a very simple pattern (e.g. you always have one more Ouphe than Homarid), and use those to build up more complicated patterns < 1697242257 107280 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and for the baseline types, the timing of the tokens doesn't matter, it's set up so that they always finish changing over after the other types do < 1697242284 827076 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :now, for the non-baseline types, they are created either from baseline types or from each other, and we can make those follow a known pattern in quantity < 1697242319 867454 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because we know how much are created from each other (the quantity is always known) and can use baseline types to adjust the quantity (e.g. if we want to increase the amount by one, we add one more Ouphe creating them and one less Homarid) < 1697242332 683558 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so, our program can make the quantities change in a pattern < 1697242344 812595 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and the quantity determines the time period between the first token being created and the tokens dying < 1697242380 361302 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so, we can effectively do arithmetic on these time moments, death time = creation time + X where we choose the value of X < 1697242398 491570 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :hmm < 1697242408 238543 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but, if two different non-baseline creature types each create the same creature type, then only the first one counts for the creation time < 1697242431 894596 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which makes it possible to do conditionals, because it in effect gives a minimum operator < 1697242496 287236 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :because they would get swept into the cycle < 1697242521 329960 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the details are in the comments here: http://nethack4.org/esolangs/waterfall-to-flooding-waterfall.pl < 1697242544 54790 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :yeah i have that open and am swapping back and forth < 1697242639 713290 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the one complexity is that there are a few cases where a creature needs to create another of the same group – that produces a sort of "sharp edge" transition that's used to handle control flow in the program being implemented (I implemented regular Waterfall Model, so this is control flow and the zeroing triggers) < 1697242674 410736 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but, there's never a loop within a group, and each cycle uses exponentially more tokens than the cycle before, so the groups still alternate as intended < 1697242705 150525 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm glad my message got through to the thread, anyway – I don't have a Twitch account and couldn't find a reliable way to send the message < 1697242734 984715 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :yeah its silly the channels of communication < 1697242736 875602 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Reddit has become surprisingly broken since it imploded, there were technical issues sending it (and, I gather from the thread, receiving it) < 1697242841 222484 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :so basically there's cycles like A->B->C->D->A and X->Y->Z->X with one like Z->C link? < 1697242892 891461 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :no, it's more like all of A,B,C create all of X,Y,Z with like one A->B link < 1697242911 366252 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the trick is to deal with the "token creation time" and "token quantity" parts of it separately < 1697242927 340624 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because once the first token has been created, you can add more and it doesn't change the amount of damage marked on the first token < 1697242947 175023 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :as long as you create all the tokens before the first one dies, the timing of the later ones doesn't matter < 1697243047 366754 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in more detail, the types are in two groups A and B, each of which is divided into baseline and non-baseline types < 1697243057 965631 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :well adding more tokens effectively is the same as making fewer tokens later < 1697243066 976194 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :baseline A types create baseline B types and vice versa, the timing doesn't hugely matter and the quantity follows a very simple pattern < 1697243071 989394 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :except for the magnitude of the resulting flood < 1697243097 729231 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the flood magnitudes are controlled to follow a simple pattern < 1697243118 389200 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the baseline loop basically works to "top up" each token type to the flood magnitude required < 1697243155 656251 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and then there's a separate loop, where non-baseline A types create non-baseline B types and vice versa, and baseline A also creates non-baseline B and baseline B also creates non-baseline A in order to get the quantities right (but doesn't affect the timing) < 1697243211 816981 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :btw, I used the term "velocity" in the proof to talk about the size of a flood, because it's the distance between the position of the flood of one type and the flood of the types it initially creates < 1697243221 107656 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :so like for one clock always being 1 higher than the other, that i can see being done with initial conditions, and having a copied column in the program < 1697243263 855020 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yep, you get into that position using initial conditions, and then ensure it always remains true throughout the program < 1697243275 371819 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :except for a little 2x2 identity matrix at their intersection so the larger one can actually trigger? < 1697243310 319842 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the actual baseline setup used in the proof is to have one "negative baseline", one "neutral baseline", and n "positive baselines" where n is the number of counters in the emulated program < 1697243327 442174 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :negative baseline has quantity 1 below neutral; one of the positive baseline counters has quantity 1 above neutral, the others are equal < 1697243361 176927 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and the positives are connected in a sort of twisted loop, so that which positive baseline counter it is that has the higher quantity changes every large cycle (from one group to the other and back) < 1697243440 975702 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :once you have that, you can make the quantities of a counter follow any pattern you like (with repeat length n) via varying how many tokens are created by which of the baselines < 1697243468 896233 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :e.g. say you want the quantities to multiply by 1000 every cycle, and the zeroing triggers from non-baseline counters add up to 5 floods < 1697243492 520504 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you need 95 from the baselines, and to control the exact quantity, you can choose how many of those 95 are from negative, how many from neutral, how many from each of the positives < 1697243510 965310 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :err, 995, not 95 < 1697243514 681536 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :yeah < 1697243523 310057 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and the new velocity wlil end up as 1000 times the old one plus a constant, and you can choose the constant < 1697243547 632458 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and make it vary in any pattern with a repeat length of n < 1697243672 611881 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :This is one of those times where having a vastly more inefficient computation method will actually make the resulting function grow much much faster lol. < 1697243685 40912 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if you want to try out the compiler, it can be run online at tio.run/#perl (you can copy-and-paste the compiler into the "program" box and write the program to compile in the "input" box) < 1697243705 528844 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :FortyTwoBB: well, it's just one exponential slower than the original Waterfall Model, and uses a lot more counters < 1697243744 827356 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :as such I think the resulting function probably grows more slowly, at least with this construction – you would get a faster-growing function in the original by writing the same program with fewer counters, then using the remaining counters to do an exponentiation < 1697243784 239395 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it still fits well within creature type limits though < 1697243811 606284 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :yeah but we also get to have another card in the deck < 1697243828 663990 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :because we dont need dralnu's crusade anymore < 1697243864 483564 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and I get to have another sideboard card in my competitive Turing-complete deck < 1697243874 211002 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :yeah < 1697243893 294015 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :trying to make the deck Turing-complete still seems to damage competitive chances somewhat, though < 1697243929 395136 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the decks which can naturally reach states which let you do anything tend to either a) care about their sideboard a lot or b) have no way to access it, forcing you to dilute the maindeck < 1697243943 681490 :craigo!~craigo@user/craigo QUIT :Remote host closed the connection < 1697243965 609007 :craigo!~craigo@user/craigo JOIN #esolangs craigo :realname < 1697244123 656514 :craigo!~craigo@user/craigo QUIT :Remote host closed the connection < 1697244186 782284 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the creature type usage seems to be 6 flooding counters per original counter, plus 8 flooding counters, plus 1 halt type, plus some way to get into the desired starting state (which in this construction requires additional creature types – as an alternative you could start with damage marked on some of the creatures, or toughness reductions on them) < 1697244196 104096 :craigo!~craigo@user/craigo JOIN #esolangs craigo :realname < 1697244201 512675 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but there's enough room to fit, say, a Spiral Rise interpreter < 1697244257 987671 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :yeah theres like 270 types now < 1697244261 427542 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :I'm trying to remember what architectures have interesting memory ordering quirks. < 1697244278 863047 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, in addition to the link to the wiki, have a link to this conversation: https://logs.esolangs.org/libera-esolangs/2023-10-14.html#ld (would be a good thing to post in the MTG Salvation thread) < 1697244290 818572 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :The two examples I always think of are: POWER doesn't necessarily have multicopy atomicity; Alpha has the split-cache issue with data dependencies. < 1697244331 429327 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :But I think I'm forgetting other wacky behaviors (I vaguely remember there was some SPARC-specific thing?). < 1697244391 880905 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :shachaf: I find architectures with more guarantees more difficult because it's hard to remember exactly what is and isn't guaranteed < 1697244443 163430 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like, why does x86 have the SFENCE instruction? normally the memory ordering guarantees make that a no-op, but its existence implies that there are cases where it does something < 1697244444 504068 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :yeah im posting it, and I did try the complier and it made a reasonable looking output < 1697244478 881325 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :I think SFENCE is relevant for non-temporal store visibility. < 1697244497 930001 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :shachaf: but only if you want to overwrite it with another store? it doesn't give store/load ordering < 1697244502 293538 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you need MFENCE for that < 1697244524 221445 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :I don't think it's particularly about overwriting it. < 1697244542 241607 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :It certainly doesn't give store-load ordering or flush the store buffer or anything like that. < 1697244562 90516 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :FortyTwoBB: by the way, thanks to all of you in the MTG Salvation thread for working on this – the Turing-completeness construction is so much neater and simpler than when I started working on this < 1697244591 382337 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :so that makes me hopeful for things to work out. I'll need to check some more but you haven't made a mistake so far and this looks good. < 1697244599 808273 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :But in the classic example where you do store_nt(a, ...); store_nt(b, ...); store(is_ready_flag, true); , I think you need SFENCE to guarantee that if the flag store is visible, so are the a and b stores. < 1697244614 808865 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :(Whereas for regular stores on x86 that behavior is guaranteed, of course.) < 1697244626 749943 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :shachaf: ah right, to pair with an LFENCE on some other processor < 1697244656 56857 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :no thank you! i bashed my head against this and though it was game over for it when the damage doubling version was not TC. < 1697244665 590244 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :I guess you only ned the LFENCE if you have a non-temporal load, too? < 1697244677 187430 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :I've never used LFENCE. < 1697244683 483110 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :regular reads can be reordered by the processor < 1697244698 290512 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if you read memory location X, then read memory location Y, then Y can be given an older value than the value you just read from X < 1697244700 916428 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :On x86 all regular loads behave like load-acquire. < 1697244710 192400 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :no < 1697244713 399412 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :And all regular stores behave like store-release. < 1697244718 762565 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :regular stores are release, but regular loads are relaxed < 1697244728 690348 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so you need to use lfence a lot in multithreaded code < 1697244758 843356 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :FortyTwoBB: I was so worried about making mistakes < 1697244770 793007 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :I don't think that's true. < 1697244771 562763 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I wasn't confident this was right until I had the Flooding Waterfall Model interpreter actually running programs < 1697244795 406148 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :E.g. https://godbolt.org/z/brfjbEKEx < 1697244863 62475 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1697244877 755861 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :Yeah if this works it solves our layers problem and shaves a cardslot < 1697244886 469965 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 255 seconds < 1697244929 208256 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Ah, https://stackoverflow.com/a/50780314 says that even the use I mentioned isn't necessary: < 1697244932 591125 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :"_mm_lfence is almost never useful as an actual load fence. Loads can only be weakly ordered when loading from WC (Write-Combining) memory regions, like video ram. Even movntdqa (_mm_stream_load_si128) is still strongly ordered on normal (WB = write-back) memory, and doesn't do anything to reduce cache pollution." < 1697244942 586996 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 NICK :Lord_of_Life < 1697244987 38204 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net PRIVMSG #esolangs :Well I'll need to take some time to go over this, but it looks very very good. < 1697245027 865986 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :shachaf: I was testing on godbolt too, you seem to be right < 1697245052 533829 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :…this means that I have been using a lot more fences than necessary in my x86 code! < 1697245242 428124 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :now I'm wondering how out-of-order execution even works, if it isn't allowed to reorder the loads – presumably it tries to keep all the values it's working with in exclusive cache so that it knows they haven't been written by other processors, and just remembers whether it's written them itself < 1697245263 928826 :FortyTwoBB!~FortyTwoB@97-120-159-76.ptld.qwest.net QUIT :Quit: Client closed < 1697245639 236130 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, I am dreading the technical issues that will happen the *next* time I try to get in contact with the MTG Busy Beaver time, this time was bad enough… < 1697245721 474216 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :ais523: My vague understanding is that it's pretty speculative. < 1697245763 130162 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :So it can maybe reorder some loads speculatively and verify later that it turns out to be OK. < 1697245768 536621 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :But I don't really know the details at all. < 1697245772 797163 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh right, you do a speculative load out of order, then check whether it was correct when you retire < 1697245789 178850 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and end up with a whole load of timing-based sidechannels that end up leaking kernel internals and causing huge security issues < 1697245837 634739 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I probably knew that at some point < 1697245858 855001 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :How does this work, though? Say you have "load A; load B;", and B is in your cache but A isn't. You speculatively do the B load while waiting for A. < 1697245897 79954 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :How can you tell when you get A whether you need to reload B? < 1697245923 229043 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :don't you just throw away all your speculative effort when retiring the "reload B" instruction? > 1697245937 14005 PRIVMSG #esolangs :14[[07^!14]]4 10 02https://esolangs.org/w/index.php?diff=117886&oldid=117824 5* 03Ninesquared81 5* (+432) 10/* Examples */ < 1697245947 387733 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like, the sequence is dispatch load A → dispatch load B → calculation based on B → calculation based on A → retire load A → retire load B < 1697245997 479077 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :by the time you retire the load of B, a) you know whether B has changed since you dispatched the load, b) nothing that was based on B has actually affected memory yet < 1697246015 789125 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so one simple solution would be to just flush the pipeline, although I suspect actual processors have some faster way to recover < 1697246036 230249 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* when retiring the "load B" instruction < 1697246046 572284 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Hmm, I'm probably confused. < 1697246063 680309 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :My concern is that another core did "store A; store B", and e.g. was preempted between the two stores. < 1697246069 864335 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Uh, wait. < 1697246075 747182 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :It does "store B; store A", oops. < 1697246082 471215 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Sorry, I was thinking complete nonsense. < 1697246117 902862 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, the general pattern is store B; sfence; store A on one processor, and load A; lfence; load B on the other (delete fences if you have a processor that doesn't need them) < 1697246124 884850 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Yep. < 1697246156 599412 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :OK, when you ignore my nonsense this makes sense. < 1697246164 253406 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :You just need to retire in order. < 1697246187 99018 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which x86(-64) does, of course < 1697246207 895950 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although, this conversation has made me realise why retiring load instructions is important < 1697246425 371433 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :There's nothing like this for stores, right? < 1697246432 604242 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :You just need to flush the store buffer in FIFO order. < 1697246528 478824 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :stores are confusing because they happen at the retire, so the execution units don't have to do anything special at all – all the complexity is in how the cache works < 1697246628 2695 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :At retire they just go in the store buffer, not the cache, I assume, right? < 1697246635 418339 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes < 1697246651 245644 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :some quick searching implies that this is the primary reason why mfence is not a no-op on x86 < 1697246662 622961 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Yes, that's my understanding. < 1697246662 825693 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because a load from cache can cross a store that's still in the store buffer < 1697246700 86867 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Still in another core's store buffer, specifically. < 1697246713 28621 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, processors know which addresses they've stored to < 1697246725 825369 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :The classic store-load ordering thing -- you do "store-load" and you want the load to only happen after the store is globally visible. < 1697246743 778376 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :So you need cross-core communication to happen between the store and the load. < 1697246759 231683 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Whereas for store-store, load-load, and load-store, you don't need that. < 1697246976 381478 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Ah, https://stackoverflow.com/a/62480523 describes this. < 1697246985 846063 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Uh, describes the memory order mis-speculation thing. < 1697246994 278168 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :And it says there's a performance counter for it? < 1697247080 446004 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there are a huge number of performance counters, not all of which have obvious meanings < 1697247092 158892 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is the sort of thing that I'd definitely expect to have a performance counter < 1697247118 871119 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :But it doesn't say what it's called and I'm trying to find it. < 1697247141 555141 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :is it machine_clears.memory_ordering? < 1697247145 137110 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or is that something else? < 1697247162 49125 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Oh, it's probably https://perfmon-events.intel.com/index.html?pltfrm=icelake.html&evnt=MACHINE_CLEARS.MEMORY_ORDERING < 1697247166 95745 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Yep, I think so. < 1697249657 827227 :chiselfuse!~chiselfus@user/chiselfuse QUIT :Ping timeout: 252 seconds < 1697249774 738435 :chiselfuse!~chiselfus@user/chiselfuse JOIN #esolangs chiselfuse :chiselfuse < 1697249781 911843 :chiselfuse!~chiselfus@user/chiselfuse QUIT :Remote host closed the connection < 1697250089 726629 :chiselfuse!~chiselfus@user/chiselfuse JOIN #esolangs chiselfuse :chiselfuse > 1697254859 964950 PRIVMSG #esolangs :14[[07^!14]]4 10 02https://esolangs.org/w/index.php?diff=117887&oldid=117886 5* 03Ninesquared81 5* (+564) 10/* Examples */ < 1697256091 329733 :Noisytoot!~noisytoot@sourcehut/user/noisytoot QUIT :Ping timeout: 264 seconds < 1697256261 438305 :ais523!~ais523@user/ais523 QUIT :Quit: quit < 1697256380 466907 :Noisytoot!~noisytoot@sourcehut/user/noisytoot JOIN #esolangs Noisytoot :Ron > 1697260026 8411 PRIVMSG #esolangs :14[[07Trampolines14]]4 10 02https://esolangs.org/w/index.php?diff=117888&oldid=117261 5* 03Aadenboy 5* (+406) 10fixed velocities for trampolines, and added pipes again > 1697260960 775122 PRIVMSG #esolangs :14[[07Trampolines14]]4 M10 02https://esolangs.org/w/index.php?diff=117889&oldid=117888 5* 03Aadenboy 5* (+1) 10stack based not cell based < 1697261858 889161 :awewsomegamer!~awewsomeg@S0106484bd46b6d3d.vn.shawcable.net JOIN #esolangs * :awewsomegamer < 1697261953 558080 :awewsomegamer!~awewsomeg@S0106484bd46b6d3d.vn.shawcable.net QUIT :Client Quit > 1697267178 210762 PRIVMSG #esolangs :14[[07Capsule14]]4 10 02https://esolangs.org/w/index.php?diff=117890&oldid=109094 5* 03Leol22 5* (+76) 10 > 1697267330 190759 PRIVMSG #esolangs :14[[07Language list14]]4 M10 02https://esolangs.org/w/index.php?diff=117891&oldid=117757 5* 03Leol22 5* (+14) 10 > 1697268758 608798 PRIVMSG #esolangs :14[[07Special:Log/upload14]]4 upload10 02 5* 03Aadenboy 5* 10uploaded "[[02File:Text BABA 0.webp10]]": BABA text from Baba is You > 1697271656 844632 PRIVMSG #esolangs :14[[07Baba Is You14]]4 10 02https://esolangs.org/w/index.php?diff=117893&oldid=88244 5* 03Aadenboy 5* (-6706) 10completely overhauled the page :P < 1697273398 617322 :Europe2048!~Europe204@fableness-hydrant.volia.net JOIN #esolangs * :[https://web.libera.chat] Europe2048 < 1697273408 158445 :Europe2048!~Europe204@fableness-hydrant.volia.net PRIVMSG #esolangs :Hi everyone! < 1697274452 609620 :craigo!~craigo@user/craigo QUIT :Quit: Leaving < 1697275938 807759 :Koen!~Koen@2a01:e34:ec7c:30:5510:320f:787:e9f6 JOIN #esolangs * :Koen < 1697278981 359003 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer > 1697279195 798632 PRIVMSG #esolangs :14[[07Talk:Nice14]]4 10 02https://esolangs.org/w/index.php?diff=117894&oldid=117879 5* 03None1 5* (+182) 10Content on this wiki must be public domain or equivalent > 1697279335 561191 PRIVMSG #esolangs :14[[07Talk:Nice14]]4 10 02https://esolangs.org/w/index.php?diff=117895&oldid=117894 5* 03None1 5* (+181) 10 > 1697279363 867629 PRIVMSG #esolangs :14[[07Talk:Nice14]]4 M10 02https://esolangs.org/w/index.php?diff=117896&oldid=117895 5* 03None1 5* (+11) 10 > 1697279397 477125 PRIVMSG #esolangs :14[[07User:None114]]4 M10 02https://esolangs.org/w/index.php?diff=117897&oldid=117861 5* 03None1 5* (-4) 10/* My Articles */ > 1697279415 487713 PRIVMSG #esolangs :14[[07User:None114]]4 M10 02https://esolangs.org/w/index.php?diff=117898&oldid=117897 5* 03None1 5* (-15) 10/* My Articles */ > 1697279550 816362 PRIVMSG #esolangs :14[[07User:None1/InDev14]]4 10 02https://esolangs.org/w/index.php?diff=117899&oldid=117853 5* 03None1 5* (+298) 10/* Arithmetic */ > 1697279598 986960 PRIVMSG #esolangs :14[[07User:None1/InDev14]]4 M10 02https://esolangs.org/w/index.php?diff=117900&oldid=117899 5* 03None1 5* (+6) 10/* Arithmetic */ periods > 1697279623 15974 PRIVMSG #esolangs :14[[07User:None1/InDev14]]4 M10 02https://esolangs.org/w/index.php?diff=117901&oldid=117900 5* 03None1 5* (+10) 10/* Declaration */ < 1697280869 631884 :arseniiv!~arseniiv@136.169.149.238.dynamic.ufanet.ru JOIN #esolangs arseniiv :the chaotic arseniiv > 1697281025 383035 PRIVMSG #esolangs :14[[07User:None1/InDev14]]4 10 02https://esolangs.org/w/index.php?diff=117902&oldid=117901 5* 03None1 5* (+60) 10/* I/O */ > 1697281161 283213 PRIVMSG #esolangs :14[[07User:None1/InDev14]]4 10 02https://esolangs.org/w/index.php?diff=117903&oldid=117902 5* 03None1 5* (+229) 10/* Commands */ > 1697281240 136584 PRIVMSG #esolangs :14[[07User:None1/InDev14]]4 M10 02https://esolangs.org/w/index.php?diff=117904&oldid=117903 5* 03None1 5* (+130) 10/* Commands */ < 1697284049 380406 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :and, I assume, even with all the overhead for the flooded encoding, a Turing-universal machine will fit into the 280 or so creature types? < 1697284155 337925 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :"but there's enough room to fit, say, a Spiral Rise interpreter" => ah < 1697284607 714578 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :" how out-of-order execution even works, if it isn't allowed to reorder the loads – presumably it tries to keep all the values it's working with in exclusive cache" => that's what I would think, since accessing main memory is so slow that at that point out of order execution doesn't help much, except… doesn't hyperthreading share the L1D cache between two threads of execution that alternate < 1697284613 722520 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :instructions in a single core? and don't all the processor cores in a processor share their L3 cache usually? < 1697284688 3356 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :I never really tried to understand x86's multi-threaded memory model, I figure I don't need to write code that communicates between threads so much that the optimization matters for me. < 1697285338 522856 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :I wonder how efficiently that M:tG construction can simulate computation < 1697285403 560811 :int-e!~noone@int-e.eu PRIVMSG #esolangs :. o O ( Will it ever be tournament viable :P ) < 1697285464 439958 :int-e!~noone@int-e.eu PRIVMSG #esolangs :. o O ( "Don't worry, we're just computing the 5th Fibonacci number; it'll be done in 5 minutes." ) < 1697285498 380905 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :int-e: I meant the other efficient, as in how slow it is asymptotically to simulate arbitrary programs < 1697285528 594472 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :probably just like two to eight levels of exponential < 1697286079 185043 :Europe2048!~Europe204@fableness-hydrant.volia.net PRIVMSG #esolangs :Tried making a bf interepter in Scratch, but I coudln't get it to work. Not even "+." worked as expected. < 1697286190 293954 :Europe2048!~Europe204@fableness-hydrant.volia.net PRIVMSG #esolangs :I can't even share it with text due to how many blocks it has. < 1697286340 948715 :Europe2048!~Europe204@fableness-hydrant.volia.net PRIVMSG #esolangs :Should I give up? < 1697286781 30168 :int-e!~noone@int-e.eu PRIVMSG #esolangs :b_jonas: that's less funny :-P < 1697286795 917356 :Koen!~Koen@2a01:e34:ec7c:30:5510:320f:787:e9f6 QUIT :Remote host closed the connection < 1697286974 384949 :Koen!~Koen@2a01:e34:ec7c:30:a5ba:d2c0:c66c:4d1f JOIN #esolangs * :Koen < 1697287120 543601 :Europe2048!~Europe204@fableness-hydrant.volia.net PRIVMSG #esolangs :Since you weren't answering, I'll give up by myself... < 1697287528 131794 :__monty__!~toonn@user/toonn JOIN #esolangs toonn :Unknown < 1697287602 515424 :Koen!~Koen@2a01:e34:ec7c:30:a5ba:d2c0:c66c:4d1f QUIT :Quit: Leaving... < 1697289804 927563 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1697289903 57714 :ais523!~ais523@user/ais523 PRIVMSG #esolangs : I wonder how efficiently that M:tG construction can simulate computation ← it's exponentially slower than The Waterfall Model, which if using the Spiral Rise implementation to fit into the required amount of memory, is exponentially slower than a tag system < 1697289908 771053 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and tag systems are polynomially slower than Turing Machine < 1697289914 266337 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* Turing machines < 1697289934 419903 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so, actually not that bad as these things go < 1697289983 789268 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(also, there may be a faster programming technique using the same sort of setups with the same cards) < 1697290212 205249 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :right < 1697290341 412710 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one thing I am interested in is esolang interpreters that can optimise out all the levels of exponential explosion in this sort of simulation < 1697290365 171232 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :optimising out one level is normally fairly easy – both ratiofall and floodfall can do it (via different mechanisms) < 1697290371 551763 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but it would be nice to get the optimisation to recurse < 1697290693 775850 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :yes, and for M:tG that doesn't even sound too impossible, by simulating stacks < 1697290714 197081 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :it's just hard if you want a somewhat competitive deck < 1697290951 175006 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, I am mostly interested in golfing the implementation so that the rest of the deck can be as competitive as possible < 1697291007 497115 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a deck like Ruby Storm can make hundreds of mana and play every card in its sideboard – but because it can do that, its sideboard is normally full of useful cards that help it win in various different situations that might come up during a game, rather than actual sideboard cards < 1697291017 914960 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :what's the newest card that seems to help (as in, you can't just replace it with older cards) these days? < 1697291022 898090 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so, using up sideboard slots on Turing-completeness cards reduces the win rate even in game 1 < 1697291049 127032 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :is the hundreds of mana colorless? < 1697291079 414883 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's red, you get some amount of other colors too < 1697291119 161283 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :e.g. Ruby Storm commonly runs Inspired Tinkering in the sideboard, which generates treasure tokens as one of its effects < 1697291123 690903 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`card-by-name Inspired Tinkering < 1697291126 226634 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :No output. < 1697291158 275532 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but this means that if you want lots of non-red mana you can't cut the Inspired Tinkering from the sideboard, even though it's one of the less important sideboard cards < 1697291212 167472 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the deck also runs Manamorphose, but that can't generate too much colored mana without decking you out, unless you have some way to reshuffle cards back into your library or some way to protect yourself against decking) < 1697291327 883469 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :the color is probably more required if you want to set up your computer than if you just want to win many games < 1697291377 293734 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, once the combo fully goes off you can win with just about any damage spell – the deck has copy effects, so you can win with just one Lightning Bolt if you want to < 1697291379 661156 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :or does it not matter because you go off infinitely powerful before you need the color? < 1697291401 186485 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so most of the sideboard is there for if the deck only partially goes off and needs to try to salvage a fizzled combo < 1697291403 770976 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :well, before you need all colors < 1697291422 761071 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a fizzled combo generally wouldn't have non-red mana available, so the salvaging cards are red < 1697291432 341870 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :things like Empty the Warrens and Galvanic Relay < 1697291451 911801 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :and your opponent will probably have a lot of the most annoying disruption < 1697291459 857461 :FireFly!~firefly@glowbum/gluehwuermchen/firefly PRIVMSG #esolangs :does this construction only require one player for computation, or does it depend on cooperation? < 1697291460 412377 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :some of the opponents at least < 1697291474 334196 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :FireFly: it requires an opponent but they don't have to be cooperative < 1697291476 284534 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :FireFly: the goal for this construction is to not require cooperation by the opponent < 1697291487 478963 :FireFly!~firefly@glowbum/gluehwuermchen/firefly PRIVMSG #esolangs :right, *nod* < 1697291490 748386 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :that's why it's so hard to make it competitive < 1697291511 934313 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: watching Ruby Storm play through disruption is glorious, it basically keeps on trying combos until the opponent runs out of counterspells, and brute-forces its way through prison pieces < 1697291531 130891 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :in cooperative you can usually just spend 50 turns to draw most of your deck and then set up a fragile combo < 1697291542 823057 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think it can even win through Trinisphere if it's given enough time to sculpt its hand < 1697291569 713644 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the main cards that stop it are Deafening Silence and Maddening Hex, which can't be burst through simply by making more mana < 1697291674 360796 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it is possible that some other Storm variant, that is less sideboard-dependent, would be more competitive after you replace 6-7 sideboard cards with a Turing-complete construction though < 1697291675 986897 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :I'm still curious, what's the newest card that's useful for the computation setup < 1697291700 533796 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :sorry, I tried to work it out and then got distracted, for most of the cards old cards are acceptable < 1697291704 523438 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :probably Arcbond? < 1697291706 672699 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`card-by-name Arcbond < 1697291707 783650 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :Arcbond \ 2R \ Instant \ Choose target creature. Whenever that creature is dealt damage this turn, it deals that much damage to each other creature and each player. \ FRF-R < 1697291726 980826 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there are other ways to repeatedly damage every creature in an unstoppable loop, though < 1697291751 154227 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :I See < 1697291755 993927 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but double Arcbond is very efficient – the problem with it is that you need a lifegain source in order to avoid the game ending due to burn damage < 1697291807 20829 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(also it is hard to ensure that the triggers always stack in the correct order – the current construction uses an Arcbond that was controlled by the turn player as it resolved, with everything else controlled by their opponent) < 1697291880 254292 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :everything else controlled by the opponent? does that mean you need Donate? < 1697291896 171944 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :or is there some other card that helps with that < 1697291906 312641 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`card-by-name Fractured Identity < 1697291907 387050 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :Fractured Identity \ 3WU \ Sorcery \ Exile target nonland permanent. Each player other than its controller creates a token that's a copy of it. \ C17-R < 1697291925 185274 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so you need to be able to a) make a huge number of tokens and b) give them to your opponent < 1697291927 888758 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :ah, that's better < 1697291933 913443 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :that plays double duty < 1697291954 474735 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Fractured Identity plays double duty, but it implies you need to add an un-exiler to the deck < 1697291968 253250 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or, hmm, maybe not < 1697291996 380688 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :that card is newer than Arcbond < 1697292009 454262 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's not part of the computation, it's part of the setup < 1697292015 600511 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I didn't realise you were counting those too < 1697292022 486785 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :I'm not sure what I'm counting < 1697292027 488299 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but yes, you need an unexiler in order to create multiple tokens < 1697292044 275434 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :I know that there's power creep so new cards are likely useful if you want to just not lose < 1697292048 72842 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`card-by-name Mirror of Fate < 1697292049 118387 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :Mirror of Fate \ 5 \ Artifact \ {T}, Sacrifice Mirror of Fate: Choose up to seven face-up exiled cards you own. Exile all the cards from your library, then put the chosen cards on top of your library. \ M10-R < 1697292052 874393 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`card-by-name Riftsweeper < 1697292053 867047 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :Riftsweeper \ 1G \ Creature -- Elf Shaman \ 2/2 \ When Riftsweeper enters the battlefield, choose target face-up exiled card. Its owner shuffles it into their library. \ FUT-U, MMA-U < 1697292059 384631 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`card-by-name Coax from the Blind Eternities < 1697292060 371595 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :Coax from the Blind Eternities \ 2U \ Sorcery \ You may choose an Eldrazi card you own from outside the game or in exile, reveal that card, and put it into your hand. \ EMN-R < 1697292093 186333 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think those are the most viable options for unexilers < 1697292106 383616 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there aren't a whole lot of unexilers printed < 1697292140 353154 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :`card-by-name Pull from Eternity < 1697292141 347206 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :Pull from Eternity \ W \ Instant \ Put target face-up exiled card into its owner's graveyard. \ TSP-U < 1697292151 254833 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :I think Pull from Eternity was the first one < 1697292156 62079 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :alternatively, you can run a create-a-token effect and a donate effect separately, but the unexilers are useful for creating infinite (rather than large finite) loops and setting up an arbitrarily large program < 1697292175 911949 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Pull from Eternity doesn't work because you then have to get the card out of the graveyard < 1697292202 775442 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :don't you need something to replicate instants anyway, for other cards? < 1697292221 112672 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Ruby Storm is based around the card Bonus Round which copies instants < 1697292239 269654 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that's one of the reasons I wanted to use it as a base – it runs four copies of an instant-copier maindeck < 1697292267 492166 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so that saves space in finding a way to copy your instants and sorceries < 1697292273 610480 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :huh < 1697292281 68656 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`card-by-name Bonus Round < 1697292282 195319 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :No output. < 1697292287 592175 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :too new, I thoughti t would be < 1697292290 354652 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :that does mandatory copy, so it just tries to go infinite if you have two of them? < 1697292298 132849 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's a cast trigger < 1697292307 940773 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it goes exponential rather than infinite < 1697292309 645031 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :ah right < 1697292326 520486 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :exponential? isn't it just linear? < 1697292336 710758 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's linear in the number of copies of Bonus Round which resolved < 1697292347 388992 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which is exponential in the number that were cast, because they copy each other < 1697292351 774476 :b_jonas!~x@89.134.28.168 PRIVMSG #esolangs :ah < 1697292599 647254 :Europe2048!~Europe204@fableness-hydrant.volia.net PRIVMSG #esolangs :What are you talking about> < 1697292631 341645 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :building a Turing-complete programming language inside a card game < 1697292669 14802 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :actually there are two games that can manage it, Magic: the Gathering and Netrunner < 1697292691 741107 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but Magic finds it much easier, we're wondering if it's possible to do it with an opponent trying to stop you (implying that you play a competitive deck) < 1697299167 614235 :Guest55!~Guest55@ool-944bd88a.dyn.optonline.net JOIN #esolangs * :[https://web.libera.chat] Guest55 < 1697299241 495768 :Guest55!~Guest55@ool-944bd88a.dyn.optonline.net QUIT :Client Quit < 1697300845 946899 :Thelie!~Thelie@2a03:2260:300c:400:61bd:fe2e:1f3c:b90a JOIN #esolangs Thelie :Thelie > 1697301326 567510 PRIVMSG #esolangs :14[[07Capsule14]]4 M10 02https://esolangs.org/w/index.php?diff=117905&oldid=117890 5* 03PythonshellDebugwindow 5* (+59) 10Fix link to userpage, add categories > 1697303105 865136 PRIVMSG #esolangs :14[[07N14]]4 M10 02https://esolangs.org/w/index.php?diff=117906&oldid=44078 5* 03PythonshellDebugwindow 5* (+13) 10Deadlink > 1697303316 117604 PRIVMSG #esolangs :14[[07Metat14]]4 M10 02https://esolangs.org/w/index.php?diff=117907&oldid=36168 5* 03PythonshellDebugwindow 5* (+52) 10Categories < 1697304535 319736 :Thelie!~Thelie@2a03:2260:300c:400:61bd:fe2e:1f3c:b90a QUIT :Remote host closed the connection < 1697304635 267850 :Europe2048!~Europe204@fableness-hydrant.volia.net PRIVMSG #esolangs :Hi everyone! < 1697309127 109281 :__monty__!~toonn@user/toonn QUIT :Ping timeout: 240 seconds < 1697309447 467747 :__monty__!~toonn@user/toonn JOIN #esolangs toonn :Unknown < 1697310691 521056 :arseniiv!~arseniiv@136.169.149.238.dynamic.ufanet.ru QUIT :Quit: gone too far < 1697311738 443651 :__monty__!~toonn@user/toonn QUIT :Ping timeout: 255 seconds < 1697311848 465410 :__monty__!~toonn@user/toonn JOIN #esolangs toonn :Unknown < 1697312116 449571 :__monty__!~toonn@user/toonn QUIT :Ping timeout: 255 seconds < 1697312503 441027 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname > 1697315852 152764 PRIVMSG #esolangs :14[[07Sultan's daughter14]]4 M10 02https://esolangs.org/w/index.php?diff=117908&oldid=91441 5* 03CreeperBomb 5* (-4) 10Corrected punctuation, added necessary conjunction > 1697315979 6308 PRIVMSG #esolangs :14[[07Oifi14]]4 M10 02https://esolangs.org/w/index.php?diff=117909&oldid=115346 5* 03CreeperBomb 5* (-1) 10/* Conclusion */ > 1697316448 182351 PRIVMSG #esolangs :14[[07Neg14]]4 M10 02https://esolangs.org/w/index.php?diff=117910&oldid=70733 5* 03PythonshellDebugwindow 5* (+53) 10Categories > 1697316953 651762 PRIVMSG #esolangs :14[[07NUMBRS++14]]4 M10 02https://esolangs.org/w/index.php?diff=117911&oldid=94370 5* 03PythonshellDebugwindow 5* (+25) 10Category < 1697318472 945883 :Europe2048!~Europe204@fableness-hydrant.volia.net QUIT :Quit: Client closed < 1697321689 646848 :craigo!~craigo@user/craigo JOIN #esolangs craigo :realname < 1697321848 384894 :Koen!~Koen@2a01:e34:ec7c:30:ccc8:8e73:10de:59c2 JOIN #esolangs * :Koen < 1697322454 426700 :craigo_!~craigo@180-150-36-21.b49624.bne.nbn.aussiebb.net JOIN #esolangs * :realname < 1697322741 670790 :craigo!~craigo@user/craigo QUIT :Ping timeout: 260 seconds > 1697322858 868519 PRIVMSG #esolangs :14[[07Three Star Programmer14]]4 10 02https://esolangs.org/w/index.php?diff=117912&oldid=74391 5* 03Tux1 5* (+105) 10 < 1697326085 360202 :Koen!~Koen@2a01:e34:ec7c:30:ccc8:8e73:10de:59c2 QUIT :Quit: Leaving... < 1697327319 486640 :Sgeo_!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname < 1697327322 993650 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer