< 1773273629 580155 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :Mathematica is somewhat like scheme where you can define ordinary functions that take their arguments by value, or macro-like functions that take their arguments unevaluated, and there's a third kind that takes only the first argument unevaluated. < 1773273633 8278 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the basic problem is that Prolog's closest equivalents to closures/lambdas are super-awkward < 1773273689 451477 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that said, something like Brachylog could do a while loop pretty easily – I wonder if it has one? < 1773273849 34204 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :looks like it doesn't have one: I suppose it has enough other types of loops that they usually aren't necessary, so nobody really noticed < 1773273880 516890 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :you can write all sorts of looping library functions that doesn't require mutable variables, similar to in haskell < 1773273888 108519 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I mean you can do that in prolog < 1773273894 995257 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :actually ⁱ can be viewed as a do-while loop, but a weirdly written one < 1773273915 597656 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it repeatedly runs the predicate/block it applies to until the rest of the program succeeds < 1773273958 868794 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(Brachylog doesn't have mutable state even though Prolog does) < 1773274125 114453 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, this discussion reminds me – I have decided that it is usually better for assignment operators to assign rightwards, i.e. 2 → x rather than x := 2 < 1773274176 651551 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: is that in languages that are usually formatted right-aligned, so you can scan the more straight right edge of the code for where a variable is assigned to? < 1773274186 277874 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :or also in languages that are formatted left-aligned? < 1773274194 104091 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: both, I hadn't thought about alignment < 1773274197 424474 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :this matters if you type the code from left to right < 1773274208 467542 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I can see an argument that you might want to make it clear when each variable is written to < 1773274232 271722 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I want a language that's right-aligned and not just assignements are on the right but the function is usually on the right of its arguments < 1773274249 534607 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :or a backwards APL-like where a function is usually after its first argument < 1773274251 978307 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, interesting < 1773274259 887397 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :function after first argument, I agree < 1773274288 445277 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think more and more languages are moving in that direction (but not enough of them and not quickly enough) < 1773274288 563916 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :this is annoying because you need to modify your editor for it < 1773274371 225032 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in a golfing language I've been working on, the top level of the program is written in such a way that the output of each statement is implicitly the first argument of the next statement, which isn't explicitly specified < 1773274404 334893 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(it uses forward-Polish for the remaining arguments, although usually degenerate cases of it) < 1773274481 346714 :pool!~nathan@user/PoolloverNathan QUIT :Read error: Connection reset by peer < 1773274514 62159 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :Enchain is defined to support both a left-aligned and a right-aligned mode, but probably only in the language definition -- since I don't have a right-aligned edition it's unlikely that I'll actually use or implement the right aligned mode. In Enchain arguments can always be either before or after functions. But there's a scoping operator that I haven't talked of yet, which lets you create local < 1773274520 69981 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :variables sort of like C scope braces. In left-aligned mode (wimpmode) variables on the column of the opening brace or to the right are local; in right-aligned mode (turtle mode) variables on the column of the opening brace and to the left of it are local. This makes the two modes assymetric, but I think is the right way for braces to work in either case. < 1773274642 617225 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :how does indentation work in a right-aligned language? < 1773274646 331220 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :The local variables are both unrelated to any variable in the same column mentioned outside of the pair of braces, and if the braces are in a function body then their lifetime is restricted to the function call but if the function is called multiple times recursively then there's a separate copy of each call stack. < 1773274703 654334 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :plenty of editors can do right-alignment; basically all word processors can, and HTML textarea probably can too < 1773274719 484466 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and almost certainly Emacs although I'm not sure how to configure it like that < 1773274826 468337 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: yes, but most editors aren't too helpful in editing something like Enchain where the specific columns matter because columns work like variable names, and I think the few editors that have a mode that help there don't do right-aligned across variable line lengths, so the best you can do is edit fixed line lengths then remove the spaces from the beginning of all lines. < 1773274859 352561 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :don't you just add trailing spaces to push a line further to the left? < 1773274880 967991 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :also I believe that no word processor supports tabs in right-aligned mode the way Enchain expects them, but of course tabs are optional and this is academic because nobody will write code with tabs because we don't have the tools to edit them. < 1773274895 288636 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: yes, you add trailing spaces to push the line further to the left < 1773274910 687397 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this seems to work: data:text/html, < 1773274940 492614 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :complete with trailing spaces to push lines leftwards < 1773274973 769170 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it doesn't accept tabs (although shouldn't such a system actually be using backtabs?) < 1773275011 289063 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: even without tabs it's hard: you need overwrite mode so you can change a character without changing other characters in the same line, < 1773275037 152444 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, you don't need it, I've done plenty of vertically aligned editing without (but it does help) < 1773275045 775170 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :and ideally you also want to be able to move the cursor down to get to the same column of a later line and write something in that line in a way where if the line is too short the editor inserts enough spaces to write in that column < 1773275069 212550 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :some editors can do these in left-aligned mode at least, but I don't know if any can do it in right-aligned mode directly < 1773275089 68326 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :yeah < 1773275205 358226 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :if you really want then in theory can write programs in a language like enchain on programming paper with a pre-printed grid then transcribe them to punch cards (though Enchain uses ASCII character set so you need a punched card representation for backtick and tilde and caret etc) < 1773275225 156264 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :but you'll have fixed-width lines < 1773275266 634034 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :left-aligned is easier because a teletype can print variable-length left-aligned lines even if it doesn't have RAM, for printing right-aligned lines you need to buffer a line in RAM before actually printing it < 1773275307 544267 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :so there's a fundamental assymetry < 1773275356 525020 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :it doesn't matter today because every device today has enough RAM to buffer a line < 1773275402 263023 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :what about using RTL character order? < 1773275416 793443 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess that'd be annoying to type, though, so it'd only be useful as a transmission format < 1773275462 981800 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :then you just have the equivalent of a left-aligned language, it's not fundamentally different from an ordinary left-aligned language it's just mirrored < 1773275534 230894 :lynndotpy6093627!~rootcanal@134.122.123.70 JOIN #esolangs lynndotpy :lynn < 1773275581 264319 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :it's useful if most of your identifiers are in a natural language that's written right to left < 1773275588 613795 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot QUIT :Ping timeout: 244 seconds < 1773275592 107628 :perlbot_!~perlbot@perlbot/bot/simcop2387/perlbot JOIN #esolangs perlbot :ZNC - https://znc.in < 1773275639 678352 :lynndotpy609362!~rootcanal@134.122.123.70 QUIT :Ping timeout: 244 seconds < 1773275640 34284 :lynndotpy6093627!~rootcanal@134.122.123.70 NICK :lynndotpy609362 < 1773275678 121192 :perlbot_!~perlbot@perlbot/bot/simcop2387/perlbot NICK :perlbot < 1773276012 236042 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :there's a third direction: you can make an editor mode to write a language backwards compared to how its characters are represented in a file, like an editor that lets you write C code backwards so you type the arguments before the function, or the rvalue before the lvalue in an assignment. it's a bit tricky because you want to type each token forwards and the lexical syntax might not work backwards so < 1773276018 299311 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :you may have to type extra token separators sometimes, but it can mostly work. then other programmers and compilers can still read your program the way they're used to but you're typing it in a way that may make more sense. < 1773276083 22930 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :of course then comma/semicolon sequencing will be backwards for you, in an imperative program you type first the statement that's run later < 1773276129 76850 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :and in languages like C where the order of declarations matter, you'll have to type those backwards too, using a name before you declare it < 1773276182 954225 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :of course that's only the default, you can probably still type code in whatever order you want and jump around while editing < 1773276256 252297 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :Enchain is imperative where execution normally goes forwards in the same direction as the characters in code, < 1773276281 730965 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :modified of course by function calls and gotos. > 1773277110 194043 PRIVMSG #esolangs :14[[07Ima gte. Ima dana/Operation table14]]4 10 02https://esolangs.org/w/index.php?diff=177582&oldid=177550 5* 03BODOKE2801e 5* (+337) 10 > 1773277349 2908 PRIVMSG #esolangs :14[[07Ima gte. Ima dana/Operation table14]]4 10 02https://esolangs.org/w/index.php?diff=177583&oldid=177582 5* 03BODOKE2801e 5* (+51) 10 < 1773277412 825034 :amby!~ambylastn@host-78-151-24-174.as13285.net 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 < 1773281324 17031 :tromp!~textual@2001:1c00:3487:1b00:2807:b44c:c102:bda9 QUIT :Ping timeout: 252 seconds < 1773283508 512849 :joast!~joast@2603:90d8:500:31cf:5e0f:3f4b:1cfe:5060 QUIT :Quit: Leaving. > 1773289797 287245 PRIVMSG #esolangs :14[[07Bit-ter lang14]]4 N10 02https://esolangs.org/w/index.php?oldid=177584 5* 03BODOKE2801e 5* (+883) 10Created page with "'''Bit-ter lang''' is a [[Esolang]] made by [[User:BODOKE2801e]], it is memoryless and works on binary, and here's a joke about the lang: What is the most bitter lang? Bit-ter lang ==Commands=== ! is input 0 is false 1 is true | outputs the next thing ne < 1773293727 841463 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :Do you think it could work for a video card to work: Each window has a "frame program" and a "pixel program", which use different instruction sets; only the frame program has flow controls and the ability to write memory, but the pixel program has no flow controls, and there is a limit of how many instructions can be reads. (A window has several other properties as well, such as the colour index mask bits) < 1773294004 949093 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :current video cards are a bit like that but more advanced – I think it would work for a retrocomputing video card but wouldn't be able to compete with the current generation of video cards < 1773294144 586466 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm actually not sure what machine code video cards use internally because none of them let you write it directly, instead you give source code and there's a compiler in the driver < 1773294203 41800 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :zzo38: You want to run the frame programs on the GPU? The pixel programs sound a lot like fragment shaders, where "fragment" is just the GL term for pixel. < 1773294218 155719 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :(I do not have any desire to do such things as 3D graphics with lighting and that stuff in real time, although I do consider such things as security to be necessary (so that one window's programs cannot read or write the memory or parameters of other windows, unless some memory is assigned to multiple windows).) < 1773294242 642595 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :korvo: Yes, I did think the pixel program is similar to a fragment shader. < 1773294258 738938 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: They're just register machines with a basic return stack that allows for some loops and subroutines. There's not much magic. I can point you at some AMD/ATI datasheets if you want to look at ISAs. < 1773294327 939913 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :seems about right < 1773294330 87209 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :(The frame program might be used for such a thing as cursor blinking, although there might be other uses as well; many windows might not need a frame program.) < 1773294371 666347 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :zzo38's design doesn't have a vertex shader, but I think those are primarily useful for 3D graphics, so it makes sense to leave it out if that isn't a goal < 1773294391 326910 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The only interesting instructions to me compared to other DSPs are DDX and DDY, taking partial derivatives in screen space. These are done by running pixels in a 2x2 grid and taking finite differences. You can take the derivative of any local variable this way, which is kind of cool. This sort of thing is why GPUs can only render in 8x8 or 16x16 tiles. (Also tiled rendering's popular on embedded GPUs.) < 1773294475 361675 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :zzo38: There are some parts of the modern GPU that still work like that. At the extreme end, the hardware cursor's position is usually a pair of MMIO'd registers. I'm on Xorg, so every time I touch the mouse, Xorg gets a SIGIO, handles a USB event, and writes to MMIO. < 1773294663 17643 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :I might also have sprites (which only display a picture at a position and have no programs associated with it); the mouse cursor is a sprite bound to the root window. And then, also window sets (one of which is displayed at once); my idea for a computer and operating system design will probably need three (one for normal use, one for full screen applications, and one for the system special screen). < 1773294712 769483 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah, I didn't want to use the word "sprite" in case you weren't in that mindset, but it's the exact same concept. < 1773294784 487437 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It's worth knowing that the GPU used to have VGA. Like, literally there was a VGA BIOS and special VGA chips; when the card powered on, it would eventually get into a VGA mode. That stopped being the case in the 2010s. < 1773294861 482740 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Instead today the GPU starts in a kind of emergency mode that *maybe* emulates VGA a bit. The operating system is expected to boot the card. At the best end, Radeons and Intel chipsets require setting power policy and booting the 3D engine; at worst, nVidia famously requires a big opaque licensed blob which includes onboard memory management and a scheduler. < 1773294917 176218 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :...Sorry, that's an ambiguous phrase. The nVidia drivers have to compile and deliver a blob onto the GPU, a mix of microcode and GPU bytecode, before the GPU can pretend to be VGA or whatever. < 1773294998 707144 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :But this is how zzo38's frame programs might run. The frame program doesn't do any fragment handling directly, but it could still instruct the GPU's memory controller. < 1773295028 206341 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I think even nVidia GPUs are able to show bootloader comments during early boot, before the OS (which would contain the GPU driver) has loaded < 1773295059 486408 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although IIRC nowdays nVidia ships the blob in question on the graphics card itself rather than having the OS do it < 1773295116 615837 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: so it turns out that the rust devs are ahead of you and prepared for identifiers being insensitive to consonant voicing differences, and that's why they named the trait for the modulo operator std::ops::Rem instead of std::ops::Mod, because the latter would collide with std::ops::Not < 1773295127 685155 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The legendary cancelled Intel GPU board, Larrabee, would have been so cool here. Larrabee was literally about 120 Pentium 3 cores on a PCIe board. x86 is pretty good at describing memory hierarchies at a distance, so we could imagine that a frame program is just one dedicated GPU core which instructs shared memory controllers. This sort of dedicated scheduling would have to happen anyway for hundreds of cores. < 1773295131 987999 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: :-D < 1773295194 299404 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Yeah. To facilitate that, nVidia's policy is to open-source a basic boot driver for any operating system that pays them, and also for Linux and BSD as a show of goodwill. The driver, "nv", is full of magic numbers and is basically obfuscated. It *is* legal portable C, I guess. < 1773295198 619302 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: hmm, don't architectures like Knight's Landing have a lot in common with GPUs? < 1773295236 542282 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :But in the 2010s the GPUs started to change so that they no longer have 2D engines. They also are starting to drop video engines; it's all GPGPU again in the 2030s, I imagine. < 1773295248 886822 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although GPUs are more pervasively SIMD < 1773295277 979449 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :for really early GPUs I think of things like the NES PPU < 1773295285 800137 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which was extremely fixed-pipeline < 1773295307 710321 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: I guess? You hit it precisely; it's SIMD. It's also MIMD in some cases, like programming for the Cell on the Playstation 3. < 1773295336 103978 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I mean that I don't know much about Knight's Landing. I know a bit about AMD APUs, which are definitely more GPU-like. < 1773295394 406437 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :Wikipedia says 72 cores, 4 threads per core, and it does AVX-512 < 1773295404 480207 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so not really a GPGPU but moving in that sort of direction < 1773295410 43046 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Oh, have you heard of "supershaders"? There's this interesting pattern in GL 2 where emulation of GL 1.4 is best done by writing more-or-less the entire GL 1.4 rendering pipeline as a per-fragment process. One shader to rule them all. < 1773295413 138303 :chloetax!~chloe@user/chloetax QUIT :Ping timeout: 246 seconds < 1773295415 444235 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the cores themselves are just a fairly normal x86 but with weird performance properties) < 1773295438 39220 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I've heard of them but have trouble remembering the details < 1773295439 204576 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :Some of the window parameters might be a tile counter and the horizontal and vertical tile counter divider, to avoid needing multiplication and division for the common case of implementing a tiled screen (a PC text mode emulation would be one example of this). Some parameters (such as these) might be readable and writable by frame programs, while the window position would be a inaccessible parameter. < 1773295446 827220 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a sort of "compile once run anything" I think? < 1773295502 443580 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah, basically. The supershader is given a bunch of "uniforms" and "varyings", which are different ways of binding global variables. Also textures are bound in the normal way, TCL (transform, clipping, lighting) is done with standard per-vertex processing, etc. < 1773295598 393718 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Surprisingly, this is a correct way to do GL 1.4 emulation! It's fast enough. One might think that it's very expensive to send a literal packet of uniforms in the GPU's command buffer, but it's not. The expense is always in binding textures. < 1773295619 733235 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The Dolphin emulation suite uses supershaders, for a real-world example. < 1773295630 423644 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :is this the sort of thign where the architectures evolve for ten more years and suddenly you look at them and you can no longer tell which chip is supposed to be the CPU and which one the GPU because they've become so similar? < 1773295650 835697 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's basically the GPU version of an interpreter, by the sound of it < 1773295671 460228 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I'm not sure < 1773295682 314710 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there are always going to be programs that parallelize poorly < 1773295694 86509 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh, they didn't call them that. https://dolphin-emu.org/blog/2017/07/30/ubershaders/ < 1773295717 466795 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one program I'm working on is CPU-bound and embarassingly parallel but it can't reasonably make use of SIMD because it involves a lot of 64×64=128 multiplications < 1773295726 806576 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :x86-64 has a builtin for that but it only works on scalars < 1773295762 839208 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and I think vectorising the non-multiplication bits would cost more in moving bytes around than it would gain in parallelised arithmetic < 1773295767 52371 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :GPU drivers do not have good shader compilers. They have, at best, a slightly outdated copy of LLVM. I think that if somebody wants to wield libdrm directly, they could probably just emit their own bytecode. This is what makes shaders expensive to load. < 1773295804 570847 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The GPU doesn't really need to context switch. The GPU's expenses are all about updating memory: caches, mappings, DMA'd buffers. < 1773295879 255874 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :korvo: is it actually possible to emit your own bytecode and send it to the CPU in the sense that an operating system can let a user program do that and you can't use that to elevate permissions? < 1773295880 863523 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: Maybe one cursed part of this is subinterpreters. Like ais523 says, at some level this is about embedding an interpreter into the chip. x86 has an interpreter for x87, for example. amd64 has an interpreter for SSE. < 1773295890 587366 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, GPUs do need to context switch precisely because updating memory is slow, so they swap threads out while they're in the middle of a memory load < 1773295908 967422 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: Yes! Moreover, I can try to help you with that, and there's also an entire IRC channel (#dri-devel, they used to be called?) that can help. < 1773295943 709722 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :not at the moment, but good to know, thank you < 1773295990 915747 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :https://bpa.st/GWSRC here's ls on my /dev/dri. libdrm boils down to open() and ioctl(). Here you can see that if you have `video` or `render` group then you can do as you like. < 1773296046 819138 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :There is also a concept of DRM master and VGA arbiter. (Bless kernel folks for these names.) DRM master is a userspace process that gets early priority over the screen and preempts all other DRM/DRI clients; that's usually Xorg or Wayland, to give you an idea of what sorts of responsibilities you'd have. < 1773296087 757134 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :VGA arbiter is the idea that VGA BIOS comes with a lot of global state, so if you have two VGA adapters on your system then you need a global switch between them. This usually doesn't matter, right up until it does. < 1773296156 617349 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Sorry if I'm overeager. I'm drugged and sleep-deprived, but more importantly the GPU community is always starved for developers. There's only like a few hundred of us and we're really just compiler engineers with the patience to hack kernel and reboot the machine if we lock up the PCI bus by crashing the GPU. < 1773296372 601373 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: are they 64 bit × 64 bit multiplications where you care about most of the 128 bits of the result? < 1773296391 746860 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :when I taught GPU programming, the GPUs were somehow able to self-recover if they were crashed (but the sort of crashes we're talking about are null-dereferences and the like which are probably easy to recover from) < 1773296396 611149 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: Oh! That was the shot, here's the chaser: the kernel has to *parse* userspace's submitted command buffers. The kernel's got a memory manager for GPU objects (okay, technically, it has two and a half GPU memory managers) and it will change your buffers to point to the right objects on the GPU for you. Hope the kernel doesn't have any parser bugs! < 1773296399 559947 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: yss < 1773296401 159960 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* yes < 1773296436 957346 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Oh, also, hope the kernel doesn't insert fences wrongly. Or hope you got your fences right. Or hope that the fences are just slow and not misrendering. etc. < 1773296515 827005 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think GPU programming is the only platform on which I've seen programmers encouraged to omit logically required fences on the basis that the hardware will automatically have enough fencing for the program to still work < 1773296541 86447 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :presumably the optimiser knew enough about the technique to not mess with the fencing invariants itself, before the hardware saw it < 1773296594 157481 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah. It's remarkable that, in GL, we need to use an extension just to get calloc() for GPU memory. This property is called "robustness" and in the 2000s it basically didn't exist; you could read Somebody Else's Framebuffer just by, like, mmap() and read(). < 1773296663 601571 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :To be fair, glClearBuffer() is really expensive if you're robust by default. Up until then, clearing a buffer was done by enqueing a draw command for a big black rect; the threat model wasn't there yet. < 1773296673 826260 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :thinking about it, it shouldn't be too hard for a GPU to tell the OS kernel "I crashed running thread X, please recreate the graphics environment without the program that did that" < 1773296713 427438 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :non-crashing overwrites of other threads' data would be harder to deal with < 1773296732 919447 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but you could use an MMU for that just like CPUs do (I suspect GPUs have MMUs nowadays even though they originally didn't) < 1773296747 705850 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :korvo: and then your browser grows an extension to expose all that low-level stuff to websites, not just the high-level GL interface < 1773296775 27402 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that said, I would expect them not to have traditional TLBs and am not sure what they do instead (possibly some sort of manually loaded TLB?) < 1773296809 652771 :zzo38!~zzo38@host-24-207-46-238.public.eastlink.ca PRIVMSG #esolangs :With my idea of how I would do it, effectively the GPU could not crash, and if one window has errors that prevent it from working, that does not affect any other windows (except possibly those that share memory with it, although I expect it would probably not affect those either) < 1773296835 587848 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh right, I don't think I've told anyone how much I hate the name TLB yet < 1773296861 367051 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's one of those names that makes no sense without an explanation, and then the explanation is just justifying the name, it doesn't help to make it a name that actually makes sense < 1773296867 89592 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: couldn't they require the programs to use physical address pointers, so they can't freely choose addresses when they mmap, and the memory processor tracks which task can access each physical page? < 1773296888 159681 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: that's possible but I don't think it has advantages over an MMU < 1773296897 26431 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you still need to check for permissions, you may as well do page-mapping in the process < 1773296931 586846 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess the pagetables would be smaller, meaning that you could maybe have fewer levels? < 1773296981 69375 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :surely it has advantages over a an MMU that does address translation! the address translation with pages as small as 4 kilobytes is a large part of what makes the caches in CPUs so hard to optimize! < 1773296982 75249 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :now I'm reminded of the way that some CPU architectures raise interrupts to ask the kernel to manually fill in the TLB, rather than pagewalking on their own < 1773297000 682959 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :if you support only larger pages then it's less of a problem, but it's still complicated to support correctly < 1773297008 354460 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Not to explain to the professor how PCI works, but the way I think of it is that PCIe has limited bandwidth. The GPU's memory controller mostly has to make scheduling decisions about what to DMA next; it sees what's upcoming in the command queue, to give you an idea of how deep the decoding pipeline gets. < 1773297063 935362 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :in CPUs the problem is that the CPU wants to use information from the L1 cache before it knows for sure that the translated address for the cache line matches the reqested address, and then has to be able to quickly change its mind if it turns out that the L1 cache hit was fake and it has to use a value from the L2 cache. < 1773297081 321811 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I'm told that this is the main reason that nouveau doesn't just have a full disassembly of the nVidia microcode. If it were that easy then they'd have done it, like people have done with x86 microcodes. But the nVidia blob contains a scheduler for the memory controller, or the moral equivalent. < 1773297115 260478 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :the L1 cache wants to be very low latency so the translated address is available *almost* too late. the address translation is on a critical path < 1773297118 627009 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I was working one level higher than that, you can definitely say "please DMA this memory" in GPU source code (not in that many words but with the same effect), but I was just working at the level of "there will be some delay if you do this" and at my level of abstraction the details of the pipeline didn't matter < 1773297146 524017 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :moreover, the L1 cache can't go larger than 8 times the page size, so we're stuck with the same L1 cache size in the best CPUs for decades < 1773297178 841232 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: I like that description because it now makes me wonder whether the TLB is yet another skeuomorphism. Like, was there a person in the days of the telegraph or switched telephone that had a little side table, and on the table was a big book of addresses, and the operator had to physically look at the side table... < 1773297206 774905 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: maybe the solution here is some sort of noalias caching, in the sense that you just ban accessing memory that would be appear to be a cache hit but actually isn't < 1773297221 658247 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Wait, L1 cache is based on *page* size? Is this an x86 detail? > 1773297231 995318 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=177585&oldid=177566 5* 03EsolangerII 5* (+57) 10/* Introductions */ < 1773297255 393057 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :GPUs have two sorts of memory, one of which works a lot like CPU memory but is typically read-only, and the other more GPU-specific one which is read-write but the caches are loaded manually < 1773297256 438700 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I thought L1 was based on how much RAM could be physically made available next to the fetch unit inside each core? > 1773297259 797101 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=177586&oldid=177585 5* 03EsolangerII 5* (+10) 10/* Introductions */ < 1773297297 772815 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :if you're loading the caches manually anyway, simply saying "don't do cache collisions" is something you can actually do < 1773297341 100149 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh! I think I know how GPUs could do MMU-like behaviour: you fix the addresses in GPUspace that each thread can access (you have to do that anyway so that they can act in parallel with each other) and you do the permission checks only when you're copying into and out of the cache-equivalent < 1773297363 146290 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you don't need to cache the address translations because you're only ever using them as part of a slow operation anyway > 1773297392 208124 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=177587&oldid=177586 5* 03EsolangerII 5* (+5) 10/* Introductions */ > 1773297425 610379 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=177588&oldid=177587 5* 03EsolangerII 5* (+10) 10/* Introductions */ < 1773297478 758543 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah. I should point out that word sizes are bigger on the GPU; the fetches are like 256 bits minimum. This is hidden at the ISA level behind the 2x2 abstraction I mentioned earlier. IIRC nVidia docs talk about "warps", as in looms. < 1773297505 808113 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the Rust developers had a spate of GPU terminology trouble recently < 1773297522 262736 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because they wanted to create a GPU-agnostic API but all the GPUs were using different names for the same concepts < 1773297532 219434 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and so it was hard to figure out what names to use in documentation < 1773297557 741432 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the course I was teaching used nVidia terminology, so we were dealing with warps and half-warps < 1773297572 741324 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :warp, thread, block, kernel as the four main levels of abstraction < 1773297576 220857 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :And they probably wanted to expose low-level control over running warps in parallel. Seductive, the Dark Side is. < 1773297590 699793 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(this is also the reason I said "OS kernel" above, to clarify that I didn't mean a GPU kernel) < 1773297614 660585 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Sheesh. And I think nVidia/CUDA "block" is what SGX and other ARM SoCs call "tile". > 1773297634 610694 PRIVMSG #esolangs :14[[07Pastebin14]]4 10 02https://esolangs.org/w/index.php?diff=177589&oldid=144016 5* 03Dragoneater67 5* (+62) 10/* Some random C++ code I found online */ < 1773297707 480560 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The model I would want, because I'm a weenie who hates going fast, is to run a pure function from tensors to tensors. The pure function can vary, it can have uniform params, but it's just a tensor mapping. AIUI this is basically what Futhark offers. < 1773297743 781464 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :anyway, a) all the threads in a block have equal permissions to each other, b) threads generally work entirely in terms of memory that belongs to the block, c) each block has its own address space for block memory < 1773297764 901093 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :korvo: I think it's based on page size. Multiple pages in logical address can map to the same physical address, but caching has to use the physical address so that if you write to one logical address and read from the other you get the correct result. There are 64*8 cache lines, each 64 bytes long. You get the lower 12 bits of the address first, because that's the same in logical and physical, and the < 1773297767 224867 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which means the only time you would need to do an address translation and permission check is when copying between block memory and main memory, and that's normally done kilobytes at a time < 1773297770 909980 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :L1D cache can tell which of the 64 groups of 8 cache lines it has to use from that, and later when it learns the physical address it picks one of those 8 to serve, or for a cache miss it has to pick the oldest one of those 8 to flush. I think this would be too complicated to do in time with 16 instead of 8 cache lines in each group. < 1773297799 133452 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(again, talking about standard GPU memory here, not the CPU-like memory that's more freely addressible) < 1773297803 481456 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I'm not a CPU designer so it's possible that I'm wrong about this and there's some other reason why the L1D cache size doesn't go over 32 kilobytes. < 1773297817 882008 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: That makes perfect sense! Beautifully explained. It might have come out of my electrical engineering textbook. > 1773297908 219411 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=177590&oldid=177490 5* 03EsolangerII 5* (+45) 10* < 1773297927 160849 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :cache associativity is one of those optimisations where you know theoretical slowpaths exist, but they're unlikely and not actually *incorrect* so you just do the optimisation anyway and hope that the slowpath never gets hit < 1773297964 430699 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and then people researching low-level CPU behaviour intentionally create a lot of clashing addresses and use the performance changes to measure the cache associativity < 1773297992 709858 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :this is 32 kilobytes per CPU core by the way, and there's a separate L1C cache for code which can be separate because if you ever write to a cache line that's used as code then the CPU is allowed to go very slow to recover from that < 1773298033 632898 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: not just that, it's allowed to not notice < 1773298047 496112 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :b_jonas: Hm. So maybe I'm misremembering, and it's L2 cache that is constrained by physics? < 1773298077 538773 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :apparently you need to run one of a few specific instructions to recheck the cache if potentially cached code got written to < 1773298081 768766 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I do recall that L2 and L3 are explicitly at different levels of sharing and coherence precisely so that L3 can be shared by more cores, which inherently means that it must be (equally) far away from all of its users. < 1773298084 978913 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(CPUID is one of them, there's a faster one but it's new) < 1773298134 7376 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :my guess is that storing data in L1C evicts it from L1D and vice versa, in much the same way as if a different CPU had written it – it could use the same mechanism < 1773298150 580288 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: but there are also some cases where you can use this knowledge to intentionally create good memory addresses to speed up your code < 1773298189 458414 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: I think on x86 the CPU is required to notice changing code as long as there's a jump instruction between the code change and execution, but maybe this has changed at some point? < 1773298219 334571 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I think it's something like, if it was changed on the same core a jump is enough, if a different core changed it you need CPUID < 1773298232 987027 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :for recent x86, anyway < 1773298236 497325 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :old x86 didn't need the jump < 1773298237 128058 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :sure that's believable < 1773298262 510429 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :oh the jump was needed even in very old x86 (in some cases anyway) < 1773298287 355455 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :IIRC DOS NetHack has a self-modification without a jump < 1773298298 545547 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :at least if running under HDPMI32 < 1773298300 907121 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :because even the original 8086 can read ahead a few bytes of instructions < 1773298320 156768 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I remember committing to an emulator so that it would emulate it correctly < 1773298338 976742 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: you could perhaps do it in some way other than a jump, but usually a jump is needed < 1773298354 39952 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :why the heck does DOS NetHack do that? < 1773298365 216590 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :do you load overlay code without a jump between? < 1773298369 953900 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :interrupts < 1773298406 597050 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :oh, but isn't that in a context where you modify one byte and it's fine if the CPU only notices it at a later time when it runs the code as long as it's atomic? < 1773298421 835702 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :if you do that then no jump is probably fine < 1773298426 60237 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the standard library wants to provide a function for "call interrupt number X" but the x86 INT instruction can't take the interrupt number from a register, it has to be an immediate < 1773298436 770530 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :what? < 1773298448 497803 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :why would you want to call an interrupt with indirect number? < 1773298449 268551 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so either you need a jump table with an option for every possible interrupt number or you need self-modifying code < 1773298466 362380 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :you wouldn't have to if you could inline the standard library < 1773298477 941489 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: So, maybe I'm outdated on this, but ISTR that GPU memory access is dominated by sampling strategy. Usually every pixel in a warp will look up nearly the same texels; they'll be near each other in 2D space or 3D space or whatever. If the texels were Z-tiled or Morton-tiled or etc. then a cache row is more likely to hold multiple nearby texels. This is why nVidia does that to all of their texture memory. < 1773298489 278513 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but the standard library wants to provide a function for calling interrupts, and it wants to provide one function, not a function for each possible interrupt < 1773298516 927220 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I see! < 1773298518 994916 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: we basically didn't use texture memory on the course < 1773298532 482295 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :just block memor < 1773298534 62467 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* memory < 1773298562 417419 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :that does sound like you need a jump between modifying the instruction and executing it though < 1773298563 342532 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :of course texture memory is very important in games and graphics programming, but we were doing GPGPU with somewhat predictable/constraint inputs < 1773298565 100124 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: Good call. It's a headache. It was a big deal in the community when they finally reverse-engineered the GPU's native memory formats. < 1773298587 290182 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so we could just load all the data we needed into block memory < 1773298632 527638 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that said, plenty of weird tiling stuff came up in the actual algorithms (GPU matrix multiplication is a classic example of the genre) < 1773298650 811792 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :even when you're manually filling the caches it needs a lot of thought to do that efficiently < 1773298671 739368 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm talking about big matrices here, not the little 4×4 ones which have a builtin < 1773298737 987698 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the basic challenge is to ensure that each value is only loaded into one block at a time, in order to make the most of your parallelism > 1773298751 872989 PRIVMSG #esolangs :14[[07One Command Programming Language(OCPL)14]]4 N10 02https://esolangs.org/w/index.php?oldid=177591 5* 03EsolangerII 5* (+503) 10Created page with "One Command Programming Language is a programming language that uses only one command, !(). If there is one argument, like this, !(1), it will print what is inside. !("Hello, World!") // prints Hello, World. If there are two arguments, < 1773298775 859204 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yep. It's a perennial desire. The Weather Channel reportedly paid for the r200 Radeon driver so that they could do weather modeling on those GPUs, despite basically no customizable shaders. I've never seen their code, but I know weather models need lots of linear algebra, so they must have done it somehow. < 1773298821 596157 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the funny thing is, with the rise of LLMs, I don't think people even use GPUs for workloads that are mostly matrix multiplication any more because nowadays there are specialised chips for that < 1773298830 647770 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(but GPUs are very good at doing large matrix multiplications) < 1773298848 513633 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Don't people usually use off-the-shelf algorithms for this? CUDA kernels or whatever? < 1773298873 649180 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :I guess it should come up in a class. < 1773298926 564688 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: don't both the GPU and CPU have parts in them that are specialized for matrix multiplication? like in recent CPUs and GPUs < 1773298954 653930 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: oh yes, they do – I was teaching the sort of class where you tell the students how the standard library works internally < 1773298981 906558 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(not directly but you teach the relevant principles) < 1773299030 504720 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in engineering you care about how to use the tools, in computer science you care about how/why the tool works < 1773299041 823490 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and this was a computer science course < 1773299054 685240 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :maybe not enough parts in those chips are, so specialized chips that are denser are needed for machine learning; and other specialized chips that are 95% SHA-256 computation are needed for bitcoin mining < 1773299067 467281 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: some very recent Intel CPUs have matrix multiplication operations, yes < 1773299096 853725 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I am surprised by this, it's the sort of thing you would expect to delegate to a different type of processor instead if you're doing more than a trivial amount, so it strikes me as mostly a marketing thing < 1773299117 282159 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: even the not very recent ones are optimized for the execution units have really high throughput for executing mostly floating point multiply and add instructions < 1773299135 556408 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: are you talking about Intel CPUs? < 1773299137 686901 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :SIMD ones < 1773299141 71859 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :yes, x86 CPUs < 1773299143 236476 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :they do have a surprising amount of FMA units < 1773299152 893794 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :to the extent that I think normal multiplication is implemented as FMA of -0 < 1773299176 797348 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :oh it's definitely partly a marketing thing < 1773299205 524405 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in general I think Intel has problems trying to persuade people to upgrade to newer chips < 1773299218 86560 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and they keep inventing bizarre features because of that < 1773299234 96775 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :yes, there's some of that < 1773299242 6225 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(also there's the persistent historical situation of "Intel specifies a new feature but only AMD implements it") < 1773299242 318816 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :We were talking earlier about how to actually get compilers to emit FMAs: https://lobste.rs/s/bunmdv/faster_asin_was_hiding_plain_sight < 1773299280 556744 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :FMA is really awkward from the programmer's point of view because if you request an FMA but the hardware doesn't have one you get a slow fallback < 1773299293 407024 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and if you don't request an FMA the compiler can't normally use it due to excessive rounding < 1773299301 581717 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :maybe there should be a maybe_fma or the like that gives the compiler a choice < 1773299304 563187 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :* excess precision < 1773299309 838819 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :don't we have a C pragma specifically for that? < 1773299360 113438 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there's also the practical problem that not all x86-64 CPUs support an FMA instruction < 1773299387 993628 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and many programmers are unwilling to have their program not be able to run on older CPUs, but switching between different instructions at runtime has its own issues < 1773299389 289546 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :`#pragma STDC FP_CONTRACT ON` then you write a multiplication and addition in your code and the compiler is allowed to emit an fma < 1773299392 163249 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :​#pragma? No such file or directory < 1773299426 979911 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :and before that there was a compiler flag < 1773299461 433926 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and of course the silly incident where Intel and AMD each specified FMA instructions and then each implemented the others' specification < 1773299471 620661 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :In some languages there's mixfix ops with two parts. `b ? x : y` for example. In E, modular exponentiation is mixfix, `b ^ e % m` or so. It would be nice if FMA could arise from a standardized mixfix `a * x + b`. < 1773299486 713291 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(they're synchronized again now, on the version originally specified by AMD and implemented by Intel) < 1773299517 442876 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :(This is probably the biggest GPU programming influence on Monte! It doesn't guarantee FMA but has syntax set up for it.) < 1773299525 63641 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: I've been increasingly thinking that FPU code should have special "rounding parentheses" that show where the rounding goes < 1773299539 277768 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :err, floating point in general, not FPU specifically < 1773299610 124895 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ais523: yes, but I think all the FMA instruction thing was before it turned out that both Intel and AMD CPUs have multiple kinds of speculative execution vulnerabilities, and then everyone upgraded just to be sure that their CPU doesn't have them < 1773299630 944933 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :kind of unfortunate but that should have solved the FMA problem by now < 1773299647 373313 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: that doesn't really help because there are almost certainly lots of undiscovered such vulnerabilities < 1773299688 203446 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :anyway, I mostly stopped thinking about this topic because when I do I start thinking about how to do a fused add-add, which sounds easy but is harder than it seems to do correctly < 1773299741 378408 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :yeah, the remaining ones are the hard ones that the CPU makers can't fix because they require the compiler writers and low level library writers to collaborate < 1773299804 236155 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I don't think it's possible to make a confident statement about the remaining ones < 1773299827 493872 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :given the history there's almost certainly going to be at least one subtle one that's extremely hard to fix, and at least one stupid oversight < 1773299909 465022 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :actually I think even a straightforward Spectre v1, "bounds check / read from array / indirect read with an address calculated based on the read value", hasn't been fully fixed yet < 1773299911 649975 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :some of them aren't specifically speculative execution but other side channel leaks < 1773299977 324109 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :even the class of "covert channel from speculatively running code to non-speculatively running code" is likely not fully explored yet < 1773300040 310072 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :now I'm thinking of that amazing Spectre v2 variant where the processor was tricked into predicting a branch from an instruction that wasn't actually a branch instruction < 1773300082 932391 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :yeah, you're probably right, there's too many side channel leaks to fix all of them easily < 1773300113 179718 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :caching is hard < 1773300146 657213 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :also I should ask #esolangs my cryptography question some time < 1773300174 469663 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :but it's not something I can do justice to in just a few lines < 1773300206 110599 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I do like the generic fix of ensuring that programs are deterministic, which prevents them translating side channels or covert channels into non-side-channel behaviour (but doesn't prevent them taking data from a covert channel and outputting it via a side channel) < 1773300223 270250 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the hard part is removing the primary externally visible side channel, which is timing < 1773300299 64011 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :come to think of it, this is essentially the same problem that we have in bridge tournaments: in bridge, each contestant is a pair of humans who are not allowed to communicate except via the moves they make < 1773300314 663932 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :the other "generic fix" is to never run multiple programs that don't trust each other on the same hardware < 1773300348 121307 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(each person has partial information – the game is about trying to make moves that give your partner enough information to make good moves of their own, whilst ensuring that your own move isn't too bad) < 1773300349 485648 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :true, bridge does try to solve that < 1773300361 593672 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :playing online blocks almost all the side channels, but not timing < 1773300390 864415 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer < 1773300398 350756 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think the solution here might be a fixed time limit per move, but players like to be able to think as long as they like, like in chess… < 1773300493 164665 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :yeah, you have to make bridge teams submit a computer program that plays their strategy, and then impose a time limit on each step when that program executes, to get around that < 1773300511 962922 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is extremely hard < 1773300515 442642 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :which is sort of what they're trying to impose on bridge but it's not that formal < 1773300518 93026 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :just explaining human systems to a computer is difficult < 1773300527 243357 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(explaining them to a human is also difficult, but easier) < 1773300548 848973 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :yes < 1773300603 174056 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :current bridge software is really bad at communicating with its partner, when it does well it's primarily through not making thinkos and through being able to work out complex lines of play when it has full information < 1773300658 722107 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :The last time I read about a bridge scandal, it was — and sorry in advance for getting the terminology wrong — a side channel via the return box where discarded cards are placed? < 1773300682 383791 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :does that apply only to bridge software that wants to communnicate with a human partner, or also bridge software that plays a team? < 1773300696 174683 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It was something remarkably subtle like one of four choices of corner, and it wasn't just sending something obvious like a suit or rank. < 1773300724 574821 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo: there were two scandals that that might have been, but only one was that subtle < 1773300744 350651 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :discarded cards in bridge are played like non-discarded cards, just the players have to remember they have no value < 1773300766 93382 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but bridge has two phases, the bidding and the play < 1773300795 270269 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and there was something complicated about placement of the tray that was used to pass the information about the bidding from one partner to the other, IIRC < 1773300805 723361 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: both < 1773300806 175897 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :I think the only reason why bridge mostly works and doesn't have these standards is that it's mostly people who already want to keep the information hygiene rules want to play it, especially british people. < 1773300839 30779 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :s/standards/scandals/ < 1773300839 340047 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I'm primarily concerned about people who are consciously honest but subconsciously pick up information they aren't entitled to < 1773300870 629317 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :ah, like CPUs that don't want to deliberately leak information on a side channel? > 1773300875 331643 PRIVMSG #esolangs :14[[07One Command Programming Language(OCPL)14]]4 10 02https://esolangs.org/w/index.php?diff=177592&oldid=177591 5* 03EsolangerII 5* (+84) 10 < 1773300882 142016 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :e.g. if you can see your partner as you play it is too easy to pick up their emotions from body language, so serious tournaments have a barrier across the table and use trays to pass information back and forth < 1773300898 738489 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :ais523: That sounds like the one. I saw a video of tourney play so that they could show what the tray ought to look like, and it felt very solemn. I'm guessing that that's just the tourney atmosphere for a game where sharing knowledge is forbidden? < 1773300916 533287 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's only done in important tournaments and normally only in the last few rounds < 1773300932 391293 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :normally (when playing in person) you just get the four people sitting round a table without many precautions < 1773300940 693585 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but I don't like that because of how much unauthorised information it creates < 1773301087 944996 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Makes sense. In this part of the USA, the contract game we usually play is whist, but much more common is the non-bidding game of hearts. Hearts is a perfect-play game, or however you call it; it's not interesting professionally because it's all down to which hand you're dealt. < 1773301147 772322 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, hearts is theoretically complicated because you have multiple opponents who are not allied with each other < 1773301174 88334 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I would expect it to be similar to poker in that it can be broken by collusion < 1773301184 763217 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Yeah. But there's a bit of game theory, so even if you're not allied, you get to bet against -- exactly! < 1773301209 135197 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :We also play lots of poker and blackjack for fun. Same idea. I guess we like bluffing games. < 1773301242 439084 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :there are card games with bidding on tricks where everyone bids simultaneously, but I think those can be broken with collusion too < 1773301416 819231 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :there's also at least one competitive trick-taking card game with some limited bidding that has just two players, that's kind of the easy way to get around these problems < 1773301430 401435 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :but it's more boring than the game with three or more players < 1773301439 586001 :b_jonas!~x@catv-80-98-84-202.catv.fixed.one.hu PRIVMSG #esolangs :s/game with/games with/ < 1773301476 357798 :chloetax!~chloe@user/chloetax JOIN #esolangs chloetax :chloe < 1773301501 215409 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :It is a dark and stormy night. I'm going to bed. Peace. > 1773301599 349044 PRIVMSG #esolangs :14[[07One Command Programming Language(OCPL)14]]4 10 02https://esolangs.org/w/index.php?diff=177593&oldid=177592 5* 03EsolangerII 5* (+120) 10 > 1773302281 609734 PRIVMSG #esolangs :14[[07One Command Programming Language(OCPL)14]]4 10 02https://esolangs.org/w/index.php?diff=177594&oldid=177593 5* 03EsolangerII 5* (+218) 10 < 1773302394 847268 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :korvo (for when you wake up): I think this is the video you were thinking of: https://www.youtube.com/watch?v=831tJ4EHLBY < 1773302460 371012 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I was almost right, they weren't signalling using the tray, but using the board that's used to hold the cards when carrying them between tables (nowadays, bridge tournaments are usually scored by comparing the play of the same deal at multiple tables, so you need to ensure that each table has players get the same cards and that's done by using a board that holds the four hands separately) < 1773307212 346915 :chloetax!~chloe@user/chloetax QUIT :Ping timeout: 264 seconds < 1773307671 191008 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I looked at the x86 emulator code I wrote to handle self-modifying code – it worked by simulating a no-op interrupt if memory was modified that could be in code cache (thus causing the code to be re-recompiled after the interrupt was handled) < 1773307687 110709 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a real processor could use the same method (and probably does do something similar) > 1773308739 893636 PRIVMSG #esolangs :14[[07Talk:14]]4 N10 02https://esolangs.org/w/index.php?oldid=177595 5* 03C++DSUCKER 5* (+43) 10Created page with "This esolang is absolutely AWWESOME!!!!! :D" > 1773308751 566742 PRIVMSG #esolangs :14[[07Talk:14]]4 10 02https://esolangs.org/w/index.php?diff=177596&oldid=177595 5* 03C++DSUCKER 5* (+27) 10 > 1773308765 577888 PRIVMSG #esolangs :14[[07Talk:14]]4 10 02https://esolangs.org/w/index.php?diff=177597&oldid=177596 5* 03C++DSUCKER 5* (+1) 10 > 1773308779 296566 PRIVMSG #esolangs :14[[07Talk:14]]4 10 02https://esolangs.org/w/index.php?diff=177598&oldid=177597 5* 03C++DSUCKER 5* (+32) 10 > 1773308802 136558 PRIVMSG #esolangs :14[[07Talk:14]]4 10 02https://esolangs.org/w/index.php?diff=177599&oldid=177598 5* 03C++DSUCKER 5* (+27) 10 > 1773308818 798987 PRIVMSG #esolangs :14[[07Talk:14]]4 M10 02https://esolangs.org/w/index.php?diff=177600&oldid=177599 5* 03C++DSUCKER 5* (-1) 10 > 1773309246 189842 PRIVMSG #esolangs :14[[07Ring-around-the-Rosie14]]4 10 02https://esolangs.org/w/index.php?diff=177601&oldid=175150 5* 03Salpynx 5* (+4482) 10/* Examples */ 99 bottles for 1 reg Minsky machine > 1773309323 138007 PRIVMSG #esolangs :14[[07Ring-around-the-Rosie14]]4 M10 02https://esolangs.org/w/index.php?diff=177602&oldid=177601 5* 03Salpynx 5* (+25) 10/* Computational class */ implemented for testing evaluation strategies < 1773311462 514115 :ais523!~ais523@user/ais523 QUIT :Quit: quit > 1773311805 438431 PRIVMSG #esolangs :14[[0714]]4 10 02https://esolangs.org/w/index.php?diff=177603&oldid=177556 5* 03Qpx5997 5* (+394) 10 > 1773312184 493615 PRIVMSG #esolangs :14[[0714]]4 10 02https://esolangs.org/w/index.php?diff=177604&oldid=177603 5* 03Qpx5997 5* (+333) 10/* Syntax */ > 1773312872 647857 PRIVMSG #esolangs :14[[0714]]4 10 02https://esolangs.org/w/index.php?diff=177605&oldid=177604 5* 03Qpx5997 5* (+812) 10 > 1773313234 942870 PRIVMSG #esolangs :14[[07One Command Programming Language(OCPL)14]]4 10 02https://esolangs.org/w/index.php?diff=177606&oldid=177594 5* 03EsolangerII 5* (+55) 10 > 1773313272 469760 PRIVMSG #esolangs :14[[0714]]4 10 02https://esolangs.org/w/index.php?diff=177607&oldid=177605 5* 03Qpx5997 5* (+76) 10/* Commands */ > 1773313364 248365 PRIVMSG #esolangs :14[[07One Command Programming Language(OCPL)14]]4 M10 02https://esolangs.org/w/index.php?diff=177608&oldid=177606 5* 03EsolangerII 5* (+0) 10 > 1773313384 885131 PRIVMSG #esolangs :14[[07One Command Programming Language(OCPL)14]]4 10 02https://esolangs.org/w/index.php?diff=177609&oldid=177608 5* 03EsolangerII 5* (+5) 10 > 1773313727 342282 PRIVMSG #esolangs :14[[0714]]4 10 02https://esolangs.org/w/index.php?diff=177610&oldid=177607 5* 03Qpx5997 5* (+58) 10 > 1773316721 314809 PRIVMSG #esolangs :14[[07Template:Unf14]]4 10 02https://esolangs.org/w/index.php?diff=177611&oldid=177551 5* 03None1 5* (-36) 10Blanked the page < 1773317251 323280 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Wtf, how does evince keep getting worse?! Can't scroll up with cursor keys anymore... it works once, but also selects the zoom input field. < 1773317290 727929 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(well, maybe it's a recent GTK change) > 1773317912 544921 PRIVMSG #esolangs :14[[07ChangeFuck14]]4 10 02https://esolangs.org/w/index.php?diff=177612&oldid=177562 5* 03None1 5* (+920) 10 < 1773318069 609751 :amby!~ambylastn@host-92-17-36-146.as13285.net JOIN #esolangs * :realname < 1773318350 271918 :ajal!~ambylastn@host-92-17-36-146.as13285.net JOIN #esolangs * :realname < 1773318605 592024 :amby!~ambylastn@host-92-17-36-146.as13285.net QUIT :Ping timeout: 244 seconds < 1773320027 676732 :APic!apic@apic.name PRIVMSG #esolangs :Hi > 1773321045 635967 PRIVMSG #esolangs :14[[07Qpx599714]]4 N10 02https://esolangs.org/w/index.php?oldid=177613 5* 03Qpx5997 5* (+81) 10Created page with "hey guys, im qpx5997, creator of [[]]. i like object shows too!" > 1773321069 350739 PRIVMSG #esolangs :14[[07Qpx599714]]4 10 02https://esolangs.org/w/index.php?diff=177614&oldid=177613 5* 03Qpx5997 5* (-81) 10Blanked the page > 1773321119 37503 PRIVMSG #esolangs :14[[07User:Qpx599714]]4 N10 02https://esolangs.org/w/index.php?oldid=177615 5* 03Qpx5997 5* (+81) 10Created page with "hey guys, im qpx5997, creator of [[]]. i like object shows too!" > 1773321477 851684 PRIVMSG #esolangs :14[[07Qpx599714]]4 10 02https://esolangs.org/w/index.php?diff=177616&oldid=177614 5* 03Qpx5997 5* (+26) 10Redirected page to [[User:Qpx5997]] < 1773324298 442447 :chloetax!~chloe@user/chloetax JOIN #esolangs chloetax :chloe < 1773325100 32108 :FireFly!~firefly@glowbum/gluehwuermchen/firefly QUIT :Ping timeout: 267 seconds < 1773325205 140396 :FireFly!~firefly@glowbum/gluehwuermchen/firefly JOIN #esolangs FireFly :firefly > 1773327373 206664 PRIVMSG #esolangs :14[[07Qpx599714]]4 10 02https://esolangs.org/w/index.php?diff=177617&oldid=177616 5* 03Aadenboy 5* (-26) 10remove redirect to userspace < 1773331490 888396 :lynndotpy609362!~rootcanal@134.122.123.70 QUIT :Quit: bye bye < 1773331554 210637 :lynndotpy6093627!~rootcanal@134.122.123.70 JOIN #esolangs lynndotpy :lynn < 1773333632 562662 :impomatic!~impomatic@31.55.121.85 JOIN #esolangs * :[https://web.libera.chat] impomatic > 1773335902 174597 PRIVMSG #esolangs :14[[07Bit-ter lang14]]4 10 02https://esolangs.org/w/index.php?diff=177618&oldid=177584 5* 03Yayimhere2(school) 5* (-154) 10/* Class */ Its a bounded in memory! AND there's no loops! > 1773336075 755604 PRIVMSG #esolangs :14[[07Bit-ter lang14]]4 10 02https://esolangs.org/w/index.php?diff=177619&oldid=177618 5* 03Aadenboy 5* (+59) 10 < 1773336459 261816 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname < 1773337040 846814 :joast!~joast@2603:90d8:500:31cf:5e0f:3f4b:1cfe:5060 JOIN #esolangs joast :joast > 1773337292 16373 PRIVMSG #esolangs :14[[07Countable14]]4 10 02https://esolangs.org/w/index.php?diff=177620&oldid=176989 5* 03Aadenboy 5* (+141) 10 > 1773337335 693043 PRIVMSG #esolangs :14[[07Countable14]]4 10 02https://esolangs.org/w/index.php?diff=177621&oldid=177620 5* 03Aadenboy 5* (-74) 10/* Commands */ this is redundant and WRONG < 1773342886 392871 :impomatic!~impomatic@31.55.121.85 QUIT :Quit: Client closed < 1773344984 266218 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1773345017 615973 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 244 seconds < 1773345157 855625 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 NICK :Lord_of_Life < 1773345521 156491 :APic!apic@apic.name PRIVMSG #esolangs :Good Night 😴 < 1773347512 267968 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Leaving [[Java]] as a redlink has become very funny to me. Big thanks to Past Corbin for placing that bet. < 1773347543 11459 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :A language so non-esoteric that bluelinking it would be pointless. < 1773348012 549228 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Hehe, this looks a bit janky: https://int-e.eu/~bf3/tmp/shapez2-train-merge.jpg (showing 6 trains arriving all at once at the vortex (central hub); it could be 8 but the 4th direction actually does something useful :) < 1773348194 641003 :korvo!~korvo@2604:a880:4:1d0::4d6:d000 PRIVMSG #esolangs :Like one of those animations of assembling a 4-dimensional hyperobject from 3D faces. < 1773348561 941984 :Artea!~Lufia@artea.pt JOIN #esolangs Artea :Artea ElFo < 1773351239 260698 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1773351821 571643 :somefan!~somefan@user/somefan JOIN #esolangs somefan :[https://web.libera.chat] somefan < 1773352124 150933 :somefan!~somefan@user/somefan QUIT :Remote host closed the connection < 1773352736 611278 :somefan!~somefan@user/somefan JOIN #esolangs somefan :[https://web.libera.chat] somefan < 1773356891 301512 :somefan!~somefan@user/somefan PRIVMSG #esolangs :has anyone visited #anagol on freenode? < 1773356907 323392 :somefan!~somefan@user/somefan PRIVMSG #esolangs :ref: http://golf.shinh.org/ second para < 1773357186 797779 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :Logs suggest I was there from 2014-10 to 2021-06. < 1773357387 721838 :somefan!~somefan@user/somefan PRIVMSG #esolangs :is the server offline? the wholist is completely empty < 1773357410 528871 :somefan!~somefan@user/somefan PRIVMSG #esolangs :or maybe i've never seen an empty server before < 1773357513 504934 :somefan!~somefan@user/somefan QUIT :Remote host closed the connection < 1773357539 572256 :somefan!~somefan@user/somefan JOIN #esolangs somefan :[https://web.libera.chat] somefan < 1773357700 662569 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :I guess it might have just dried up. < 1773357797 553304 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I almost forgot that Freenode is still a thing, technically. < 1773358371 823887 :somefan!~somefan@user/somefan PRIVMSG #esolangs :that's sad, should've migrated to libera or someplace before the sweep < 1773358758 572179 :impomatic!~impomatic@31.55.121.85 JOIN #esolangs * :[https://web.libera.chat] impomatic