00:00:30 <zzo38> ais523: Did you write more about the card game you were designing?
00:01:26 <ais523> I'm working on so many projects that any specific random old project from a while ago is unlikely to have received updates, even if I've had no reason to abandon it
00:01:28 <zzo38> I made other changes as well, such as, I added a solitaire mode, and I removed the fifty-point bonus.
00:02:04 <shachaf> Is making statically linked binaries a hopeless endeavor?
00:02:56 <ais523> I don't think most build tools are very good at it nowadays
00:03:18 <ais523> the ideal would be some sort of LTO against libc, which would be fun to see
00:03:40 <shachaf> I mean in terms of the capabilities of the final binary, not how it's produced.
00:04:47 <ais523> "gcc -static helloworld.c" produced a binary for me that file claims is statically linked
00:05:10 <ais523> however, it appears to have a PLT anyway, which is suspicious
00:05:42 <shachaf> Yes. On Linux it's sort of possible. But once you want to do things like OpenGL it's not possible again.
00:06:18 <ais523> …also I'm not sure if I trust my disassembler, it disassembles "66 90" as "xchg %ax, %ax", which is not correct ("xchg %ax, %ax" would clear the upper 32 bits of %rax, it should be disassembled as "nopw" or "word ptr nop")
00:08:43 <shachaf> `` echo 'int main() { return 0; }' | gcc -x c - -o /tmp/true; readelf -a /tmp/true > tmp/out; objdump -d /tmp/true >> tmp/out; url tmp/out
00:08:46 <HackEso> https://hack.esolangs.org/tmp/out
00:08:50 <shachaf> `` echo 'int main() { return 0; }' | gcc -static -x c - -o /tmp/true; readelf -a /tmp/true > tmp/out; objdump -d /tmp/true >> tmp/out; url tmp/out
00:08:52 <HackEso> readelf: Warning: [ 3]: Link field (0) should index a symtab section. \ https://hack.esolangs.org/tmp/out
00:09:25 <shachaf> It's certainly possible to make statically linked binaries that only use the kernel ABI.
00:10:35 <ais523> my statically linked hello world has a relocation section, which is interesting: it hasn't been fully linked
00:10:43 <ais523> maybe that's related to ASLR or something like that
00:10:50 <shachaf> I think glibc is quite hostile to static linking.
00:11:32 <ais523> IIRC there's a separate compile of it which is more static-link-friendly
00:11:41 <shachaf> There's no reason for ASLR to cause this because all the statically linked jumps are relative.
00:12:52 <ais523> apparently not, there are some absolute calls in the compiled hello world executable
00:12:55 <ais523> those are what are going via the PLT
00:13:16 <shachaf> Right, but the PLT is what's making them absolute in the first place.
00:13:53 <shachaf> I've seen 66 90 diassembled as xchg %ax,%ax before. I wonder why.
00:14:40 <shachaf> `` echo $'.globl _start\n_start:\nxchg %eax,%eax\nint3' > /tmp/test.s; as -o /tmp/test.o /tmp/test.s; objdump -d /tmp/test.o
00:14:41 <HackEso> \ /tmp/test.o: file format elf64-x86-64 \ \ \ Disassembly of section .text: \ \ 0000000000000000 <_start>: \ 0:87 c0 xchg %eax,%eax \ 2:cc int3
00:14:52 <shachaf> `` echo $'.globl _start\n_start:\nxchg %ax,%ax\nint3' > /tmp/test.s; as -o /tmp/test.o /tmp/test.s; objdump -d /tmp/test.o
00:14:52 <HackEso> \ /tmp/test.o: file format elf64-x86-64 \ \ \ Disassembly of section .text: \ \ 0000000000000000 <_start>: \ 0:66 90 xchg %ax,%ax \ 2:cc int3
00:14:59 <shachaf> `` echo $'.globl _start\n_start:\nxchg %rax,%rax\nint3' > /tmp/test.s; as -o /tmp/test.o /tmp/test.s; objdump -d /tmp/test.o
00:15:00 <HackEso> \ /tmp/test.o: file format elf64-x86-64 \ \ \ Disassembly of section .text: \ \ 0000000000000000 <_start>: \ 0:90 nop \ 1:cc int3
00:15:26 <ais523> shachaf: because if you treat the instruction encoding orthogonally, 90 actually means xchg %ax, %ax on 8086; with 32-bit processors it was repurposed to mean nop (and xchg %ax, %ax is actually a nop on those)
00:16:01 <shachaf> But you'd expect it to clear the upper 32 bits on amd64, like you said.
00:16:14 <ais523> right, so on amd64, you need to special-case 90 to have no relationship to ax
00:16:31 <ais523> and it's probably easy to forget to do that when it doesn't matter on a 32-bit processor
00:21:37 <shachaf> "XCHG (E)AX, (E)AX (encoded instruction byte is 90H) is an alias for NOP regardless of data size prefixes, including REX.W."
00:22:26 <shachaf> So I think the diassembly is correct? Though it would be nicer to call it a 2-byte nop.
00:24:11 <shachaf> objdump should have an option to show the instruction in octal.
00:24:15 <ais523> huh, "xchg %ax, %ax" assembles into 66 90
00:24:19 <ais523> (I ran it the other way)
00:25:09 <ais523> interestingly, "xchg %rax, %rax" assembles into just 90
00:25:17 <shachaf> I guess REX.W followed 90 would also be a 2-byte nop.
00:25:24 <ais523> I guess that does the same thing :-D
00:25:41 <ais523> REX is a bit of a complex prefix, it /also/ overrides which registers you're using
00:25:54 <ais523> so you'd need to pick a version of REX that left the registers the same
00:26:25 <shachaf> `` echo $'.globl _start\n_start:\n.byte 0x48; .byte 0x90\nint3' > /tmp/test.s; as -o /tmp/test.o /tmp/test.s; objdump -d /tmp/test.o
00:26:26 <HackEso> \ /tmp/test.o: file format elf64-x86-64 \ \ \ Disassembly of section .text: \ \ 0000000000000000 <_start>: \ 0:48 90 rex.W nop \ 2:cc int3
00:27:09 <shachaf> (I was hand-encoding some x86-64 code today so I happened to have it handy.)
00:27:11 <ais523> I just used 48 in my own tests
00:27:25 <ais523> and yes, it disassembles as REX.W
00:28:30 <ais523> hmm, I wonder what the other REXes disassemble as
00:28:33 <shachaf> I wonder whether I should go the Microsoft route and call that architecture "x64".
00:28:51 <ais523> OK, so the odd-numbered REXes change the second operand to r8
00:30:11 <ais523> only REX.B and REX.WB weren't noted at all by the disassembler, for the others it mentioned the prefix explicitly
00:31:40 <shachaf> `` echo $'.globl _start\n_start:\n.byte 0101; .byte 0220' > /tmp/test.s; as -o /tmp/test.o /tmp/test.s; objdump -d /tmp/test.o
00:31:40 <HackEso> \ /tmp/test.o: file format elf64-x86-64 \ \ \ Disassembly of section .text: \ \ 0000000000000000 <_start>: \ 0:41 90 xchg %eax,%r8d
00:31:54 <shachaf> `` echo $'.globl _start\n_start:\n.byte 0111; .byte 0220' > /tmp/test.s; as -o /tmp/test.o /tmp/test.s; objdump -d /tmp/test.o
00:31:55 <HackEso> \ /tmp/test.o: file format elf64-x86-64 \ \ \ Disassembly of section .text: \ \ 0000000000000000 <_start>: \ 0:49 90 xchg %rax,%r8
00:32:11 <ais523> I'm reading the spec now
00:32:14 <shachaf> `` echo $'.globl _start\n_start:\n.byte 0111; .byte 0221' > /tmp/test.s; as -o /tmp/test.o /tmp/test.s; objdump -d /tmp/test.o
00:32:15 <HackEso> \ /tmp/test.o: file format elf64-x86-64 \ \ \ Disassembly of section .text: \ \ 0000000000000000 <_start>: \ 0:49 91 xchg %rax,%r9
00:32:34 <shachaf> Does HackEgo have a nicer way to ask these questions than that?
00:32:42 <shachaf> LLVM has some tools for it, I think.
00:35:21 <ais523> hmm, xchg seems to use a really weird formatting for its arguments
00:36:19 <ais523> normally you'd use rex.r to change the first register to the r9..r15 set, but rex.rw xchg %ax, %r9 isn't interpreted as xchg %r9, %r9 like you'd expect
00:36:52 <ais523> I'm guessing it's because the one-byte encoding of xchg hardcodes the first register rather than using modrm
00:37:05 <shachaf> This form of xchg just always uses ax, I think.
00:37:20 <ais523> so xchg %r8, %r8 has to be encoded as 4d 87 c0
00:37:34 <shachaf> You can use 0x87 to exchange arbitrary registers.
00:38:00 <shachaf> I think that's pretty reasonable? REX only affects registers whose name is explicitly encoded.
00:38:33 <ais523> yep; 87 = xchg (word/dword/qword); c0 = registers only, ax or r8, ax or r8; then the rex prefix disambiguates the registers and operation size
00:39:10 <shachaf> By the way this is way better in base 8.
00:39:36 <ais523> meanwhile, 90 has a hardcoded first argument (ax), and non-hardcoded second argument (ax or r8), which seems a little inconsistent
00:39:58 <shachaf> The mod r/m byte for two-register exchange is encoded as 03xy where x and y are the names of the two registers.
00:40:00 <Sgeo__> I'm still trying to wrap my mind around how calls into the OS work on Windows. On Linux and DOS there are certain interrupts. On Windows... you assemble an EXE to say that it links to kernel32.dll, and have the assembly code ... jump into some location that the loader will point to the userland code in kernel32 that will do the jump?
00:40:25 <shachaf> Sgeo__: Yes, the standard ABI is based on dynamic linking.
00:40:58 <shachaf> It's kind of like the VDSO in Linux.
00:41:06 -!- Phantom_Hoover has quit (Ping timeout: 248 seconds).
00:41:08 <Sgeo__> I have no idea what VDSO is
00:41:33 <ais523> the vDSO is a library that's provided by the kernel and that ld-linux automatically links against
00:41:34 <shachaf> It's a small ELF file that's loaded into your address space at startup in Linux which you can use to make system calls.
00:41:58 <shachaf> Some system calls can be implemented without switching to kernel mode so the VDSO implements them directly, or something.
00:42:23 <ais523> it contains a general system call instruction (mostly not needed nowadays now that syscall is a CPU instruction), but also implementations of functions like gettimeofday that communicate with the kernel using shared memory rather than system calls
00:43:02 <ais523> cpuid is a good example, the kernel basically just places the number of the CPU the thread is running on into a particular memory location, and the vDSO implementation reads it
00:43:23 <ais523> you need the kernel to make this sort of cpuid caching work because it's the kernel that knows when it's moved a thread to a different CPU
00:44:01 <Sgeo__> I bought the Windows Internals book, but I think it's a bit too detailed for me.
00:44:10 <shachaf> In Windows the only stable ABI is like this.
00:45:02 <ais523> a good way to put it is that on Windows, the only documented kernel ABI is to go via some libraries (lower-level than libc) that are provided with the operating system
00:45:22 <ais523> presumably they make calls into the kernel themselves via some means, but the way they do that, and the interfaces they use, are both intended to be opaque to users
00:45:42 <shachaf> It's also the only stable way. They change the library-kernel ABI all the time.
00:46:20 <ais523> well, that's the reason you make it opaque, isn't it?
00:46:24 <Sgeo__> What do calls into DLLs look like at the assembly level (assuming the assembler itself doesn't hide details)?
00:46:26 <ais523> so that you can change it without things breaking
00:47:16 <shachaf> Sgeo__: Presumably they have references to functions exported by DLLs which are resolved by the dynamic loader.
00:47:20 <ais523> on Windows, IIRC the way it works is that you write a jump instruction aimed at 0, together with a note (elsewhere in the executable) specifying what it's meant to go to
00:47:31 <ais523> and the dynamic linker will update it to the real address
00:47:47 <shachaf> Sgeo__: https://x0r19x91.github.io/2018/tiny-pe
00:48:03 <Sgeo__> shachaf, ais523, thank you
00:49:09 <shachaf> I don't know how these things work on Windows exactly but I hear it's a bit different from the standard Linux thing.
00:49:30 <shachaf> I'll probably write a program to emit PE binaries at one point.
00:50:08 <ais523> actually, shared library linking is pretty similar between Windows and Linux at the asm level, but it's pretty different at the .o/.c level
00:50:20 <shachaf> kmc: should i put a fancy 512-byte dos demo in the MZ stub in windows binaries i generate
00:50:30 <shachaf> Well, even Linux has multiple methods.
00:50:45 <ais523> like, the encoding in the executable is pretty similar, but the toolchain to get there is radically different
00:51:25 <ais523> the way things work toolchain-wise in Windows is more explicit than on Linux, it's actually a bit easier for tools like aimake to handle because there are clear dependencies between all the steps
00:51:42 <ais523> (whereas on Linux, a .so acts as its own import library, which makes, e.g., circular dependencies between .so files hard to intentionally construct)
00:51:42 <shachaf> Some Linux libraries use relocation rather than position-independent code (I think this is pretty rare nowadays).
00:52:02 <ais523> that only works with 32-bit code IIRC
00:52:02 <shachaf> I think for a long time (maybe still?) Windows DLL addresses were randomized at boot time rather than load time.
00:52:35 <shachaf> ais523: I don't understand how Windows import libraries work or why you'd want them.
00:52:51 <shachaf> Can you generate them from DLLs?
00:53:03 <ais523> you can generate them from more or less anything
00:53:21 <ais523> all you need is a list of functions to import, pretty much (maybe also some information about their calling convention, I forget if you need that)
00:53:24 <shachaf> Why would I use them rather than just using DLLs directly?
00:53:25 <Sgeo__> I tried ton generate one for a dll, failed because the tool couldn't do it for the ... calling convention in question iirc
00:53:27 <ais523> that can either be explicit or extracted from some file
00:53:48 <ais523> the import library is what you /link against/ to be able to use the DLL
00:54:00 <ais523> it isn't the DLL itself, just the code/data to link to it
00:54:10 <shachaf> I mean: If I'm writing a compiler/linker, why shouldn't I do it Linux-style rather than generating import libraries first?
00:54:15 <ais523> the interesting part, and where the value comes from, is you can generate the import library even if you don't have a workinh DLL
00:54:27 <shachaf> Does it correspond to the PLT section in an ELF file or something?
00:54:28 <ais523> so it makes the dependencies in the build process more fine-grained
00:54:40 <ais523> you can think of an import library as the "source code" for the PLT
00:54:49 <ais523> that compiles to produce it
00:55:02 <Sgeo__> You can use a DLL without an import library if you're willing to do the retrieve function calls at runtime stuff
00:55:18 <Sgeo__> I wonder if any languages make that as convenient as using a DLL with an import library
00:55:28 <ais523> perhaps a good way to think about it is that the import library is the header file for a DLL
00:55:36 <shachaf> Why can't I just use a header file?
00:55:37 <ais523> it specifies what functions it has and how to call into them
00:55:47 <ais523> shachaf: because those only generate declarations, not code
00:56:09 <ais523> it'd make a /lot/ of sense to combine implibs and header files, except that C is the wrong language for it
00:56:24 <shachaf> OK, if I'm making up a language, why shouldn't I just use something like a header file, is what I meant.
00:56:27 <esowiki> [[User talk:A]] https://esolangs.org/w/index.php?diff=64760&oldid=64711 * Areallycoolusername * (+299) Ask User: A for ideas
00:56:36 <ais523> if you were creating a new language you would probably make a (header file + static library) or (header file + import library) combination as its own thing
00:56:52 <ais523> whereas (header file + shared library) doesn't work because you don't want to compile the shared library into your source code
00:57:07 <shachaf> I mean, if you're making up a language you should probably get rid of header files entirely for most uses.
00:57:19 <shachaf> Import libraries are the only place where you'd want things that look like headers.
00:57:24 <ais523> well, you don't want header files that are textually included, like C has
00:57:36 <ais523> but you do want some way to specify the API of code you don't have access to because it's in a library
00:57:49 <shachaf> You also don't want declarations that appear twice.
00:58:08 <shachaf> So it makes sense for externally linked things.
00:58:35 <shachaf> Anyway this all makes sense.
00:58:51 <ais523> actually, one thing that strikes me about languages is that working out the API of a file you're linking against is kind-of a major problem, that different languages solve (or fail to solve) in very different ways
00:59:09 <shachaf> You also ant to be able to cross-compile things without access to the DLLs or import libraries (I think kernel32.lib normally comes with Visual Studio or something?).
00:59:24 <ais523> e.g. in OCaml, the compiler can extract an interface from a file, and you can then compile against that, but writing the interfaces manually is also common
00:59:54 <ais523> in Java, the compiler wants access to either the source or binary you're linking against, and extracts declarations from that, but this is a pretty painful process and requires doing things like giving files specific names so that the compiler can find them
01:00:23 <ais523> shachaf: that's a good point, an ideal implib equivalent wouldn't be platform-specific
01:00:56 <ais523> although maybe it at least needs to be specific to things like target word sizes
01:01:57 <shachaf> I mean, the import library specifies an ABI, so it makes sense for it to specify platform-specific things?
01:04:51 -!- callforjudgement has joined.
01:04:57 -!- ais523 has quit (Disconnected by services).
01:05:02 -!- callforjudgement has changed nick to ais523.
01:05:22 <ais523> <ais523> hmm… if you're writing vectorised code by hand, what instruction set should you aim for?
01:05:37 <ais523> I was trying to use VPCMOV but it turns out my processor doesn't support it
01:05:38 <shachaf> The target architecture's?
01:05:48 <ais523> I mean, if you want other people to use the program
01:05:56 <ais523> presumably you aim for x86_64 as that's what most people have
01:06:11 <shachaf> Depends on how many people you want to use your thing.
01:06:12 <ais523> but what vector instructions do most people have on their processors and which ones might be less well supported?
01:06:31 <ais523> the manual I have in which VPCMOV is documented dates from 2005
01:06:50 <ais523> it's 2019 now and my processor still doesn't support it, so maybe some instructions are just omitted intentionally on some processors
01:07:26 <ais523> Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz
01:07:56 <ais523> I'm guessing that AVX2 might be a good cutoff point
01:08:02 <shachaf> Are you sure it's not supported?
01:08:13 <shachaf> Intel says it supports SSE4.
01:08:16 <ais523> shachaf: I compiled a program that used it and got SIGILL when it tried to execute
01:08:21 <ais523> it's an XOP instruction I think
01:09:05 <ais523> hmm, apparently AMD changed their mind about XOP and removed it again
01:09:19 <ais523> so I have some documentation of apparently very useful instructions that ended up not being implemented
01:11:16 <shachaf> At one point I wanted AVX2 and there was no CPU available that had it.
01:11:24 <shachaf> But that was years ago and it's probably reasonable to target by now.
01:11:38 -!- xkapastel has quit (Quit: Connection closed for inactivity).
01:13:01 <ais523> VPCMOV and some of the permutation instructions seem like the most useful XOP instructions
01:13:09 <ais523> horizontal adds could be useful in some algorithms too
01:13:39 <ais523> also the vectorised shifts/rotates are XOP, which surprises me, I thought they'd have been introduced long ago
01:15:41 <esowiki> [[Renumbering]] https://esolangs.org/w/index.php?diff=64761&oldid=64756 * JonoCode9374 * (+267) /* Example programs */ Infinite Counter
01:16:16 <ais523> hmm, so apparently Intel and AMD had their own competing ways to write vectorised shifts and rotates?
01:18:46 <ais523> or, no, PSLLW and friends hvae indeed been around for ages, now I'm really confused
01:19:39 <ais523> aha, the relevant case is shifts where different components get shifted different distances, i.e. vectorising << over both args, not just the left arg
01:22:14 <ais523> so that's less useful, then
01:37:30 <Sgeo__> "By using the pointer table, the loader does not need to fixup all of the places in the code that want to use the api call, all it has to do is add the pointer to a single place in a table and its work is done. "
01:37:32 <Sgeo__> http://sandsprite.com/CodeStuff/Understanding_imports.html
01:44:54 <shachaf> Do you know why ELF files usually have the program headers at the beginning of the file and the section headers at the end?
01:45:06 <shachaf> Is it an artifact of how they're usually generated, a section at a time?
01:47:29 <shachaf> Sgeo__: Are you writing fancy code to generate PE files too?
01:48:04 <Sgeo__> No. Learning about DOS to write a driver-level emulator for a DOS VR device, and started becoming curious about Windows
01:54:04 <shachaf> Can you also figure out Mac OS while you're at it?
01:54:21 <shachaf> I think it has a similar story to Windows, except system calls are somewhat more stable.
01:56:20 <Sgeo__> I don't know anything about Mac (and I'm pretty sure Mac would have two stories. X and before X). But AmigaOS is fascinating. Multitasking without virtual memory by using relocation. I think Windows at least doesn't bother relocating the .exe being run most of the time, but Amiga has to
01:57:05 <Sgeo__> On Amiga, 0x04 is a special location containing a pointer into an "Exec" library, and offsets of that are used to find Exec functions including ones for using other libraries.
01:57:35 <Sgeo__> Also the entire kernel is run in the user ring
02:01:09 <pikhq> Classic Mac OS was kinda funky -- it didn't have multitasking until a decent bit in.
02:02:23 <Sgeo__> That reminds me, is Commodore 64 considered to have multitasking? It's... possible to run two programs at once sort of, but it's hard to be sure they'll both not occupy the same memory
02:02:34 <Sgeo__> I guess more like a TSR than real multitasking
02:10:06 <Sgeo__> pikhq, did Classic Mac OS ever need its memory defragmented? I remember reading about ... something like that, I think in a book about using Macs.
02:10:53 <Sgeo__> These days paging sort of makes that irrelevant, memory locations don't need to be physically next to each other to be virtually next to each other
02:11:10 <pikhq> After Mac OS 7, it also had virtual memory and a 32-bit address space.
02:11:22 <pikhq> (this is also when it actually shipped with multitasking)
02:18:24 <shachaf> OK, it's pretty clear now why it's generated that way.
02:22:17 <ais523> hmm, so apparently Intel and AMD implemented incompatible versions of fused multiply-add, then both changed to support the other's version and dropped their own previous version
02:22:51 <ais523> apart from that, though, they're pretty much compatible up to AVX2
02:23:45 <ais523> whereas AMD hasn't yet started supporting Intel's new AVX-512 (which is admittedly pretty ridiculous, it contains so many features it needs a 4-byte /prefix/ on every operation in addition to things like the ModRM byte and opcode)
02:26:17 <esowiki> [[User talk:A]] M https://esolangs.org/w/index.php?diff=64762&oldid=64760 * A * (+194)
02:27:02 <pikhq> Isn't AVX-512 the one that's also really hard to use effectively, because just using it forces a downclock for some fraction of a second?
02:27:36 <esowiki> [[User talk:A]] M https://esolangs.org/w/index.php?diff=64763&oldid=64762 * A * (-7) /* Race conditions */
02:30:40 <zzo38> Is there any pokemon battle where each player may have a computer with three pokemons that you can exchange between each battle if you do best of three, like you can with side cards in Magic: the Gathering?
02:32:06 <esowiki> [[Talk:Sidex]] M https://esolangs.org/w/index.php?diff=64764&oldid=64755 * A * (+485)
02:33:18 <esowiki> [[Sidex]] M https://esolangs.org/w/index.php?diff=64765&oldid=64752 * A * (-73)
02:44:52 <ais523> zzo38: the Battle Factory mode in Pokémon Emerald/Platinum/HeartGold/SoulSilver is sort of like that: you start by being given 6 random Pokémon and pick a team of 3 of them, then play 3v3 against computer opponents, whenever you win you can swap one of your Pokémon with one of theirs, whenever you lose you have to restart from the start
02:45:08 <ais523> it's not quite the same rules as you were describing but it's close
02:45:56 <ais523> oh, Pokémon Black 2/White 2 have Mix Battles at the PWT, which is even closer to what you said: each player brings a team of 3 Pokémon, then chooses one of their opponents Pokémon and battles with the one they chose + the 2 the opponents didn't choose
02:46:52 <ais523> if you're talking about a sideboarding equivalent, that's already used in standard tournament rules: each player brings six Pokémon, sees the opponents six, then chooses four to battle with
02:47:06 <ais523> like sideboarding in M:tG except you get to do it right from the start of the game
02:53:02 -!- FreeFull has quit.
02:55:30 -!- ais523 has quit (Ping timeout: 248 seconds).
03:21:46 <dont-panic> are there certain topics that are easier to learn or find information on if you know a language that isn't english? I guess english could be included... I'm not sure how to search for what I'm thinking of on google
03:23:29 <zzo38> Maybe it even isn't on Google. Or even if it is, may be difficult to find for other reasons, such as how the searching ranking is work, or on the wording they use difference from your wording (they try to make it work anyways, but it doesn't always work so well), etc
03:24:27 <dont-panic> zzo38: I'm thinkiing of things like Ruby used to be more popular in japan as well as trading candlesticks for various currency markets
03:26:39 -!- dont-panic has quit (Read error: Connection reset by peer).
03:31:45 -!- dont-panic has joined.
03:32:42 <dont-panic> my hotspot is so bad I can't even do a speed test and my lag on irssi goes from 0 to 200 something and back and forth... its really bad
03:33:06 <dont-panic> like, I don't know if half of my messages make it into the channel type of bad
03:36:27 <Sgeo__> dont-panic, fiction originally in non-English languages. I like a thing called the Evillious Chronicles, but the novels are in Japanese
03:36:38 <Sgeo__> (The songs are also in Japanese but most of them have good English subtitles)
03:37:49 <dont-panic> its just unfathomable the amount of infromation in even one language, and then to think we have like 7111 languages, 23 of which are the main ones... what information am I missing out on?
03:38:43 <dont-panic> luckily the ramayana and vasistha's yoga were translated among other items from sandscrit... but its just kind of mind blowing to think about what you'd be able to figure out if you knew like 7 or 8 languages fluently
03:39:43 <zzo38> There is log for this IRC, so you can check if the messages are in the channel.
03:41:04 <dont-panic> I'm using irssi and for some reason ubuntu keeps thinking I hit page up and page down 10 or so times when I hit it once... its impossible to loook up further than the monitor allows
03:44:16 <dont-panic> I've been learning russian, but now I think I might switch over to chinese since there's more chinese and english speakers than most of the other languages combined
03:45:39 <kmc> the chinese writing system is so hard though ;_;
03:48:25 <kmc> what's new
03:49:06 <zzo38> dont-panic: It logs the message if the logging bot received the message. If it was sent to the channel, then all clients on that channel will receive it.
03:51:09 <kmc> dont-panic: I worked on an OCaml related thing in uni and took advantage of the fact that my project partner knew a little French and could read docs that weren't translated to English
03:52:00 <kmc> (it involved internals of the OCaml VM so not as well documented as the user level stuff)
03:58:15 <esowiki> [[User talk:A]] M https://esolangs.org/w/index.php?diff=64766&oldid=64763 * A * (+4) /* Race conditions */
04:06:35 <dont-panic> kmc: chinese writing may look hard, but if its your first language, you wouldn't know it was... the same as those with chinese as a first language probably squirm at english... our characters and sounds are all weird to them too lol
04:07:00 <kmc> chinese has thousands of symbols you have to learn
04:07:03 <kmc> english has 26, give or take
04:07:13 <dont-panic> Russian is the same... not entirely true
04:07:30 <dont-panic> chinese has thousands of combined symbols
04:07:53 <dont-panic> i.e. hill is like ^ and mountains is 3x ^ spaced weird
04:08:29 <dont-panic> its the same as prefix's and postfixes or whatever and particles in english or other languages
04:09:23 <dont-panic> *thousands of symbols made from combining symbols
04:09:51 <dont-panic> how else would one be able to use a standard keyboard to type mandarin or kanji?
04:11:35 <shachaf> `` echo $'.globl _start\n_start:\n.byte 0xeb; .byte 00' > /tmp/test.s; as -o /tmp/test.o /tmp/test.s; objdump -d /tmp/test.o
04:11:36 <HackEso> \ /tmp/test.o: file format elf64-x86-64 \ \ \ Disassembly of section .text: \ \ 0000000000000000 <_start>: \ 0:eb 00 jmp 2 <_start+0x2>
04:11:50 <shachaf> `` echo $'.globl _start\n_start:\n.byte 0xeb; .byte 00; int3' > /tmp/test.s; as -o /tmp/test.o /tmp/test.s; objdump -d /tmp/test.o
04:11:51 <HackEso> \ /tmp/test.o: file format elf64-x86-64 \ \ \ Disassembly of section .text: \ \ 0000000000000000 <_start>: \ 0:eb 00 jmp 2 <_start+0x2> \ 2:cc int3
04:12:03 <shachaf> I guess eb 00 is also a nop.
04:16:40 <dont-panic> сказок жен, их уже такой как ты ГОГ LOL ГОГ ROFL
04:16:59 <dont-panic> ^those aren't any easier for me to understand than chinese would be lol
04:17:06 <HackEso> [U+004C LATIN CAPITAL LETTER L] [U+004F LATIN CAPITAL LETTER O] [U+004C LATIN CAPITAL LETTER L]
04:18:12 <dont-panic> in russian p's are r's and b's are v's... along with a lot of weird stuff going on. sounding it out becomes a pain when transitioning from english and remembering where keys are on the keyboard gets weird too...
04:18:37 <dont-panic> http://xahlee.info/kbd/i2/Russian_keyboard_windows_layout_78067.png
04:19:39 <dont-panic> and f's look like they belong in a schematic work book... 'ф'
04:21:27 <dont-panic> № <-- that's one of my favorite keys lol
05:18:24 <zzo38> I think that Aquinas's proof of existence of God is illogical, because the conclusion contradicts the premise. However, the suggestion of infinite regress, that would satisfy the conditions, even though, they say it is impossible. Such infinite regress, the "end" (which still goes on anyways by infinitely) can then be "God".
05:25:18 <zzo38> Do you think such thing?
05:27:08 -!- user24 has joined.
06:17:45 -!- kolontaev has joined.
06:20:57 <zzo38> I mentioned my idea of cfork() for Plan10 on here before, and then one way to implement fork() by: #define fork() (cfork()?:detach())
06:28:33 <shachaf> What is cfork? What is Plan10?
06:34:07 -!- kolontaev has quit (Quit: leaving).
06:39:24 -!- moony24 has joined.
06:39:32 <zzo38> It is just a idea I had, about a alternative of Plan9 and Unix, which is compatible with Unix but also has some differences. (If you do not define plan10main() then the linker can substitute the default implementation, which sets up some compatibility with Unix and then calls main().)
06:39:54 -!- moony24 has changed nick to moony_.
06:41:25 <moony_> zzo38, what kind of differences?
06:41:30 <zzo38> shachaf: The cfork() function will fork, but all memory and registers (including the program counter) are shared until execve(), _exit(), or detach() is called. If successful, cfork() returns 0 (to the child process; it does not return any value to the parent process). In this case, execve() returns zero if successful.
06:43:22 <moony_> zzo38, i don't see what can be done with cfork that can't be done with normal fork
06:44:42 <moony_> if, theoretically, both programs have the exact same state as you described, it'd just have the same behavior as forking at the point the programs diverge
06:44:42 <zzo38> It seem a better interface to me, and also seems like it may be able to be more efficient in some cases.
06:45:31 <zzo38> The two processes do not have the exact same state; they still have their own process ID, file descriptors, etc (although the file descriptors are initially inherited).
06:46:43 <int-e> sounds eerily similar to vfork
06:47:48 <zzo38> Yes, it is similar, but there are some differences. (For one thing, vfork() is not guaranteed to be different from fork().)
06:50:05 <zzo38> Also, it is not allowed to return from the function vfork() was called in the child process, and the behaviour may depend on what is stored in registers, and so on; with cfork the registers are shared too (including the program counter).
06:54:09 <moony_> How would that be feasibly implemented on x86_64 without just setting a flag and no-oping
06:56:38 <int-e> moony_: yeah I'd also think it sets a flag that modifies the behavior of execve.
06:56:57 <zzo38> The kernel would probably copy some stuff, select the new process, and then just continue the same program with the new process ID.
06:56:59 <int-e> and reserves a PID?
06:58:02 <int-e> moony_: or it could be like vfork except that on child termination or execve, state is copied back to the parent.
06:58:36 <int-e> (state being the registers...)
06:58:43 <zzo38> Once it is detached, then it would create a new saved register set for it, I suppose.
06:58:57 <zzo38> int-e: Yes, that could also be a way to implement it, I suppose.
06:59:21 <moony_> Well uh, two processes with the exact same deterministic behavior seems kinda useless in practice
06:59:38 <moony_> and it'd be very easy to break the illusion via, say, RDRAND
07:00:37 <int-e> or something trivial like getpid() ;-)
07:01:02 <moony_> "who am i" "you are a split personality"
07:01:45 <zzo38> You can use getpid(); if used before it is detached, it will return the child process ID, but you can store it in a variable, and then after it is detached, the value (which is the child process ID) will still be visible to the parent.
07:02:11 <moony_> could add a brand new error value to handle the CFORK state when calling certain syscalls
07:02:49 <moony_> technically syscalls should be done twice
07:02:56 <int-e> moony_: no, I don't think it's really two processes.
07:03:08 <zzo38> (The parent process won't execute until the child is detached, so getpid() will always return the child process ID. Any system calls will be executed in the child process, too.)
07:03:57 <int-e> moony_: the way zzo38 describes it, only the child runs (like vfork) and the parent is revived upon executing execve() (and sees the return code of that)
07:03:59 <moony_> you can ignore me because I am a derp
07:04:02 -!- doesntthiswork has quit (Ping timeout: 248 seconds).
07:04:47 <int-e> Or only upon *successfully* executing execve?
07:05:40 <zzo38> Only if successful, then the parent sees zero as the return value of execve(). If execve() is not successful, it returns -1 to the child, and the parent is not revived.
07:07:49 <zzo38> Hopefully that explains it?
07:09:04 <int-e> zzo38: so what does the child do if it doesn't find any executable to execute?
07:09:55 <int-e> I mean, at some point you need to give up, and pass control back to the parent anyway.
07:11:05 <zzo38> Yes; then you can just call _exit() in the child, which causes the parent to continue; or detach(), which causes both the parent and child to continue.
07:11:58 <zzo38> (Remember that fork() is the same as (cfork()?:detach()).)
07:21:49 <esowiki> [[BlobVM]] N https://esolangs.org/w/index.php?oldid=64767 * Void * (+7367) Create BlobVM
07:22:27 -!- xkapastel has joined.
07:22:52 <esowiki> [[Language list]] M https://esolangs.org/w/index.php?diff=64768&oldid=64759 * Void * (+13) Add BlobVM
07:23:14 -!- dont-panic has quit (Ping timeout: 248 seconds).
07:24:19 -!- moony_ has quit (Ping timeout: 260 seconds).
07:25:32 <esowiki> [[Special:Log/upload]] upload * Void * uploaded "[[File:Little.png]]"
07:29:03 <esowiki> [[BlobVM]] M https://esolangs.org/w/index.php?diff=64770&oldid=64767 * Void * (-1573) Add capability example
07:37:23 <esowiki> [[BlobVM]] M https://esolangs.org/w/index.php?diff=64771&oldid=64770 * Void * (+424) Add data structure overview
07:37:57 <esowiki> [[BlobVM]] M https://esolangs.org/w/index.php?diff=64772&oldid=64771 * Void * (+0) Fix list
07:40:21 <esowiki> [[BlobVM]] M https://esolangs.org/w/index.php?diff=64773&oldid=64772 * Void * (-346) /* Cooperative resource sharing between devices */
07:45:28 <user24> Can I rename an article?
07:46:14 <esowiki> [[Special:Log/move]] move * Void * moved [[BlobVM]] to [[KeyVM]]: Rename VM
07:47:33 <esowiki> [[KeyVM]] M https://esolangs.org/w/index.php?diff=64776&oldid=64774 * Void * (-3) Rename from blobVM to keyVM
07:48:39 <esowiki> [[Language list]] M https://esolangs.org/w/index.php?diff=64777&oldid=64768 * Void * (-1) Rename from blobVM to keyVM
07:54:41 <zzo38> Do you like to play solitaire Scrabble? My highest score so far is 699
08:00:27 -!- Lord_of_Life has quit (Ping timeout: 245 seconds).
08:02:19 <shachaf> My highest score so far is 700.
08:02:42 <shachaf> (But not in solitaire Scrabble. That's just my score in life.)
08:04:35 <int-e> What's the measure? sheets of sheet music?
08:05:16 -!- Lord_of_Life has joined.
08:06:37 <int-e> .......... .......... .......... .......... ..
08:06:56 <int-e> Oh maybe it's your Chinese social score.
08:09:42 <shachaf> Are you objecting to not being swatted for that pun? I'm not oerjan.
08:09:44 -!- cpressey has joined.
08:10:27 <int-e> shachaf: I'm just riding the wave.
08:10:36 <shachaf> But I think that multiplier is backwards.
08:11:03 <int-e> I was working with a a 700 score.
08:11:22 <shachaf> If my score = 700, then my = 35
08:12:02 <int-e> (Does that bring it up to 701?)
08:28:29 -!- Phantom_Hoover has joined.
08:44:56 <esowiki> [[Talk:An Odd Rewriting System]] https://esolangs.org/w/index.php?diff=64778&oldid=64723 * Chris Pressey * (+1944) I don't see "predict parity on the left" being a problem.
09:02:12 -!- ais523 has joined.
09:02:15 -!- ais523 has quit (Client Quit).
09:05:40 <cpressey> Since we have an esowiki->IRC bridge, I think the obvious next step would be to build an IRC->esowiki bridge
09:06:09 <cpressey> Hm. I said that in jest, but now I'm not so sure
09:07:49 <int-e> Well, it does sound like a terrible idea.
09:09:06 <HackEso> helsinki:Helsinki is the capital of Finland. Its main suburb is Hexham, Northumberland.
09:09:20 <HackEso> 1229) <fungot> boily: the proc is invoked. before or after the evaluator transfers control to a certain class of anime characters with long hair and loud music \ 847) <zzo38> The winter solstice is in approx. 13 hours from now <kmc> the mayans warned us <zzo38> Warned you of what? The solstice? <kmc> yes
09:22:16 -!- tswett[m] has quit (Remote host closed the connection).
09:22:20 -!- ivzem[m] has quit (Remote host closed the connection).
09:22:26 -!- wmww has quit (Remote host closed the connection).
09:22:43 -!- xylochoron[m] has quit (Read error: Connection reset by peer).
09:22:55 <shachaf> Do you know how .a files work?
09:23:05 <int-e> beyond them being ar archives, a collection of .o files? no
09:23:13 <shachaf> I thought they'd be very simple but there's no formal specification and I'm confused.
09:23:34 <int-e> (in particular I think there's some magic on top for better indexing)
09:27:17 <FireFly> Based on a very quick look at creating one with 'ar', it does look fairly simple
09:27:50 <FireFly> and perhaps unsurprisingly, not too far from tar
09:28:34 <shachaf> I'm looking at /usr/lib/x86_64-linux-gnu/libfreetype.a, hopefully without loss of generality
09:30:42 -!- wmww has joined.
09:31:25 <shachaf> OK, it's a symbol lookup table.
09:31:32 <shachaf> I was looking in the wrong place.
09:33:01 <cpressey> so if I untar an .a file will it create a file for each symbol, please say it does
09:37:22 <esowiki> [[KeyVM]] M https://esolangs.org/w/index.php?diff=64779&oldid=64776 * Void * (-9) /* Distinguishing features */
09:37:51 -!- arseniiv has joined.
09:50:44 -!- tswett[m] has joined.
09:50:44 -!- xylochoron[m] has joined.
09:50:53 -!- ivzem[m] has joined.
10:02:06 -!- xkapastel has quit (Quit: Connection closed for inactivity).
10:48:57 <shachaf> So apparently sections aren't used for running a program at all?
10:53:54 * int-e wonders where shachaf is going with all this
10:55:10 <int-e> But programs have sections too, don't they... executable bits, read-only data bits, zero-initialized read/writable bits...
10:55:40 <shachaf> They have segments which specify what's mapped into memory.
10:56:27 <shachaf> I thought the .bss section and .plt section and .rodata and so on were used for that but apparently not?
10:59:21 <shachaf> Writing a compiler, maybe. Or just understanding things?
10:59:37 <shachaf> There are more important problems in the compiler thing than this, of course.
11:02:22 <cpressey> Sections are used for computing offsets during linking, I think
11:02:44 <cpressey> Once those offsets have been computed, the running program doesn't need to care what they were
11:02:49 <cpressey> So in that sense they're not used
11:03:27 <cpressey> Actually I think I mean "segment", don't know if that's different from "section" or not
11:05:59 <shachaf> Sections are required for object files and optional for executable files, and segments are the other way around.
11:09:57 <cpressey> Mostly what I remember is that the .bss section is for uninitialized data. The linker needs to decide where in memory it will be, but doesn't need to give it any particular contents.
11:10:26 <shachaf> Yes. But apparently the ELF loader doesn't care about it at all.
11:11:24 <cpressey> The linker might merge it and other sections into a single segment, as long as there's enough space in that segment for all the variables.
11:11:36 <cpressey> I really have no idea, actually
11:11:53 <cpressey> I'm just going from fuzzy memories to plausible inferences
11:13:28 <cpressey> I imagine there are probably a dozen people in this channel who know this like the back of their hand...?
11:20:25 <arseniiv> . o O (what is more complex, ELF or PE?)
11:21:36 <shachaf> Though I looked at a PE file today, it seems OK.
11:22:10 <int-e> ELF does not contain an a.out stub that prints a useless message. :P
11:23:46 <shachaf> You can put whatever you want in there.
11:24:01 <shachaf> The first 60 bytes are up to you.
11:24:34 <shachaf> Oh, no, you need the MZ header, of course.
11:24:41 <int-e> superficially they look to be of similar complexity.
11:25:27 <int-e> (ELF may have more extensions? I don't know.)
11:26:16 <int-e> Though the extensions were mostly special sections, which technically do not increase the file format complexity... just the complexity of making sense of the contents.
11:27:02 <shachaf> I thought the .gnu.hash section was used for dynamic linking, but apparently the information is in the DYNAMIC segment which is what actually matters.
11:40:23 -!- Phantom_Hoover has quit (Quit: Leaving).
12:07:39 <esowiki> [[Tsb]] N https://esolangs.org/w/index.php?oldid=64780 * Sec-iiiso * (+5262) Created page with "'''Tsb''' is a programming language that compiles to [[Seabass]] and was made to simplify coding in it, while retaining many of Seabass's design choices. ==Basics== ===Genera..."
12:08:25 <esowiki> [[KeyVM]] M https://esolangs.org/w/index.php?diff=64781&oldid=64779 * Void * (+59) /* See also */
12:12:14 -!- user24 has quit (Quit: Leaving).
12:20:31 <esowiki> [[Tsb]] https://esolangs.org/w/index.php?diff=64782&oldid=64780 * Sec-iiiso * (+225) /* General */
12:23:36 -!- MDude has quit (Ping timeout: 272 seconds).
12:45:48 -!- FreeFull has joined.
12:54:05 <esowiki> [[Special:Log/newusers]] create * Hanzlu * New user account
12:58:14 <esowiki> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=64783&oldid=64693 * Hanzlu * (+142)
13:00:09 -!- user24 has joined.
13:00:25 -!- user24 has quit (Remote host closed the connection).
13:35:43 -!- MDude has joined.
13:38:24 <esowiki> [[ACL]] N https://esolangs.org/w/index.php?oldid=64784 * Hanzlu * (+2995) Created page with "ACL (Advanced Computer Language) is a language created in 2019. Its memory consists of binary cells, with the values 0 or 1. The commands in the language code are Hexadecimal..."
13:39:58 <esowiki> [[Language list]] https://esolangs.org/w/index.php?diff=64785&oldid=64777 * Sec-iiiso * (+10) /* T */
13:40:36 <esowiki> [[ACL]] https://esolangs.org/w/index.php?diff=64786&oldid=64784 * Hanzlu * (+14)
13:46:40 <esowiki> [[ACL]] https://esolangs.org/w/index.php?diff=64787&oldid=64786 * Hanzlu * (+79)
13:49:22 <esowiki> [[ACL]] https://esolangs.org/w/index.php?diff=64788&oldid=64787 * Hanzlu * (+41)
14:00:45 -!- doesntthiswork has joined.
14:08:07 -!- user24 has joined.
14:08:47 -!- Melvar has quit (Ping timeout: 245 seconds).
14:17:30 <esowiki> [[ACL]] https://esolangs.org/w/index.php?diff=64789&oldid=64788 * Hanzlu * (+338)
14:22:47 -!- Melvar has joined.
14:56:57 -!- cpressey has quit (Quit: WeeChat 1.4).
15:02:22 <esowiki> [[Renumbering]] M https://esolangs.org/w/index.php?diff=64790&oldid=64761 * DoggyDogWhirl * (+127) Primer
16:02:35 -!- FreeFull has quit.
16:03:01 -!- Sgeo_ has joined.
16:05:55 -!- Sgeo__ has quit (Ping timeout: 246 seconds).
16:20:10 -!- xkapastel has joined.
16:30:00 -!- Sgeo__ has joined.
16:32:52 -!- Sgeo_ has quit (Ping timeout: 246 seconds).
17:07:58 -!- user24 has quit (Quit: Leaving).
17:09:34 -!- Reallycooluserna has joined.
17:09:59 <Reallycooluserna> Im thinking of creating a computer that uses an esolang as its native machine code.
17:10:22 <Reallycooluserna> Ive already figured out what I would need to do this, thanks to quora
17:12:09 <Reallycooluserna> If anyone has an esolang thats simple enough to be workable machine code, and elaborate enough to be used to perform useful computations, I'd appreciate it
17:12:46 -!- Reallycooluserna has quit (Remote host closed the connection).
17:16:20 -!- Phantom_Hoover has joined.
17:18:30 <esowiki> [[MISC]] https://esolangs.org/w/index.php?diff=64791&oldid=54347 * Areallycoolusername * (-9) /* Origin of the name */
17:21:22 <kmc> Reallycooluserna: I have some ideas, but you left immediately after asking your question for some reason. how do you think IRC works, exactly?
17:33:14 <HackEso> 330) <oklopol> are there boobs you wack and squeeze around to move the mouse? [...] <oklopol> like those little nipples in laptop keyboards, but they'd be full-blown boobies
17:42:26 -!- Sgeo_ has joined.
17:45:27 -!- Sgeo__ has quit (Ping timeout: 245 seconds).
18:45:31 -!- Reallycooluserna has joined.
18:47:30 <shachaf> This is what they do all the time.
18:47:40 <Reallycooluserna> I usually leave after asking a question, since I don't wan to wait on the chat until someone answers. I instead go do something else and wait, and then check the logs for some answers.
18:47:52 <shachaf> It's also what A did all the time, though the claim is that they're a different person.
18:51:33 -!- Reallycooluserna has changed nick to ARCUN.
18:56:49 <arseniiv> ARCUN: one of your previous questions was pretty mysterious :D let me look for it…
18:56:59 <arseniiv> ah, here it was: <Reallycooluserna> Can anyone give me tips as to how to make a good C++ Compiler?
18:56:59 <doesntthiswork> ARCUN: you have to leave the channel and wait for the answer or it won't work
18:57:56 <arseniiv> ARCUN: did you mean a compiler written in C++ or (what I thought of) a full-blown compiler of C++ itself?
19:00:03 <arseniiv> the latter should be a massive task, as C++ is a language wih a huge specification, even if one is to take one of its older versions
19:00:07 -!- ARCUN has quit (Ping timeout: 260 seconds).
19:01:10 <arseniiv> the former can have some specifics regarding C++, but usually writing a compiler (in a normal language) is more or less the same
19:07:28 -!- ARCUN has joined.
19:08:49 <ARCUN> I meant writing a compiler IN C++. Writing a compiler for C++ would be the end of me.
19:10:08 <ARCUN> Im asking because I need to make a compiler for a minimalistic esolang for a computer that runs that esolamg as its machine code
19:10:15 -!- ARCUN has quit (Remote host closed the connection).
19:30:25 <shachaf> My program is segfaulting in the ELF interpreter, before getting to my entry point.
19:30:35 <shachaf> I don't know how to tell gdb to break early enough.
19:37:29 -!- ARCUN has joined.
19:38:16 <kmc> shachaf: can you explicitly invoke the interpreter as a program?
19:41:14 <ARCUN> kmc: What are the ideas you said you had regarding the esoteric computer?
19:42:00 -!- lldd_ has joined.
19:44:23 <kmc> well, it would be easy to implement any simple state machine like thing such as Brainfuck
19:44:27 <kmc> in Verilog or VHDL
19:44:33 <kmc> i've done it actually, loooooong time ago
19:45:26 <ARCUN> Yeah, I was thinking of a language that used 1 byte constructions, to maximize space like brainfuck
19:45:57 <shachaf> kmc: I could, but that would go through a different code path.
19:46:05 <ARCUN> but using brainfuck in an eso-computer has already been done more than twice
19:47:51 <kmc> shachaf: yeah :(
19:48:08 <kmc> shachaf: inject an INT3 instruction at _start?
19:48:19 <shachaf> Oh, that gives me an odd error message.
19:48:22 <kmc> also, there probably is an obscure gdb option to do what you want
19:48:30 <shachaf> I think it explains what's going on so that's something.
19:48:33 <kmc> what the heck did you even do to segfault the ELF interpreter
19:48:35 <shachaf> kmc: _start where, in ld.so?
19:48:55 <kmc> may not have a symbol but I mean whatever its entry point is (which readelf will tell you)
19:48:55 <shachaf> I guess I can make a copy of ld.so for testing.
19:49:18 <shachaf> I'm generating my own ELF files so it figures they're malformed.
19:49:25 <shachaf> I also made an ELF file that segfaults gdb.
19:49:46 <kmc> good old libbfd
19:50:43 <shachaf> No, I'm writing them out myself.
19:52:02 <shachaf> It looks like ld.so isn't happy that I wasn't mapping the DYNAMIC segment into memory. Which, I mean, fair enough, I guess.
19:52:13 <kmc> it is the file format for executables and libraries used on Linux and many other systems
19:52:17 <shachaf> Or rather I wasn't specifying its address.
19:53:08 <kmc> ARCUN: at its core it is a set of records saying "load this chunk of data to this memory address, with this set of permissions (read / write / execute)"
19:53:15 <shachaf> ARCUN: In response to the other day, making a dynamically linked PE file seems a lot simpler, probably because it's required.
19:53:33 <kmc> ARCUN: but there are many complexities of course
19:53:55 -!- Sgeo__ has joined.
19:54:12 <kmc> ARCUN: if you have access to a Linux system then you can run "readelf -a /bin/ls | less" to see some of this info
19:54:24 <kmc> linkers are so complicated
19:54:25 <kmc> and also neat
19:54:34 <kmc> https://www.iecc.com/linker/
19:54:42 <ARCUN> I'm just starting to use UNIX through cygwin, so i'll look into it
19:55:11 <arseniiv> <ARCUN> I meant writing a compiler IN C++. Writing a compiler for C++ would be the end of me. => okay, thanks
19:55:47 <arseniiv> though I personally can’t advice about writing on C++, I don’t know it too well
19:56:23 <kmc> ARCUN: cygwin uses native Windows binaries, so they will be PE format, not ELF
19:56:48 <kmc> cygwin is, roughly speaking, a set of userspace libraries which implement a POSIX compatible userspace for the Windows operating system
19:56:51 <ARCUN> arseniiv: Then what languages do you know? I'm certain you know a language that I know also
19:57:01 <kmc> it's not a Linux/UNIX emulator
19:57:16 -!- Sgeo_ has quit (Ping timeout: 246 seconds).
19:57:19 <kmc> however Windows 10 also has WSL which runs unmodified Linux ELF binaries through a kernel level syscall translation layer
19:57:51 <ARCUN> kmc: Then i'll try running ubuntu in a VM
19:57:58 <kmc> ARCUN: that is a good way to go
19:59:39 -!- Lord_of_Life_ has joined.
19:59:41 <arseniiv> shachaf: I wondered about ELF vs PE because I don’t know either (except that MZ-something header thing, but it’s of course doesn’t matter)
20:00:07 <arseniiv> ARCUN: yeah I have an Ubuntu in VirtualBox
20:01:16 <arseniiv> though I boot it rarely. I definitely need to make myself more familiar with it for the future
20:01:38 -!- Lord_of_Life has quit (Ping timeout: 248 seconds).
20:02:24 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
20:04:22 <shachaf> I think I'm still confusil about how things are normally mapped into memory.
20:04:31 <arseniiv> <ARCUN> arseniiv: Then what languages do you know? I'm certain you know a language that I know also => C#, Python, Mathematica are those I written in more or less recently to not forget them too much. Though of course using Mathematica for a VM is a strange thing. OTOH C# and Python allow one to emit their bytecode (and in case of C#, it would then be JIT’ed, which is good, and in case of PyPy Python implementation it should IIRC be so too, but not s
20:04:36 <shachaf> There are typically two loaded segments, right? One rw and one rx.
20:04:59 -!- ARCUN has quit (Ping timeout: 260 seconds).
20:05:25 <shachaf> These are presumably both randomized independently.
20:06:00 <shachaf> The PLT and data and so on would be in the rw segment.
20:06:05 <shachaf> Are those at a fixed offset to each other?
20:07:12 -!- ARCUN has joined.
20:08:03 <ARCUN> arseniiv: Yeah I know C#, it was my first language
20:08:29 <ARCUN> but I use C++ a lot more than C#, so i'll have to brush up on it
20:09:44 -!- xkapastel has quit (Quit: Connection closed for inactivity).
20:10:57 <shachaf> So I guess some fixed offset is randomized and everything is loaded relative to that.
20:11:20 <shachaf> And so everything can just do IP-relative addressing to get at data, which is reasonable.
20:16:08 <arseniiv> ARCUN: then if you are not shy of parser combinators, I’d recommend writing parser/lexer for the language chosen in them, it’s good at least as a prototype thing, and some libraries are as good as to allow writing a parser robust enough to show transparent error messages to user or etc.. Also maybe a useful general advice would be to use Expression trees to get compiled methods out of them without having to use Emit class. They both had poor docume
20:16:08 <arseniiv> ntation when I looked it, but the former are clearer semantically, almost a high-level language. If you’ll use C#, that is
20:17:36 <arseniiv> there should be some parser combinator libraries for C++ too
20:18:25 <ARCUN> I'll look into that, since I'd like my language to have some extensions
20:18:41 <ARCUN> maybe a math library for starters
20:25:35 <ARCUN> The language I had in mind would be called "Xrk", and it would have logic based on Complex numbers. somewhat based on the "NaNs and Flips flops" paper from http://sigbovik.org/2019/proceedings.pdf#page102
20:28:25 <ARCUN> arseniiv: It would be minimalistic with maybe 6 or less instructions, but would still have a lot of potential. i'll do everything possible to make it not look like Brainfuck
20:30:57 <arseniiv> have you seen https://esolangs.org/wiki/7 ?
20:32:39 <arseniiv> one of my favorite esolangs is FALSE, maybe because it looks pretty writeable/readable (so, not so eso?..)
20:32:59 -!- ARCUN has quit (Ping timeout: 260 seconds).
20:33:57 <arseniiv> I like [...] from it, though I don’t know if it was borrowed from some more mainstream stack language
20:42:21 -!- ARCUN has joined.
20:43:27 -!- ARCUN has quit (Remote host closed the connection).
20:54:01 -!- lldd_ has quit (Quit: Leaving).
21:52:26 -!- Sgeo_ has joined.
21:55:41 -!- Sgeo__ has quit (Ping timeout: 258 seconds).
22:19:33 <HackEso> smlist 1172: shachaf monqy elliott mnoqy Cale
22:19:40 <shachaf> That's not the right list.
22:19:42 <HackEso> olist 1172: shachaf oerjan Sgeo FireFly boily nortti b_jonas
22:27:58 -!- Phantom__Hoover has joined.
22:30:26 -!- Phantom_Hoover has quit (Ping timeout: 248 seconds).
22:35:40 -!- b_jonas has joined.
22:35:56 <b_jonas> zzo38, ais523: in perl, y/x// also works instead of y/x/x/
22:40:11 <b_jonas> ais523: re x86_64 nop and xchg instructions, we tried to figure out how those worked at https://esolangs.org/logs/2019-02.html#lwFc
22:44:34 <b_jonas> ais523: "on Linux, a .so acts as its own import library, which makes, e.g., circular dependencies between .so files hard to intentionally construct" => is that like how if you want to make circular dependencies between modules in haskell or rust, then you need to write "headers" with declarations, which you normally don't have to do because the compiler can tell the declarations from the object file?
22:45:30 <b_jonas> whereas in C or C++, you always write header files if you have more than one compilation unit, because the compiler can't read the declarations from the object files
22:45:47 <shachaf> Whole program compilation is TG.
22:59:35 <b_jonas> oh good, there was a new olist while I was gone
23:15:39 -!- arseniiv has quit (Ping timeout: 264 seconds).
23:21:25 -!- Sgeo__ has joined.
23:24:37 -!- Sgeo_ has quit (Ping timeout: 258 seconds).
23:26:50 -!- Sgeo has joined.
23:29:14 -!- Sgeo__ has quit (Ping timeout: 272 seconds).
23:56:16 <Sgeo> Hm. Is Windows's thing of sys calls being undocumented behind a dll a thing that allows WINE to run in userspace?
23:56:32 <Sgeo> Like, a reverse WINE would need to run as admin and do some tricky stuff, right?
23:59:13 -!- doesntthiswork has quit (Ping timeout: 244 seconds).