00:00:46 <Corbin> Yeah, it's definitely skeletal.
00:01:06 <b_jonas> ais523: perhaps one of the languages that are specialized for programming MUDs or text adventure games have all function definitions work in an event handler way that concatenates multiple handlers
00:01:40 <Corbin> Yes, row polymorphism is intimately connected to the typical stack-based Forth desendant. IIRC Factor's type system is effectively just higher-order row-polymorphic signatures.
00:05:32 <b_jonas> "skeletal" still reminds me of how Hollow Dogs the M:tG card still hasn't been errataed to have the Skeleton creature type
00:06:27 <b_jonas> give me my Phyrexian Zombie Skeleton Dogs already, Wizards
00:06:41 <b_jonas> (this line is to preempt any Changeling joke)
00:06:48 <zzo38> I mostly use C for my own programs (I dislike some of the features of some of the programming languages intended to be a replacement for C), but sometimes I will use PostScript, or others
00:07:15 <keegan> A hollow dog is never empty. It is filled with thirst for the hunt.
00:11:57 <esolangs> [[Category theory]] M https://esolangs.org/w/index.php?diff=87540&oldid=74393 * Corbin * (+632) Give a couple ways to apply category theory to programming language theory.
00:20:17 <b_jonas> zzo38: I wonder what your opinion on zig is. it seems like it's trying to be for C what Rust is for C++, and I think it's doing that pretty well
00:21:00 <b_jonas> though I guess their selling point of trying to provide a sane (Zig AND C AND C++) compiler package for Windows isn't a selling point for you
00:22:42 <ais523> I guess my opinion is that making a better C is incredibly easy, the issue is trying to make a C that's better *enough* for people to use it
00:23:02 <ais523> for me, Rust is better by enough to be worth changing my main systems language
00:23:22 <b_jonas> ais523: and providing a sane compiler environment for Windows, which is something we're lacking right now, is a good way of doing that
00:23:42 <b_jonas> like, I download the package to get a C++ compiler for windows, and get curious what else is there
00:24:10 <b_jonas> it's like git, which provides a vim port and a terminal for windows, you install it, and wonder what the version control thing that the distribution is named of is about
00:24:10 <ais523> I normally use Strawberry Perl if I want a C compiler for Windows (there's one bundled in with it)
00:24:26 <b_jonas> ais523: does it have a C++ compiler?
00:24:31 <ais523> also I don't think that's what made git popular
00:24:35 <ais523> b_jonas: I'm not sure, but probably
00:24:37 <b_jonas> also thanks for that recommendation, I might look at it
00:24:57 <b_jonas> ais523: no, it didn't. the Linux kernel versioned with it did, sadly
00:24:59 <ais523> it's basically just gcc with competent packaging
00:25:14 <b_jonas> ais523: yes, and that's the hard part. Zig distributes a clang with competent packaging.
00:25:32 <ais523> I agree that competent packaging is the hard part, especially on Windows
00:25:36 <b_jonas> that's how you get a good C++ compiler, more so than trying to implement one from scratch
00:26:18 <b_jonas> there used to be https://www.msys2.org/ which provides a gcc, but it's not been updated for years now
00:28:12 <b_jonas> hehe, https://scryfall.com/card/ice/137/kjeldoran-dead was originally printed as a Dead, while https://scryfall.com/card/all/55b/lim-d%C3%BBls-high-guard as a Skeleton. they really didn't know how to use creature types back then.
00:28:21 <ais523> Windows is a moving target (although not to the extent Mac OS X is), it's a pain to keep things updated there
00:29:01 <b_jonas> yes, it's definitely not an easy task
00:29:14 <ais523> the situation with the standard libraries is especially disappointing
00:29:23 <b_jonas> (Dimir House Guard is a rare armored skeleton)
00:29:51 <ais523> (there's a libc bundled with Windows but it's nonstandard and your aren't officially supposed to use it; there are also libcs bundled with MSVC which are more standards-compliant, but are licensed in such a way that you can't use them as the libc for an open-source compiler)
00:30:29 <ais523> (and the raw system calls aren't supposed to be exposed to applications – although some applications are using them anyway, it seems – so writing your own libc from scratch is also very difficult)
00:32:26 <b_jonas> you can't use MSVC as the libc as an open-source compiler?
00:32:38 <b_jonas> as opposed to just with gcc because of gcc's GPL license or something?
00:33:04 <b_jonas> not even if you have to install the library separately, it's not distributed with the compiler toolkit?
00:34:07 <ais523> I forget the exact license terms, but I know they prevent that working somehow
00:34:15 <b_jonas> (not that I think GPL would forbid that, but just in case)
00:34:43 <b_jonas> I know MS has some licences where you can't redistribute the library or font, but if you download it directly from Microsoft, you can use it
00:36:01 <b_jonas> but that doesn't apply to the part of the library that wraps syscalls to Windows API calls, right? just the part that's trying to be a C standard library?
00:39:15 <ais523> this is horrible, I've been on Microsoft's website for about 10 minutes now and still can't find the EULA for these things
00:39:28 <ais523> I even found a download page, but the license isn't specified on the download page itself
00:40:06 <ais523> one of the pages I found suggested installing Visual Studio to view the license
00:40:59 <ais523> I found links to webpages that were supposed to contain the license terms, but they didn't
00:41:26 <ais523> also, they're the same library
00:42:34 <shachaf> ais523: I just want a "better C" that's better enough that I can use it.
00:43:13 <shachaf> Rust seems much more like "better C++" to me, and I that's not really the style of language I want.
00:44:13 <ais523> fair enough; I think that's a fair assessment of the language
00:44:24 <ais523> I would probably have been using C++ already if I thought it was better enough than C, but I didn't
00:47:47 <ais523> ooh, this is new: https://docs.microsoft.com/en-us/cpp/windows/universal-crt-deployment?view=msvc-160
00:47:53 <ais523> Windows finally has a centralised C runtime!
00:48:55 <ais523> 2015, so more recently than I last looked at this nonsense
00:52:58 <b_jonas> ais523: what does "centralized C runtime" mean? I seem to recall they introduced an ABI stable between MSVC releases around that point
00:55:05 <ais523> b_jonas: the C runtime is installed with/by the OS, rather than being installed along with every C program you want to run on you rcomputer
00:55:47 <ais523> for a while, Windows was using a hybrid model in which the C runtime was installed by installers for the various C programs you installed on your computer, but into a location that Windows Update knew about, and it kept it updated once it was there
00:55:54 <ais523> but just having one copy that's kept updated by the OS makes a lot more sense
01:25:49 <zzo38> I think one of the worst things about C is the confusing syntax for types. Although, there are also many features that I like about C that the other ones are not doing.
01:26:53 <zzo38> One thing I like about C is the macros, and also that it doesn't use Unicode
01:29:50 -!- oerjan has joined.
01:37:59 <shachaf> It had a secret mini-CRT for a long time, right?
01:38:18 <shachaf> Apparently since Windows 98 or so?
01:38:54 <b_jonas> ais523: I thought that was always the model, but you didn't get a libc newer than the Windows version that way, while programs wanted to work on older versions of Windows, so they installed the libc anyway
01:39:36 <b_jonas> and since like Windows 7, Windows update installs future versions of the runtime too in updates
01:39:48 <ais523> shachaf: yes, it was used internally by the OS
01:39:52 <b_jonas> but this is just a vague impression, it's probably not accurate
01:40:11 <ais523> and was very similar to a libc, but had a few bizarre differences, just different enough to break C programs that weren't aware of them
01:40:32 <ais523> I think the most famous is snprintf returning 0 if the number of characters which would be printed were too long for the buffer
01:41:21 <ais523> somewhere I have an snprintf wrapper that allocated a larger buffer and tries again if snprintf returns an impossible value, so that it'll work with msvcrt.dll
01:41:52 <ais523> (obviously, having snprintf return the expected buffer length itself is much more useful…)
01:43:49 <b_jonas> whereas the MSVC library has a version that prints floating point numbers in a way that doesn't match C99 or gnu libc, and since implementing formatting floating point is so hard, a lot of programs use it as the backend for formatting floats, sometimes even with a fixup to print floating point numbers the usual way
01:44:08 <b_jonas> usual for C99 that is, Windows libc might have priority
01:44:54 <b_jonas> it's so odd, I wish the libc makers could cooperate to fix this somehow, like by introducing a low-level function that formats floats always in the unix/C99 way
01:45:07 <b_jonas> it doesn't even have to be a full printf function
01:45:07 <ais523> I think libc should be split into two parts
01:45:25 <ais523> one of which just does system calls / OS interaction with minimal logic (only just enough to smooth out differences between OSes)
01:45:30 <ais523> and the other part is platform-independent
01:45:43 <b_jonas> of course if they do it now, it will only get a use ten years later, but software developers don't have term limits and regular elections
01:45:59 <ais523> it's weird that if you want, say, a portable fopen(), you also need to pull in a strlen() too
01:46:53 <ais523> at a previous job, my boss asked me why his Haskell program was getting affected by libc buffering when it wasn't written in C
01:47:17 <ais523> I had to explain that most programming languages went via C to interface with the operating system because it's simpler than writing code to interface with every operating system yourself
01:47:18 <oerjan> . o O ( should software developers also be changed like diapers? )
01:48:14 * oerjan gets a deja vu about ais523's last anecdote
01:48:29 <b_jonas> oerjan: do you mean changed that frequently, or changed when they stink, or treated as identical throwaway ones?
01:48:54 <keegan> Go is a notable exception
01:49:01 <oerjan> well for politicians, ALL OF THE ABOVE obviously
01:49:47 <keegan> also Rust makes it pretty easy to use a statically linked musl instead of system libc
01:50:08 <ais523> huh, I just realised that I don't know how stdbuf worked
01:50:26 <ais523> I assumed it did something to the file handle at the OS level, but that doesn't make sense because stdio buffering is a libc thing, not an OS thing
01:50:50 <oerjan> for developers, i may not have been entirely serious.
01:51:24 <keegan> huh i didn't know about stdbuf until just now
01:51:27 <ais523> I just looked at the source: it's an LD_PRELOAD trick
01:51:38 <ais523> so presumably it's replacing parts of stdio
01:51:50 <keegan> either shim the libc functions or just insert some code which calls whatever libc functions set the buffer mode
01:52:20 <keegan> NOTE: If COMMAND adjusts the buffering of its standard streams ('tee' does for example) then that will override corresponding changes by 'stdbuf'. Also some filters (like 'dd' and 'cat' etc.) don't use streams for I/O, and are thus unaffected by 'stdbuf' settings.
01:52:59 <b_jonas> I hadn't heard of stdbuf until today
01:53:29 <b_jonas> why isn't that done with libc supporting it directly somehow so that stdbuf just has to pass it the information somewhere?
01:54:02 <ais523> with some sorts of input and output filehandles, pv doesn't actually do any reading and writing at all, just tells the kernel to move information around internally and counts how much information moved
01:54:34 <ais523> b_jonas: would have to be an environment variable, I think, and having lots of undocumented environment variables is a security risk
01:54:37 <ais523> pv measures the speed of a pipe
01:54:50 <ais523> like, counts the bytes going through
01:55:13 <ais523> basically cat with a progress bar
01:57:47 <b_jonas> ais523: that's true, though LD_PRELOAD env-var is documented in ld.so(8), TERMINFO_DIRS is docuemnted in terminfo(5), LOCPATH is documented in locale(7), and all those are security risks.
01:58:09 <b_jonas> I wonder if there is some better way to pass that information for stdbuf that is less of a security risk
01:58:26 <b_jonas> but I'm not sure what it could be
01:59:23 <ais523> I think it'd have to be some sort of fcntl that only existed for stdio's benefit
01:59:29 <ais523> a "suggested buffering behaviour" or such
01:59:34 <b_jonas> I don't think there's a way to create a kernel level file description that behaves like a normal one in general but has some auxiliary information that the child can extract.
01:59:51 <b_jonas> or more likely a general one to attach hints
02:01:16 <zzo38> I had before had a few different ideas which can be used for this
02:01:23 <zzo38> (other uses are also possible)
02:01:41 <b_jonas> I guess you could use a lopp device, that can wrap some existing file descriptors, though perhaps not all types that are readable or writable
02:02:22 <ais523> that couldn't remove buffering, only add it (unless stdio knew that writes to that sort of loop device shouldn't be buffered)
02:02:24 <b_jonas> except I think that's super-user only
02:02:39 <b_jonas> ais523: no, I mean you could more easily attach hint information to that
02:02:56 <b_jonas> and since it's a device, it will be unbuffered by default
02:03:16 <b_jonas> is that only char devices, not block devices?
02:03:53 <ais523> the problem with using devices for this is that they need device numbers, which are in limited supply
02:04:22 <ais523> also I thought it was specifically ttys that had weird buffering behaviour, but even then, writes to ttys are line-buffered by stdio
02:04:58 <zzo38> One idea might be if the C library would read a environment variable and set them (unless overridden), but then the C library must be written to take advantage of that. There is also the case of file descriptors; possibly allowing file descriptors to be attached somehow (and for this attachment to be visible in /proc)
02:05:10 <b_jonas> not even that. libc docs says "Newly opened streams are normally fully buffered, with one exception: initially line buffered."
02:05:31 <b_jonas> ais523: yes, specifically terminal devices
02:07:27 <b_jonas> well this stdbuf is an esoteric hack I guess, one that you hopefully don't need because programs where you may want to change the buffering have that built-in as an option
02:09:29 <keegan> it's a handy hack to know
02:09:42 <keegan> now i'm wondering if it could generalize to some 'run these libc calls before main()' type of wrapper
02:09:47 <keegan> which could actually probably be a gdb script
02:10:38 <zzo38> Free Hero Mesh does flush or disable buffering in some cases in order to allow ts to be used to time parts of the program.
02:10:49 <b_jonas> btw I dreamt of a kernel feature where there's a Linux namespace such that different namespaces can have different wall clocks, differing not just in the timezone (which is mainly a user-space thing and can already be overridden with an env-var) but different offset and speed correction and even different idea of which months have leap seconds. this would probably be more esoteric than useful.
02:11:08 <b_jonas> there is an old libc hack to try to convince a process that the time is what you say it is
02:11:21 <keegan> was this from an actual dream
02:11:29 <b_jonas> keegan: more like a daydream
02:11:38 <b_jonas> but it's so old that I think it predates clock_gettime
02:12:06 <ais523> this would be useful for running programs reproducibly
02:12:19 <zzo38> I think I saw once a program that can do that, and I think that the system emulation interface should be designed to allow this including stealthy.
02:12:22 <b_jonas> ais523: perhaps, but it's not really enough for that
02:12:22 <ais523> although I think leap seconds are mostly handled in userspace?
02:12:46 <b_jonas> ais523: yes, I think they're handled by the same daemon that synchronizes time to NTP
02:13:08 <b_jonas> I don't think the kernel knows about them
02:14:14 <b_jonas> running programs reproducibly is really hard these days if you want any kind of performance
02:15:00 <b_jonas> because the CPU itself doesn't aim to run things completely reproducibly
02:15:12 <zzo38> Swiss Ephemeris has its own handling of leap seconds (since it is necessary to know about past and future leap seconds), in order to convert between UTC and ephemeris time
02:15:39 <zzo38> It is something I thought of, design the CPU instruction set with the idea that you can run programs completely reproducibly
02:17:19 <b_jonas> zzo38: perhaps a CPU could provide such a mode, but it's not easy
02:17:27 <ais523> I think on modern x86, the vast majority of commands are intended to be reproducible in register/memory effect, if not timing
02:17:43 <ais523> and most of the others have options to disable them or emulate in software
02:18:00 <ais523> the main lack of reproducibility comes to things like the sequence in which multiple threads are interleaved
02:19:13 <b_jonas> ais523: perhaps, but there are all sorts of ways to leak informaton about caching and timing and speculation, some of them deliberately intended for measuring performance and microoptimzing your code, some just incidentally exposing something like the software transactional memory instructions which are used to implement mutexes and the like, and you can just ask for the time or randomness deliberately
02:20:04 <b_jonas> and the OS not being reproducible adds to that cake, because a program can tell if a page is swapped in or not if it wants to
02:21:27 <ais523> RDTSC and RDRAND can both be switched off I think
02:21:44 <ais523> and most (but probably not all) of the side-channels come down to timing
02:24:18 <zzo38> Including fake timing if needed, and designing the rest of the system to support this too, including the BIOS. Also excluding much of the complexity of modern systems, such as out of order execution, automatic caching, etc
02:24:31 <b_jonas> I did sort of wonder what it would take to make an interpreter that aims to be reproducible, even on different hardware, slower than native code but still performant enough. Mostly for the purpose of being able to run user-submitted code like bfjoust and get a deterministic result. The hard part is that need to decide when the code is terminated with a timeout, reproducibly and without overhead, without
02:24:36 <b_jonas> assuming that every single memory access has to go to the main memory without caches.
02:25:45 <b_jonas> ais523: can the OS disable software transactional memory? all debugging and peformance thingies? checking what pages are swapped in is fixable if you don't allow swapping any of the pages I guess.
02:26:31 <ais523> performance counters and debugging variables can definitely be made inaccessible from userspace (in fact, I think they are by default, and gdb has to ask the kernel to set the debugging variables for it)
02:27:12 <ais523> software transactional memory, I'm not sure on, IIRC the current Intel implementation is buggy anyway and so it gets switched off entirely in BIOS or microcode or somewhere like that
02:27:19 <ais523> (not sure if they've fixed it yet)
02:28:30 <ais523> zzo38: out of order execution is interesting, in that it's in theory possible to write programs to not need it simply by reordering the commands, but modern processors pretty much have to implement it so that compilers don't need to generate specific code for every processor model
02:29:13 <b_jonas> ais523: what do you do with detecting what's in the various code caches using ill-advised self-modifying code?
02:29:16 <ais523> as for caching, processors would probably be faster with manual caching in many cases
02:29:18 <b_jonas> oh wait, that might not work
02:29:28 <ais523> b_jonas: that causes a machine nuke nowadays if you try to do it
02:29:32 <ais523> very slow, but deterministic
02:29:58 <b_jonas> yeah, on x86 it's probably deterministic enough
02:30:03 <ais523> (where by "very slow" I mean tens of processor cycles, plus however long it takes to re-fetch the code from memory, so not all that slow in an absolute sense)
02:30:14 <b_jonas> (at least for things that you can do in userspace)
02:31:15 <b_jonas> interesting, this makes it sound less hopeless than I thought
02:31:21 <ais523> I don't know whether verr/verw (the "check which pages are swapped in" commands) are disabled
02:31:39 <b_jonas> ais523: you can just disable caching for that
02:31:41 <ais523> they are used very rarely, tohugh
02:32:03 <ais523> also, swapping is under kernel control (not processor control), so you could just swap deterministically if you wanted to
02:32:13 <ais523> you can actually disable caching
02:32:17 <ais523> you probably shouldn't, but it's *possible*
02:32:25 <b_jonas> yes, but here I meant disable swapping
02:33:08 <ais523> one thing that is missing in the x86 instruction set is a way to tell it "I'm no longer using this memory and don't care if you put arbitrary data in it"
02:33:24 <ais523> this would be useful to let it know that it doesn't have to write its caches back to memory
02:33:40 <ais523> (although it would provide side-channel opportunities)
02:34:03 <ais523> I guess there's INVD but that affects all memory on the entire system, which isn't the most useful operation :-D
02:34:12 <ais523> (and it's ring 0 for obvious reasons)
02:35:34 -!- delta23 has quit (Quit: Leaving).
02:35:50 <b_jonas> that doesn't seem like a thing you'd often want to do
02:35:58 <b_jonas> I mean for all memory in the system
02:36:07 <b_jonas> for a specific cache line it would be useful
02:39:26 <ais523> it doesn't seem useful to me either
02:41:01 <b_jonas> there is a way to disable RDTSC, but can you disable RDRAND or RDSEED in a sane way?
02:42:13 <b_jonas> there's probably some insane way to disable it, intended only for debugging or performance monitoring or virtual machines or reflushing the BIOS
02:42:33 <ais523> "rdrand" doesn't appear anywhere in the documentation of the various processor bits that can be messed with by the OS
02:42:46 <ais523> although, this is some fairly old docs I'm looking at
02:42:52 <ais523> (I grepped it, didn't search manually)
02:44:43 <b_jonas> presumably you'd also have to make sure the program isn't interrupted by signals in a nondeterministic way, and terminated on some fatal conditions like segfaults
02:45:07 <ais523> signals generated by the processor are very, very deterministic on x86
02:45:24 <ais523> to the extent that it's documented which order they get delivered in if multiple signals are generated simultaneously
02:45:27 <b_jonas> and even then I wonder if there might be detectable side-effects from hardware interrupts that aren't related to the process at all
02:45:51 <ais523> hardware interrupts relative to software execution are a lot less deterministic, obviously
02:46:06 <b_jonas> ais523: yes, but only if the signals are triggered at exactly the same time, which you can't do if you want to allow the underlying process to have varying timing
02:47:36 <ais523> well, it matters if they're triggered by the same instruction
02:48:18 <ais523> a common example is simultaneous page fault and general protection fault, if a userspace program tries to use a kernelspace command on memory it can't access
02:48:30 <ais523> well, not common, I doubt that happens in practice very often
02:48:40 <b_jonas> hmm, maybe that's not too serious and they don't have detectable side effects in your user program if you're careful
02:48:41 <ais523> but common in that it doesn't take much setup and there are lots of ways to do it
03:02:53 <zzo38> I didn't like there are too many functions for making new file descriptors, and I would remove most of them; for many cases openat can be used, and sometimes newfd. (This simplifies overriding them or recording the used file descriptors, and other things too)
03:09:42 <ais523> what is newfd? I don't have a manual page for it
03:10:17 <ais523> at least there isn't a creatat (openat can do the same thing)
03:19:47 <zzo38> It is my own idea; it causes the next file descriptor to use the specified number (even if it is already in use) instead of assigning one automatically
04:14:49 <ais523> I don't think that's thread-safe, because another thread might open an FD in between the newfd and openat calls
04:15:28 <ais523> maybe the desired FD number should be an argument to openat?
04:15:47 <ais523> (alternatively, you could go the other way, where FD numbers don't follow any pattern at all and are arbitrary; this is what WebAssembly does)
04:27:33 <shachaf> That seems like a good way to me.
04:27:46 <shachaf> It's what Windows does, I guess. How does Windows handle standard descriptors like stdout?
04:44:03 -!- oerjan has quit (Quit: Nite).
04:44:57 <zzo38> I think being able to override specific existing file descriptors is useful. Although, making it a argument of openat (and -1 meaning automatic) will work too.
04:44:59 <pikhq> the libc file descriptor layer maps the stdin, stdout, and stderr file handles (which can be retrieved from GetStdHandle()) to file descriptors 0, 1, and 2
04:45:29 -!- citrons has joined.
04:45:37 -!- fungot has quit (*.net *.split).
04:45:37 -!- citrons_ has quit (*.net *.split).
04:45:43 <pikhq> (since on Windows, file descriptors aren't an OS-level feature at all, they're just an API that libc implements on top of the Win32 API)
04:46:17 <shachaf> Sure, I didn't mean file descriptors, I meant how you get the handle to stdout at all.
04:46:40 <shachaf> I guess GetCurrentProcess is similarly a way to get a handle to the current process.
04:46:57 <shachaf> So you just have known calls that get handles. That seems fine.
04:47:17 <shachaf> It probably makes sense to have handles be arbitrary, and then have special ways to get special ones.
04:47:48 <pikhq> it is the typical windows thing -- rather than having fixed constants or parameters to main or globals or something, you've got functions that retrieve opaque handles you can operate on
04:48:13 <pikhq> to be entirely fair, while it is weird to me coming from a unix mindset, it is not at all an unreasonable way of doing things
04:48:16 <shachaf> You could also have a known region of memory.
04:48:27 <shachaf> It's like auxvals in Linux for instance.
04:48:41 <shachaf> You could imagine having the file descriptors for in/out/err stored there.
04:48:49 <pikhq> i also think those are weird :p
04:48:50 -!- zzo38 has quit (*.net *.split).
04:48:50 -!- Riviera has quit (*.net *.split).
04:48:58 -!- Riviera_ has joined.
04:49:29 -!- zzo38 has joined.
04:51:07 <pikhq> auxvals as a concept, yeah. it's just a slightly odd additional mechanism, although i understand exactly why you'd do it
04:53:25 <zzo38> I think probably the requested number (or -1) as the argument of openat is probably good. Also you can have POSIX compatibility (in the C standard library) in this way, and can make new specific numbes if you need that for some reason passing between programs, too. (Maybe it could also be usable for argv and envp too; I don't know)
04:53:53 <pikhq> the thing that makes auxvals kinda weird (at least to me) is that they aren't parameters to main() but they are parameters to _start
04:54:29 <shachaf> Oh, well, main is a nonsense lie.
04:54:49 <shachaf> I did say Linux, so the ABI I have in mind is the one the kernel sets up.
04:55:03 <pikhq> i know that main isn't the actual entry point, but it is the actual API contract :P
04:55:20 <pikhq> although to be sure the ELF entry point is also a hard API contract
04:55:34 <shachaf> Statically linked programs are where it's at.
04:56:06 <shachaf> main is a libc API, and I'm not a big fan of libc.
04:56:10 <pikhq> (and even a portable one! this isn't Linux-specific, it's an ELF thing!)
04:57:16 <pikhq> it is but you're gonna have a hard time using any external libraries without libc (and writing to the raw Linux syscall interface has some really counterintuitive edge cases if you're more familiar with POSIX semantics)
04:58:04 <pikhq> of course, if you actually are static linked, you are probably in sufficient control of what you depend on that you can just... not worry about that
04:58:56 <shachaf> The only external libraries I'm worried about are things like OpenGL where you have no choice but to use libc.
04:59:49 <shachaf> For the most part the raw Linux interface seems much better and more usable than the libc interface.
04:59:57 <pikhq> yeah that's the main example where it's a necessity rather than convenience
05:00:53 <shachaf> For example: ptrace(PTRACE_PEEKDATA) (and getpriority/nice)
05:01:10 <shachaf> ppoll's remaining timeout return value
05:01:31 <shachaf> glibc used to *emulate* ppoll in userspace when the system call failed with ENOSYS, defeating the entire purpose of using ppoll.
05:01:55 <shachaf> The waitid() system call has a fifth argument but glibc hides it for no reason and makes you use deprecated calls to get at it.
05:02:27 <shachaf> The whole errno deal, of course.
05:02:46 <pikhq> and then there's setuid. POSIX setuid sets the effective uid of the process. Linux setuid sets the effective uid of the thread, and now you have different privileges coexisting in your process
05:03:07 <shachaf> pthread_create probably wins over doing it yourself with clone, which is admittedly pretty awkward.
05:05:16 <shachaf> I imagine almost all cases of setuid are single-threaded anyway.
05:05:35 <shachaf> But that's good to know. Looking at musl, it just kills the current process if it fails to setuid on all threads.
05:33:02 <ais523> 99% of the uses of setuid are dropping permissions, rather than raising them
05:33:22 <ais523> and I think it's plausible to want to drop permissions on some threads and not others, although it might make it hard for them to communicate with each other
05:34:34 <ais523> (although, there are probably better permission models than the UNIX model)
05:43:54 -!- ais523 has quit (Quit: quit).
05:56:09 <zzo38> Which pokemon rule options are missing/wrong? http://zzo38computer.org/misc/option.html
05:57:06 -!- PinealGlandOptic has joined.
06:09:44 -!- mnrmnaugh has joined.
06:11:54 -!- mnrmnaugh has quit (Client Quit).
06:44:14 -!- imode has quit (Ping timeout: 250 seconds).
06:45:56 -!- op_4 has quit (Ping timeout: 252 seconds).
06:48:04 -!- immibis has joined.
06:55:56 -!- Sgeo has quit (Ping timeout: 268 seconds).
08:05:46 -!- hendursa1 has joined.
08:08:56 -!- hendursaga has quit (Ping timeout: 244 seconds).
10:00:24 <esolangs> [[4BOD]] https://esolangs.org/w/index.php?diff=87541&oldid=85372 * WallGraffiti * (+100)
10:02:27 <esolangs> [[4BOD]] M https://esolangs.org/w/index.php?diff=87542&oldid=87541 * WallGraffiti * (+42)
10:18:57 -!- arseniiv has joined.
10:35:27 -!- wib_jonas has joined.
10:37:41 <wib_jonas> "<ais523> I think libc should be split into two parts" => the problem is that libc has to be compatible with its old versions for a very long time, so it gathers lots of historical cruft that obviously shouldn't be there but we can't just remove it now
10:38:01 <wib_jonas> so some of what is and isn't in libc is partly accidental
10:39:03 <wib_jonas> and as for libc buffering of file handles, some programming language standard libraries actually reimplement it, rather than just forward the C thing.
10:40:39 <wib_jonas> the guaranteed sequential file descriptors in unix is also something we can't do much about. we can add a flag like O_CLOEXEC where the process tells the kernel that it doesn't require sequential file descriptor number, but we can't change the existing ABI\
10:42:41 <wib_jonas> zzo38: as for more explicit control of memory caching, one thing I was wondering is if a CPU or virtual machine specialized on this could have, instead of a single eight-way L1D cache, a separate one-way L1D cache per index register, and every reference to data memory would use the L1D cache associated with the index register that is the base of
10:42:41 <wib_jonas> the memory address, at least by default
10:43:47 <wib_jonas> of course the problem then is what happens when you try to write a memory address through multiple index registers
10:46:43 <river> I wonder why we need things like libc to be compatable
10:46:55 <river> all software is being constantly "maintained"
10:47:44 <river> so if libc changed they could just sort problems that come up, they probably wouldn't even notice a difference from normal maintanance
10:48:47 <myname> "all software is being constantly maintained" hahahahahahaha
10:49:09 -!- PinealGlandOptic has quit (Quit: leaving).
10:57:49 <myname> i am actively using a software that is abandoned for 6 years now
11:01:13 <int-e> is it Windows 7 ;-)
12:13:49 <nakilon> no way, linux is maintained by paid employees of a Linux megacorporation in the Silicon Valley; oh wait...
12:14:50 <nakilon> btw, want to share two news about videogames
12:15:02 <nakilon> 1. OpenTTD is now in Steam
12:15:20 <nakilon> 2. Stray - Official Gameplay & Release Window Trailer https://www.youtube.com/watch?v=P4l6uWxe-vk
12:17:34 <wib_jonas> nakilon: OpenTTD is also in Debian, which just released a new major release, so you get a reasonably up to date version of OpenTTD if you install from there. or you can just download a binary from https://www.openttd.org/downloads/openttd-releases/latest.html
12:18:41 <nakilon> looks liek it's even here https://formulae.brew.sh/formula/openttd
12:19:16 <wib_jonas> I have compiled the openttd executable from source, so I know that works, but that was many years ago
12:22:45 <nakilon> steam is handy -- you can see what your friends are playing and jump into multiplayer with them without leaving the game and registering more accounts around the web
12:23:51 <nakilon> also a handy way to save and share game screenshots
12:23:53 <Melvar> <ais523> at a previous job, my boss asked me why his Haskell program was getting affected by libc buffering when it wasn't written in C – Probably it wasn’t, but everything does buffering because not buffering performs badly *except* for terminal interaction. Furthermore, ttys themselves distinguish raw (unbuffered) and cooked (line-buffered) mode for input only, so everything has to have
12:23:55 <Melvar> those three buffering modes on at least certain handles.
12:27:07 <Melvar> Regarding the whole discussion of processor determinism, I was reminded of https://queue.acm.org/detail.cfm?id=3212479 (“Your computer is not a fast PDP-11”).
12:28:22 <Melvar> <zzo38> I think being able to override specific existing file descriptors is useful. – That’s what dup2/dup3 is for, isn’t it?
12:40:58 <fizzie> Hey, that's that cat game.
12:47:19 <fizzie> (Stray, I mean; I don't think OpenTTD has any cats. You probably couldn't really see them, the scale it's at.)
12:49:40 -!- hendursa1 has quit (Quit: hendursa1).
12:50:18 -!- hendursaga has joined.
13:05:47 <nakilon> I wonder if some moments in that trailer are scripted or not
13:06:10 <nakilon> such as when dude goes backward into a room and bumps into another one
13:09:20 <myname> nakilon: i said linux software, not the kernel
13:10:28 <myname> not every oss project in existence is maintained by the linux foundation
13:22:09 -!- impomatic has joined.
13:38:11 <wib_jonas> how much category theory does fungot know? did he pick some up on the channel when you prepared all those models
13:41:36 <river> fungot: know category theory?
13:48:03 <lambdabot> I saw fungot leaving #esolangs 9h 2m 25s ago.
13:48:03 <wib_jonas> missing because of the pandemic probably
13:49:14 <int-e> fizzie: libera rebooted two servers around that time, maybe fungot was on one of those
13:49:24 -!- fungot has joined.
13:50:10 <fizzie> Yep. This time it had reconnected, but not rejoined because it doesn't know how to.
13:54:35 <shachaf> int-e: Wait, @seen is back?
13:54:44 <shachaf> Wasn't it broken for a decade or two?
13:56:15 <int-e> shachaf: I had it disabled for a long time because it caused lambdabot to use noticably more memory, possibly leaking memory as well (though I never quite proved that)
13:56:18 <HackEso> seen(1hackeso) - no description
13:56:47 <int-e> it made the difference between it becoming unresponsive and needing a restart every week and it being stable for basically forever, subject to network troubles
13:57:32 <int-e> I fixed some shortcomings but mostly it's on a larger VM now where this is less of an issue.
14:00:52 -!- impomatic has quit (Quit: impomatic).
14:01:14 -!- impomatic has joined.
14:05:23 -!- impomatic has quit (Client Quit).
14:05:46 -!- impomatic has joined.
14:10:36 <wib_jonas> int-e: like stalker mode for fizzie?
14:18:59 -!- Sgeo has joined.
14:20:52 -!- impomatic has quit (Quit: impomatic).
14:21:14 -!- impomatic has joined.
14:25:32 -!- impomatic has quit (Client Quit).
14:25:53 -!- impomatic has joined.
14:32:13 -!- imode has joined.
14:35:52 -!- impomatic has quit (Quit: impomatic).
14:36:12 -!- impomatic has joined.
14:40:23 -!- impomatic has quit (Client Quit).
14:40:45 -!- impomatic has joined.
14:41:24 <Noisytoot> wib_jonas, OpenTTD is also packaged in GNU Guix and probably many other distributions
14:59:29 <myname> even nixos has a package for it
15:00:38 <myname> guix reads pretty similar to nixos
15:01:33 <Corbin> Is that surprising? nixpkgs is basically the biggest public ports tree, although I'd love to learn of bigger ones.
15:02:20 <Corbin> https://repology.org/graph/map_repo_size_fresh.svg I still love this plot. Comparison of various distros and ports trees based on number of packages and number of "fresh" up-to-date packages.
15:08:16 <wib_jonas> Corbin: only in the sense that the tireless contributors to OpenTTD managed to replace the original graphics from TTD and provide free graphics, so it's now free software enough even for Debian's standards, unlike the early versions.
15:14:13 <Corbin> wib_jonas: Oh, that makes sense. Congratulations to them; it must have been a lot of work.
15:20:52 -!- impomatic has quit (Quit: impomatic).
15:21:13 -!- impomatic has joined.
15:25:23 -!- impomatic has quit (Client Quit).
15:25:43 -!- impomatic has joined.
15:41:16 -!- Koen_ has joined.
15:45:32 -!- impomatic has quit (Quit: impomatic).
15:57:09 -!- impomatic has joined.
16:01:29 -!- impomatic has quit (Client Quit).
16:01:46 -!- impomatic has joined.
16:06:30 -!- wib_jonas has quit (Quit: Client closed).
16:21:56 -!- impomatic has quit (Quit: impomatic).
16:22:17 -!- impomatic has joined.
16:26:27 -!- impomatic has quit (Client Quit).
16:26:47 -!- impomatic has joined.
16:36:56 -!- impomatic has quit (Quit: impomatic).
16:37:16 -!- impomatic has joined.
16:41:28 -!- impomatic has quit (Client Quit).
16:41:48 -!- impomatic has joined.
16:51:56 -!- impomatic has quit (Quit: impomatic).
16:52:18 -!- impomatic has joined.
16:56:27 -!- impomatic has quit (Client Quit).
16:56:48 -!- impomatic has joined.
17:01:56 -!- impomatic has quit (Quit: impomatic).
17:02:18 -!- impomatic has joined.
17:06:27 -!- impomatic has quit (Client Quit).
17:06:48 -!- impomatic has joined.
17:14:02 <esolangs> [[Special:Log/upload]] upload * Jdonszelmann * uploaded "[[File:Collatz.png]]"
17:14:58 -!- Trieste has quit (Ping timeout: 240 seconds).
17:15:42 -!- Trieste has joined.
17:17:14 <esolangs> [[TRAIN!]] N https://esolangs.org/w/index.php?oldid=87544 * Jdonszelmann * (+8291) TRAIN! is a programming language centered about trains moving passengers with data around stations which apply operations.
17:18:11 <esolangs> [[TRAIN!]] https://esolangs.org/w/index.php?diff=87545&oldid=87544 * Jdonszelmann * (-5)
17:21:11 <esolangs> [[TRAIN!]] M https://esolangs.org/w/index.php?diff=87546&oldid=87545 * Jdonszelmann * (-10)
18:06:56 -!- impomatic has quit (Quit: impomatic).
18:07:17 -!- impomatic has joined.
18:11:27 -!- impomatic has quit (Client Quit).
18:11:50 -!- impomatic has joined.
18:47:46 <esolangs> [[Mogus]] N https://esolangs.org/w/index.php?oldid=87547 * VilgotanL * (+1201) mogus
18:48:49 <esolangs> [[Mogus]] M https://esolangs.org/w/index.php?diff=87548&oldid=87547 * VilgotanL * (+1) fix minor bug
18:53:17 <esolangs> [[Mogus]] M https://esolangs.org/w/index.php?diff=87549&oldid=87548 * VilgotanL * (+158)
18:53:34 <esolangs> [[Mogus]] M https://esolangs.org/w/index.php?diff=87550&oldid=87549 * VilgotanL * (+6)
18:57:55 <esolangs> [[Mogus]] M https://esolangs.org/w/index.php?diff=87551&oldid=87550 * VilgotanL * (+226)
18:58:17 -!- sknebel has quit (Remote host closed the connection).
18:59:32 -!- sknebel has joined.
19:12:07 -!- arseniiv has quit (Ping timeout: 240 seconds).
19:20:38 <esolangs> [[Malfunge]] N https://esolangs.org/w/index.php?oldid=87552 * ArthroStar11 * (+2607) created page and provided link to my interpreter
19:22:02 <esolangs> [[Language list]] M https://esolangs.org/w/index.php?diff=87553&oldid=87538 * ArthroStar11 * (+15) Added my language "Malfunge"
19:23:30 <esolangs> [[User:ArthroStar11]] https://esolangs.org/w/index.php?diff=87554&oldid=86412 * ArthroStar11 * (+131)
19:24:26 <esolangs> [[Malfunge]] M https://esolangs.org/w/index.php?diff=87555&oldid=87552 * ArthroStar11 * (+25) remembered to add "Implemented" category
19:26:17 <esolangs> [[Geolang]] N https://esolangs.org/w/index.php?oldid=87556 * TJC games * (+538) Created page with "Geolang is a programming language made by [[user:TJC games|TJC games]] for helping with geometry. Who am I kidding, it is a stupid language made by a stupid person. ==Usage==..."
19:43:16 -!- Lord_of_Life_ has joined.
19:44:14 -!- Lord_of_Life has quit (Ping timeout: 250 seconds).
19:44:33 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
19:53:05 -!- impomatic_ has joined.
19:55:07 -!- impomatic has quit (Ping timeout: 240 seconds).
19:55:07 -!- impomatic_ has changed nick to impomatic.
19:56:27 -!- impomatic has quit (Client Quit).
19:56:47 -!- impomatic has joined.
19:59:02 <esolangs> [[User:Oshaboy]] https://esolangs.org/w/index.php?diff=87557&oldid=83461 * Oshaboy * (+508)
20:24:01 -!- impomatic has quit (Quit: impomatic).
20:56:33 <esolangs> [[Malfunge]] M https://esolangs.org/w/index.php?diff=87558&oldid=87555 * PythonshellDebugwindow * (+39) /* Implementation */ cAt
21:06:41 <esolangs> [[Sophie]] M https://esolangs.org/w/index.php?diff=87559&oldid=85358 * Oshaboy * (+0) typo
21:11:00 -!- user3456 has quit (Ping timeout: 272 seconds).
21:11:47 -!- user3456 has joined.
21:23:02 <esolangs> [[Truthlang]] N https://esolangs.org/w/index.php?oldid=87560 * Oshaboy * (+779) Initial
21:23:31 <esolangs> [[User:Oshaboy]] https://esolangs.org/w/index.php?diff=87561&oldid=87557 * Oshaboy * (+37) Added Truthlang
21:27:11 <esolangs> [[Truthlang]] https://esolangs.org/w/index.php?diff=87562&oldid=87560 * Oshaboy * (+50) I just realized an interpreter would be a Truth Machine.
21:29:44 <esolangs> [[Truthlang]] https://esolangs.org/w/index.php?diff=87563&oldid=87562 * Oshaboy * (-50) Undo revision 87562 by [[Special:Contributions/Oshaboy|Oshaboy]] ([[User talk:Oshaboy|talk]])
21:30:54 <esolangs> [[Truthlang]] https://esolangs.org/w/index.php?diff=87564&oldid=87563 * Oshaboy * (+93) Truth Machines aren't Truthlang Interpreters
21:32:52 <esolangs> [[Truthlang]] https://esolangs.org/w/index.php?diff=87565&oldid=87564 * Oshaboy * (+29) /* Overview */
21:39:02 -!- Koen_ has quit (Quit: Leaving...).
21:45:00 <esolangs> [[Malfunge]] M https://esolangs.org/w/index.php?diff=87566&oldid=87558 * ArthroStar11 * (+150) Put in size of playfield. Sorry, it was a big project with a complex specification, I'm not trying to spam.
22:19:54 <esolangs> [[Scroll]] https://esolangs.org/w/index.php?diff=87567&oldid=87436 * WreckingGames * (+1)
22:21:23 <esolangs> [[Scroll]] M https://esolangs.org/w/index.php?diff=87568&oldid=87567 * WreckingGames * (+1)
22:28:40 -!- immibis has quit (Ping timeout: 240 seconds).
23:15:26 -!- oerjan has joined.
23:55:31 <esolangs> [[Hello world program in esoteric languages]] https://esolangs.org/w/index.php?diff=87569&oldid=84431 * Oerjan * (+147) Temporary fix for the edit blocking people are experiencing
23:57:14 -!- ais523 has joined.
23:57:28 <ais523> it's unclear what the correct solution for the hello world page is
23:57:55 <ais523> your temporary solution's a nice one to unblock things, but I'm not sure what the "correct" solution is
23:58:24 <ais523> maybe we need some sort of dedicated hello world browser
23:58:53 <oerjan> yeah if we want people to be able to see everything on one page it may be awkward.
23:59:36 <ais523> perhaps splitting it up into 27 pages (one for each English letter and one for the languages whose names start with something else)?