< 1697761410 67399 :we11en!~we11en@user/utoneq JOIN #esolangs zut :we11en < 1697761701 971842 :we11en!~we11en@user/utoneq QUIT :Ping timeout: 255 seconds < 1697761753 315029 :we11en!~we11en@user/utoneq JOIN #esolangs zut :we11en < 1697763503 685721 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1697763542 285738 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 255 seconds < 1697763586 886440 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 NICK :Lord_of_Life < 1697777325 27368 :we11en!~we11en@user/utoneq QUIT :Quit: Lost terminal < 1697781348 606022 :we11en!~we11en@user/utoneq JOIN #esolangs zut :we11en < 1697782529 330738 :we11en!~we11en@user/utoneq QUIT :Quit: Lost terminal < 1697782692 427706 :wpa!uid568065@id-568065.helmsley.irccloud.com JOIN #esolangs WeepingAngel :wpa < 1697783191 737648 :chiselfuse!~chiselfus@user/chiselfuse QUIT :Read error: Connection reset by peer < 1697783210 604525 :chiselfuse!~chiselfus@user/chiselfuse JOIN #esolangs chiselfuse :chiselfuse > 1697784881 494935 PRIVMSG #esolangs :14[[07Language list14]]4 M10 02https://esolangs.org/w/index.php?diff=118122&oldid=118007 5* 03Peter01 5* (-20) 10/* H */ Please, stop. < 1697787452 624976 :craigo!~craigo@user/craigo JOIN #esolangs craigo :realname < 1697790041 384612 :arseniiv!~arseniiv@188.64.15.98 JOIN #esolangs arseniiv :the chaotic arseniiv < 1697790170 401974 :__monty__!~toonn@user/toonn JOIN #esolangs toonn :Unknown < 1697791473 248323 :Koen!~Koen@2a01:e34:ec7c:30:5db3:4a43:ec04:d365 JOIN #esolangs * :Koen > 1697794873 297785 PRIVMSG #esolangs :14[[07User:Cinnamony14]]4 M10 02https://esolangs.org/w/index.php?diff=118123&oldid=118110 5* 03None1 5* (-11) 10/* Picture */ < 1697795709 838727 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer < 1697796249 211010 :int-e!~noone@int-e.eu PRIVMSG #esolangs :b_jonas: you might enjoy this: https://int-e.eu/~bf3/tmp/shapez-cursed-white.png > 1697797034 389574 PRIVMSG #esolangs :14[[07CFR14]]4 M10 02https://esolangs.org/w/index.php?diff=118124&oldid=118116 5* 03None1 5* (+23) 10 > 1697797706 609503 PRIVMSG #esolangs :14[[073 Bits, 3 Bytes14]]4 N10 02https://esolangs.org/w/index.php?oldid=118125 5* 03None1 5* (+1082) 10Create language > 1697797729 199793 PRIVMSG #esolangs :14[[073 Bits, 3 Bytes14]]4 M10 02https://esolangs.org/w/index.php?diff=118126&oldid=118125 5* 03None1 5* (+1) 10 > 1697798104 168379 PRIVMSG #esolangs :14[[073 Bits, 3 Bytes14]]4 10 02https://esolangs.org/w/index.php?diff=118127&oldid=118126 5* 03None1 5* (+221) 10 > 1697798137 525870 PRIVMSG #esolangs :14[[073 Bits, 3 Bytes14]]4 M10 02https://esolangs.org/w/index.php?diff=118128&oldid=118127 5* 03None1 5* (+0) 10 > 1697798179 740145 PRIVMSG #esolangs :14[[073 Bits, 3 Bytes14]]4 10 02https://esolangs.org/w/index.php?diff=118129&oldid=118128 5* 03None1 5* (+51) 10 > 1697798233 830178 PRIVMSG #esolangs :14[[07Joke language list14]]4 10 02https://esolangs.org/w/index.php?diff=118130&oldid=118095 5* 03None1 5* (+61) 10/* General languages */ > 1697798244 806680 PRIVMSG #esolangs :14[[07User:None114]]4 10 02https://esolangs.org/w/index.php?diff=118131&oldid=118101 5* 03None1 5* (+61) 10/* My Esolangs */ < 1697798266 84072 :wpa!uid568065@id-568065.helmsley.irccloud.com QUIT :Quit: Connection closed for inactivity > 1697798475 499872 PRIVMSG #esolangs :14[[07User:None114]]4 M10 02https://esolangs.org/w/index.php?diff=118132&oldid=118131 5* 03None1 5* (+0) 10/* My Esolangs */ > 1697798527 683295 PRIVMSG #esolangs :14[[073 Bits, 3 Bytes14]]4 10 02https://esolangs.org/w/index.php?diff=118133&oldid=118129 5* 03None1 5* (+34) 10 < 1697800097 385060 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas < 1697800122 388474 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :int-e: does that break by getting desynchronized when you save and load? < 1697800154 209520 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :it really is cursed, usually you want white paint in a large amount so it's not worth to multiplex a single painter for it, and this doesn't even save space < 1697800158 90366 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :s/painter/mixer/ < 1697800200 383300 :int-e!~noone@int-e.eu PRIVMSG #esolangs :wib_jonas: It survived my reload test. But it'll still desync whenever you hold it wrong. And yes, the throughput is half of what you'd get with two mixers so it's really just a curiosity. < 1697800232 746902 :int-e!~noone@int-e.eu PRIVMSG #esolangs :My first uploaded version couldn't even be reset properly, but I fixed that :-) < 1697800415 747435 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :if it's not practical, can you turn it into a puzzle instead? < 1697801597 464 :int-e!~noone@int-e.eu PRIVMSG #esolangs :No, because puzzles don't have mergers or balancers. (They *do* have double painters though which sort-of can merge shapes, and people abuse that quite a bit.) < 1697801849 301920 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I believe that design choice is actually a good one... there's just too much crazy things you can do with balancers and they tend to be extremely tricky to balance. < 1697802258 414010 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :makes sense < 1697808373 835908 :cpressey!~cpressey@host-92-10-146-234.as13285.net JOIN #esolangs cpressey :[https://web.libera.chat] cpressey < 1697810688 368211 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1697811177 832595 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :hi ais523 < 1697812556 539803 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu QUIT :Quit: Client closed < 1697812665 587395 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hi cpressey < 1697812684 633883 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :do you logread? I replied to your questions from a couple of days ago in the logs, but you weren't online, and I don't know whether you read them < 1697812702 730563 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :https://logs.esolangs.org/libera-esolangs/2023-10-18.html#lLe < 1697812840 419052 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :Oh sorry, yes, I saw your response, thank you.  Then I kind of forgot about it... < 1697812878 443624 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fwiw I have been wondering about fun things like "an entirely branchless lexer+parser combination" (where the only branch is to handle EOF) < 1697812891 783752 :river!river@tilde.team/user/river PRIVMSG #esolangs ::O < 1697812893 427357 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and the same code does both the lexing and hte parsing < 1697812915 932238 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :
ACTION posts a squinting-Fry reaction gif
< 1697812921 114236 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is of course possible in theory because branchless programming is TC, but I'm wondering whether it might be possible to get it more efficient than a traditional parser < 1697812965 17275 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :something like yacc has to have branches everywhere on whether it's read a lookahead token or not – ironically, just reading it unconditionally would probably be more efficient, because you wouldn't have to check whether you'd done it or not < 1697812990 301733 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :I don't know much about branchless but I can imagine a sort of thing where you turn all the parsing operations into matrix operations or something < 1697813036 50462 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but, it would change the semantics because you could no longer get the parser to change the way the next token was lexed (only the one after) < 1697813036 75121 :ais523!~ais523@user/ais523 QUIT :Remote host closed the connection < 1697813050 506035 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1697813123 820719 :ais523!~ais523@user/ais523 QUIT :Client Quit < 1697813138 566763 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1697813165 117069 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one thing that I have realised is that there are only finitely many possible states for the lookahead tokens to be in (for most standard parser types – LL(*) is an exception) < 1697813189 632705 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so you could in theory combine them with the parser states < 1697813234 662742 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I am not sure whether this would cause a combinational explosion – it's quite possible that it doesn't, because you wouldn't have to be able to store lookahead tokens that would inevitably cause an error anyway, you can just produce the error on the spot < 1697813385 524886 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :If you're talking LL(1) you can compute the FIRST set of each production, which is usually small.  Combining this with the set of all the productions would usually lead to a huge product set, I don't think. < 1697813396 74679 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :*wouldn't < 1697813473 143996 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, and LR(1) is similar – canonical LR(1) has a lookahead set for each production, which again is usually small, and holds all the symbols that can possibly correctly appear in lookahead < 1697813511 224220 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which implies that the various compressed LR(1) formats, like LALR(1), could also handle it < 1697813749 539083 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :So one thing I've heard is that "recursive descent is better than LR in modern world because the LR lookup tables for realistically sized grammars don't fit in cache lines".  This was a long time ago though, maybe 20 years ago.  I don't know if it was then true or is still true. < 1697813782 403820 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :I also heard that the Lua team replaced their yacc parser with a hand-crafted RDP and the speedup was significant, something like 2x < 1697813831 995043 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think of LR grammars as having a large LR table, but it's compressed for storage and used in the compressed form < 1697813840 199588 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and think that parsers can be optimised by finding better ways to compress it < 1697813851 723596 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :looking at LR tables generated by yacc and friends, there is a lot of repetition < 1697813899 499414 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I also think recursive descent parsers use more cache than the typical LR table does, but it's L1c rather than L1d, which may matter – there is normally less pressure on the code cache while parsing than on the data cache < 1697813940 796708 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :I generally don't work on this level of optimization, anyway; for me "efficient" means "in P instead of in EXPTIME" :) < 1697814355 784129 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :I'm working on a grammar formalism, but it's not for building parsers; it's a lot like an attribute grammar or DCG, the main improvement over these being that it can generate strings as efficiently as it can parse them.  (again, "efficiently" meaning "avoiding exponential blowup") < 1697814413 907295 :Thelie!~Thelie@2a03:2260:300c:400:61bd:fe2e:1f3c:b90a JOIN #esolangs Thelie :Thelie < 1697814477 985466 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :You can run a DCG "forwards or backwards" in a relational programming language like Prolog or miniKanren to do this, but if it's efficient in one direction (parsing) it will be inefficient in the other direction (generation). < 1697814498 842964 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :(I don't have a proof of this but this was my experience from playing with it extensively) < 1697814689 601770 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :cpressey: oh, that's interesting < 1697814727 130523 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one of the things I was looking at was the possibility of bootstrapping a parser, and an idea I had to do that was to write the parser in Prolog < 1697814735 848379 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and have it generate its own source code by unparsing itself < 1697814745 769796 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I didn't actually get it to work beyond a small proof of concept < 1697814760 373575 :b_jonas!~x@89.134.28.176 QUIT :Ping timeout: 252 seconds < 1697814765 478032 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so I'm not sure what the efficiency was like < 1697814814 285113 :b_jonas!~x@89.134.28.176 JOIN #esolangs * :b_jonas < 1697814958 190575 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but yes, I don't normally work on this level of optimization either, but thought it would be a fun (and potentially practically useful) followup to the fizzbuzz > 1697815946 749242 PRIVMSG #esolangs :14[[07Jack Eisenmann14]]4 M10 02https://esolangs.org/w/index.php?diff=118134&oldid=50339 5* 03PythonshellDebugwindow 5* (+30) 10Stub, category < 1697816935 327415 :Thelie!~Thelie@2a03:2260:300c:400:61bd:fe2e:1f3c:b90a QUIT :Ping timeout: 264 seconds < 1697817634 219921 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :I'm having a heck of a time getting backtracking right in the generation case.  I probably need to step back. < 1697817727 218507 :Thelie!~Thelie@2a03:2260:300c:400:d115:ecfe:1ef4:7596 JOIN #esolangs * :Thelie < 1697817820 772068 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :If I can do it, though, it ought to be neat.  To be able to write a grammar that can solve knapsack problems.  That sort of thing. < 1697817874 586036 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :I think I'm missing the fact that a loop can have three outcomes: it can terminal successfully, it can fail (and cause backtracking in the enclosing context), or it can repeat (and then you ask this question again and get these three outcomes again) < 1697817881 576417 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :*terminate < 1697817893 684784 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :maybe it'd be easier to generate in parallel rather than using backtracking? < 1697817906 671606 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(this is comparable to using a call queue rather than a call stack) < 1697817980 465311 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :Well, in some ways that would be nicer, yes -- like miniKanren, you won't get stuck in an infinite DFS. < 1697817999 917097 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :But the flipside is that you can start being a memory hog! < 1697818157 181287 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes, it's probably bad from a memory point of view unless you can compress the storage somehow < 1697818243 479294 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :At some point earlier this year I ended up reading GOFAI textbooks trying to understand if "truth management" could be used to narrow down the search space for that sort of thing. < 1697818331 62864 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :Which was somewhat interesting, actually, because in the modern world those algorithms no longer look like "artificial intelligence", they just look like search space optimization < 1697818343 375893 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas < 1697818353 873808 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :cpressey: "because the LR lookup tables for realistically sized grammars don't fit in cache lines" => yes, and that's why I don't think a branchless parser is such a good idea < 1697818452 676744 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, one cache line is 64 bytes, and the L1 data cache as a whole is normally 32 KiB < 1697818464 589210 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you can't fit a parser into the former, but the latter seems plausible < 1697818527 679043 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :anyway, I think the real problem is handling output from the parser efficiently < 1697818545 755045 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :normally parsers are used to build a tree-structured AST, but that's inherently slow < 1697818555 65441 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :wib_jonas: what if you could turn it into a numerical matrix problem (insert lots of handwaving here) and run it on the GPU though? < 1697818601 963282 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :actually, I think someone did something like that for parsing JSON < 1697818843 204464 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :I was apparently thinking of "simdjson".  But it looks like ppl have tried using GPU to parse CSV and JSON.  But these are very specialized approaches, a general approach feels very much like it still requires a lot of handwaving < 1697818973 387432 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :GPUs don't obviously map well to most parsing algorithms < 1697818988 574532 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :they might be good at the algorithm used for DCGs, that one feels somewhat parallel in spirit < 1697819055 495788 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it feels weird trying to use a GPU to speed up something that's linear-time anyway, though < 1697819381 591886 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :Well, the algorithm for DCGs is no different than the rest of Prolog; it's basically syntax sugar for inference rules.  I tried search for GPU-accelerated inference engines and all the results are AI stuff, because that's what "inference engine" means in 2023. < 1697819650 30580 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I said the wrong thing, I didn't mean DCGs but PCGs < 1697819655 909881 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :err, PEGs < 1697820055 635778 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :Ah.  Hm, well PEGs backtrack, but they use ordered choice, which doesn't feel very parallel-y to me; I assumed that it was generally implemented linearly with some kind of DFS.  But I haven't looked at their implementation.  ("packrat parsing" is it?) < 1697820097 730760 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's basically dynamic programming < 1697820100 745514 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :My brain wants to say "how is this not dynamic programming / memoization all over again" < 1697820114 217874 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :Exactly < 1697820134 658701 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but the reason it's linear time is that there are only finitely many things that could be memoized per token of input < 1697820146 61300 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so, instead of memoizing on demand, you could possibly calculate them all in parallel < 1697820235 352089 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :GPUs don't require the things they're calculating in parallel to be entirely independent, just to have similar code – the various threads are allowed to communicate with each other, and in some special cases can do so very efficiently < 1697820373 723456 :cpressey!~cpressey@host-92-10-146-234.as13285.net PRIVMSG #esolangs :(I think I see my confusion regarding backtracking generation now - but now I don't understand how I thought the backtracking parsing part was working - I might've chosen a bad example to use as a test) < 1697821039 321680 :cpressey!~cpressey@host-92-10-146-234.as13285.net QUIT :Quit: Client closed < 1697821791 665859 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :hmm, so you're saying that how he GPU parsing would work like this. for each n from 0 to logarithm, you split the document to 2**n long infixes, and parse each of those infixes starting from each parser state. if 0==n then you just look up the transition rules, whereas for 0 1697832201 982893 PRIVMSG #esolangs :14[[07User talk:None114]]4 M10 02https://esolangs.org/w/index.php?diff=118135&oldid=116873 5* 03TheBigH 5* (+361) 10 < 1697832286 465535 :__monty__!~toonn@user/toonn JOIN #esolangs toonn :Unknown < 1697833198 107278 :Koen!~Koen@2a01:e34:ec7c:30:89b8:4b7c:cfe1:c2c JOIN #esolangs * :Koen < 1697834562 791187 :__monty__!~toonn@user/toonn QUIT :Quit: leaving < 1697837366 482359 :Thelie!~Thelie@2a03:2260:300c:400:d115:ecfe:1ef4:7596 QUIT :Quit: Leaving. < 1697837371 181148 :Thelie1!~Thelie@185.66.193.30 JOIN #esolangs * :Thelie < 1697837381 734672 :craigo!~craigo@user/craigo QUIT :Ping timeout: 260 seconds < 1697842775 442116 :Koen!~Koen@2a01:e34:ec7c:30:89b8:4b7c:cfe1:c2c QUIT :Remote host closed the connection < 1697842952 325163 :Koen!~Koen@2a01:e34:ec7c:30:3de7:fa73:cbaf:2b5 JOIN #esolangs * :Koen < 1697844248 592727 :Koen!~Koen@2a01:e34:ec7c:30:3de7:fa73:cbaf:2b5 QUIT :Quit: Leaving... < 1697845109 274030 :Thelie1!~Thelie@185.66.193.30 QUIT :Ping timeout: 255 seconds