< 1566172808 987532 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :UTC rollover. < 1566172836 810753 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :well, you could say that you forgot that the 8-byte immediates are available for the general encoding of the arithmetic, as opposed to the shortcut accumulator destination encoding < 1566172900 491920 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :fwiw, I think modern processors in general are insane because of register renaming < 1566172924 167784 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :compilers go to all this effort to pack their nicely SSAed programs into a set of registers, which is an NP-complete problem < 1566172937 735931 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :then the processor goes to a lot more effort to unpack all thhe register names back into SSA and disregard the actual registers < 1566172985 578879 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The Mill people describe their belt system as "hardware SSA". < 1566173021 250147 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes, it's pretty similar, but also somewhat limiting I think < 1566173037 834404 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I prefer doing things the other way round, where each instruction says where the data should be routed to, rather than where the data came from < 1566173062 250619 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because that allows you to pipeline high-latency instructions, which is half the reason for the register renaming in the first place < 1566173133 742019 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I wish I had a better x86 REPL thing. < 1566173146 732911 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I could probably write something reasonably easily. < 1566173160 402664 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :asm repl, that's an interesting idea < 1566173191 131026 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I remember debug.com, arguably that counts, but it was a bit weird in how it worrked < 1566173283 538877 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Are there any good debuggers for Linux? < 1566173292 873302 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :what do you mean by "good"? < 1566173313 813880 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :gdb is easily good enough for what I want, but may well not count as "good" < 1566173319 342268 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hmm, I'm not sure. It's probably mostly a UI thing? < 1566173331 832559 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ddd is a GUI version of gdb, but is incredibly dated < 1566173333 397120 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I can figure out the things I want with gdb but it often takes a lot of overhead. < 1566173350 894005 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there are also a lot of IDEs that run on Linux, of course; probably most of them do < 1566173357 988641 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :People say Microsoft's debugger is good, but I haven't used it. < 1566173389 613833 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :well, it's integrated with Visual Studio, which IMO automatically makes anything insane < 1566173417 1478 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I've barely used Visual Studio. I don't know much about it. < 1566173444 289418 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: yes, and that's made even more insane by how the intel x86 optimization manual says that the longer nop instructions use execution units and a gp register from the register file, so the compiler sometimes has to figure out which register a nop instruction should reference < 1566173447 614236 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: the last-but-one time I attempted to install Visual Studio, I ended up needing to entirely reinstall Windows < 1566173459 371188 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The debugging APIs in Windows are certainly better than ptrace. < 1566173473 733645 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :aww, I like ptrace < 1566173485 788481 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although it's a bit slow in terms of how many system calls are needed < 1566173486 218500 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :it's strange, you'd think they solve that in the decoder, but no < 1566173498 606736 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ptrace does approximately the minimum possible. < 1566173510 375968 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: fwiw, I think there should be two different .align pseudoinstructions < 1566173519 971490 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I don't remember all the things Windows does but they generally seem useful. < 1566173520 842141 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :one which uses NOP padding, and the other of which uses ud2 < 1566173527 579126 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :For example, Win32 VirtualAllocEx lets you allocate memory in another process's address space. < 1566173546 15751 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: ugh, that seems outright dangerous < 1566173555 675690 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :what if the other process is using a different allocator to the expected allocator? < 1566173559 548362 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :When you're debugging a process? < 1566173568 39458 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :VirtualAllocEx is the equivalent of mmap. < 1566173568 962865 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the ptrace equivalent is to force the other process to call malloc, which seems safer < 1566173587 825640 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :In general I think many Windows system calls let you specify a process handle. < 1566173607 224634 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :How do you even do a system call, when you attach to some unknown process? < 1566173641 633450 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You at least need to find a syscall instruction, which could mean waiting for the process to do a system call, searching its address space for a syscall instruction, or writing one into its address space. < 1566173675 23088 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's documented what you do if the ptrace is stopping at a syscall instruction, you just rewind the IP two bytes < 1566173686 974845 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if the process isn't stopped at a system call, though, you have to change the IP to point at one < 1566173689 393770 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But you need it to be in an executable page, which is often read-only. ptrace lets you write to read-only mappings, but if a file is mapped into memory, it'll secretly convert it to a private mapping from a shared mapping. < 1566173698 503860 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(there is a system call instruction in the vDSO, that's the one I use for Web of Lies) < 1566173717 922602 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That's true, maybe finding the vdso page is your best bet. < 1566173726 598350 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :(Unless the debugee unmapped it?) < 1566173736 667796 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :well, you just use /proc/*/maps to find where it is < 1566173751 999041 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I guess writing a debugger for hostile programs that don't want to be debugged is quite different from writing one for your own programs. < 1566173757 551086 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :unmapping the vDSO is interesting, I didn't think of that < 1566173784 168821 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also, ptrace doesn't work recursively, which means that you can make yourself almost debugger-immune simply by ptracing yourself or a bunch of child processes < 1566173792 455311 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(for a debugger to hide from that, it needs to /simulate/ all the ptrace calls itself) < 1566173837 782071 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: I don't think padding with repeated UD2 is a good idea. it encodes to db 0x0F,0x0B| and if you happen to jump to that with the odd alignment, it reads the bytes 0x0B,0x0F which is a perfectly valid two-byte instruction < 1566173853 107239 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ah right < 1566173869 203181 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :does x86 have an instruction sequence that's invalid from any offset? < 1566173889 935654 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :other than the last byte, possibly, as there are no guaranteed one-byte illegal instructions < 1566173923 147797 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Why do you want an illegal isntruction? < 1566173979 490847 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: there are like sixteen one-byte instructions that are currently illegal in x86_64, but they're all just reserved, not guaranteed to be illegal forever < 1566173980 567590 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because the padding isn't meant to be executed < 1566173993 156140 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Why not 0xCC? < 1566174035 868813 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :yes, padding with 0xCC is probably the best < 1566174039 681051 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Or 0xF4 if you're not in ring 0. < 1566174080 360376 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I guess I should start using octal instead of hexadecimal. < 1566174089 207679 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :LOCK LOCK LOCK … LOCK NOP is illegal at any offset other than the last < 1566174117 420636 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So int3 is 0314 and hlt is 0364. < 1566174129 935746 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(once you have more than 15 lock prefixes it becomes illegal for a different reason, but that's OK) < 1566174161 252148 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :(more than 14?) < 1566174169 563413 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :max length of an instruction is 16 I think < 1566174185 831322 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Wait, really? I thought it was 15. < 1566174191 271809 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :…wait, why is LOCK NOP even illegal? NOP is a sort of XCHG instruction, which is one of the few that /can/ be locked < 1566174218 887491 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, because there are two registers, LOCK requires memory to be mentioned < 1566174221 845682 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It makes sense for reg-reg xchg to be illegal. < 1566174223 219539 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Right. < 1566174280 576583 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :while messing around with atomics I discovered that x86 has an XADD instruction < 1566174296 352599 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which is (r, m) = (m, r+m) < 1566174317 752272 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :notable mostly because it's lockable and has pretty useful semantics for a lockable instruction < 1566174342 800818 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hmm, I didn't know that. < 1566174388 572178 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :I think it can be useful sometimes, yes. < 1566174389 82975 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :XADD can also be used to perform the fibbonaci sequence in very little space < 1566174392 506293 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :which is a thing < 1566174403 794728 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :just two registers, I assume < 1566174416 555687 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Yes, I thought that too < 1566174455 128343 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :yup, 2 registers fib. < 1566174475 87794 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :technically 3 < 1566174480 688282 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :now the fun part is: can you do it with /one/ register? < 1566174481 652051 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :but 3rd is for loop if you want it to actually halt < 1566174482 352210 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But it's not as efficient as repeated squaring, I suppose. < 1566174523 633951 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :one loop iteration, that is < 1566174524 780370 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :ais523: quickly thought over the various ways to do addition on x86. My guess is no < 1566174538 762733 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :moony: it'd have to be a vector register I think < 1566174543 430520 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Two unbounded registers are enough for any computation. < 1566174556 401136 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :I was thinking of vectors too < 1566174560 804835 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Man, I wish I had a computer with even one unbounded register. < 1566174578 262781 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: do you need it modulo 2**32, or just the first fifty or so terms? < 1566174578 723102 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :you do. it's called RAM. (/s) < 1566174587 284790 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :mod r/s < 1566174599 391709 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :if the latter, then you can do a compare conditional jump thing to do it in one register < 1566174618 448485 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :and possibly even some smart hash lookup table thing < 1566174628 96218 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :but if you need it forever, then it gets harder < 1566174650 137088 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I think you could use one 64-bit register to compute it mod 2**32: < 1566174654 1508 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :actually no < 1566174662 425778 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :fib with a 1 byte value should be doable in 1 reg < 1566174668 649612 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :as long as you can have a constant in memory < 1566174681 490215 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :because upper lower halves < 1566174685 677909 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Why the PostScript binary format does not include dictionaries? < 1566174690 861766 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: I was thinking 32-bit integers, or even floats < 1566174700 821813 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :multiply it by a constant 0x00000001_00000000, then swap the upper and lower parts using rotate < 1566174747 285386 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :no, I mean < 1566174756 156720 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :multiply it by 0x00000001_00000001 < 1566174757 717393 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :duh < 1566174797 352017 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I think you could do that even without a constant memory operand, because 0x00000001_00000001 is composite < 1566174833 550217 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :multiply by 641 then multiply by 6700417 then rotate right by 32 < 1566174837 543848 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :start from 1 < 1566174855 367777 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :low 32 bytes gives the fibonacci number < 1566174911 45209 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I'm wondering about a language feature which is sort of the opposite of the ones I've been talking about wanting recently. < 1566174920 882850 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :https://www.perlmonks.com/?node_id=715414 is slightly releavnt < 1566174939 425123 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I want a type which can have values that are either known at runtime or at compiletime, and can mostly be treated uniformly. < 1566174956 722659 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :For example an array's length might either be known statically or be a field on a struct. < 1566174960 51480 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :oh yeah, that also works < 1566174991 570204 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You might like to be able to write code that works uniformly in both cases. < 1566174995 455211 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :actually AVX is almost certainly enough, you can treat %xmm1 or whatever as four floats, then vhaddps gives you the ability to add and vpermilps lets you move them around inside the register < 1566175000 413176 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: in each step, multiply by phi*2**32, add 2**31, then shift right by 32 < 1566175019 237018 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So you'd have a "field" on the struct which just refers to a constant compiletime value, or something. < 1566175019 960248 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :also works with floats: multiply by phi, round to integer < 1566175026 183418 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this doesn't work with ints because vpermd can't take input from an immediate for some reason < 1566175028 941755 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :round to nearest < 1566175030 476619 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Are there languages that do that? < 1566175048 678550 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :can only give the series starting from the second 1 though < 1566175059 82512 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: Rust does several things which are incredibly similar to that < 1566175075 234569 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but might not quite have the syntax you want < 1566175078 201036 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hmm, do you have an example? < 1566175118 83211 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you can say print!("{}", obj.field()); and depending on the type of obj, that can either get a value of a field or else compile down to a constant < 1566175154 574632 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in this case the function containing that would have a type parameter describing the type of obj so that the compilier knew which implementation to use < 1566175183 509781 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Another version of this might be a function that can either take an argument at compiletime or at runtime. (In the former case it could be specialized for that argument.) < 1566175227 784612 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :several of the more modern C-replacements (although not Rust, I think) have syntax in which you just write a function and can use it at compile-time if everything it does is safe then < 1566175247 279157 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I guess if you have a length() "method" in your language, and you monomorphize polymorphic functions, that more or less accomplishes the same thing, with enough optimizations. < 1566175254 710931 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :fwiw, even gcc compiling C will generate specialised functions if the code implies that they might be useful, at a sufficiently high optimisation level < 1566175289 754028 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: right; one weird thing in Rust is that it's idiomatic to rely on this actually happening < 1566175306 671682 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: yeah, but that's another of those optimizations that are hard to get right in the compiler < 1566175307 908081 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That sounds like something straight out of C++. < 1566175308 186293 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :e.g. arrays have a compile-time known length but you'd normally write .len() to get at their length anyway < 1566175329 185649 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because Rust monomorphises whenever you don't explicitly tell it not to < 1566175344 474398 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :C++ people are all about generating ridiculously inefficient code with recursive nested structs that the compiler can optimize to something efficient. < 1566175349 89335 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :the compiler would have to try to inline every call, recursively, to figure out which sets of inlinings result in a simplificatoins < 1566175355 225878 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: yes, that's very Rust as well < 1566175361 146462 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Right. < 1566175368 424632 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think that's not that great an approach. < 1566175372 847484 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :just inlining single calls isn't enough, because sometimes everything is hidden behind several layers of functions < 1566175374 630274 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :with the exception that Rust relies a bit less on the optimiser for it < 1566175384 734863 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the language semantics are such that the optimisation is more or less forced < 1566175492 643445 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Imagine you could say struct Arr { T* data; if length < 0 { int len; } else { compiletime int len = length; } };, or something. < 1566175500 832260 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Uh, I mean "T *data;". < 1566175538 78742 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Of course there are more things about an array that you might want to be either compiletime or runtime. < 1566175549 156581 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :For example you could track strides for a multidimensional array. < 1566175570 926148 :nfd!~nfd9001@c-67-183-33-240.hsd1.wa.comcast.net JOIN :#esoteric < 1566175608 674255 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shachaf: sure, Eigen does that with array lengths, and I think some other libraries do too < 1566175632 135128 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :In general I feel like there are so many different arrayish types you might want, which is kind of annoying. < 1566175641 807333 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :well, the Rust way to do that would be to write [T; 10] for a fixed ten-element array and [T] (which is a different type) for an array of unknown length, but it's trivial to write a function that's generic over both of those < 1566175668 169702 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(e.g. by specifying the type of your argument as Into<&[T]>) < 1566175699 340355 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :For example: Array with static length; array with dynamic length; array with dynamic length and (static or dynamic?) capacity, which can't grow past that capacity; array with dynamic length and dynamic capacity that can be grown with an allocator (do you store the allocator too?) < 1566175718 878786 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I have come to the conclusion that it's generally incorrect for a method to require a specific type from its arguments, rather than a description of what the type needs to support < 1566175741 150265 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but that description doesn't have to be duck typing, something like Rust's traits or Haskell's typeclasses probably works better < 1566175791 905995 :nfd9001!~nfd9001@2601:602:8500:2443:395e:78ef:ab2:ff1 QUIT :Ping timeout: 264 seconds < 1566175809 958616 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :Rust has three arrayish things, [T; len] (compiletime fixed length); [T] (runtime fixed length); Vec (growable) < 1566175822 882277 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :(more than three but yeah) < 1566175825 817171 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think doing too much monomorphizing everywhere isn't that great either. < 1566175827 279392 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that said, I think the "growable up to a fixed capacity" would be useful, but I don't think it's in the standard library < 1566175834 615 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: three really well-known ones < 1566175841 617461 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :For example you get a lot generated code, which isn't great. < 1566175842 713270 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :what sort of minor arrayish things does it have? < 1566175843 925465 :nfd!~nfd9001@c-67-183-33-240.hsd1.wa.comcast.net QUIT :Ping timeout: 248 seconds < 1566175869 171380 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :yeah, those are mentioned on the front page of the standard library documentation < 1566175872 90543 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: Vec is only growable with a call to a global allocator, right? < 1566175882 643578 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: right < 1566175887 753457 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :In general I'd like my libraries not to depend on things like a global allocator. < 1566175911 565079 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :at https://doc.rust-lang.org/nightly/std/index.html#containers-and-collections that is < 1566175932 350678 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shachaf: sure, but if you want a growable type, what should it grow into? < 1566175953 644485 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Well, that's one reason I want "growable up to a fixed capacity". < 1566175954 590289 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :do you want one that uses a buffer you give it? < 1566175960 742407 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :oh, or that < 1566175972 454581 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :hmm yes, I don't know if the library has such a type < 1566175974 8019 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You could tell your caller that you need more space. < 1566175978 863572 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :you could define one though < 1566175989 363369 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ugh, I've been trying to remove doc.rust-lang.org from my browser history < 1566176004 199448 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :mm? why? < 1566176005 403614 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I shouldn't have clicked that link < 1566176010 403282 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :moony: well, I often develop Rust offline < 1566176013 128286 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: use the forget feature < 1566176014 216275 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :ah < 1566176019 275437 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so I have a local copy of the Rust documentation < 1566176021 390683 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I do all my browsing in incognito mode by default so nothing goes in my history. < 1566176022 535201 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: I did, it's just a pain < 1566176055 177191 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :actually, the really annoying thing is that I can't use file:/// URLs for Rust documentation any more, because the page crashes if you don't have cookies/localstorage enabled < 1566176067 140920 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: There's also the separate distinction of whether a type "owns" the memory it's referring to or not. < 1566176068 383311 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and I don't think file:/// supports that < 1566176075 115567 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so I'm now running a local webserver just for the Rust documentation < 1566176077 513187 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :ais523: `rustup doc` < 1566176082 807872 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :does that not work < 1566176091 746976 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :moony: in what way? < 1566176093 43352 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: ouch < 1566176114 515422 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: it's not that ouch, I've had a local webserver running on here for years because I couldn't figure out how to get rid of it < 1566176114 557809 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I guess Rust is full of ways to handle that. < 1566176117 175018 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :now it at least has some purpose < 1566176123 855482 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(it's only accessible on localhost, at least) < 1566176128 75409 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :sure, but < 1566176128 670430 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But I think e.g. Box<> assumes you're using the global allocator? < 1566176153 337270 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: pretty much the entirety of Rust is about whether types own their memory or not < 1566176169 773103 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shachaf: yes, or at least its destructor does < 1566176172 94076 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :many methods have to be written three times for the three possible ownership relationships < 1566176186 407506 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :Box<> is basically the main API for accessing the global allocator < 1566176188 107020 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that and Vec<> < 1566176199 627200 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so them being tied to the global allocator really isn't surprising < 1566176200 638513 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :and there's not much point using it without < 1566176202 551404 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :And yet they don't seem to have great support for a lot of allocation strategies. < 1566176209 807172 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you could have a MyLocalBox or whatever for a different allocator < 1566176217 334819 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I guess. < 1566176233 56007 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :basically nothing in Rust's standard library assumes you're using a Box, it's always done with traits < 1566176259 575531 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there are standard trait combinations to use to say "this is a custom pointer-like thing" and then it can be used in all the same contexts that Box can < 1566176273 395292 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Last I tried Rust much Box was called ~, I think (or maybe @?). < 1566176284 487034 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it was called ~ < 1566176285 208688 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think @ was for garbage-collected or maybe reference-counted cells. < 1566176316 336904 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :nowadays ~ is called Box and @ was split into Rc and Arc (a Gc was planned but they never got around to it) < 1566176327 487453 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the Rc/Arc difference is that Arc is thread-safe but slower < 1566176397 646084 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(Rc can be used in multithreaded programs but Rust won't let you send one between threads, it's confined to a single thread) < 1566176438 87463 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shachaf: that's what cpressey said too ("https://esolangs.org/logs/2019-07-23.html#l2c") < 1566176441 248075 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Pervasive reference-counting doesn't seem like a great allocation strategy to me. < 1566176472 89604 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :b_jonas: No, I'm not annoyed by the language changing as long as I'm not using it. < 1566176488 799640 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I'd rather they make it better rather than try to ensure backwards compatibility. < 1566176538 734198 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: pervasive reference-counting is one of the reasons that Perl is probably unrecoverable from a performance point of view < 1566176567 756019 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I found out fairly recently (in the last few days) that Python uses pervasive reference-counting + a cycle-breaker, which seems even worse somehow (especially in a language which could easily use its own VM) < 1566176587 675655 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: what does "use its own VM" even mean? < 1566176596 286839 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: like Java has the JVM < 1566176607 667020 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :OCaml's allocation strategy is really interesting and apparently not widely used < 1566176645 110372 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: in Java's case that means that the programs are compiled down to an executable that the VM can run, and you don't need the compiler, only the VM, to run the program < 1566176646 687575 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :everything is 32-bit aligned, every 32-bit chunk has a tag bit saying whether or not it's a pointer < 1566176657 781685 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :but how is that relevant for what you've said above? < 1566176672 124027 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: I think this was changed at one point, but for a long time Python objects that had a reference cycle and destructors were just not collected. < 1566176674 651912 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this means that exact garbage collection is possible (not just conservative) and doesn't need to know anything about the structure of memory apart from the tag bits < 1566176708 736365 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: well, the JVM is an example of something that can implement exact reference counting, and even things like compaction, because it has full control over the structure of all the memory stored there < 1566176725 185821 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in Java you can swap out GC algorithms without changing the performance of the program < 1566176727 768946 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: doesn't it also mean that you can't easily have an array of numbers in a dynamically allocated thingy though? < 1566176737 775264 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and I don't think reference-counting + cycle-breaker can possibly be superior to a GC < 1566176754 15172 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: OCaml numbers are only 31 bits wide so that there's room for the tag bits < 1566176769 375084 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ints, at least < 1566176774 562747 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: right, so you can't have an array of proper numbers, only of OCaml numbers < 1566176781 187414 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :OCaml has to do fairly insane things to make floats work with this, which is a major downside < 1566176801 872837 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What's a cycle-breaker? < 1566176823 827661 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: something that detects a situation in which a nonzero reference count exists only because of objects recursively referencing each other < 1566176830 367363 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and not because the objects are actually referenced < 1566176835 295107 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and frees all the objects in the cycle < 1566176858 289863 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Fix the Rust documentation so that it does not use cookies/localstorage. A documentation page shouldn't require that anyways. < 1566176859 761395 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shachaf: a would-be-thief that decides that if he can't have your bicycle, then you can't either < 1566176893 27902 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I mean, how does it work other than effectively doing general GC? < 1566176914 675500 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: that's why I think it's ridiculous; it's basically most of the way to a general GC with all the disadvantages of an Rc < 1566177021 476815 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :that said, python can work with a pure Gc, and I think the python implementations that run in the jvm do that; and if you know that no dependency of your code needs the gc, then you can run cpython with just the refcounting, disabling the gc < 1566177101 132988 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :you can use destructors and/or weak references to make the pure refcounting work < 1566177140 908264 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :https://docs.python.org/3/library/gc.html#gc.disable < 1566177155 918981 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :(don't click on that if you want to use a local copy of the docs) < 1566177171 947178 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I don't think I have a local copy of the Python docs < 1566177181 859804 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :maybe I should, but I hardly program in Python < 1566177206 890424 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :If you program in a language all the time, you probably don't need the documentation. < 1566177230 645106 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :anyway, I had an idea wrt the OCaml way of doing things: for each type, identify the ratio of pointers to non-pointers in it (in terms of bytes), and allocate each type with a given ratio in its own arena < 1566177262 741006 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :/but/, you allocate the pointer and non-pointer parts in separate arenas too (the addresses of the two parts are mathematically related because of the constant ratio) < 1566177296 908669 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :now, you have all the pointers in memory blocks of their own, so that you can GC them really easily, and don't need to waste any bits on tagging things < 1566177388 200565 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :another benefit of this is that it statically guarantees that all pointers are correctly aligned, without needing to waste any bytes on padding < 1566177418 940575 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm not sure what the cache effect would be, there are reasons to think it would help but also reasons to think it would hinder < 1566177501 459116 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :`? flower < 1566177502 518906 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :flower. what IS a flower? < 1566177531 402703 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :actually, this is almost strictly better than the OCaml approach (which is already pretty good), the only downside is related to unions and other sum types < 1566177542 991600 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which are, of course, heavily used in OCaml, so that might be a problem < 1566177575 419908 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :unless, hmm, perhaps sum types could be references and the tag is stored in your choice of arena to point the pointer into < 1566177672 811812 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :OCaml is the sort of language that really wants a GC, because it heavily relies on immutable value types that it wants to avoid copying, /but/ also contains mutable data < 1566177729 800897 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(I think that languages which mutate a lot normally benefit from manual memory management, and with languages which don't mutate at all, reference counting is a more attractive possibility than it would be otherwise) < 1566177840 911772 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think languages should mutate a lot when they can, but they always seem to focus on backwards compatibility. < 1566177856 186311 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :This is why you should never release your software. < 1566177878 306156 :Sgeo_!~Sgeo@ool-18b98995.dyn.optonline.net QUIT :Ping timeout: 245 seconds < 1566177907 733009 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :I'm increasingly of the conclusion the transistor was a mistake. < 1566177919 838832 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :hikhq < 1566177925 314050 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :hichaf < 1566177988 863250 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :do you want to design my language for me twh < 1566177991 558552 :Sgeo!~Sgeo@ool-18b98995.dyn.optonline.net JOIN :#esoteric < 1566178017 489616 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :also do you want to see pictures of cute kittens < 1566178019 47594 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: Rust is instructive in that but I'm not sure in what direction < 1566178025 521167 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :Between work and general life demands I'm doing well to keep up on developments in programming languages, really < 1566178032 855843 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :Also, of course I do. Cute kittens are great. < 1566178042 784535 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :lots of people got upset that it changed so much before being stabilised, but OTOH it ended up really benefitting from the time < 1566178074 152139 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I do think it's beneficial to really work on a project's specification before the first release, though, making sure it's perfect < 1566178132 873680 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :There's still some things in the Rust stdlib that I think are kinda questionable... < 1566178198 17082 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :What things is that? < 1566178223 684374 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :Allocation failure is generally an unreported and unhandlable error. < 1566178245 205533 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :Which, yes, I know is more _ergonomic_, but it means you have limited options for handling that error condition. < 1566178253 832450 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think it'd be a pretty reasonable world for every sufficiently large company and so on to use its own programming language, rather than everyone standardizing on a few. < 1566178312 208247 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :pikhq: my experience with allocation failures is that almost every attempt I've seen to handle them is either equivalent to a crash, or more user-hostile than a crash would be < 1566178315 212574 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Unfortunately there's a lot of nonsense involved in making programming languages which probably shouldn't be necessary. And also cross-language interoperability is often very bad. < 1566178339 749778 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :And it feels a touch silly in a language that offers decent error handling approaches, and doesn't have semantics necessitating always-crash behavior < 1566178340 387245 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :arguably /every/ attempt < 1566178354 986416 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :ais523: For many programs, that is indeed the correct decision. < 1566178356 939809 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :Perhaps most. < 1566178392 41893 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :In Rust it grates because Rust is trying to handle problem spaces where that might _not_ be the best decision. < 1566178401 504009 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :pikhq: in programs where you'd want to do something else, you probably need safety against other sorts of crashes too, or even power failure < 1566178456 422156 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(also, my guess is that allocation failure in Rust is a panic, which is just about possible to handle, and I'm guessing that programs that care about allocation failure recovery care about panic recovery too) < 1566178478 107421 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :I believe there is an outstanding RFC for _making_ it a panic. < 1566178497 887447 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, it isn't atm? presumably that's due to a fear that destructors might allocate memory < 1566178513 679829 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :And yeah, having allocation failure be a panic is probably a reasonable strategy for a lot of programs. < 1566178516 408013 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think it would be obviously incorrect to make it anything less than a panic < 1566178543 910098 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :especially as it's almost impossible, on most computers, to reach the point of memory exhaustion < 1566178553 232459 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :memory is a shared resource, so the computer just runs slower and slower and slower as it gets shorter on memory < 1566178572 415284 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the point of true memory exhaustion doesn't actually get reached because the user has started force-quitting things and even doing hard power offs before then < 1566178578 618970 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :On my computer if a program uses too much memory, it just makes the kernel kill some other random program. < 1566178578 775711 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :Pretty frequently the hypothetical ideal allocation failure behavior is for a given task to abort, not for the program as a whole to. < 1566178588 437325 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :(but of course that's harder to achieve) < 1566178590 747047 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so an actual memory exhaustion only happens when it's a quota that got exhausted rather than physical memory < 1566178611 951279 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Are destructors a good idea? I can't tell. < 1566178618 439062 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :shachaf: On Windows on the other hand, the kernel just reports memory exhaustion. < 1566178618 743859 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(my life got a lot better when I realised that I could just set a per-program RAM usage quota) < 1566178634 641321 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :It has strict commit charge tracking. < 1566178656 276101 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :(though it's still hard to really get this to come into play, because the swap file scales in size) < 1566178677 484498 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It's kind of bizarre that Linux still uses swap partitions instead of files. < 1566178704 740357 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :To be honest, probably the most common case where allocation is going to report failure is exhaustion of address space on 32-bit systems. < 1566178718 911861 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :And that one's pretty easy to hit. < 1566178747 716646 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :Easier still to have an attempt to allocate that would exhaust address space, while still having plenty after the allocation failed. < 1566178758 976107 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: re destructors: my belief is no, except when it's syntactic sugar for something else (as is often the case with RAII), but for a slightly strange reason: if you have the sort of object that benefits from a destructor, you probably need to be tracking/organising all the references to the object anyway to be able to use it in a semantically correct way, in which case calling the destructor manually would be trivial < 1566178788 202607 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :re: swap: Linux can use swap files just fine, people are just used to setting up partitions < 1566178799 52292 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Can it suspend-to-disk to a swap file? < 1566178809 75577 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That's my main reason for having a swap partition. < 1566178847 514602 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :I wouldn't be surprised if using a swap file ends up having a performance penalty over a swap partition, just because the Linux swap code is pretty poo. < 1566178867 41719 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I also don't know why swapoff takes half an hour. < 1566178870 237436 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Also maybe the file is fragmented < 1566178875 410363 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :Not that swapping is _ever_ going to be fast, but Linux seems to do it a page at a time, synchronously. < 1566178886 584855 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(fwiw, I set my current laptop up with no swap, neither partition nor file, and have so far not regretted that decision at all) < 1566178887 695271 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I guess the reason is what pikhq just said. < 1566178949 118315 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :even then, you still get swapping-like behaviour at times of high memory pressure, but the kernel isn't swapping data out to disk, but rather unloading pages from memory that happen to equal the corresponding page on disk < 1566178981 798734 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think there are two main uses for destructors, which RAII wants to unify: < 1566179008 401599 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :One is objects on the stack, where things get auto-cleaned-up at the end of a scope. < 1566179038 361447 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :This is convenient but I think something like Python's "with" or Go's "defer" might address it better. It's mostly a control flow thing, not an object thing. < 1566179064 556727 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :does Java's try-with-resources fall into the same category? < 1566179077 812499 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The other is objects that contain other objects that contain other objects that have destructors, or something. < 1566179109 910925 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(the semantics: you write try (expression) {}, and when control leaves the {} for any reason at all, the ".close()" method is called don the expression; this includes exceptions and all control flow structures, in addition to just falling off the end naturally) < 1566179112 27215 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Where the whole tree is automatically traversed for you when you destruct the outermost object. < 1566179141 887230 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That sounds plausible? < 1566179173 978430 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :of course, things like System.exit() can beat the try-with-resources and prevent .close() from running, but the semantics are that the process can't continue until your destructor has run < 1566179180 264981 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I guess there's also the special case where you e.g. use a lock-acquiring-object and then tail-call another function and give it that object. < 1566179192 220685 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That's probably not handled with a thing like "with". < 1566179228 768060 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :semantically the only issue is that it wouldn't be a tail-call any more < 1566179249 713753 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I mean the case where you pass ownership of the lock-object to the other function. < 1566179260 826162 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So it can presumably destruct it at any point. < 1566179283 676729 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm… isn't the lock-object basically just a continuation? < 1566179301 817048 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Why? < 1566179316 176530 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I guess it's more like a callback < 1566179459 842691 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :anyway, I have one very strong opinion about memory management, which is: for immutable types that never change, programming languages (possibly unless they're /very/ low level) should provide an API which from the programmer's point of view looks like the objects are copied everywhere and never have multiple references, and should optimise it behind the scenes (which may involve garbage collection or reference counting of a single copy or whatever), < 1566179461 198374 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but should /never/ allow such objects to mix with any sort of memory allocation scheme that's explicitly controlled by the programmer < 1566179505 887504 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Why? < 1566179568 78063 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because the two cases are basically entirely different in terms of how you need to optimise them, and trying to treat them the same way makes both of them much more difficult < 1566179605 578163 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in particular, the programmer should never need to track immutable things, you can pass them around at will without any semantic issues, forget about them, whatever < 1566179627 410184 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :things that can be mutated are both rarer, and need a lot more care, typically you'll have some very regimented rules for using them already < 1566179653 582025 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Maybe your "/very/ low level" boundary is different from mine. < 1566179686 611665 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :for example, in NetHack, keeping track of the memory management for every string in the program is a lot of ridiculous effort, especially when you want to be able to pass the same string to multiple functions or to the same function multiple times < 1566179692 550940 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so a garbage collector for strings would be really nice < 1566179727 246882 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :OTOH, a garbage collector for in-game items, monsters, etc. would just be semantically wrong, because you want those things to stick around until you explicitly destroy them, and the destruction has a lot of /logic/ impacts that need consideration by the programmer < 1566179731 936117 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Is there a driver to use with Ghostscript to write to a DVI file? < 1566179766 112133 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :e.g. if the monster is holding an item, do you want to destroy that too? what if it's a plot-critical item that simply cannot be destroyed? you need to know where the monster "should have been" to place the item in the right location after hte monster is gone < 1566179796 832369 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so things like monsters are part of the game logic and managing their memory is trivial because you need to manage their state in just as much detail, and the memory management is easy to tack onto that < 1566179875 278617 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(I've also concluded that there's actually a third category here, things like "the internal state of an algorithm" that are mutable but self-contained and used only temporarily, but those are nearly always either stack-allocated or effectively-stack-allocated) < 1566179956 772610 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I guess you could make exceptions for, say, treesort, which could in theory be stack-allocated but nearly always isn't < 1566179958 669801 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :(Also, is it possible to add drivers to Ghostscript without recompiling?) < 1566180020 372435 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Why would treesort not be stack-allocated? < 1566180031 25495 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Or allocated in some kind of temporary memory. < 1566180037 631057 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the tree you're building is a recursive data structure the same size as the original list < 1566180063 587196 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :trying to express a stack-allocation of that, especially if the list is coming from a streaming source and you don't know how large it is, is incredibly difficult in most languages < 1566180090 554254 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Well, you can allocate in some temporary arena or something with effecitvely stack semantics. < 1566180106 759327 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :using a recursive function to do the stack allocation using its own call frames would work, but is inefficient due to the return addresses cluttering up the stack < 1566180127 518785 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Mergesort also allocates a linear amount of memory. < 1566180130 802631 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so you'd either need an alloca-alike or else a temporary arena < 1566180142 383987 :Hooloovo0!Hooloovoo@sorunome.de PRIVMSG #esoteric :could you do something fancy with tail recursion? < 1566180157 835648 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Tail recursion is pretty pointless if you have iteration. < 1566180173 952992 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Just write while (true). < 1566180224 613470 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :By the way: I realized that "if" evaluates its argument exactly once, at the time it's executed, so it's a lot like a function parameterized on a block. < 1566180236 186813 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But "while" re-evaluates its argument so it's not very function-like. < 1566180238 899322 :Hooloovo0!Hooloovoo@sorunome.de PRIVMSG #esoteric :hmm, I guess? < 1566180261 161088 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Is "while" an exception among control flow keywords? < 1566180323 671053 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric : could you do something fancy with tail recursion? ← I was actually just thinking that, and did some experiments; my conclusion is yes in theory, but no using the x86_64 calling convention < 1566180343 426006 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Actually, my real question is: If my function has user-definable control flow constructs, should they be functions, which is enough to support "if", and if so how should they handle "while"? < 1566180389 247017 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you'd need a calling convention in which the called function cleaned up the section of the stack between stack and base pointer for the caller < 1566180411 926331 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this calling convention is trivial to define but I don't see any benefit except in this one massively specific case, so I doubt it'd ever be used < 1566180453 332205 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: the mathematical solution is call-by-name, and the practical solution most languages use for that is to take a callback parameter, meaning that your language is genereally call-by-value but you call-by-name just this one small part < 1566180473 718347 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: There might be more benefit in non-recursive tail calls? But probably you should just manage the memory more epxplicitly if you're doing that. < 1566180496 860947 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so, e.g., in C, the prototype for while would look liike while(bool(*condition)(), void(*body)()) < 1566180513 761150 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because it's a function pointer not a value, the function you're calling can run it multiple times if it wants to < 1566180516 908206 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Except that presumably you're thinking of a closure and not a function pointer. < 1566180528 281119 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it would normally be a closure in practice < 1566180541 226386 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :doesn't have to be, though, it could just be a function constant < 1566180554 974374 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Anyway, I'd want this for an efficient language, where the predicate argument is guaranteed to be inlined at compiletime. < 1566180593 983812 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :If you have a notion of passing multiple blocks to a function, you could just write "while {p} {body}", which maybe wouldn't be so bad. < 1566180608 609072 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :I think the user defined control structures should be macros and not functions, and operate at compile time. < 1566180609 312515 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :heh, well I designed Verity a while back: intended for efficiency, call-by-name, callbacks are guaranteed to be inlined (in fact, absolutely everything is guaranteed to be inlined, which in turn means that the language doesn't support recursion) < 1566180625 424790 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :or, well, it does actually support recursion but it does so using a recursion combinator < 1566180635 875121 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :(The macro expansion will then put in all of the correct code to make it work properly at run time) < 1566180656 76876 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it doesn't support recursion via having a function call itself because that would just inline it < 1566180675 312493 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :zzo38: I'd like them to be something between macros and functions. < 1566180681 980789 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: hmm, I think that might be valid syntax in Perl (once you change "while" to something that isn't a keyword) < 1566180686 840242 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Maybe this just means hygienic macros, but I think it's a bit more than that. < 1566180700 197645 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :For example, I'd like a block to optionally take parameters. < 1566180709 637735 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So you might write "for(xs) {\x; ... }" < 1566180728 401421 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That's not just an AST, exactly, it's a compiletime object that can be called. < 1566180751 899025 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Yes, that makes sense, it could be hygienic macros that you can add blocks to take parameters. So, you can have anonymous macros perhaps? < 1566180775 596966 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I guess you could, though it doesn't seem that useful. < 1566180798 118617 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :I think may would be useful. < 1566180804 456133 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It's possible. < 1566180842 357220 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: impossible to reach memory exhaustion => unless you deliberately put a memory limit to catch it early, whether by setrlimit or through the memory allocator function itself < 1566180842 899597 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So my old language idea is, you have an operator that captures "the rest of block" and passes it as an argument to an expression. < 1566180863 767654 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So instead of writing "if(p) { body }", you can write "{ if(p)`; body }" < 1566180882 61373 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :but I do agree that it's usually not worth to handle an out of memory condition other than guaranteeing that it will crash properly rather than randomly corrupt memory < 1566180893 140877 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: yes, this is why I have a setrlimit on every program I start from the command line by default nowadays < 1566180908 504556 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :And also instead of writing "for(xs) {\x; ... }", you can write "{ x := for(xs)`; ... }" < 1566180916 847169 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(to catch fast memory leaks in programs I write, which I'd nearly always be running from the command line) < 1566180957 864077 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :If you're using this idea, you could maybe have "while" pass a special block that breaks from the loop when you pass it false. Then you could have "{ while`(p); body }". < 1566180971 529771 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I don't really like this, though, it seems pretty complicated. < 1566180993 694785 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: last time we discussed this, I think we had a debate about if it was a monad or not < 1566181004 362852 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :my current thoughts on this is that it works very well for if-like things but much less well for while-like things < 1566181010 973411 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What about for-like things? < 1566181035 658914 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :unsure, but currently leaning towards working < 1566181059 820212 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think it works quite well for "{ loop`; ... }" and "{ x := for(xs)`; ... }" < 1566181076 582759 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think this is nicer than almost any "for" construct in any language. < 1566181106 461198 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :For example I don't think anyone has a nice way to express "{ x := for(ns)` + 1; ... }" < 1566181108 102461 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :fwiw, I think "each" is a good name for it in this context < 1566181118 371234 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Sure, "each" is good. < 1566181158 271939 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this also generalises to "any" loops pretty well, but those aren't in common use (maybe they should be) < 1566181159 912718 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You can also write "{ x := for(xs)`; y := for(ys)`; if(x < y)`; ... }" and get something like list comprehensions. < 1566181169 499170 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What are "any" loops? < 1566181176 557483 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the loop exits unless there's an exception in the loop body < 1566181187 970435 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if there is an exception it just moves onto the next loop iteration < 1566181193 659473 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :How do you express the exception? < 1566181222 991215 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :normally it would be some sort of assertion failure, these loops are normally only used in declarative languages < 1566181232 819987 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You can also write "{ x := for(for(xss)`)`; ... } < 1566181240 663858 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but I've found myself writing them in, e.g., Java < 1566181254 630984 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I've hardly seen loops like this, or maybe I just haven't recognized them. < 1566181270 663225 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :where they're an ugly sort of "for (a : …) try { … ; break } catch (Exception ex) {} < 1566181272 214754 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :" < 1566181282 861255 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh man, no way. < 1566181300 42313 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you basically use them when you have multiple approaches that might potentially work, and just want to find one that works < 1566181311 604849 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think just writing a break at the last line of your loop is simple enough. < 1566181315 175346 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, that's not quite right, because if /every/ iteration fails you want to throw an exception < 1566181335 259097 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ideally that's a combination of all the others, but I haven't yet seen a language that does that < 1566181355 855322 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Probably related to Python-style for-else. < 1566181357 708329 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :"could not communicate by TCP because the socket is closed, nor via carrier pigeon because no pigeons were available" < 1566181370 301391 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I keep forgetting how for-else works < 1566181383 94170 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I used to think it was bizarre but now I think it's very natural. < 1566181393 236074 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :is it that the else block only runs if the loop has no iterations? < 1566181395 749859 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Though possibly it's even more natural to express it directly with my language idea. < 1566181412 545658 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The else block runs if the loop exits via the condition, instead of a break. < 1566181439 865504 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :aha, I do like that < 1566181442 935467 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the terminology is insane though < 1566181454 683074 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but the semantics are useful < 1566181473 116287 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oddly, I think it's the "break" I disagree with here rather than the "else" < 1566181484 791425 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because "break" is indicating "found"/"success" which the word "break" doesn't really imply < 1566181494 681751 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :In my language thing, you can label blocks with, say, @, and the label lets you exit them. < 1566181496 375066 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(likewise, "continue" is indicating failure) < 1566181505 10923 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :perhaps "done" is a good name for "break" < 1566181524 295263 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :"I keep forgetting how for-else works" => isn't that because there are at least two unrelated things with a name similar to them? < 1566181544 710385 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So "{ x := for(xs)`; ... }" actually means somthing like: { break := @`; x := for(xs)`; continue := @`; ... } < 1566181640 292033 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: I'd prefer "break" or "last" (especially if you have the full quadruplet "retry/redo/next/last"), because "done" is already used in a conflicting sense in sh < 1566181646 422343 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So if you wrote "for (xs) { body } else { notfound }" explicitly, it would be something like: { done := @`; { x := for(xs)`; continue := @`; ... }; notfound } < 1566181684 895787 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Who cares about sh? The only good thing about sh syntax is the way it handles variables. < 1566181823 654945 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: what does retry do? < 1566181885 152142 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: jumps to right before the start of the loop. not the start of the loop body, the start of the whole loop < 1566181986 881407 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :neat, that's a possibility I hadn't thought of < 1566182001 369433 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :now I sort-of want a control flow operator to go back to the previous loop iteration < 1566182027 988731 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: jumps to right before the start of the loop. not the start of the loop body, the start of the whole loop < 1566182048 314015 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think you sent the wrong line? < 1566182053 548730 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :yes, sorry < 1566182080 118070 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What's redo? < 1566182105 425878 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :
ACTION tries to wrap head around this
< 1566182137 826182 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: repeats the current loop iteration < 1566182155 843327 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so it's basically a goto to the start of the block, without increasing the loop counter or anything like that < 1566182190 142967 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I've used it a few times but it doesn't seem massively useful < 1566182216 356818 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I like the way both break and continue are forward jumps, and only the loop construct itself does a backward jump. < 1566182242 843619 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :I implemented Z-machine in C, JavaScript, and Glulx; now I do in PostScript. Later, I could try other stuff, such as PC, and Famicom (which I have started to do some time ago but haven't finished it), and possibly others too. What others will you implement Z-machine on? < 1566182248 410249 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's debatable where continue jumps to < 1566182272 316791 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm not sure it's observable whether it's a forwards or backwards jump (and at the asm level, backwards is normally more efficient unless the loop entry has been unrolled) < 1566182284 56100 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The C standard defines it as a forward jump. < 1566182297 702418 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I also think that's a much more sensible definition. < 1566182320 667117 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Yes, forward jump is sense, and then the optimizer could alter it < 1566182361 120461 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Let me see if I can label all the points in a loop to support these behaviors. < 1566182383 720563 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in BF, is ] a conditional or unconditional jump? < 1566182393 230433 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :{ @break; forever`; @retry; { @thing; forever`; @redo; x := for(xs)`; { @continue; BODY; }; thing; }; break; } < 1566182399 190500 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(you can even make the argument that ] is conditional but [ is unconditional) < 1566182445 217680 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :what does thing do? I'm still getting used to this notation < 1566182477 552506 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It exits the loop when you haven't used redo. < 1566182503 619115 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :There's probably a better way to express this. < 1566182600 140390 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I can see what that operation doesn't have a standard name :-D < 1566182636 544814 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in a more normal notation, the labels go here: retry: while(condition) { redo: BODY; continue:; } break:; < 1566182693 824213 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I like break-from-named-block much more than goto for control flow. < 1566182715 634582 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It probably doesn't clarify things here, though. < 1566182735 117557 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :(I think this is a good argument for retry/redo being confusing.) < 1566182786 530786 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :I prefer goto rather than named continue/break. < 1566182814 612194 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :I prefer named continue/break < 1566182818 965559 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :goto has too many ways to be evil < 1566182863 930560 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I even wonder whether you should just not have continue/break and be explicit about writing the labels when you want them. < 1566182908 695699 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :moony: Well, so does any other feature, I think. < 1566182910 909630 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm, the only situation in which I find myself tempted to use goto, and it clearly isn't a standin for a missing control structure, is when you have lots of if statements with the same body but they're scattered around the function so you can't combine the conditions, and they're too tightly tied to local variables to extract into a function < 1566182918 569647 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you can use temporary booleans for that instead but I think the goto is clearer < 1566182938 76592 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Yes, and I think there are also other situations where goto is clearer. < 1566182939 553964 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: This sounds like a use case for the "blocks" I was describing earlier. < 1566182944 396716 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: I think the issue is that the loops are too generically named < 1566182983 794968 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :I have once written how to convert a program with goto so that it only uses labeled continue/break, which, for example can be used with JavaScript. < 1566182990 943256 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :something like Python's for-else has a clearly defined intended use, Haskell's map also has a clearly defined intended use, but both operations become a for loop in most languages even though they function very differently < 1566183017 474228 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :things like continue and break have unclear semantics because the loops they're short-circuiting/exiting have varying semantics < 1566183059 876660 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :With your goto notation, for (x in xs) { BODY } else { ELSE } is "for (x in xs) { BODY; continue: }; ELSE; break: " < 1566183101 939864 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes < 1566183116 556446 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and a label before the ELSE should probably be called "fail" < 1566183223 711067 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Man, { x := for(xs)`; if(valid(x))`; switch(x)`; { case(A)`; ... }; { case(B)`; ... } } < 1566183226 652258 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So flat. < 1566183261 353525 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :for (x in xs) { if (valid(x)) { switch(x) { Case A: ...; Case B: ... } } } < 1566183335 529618 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm, that's semantically correct but isn't it basically an if/else chain? < 1566183354 874238 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The switch part? Sure. < 1566183358 862420 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the original purpose of a switch was to hint to a compiler that it might want to make a jump table < 1566183373 408497 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but I guess that nowadays, maybe switches are just syntactic sugar for the if/else chain < 1566183564 285018 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Anyway I don't believe in exceptions so you'd need some other way to express "any". < 1566183592 538523 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think it might reasonable to say that the loop breaks by default and you can explicitly tell it to continue instead. < 1566183616 814766 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But it seems infrequent enough that you can probably just write out the control flow yourself? < 1566183624 885015 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :well, I'm using "exception" in a general sense, it's any situation where the code says "OK, this won't work" < 1566183639 582293 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Sure. < 1566183639 958028 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think people normally just use "continue" for failures and "break" for successes < 1566183650 659955 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :then an any loop is just a regular for loop < 1566183657 705707 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Maybe you can require an "else" clause for "any" loops. < 1566184736 682227 :ais523!~ais523@unaffiliated/ais523 QUIT :Quit: quit < 1566187427 185924 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 245 seconds < 1566187782 340464 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1566187880 15876 :kolontaev!~kolontaev@slow.wreckage.volia.net QUIT :Quit: leaving > 1566188660 929369 PRIVMSG #esoteric :14[[07ADxc14]]4 N10 02https://esolangs.org/w/index.php?oldid=65559 5* 03A 5* (+467) 10Created page with "==Example== Suppose your snippets were AD, xc, 123, and ;l. Then: * AD should produce 1 * [[ADxc]] should produce 2 * ADxc123 should produce 3 * and ADxc123;l should produce..." > 1566192179 450208 PRIVMSG #esoteric :14[[07JUMP14]]4 10 02https://esolangs.org/w/index.php?diff=65560&oldid=41105 5* 03Dtuser1337 5* (+66) 10Adding some category. > 1566192255 354952 PRIVMSG #esoteric :14[[07Tarpit14]]4 10 02https://esolangs.org/w/index.php?diff=65561&oldid=40466 5* 03Dtuser1337 5* (+22) 10 > 1566192498 826237 PRIVMSG #esoteric :14[[07JUMP14]]4 10 02https://esolangs.org/w/index.php?diff=65562&oldid=65560 5* 03Dtuser1337 5* (+34) 10Woosh > 1566192693 769611 PRIVMSG #esoteric :14[[07Truth-machine14]]4 10 02https://esolangs.org/w/index.php?diff=65563&oldid=64960 5* 03Dtuser1337 5* (+84) 10/* Jug */ > 1566192753 198041 PRIVMSG #esoteric :14[[07Truth-machine14]]4 10 02https://esolangs.org/w/index.php?diff=65564&oldid=65563 5* 03Dtuser1337 5* (+2) 10/* JUMP */ > 1566195362 495869 PRIVMSG #esoteric :14[[07Truth-machine14]]4 10 02https://esolangs.org/w/index.php?diff=65565&oldid=65564 5* 03Dtuser1337 5* (+207) 10My implementation of truth machine in emoji-gramming. > 1566196059 267665 PRIVMSG #esoteric :14[[07Turth-machine14]]4 10 02https://esolangs.org/w/index.php?diff=65566&oldid=63931 5* 03Dtuser1337 5* (+80) 10formatting codebase and adding categories. > 1566196217 554913 PRIVMSG #esoteric :14[[07Hello world program in esoteric languages14]]4 10 02https://esolangs.org/w/index.php?diff=65567&oldid=65558 5* 03Dtuser1337 5* (+43) 10/* Trigger */ > 1566196301 355487 PRIVMSG #esoteric :14[[07Truth-machine14]]4 10 02https://esolangs.org/w/index.php?diff=65568&oldid=65565 5* 03Dtuser1337 5* (-6) 10/* Turth-machine */ > 1566196556 961752 PRIVMSG #esoteric :14[[07Turth-machine14]]4 10 02https://esolangs.org/w/index.php?diff=65569&oldid=65566 5* 03Dtuser1337 5* (+45) 10 > 1566198239 169255 PRIVMSG #esoteric :14[[07Capuirequiem14]]4 10 02https://esolangs.org/w/index.php?diff=65570&oldid=58513 5* 03Dtuser1337 5* (-1) 10/* External resources */ > 1566198309 668777 PRIVMSG #esoteric :14[[07RETURN14]]4 10 02https://esolangs.org/w/index.php?diff=65571&oldid=38078 5* 03Dtuser1337 5* (+13) 10/* External resources */ > 1566198413 663495 PRIVMSG #esoteric :14[[07Nil14]]4 10 02https://esolangs.org/w/index.php?diff=65572&oldid=52918 5* 03Dtuser1337 5* (+1) 10/* External resources */ < 1566198670 754461 :Sgeo_!~Sgeo@ool-18b98995.dyn.optonline.net JOIN :#esoteric < 1566198896 553255 :Sgeo!~Sgeo@ool-18b98995.dyn.optonline.net QUIT :Ping timeout: 272 seconds > 1566198952 41440 PRIVMSG #esoteric :14[[07CopyPasta Language14]]4 10 02https://esolangs.org/w/index.php?diff=65573&oldid=56021 5* 03Dtuser1337 5* (+13) 10 < 1566201204 218855 :AnotherTest!~turingcom@d51a4b8e1.access.telenet.be JOIN :#esoteric < 1566203127 292582 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 245 seconds < 1566203172 561492 :Sgeo__!~Sgeo@ool-18b98995.dyn.optonline.net JOIN :#esoteric < 1566203261 736644 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1566203391 772637 :Sgeo_!~Sgeo@ool-18b98995.dyn.optonline.net QUIT :Ping timeout: 268 seconds < 1566205756 204297 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru JOIN :#esoteric < 1566208429 166188 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :yes, that's how I think of it. imagine added labels like A: for (init; cond; step) { B: body; C: } D: < 1566208447 996366 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :then retry/goto jumps to A, redo jumps to B, next/continue jumps to C, last/break jumps to D < 1566211423 922454 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :ah, these polysigns are simply amateur algebra (bordering crackpottery), bleh. We take a vector space spanned by e[0], …, e[n−1], add a product e[i] e[j] = e[(i + j) mod n] and factor it all so e1 + … + en = 0. Why don’t people read good math textbooks and speak the consensus language < 1566211486 973501 :Taneb!~Taneb@runciman.hacksoc.org PRIVMSG #esoteric :Polysigns? < 1566211532 6269 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :though an analysis paper by Hagen von Eitzen doesn’t go in this straightforward way so IDK, maybe one can’t factor an algebra this way < 1566211618 460161 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :Taneb: a person named sombrero posted a link on some images hosted on vixra ≈yesterday. I didn’t look at them but I saw that word in the abstract and went investigating what it is < 1566211647 669045 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :unfortunately, my expectations were confirmed < 1566211696 221012 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :(amateur math with crackpotish philosophical claims) < 1566211722 29779 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :and also an old one: the analysis paper is 2009 < 1566211748 696516 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :b_jonas: Where that expands further to A: init; while (cond) { B: body; C: step; } D: presumably < 1566211766 455162 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shachaf: yes < 1566211775 166746 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :linear algebra is sufficient to do many many things people try to invent < 1566211805 455019 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :(of course it’s a trivial statement here) < 1566211818 447898 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :(but not somewhere there) < 1566211821 751216 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shachaf: well actually more like A: { init; while (cond) { B: body; C: step; } } D: if you care about the scope of the variables declared in init < 1566211938 365026 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :One of the nice things about my system is that many things gets correctly scoped by default. < 1566211968 206778 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Instead of Go-style "if x := e; p(x) { ... }" you can just write "{ x := e; if(p(x))`; ... }" < 1566211972 505156 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :get < 1566211996 84488 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :(ah, now I see the author uses a R[x] as a base because its multiplication is almost right) < 1566212047 55834 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shachaf: "if x:= e; p(x) { ... }" is actual syntax? < 1566212080 527640 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :that looks odd to me because in ruby (and julia too) the semicolon would end the condition and start the loop body, but I guess it makes sense because sh works that way too < 1566212090 189583 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It's syntax in Go, yes. < 1566212111 160227 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :the sh syntax for while loops allows you to put multiple statements in the condition too, which means you can put the test anywhere in the middle of the loop, you don't need a separate do-while loop or if-break < 1566212121 409469 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think something like "if (auto x = e; p(x)) { ... }" is syntax in recent C++ too. < 1566212145 401239 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shachaf: dunno, I can't follow that < 1566212177 761436 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :in perl you can write { my $x = e; p(x) or last; body } < 1566212189 952222 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It just declares something that's only in the scope of the if. < 1566212310 895680 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Presumably it means the same as { x := e; if (p(x)) { ... } } < 1566212420 76315 :heroux!sandroco@gateway/shell/insomnia247/x-fnsmdxsfkpisygab QUIT :Ping timeout: 248 seconds < 1566212875 298269 :heroux!sandroco@gateway/shell/insomnia247/x-rlhsvfwjxoccdzaj JOIN :#esoteric < 1566213172 140601 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Hmm, this looks like a good preamble for a SMETANA program to me :) Step 1. Swap step 1 with step 2. Step 2. Go to step 1. < 1566213534 101505 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :Imagine an alternate universe where English didn't become a lingua franca, so there are entire libraries where all the identifiers are in German, ones where all of them are Russian, ones where all of them are in French, < 1566213559 730127 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :but you sometimes end up with names mixing words from different languages because the concept has a name popularized by an earlier library, < 1566213579 258619 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :and perhaps the oldest libraries with the worst names, like ncurses in our world, would even be all in latin. < 1566213617 403262 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It's ironic that you're calling English a "lingua franca" in that description. < 1566213635 373340 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :and then some libraries with English names would appear too. < 1566213670 488552 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :and you'd have to learn the basics of three or four different languages to understand source code, which was basically the status of scientific research in the 1960s < 1566213760 699914 :Taneb!~Taneb@runciman.hacksoc.org PRIVMSG #esoteric :fenestram_crea < 1566213826 933655 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :yes, you'd probably have to know not only the root words, but also conjugation in latin, french, italian, german, and russian to be able to guess the spelling of identifiers if you want to write code < 1566213841 787654 :Taneb!~Taneb@runciman.hacksoc.org PRIVMSG #esoteric :Sounds fun, we should make this happen < 1566213879 966053 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :Taneb: sure, but do it in a modern way, where latin is excluded but instead we have chinese identifiers too < 1566213907 143990 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I mean using latin directly is excluded, we can still have the french and italian and portugeese identifiers of course < 1566213916 872329 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :(and englihs) < 1566214097 327843 :Taneb!~Taneb@runciman.hacksoc.org PRIVMSG #esoteric :Hmm, a lot of libraries are American, so would naturally be written in English < 1566214104 201865 :Taneb!~Taneb@runciman.hacksoc.org PRIVMSG #esoteric :Or maybe Spanish or Navajo or something < 1566214149 406494 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :and we may have some short identifiers that are ambiguous because they mean something different depending on what language you're reading them in < 1566214156 808501 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I wonder if we can engineer such a situation in common keywords < 1566214237 249049 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :`? zodiac < 1566214238 318902 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :zodiac? ¯\(°​_o)/¯ < 1566214239 872764 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :`? signs < 1566214241 256853 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :signs? ¯\(°​_o)/¯ < 1566214242 248418 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :`? signs of the zodiac < 1566214243 308086 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :signs of the zodiac? ¯\(°​_o)/¯ < 1566214294 402656 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Oh I just realized that SMETANA may just be powerful enough to write a quine in. (But I'm targeting SMETANA To Infinity! for now.) < 1566214348 893908 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Well, if we steal the output instruction from S2I that is. < 1566214359 532570 :int-e!~noone@int-e.eu PRIVMSG #esoteric :No output, no quine... :) < 1566214377 553479 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What if you just put the quine in memory? < 1566214385 752921 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :For example, in the text section. < 1566214422 871391 :int-e!~noone@int-e.eu PRIVMSG #esoteric :shachaf: Maybe you should refresh your memory (no pun intended) on what SMETANA is. < 1566214517 947663 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :tha handle transform tool in gimp 2.10 is such a blessing, it was so hard to do proper alignments of multiple pictures with affine or perspective transforms before that < 1566214534 762383 :int-e!~noone@int-e.eu PRIVMSG #esoteric :(SMETANA suffers from being a finite state machine; all data has to be encoded somehow in the program itself as written. So you need some serious compression to allow the program to contain a representation of itself, which stretches the term "quine" beyond the limits I'm willing to allow.) < 1566214642 422814 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :how does it stretch the term "quine"? < 1566214643 322598 :int-e!~noone@int-e.eu PRIVMSG #esoteric :shachaf: Of course we could define other output conventions without extending the language... like looking at the trace and mapping certain predetermined addresses to characters. < 1566214658 952381 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :int-e: I didn't even know about SMETANA until I looked it up 25 minutes ago. < 1566214697 184742 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But I was making a general joke that is equally bad in any language. < 1566214730 692688 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :(The joke is, define "output" to be some region of memory. At program startup, the program is loaded into memory, and therefore you can define that region to be the output and call it a quine.) < 1566214767 13938 :int-e!~noone@int-e.eu PRIVMSG #esoteric :b_jonas: Well, I don't know how to delineate decompression and a BASIC-style 'LIST' function that makes quines trivial. < 1566214808 142656 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :@time < 1566214812 543190 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :Local time for shachaf is Mon Aug 19 04:40:08 2019 < 1566214828 237505 :int-e!~noone@int-e.eu PRIVMSG #esoteric :it's getting worse < 1566214838 773123 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :[ fungot, is j-bot here? < 1566214839 362340 :fungot!~fungot@2a01:4b00:82bb:1341::2 PRIVMSG #esoteric :b_jonas: not very quickly, and it has a non-real-time gc, but that's just what the user expected type character, got ' ( 1 2 3) < 1566214977 742168 :int-e!~noone@int-e.eu PRIVMSG #esoteric :fungot's almost making sense again (though I guess that last part is closer to Lisp than to J?) < 1566214978 64749 :fungot!~fungot@2a01:4b00:82bb:1341::2 PRIVMSG #esoteric :int-e: lms that doesn't violate her fnord, either. probably still aren't. is slib standard? < 1566215010 921308 :int-e!~noone@int-e.eu PRIVMSG #esoteric :oh well, the moment of clarity has passed < 1566215188 752720 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :fungot: Was that Lisp or J? < 1566215188 931108 :fungot!~fungot@2a01:4b00:82bb:1341::2 PRIVMSG #esoteric :shachaf: ( define ( get-move-console) count)). the funge-98 standard is also written in scheme < 1566215204 308589 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :fungot: the reason why people don't take you seriously is that you aren't using the One True Style for formatting your code. don't put whitespace after the left parenthesis or after the quote < 1566215204 626552 :fungot!~fungot@2a01:4b00:82bb:1341::2 PRIVMSG #esoteric :b_jonas: goes where no other music fnord or has been in jail. we went to another bar. then we only need to cons stuff onto the top of < 1566216472 161921 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :peksy arthropods, thinking that I invited them just because I left food open on the counter < 1566216506 502647 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :if you want food, buy your own, darn it < 1566216645 522405 :j-bot!eldis4@firefly.nu JOIN :#esoteric < 1566216649 690585 :FireFly!znc@freenode/staff/firefly PRIVMSG #esoteric :[ 'hi' < 1566216650 361099 :j-bot!eldis4@firefly.nu PRIVMSG #esoteric :FireFly: hi < 1566216698 630307 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :nice, thanks < 1566217005 43558 :andrewtheircer!6d5da57e@gateway/web/cgi-irc/kiwiirc.com/ip.109.93.165.126 JOIN :#esoteric < 1566217812 729674 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :is there a strongly typed golf language where, if your code isn't well-typed, it tries to put extra stuff like parenthesis and other extra stuff into your code until it's well-typed, so if you use the type system well, you can omit a lot of things from the parse tree? < 1566217828 908778 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :would need a good built-in library and good heuristics for what to insert < 1566217860 251757 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :and might be harder to program in than Jelly < 1566218010 67231 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :also, is there a golf language that is basically the same as haskell but with a much more golfier syntax? < 1566218026 427874 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I don't think blsq counts as such < 1566218169 793610 :andrewtheircer!6d5da57e@gateway/web/cgi-irc/kiwiirc.com/ip.109.93.165.126 PRIVMSG #esoteric :i dunno either, jonas < 1566219173 332873 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :oh, I get it! if a C compiler environment isn't made for hard realtime programs, then the library defines the PRIoMAX macro to "llo", meaning that the maximum priority that your threads will be able to run is very low < 1566219460 885505 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :``` gcc -O -Wall -o /tmp/a -x c - <<<$'#include\n#include\n int main(void){ printf("maximum thread priority: %s\\n", PRIoMAX); return 0; }' && /tmp/a < 1566219461 981928 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :maximum thread priority: lo < 1566219469 974518 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :that's slight better, it's only low, not very low < 1566220524 417915 :andrewtheircer!6d5da57e@gateway/web/cgi-irc/kiwiirc.com/ip.109.93.165.126 QUIT :Quit: Ping timeout (120 seconds) < 1566220548 10206 :arseniiv_!~arseniiv@46.191.137.50 JOIN :#esoteric < 1566220653 533160 :andrewtheircer!6d5da57e@gateway/web/cgi-irc/kiwiirc.com/ip.109.93.165.126 JOIN :#esoteric < 1566220654 203184 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru QUIT :Ping timeout: 246 seconds < 1566220790 839977 :andrewtheircer!6d5da57e@gateway/web/cgi-irc/kiwiirc.com/ip.109.93.165.126 PRIVMSG #esoteric :oop > 1566222845 536779 PRIVMSG #esoteric :14[[07Special:Log/newusers14]]4 create10 02 5* 03Mid 5* 10New user account < 1566224194 134926 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :apparently the We The Robots comics has ended the long hiatus, except it's not at the old address "http://www.chrisharding.net/wetherobots/" but at "http://www.wetherobots.com/" now < 1566224200 568150 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I haven't noticed until now < 1566224206 503999 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :this is what happens when you break urls < 1566224995 75092 :sleepnap!~thomas@c-68-55-111-60.hsd1.mi.comcast.net JOIN :#esoteric > 1566225057 501607 PRIVMSG #esoteric :14[[07ABCD14]]4 10 02https://esolangs.org/w/index.php?diff=65574&oldid=46025 5* 03Dtuser1337 5* (+18) 10 < 1566225574 441390 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :question. is it possible to make a terminfo entry for irc that tells how to output colors and bold and italic with the mirc codes, and if so, will gcc output colored error messages in HackEso? < 1566225604 56522 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I don't know if gcc's colored error messages respects that < 1566225654 233657 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I made a terminfo entry once, but only by editing a single value in an existing entry < 1566225858 195619 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I should check the ncurses sources in case it already has such an entry though < 1566226485 696798 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :whoa... are the terminfo thingies no longer distributed with ncurses? where do they come from then? < 1566226917 222670 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I'll check what debian thinks < 1566227086 196092 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :the compiled entries come from the ncurses-term package, now how do I find what the source package is for that? < 1566227161 246888 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :and the source package is apparently ncurses < 1566227213 736374 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ah < 1566227218 80782 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :it is in ncurses < 1566227220 592038 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :in one giant file < 1566227233 752291 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :called ncurses-6.1/misc/terminfo.src < 1566227282 139710 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :now the question is, can terminal libraries handle that the same code toggles bold on and off? < 1566227294 506926 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :and also the way how you can't put a digit after a color code? < 1566227326 979302 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :if not, we need a filter after it, which would be ugly < 1566227353 325338 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I guess for the latter, I can just force put two bold codes after a color code < 1566227361 460426 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :and for the former, just hope it works < 1566227852 678027 :xkapastel!uid17782@gateway/web/irccloud.com/x-iysxgalxowpkpzed JOIN :#esoteric < 1566227975 997887 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :that debian package ncurses-term, by the way, contains the _additional_ compiled terminfo entries, the decades of legacy terminals that nobody uses anymore < 1566228189 410326 :Taneb!~Taneb@runciman.hacksoc.org PRIVMSG #esoteric :Imagine if people started adding footnotes* to their IRC messages < 1566228192 5063 :Taneb!~Taneb@runciman.hacksoc.org PRIVMSG #esoteric :* like this one# < 1566228213 737707 :andrewtheircer!6d5da57e@gateway/web/cgi-irc/kiwiirc.com/ip.109.93.165.126 PRIVMSG #esoteric :nice < 1566228219 678894 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :it's actually split around the directory tree too, so the important terminfo entries are in /lib/terminfo , the rest are in /usr/share/terminfo , in case you're mounting usr late < 1566228233 101370 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :`? footnote 1 < 1566228234 267256 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :May contain nuts. < 1566228239 120886 :andrewtheircer!6d5da57e@gateway/web/cgi-irc/kiwiirc.com/ip.109.93.165.126 PRIVMSG #esoteric :can i add meta footnotes* < 1566228241 595369 :andrewtheircer!6d5da57e@gateway/web/cgi-irc/kiwiirc.com/ip.109.93.165.126 PRIVMSG #esoteric :may contain nuts < 1566228382 662278 :andrewtheircer!6d5da57e@gateway/web/cgi-irc/kiwiirc.com/ip.109.93.165.126 PRIVMSG #esoteric :`? footnote 1 < 1566228383 809145 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :May contain nuts. < 1566228752 455993 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :fungot, do you have a calendar? has SGDQ 2019 started yet? < 1566228752 541967 :fungot!~fungot@2a01:4b00:82bb:1341::2 PRIVMSG #esoteric :b_jonas: wtf is that? that problem haunts me. i don't think < 1566228759 809501 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :uh ok < 1566229855 574431 :andrewtheircer!6d5da57e@gateway/web/cgi-irc/kiwiirc.com/ip.109.93.165.126 PRIVMSG #esoteric :oh < 1566230599 957490 :joast!~rick@cpe-98-145-132-215.natnow.res.rr.com QUIT :Quit: Leaving. < 1566230638 377425 :joast!~rick@cpe-98-145-132-215.natnow.res.rr.com JOIN :#esoteric < 1566233562 376385 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :fungot: I take it you don't watch speedruns then? < 1566233562 833782 :fungot!~fungot@2a01:4b00:82bb:1341::2 PRIVMSG #esoteric :fizzie: if i remove the fan, heatsink, installation instructions and finally the body is ( are) returned. this expression type is used at a german bank for financial simulations. but that's a mere one character :) i'm not complaining < 1566233578 984035 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :fungot, 45 minutes is how many hours? < 1566233579 217351 :fungot!~fungot@2a01:4b00:82bb:1341::2 PRIVMSG #esoteric :b_jonas: you could just select another transport module system in the works to start off by reading sicp or htdp. < 1566233599 244556 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :fungot: don't remove the fan and heatsink! the cpu will overheat < 1566233599 394460 :fungot!~fungot@2a01:4b00:82bb:1341::2 PRIVMSG #esoteric :b_jonas: is that what you mean < 1566233611 44959 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :yes < 1566233877 99349 :andrewtheircer!6d5da57e@gateway/web/cgi-irc/kiwiirc.com/ip.109.93.165.126 PRIVMSG #esoteric :unfulfilling < 1566234253 316328 :Phantom_Hoover!~phantomho@unaffiliated/phantom-hoover JOIN :#esoteric < 1566235149 273608 :int-e!~noone@int-e.eu PRIVMSG #esoteric :`footnote 1 < 1566235149 874062 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :May contain nuts. < 1566235224 165203 :int-e!~noone@int-e.eu PRIVMSG #esoteric :`? password < 1566235225 846738 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :The password of the month is surprising. < 1566235275 204377 :Sgeo!~Sgeo@ool-18b98995.dyn.optonline.net JOIN :#esoteric < 1566235452 532430 :Sgeo__!~Sgeo@ool-18b98995.dyn.optonline.net QUIT :Ping timeout: 272 seconds < 1566235829 68543 :andrewtheircer!6d5da57e@gateway/web/cgi-irc/kiwiirc.com/ip.109.93.165.126 PRIVMSG #esoteric :e < 1566236316 953045 :FreeFull!~freefull@defocus/sausage-lover JOIN :#esoteric < 1566237229 376518 :andrewtheircer!6d5da57e@gateway/web/cgi-irc/kiwiirc.com/ip.109.93.165.126 QUIT :Remote host closed the connection < 1566237765 210967 :arseniiv_!~arseniiv@46.191.137.50 NICK :arseniiv < 1566238196 533868 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :Taneb: I¹ proved² the Riemann hypothesis³ false⁴ < 1566238230 951004 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :but the page is too short for the footnote section so no one will know what I meant < 1566238250 614403 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :mwahaha < 1566238361 974104 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :though one footnote can be crammed into the margin (¹ I — Roman numeral 1) < 1566238375 168539 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :s/into/onto < 1566238376 504738 :int-e!~noone@int-e.eu PRIVMSG #esoteric :. o O ( "I proved the Riemann hypothesis" [is] false. ) < 1566238411 623377 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :int-e: ah yes, newspaper heading grammer < 1566238428 437202 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Oh. We can claim that this is a portmanteau. < 1566238444 874218 :int-e!~noone@int-e.eu PRIVMSG #esoteric :(hypothesis and is -> hypothesis) < 1566238473 805419 :int-e!~noone@int-e.eu PRIVMSG #esoteric :`grWp portmanteau < 1566238475 298641 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :friend:friend is a portmanteau of fritter and rend \ ism:Isms are philosophies, religions or ideologies that have branched off from older ones, such as Leninism or Buddhism. Etymologically "ism" is a backformation from portmanteaus on "schism". \ portmanteau:«Portmanteau» is the French spelling of “port man toe”. < 1566239737 303020 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :`? shoehorn < 1566239738 317726 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :shoehorn? ¯\(°​_o)/¯ < 1566239745 222621 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :`? bottleneck < 1566239746 371963 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :bottleneck? ¯\(°​_o)/¯ < 1566239977 828588 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :int-e: :D but is omission of this kind grammatical? < 1566240010 927730 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric : (hypothesis and is -> hypothesis) => ah, quite clever < 1566240047 38716 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :one can even claim that hypotheses < hypothesises :D < 1566240081 72390 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :or not, it seems different phonetically? < 1566240098 804961 :int-e!~noone@int-e.eu PRIVMSG #esoteric :arseniiv: FWIW I initially intended to provide a footnote 4 that would redefine "false", but didn't find any nice formulation... < 1566240135 694845 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :why, false is true < 1566240169 592867 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :though this is not nice at all < 1566240217 230456 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :I had in mind conflating unprovedness, unprovability and proved negation < 1566240249 275329 :int-e!~noone@int-e.eu PRIVMSG #esoteric :arseniiv: https://www.youtube.com/watch?v=8keZbZL2ero is somehow relevant < 1566240251 136821 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :but decided to let it vague (v) for a time < 1566240509 635248 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :int-e: hehe < 1566240955 352168 :Melvar!~melvar@dslb-188-106-184-179.188.106.pools.vodafone-ip.de QUIT :Quit: WeeChat 2.4 < 1566242765 533035 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1566242778 476835 :ais523!~ais523@unaffiliated/ais523 QUIT :Client Quit < 1566242791 531573 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1566242815 271862 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric : is there a strongly typed golf language where, if your code isn't well-typed, it tries to put extra stuff like parenthesis and other extra stuff into your code until it's well-typed, so if you use the type system well, you can omit a lot of things from the parse tree? also, is there a golf language that is basically the same as haskell but with a much more golfier syntax? ← yes to both, and it's the same language: Husk < 1566242841 887837 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ooh, let me look < 1566242857 919002 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :hmm, there doesn't seem to be an article on the wiki < 1566242998 449060 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :CGCC users rarely bother with creating wiki articles for their golflangs :-( < 1566243014 340890 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :they normally just link to the github repo to let people know wha the language is < 1566243027 462990 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :https://github.com/barbuz/Husk in this case < 1566243038 316112 :Sgeo_!~Sgeo@ool-18b98995.dyn.optonline.net JOIN :#esoteric > 1566243064 743518 PRIVMSG #esoteric :14[[07Husk14]]4 N10 02https://esolangs.org/w/index.php?oldid=65575 5* 03B jonas 5* (+158) 10stub > 1566243093 600516 PRIVMSG #esoteric :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=65576&oldid=65520 5* 03B jonas 5* (+11) 10Husk < 1566243136 414106 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :oh no, not yet another golf language with its own custom eight-bit character set < 1566243182 868566 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :most golf languages do that < 1566243189 356755 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because control codes are /really/ hard to read and type < 1566243214 273922 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(a golf language I'm sporadically working on has its own /six/-bit character set, which has the advantage that I can make it a subset of ASCII) < 1566243228 316600 :Sgeo!~Sgeo@ool-18b98995.dyn.optonline.net QUIT :Ping timeout: 245 seconds < 1566243274 802832 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I guess it's still better than if the golf language has a tricky variable length compression, so reading and writing it is more difficult than just translating characters < 1566243288 658642 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :like a hufmann encoding or even worse < 1566243291 602696 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :with shift codes < 1566243328 692168 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :of course Jelly's compressed string modes are sort of like that < 1566243906 761336 :heroux!sandroco@gateway/shell/insomnia247/x-rlhsvfwjxoccdzaj QUIT :Ping timeout: 268 seconds < 1566244019 530380 :adu!~ajr@pool-173-73-86-191.washdc.fios.verizon.net JOIN :#esoteric < 1566244032 160696 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :interesting < 1566244299 939591 :heroux!sandroco@gateway/shell/insomnia247/x-czajepotlypsxlhl JOIN :#esoteric < 1566245012 889655 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :ais523: thanks for an interesting language! < 1566245042 972863 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :though golflangs make my head spin, there are so many details because of need to compress < 1566245071 301243 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :nondeterministic typing there is cool < 1566245120 283352 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :(hopefully it’s implemented in such a way as to not blow up combinatorily) < 1566245289 576710 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :I’d type overloaded multimethods using union typing, but am I right it’s not easily added to Hindley—Milner-like inference? < 1566245296 687584 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it might blow up at compile time but that's probably forgivable, golflang programs are short < 1566245352 223555 :Melvar!~melvar@dslb-188-106-184-179.188.106.pools.vodafone-ip.de JOIN :#esoteric < 1566245401 808277 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I wonder if there's a golf language that has a built-in that gets the OEIS sequence from its index, and to compute its terms, tries to automatically run code in the OEIS entry, so requires Maple and Mathematica plus ten gigabytes of other software to run. < 1566245422 336807 :sleepnap!~thomas@c-68-55-111-60.hsd1.mi.comcast.net QUIT :Quit: Leaving. < 1566245428 393022 :arseniiv!~arseniiv@46.191.137.50 PRIVMSG #esoteric :b_jonas: (rofl) < 1566245452 963738 :sleepnap!~thomas@c-68-55-111-60.hsd1.mi.comcast.net JOIN :#esoteric < 1566245483 153221 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :and of course you download a snapshot of the OEIS at the time you build the compiler, so that it doesn't cheat by looking info up on the internet that may be newer than the language < 1566245605 746372 :sleepnap!~thomas@c-68-55-111-60.hsd1.mi.comcast.net QUIT :Client Quit < 1566245953 324518 :Melvar!~melvar@dslb-188-106-184-179.188.106.pools.vodafone-ip.de QUIT :Ping timeout: 245 seconds < 1566245977 223044 :Melvar!~melvar@dslb-188-106-184-179.188.106.pools.vodafone-ip.de JOIN :#esoteric < 1566246070 81397 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: I think someone tried that once but failed < 1566246107 145891 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :a better approach would probably be to encourage people to submit OEIS programs in a standard machine code; WebAssembly comes to mind < 1566246108 228161 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :yeah, this does seem like an interesting language < 1566246131 317451 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: does WebAssembly have bigints? < 1566246152 385843 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's a machine code, so not natively in the same sense that x86 doesn't have native bigints < 1566246158 829349 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but you can run GMP or the like on it easily enough < 1566246183 926593 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: I mean as a standard library that's usually accessible or something, not as a "built-in" < 1566246207 161384 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :WebAssembly doesn't have standard libraries, you're supposed to compile your own language's standard library onto it < 1566246211 39302 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :so that you don't have to bundle a copy of the bigint multiplication routine with the code of every quickly growing sequence < 1566246237 390739 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :a typical WebAssembly program is shipped with a decent proportion of libc < 1566246238 294156 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :(though I presume you'd allow a single object file that implements multiple OEIS sequences) < 1566246257 288964 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I guess object files might make more sense than executables, in that case > 1566246324 575820 PRIVMSG #esoteric :14[[07Husk14]]4 10 02https://esolangs.org/w/index.php?diff=65577&oldid=65575 5* 03B jonas 5* (+465) 10 < 1566246346 261627 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :it could be executables, that's not the difference I care about here < 1566246356 573136 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :just that there are bunches of OEIS sequences that are closely related < 1566246368 727984 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :so it would be redundant to copy the code to each one < 1566246392 317862 :Lord_of_Life_!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1566246459 877082 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 268 seconds < 1566246567 399877 :Lord_of_Life_!~Lord@unaffiliated/lord-of-life/x-0885362 NICK :Lord_of_Life < 1566247004 525278 :ais523!~ais523@unaffiliated/ais523 QUIT :Ping timeout: 272 seconds < 1566248936 531716 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1566249027 229790 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :well, executables are self-contained, but object files don't have to be < 1566249118 610337 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I wrote a program to generate ELF executables but it seems to me object files might actually be trickier < 1566249146 250694 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hmm, maybe just differently tricky. < 1566249182 412000 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The tricky thing is that you need a bunch of information in sections for the linker to interpret. But it can handle relocations and so on for you, I suppose. < 1566249226 664695 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shachaf: do you also emit basic debug information like the code span of each function? < 1566249236 643744 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Not yet. < 1566249257 970050 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I guess that is sort of redundant because gdb can guess the function from the function symbols, without the debug info < 1566249270 970652 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :(Because the program just emits some fixed handwritten x86 code.) < 1566249297 866483 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I do emit function information, I think. But the only function is _start. < 1566249335 785855 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`` objdump -d tmp/out.a < 1566249336 564005 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :​ \ tmp/out.a: file format elf64-x86-64 \ \ \ Disassembly of section .text: \ \ 0000000000000178 <_start>: \ 178: 48 31 ed xor %rbp,%rbp \ 17b: 49 89 d2 mov %rdx,%r10 \ 17e: 48 b8 66 69 6e 61 6c movabs $0xa796c6c616e6966,%rax \ 185: 6c 79 0a \ 188: 50 push %rax \ 189: b8 01 00 00 00 mov $0x1,%eax \ 18e: bf 01 00 00 00 mov $0x1,%edi \ 193: 48 89 e6 mov < 1566249355 332213 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :nice < 1566249360 837612 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :what sort of calling convention is that? :-D < 1566249370 554429 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm used to seeing functions starting out by messing around with sp and bp < 1566249373 814371 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but zeroing bp is weird < 1566249380 705672 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm guessing it's just being used as a general-purpose register? < 1566249389 239252 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That's standard in the amd64 ABI. < 1566249399 277602 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :To mark the outermost stack frame. < 1566249403 672886 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :aha < 1566249425 593163 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :couldn't the outermost stack frame actually need it as a base pointer, though? < 1566249476 910832 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think _start normally calls another entry point almost immediately. < 1566249477 177421 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, that string says "finally" < 1566249497 285212 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I initially misread it as "fitally", I'm not as good at converting hex to ascii in my head as I'd like < 1566249538 254231 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm… do you have an opinion on caller-saved versus callee-saved registers? < 1566249557 937034 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :`perl -eprint pack"q",0xa796c6c616e6966 # let's ask a computer to do that, just to check < 1566249558 588012 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :finally < 1566249558 733212 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I don't remember. < 1566249581 451083 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I don't have a strong opinion, at least. Maybe I had one in the past. < 1566249627 470534 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think someone who knows more about register renaming and things than I do should give me an opinion. < 1566250065 126637 :asdfbot!potato@hellomouse/bin/notJeffbot JOIN :#esoteric < 1566250155 539928 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think it's reasonable for _start to be special in this way because it's not actually a function. < 1566250181 809138 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :=rasm xor rax, rax < 1566250189 367548 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :=rasm2 xor rax, rax < 1566250189 963565 :asdfbot!potato@hellomouse/bin/notJeffbot PRIVMSG #esoteric :4831c0 < 1566250194 162876 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :
ACTION happy
< 1566250225 830296 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Intel style?! < 1566250231 698218 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :yes < 1566250254 50681 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :=rasm2 -s att xor %rax, %rax < 1566250254 194001 :asdfbot!potato@hellomouse/bin/notJeffbot PRIVMSG #esoteric :Unknown argument: s < 1566250254 232136 :asdfbot!potato@hellomouse/bin/notJeffbot PRIVMSG #esoteric : < 1566250254 277392 :asdfbot!potato@hellomouse/bin/notJeffbot PRIVMSG #esoteric :Use --help for options < 1566250266 566007 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :=rasm2 -satt xor %rax, %rax < 1566250266 594303 :asdfbot!potato@hellomouse/bin/notJeffbot PRIVMSG #esoteric :Unknown arguments: s, t < 1566250266 632501 :asdfbot!potato@hellomouse/bin/notJeffbot PRIVMSG #esoteric : < 1566250266 682196 :asdfbot!potato@hellomouse/bin/notJeffbot PRIVMSG #esoteric :Use --help for options < 1566250271 546236 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :): < 1566250284 240432 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Which order should I write the operands in in my assembler? < 1566250294 980261 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :radare2 on hackeso when < 1566250302 368034 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shachaf: use NASM syntax, it's better than either intel or att < 1566250307 547027 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :^ < 1566250315 230069 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Isn't it pretty Intely? < 1566250320 587843 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :it's intel-like yes < 1566250323 116609 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :att sucks < 1566250323 564539 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :that is if this is an assembler for x86 < 1566250378 200808 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Presumably I want to target a bunch of platforms < 1566250391 837999 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :At least x86 and ARM < 1566250403 840610 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Maybe WebAssembly? < 1566250414 149436 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :shachaf: https://github.com/asmotor/asmotor contribute to this instead then < 1566250471 407767 :LBPHacker!lbphacker@trigraph.net JOIN :#esoteric < 1566250478 143467 :BWBellairs!~bwbellair@hellomouse/dev/bwbellairs JOIN :#esoteric < 1566250481 128864 :LBPHacker!lbphacker@trigraph.net PRIVMSG #esoteric :good day < 1566250483 868030 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :`welcome LBPHacker < 1566250484 132860 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :you should probably use xor %eax,%eax though, because it encodes shorter < 1566250484 974635 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :LBPHacker: Welcome to the international hub for esoteric programming language design and deployment! For more information, check out our wiki: . (For the other kind of esoterica, try #esoteric on EFnet or DALnet.) < 1566250485 882799 :LBPHacker!lbphacker@trigraph.net PRIVMSG #esoteric :blame moony for everything I do here :P < 1566250492 363659 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :): < 1566250544 221724 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Why contribute to that instead? < 1566250555 13113 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :good, multi-CPU assembler. < 1566250569 437865 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :more assemblers is just more competing standards right now < 1566250589 199944 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :see http://yasm.tortall.net/ for x86 < 1566250623 241120 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :or invent your own syntax that looks similar to the others but is incompatible in subtle ways that are hard to debug < 1566250642 121559 :sleepnap!~thomas@c-68-55-111-60.hsd1.mi.comcast.net JOIN :#esoteric < 1566250644 465218 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I primarily wanted a library rather than something with a parser anyway < 1566250657 283912 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :ah < 1566250665 275043 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :uh < 1566250668 971112 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :capstone not work? < 1566250690 928095 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I don't know? < 1566250699 12788 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :oh, right, capstone's a disassembler < 1566250718 425076 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :http://www.keystone-engine.org/ < 1566250744 469471 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :that's it's assembler counterpart < 1566250759 60170 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :for disassembling, you can try Agner's disassembler < 1566250779 694640 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :or http://www.capstone-engine.org/ as i mentioned < 1566250887 805929 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :There's only one application I previously wanted a general disassembler library for, and it was kind of ridiculous. < 1566250932 186314 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :did it involve malware research or kernel debugging? < 1566250964 794658 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :No, the goal was to make a variant of strace that traces I/O to memory mapped files precisely. < 1566250976 888776 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ouch < 1566250980 260148 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :yes, that is ridiculous < 1566251016 993661 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :In order to trace exactly which bytes were read from or written to, you need to disassemble the instruction. < 1566251081 464324 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think there are some debuggers that have this feature. < 1566251081 933702 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :that, or mprotect all of the mapped pages to 0 permissions after every access, and catch the segfault and see what the siginfo says < 1566251117 318889 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That's the approach I'm proposing. < 1566251117 881021 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :wait, can't intel's built-in debug faults already tell what's read and written, and doesn't the kernel expose that in siginfo? < 1566251134 885450 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Certainly not stepping through every instruction, that seems way too slow. < 1566251150 479874 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But when you get the SEGV you need to figure out exactly which octets were read or written. < 1566251152 276019 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :
ACTION has been reading the x86_64 ABI
< 1566251162 136174 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it gives advice on how to implement exabyte-size functions < 1566251170 922766 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I wonder what circumstances would require you to write one of those < 1566251184 410201 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :I can not imagine a sane one < 1566251213 925867 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :hmm < 1566251222 975136 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :why do me and ais523 have the same name color in weechat < 1566251242 551527 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :we're alphabetical miles apart < 1566251255 429067 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I don't know how all that x86 stuff works < 1566251268 62272 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :b_jonas: it works via a generator that runs on hot garbage < 1566251286 973507 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: a compiler may have to, when it's forced to compile firefox < 1566251307 158611 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :i mean < 1566251313 23295 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :maybe you unroll a massive loop? < 1566251352 57442 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :LBPHacker: help i need ideas for why one would use a exabyte sized functions < 1566251378 146445 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I still have trouble imagining exabytes of data, although there are probably some companies who store that much nowadays < 1566251378 863954 :LBPHacker!lbphacker@trigraph.net PRIVMSG #esoteric :hwhat < 1566251381 697152 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :though I think they don't have functions larger than gigabyte sized < 1566251382 198449 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but exabytes of /code/? < 1566251385 222556 :LBPHacker!lbphacker@trigraph.net PRIVMSG #esoteric :^ < 1566251406 666868 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I guess when you're writing an ABI you need to take all eventualities into account < 1566251448 851250 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: right, so that twenty years later, when the required hardware is available, different groups of people don't start inventing incompatible exensions < 1566251459 201579 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: I doubt there's any company that stores an exabyte of data on one machine. < 1566251483 509687 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :not even in memory? < 1566251489 547381 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :my guess is that nobody does but I'm not sure < 1566251490 363325 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :I wonder what happens if you give GCC infinite (to the max x86-64 allows) RAM and have it compile a exabyte sized function < 1566251503 233595 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :ais523: the most we can store per machine right now is about 1PB i think < 1566251530 817591 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :so 1024 machines per exabyte < 1566251538 866393 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there are definitely use cases in which you want as much in-memory storage as possible in one machine and don't care if it's lost to a crash < 1566251559 934806 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :moony: even a petabyte is a lot, yeah < 1566251582 760541 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :you'd need 32 hard disks, each one 32 terabytes size, or something < 1566251592 526037 :LBPHacker!lbphacker@trigraph.net PRIVMSG #esoteric :moony: I'm missing a lot of context here but iirc x86-64 supports an address space of 2**52 < 1566251592 627871 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :ais523: the most RAM per machine right now is 8TB, assuming a AMD EPYC based server. < 1566251599 104479 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: such as video games, sure < 1566251608 266932 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :moony: so not even in the petabyte range < 1566251613 729742 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :or trying to break cryptography stuff by building huge tables < 1566251622 848516 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :and this is asof just a few days ago btw < 1566251624 240466 :LBPHacker!lbphacker@trigraph.net PRIVMSG #esoteric :or are we talking possibly out of memory < 1566251636 317707 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :before the latest EPYC units were released, it was a max of 4TB per machine < 1566251655 760730 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :LBPHacker: possibly out of memory i bet < 1566251655 837733 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :or rather < 1566251660 711673 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :memory paging/swapping/whatever < 1566251672 459565 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :LBPHacker: I disagree, https://esolangs.org/logs/2019-08-05.html#luc < 1566251684 711378 :LBPHacker!lbphacker@trigraph.net PRIVMSG #esoteric :oh 5-level < 1566251687 459271 :LBPHacker!lbphacker@trigraph.net PRIVMSG #esoteric :fun < 1566251699 725089 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :LBPHacker: it's the 5-level one that would support 52 bits I think < 1566251712 590126 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :the current cpus support only up to 48 bits < 1566251739 563135 :LBPHacker!lbphacker@trigraph.net PRIVMSG #esoteric :well I mean I remember 9+9+9+9+12, which is the 4-level < 1566251741 600536 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :moony: what's the most fast solid state storage you can have in a machine? < 1566251747 646571 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :uh < 1566251750 68975 :LBPHacker!lbphacker@trigraph.net PRIVMSG #esoteric :how many address pins your cpu has is another matter :P < 1566251758 96041 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :I dunno, i know some servers with 48+ NVME slots < 1566251760 44161 :LBPHacker!lbphacker@trigraph.net PRIVMSG #esoteric :oh < 1566251762 685917 :LBPHacker!lbphacker@trigraph.net PRIVMSG #esoteric :ok reee I'm dumb < 1566251766 820010 :LBPHacker!lbphacker@trigraph.net PRIVMSG #esoteric :36+12 < 1566251771 514837 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :even if your CPU is short on address pins you could always use… bank switching! < 1566251772 249867 :LBPHacker!lbphacker@trigraph.net PRIVMSG #esoteric :see this is why I don't do addition < 1566251796 914863 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although it tends not to play very nicely with the concept of an operating system < 1566251808 458269 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :b_jonas: with a modern EPYC system, I think it'd max out at 128 NVMe devices, assuming you somehow utilized all 128 PCIe lanes from both CPUs < 1566251838 131729 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :LBPHacker: I gave up on arithmetic years ago, when I debugged a segfault for hours, then found that I allocated 8092 bytes instead of 8192 < 1566251840 145742 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :(Yes, EPYC servers are currently the most capable. Perfect.) < 1566251854 497534 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :these days I'd let the computer figure out the size from a multiplication or shift < 1566251861 319962 :LBPHacker!lbphacker@trigraph.net PRIVMSG #esoteric :lol. yes, that is why I don't do decimal either < 1566251878 233749 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :uh < 1566251880 410581 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :hmm < 1566251887 90493 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :moony: and how large can those NBMe devices be? < 1566251887 731803 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :how many SATA devices can you have per PCIe lane < 1566251895 569768 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Or write 0x2000 < 1566251914 427805 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shachaf: yes, that too, though sometimes I mess that up too < 1566251939 788124 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :moony: also how many ways is the largest possible NUMA in a machine? < 1566251969 769405 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :uh < 1566251989 585668 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :I dunno NUMA < 1566252044 9311 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :haha, the PLT uses one format for the first 102261125 entries and changes to a different format from the 102261126th onwards < 1566252054 911339 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :computer hardware is getting ridiculously powerful. good thing I have my programmable calculator, with 2 kilobytes of RAM, battery-backed to make it persistent, in the shelf < 1566252055 394993 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :I think EPYC zen 2 server processors are one NUMA P each\ < 1566252060 23917 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :s/shelf/drawer/ < 1566252067 229664 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I wonder how many programs a) care about the PLT format at all and b) are unaware of that detail < 1566252081 619292 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :b_jonas: 128 cores per server \o/ < 1566252131 44079 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :128 cores, with slots for 4 accelerator cards < 1566252136 808935 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :or was it 8 < 1566252148 171103 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(the reason is that there's some shared code between the entries that they normally reach via a jump, but you can't write the jump instruction when you're too far from the start of the PLT) < 1566252170 342126 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :moony: nice. have you ever written a program for those that spawns 128 parallel processes to speed up something, but some library you call in them tries to be automatically smart and spawns 128 parallel threads in each of them? < 1566252183 209085 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :pffft < 1566252201 790035 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :If I generate an amd64 program, should I just not use a PLT? < 1566252210 110676 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :that's happened to me on 12 cores only, I haven't seen a 128 core machine < 1566252217 671839 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :2-way NUMA too < 1566252222 491543 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :b_jonas: 128 core machines are on the market as of a few days ago < 1566252226 854966 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: I'm sceptical about the value of the PLT and GOT < 1566252226 915739 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :they're 2-way as well < 1566252232 674183 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Also, should I take Microsoft's approach and say "x64" instead of "x86-64" or "amd64"? It's shorter. < 1566252239 355138 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :go ahead < 1566252247 551150 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shachaf: no < 1566252248 612748 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: Hmm, what's the alternative to the GOT in ELF files? < 1566252253 860472 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :x64 probably refers to an unrelated CPU < 1566252258 22956 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :b_jonas: they're also impressively cheap, 7k for the highest end 64-core CPU from AMD < 1566252266 771282 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :and it absolutely kills in terms of performance < 1566252283 449968 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :nice < 1566252291 83255 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :somethingsomething50kfor56coresfromintel < 1566252295 279733 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: well, the GOT basically lets you find addresses that aren't compile-time constants, but doing arithmetic on %rip can also do that if you know that the entire program has moved the same amount < 1566252304 869957 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I'd like a powerful computer, but not that powerful < 1566252311 675648 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so it'd only be useful when connecting between two parts of the program that are ASLRed by different amounts < 1566252330 192844 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :b_jonas: AMD has 16-core processors for desktop for about $800 i think, coming to market real soon < 1566252346 151633 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: Right, but isn't every library loaded at a random address? < 1566252399 502640 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: yes, but there isn't a whole lot of actual communication done between libraries through, e.g., shared global constants < 1566252446 150680 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But what about calls to library functions? < 1566252451 262777 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so I'm not sure that I see any particular difference between absolute and position-independent code; you need the dynamic linker to update function calls in one library to point to the other anyway < 1566252478 765561 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the purpose of the PLT is pretty much just so that you can avoid editing the .text segment, which forces you to use a private rather than shared map < 1566252489 838650 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Right, so the PLT seems kind of pointless. < 1566252504 234195 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But isn't the GOT the alternative that doesn't edit .text? < 1566252519 970483 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the GOT and PLT are very similar < 1566252549 495998 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the difference is that GOT is general-purpose and the PLT is just wrappers for function calls < 1566252563 93968 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(this lets you give a location in the PLT when you need to give someone a function pointer for a callback) < 1566252585 995213 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :LBPHacker: exascale R316 when < 1566252593 558311 :LBPHacker!lbphacker@trigraph.net PRIVMSG #esoteric :uwot < 1566252596 333096 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that said, position-independent code doesn't move while it's running, so if you need to give someone a function pointer, you could probably just lea it yourself and pass them the resulting absolute address < 1566252601 859701 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :why do we have to have these interesting conversations during the night when I have to get up early the next day? the sleep cycle of this channel is messe dup < 1566252611 25602 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :hi i'm american < 1566252614 477368 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Maybe I'm saying GOT when I mean something else. < 1566252615 102317 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :it's just the afternoon here < 1566252628 802047 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :GOT sounds an awful lot like GDT < 1566252639 45626 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What's the way you're proposing to call a dynamically linked function? < 1566252642 261556 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :I know GDT, but not GOT.. < 1566252673 20966 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :moony: you are, yes < 1566252731 814532 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think you should have something like "movq some_offset(%rip), %rax; callq %rax", where that offset is an offset into a segment the dynamic linker populates with the correct address at load time. < 1566252767 809009 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Or maybe that's not what I think? < 1566252869 761943 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: my suggestion is callq 0(%rip) in the executable, the dynamic linker edits the 0 to the actual distance when the executable is loaded < 1566252894 476679 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that works well for executable → library calls as long as they're both in the first 31 bits (they typically will be) < 1566252908 241740 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But that requires editing .text such that it can't be shared, right? < 1566252912 413481 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it doesn't work as well for library → library calls, though, because you'd ideally want to be able to store the libraries in a shared mapping < 1566252922 587430 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :right, that prevents a shared .text < 1566252923 723435 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Maybe you're saying that's irrelevant. < 1566252932 6455 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I consider it insufficiently relevant < 1566252948 456601 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :One thing I like being able to do is load a new copy of a .so at runtime repeatedly. < 1566252964 20082 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I guess that's still possible with that approach. < 1566252977 372239 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But it might require a page to be W|X. < 1566252981 126084 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but if it's a problem, the next step would be to have a separate section that groups together jumps to functions, do calls by calling that section, and have the dynamic linker edit the jump targets < 1566253003 47555 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I was going to say that sounds like the PLT, but I guess the PLT has an extra level of indirection. < 1566253020 329731 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :indeed < 1566253027 84092 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I don't understand why it has that extra level < 1566253043 746372 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think it's to allow lazy loading. < 1566253065 191332 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think lazy loading is probably a bad idea, though. < 1566253103 244348 :AnotherTest!~turingcom@d51a4b8e1.access.telenet.be QUIT :Ping timeout: 245 seconds < 1566253103 661328 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the remaning hard case is when one library (or the executable) refers to a global variable in another library (or the executable) < 1566253115 733735 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :my preferred solution to this would be simply to ban it :-D < 1566253127 174332 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hmm, I use this in the aforementioned use case. < 1566253167 38528 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Specifically my program is made of two parts, a loader binary and an application .so. < 1566253169 563482 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in cases like this, getter/setter methods would normally be a better API < 1566253198 303310 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The .so refers to some global variables defined in the loader to share state across reloads. < 1566253208 387269 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I suppose the loader could just pass it a pointer. < 1566253264 322723 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ooh, I think I know why the PLT might be useful: it's to avoid invalidating function pointers into a library after it's reloaded < 1566253294 537872 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think those are invalidated anyway. < 1566253307 393222 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I guess they have to be < 1566253308 882242 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Well, I'm loading the library with dlopen. < 1566253314 11813 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So the PLT is irrelevant. < 1566253325 430581 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :(In the loader->library direction.) < 1566253635 950840 :arseniiv!~arseniiv@46.191.137.50 QUIT :Ping timeout: 248 seconds < 1566253645 748475 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :anyway, my current hobby is being annoyed at compiler optimisers < 1566253657 181218 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :One annoying thing about structuring the program this way is that the .so can't use any global variables (that survive across reloads). < 1566253674 657557 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Most of the global variables I'm importing from the loader really belong in the library anyway. < 1566253701 251654 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :unsigned short f(unsigned long long *p) { unsigned long long rp = *p; if ((rp & 0xFF00000000000000LLU) != 0x8000000000000000LLU) return 0; return (unsigned short)((rp ^ 0x8000000000000000LLU) >> 48); } < 1566253713 46276 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :^ that is the test function that I've been working on optimising < 1566253733 311241 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I feel like, if you want to make your programs fast, optimizing compilers are rarely the right place to look. < 1566253762 59211 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this compiles to 45 bytes with gcc -Os, 34 bytes with clang -Os < 1566253788 910419 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I got it down to 13 bytes of hand-written asm < 1566253804 656794 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh man. That's a lot of bytes. < 1566253807 918976 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the reason I'm annoyed is that I want to be able to write clear code and rely on compiler optimisations < 1566253852 146959 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I had a go at trying to generate good asm via repeatedly hand-optimising the C file < 1566253878 178823 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that got it down to 24 bytes on clang and 17 on gcc, but at the cost of requiring -fno-strict-aliasing < 1566253911 985678 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :
ACTION has an idea
< 1566253921 801122 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :" haha, the PLT uses one format for the first 102261125 entries and changes to a different format from the 102261126th onwards" => I wonder if I should addquote that < 1566253968 266827 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :helps on clang, at least < 1566253985 152320 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you can hit an LLVM optimiser idiom and get back to strictly conforming C, which is nice < 1566253986 755811 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :getter/setter methods? why not a function that returns the address of the variable instead? < 1566254011 2476 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I guess that works in most cases < 1566254024 596038 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I like getter/setter because it abstracts away the way in which the variable is stored internally < 1566254049 108136 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but many of the cases you'd need that, e.g. if you need to move the variable to thread-local-storage, still let you take references to it < 1566254060 358791 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`` printf "%x" 102261125 < 1566254061 34602 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :6186185 < 1566254099 447124 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: isn't the extra indirection so that you can take a function pointer to a function in another library, and equality-compare it in C to the same function pointer taken from a third library, and make them return equal? < 1566254106 332373 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :the extra indirection in the PLT that is < 1566254126 773918 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, could be < 1566254127 158162 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :How does the PLT let you do that? < 1566254141 367729 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: you have made sure that you aren't using a too old compiler or an MS compiler, right? < 1566254166 657328 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: ^ this is a really good example of my belief that immutable things should be treated as indistinguishable from values, with any references managed behind the scenes < 1566254212 279048 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :reference-== on immutable things is not a useful operation (except possibly as an optimisation hint) and if you accidentally expose it in your language semantics, a lot of contortions are needed to avoid breaking programs that rely on it < 1566254222 59957 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: for a thread-local variable, you call the function again each time you're not sure you're in the same thread. that's how errno works. < 1566254238 525305 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in retrospect, errno was a mistake < 1566254243 187331 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but it took a while for that to become apparent < 1566254252 834809 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :errno is a big mistake < 1566254259 933712 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :``` gcc -E - <<<$'#include\nerrno' | tail < 1566254260 690864 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :​# 25 "/usr/include/x86_64-linux-gnu/bits/errno.h" 2 3 4 \ # 50 "/usr/include/x86_64-linux-gnu/bits/errno.h" 3 4 \ \ # 50 "/usr/include/x86_64-linux-gnu/bits/errno.h" 3 4 \ extern int *__errno_location (void) __attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__const__)); \ # 36 "/usr/include/errno.h" 2 3 4 \ # 58 "/usr/include/errno.h" 3 4 \ \ # 2 "" 2 \ (*__errno_location ()) < 1566254280 391369 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that "leaf" in the header file is curious < 1566254284 215032 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :moony: yes, and C99 at least partly gets rid of it by allowing such fast functions as sqrt to not necessarily set it < 1566254292 73992 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :when would a function need to know that it's /calling/ a leaf functiion < 1566254292 316834 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :and floor < 1566254327 937339 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm, apparently it means "this function will never call a callback function, nor longjmp" < 1566254349 93244 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which does seem potentially useful as an optimisation hint < 1566254523 676133 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ok, not floor, sorry < 1566254527 16115 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :but sqrt < 1566254540 278706 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So when foo is a dynamiclly linked function and it's used as a function pointer, what does that pointer point to? < 1566254595 72658 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shachaf: I don't know. it might not even work the way I explained, maybe it points to different places depending on which library you're naming the function pointer. I never tested it. < 1566254596 466099 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Apparently it's not the PLT entry. < 1566254657 766590 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I made a test program but now I gotta figure out what it's actually doing. < 1566254708 873887 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :A PLT entry isn't even generated when you get a function pointer. Only when you call the function directly. < 1566254730 319693 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Which is pretty bizarre because "calling the function directly" nominally happens through a function pointer, in C. < 1566254794 432747 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shachaf: does it really? I thought the function (reference) just decays to a function pointer when used as such, just like how an array decays to a pointer < 1566254807 158354 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :and when you call it, that doesn't happen < 1566254841 550594 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That's what the C standard says. < 1566254864 744882 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :not that that's an observable reference, and in any case, this is something that can and will be optimized < 1566254869 607346 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :When I get back to the computer I'll test it more directly. < 1566254900 696874 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ok < 1566254939 571394 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :but still, I think compilers will likely optimize it, because direct function calls are pretty common < 1566254950 894436 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hmm, maybe it is observable, for the reason you said (making function pointers equal across libraries). < 1566254979 104387 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Since each library has its own PLT. < 1566255037 321574 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shachaf: does C even guarantee the thing about making function pointers equal? < 1566255132 201809 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I'm not sure you are even allowed to compare two function pointers without invoking undefined behavior unless one of them is a null pointer < 1566255155 978657 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ah no, you probably can < 1566255177 413910 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :for equal comparisons, you don't get UB < 1566255201 291715 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :but I don't know if two function pointers to the same pointer are guaranteed to be equal, even within a compilation unit < 1566255205 973064 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you can compare for equality, but not for < and > < 1566255224 773636 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: right, but what result do you get? < 1566255242 920904 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :does f == f have to return true if f is a function? < 1566255243 478340 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :who knows, this is C we're talking about :-D < 1566255246 644842 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :yeah < 1566255259 201055 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, with optimizations it turns into a PLT call in gcc. < 1566255303 672438 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I think you can do equal comparisons on function pointers only because some apis treat null pointers in a special way < 1566255320 841865 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shachaf: nice < 1566255327 190397 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu QUIT :Quit: leaving < 1566255365 564216 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, the function pointer comes from the GOT. < 1566255657 17305 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Ugh, dynamic linking is so complicated. < 1566255728 221608 :Phantom_Hoover!~phantomho@unaffiliated/phantom-hoover QUIT :Ping timeout: 245 seconds < 1566256180 610225 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I'm kind of annoyed that when you lookify up something about dynamic linking or ELF files or whatever most of the search results are about random programs that print error messages involving those things rather than anything about how those things actually work. < 1566256578 661054 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :yea... < 1566256630 875094 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :At least writing an emitter is probably way better than writing a loader (which needs to handle all the old things no one uses anymore). < 1566256635 781888 :xkapastel!uid17782@gateway/web/irccloud.com/x-iysxgalxowpkpzed QUIT :Quit: Connection closed for inactivity < 1566256753 36942 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I'm confused by the last paragraph in https://www.airs.com/blog/archives/549 < 1566256761 518021 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :"It is possible to design a statically linked PIE, in which the program relocates itself at startup time." < 1566256771 13122 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Why does the program need to relocate itself? Doesn't the kernel do that? < 1566257718 724216 :sleepnap!~thomas@c-68-55-111-60.hsd1.mi.comcast.net QUIT :Quit: Leaving. < 1566257816 476969 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :I'd have to look to check, but I think this is "relocation" in the sense of "processing ELF symbol relocations", not in the sense of "mapping into memory" < 1566257854 138582 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :Because a static PIE binary is more-or-less a shared object that happens to have an entry point and no external dependencies. < 1566257878 202088 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Why would ELF symbol relocations be relevant for a statically linked executable? < 1566257974 66639 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :The executable's GOT and PLT needs populated. < 1566258015 347946 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What, are you from Pittsburgh now? < 1566258029 130009 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I don't see why a statically linked executable would have a GOT or PLT. < 1566258066 945912 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :Because you're implemented a static PIE binary by emitting, essentially, a shared object. That happens to have an entry point. < 1566258103 760231 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, but that's just a technicality due to the kernel only randomizing ET_DYN files. < 1566258118 996582 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :There's no need to emit a DYNAMIC segment. < 1566258238 312133 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :Trying to remember exactly how musl does static PIE binary support... < 1566258300 455569 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric : movzwl -0x2(%rdi,%rax,1),%ecx \ mov %ecx,%edx \ xor $0x8060,%edx \ movzwl %dx,%edx < 1566258302 54491 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh come on < 1566258312 875952 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that last movzwl is just some really obvious dead code < 1566258337 635102 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the top 16 bits of %edx didn't stop being 0 just because you XORed the bottom 16 < 1566258438 56320 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I need to stop taking it personally when compilers generate ridiculous code, but still, that one really hurts < 1566258497 912603 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :meanwhile, clang optimised (x ^ 0x807F) >= 0x00A0 into (x ^ 0x8060) >= 0x00A0 which doesn't really change anything but is amusing < 1566258569 1152 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :Looks like musl's implementation is that it links in the dynamic linker to static PIE binaries. < 1566258618 700461 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :Or, rather, a portion of it. < 1566258630 422946 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Why? < 1566258656 627656 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :https://git.musl-libc.org/cgit/musl/tree/ldso/dlstart.c It's this portion. < 1566258684 317742 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :Just the startup code for the dynamic linker, not the full thing. < 1566258745 508472 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :Oh, it's doing very very little. < 1566258754 102308 :pikhq!~pikhq@97-118-196-215.hlrn.qwest.net PRIVMSG #esoteric :Not even really processing relocations. < 1566258902 486358 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :later on there's also the beautiful "xor %r8d,%r8d \ movzbl %r8b,%eax" (with, AFAICT %r8 dying immediately afterwards) < 1566258930 384966 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :*with, AFAICT, < 1566259179 398796 :tromp_!~tromp@ip-213-127-58-74.ip.prioritytelecom.net QUIT :Remote host closed the connection