> 1708390934 780365 PRIVMSG #esolangs :14[[07Adj14]]4 N10 02https://esolangs.org/w/index.php?oldid=123663 5* 03BestCoder 5* (+374) 10Created page with "Adj (a is ADd a to b, then Jump to c) aka a=a+b; goto c command = ADJ a b c label = x: add only = ADJ a b X jump only = ADJ X X c output = ADJ 0 b c or ADJ 0 b X input = ADJ 1 b c or ADJ 1 b X = Examples = == Add 1 and 1 == ADJ a 1 X ADJ b 1 X ADJ a b X ADJ 0 a X == Ad < 1708392446 251770 :amby!~ambylastn@31.205.89.228 QUIT :Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement < 1708393795 679616 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 268 seconds < 1708393845 409732 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1708396235 201407 :Noisytoot!~noisytoot@sourcehut/user/noisytoot QUIT :Ping timeout: 264 seconds < 1708397098 447332 :Noisytoot!~noisytoot@sourcehut/user/noisytoot JOIN #esolangs Noisytoot :Ron < 1708399945 299286 :^[!~user@user//x-8473491 QUIT :Quit: ^[ < 1708403442 335294 :Noisytoot!~noisytoot@sourcehut/user/noisytoot QUIT :Remote host closed the connection < 1708403569 933130 :APic!apic@apic.name QUIT :Ping timeout: 264 seconds < 1708404426 875427 :Noisytoot!~noisytoot@sourcehut/user/noisytoot JOIN #esolangs Noisytoot :Ron < 1708405473 526153 :SGautam!uid286066@id-286066.ilkley.irccloud.com JOIN #esolangs SGautam :Siddharth Gautam < 1708406102 383117 :APic!apic@apic.name JOIN #esolangs APic :A. Pic. - my name since YOLD 3149 < 1708408536 995540 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1708409112 562064 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :What's the fastest Thue interpreter in existence? < 1708410552 303266 :^[!~user@user//x-8473491 JOIN #esolangs ^[ :user < 1708410777 795233 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Swyrl: most of the work on Thue interpreters was over a decade ago, so I'm not sure anyone remembers that any more < 1708410792 180398 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and I'm not sure if any were optimised for speed < 1708410795 847091 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Thue interpreter or compiler, I guess. < 1708410807 535001 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it wouldn't surprise me if the best approach would be to write a new one, if you need speed < 1708410882 529442 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(also, writing fast interpreters for tarpits can be very difficult because many tarpit programs store things in very inefficient encodings, which an optimising interpreter can reverse-engineer and store more efficiently for a huge speedup, but that's generally very difficult to implement) < 1708410980 345097 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Yeah, there's only so much you can do to make the core operations fast before you hit the "bottom". < 1708411017 93046 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right – optimising the core operations in a tarpit is sometimes helpful, but working out how they optimise as groups and optimising the group gives a much larger benefit < 1708411056 673200 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :e.g. in brainfuck, a good optimising compiler should optimise code like [->+++<] into a multiplication by 3, and that will inherently be much faster than simply trying to implement [ and - and > and + and < as efficiently as possible# < 1708411159 188287 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I wrote an optimizing interpreter for The Waterfall Model named Ratiofall, which works by analyzing what a loop is doing and attempting to shortcut as many iterations of the loop as possible, and this works recursively, so often even complex and nested loops can be optimized down to a single constant-time operation < 1708411188 370471 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(although of course it's impossible, both in general and in this particular case, to make this sort of thing work for all loops) < 1708411203 97618 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Hard to do things like that in Thue and other string rewrite languages unless you write rules in a specific form. < 1708411210 937029 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :with Thue this sort of thing is harder because it's hard to even identify where the loops are < 1708411282 28272 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, another thing that can make Thue hard to implement efficiently is that the search string and replacement can be different lengths, which means that you need to be able to insert into the middle of a string < 1708411313 249765 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Yeah. You solve that with a deque. < 1708411381 205631 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I don't think a deque would handle that problem – it can only do fast different-length replacements at one particular point in the string (typically the ends), so you would have to scan the entire string repeatedly changing the replacement point < 1708411390 377111 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :A deque and a trie are as fast as I've gotten. < 1708411392 513321 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Yes. < 1708411412 295374 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Throw your rules into a trie, with the leaves being the right hand sides of your rules. < 1708411432 409751 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :At any evaluation step, try to match the head of the deque with the trie. < 1708411437 733381 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :If you can't, advance one character, try again. < 1708411469 251706 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :If you can, dequeue the pattern length, and then enqueue the right hand side to the head of the deque. < 1708411471 964212 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so I think there are two basic models you could use: one is the "iterated finite-state transducer" model which I think is what you are using (although it doesn't easily work for the "standard" probabilistic variant of Thue, it works for "Thue with unspecified evaluation order") < 1708411499 284896 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Yeah, the latter bit. < 1708411510 705407 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :You can also use the trie to compile to a sequence of nested switch/case statements. < 1708411511 806684 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and the other would be to have some sort of rope to hold the string, together with an index of what locations matched the LHS of a rule < 1708411513 225592 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Or nested ifs. < 1708411527 167122 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that would be faster in cases where most of the string doesn't match most of the time < 1708411545 247432 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think the trie would ideally be compiled into a finite-state machine < 1708411577 196373 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :What would be the difference? < 1708411583 172144 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :https://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_string-search_algorithm < 1708411590 314917 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Time complexity is the same-ish. < 1708411638 533848 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :with the finite-state machine time complexity is O(n) where n is the length of the state string, with the trie it's O(nx) where x is the length of the longest search string < 1708411658 389732 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although, x is a constant for any given program, so it doesn't change the computational complexity of any given program < 1708411668 426171 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :still, not having to rewind after a failed match makes it faster in practice < 1708411669 33468 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :I was going to say. < 1708411670 842093 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :It's still linear. < 1708411691 116164 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Why would you rewind? Failure means you advance by one character by "rolling" the deque. < 1708411717 856415 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :say your rule is aaab::=c and your search string is aaaaaab < 1708411718 498623 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Or are you talking about a rewind in terms of control flow. < 1708411729 132831 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Right. < 1708411739 494366 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :first you match aaab against the first four characters of the string, then against characters 2-5, then against characters 3-6, and so on < 1708411743 913751 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so each character is being checked multiple times < 1708411760 704641 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Mmm. < 1708411782 964130 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a well-designed finite-state machine can check aaab against characters 1-4, then just check b against 5, because the information that we just saw 3 'a's is already encoded in the machine's state < 1708411790 437408 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Yeah, if we divide it like.. `aaa aaab`. < 1708411818 170135 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :You'd traverse `a -> a -> a -> b` and then fail on `a`, advance one character. < 1708411848 757658 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess you can think of a finite state machine as checking from all possible starting positions in parallel < 1708411876 319685 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Yeah you'd have to go through.. eugh, 4 comparisons each. < 1708411879 705209 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Hm. < 1708411881 811196 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Yeah. < 1708411917 814586 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :I feel like at that point you're describing regular expressions with string replacement states. < 1708411939 55835 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, this is why I said "finite-state transducer" which is effectively the mathematical formalization of that < 1708411950 969525 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :And you can morph a trie into a DFA. < 1708411979 370672 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :It's just merging common prefixes, but.. < 1708411982 177816 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Err, suffixes. < 1708412034 912490 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the trie already merges common prefixes – the change to a DFA is in working out what part of the tree to return to after a mismatch (which might not necessarily be the root) < 1708412053 430746 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Yeah that part I don't have an intiution about. < 1708412057 368069 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :*intuition < 1708412069 153201 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :So what would the FSM for `aaab ::= c` be, do you think? < 1708412111 612138 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it would have 5 states, representing the number of characters of "aaab" that had matched, so I'll call them 0…4 respectively < 1708412150 638166 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :most characters go to state 0 when read; 'a' in state 0-2 adds 1 to the state number; 'b' in state 3 shows a match; 'a' in state 3 remains in state 3; and 4 is the state that shows a match was found < 1708412180 628031 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :normally it's harder for a human to calculate than that (although still pretty easy for a computer), but this string is quite well-behaved < 1708412232 112401 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :OK, so 'b' in state 3 goes to state 4 and that's how it reports the match; state 4 is just a halt/success state < 1708412289 204591 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in general I think you have a state for all possible prefixes of the search strings, so the behaviour when there is a potential match is identical to that of a trie < 1708412340 633695 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the only difference is in deciding where to go after a mismatch, which is done by looking at the longest (possibly empty) suffix of the characters read so far that's a prefix of at least one search string, and going to that state < 1708412378 604340 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Hm, I'm gonna try to draw that out. < 1708412380 716046 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Hard to visualize. < 1708412401 467525 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :You seek to the next character on successful match given a transition, yeah? < 1708412421 24296 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :e.g. if we have search strings "abcde" and "cdfg", then upon reading "f" after "abcd", the longest suffix of the characters read that's a prefix of a search string is "cdf", so we jump to the "cdf" section of the trie < 1708412457 27996 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so, there's one state for every string that's a prefix of at least one search string (even if it's a prefix of more than one search string, you still only have the one state) < 1708412543 442488 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :say the state is "X" and you're reading a character 'y' to produce the string "Xy" – you then need to go to the state "Xy", but if there isn't one (because no search string starts with "Xy"), you remove the first character of "X" and try again (effectively advancing the position "you started scanning from" by one character) < 1708412572 925687 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :That's kind of interesting.. < 1708412573 55518 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and repeat, eventually (if you just read a character that doesn't appear in any search string) you end up with the empty string, which must be a prefix of every search string < 1708412602 832075 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and because there are finitely many "X"s and finitely many "y"s, you can just work out the correct state transition for every "Xy" in advance by trying all of them < 1708412643 380005 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :ACTION thinks. < 1708412930 436488 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Wouldn't this require analyzing the initial string -and- the rules? < 1708412976 54998 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :no, just the rules, once you've analyzed it it works on any string (initial or not) < 1708412980 394793 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :aaab -> c run on a string "aaaaaaaab" would fit the bill, but what if it was something like "aaaacccccaaaaaaab". < 1708413010 486768 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so, the rule for state 3 (i.e. after reading "aaa") goes to state 3 upon reading "a", but back to state 0 upon reading "c" < 1708413037 726612 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Right, but you'd need to do have your list of symbols to fail on. < 1708413042 490987 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because "aaac" isn't a prefix of any search string, and nor is "aac" nor "ac" nor "c" < 1708413047 62157 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :*you'd need to have your list of symbols to fail on". < 1708413052 633882 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Bah, fingers. < 1708413062 292008 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and we can analyze that in advance < 1708413103 101016 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, your "any symbol not in any of the rules" transition goes to state 0 < 1708413139 547017 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess you do need to know the complete list of characters that could occur (or just design the FSM to always go to state 0 upon seeing an unexpected character) < 1708413158 167352 :ais523!~ais523@user/ais523 QUIT :Quit: my connection is playing up, reconnecting in the hope of fixing it < 1708413200 993020 :SGautam!uid286066@id-286066.ilkley.irccloud.com QUIT :Quit: Connection closed for inactivity < 1708413205 817598 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1708413216 639079 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :So 1 -(a)-> 2 -(a)-> 3 -(a)-> 4 -(b) -> 0, and 1 -(a)-> 2 -(a)-> 3 -(a)-> 4 -(*) -> 4. < 1708413244 270576 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think you have the states numbered incorrectly, but the general pattern of the transitions looks right < 1708413263 185050 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :I just started from 1 instead of 0. < 1708413301 890415 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Whoops, yeah, that last one should be 0. < 1708413315 404885 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :last one should be 1 I think, with your numbering < 1708413315 488043 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Initial state, see 'a', next state, see 'a', next state, see 'a', next state, see 'b' and go to initial state. See anything else, go to the same state. < 1708413331 412684 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Yeah, a 1.. sorry, it's almost midnight and my meds have worn off. < 1708413348 260672 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this sort of thing is common among programmers, don't worry about it < 1708413372 943652 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :That'd be odd, though. I feel like that'd produce some weird results. < 1708413381 990191 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Like that'd match on `aaaaaacb`. < 1708413441 63262 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the full machine is (with your numbering) 1: {'a': 2, others: 1}; 2: {'a': 3, others: 1}; 3: {'a': 4, others: 1}; 4: {'a': 4, 'b': accept, others: 1} < 1708413473 696137 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so on 'aaaaaacb', the machine goes from 1 to 2 to 3 to 4 on the leading 'a's, stays at 4 for the rest of the 'a's, then goes back to 1 on the 'c' < 1708413482 965837 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and then stays at 1 for the 'b' because state 1 doesn't have a rule for 'b' < 1708413529 661473 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Why wouldn't 'c' trigger a transition to 4 as well, or is that just "if we're repeating the previous transition"? < 1708413550 79614 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Like if the transition that led to 4 is 'c' that'd be 'c'. < 1708413565 518173 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :'c' doesn't trigger a transition to 4 because we're only supposed to be in state 4 if the preceding three characters were "aaa" < 1708413598 186463 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Right, but locally it's just because the prior transition is 'a', right? < 1708413632 272138 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I don't understand your reasoning < 1708413644 945326 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :we're looking for "aaab" and no other string < 1708413679 744934 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so if we see a 'c' we know that the string we're looking for doesn't overlap this point in the string being searched, because "aaab" doesn't contain 'c' < 1708413708 162281 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and so we can go back to the initial state because we know that any match has to be entirely to the right of the current location, so it's safe to forget everything we've seen < 1708413726 602015 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :thus 'c' always goes back to state 1, regardless of which state we were in beforehnad < 1708413736 963721 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :I'm trying to figure out the general rule for generating these. < 1708413796 734025 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :What would "abc -> xyz" look like as a state diagram? < 1708413829 598004 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :1: {'a': 2, others: 1}; 2: {'b': 3, others: 1}; 3: {'c': accept, others: 1} < 1708413843 456229 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the right hand half of the rule doesn't matter at all for the matching, just for the replacement < 1708413855 822844 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :to make it into a full finite-state transducer, you need to add in the replacements too < 1708413858 974371 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so it'd look like this: < 1708413867 393413 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Right. < 1708413900 764440 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :So let's add more search strings. "abc", "aab", "acab", "baac". < 1708413923 827297 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :1: {'a': goto 2, others: echo the read character, goto 1}; 2: {'b': goto 3, others: print 'a', echo the read character, goto 1}; 3: {'c': print "xyz", goto 1; others: print 'ab', echo the read character, goto 1} < 1708413950 376340 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :with your new set of search strings, the states are "a", "b", "aa", "ab", "ac", "ba", "aca", "baa" < 1708413952 897242 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and "" < 1708413964 140357 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :i.e. everything that's a prefix of any of the search strings < 1708413983 498357 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Hmmmm. < 1708414005 402064 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :("a" is a prefix of three of the search strings, but we nonetheless only have one "a" state) < 1708414013 225211 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :And that's not really any different from a trie. < 1708414025 43489 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :You'd still have those same states.. ish. < 1708414033 891781 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, the transitions for when we read something that could extend a match are identical to the trie < 1708414058 352507 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the only difference is the transitions that produce something that isn't a valid prefi < 1708414060 730551 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* prefix < 1708414109 724451 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :e.g. say we read "a" in state "baa" – "baaa" doesn't match, so we would transition to "aaa" if it were a state (but it isn't), and so we instead transition to "aa" which is a state < 1708414134 133147 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(and when constructing the finite-state transducer, the "b" and "a" that "fall off the start" get echoed) < 1708414156 411042 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :..What the heck is the algorithm to do this? < 1708414217 748515 :tromp!~textual@92.110.219.57 JOIN #esolangs * :Textual User < 1708414243 216918 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :DFA minimization? < 1708414253 69962 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a) calculate all prefixes of the state LHSes; b) append all possible symbols to each of those prefixes (you can optimize for symbols that can't occur); c) for each of those strings made by appending prefix+symbol, take the longest suffix of it that's one of the prefixes; the suffix becomes the next state to go to, the bit before the suffix gets echoed < 1708414278 94014 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :except d) if the prefix+symbol happens to be a rule LHS, instead print the RHS and goto the initial state < 1708414288 537118 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(assuming we're talking about unspecified-evaluation-order Thue) < 1708414350 204907 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :For a), that's just "all possible slices of a string starting from the first character and ending with the last"? < 1708414380 598979 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :no, it's prefixes, not slices < 1708414386 57220 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and it's only prefixes of rule LHSes < 1708414407 408639 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so, all substrings of rule LHSes that start at the start, but end before the end < 1708414428 554251 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :That's a lot. < 1708414441 992867 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Even for a string like "aaab". < 1708414456 146491 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's less than or equal to the total number of characters in the rule LHses < 1708414470 246301 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :e.g. a 10-character string has 10 prefixes < 1708414481 62612 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so, linear in the size of the program < 1708414484 525219 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :I'm sorry, I'm not grokking this properly, what exactly do you define as a prefix here? < 1708414504 391057 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so for "abcde", the prefixes are "", "a", "ab", "abc", "abcd" < 1708414506 101564 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :For me, if I have a string abcd, [a, ab, abc, abcd]- < 1708414514 844439 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Yeah. < 1708414536 568387 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :All substrings starting from the first character, and ending right before the end. < 1708414541 257344 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yep < 1708414550 240593 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Which I said as a slice earlier. < 1708414550 942709 :SGautam!uid286066@2a03:5180:f:3::4:5d72 JOIN #esolangs SGautam :Siddharth Gautam < 1708414563 379512 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :"slice" to me doesn't necessarily imply starting at the start < 1708414599 846634 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a prefix is a sort of slice, but not the only sort of slice < 1708414600 762025 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Ah. < 1708414603 912441 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Makes sense. < 1708414770 746466 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :anyway, this conversation has been useful to me because I've been thinking about the use of iterated finite-state transducers as a parsing automaton – it's been interesting to learn that my automaton is exactly the same thing as "left-to-right Thue" < 1708414804 342670 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(although, the parsing automaton has restrictions on it to ensure it finishes in linear time, whereas Thue doesn't have those restrictions and is Turing-complete) < 1708414823 897806 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess this makes sense because Thue was originally invented as a type of grammar, before it became a programming language < 1708414939 849508 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :anyway, this gives an idea for the next step in optimising the Thue interpreter: suppose you are using the search algorithm of "make the leftmost replacement, then scan the string again and make the leftmost replacement in the new string" < 1708414967 920274 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you don't have to scan the string again from the start, there is a limit on how far to the left the next match can occur < 1708414993 537682 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :I feel like you could use this in tandem with a deque. < 1708415003 533065 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, at this point I think you could < 1708415016 129718 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the "leftmost replacement" rule is particularly amenable to being optimized < 1708415016 265029 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :I've always wanted to upgrade my trie approach to a DFA. < 1708415030 573816 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :I managed to get single rule firing down to like.. 50ns. < 1708415037 183011 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Including replacement. < 1708415048 524106 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :are you using an array-based deque? those are normally the fastest deque implementations < 1708415057 167099 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Yep. < 1708415063 970675 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :It's just a circular buffer. < 1708415067 998787 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Head and tail pointers. < 1708415104 945709 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, the only hard part is resizing the buffer if the string grows, and even then it's not that hard, just a pain to get right < 1708415126 41633 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, I guess this is actually the same thing as a gap buffer < 1708415138 826272 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :It's not that hard. You do have a max string length, but. < 1708415152 691714 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :You can chain buffers together and allocate/expand as needed. < 1708415183 81470 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I believe the correct technique is, if the circular buffer fills, to create a new circular buffer that's (e.g.) twice as large and then copy the entire contents over < 1708415214 695824 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is linear time because the time spent copying the data is amortized over the time spent filling the buffer in the first place < 1708415738 293213 :tromp!~textual@92.110.219.57 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1708416174 748282 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :A better way would be to just chain "pages" together in a ring (previous/next pointers), with each page being a fixed size. Your head/tail pointers are then a combo of index + pointer. < 1708416237 382075 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it wouldn't surprise me if that's slower – you're paying time every time you move between pages, rather than just when the size grows < 1708416279 189587 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Not sure how. < 1708416292 66123 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although I guess the extreme way to get this to work would be to use the processor's page table, and just change the relationship between logical memory to move memory around without actually copying it < 1708416300 752226 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :You don't copy anything. < 1708416302 116258 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* relationship between logical and physical memory < 1708416317 485431 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Swyrl: yes but I think the copy is actually faster < 1708416353 722045 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :otherwise you have to deal with pagebreaks for the rest of the program's runtime, which is linear in the number of times you cross a pagebreak rather than linear in the total amount of memory you use < 1708416377 451073 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :If I have a "page" or "chunk" size of 256 elements, and I fill that up, I allocate another "chunk", set the current chunk's "next" pointer to the newly allocated chunk, and then set my "head" or "tail" pointer to that chunk, and reset the index. < 1708416393 784174 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :You have a sliding window back and forth. It's not circular. < 1708416408 63666 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, but say you move back to the previous chunk – now you need to follow the pointer between the chunks < 1708416445 173859 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :So let's say you "roll" the deque. < 1708416458 416760 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Meaning dequeue from tail, enqueue at head, or vice versa. < 1708416496 298397 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Unless you're frequently flipping back and forth on chunk boundaries, you'll pay the cost infrequently if your chunks are sufficiently large. < 1708416510 805656 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer < 1708416546 165529 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I feel like there are some situations in which frequently flipping back and forth might happen < 1708416560 692433 :tromp!~textual@92.110.219.57 JOIN #esolangs * :Textual User < 1708416572 784758 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in the random/average case, this'll happen at a rate inversely proportional to the size of the chunks < 1708416585 112944 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, maybe the compromise is to make each chunk twice as large as the previous < 1708416591 316361 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Could! < 1708416600 965318 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, I just understood why copying is faster from a computational complexity point of view < 1708416616 736115 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the length of time it takes to *allocate* all the chunks is O(total used memory) < 1708416625 894795 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and the length of time it takes to do the copies is also O(total used memory) < 1708416654 995989 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so, the time spent doing the copy can be counted against the time taken doing the allocation < 1708416708 591226 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :I'm not sure that that holds. Allocating the double-sized queue and then doing the copy every time is more operations than just allocating. < 1708416725 267568 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :You have allocate + copy instead of just allocate. < 1708416777 722968 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's more operations but they're proportional to the same value < 1708416925 824926 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :So let's say you have a chunk setup like [T.....]-[.....]-[...H.] < 1708416937 57060 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :And you move the head to the right. < 1708416960 155277 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :You'd just allocate another chunk, and move the head to the right. [T.....]-[.....]-[....]-[H.....] < 1708416985 211880 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :I don't see how that's the same operationally. You're doing allocations that are smaller than the string you've stored at that point. < 1708417014 529572 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, say you have 65536-byte chunks, now you have to follow a chunk pointer on (on average) 1 in 65536 operations < 1708417016 710437 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :So if reserving memory takes linear time with respect to how much you wanna reserve, it's both less than the entire stored string -and- less than double the capacity of the buffer. < 1708417040 365888 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you are making the "expand" operation cheaper but the "move head/tail" operation more expensive < 1708417063 670747 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and the latter happens a lot more often – you have to move the head/tail 65536 times to even make an expand happen < 1708417106 542940 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the vast majority of programs will move quadratically or even exponentially more than they expand < 1708417122 582575 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so, a tiny extra cost in the move will eventually end up outweighing a linear cost in the expansion < 1708417201 641536 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(incidentally, most modern operating systems don't have an "allocate as a copy of" primitive, but they should – it would be faster than an allocation and a copy because the allocation has to spend time zeroing the memory in order to stop programs looking at other programs' deallocated memory) < 1708417222 524250 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(and the point is that zeroing memory takes a comparable length of time to copying memory) < 1708417332 176378 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :So, the trade-off is useful because it prevents you from keeping the memory you've allocated. If you expand by twice the buffer size every time you fill it, but never release the memory or downsize, that's wasting space. < 1708417378 87335 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :The only valid chunks, i.e the ones that need to be maintained, are the ones between the head and tail pointer. < 1708417386 424781 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Tail can never be after head, head can never be before tail. < 1708417526 847271 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, the normal technique is to use a circular buffer < 1708417534 842260 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Right. < 1708417549 199759 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :But in this scheme, the circular nature is an illusion. < 1708417555 802608 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so when you have one big chunk you can have the "edges" contain useful data, and the head and tail closer to the middle, with the bit between them being uninitialized < 1708417589 328339 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that means that if the head and tail are constantly moving, but the length of the deque isn't growing, you can avoid needing to do memory operations at all < 1708417611 109207 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :anyway, with respect to "never release/downsize the memory", that's what most programs do already < 1708417626 67560 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :freeing memory back to the OS is a) slow and b) usually impossible due to fragmentation < 1708417632 416413 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :ACTION shrugs. < 1708417673 399551 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :historically in most standard lirbaries, a call to free() will make the memory available to future calls to malloc() but otherwise does nothing to affect the system state, e.g. it doesn't return the memory for use by other programs < 1708417697 493007 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(although glibc is an exception if you make sufficiently large allocations) < 1708417758 490758 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :deallocating memory is actually the most difficult part of writing a memory allocator, if you never have to deal with deallocation it is trivially easy < 1708417788 724031 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :anyway, for a program like a Thue interpreter, I'm pretty sure it is more efficient to never deallocate < 1708417793 362477 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :There was a neat talk about Zig about this. And yes, I agree. Fixed object allocators are usually the best. < 1708417817 506813 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Your fragment size is 1. < 1708417854 773041 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, if all the mallocs and frees in the same program are for blocks of the same size it's also easy < 1708417870 365241 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(although, only in terms of reusing memory in the program – it's still hard to release it back to the OS) > 1708418413 33034 PRIVMSG #esolangs :14[[07COSOL14]]4 M10 02https://esolangs.org/w/index.php?diff=123664&oldid=109310 5* 03SirBrahms 5* (-1) 10 < 1708420437 397981 :tromp!~textual@92.110.219.57 QUIT :Quit: My iMac has gone to sleep. ZZZzzz… > 1708420506 392056 PRIVMSG #esolangs :14[[07Adj14]]4 M10 02https://esolangs.org/w/index.php?diff=123665&oldid=123663 5* 03None1 5* (+8) 10 > 1708420707 390236 PRIVMSG #esolangs :14[[07Adj14]]4 M10 02https://esolangs.org/w/index.php?diff=123666&oldid=123665 5* 03None1 5* (+23) 10 > 1708420763 217604 PRIVMSG #esolangs :14[[07A+B Problem14]]4 10 02https://esolangs.org/w/index.php?diff=123667&oldid=123614 5* 03None1 5* (+68) 10/* 1 */ Added Adj implementation > 1708421194 894642 PRIVMSG #esolangs :14[[07Adj14]]4 M10 02https://esolangs.org/w/index.php?diff=123668&oldid=123666 5* 03None1 5* (-2) 10 < 1708421263 466489 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :" I'm trying to figure out the general rule for generating these." => the Cormen, Leiserson, Rivest, Stein, "Introduction to Algorithms" book chapter 32.3 describes it for now, until TAOCP volume 5 is ready. < 1708421290 839993 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :it's rather weird and I don't recall the details < 1708421307 927132 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Wonder if there's an equivalent algorithm or parsing strategy for structured programming. < 1708421355 876896 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Instead of state machines. I know there's a direct conversion by virtue of a state variable and if/else but I have a feeling there's something you can do there that gets at or close to the same complexity as the generated FST. < 1708421376 418611 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :I'll have to think on that. And thanks, b_jonas, ais523. < 1708421392 678908 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :Swyrl: also maybe look at the ICFP contest 2007, since it has the Fuun DNA language which is kind of like Thue, and it may have been worth for some teams to make an optimized interpreter for it < 1708421445 30376 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Ooh. < 1708421485 493191 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :Self-modifying. < 1708421487 890591 :Swyrl!sid553797@user/wryl PRIVMSG #esolangs :ACTION peeps. < 1708421802 842458 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :or rather, Fuun DNA is similar to Slashalash except it's more powerful and so less of a tarpit < 1708422015 71290 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523 “most modern operating systems don't have an ‘allocate as a copy of’ primitive”: I think Linux has that, at least if you're copying OS-page-aligned data, but it's a rather obscure thing that doesn't come up often because normally a program can just resuse previously allocated memory to avoid the zeroing < 1708422072 318859 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :besides the zeroing is not much of an overhead if you're overwriting immediately anyway, beacuse it only has to write the farther levels of the cache hierarchy once < 1708422302 259033 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :or at least, that used to be the case: when you allocated a large amount of memory, the kernel didn't need to zero and give it to you all at once, it could zero each page when you first touch it. this is probably no longer exactly true because of automatic hugepages. < 1708422308 961078 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: hmm, which system call is that? there's mremap but that doesn't copy the data, it moves it and/or hardlinks it (of course, moving would be good enough for the purpose of this program) < 1708422344 841873 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and yes, the zeroing is lazy nowadays but that doesn't really change much in terms of the time spent, it still has to be spent at some point < 1708422392 123484 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Windows at least used to have a background memory zeroing thread, but Linux rejected the idea because of cache thrashing (although, they started reconsidering it once uncached write instructions became generally available, not sure if it was implemetned then) < 1708422650 18993 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: Maybe a combination of memfd_create and mmap with MAP_PRIVATE will do it? < 1708422722 779532 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(it's interesting that this is hard... COW pages exist for fork() after all) < 1708422925 985475 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: I think that might work if you knew before you started populating the memory that you were going to need to copy it < 1708422935 384177 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but yes, I agree that it's interesting that it's hard < 1708423003 802016 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, actually, if you MAP_PRIVATE the same file twice, do you get two different copies? I suppose you do? < 1708423275 618405 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I'd hope so, and I don't know. < 1708423353 227950 :int-e!~noone@int-e.eu PRIVMSG #esolangs :If you ever want to make a copy of a copy this approach will break down. < 1708423772 17601 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Regarding MAP_PRIVATE... POSIX is not clear about that ("modifications to the mapped data by the calling process shall be visible only to the calling process and shall not change the underlying object") and neither is the Linux manpage. Hmm. < 1708423909 776314 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: I'm not sure if it's available in full generality, but yes, there's MAP_PRIVATE to map a private writable copy of a file, and vmsplice lets you make the kernel copy data though I don't know the details. < 1708423909 949492 :int-e!~noone@int-e.eu PRIVMSG #esolangs :https://stackoverflow.com/questions/16965505/allocating-copy-on-write-memory-within-a-process "Then use libsigsegv to intercept write attempts, manually make a copy of the page and then mprotect both to read-write." < 1708423983 41278 :shachaf!~shachaf@user/shachaf PRIVMSG #esolangs :Sounds awful. < 1708424020 306360 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: nowadays you can use userfaultfd for that, which is slightly more efficient – but both solutions still have the problem that you allocate zeroed memory and then copy into it < 1708424073 448844 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :as for MAP_PRIVATE, I'm pretty sure it's possible to map /dev/zero and I'd hope you'd get zeroed memory both times, rather than the second time contain the same data as the first < 1708424198 907682 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I wouldn't worry about the zeroing. If it's really that important, eventually the CPU developer folks will change the cache architecture so that the cache can zero a page on its own. But I don't think it will matter in the case you want, because if you overwrite the page immediately then the copy doesn't cost much. < 1708424240 378165 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it does for large pages I think < 1708424258 763124 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if it's just a 4KiB page then yes, the whole thing is zeroed and is now in L1, then you can copy it and the source of the copy also fits into L1 at the same time < 1708424274 151062 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: but it's also conceivable that /dev/zero is a special case and "real" files behave differently... but not terribly likely, I think. < 1708424278 160673 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so you just have to pay the cost of writing 4KiB into L1 twice < 1708424303 594330 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but with larger pages, the start of the page will fall out of cache before the end is zeroed, so you're going at a much slower speed < 1708424330 615002 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I wonder if POSIX was intentionally vague because they didn't want to constrain OSes, they do that sort of thing a lot < 1708424350 422941 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(for one I bet if private mappings were shared within a process this would be an attack vector, maybe on on the dynamic linker, that I'd have seen somewhere) < 1708424474 576840 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :they logically shouldn't be, and I think they probably aren't, but it's weird that that isn't clearly documented < 1708424687 422267 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, another way to implement it would be to have something similar to /dev/mem, but for logical/virtual memory (from the mapping process's point of view) rather than physical memory < 1708424694 479568 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :then, you could just MAP_PRIVATE a section of your own memory < 1708424746 13237 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(although that would have the usual MAP_PRIVATE issues of needing prefaulting in order to ensure that you are taking a snapshot, rather than some parts of the memory being loaded later and seeing changes that had been made since the map) < 1708424938 475782 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Anyway, a quick test with a real file indicates separate COW mappings. Same for memfd_create(). < 1708425021 18880 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, I wonder how you submit patches for the man pages < 1708425430 202795 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User > 1708426220 903309 PRIVMSG #esolangs :14[[07Chicken14]]4 M10 02https://esolangs.org/w/index.php?diff=123669&oldid=117332 5* 03None1 5* (+29) 10/* External resources */ > 1708426340 958888 PRIVMSG #esolangs :14[[07Chicken14]]4 M10 02https://esolangs.org/w/index.php?diff=123670&oldid=123669 5* 03None1 5* (+170) 10/* Instructions */ < 1708427347 236097 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas < 1708427679 689453 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: there's a suggestive note in the OpenBSD manpage https://man.openbsd.org/mmap on this, search for /MAP_COPY/ < 1708428339 397873 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: MAP_COPY is a GNU Hurd flag for mmap, I think < 1708428367 956714 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Linux didn't implement it in favour of MAP_DENYWRITE, but then MAP_DENYWRITE got removed because it was inherently a DOS vector < 1708428383 945476 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :…but didn't add anything else to solve the same underlying problem < 1708428410 561746 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: in any case, if you want to map a copy of your process's existing memory, and you can go linux-specific, then you can write that memory into a file in /dev/shm , and then map MAP_SHARED that part of the file. this way the kernel does the copying and presumably doesn't have to zero pages, except where you're writing not page aligned < 1708428434 154418 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: that doesn't map a copy, it double-maps the same part of memory < 1708428441 327966 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :overwriting either will overwrite the other < 1708428463 337411 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :write copies from your memory < 1708428470 434653 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah right, I see < 1708428504 288141 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :now I am wondering if you could do something with vmsplice, probably not though because you can't map a pipe < 1708428546 394188 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but you have to be careful with it, because the kernel has to keep track of what's mapped where. I presumably you'd just create a large file in /dev/shm in advance, map it non-readable, then write to the file and mprotect the region to make it available < 1708428555 737286 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :btw, this reminds me of one of my great ideas: a kernel implementation of pipes mostly in userspace, along the lines of a futex < 1708428592 927765 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so that the two programs connected by the pipe just directly read and write into memory that's mapped by both of them < 1708428600 137486 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: I think you can use splice or vmsplice if you want the kernel to copy the same pages to multiple copies in memory. you could plausibly do that for some esoteric stuff. < 1708428622 477314 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: there's a system call "tee" which copies pages out of a pipe whilst leaving the originals in the pipe < 1708428634 960363 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: right < 1708428683 836135 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although it's splice-style copying of references to the pages, rather than actual copies in memory < 1708428761 938903 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: well, there are multiple libraries that try to implement data structures over interprocess shared memory. some of them probably support something like a pipe. I find the whole thing confusing because there are like four different kernel interfaces for shared memory just on Linux, and I think at least one more on win32, and then the < 1708428762 512590 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :libraries abstract some of these away, but I don't understand how we ended up with so many different interfaces on linux in first place < 1708428811 617576 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: if the kernel were involved, though, it could allow regular reads and writes to the userspace pipes from processes that didn't know how they worked < 1708428841 51977 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and I think the reason Linux has so many interfaces is that they keep inventing better ones, but have to keep the old ones around for compatibility < 1708428858 347551 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: yes, but IIUC tee lets you copy reference only between pipes, and then splice lets you write from those pipes into any file, hopefully with as few copy operations as the kernel can get away with < 1708428908 861847 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right < 1708428995 193428 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yes, but in particular in the case of shared memory I don't really understand what is improved between the SysV shared memory and the POSIX shared memory interfaces. I understand the Linux-specific underlying interface which is that shared memory is just files in /dev/shm which is a tmpfs, and I think POSIX  shared memory is a libc interface over < 1708428995 609056 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :that, but why is there a POSIX shared memory interface in first place instead of standardizing SysV shared memory? < 1708429061 525748 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :no wait, I think POSIX does standardize the SysV shared memory < 1708429068 670781 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but also has the new interface < 1708429142 129846 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :https://man7.org/linux/man-pages/man7/sysvipc.7.html is the SysV shared memory interface, while https://man7.org/linux/man-pages/man7/shm_overview.7.html is the POSIX shared memory interface < 1708429170 473406 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :the latter says "POSIX shared memory provides a simpler, and better designed interface" < 1708429182 242905 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :POSIX isn't just for Unix-alikes, I think many of the new POSIX interfaces are to make it work on, e.g., Windows < 1708429195 849625 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like, posix_spawn exists because not all OSes can do a fork < 1708429240 251783 :__monty__!~toonn@user/toonn JOIN #esolangs toonn :Unknown < 1708429259 64518 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh right, isn't there an inherent resource leak in SysV shared memory? < 1708429262 633278 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I'm not convinced.  I think posix_spawn exists to preserve the vfork optimization without exposing it to the user, it should exist even without windows < 1708429268 32342 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like, if a process crashes the OS has no idea when to deallocate it < 1708429282 971985 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or am I thinking about something else < 1708429322 538981 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :as in, even if you can fork, that requires the OS to copy a lot of administrative data structures, vfork is cheaper but very messy, so it's worth to abstract it away to a library < 1708429357 802388 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :vfork's behaviour is kind-of unclear in between OSes, and it has odd restrictions that aren't always documented well < 1708429360 804146 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :vfork is so messy that you can't use it at all without some low-level knowledge of what the compiler even compiles as a write into memory < 1708429362 379951 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so abstracting that to a library makes sense < 1708429380 854401 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :interestingly, gcc seems to interpret vfork as equivalent to setjmp < 1708429405 119292 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :at least for the purpose of warning about incorrect uses < 1708429422 969791 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(that said, I think gcc has some false-positive setjmp warnings, or at least did last time I tried) < 1708429438 171006 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :that makes sense, it's a function that can return twice < 1708429474 195803 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :a C function; for a prolog function that's normal < 1708429481 686184 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :same for a scheme function < 1708429506 467324 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :or an unlambda function while we're there < 1708429539 368765 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess this creates philosophical problems about what returning is < 1708429555 22077 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in prolog, the compiler is basically rewinding execution to back when the function was running – although setjmp is pretty similar in spirit to that < 1708429635 936481 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and setjmp is hard to use correctly too, which is why http://software.schmorp.de/pkg/libcoro.html abstracts away one particular use case that you can implement with setjmp but where you don't want to expose the weird thing about returning twice < 1708429646 34532 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :call/cc is also similar to a rewind in spirit < 1708429678 717539 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I had a call/cc-like operator planned for an Underload-like language, which basically just took a copy of the program-to-run and made it into a stack element < 1708429717 642690 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's hard to think of that as returning twice, although in a way it does – the remainder of the program is similar in nature to a call stack and you are copying it, so running past the same point on the stack twice (or on the stack and its copy) can be thought of as returning twice < 1708429816 429019 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :scheme and ruby expose this in a maximal way, because they allow full call/cc but also conveniently usable mutable local variables and mutable arrays. whereas prolog makes mutable state somewhat hard to use, and unlambda doesn't have mutable variables at all. < 1708429841 655940 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :well, ruby 1.8; I don't know if ruby 2 still supports call/cc < 1708429875 316878 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :it was already an esoteric addition to ruby 1, I think the source code has a comment saying that they aren't doing this because it's useful, they're doing it because they can < 1708429948 733970 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :at least SWI-Prolog has a mutable assignment operator that outright overwites things that you would expect to be immutable < 1708429953 358124 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but I forget the details < 1708430018 258851 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :nb_setarg(+Arg, +Term, +Value) Assigns the Arg-th argument of the compound term Term with the given Value as setarg/3, but on backtracking the assignment is not reversed. < 1708430030 694594 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there we go < 1708430252 867422 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Read error: Connection reset by peer < 1708430276 573902 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yeah, there are multiple brands of mutability; but in scheme, the default way to create a local variable (lambda or let) is just mutable (or potentially mutable; a compiler could detect whether you ever use it as a mutable), and the default way to heap-allocate an array of object references (make-vector) makes the array elements mutable. the same < 1708430277 44510 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :is true for ruby or C. < 1708430325 277150 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :whereas prolog is designed with storage immutable by default, sort of like Haskell < 1708430386 105056 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :hmm, now I wonder, is there an unlmabda extension that lets you mutate the bindings of a k or s? < 1708430431 724476 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I don't think so, but it would fit what seems to be the spirit of the language (which is to have something that seems at first neat and mathematically elegant, but then to add on features that are surprisingly hard to reason about and break the abstractions) < 1708430492 890403 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :also, I am not sure I would describe Prolog's storage as immutable, it's more "narrowable" < 1708430503 954690 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in that variables start out undefined and your various operations on them make them more defined < 1708430581 765690 :int-e!~noone@int-e.eu PRIVMSG #esolangs :<3 lazy evaluation < 1708430616 921881 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(it's not quite the same, since Prolog is happy to spit out such a "partial" result with a placeholder variable where the hole is) < 1708430625 283660 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(or holes) < 1708430659 429986 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: right, assign-once storage. Rust has now added specific support for assign-once cells in its standard library. < 1708430676 105353 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's more like assign-gradually storage < 1708430688 180472 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which is something that lots of programming languages feel like they could benefit from, but is hard to formalize < 1708430755 236464 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :but isn't that assign gradually just made of data structures that contain multiple assign-once cells in it? < 1708430786 346758 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :it probably isn't if you look at the implementation, but that's invisible < 1708430801 568258 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in very primitive Prologs, possibly – but in practial usage you have lots of assignments that work more like "X #> 4" < 1708430809 58639 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which narrow the range of something < 1708430838 772636 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ah you're talking about the finite domain constraint satisfaction extension < 1708430846 366356 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :likewise, it's common to end up asserting that a list has at least X elements, which you can implement with assign-once cells if you use the car/cdr approach to list implementation, but which isn't how you normally think when programming it < 1708430881 486265 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think the #> syntax is pretty common for all constraint satisfaction extensions, whether finite domain or not < 1708430947 403898 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ok < 1708430989 820200 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :my point of view is probably skewed because I used prolog as a somewhat inconvenient language that I translate ordinary code into < 1708431015 679617 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :with extra features that just get in my way < 1708431062 782598 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I mostly use prologs (and Brachylog in particular) in programming competitions (typically code golf), where constraints are often very useful < 1708431082 527777 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I have used the constraint solving for a puzzle once < 1708431104 817475 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :to verify that the solution to a certain tiling puzzle is unique < 1708431193 161556 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :plus I've met https://www.perlmonks.com/?node_id=940355 where someone else used prolog to solve a puzzle that I posed on the forum > 1708431322 261177 PRIVMSG #esolangs :14[[07Chicken14]]4 M10 02https://esolangs.org/w/index.php?diff=123671&oldid=123670 5* 03None1 5* (+91) 10/* Instructions */ According to armichaud's explanation, char command pushes HTML escaped characters instead of real characters > 1708431394 73517 PRIVMSG #esolangs :14[[07Chicken14]]4 10 02https://esolangs.org/w/index.php?diff=123672&oldid=123671 5* 03None1 5* (+105) 10/* External resources */ < 1708432400 860295 :SGautam!uid286066@2a03:5180:f:3::4:5d72 QUIT :Quit: Connection closed for inactivity < 1708432638 834771 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu QUIT :Quit: Client closed < 1708432686 434126 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User > 1708434042 24784 PRIVMSG #esolangs :14[[07Putlines14]]4 N10 02https://esolangs.org/w/index.php?oldid=123673 5* 03Yourusername 5* (+594) 10Created page with "Putlines is a esolang that uses line selectors like "Run lines N to N" to loop = Commands = == Normal == === Print === print "hi" print "this is how" print "to do this" === Comments === #this counts as a line btw #ok === Labels === loop: print "this is used > 1708434156 966822 PRIVMSG #esolangs :14[[07Putlines14]]4 10 02https://esolangs.org/w/index.php?diff=123674&oldid=123673 5* 03Yourusername 5* (+28) 10/* Swap lines N and N */ > 1708434222 329997 PRIVMSG #esolangs :14[[07FatFinger14]]4 10 02https://esolangs.org/w/index.php?diff=123675&oldid=123517 5* 03Rottytooth 5* (+272) 10/* Examples */ > 1708434270 974882 PRIVMSG #esolangs :14[[07FatFinger14]]4 M10 02https://esolangs.org/w/index.php?diff=123676&oldid=123675 5* 03Rottytooth 5* (-26) 10/* FizzBuzz */ < 1708435669 698011 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Read error: Connection reset by peer < 1708435961 782661 :ais523!~ais523@user/ais523 QUIT :Ping timeout: 256 seconds < 1708436942 677329 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1708439426 156260 :slavfox!~slavfox@93.158.232.111 QUIT :Quit: ZNC 1.8.2 - https://znc.in < 1708439507 287767 :slavfox!~slavfox@93.158.232.111 JOIN #esolangs slavfox :slavfox < 1708440369 562900 :ais523!~ais523@user/ais523 QUIT :Quit: quit < 1708440443 397268 :SGautam!uid286066@id-286066.ilkley.irccloud.com JOIN #esolangs SGautam :Siddharth Gautam < 1708440494 548428 :GregorR!~GregorR@71.19.155.102 QUIT :Quit: Ping timeout (120 seconds) < 1708440508 83233 :GregorR!~GregorR@71.19.155.102 JOIN #esolangs GregorR :Gregor Richards > 1708441290 880906 PRIVMSG #esolangs :14[[07FatFinger14]]4 10 02https://esolangs.org/w/index.php?diff=123677&oldid=123676 5* 03Rottytooth 5* (+997) 10/* Examples */ > 1708442058 69503 PRIVMSG #esolangs :14[[07FatFinger14]]4 10 02https://esolangs.org/w/index.php?diff=123678&oldid=123677 5* 03Rottytooth 5* (+819) 10Filled out overview > 1708442699 444026 PRIVMSG #esolangs :14[[07FatFinger14]]4 10 02https://esolangs.org/w/index.php?diff=123679&oldid=123678 5* 03Rottytooth 5* (+1221) 10Added Fat Dactyls > 1708443472 688659 PRIVMSG #esolangs :14[[07User:Rottytooth14]]4 10 02https://esolangs.org/w/index.php?diff=123680&oldid=123457 5* 03Rottytooth 5* (-23) 10 > 1708443830 392691 PRIVMSG #esolangs :14[[07Tare14]]4 10 02https://esolangs.org/w/index.php?diff=123681&oldid=123639 5* 03Ais523 5* (+39) 10/* See also */ another language based on similar principles > 1708444964 375698 PRIVMSG #esolangs :14[[07Olympus14]]4 N10 02https://esolangs.org/w/index.php?oldid=123682 5* 03Rottytooth 5* (+8078) 10Adding Olympus. Still needs additional detail > 1708445107 875154 PRIVMSG #esolangs :14[[07Olympus14]]4 M10 02https://esolangs.org/w/index.php?diff=123683&oldid=123682 5* 03Rottytooth 5* (+20) 10 > 1708446484 645252 PRIVMSG #esolangs :14[[07Captive14]]4 10 02https://esolangs.org/w/index.php?diff=123684&oldid=123435 5* 03Rottytooth 5* (-4) 10Moved name to box > 1708446679 176177 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03TheguywholetthedoGSout 5* 10New user account < 1708446717 159759 :amby!~ambylastn@31.205.89.228 JOIN #esolangs * :realname > 1708446807 723113 PRIVMSG #esolangs :14[[07Olympus14]]4 M10 02https://esolangs.org/w/index.php?diff=123685&oldid=123683 5* 03Rottytooth 5* (+48) 10/* Gods */ Formatting > 1708446888 587030 PRIVMSG #esolangs :14[[07FatFinger14]]4 M10 02https://esolangs.org/w/index.php?diff=123686&oldid=123679 5* 03Rottytooth 5* (+20) 10 > 1708447095 497145 PRIVMSG #esolangs :14[[07Olympus14]]4 M10 02https://esolangs.org/w/index.php?diff=123687&oldid=123685 5* 03Rottytooth 5* (+0) 10/* Building A Program */ > 1708447678 542353 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=123688&oldid=123630 5* 03Rottytooth 5* (+114) 10Added missing langs > 1708447809 383497 PRIVMSG #esolangs :14[[07Velato14]]4 10 02https://esolangs.org/w/index.php?diff=123689&oldid=108925 5* 03Rottytooth 5* (+292) 10Added ref box > 1708447820 81367 PRIVMSG #esolangs :14[[07Velato14]]4 10 02https://esolangs.org/w/index.php?diff=123690&oldid=123689 5* 03Rottytooth 5* (-20) 10 > 1708447863 602469 PRIVMSG #esolangs :14[[07Velato14]]4 M10 02https://esolangs.org/w/index.php?diff=123691&oldid=123690 5* 03Rottytooth 5* (-1) 10 > 1708447904 740856 PRIVMSG #esolangs :14[[07Velato14]]4 M10 02https://esolangs.org/w/index.php?diff=123692&oldid=123691 5* 03Rottytooth 5* (+8) 10 < 1708449720 889295 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User > 1708449886 590663 PRIVMSG #esolangs :14[[07N1014]]4 N10 02https://esolangs.org/w/index.php?oldid=123693 5* 03AnotherUser05 5* (+263) 10Created page with "{{wrongtitle|title=n10}} '''n10''' is an esolang invented by [[User:AnotherUser05]]. ==Syntax== Every command is one character followed by a numerical, conditional, or math input. o - Print the ASCII value. n - Print the value. i - Returns the user's input." > 1708450418 599976 PRIVMSG #esolangs :14[[07Graphene14]]4 10 02https://esolangs.org/w/index.php?diff=123694&oldid=123540 5* 03Baltdev 5* (+2) 10 < 1708450921 501124 :__monty__!~toonn@user/toonn QUIT :Quit: leaving > 1708451646 217092 PRIVMSG #esolangs :14[[07Graphene14]]4 10 02https://esolangs.org/w/index.php?diff=123695&oldid=123694 5* 03Baltdev 5* (+361) 10/* Structure */ < 1708452968 572974 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… > 1708452980 665725 PRIVMSG #esolangs :14[[07Graphene14]]4 10 02https://esolangs.org/w/index.php?diff=123696&oldid=123695 5* 03Baltdev 5* (+97) 10/* Layout */ > 1708452987 631517 PRIVMSG #esolangs :14[[07Graphene14]]4 10 02https://esolangs.org/w/index.php?diff=123697&oldid=123696 5* 03Baltdev 5* (+1) 10/* Layout */ > 1708453468 776803 PRIVMSG #esolangs :14[[07Graphene14]]4 10 02https://esolangs.org/w/index.php?diff=123698&oldid=123697 5* 03Baltdev 5* (+90) 10/* Layout */ < 1708454643 672126 :SGautam!uid286066@id-286066.ilkley.irccloud.com QUIT :Quit: Connection closed for inactivity > 1708456881 253607 PRIVMSG #esolangs :14[[07Light Pattern14]]4 10 02https://esolangs.org/w/index.php?diff=123699&oldid=41102 5* 03Rottytooth 5* (+282) 10Added info box > 1708456897 565782 PRIVMSG #esolangs :14[[07Light Pattern14]]4 M10 02https://esolangs.org/w/index.php?diff=123700&oldid=123699 5* 03Rottytooth 5* (+1) 10 > 1708456925 9932 PRIVMSG #esolangs :14[[07Light Pattern14]]4 M10 02https://esolangs.org/w/index.php?diff=123701&oldid=123700 5* 03Rottytooth 5* (+8) 10 > 1708457189 767926 PRIVMSG #esolangs :14[[07Folders14]]4 10 02https://esolangs.org/w/index.php?diff=123702&oldid=123509 5* 03Rottytooth 5* (+27) 10added info box, shortened summary < 1708457926 588154 :esolangs!~esolangs@techne.zem.fi JOIN #esolangs esolangs :esolangs.org < 1708457926 992295 :ChanServ!ChanServ@services.libera.chat MODE #esolangs +v :esolangs > 1708458189 941811 PRIVMSG #esolangs :14[[07Time Out14]]4 10 02https://esolangs.org/w/index.php?diff=123703&oldid=74978 5* 03Rottytooth 5* (+524) 10Added info box > 1708458365 895021 PRIVMSG #esolangs :14[[07Entropy14]]4 10 02https://esolangs.org/w/index.php?diff=123704&oldid=123418 5* 03Rottytooth 5* (+291) 10added info box < 1708460140 481263 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1708460461 970424 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User > 1708460521 15360 PRIVMSG #esolangs :14[[07Captive14]]4 10 02https://esolangs.org/w/index.php?diff=123705&oldid=123684 5* 03Rottytooth 5* (+104) 10/* Hi */ < 1708460798 438300 :Thelie!~Thelie@2a03:2260:300c:400:d115:ecfe:1ef4:7596 JOIN #esolangs Thelie :Thelie > 1708460828 499266 PRIVMSG #esolangs :14[[07Entropy14]]4 M10 02https://esolangs.org/w/index.php?diff=123706&oldid=123704 5* 03Rottytooth 5* (+39) 10 < 1708463951 527252 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1708464228 466928 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User > 1708465746 935462 PRIVMSG #esolangs :14[[07Mode Spam14]]4 10 02https://esolangs.org/w/index.php?diff=123707&oldid=123618 5* 03EvyLah 5* (+55) 10file extension .modespam > 1708465760 424344 PRIVMSG #esolangs :14[[07Mode Spam14]]4 M10 02https://esolangs.org/w/index.php?diff=123708&oldid=123707 5* 03EvyLah 5* (+0) 10 > 1708466001 365408 PRIVMSG #esolangs :14[[07N1014]]4 M10 02https://esolangs.org/w/index.php?diff=123709&oldid=123693 5* 03PythonshellDebugwindow 5* (+78) 10Lowercase, stub, categories > 1708466008 839643 PRIVMSG #esolangs :14[[07N1014]]4 M10 02https://esolangs.org/w/index.php?diff=123710&oldid=123709 5* 03PythonshellDebugwindow 5* (+1) 10o > 1708467388 748116 PRIVMSG #esolangs :14[[07FatFinger14]]4 M10 02https://esolangs.org/w/index.php?diff=123711&oldid=123686 5* 03Rottytooth 5* (+4) 10/* FizzBuzz */ < 1708467441 959517 :Koen_!~Koen@2a01:e34:ec7c:30:e0e8:d417:48bd:7aab JOIN #esolangs * :Koen > 1708467459 96387 PRIVMSG #esolangs :14[[07FatFinger14]]4 M10 02https://esolangs.org/w/index.php?diff=123712&oldid=123711 5* 03Rottytooth 5* (+23) 10/* 99 Bottles */ > 1708467469 692933 PRIVMSG #esolangs :14[[07Mode Spam14]]4 10 02https://esolangs.org/w/index.php?diff=123713&oldid=123708 5* 03EvyLah 5* (+220) 10added some stuff to mode 5 to not make it look useless > 1708467489 78430 PRIVMSG #esolangs :14[[07Mode Spam14]]4 10 02https://esolangs.org/w/index.php?diff=123714&oldid=123713 5* 03EvyLah 5* (+2) 10I forgot to include the number > 1708467975 182234 PRIVMSG #esolangs :14[[07Stasis14]]4 10 02https://esolangs.org/w/index.php?diff=123715&oldid=107735 5* 03Rottytooth 5* (+445) 10added info box > 1708468552 966163 PRIVMSG #esolangs :14[[07User:Rottytooth14]]4 10 02https://esolangs.org/w/index.php?diff=123716&oldid=123680 5* 03Rottytooth 5* (+27) 10 > 1708468761 107386 PRIVMSG #esolangs :14[[07Sound14]]4 10 02https://esolangs.org/w/index.php?diff=123717&oldid=123651 5* 03Rottytooth 5* (+25) 10Added to See Also > 1708468847 682612 PRIVMSG #esolangs :14[[07N1014]]4 10 02https://esolangs.org/w/index.php?diff=123718&oldid=123710 5* 03AnotherUser05 5* (+588) 10 > 1708468870 161024 PRIVMSG #esolangs :14[[07N1014]]4 10 02https://esolangs.org/w/index.php?diff=123719&oldid=123718 5* 03AnotherUser05 5* (-1) 10 > 1708468888 880889 PRIVMSG #esolangs :14[[07User:Rottytooth14]]4 10 02https://esolangs.org/w/index.php?diff=123720&oldid=123716 5* 03Rottytooth 5* (+136) 10 > 1708469044 866542 PRIVMSG #esolangs :14[[07BrainTravel14]]4 10 02https://esolangs.org/w/index.php?diff=123721&oldid=122436 5* 03AnotherUser05 5* (+42) 10 > 1708469076 942313 PRIVMSG #esolangs :14[[07Ice box14]]4 10 02https://esolangs.org/w/index.php?diff=123722&oldid=123318 5* 03AnotherUser05 5* (+0) 10 > 1708469143 885356 PRIVMSG #esolangs :14[[07JustWords14]]4 10 02https://esolangs.org/w/index.php?diff=123723&oldid=123204 5* 03AnotherUser05 5* (+32) 10 > 1708469273 81968 PRIVMSG #esolangs :14[[07Laser Pointer14]]4 10 02https://esolangs.org/w/index.php?diff=123724&oldid=123352 5* 03AnotherUser05 5* (+55) 10 > 1708469354 394293 PRIVMSG #esolangs :14[[07Sword14]]4 10 02https://esolangs.org/w/index.php?diff=123725&oldid=123258 5* 03AnotherUser05 5* (+45) 10 > 1708469413 472885 PRIVMSG #esolangs :14[[07User:AnotherUser0514]]4 10 02https://esolangs.org/w/index.php?diff=123726&oldid=123388 5* 03AnotherUser05 5* (+10) 10 > 1708469538 469696 PRIVMSG #esolangs :14[[07N1014]]4 10 02https://esolangs.org/w/index.php?diff=123727&oldid=123719 5* 03AnotherUser05 5* (+95) 10/* Syntax */ > 1708469658 991711 PRIVMSG #esolangs :14[[07JustWords14]]4 10 02https://esolangs.org/w/index.php?diff=123728&oldid=123723 5* 03AnotherUser05 5* (+0) 10 > 1708469673 137185 PRIVMSG #esolangs :14[[07Olympus14]]4 10 02https://esolangs.org/w/index.php?diff=123729&oldid=123687 5* 03Rottytooth 5* (+507) 10/* Concept */ > 1708469777 376236 PRIVMSG #esolangs :14[[07User:Rottytooth14]]4 10 02https://esolangs.org/w/index.php?diff=123730&oldid=123720 5* 03Rottytooth 5* (+15) 10 > 1708469812 740274 PRIVMSG #esolangs :14[[07User:Rottytooth14]]4 10 02https://esolangs.org/w/index.php?diff=123731&oldid=123730 5* 03Rottytooth 5* (+11) 10 > 1708469848 220896 PRIVMSG #esolangs :14[[07User:Rottytooth14]]4 10 02https://esolangs.org/w/index.php?diff=123732&oldid=123731 5* 03Rottytooth 5* (+1) 10 < 1708469872 710695 :simcop2387!~simcop238@perlbot/patrician/simcop2387 QUIT :Quit: ZNC 1.8.2+deb3.1 - https://znc.in < 1708469872 838320 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot QUIT :Quit: ZNC 1.8.2+deb3.1 - https://znc.in > 1708469986 141197 PRIVMSG #esolangs :14[[07User:Rottytooth14]]4 10 02https://esolangs.org/w/index.php?diff=123733&oldid=123732 5* 03Rottytooth 5* (+31) 10 > 1708470178 568232 PRIVMSG #esolangs :14[[07User:Rottytooth14]]4 10 02https://esolangs.org/w/index.php?diff=123734&oldid=123733 5* 03Rottytooth 5* (+12) 10 > 1708470797 117339 PRIVMSG #esolangs :14[[07Cree14]]4 N10 02https://esolangs.org/w/index.php?oldid=123735 5* 03Rottytooth 5* (+2415) 10Added Cree#, a work in progress by Jon Corbett < 1708471075 795677 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname > 1708471123 17458 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=123736&oldid=123688 5* 03Rottytooth 5* (+17) 10 < 1708471139 341266 :simcop2387!~simcop238@perlbot/patrician/simcop2387 JOIN #esolangs simcop2387 :ZNC - https://znc.in < 1708471221 799028 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot JOIN #esolangs perlbot :ZNC - https://znc.in > 1708471469 700135 PRIVMSG #esolangs :14[[07User:Rottytooth14]]4 10 02https://esolangs.org/w/index.php?diff=123737&oldid=123734 5* 03Rottytooth 5* (+12) 10 > 1708471583 696629 PRIVMSG #esolangs :14[[07Cree14]]4 10 02https://esolangs.org/w/index.php?diff=123738&oldid=123735 5* 03Rottytooth 5* (+9) 10 > 1708471672 400299 PRIVMSG #esolangs :14[[07Cree14]]4 10 02https://esolangs.org/w/index.php?diff=123739&oldid=123738 5* 03Rottytooth 5* (+51) 10 > 1708471824 198298 PRIVMSG #esolangs :14[[07Cree14]]4 10 02https://esolangs.org/w/index.php?diff=123740&oldid=123739 5* 03Rottytooth 5* (+39) 10