00:02:46 <b_jonas> zzo38: yes, but where's the rule that says you can't cast a land?
00:03:02 <b_jonas> it looks like there's none, though this may get fixed in the next update
00:08:53 <zzo38> Rule 305.9 says a land that is also another type can't be cast as a spell, but that doesn't say if it is only one. That seems to be a mistake, but I suppose that for now, it would seem to be allowed even if it isn't supposed to be allowed.
00:17:31 -!- ais523 has quit (Read error: Connection reset by peer).
00:18:09 -!- ais523 has joined.
00:19:18 <ais523> if you have a card with no types, can you cast it?
00:19:27 <ais523> (assuming it's in your hand and has a mana cost)
00:20:34 <ais523> bear in mind that I'm not convinced the situation can ever arise, but the situation of casting a land on the back of an MDFC seems comparable (except that it doesn't have a mana cost, so you'd need Omniscience or the like)
00:25:53 <b_jonas> ais523: I don't think there's a way to have a card with no types outside the battlefield
00:26:52 <b_jonas> but the rules are weird about that, if you could get to cast such a thing, it would not enter the battlefield, because it wouldn't count as a permanent spell, it would try to resolve like a sorcery but not quite count as a sorcery in all respects
00:27:45 <b_jonas> ais523: but I don't think there's anything to stop you from casting it from your hand if it has a mana cost
00:28:02 <zzo38> The rules say a object with instant or sorcery type cannot enter the battlefield, but I don't know about other ones
00:29:01 <b_jonas> I don't know what would happen
00:30:09 -!- tromp has joined.
00:30:09 <b_jonas> the relevant rule is 608.3, that's what moves the spell to the battlefield, but only if it's a "permanent spell", which is defined in 110.4b, which says "an artifact, creature, enchantment, or planeswalker spell"
00:31:48 <b_jonas> 608.2k says that an instant or sorcery spell moves to the owner's graveyard when it resolves, after it has done all the other steps for resolving
00:32:04 <b_jonas> and 608.2k also talks about resolving abilities
00:32:17 <b_jonas> combat damage on stack no longer exists
00:33:01 <b_jonas> there are of course some replacement abilities that can make a spell move to exile instead of the graveyard when resolving
00:33:42 <b_jonas> I can't find what happens with a typeless spell, so if there's no specific rule, it would remain on the stack and try to resolve again after everyone passes
00:34:02 <b_jonas> but I don't think this can happen in first place
00:35:01 -!- tromp has quit (Ping timeout: 244 seconds).
00:37:22 <zzo38> Yes, that would seem to be, although it isn't very good and I thought it might make more sense to unify the rules, to change them so that, in general: An resolving object's spell abilities are done first, and then it moves to the battlefield; if it doesn't, it moves to the graveyard; if it still doesn't, it is exiled; and if even then it still doesn't, it ceases to exist.
00:37:32 <ais523> the same thing would happen with a land spell, wouldn't it?
00:37:41 <ais523> instant draw, unless someone chooses to counterspell it
00:38:31 <zzo38> ais523: Yes, I think so, unless it is a land with another type, I suppose (although lands with other types cannot be cast anyways, due to 305.9, so it would have to change while on the stack)
00:38:39 <ais523> Netrunner fixes this problem by having playing events/operations (non-permanents), and installing hardware/programs/resources/ice/assets/upgrades/agenda (permanents), being two unrelated actions
00:39:29 <ais523> so there's never any problem about how to remove them from the play area after they resolve
00:40:01 <b_jonas> there also doesn't seem to be a rule specific for what happens with a copy of a spell if it's not a permanent spell, but the same rules as for a spell that's a card applies to them: if it's an instant or sorcery it goes to the graveyard (and later gets cleaned up), otherwise ?? but that's probably not possible
00:40:18 <b_jonas> because the type gets copied from the original spell
00:40:20 <ais523> (although, Netrunner also doesn't have counterspells in the traditional sense, to counter someone's install you destroy the thing they installed after it arrives)
00:40:43 <b_jonas> ais523: hmm. you have a point about the land spell
00:41:59 <zzo38> See a puzzle I made up some time ago, for another point of view about typeless cards outside of the battlefield (although you will not generally get a chance to cast them, nor will they get a chance to resolve, in the specific situation that I did)
00:42:36 <ais523> that said, Netrunner also doesn't have a problem with just leaving things in the play area, over multiple turns if necessary
00:43:10 <ais523> you can think of events/operations as having triggered abilities that trigger on them being played, causing them to resolve and be trashed
00:43:24 <ais523> if something goes wrong with the ability, they just kind-of sit there until something happens to them
00:43:41 <ais523> this wouldn't work in Magic, because you can counter triggered abilities there
00:43:48 <ais523> but it's a clever way to avoid having both spells and abilities on the stack
00:45:01 <ais523> and it's sometimes used to make operations that take multiple turns to resolve
00:45:30 <b_jonas> zzo38: well, I personally think the rule should be that if a spell isn't a sorcery or instant or conspiracy or emblem or plane or phenomenon or scheme or vanguard or contraption then it etb as it resolves.
00:46:41 <ais523> the really controversial option would be to have a unified list of subtypes (i.e. not needing tribal), and mark artifact and enchantment into permanent subtypes
00:46:48 <zzo38> b_jonas: The rule I suggested has the same effect that you mentioned I think anyways (although emblem isn't a type at all but a kind, and Contraption is a subtype)
00:46:56 <ais523> (land is more of a keyword ability, and creatures and planeswalkers have a lot of rules of their own)
00:46:59 <b_jonas> ais523: yes, but we want to have effects printed on cards that let you cast or play sorceries and creatures uniformly
00:47:12 <b_jonas> ais523: and keywords like suspend
00:47:19 <ais523> b_jonas: Netrunner has plentry of the former, they just say "play or install"
00:48:01 <zzo38> I think that a good way to fix it is with the unified rule I mentioned, together with fixing rule 305.9 so that it says that any object with the type "land" cannot be cast, rather than only saying if it has another type as well as land.
00:49:49 <ais523> and suspend in Netrunner would be worded as "Place 3 power counters on this event rather than trashing it as it resolves. Remove 1 counter at the start of your turn. When it has no counters, trash it and do X"
00:50:10 <ais523> (I don't think it'd be modal, Netrunner doesn't do modal effects very often, so it'd just have the suspend cost")
00:50:34 <ais523> actually that wouldn't work for suspend permanents, those would be awkward
00:50:56 <ais523> but also there wouldn't be much reason to not just have them installed normally and not do anything for a few turns, other than being counted
00:53:24 -!- FreeFull has quit.
00:54:30 <b_jonas> ais523: ok, but in M:tG it's not easy to make creatures "not do anything" for a few turns, because there used to be so many costs payed by sacrificing a creature
00:54:50 <zzo38> I suppose the other place to ask is rec.games.trading-cards.magic.rules but that newsgroup doesn't seem to be much in use.
00:55:18 <b_jonas> those work even if they're Arrested and Turned to Frog
00:56:44 <b_jonas> also I'm pointed to https://twitter.com/WotC_Matt/status/1310740942182178817 , where re a bug about a land getting cast as a spell, Matt Tabak says "You shouldn’t be able to play a land because the instruction is to cast. The team tells me this is known and a fix is coming soon." but "fix" refers to the Arena software, not the Comp Rules
00:57:08 <ais523> it wouldn't surprise me if the Arena programmers just read the rules and implemented them as written
00:57:38 <ais523> actually I suspect the reverse has happened in some cases, with cards that don't work within the rules being errata'ed based on the implementation on jinteki.net
00:57:42 <b_jonas> that said, Matt Tabak might look at the Comp Rules anyway, plus he already knows that there are problems with the basic rules for modal double-faced cards so he'll fix them,
00:57:53 <zzo38> They should fix the Comp Rules too, I should think. I have suggested before to actually write the rules as a literate computer program (perhaps inventing a programming language for that purpose), as that would make the rules more clearly.
00:58:28 <b_jonas> plus there will probably be more modal double-faced cards in near future sets, for which he'll look at the rules too
00:58:43 <b_jonas> so I'll just have to wait for the next update and then read what the rules say again
01:04:36 <b_jonas> lol! today's SMBC is great https://www.smbc-comics.com/comic/nudge
01:05:13 <b_jonas> that's a take on Allosaurus president plus asteroid defense mission that didn't come up in Irregular
01:08:24 <b_jonas> as for the xkcd, I was thinking about why the road traffic rules mention that the middle light of car traffic lights is amber colored. everyone else except the weird formal texts either calls it yellow, or calls it yellow but notes that it looks more like orange, but the rules and teaching material says amber. but I haven't heard anything else described as being amber colored. I have no other reference
01:08:30 <b_jonas> to amber color than those lights used as signals for road traffic.
01:12:39 -!- aaaaaa has quit (Quit: leaving).
01:29:52 -!- adu has joined.
01:42:20 -!- tromp has joined.
02:02:20 -!- adu has quit (Quit: adu).
02:15:57 -!- dcristofani has joined.
02:35:58 -!- dcristofani has quit (Ping timeout: 260 seconds).
02:51:02 -!- MDude has quit (Quit: Going offline, see ya! (www.adiirc.com)).
03:11:09 -!- adu has joined.
03:15:28 -!- Sgeo has quit (Read error: Connection reset by peer).
03:19:43 -!- Sgeo has joined.
03:24:15 <int-e> Oh there's a dprintf() for printing to fds, interesting.
03:26:16 <int-e> (in POSIX, since 2008)
03:31:11 -!- dcristofani has joined.
03:38:54 <shachaf> My formatting API lets you printf into a fixed-size buffer. It would be nice if sprintf did that.
03:39:18 <shachaf> As it is you can't implement fprintf in terms of sprintf or vice versa.
03:43:50 -!- deltaepsilon23 has joined.
03:48:57 <int-e> . o O ( fork off a thread and fprintf to a pipe )
03:51:08 <int-e> (But I get what you mean.)
03:52:01 -!- deltaepsilon23 has changed nick to deltadoge23.
03:59:48 <shachaf> https://shachaf.net/tmp/fmt/fmt.h
04:00:04 <shachaf> I think C varargs makes this pretty tricky for printf, though.
04:00:11 <int-e> I also still remember that you've worked on this.
04:00:25 <shachaf> Oh no, do I just post the same things in here over and over again?
04:01:16 <shachaf> Anyway, C varargs are invalidated as soon as the function returns, which makes it harder.
04:01:46 <shachaf> I guess you could scan over the format string once to copy the varargs values? But I'm not sure you'd want to.
04:03:32 <zzo38> There is fmemopen and open_memstream, and all of the printf variants return the length of the result, in case those things are needed.
04:04:22 <zzo38> Although there is that problem with varargs that you mention.
04:04:43 <shachaf> Yes, but that still needs you to have enough memory for the result at once, I suppose.
04:05:02 <int-e> shachaf: We all have our own little pet topics, I suppose.
04:05:28 <shachaf> musl libc uses a FILE * with a write callback argument for vfprintf.
04:06:21 <shachaf> Oh, maybe glibc does something similar.
04:06:32 <shachaf> int-e: I did change the API since last time I mentioned it, I think.
04:08:28 <int-e> Oh poking in FILE * interna, hmm.
04:09:18 <int-e> what a fun name...
04:09:36 <shachaf> Well, it's a GNU extension.
04:09:56 -!- ais523 has quit (Read error: Connection reset by peer).
04:10:02 -!- callforjudgement has joined.
04:10:39 <int-e> Yes, it is. And it's still a funny name.
04:12:20 <int-e> It's too bad that this isn't standardized so you get reimplementations like https://wiki.openssl.org/index.php/BIO
04:12:35 <int-e> where nothing ever fits with anything else
04:15:05 <shachaf> It's too bad libc mixes "language" convenience things (that maybe ought to just be a regular library statically linked into your program) with "OS" things.
04:28:30 -!- dcristofani has quit (Ping timeout: 272 seconds).
04:33:53 <int-e> shachaf: I guess you wouldn't really like fopencookie anyway... because it allocates from the heap.
04:34:11 <shachaf> Do I hate all heap allocations?
04:34:39 <shachaf> When you're interacting with libc things like FILE * functions it seems too far gone to worry about things like that.
04:34:44 <int-e> Not quite, just the not strictly necessary ones.
04:34:50 <shachaf> It probably calls malloc 20 times before breakfast.
04:38:39 <int-e> but it leads to things like FILE *f = fopencookie(s, "a", cb); if (!f) { errno = ENOMEM; return -1; }
04:39:01 <shachaf> Oh, sure, that seems annoying.
04:40:18 <shachaf> Certainly it seems entirely gratuitous when an API makes you do that many times for no reason, like posix_spawn.
04:42:48 <int-e> Oh well. It seems to work... https://paste.debian.net/1167655/
04:43:17 <shachaf> Good thing malloc failures never happen.
04:43:42 <int-e> that's an entirely different pet peeve :P
04:44:24 <zzo38> I often use a macro to check for memory allocation errors
04:44:37 <shachaf> Of course, if you're OK with GNU extensions + allocation, you could use asprintf.
04:44:40 <int-e> But whatever, I need some fresh air, and then I can figure out how to wrap up this toy program.
04:45:06 <int-e> shachaf: Which would be perfectly okay for my use, but less interesting :P
04:45:07 <shachaf> The allocation is theoretically variable-sized but maybe it's fine in practice for all uses of printf.
04:45:39 <int-e> (no attacker controlled format strings or format lengths or string sizes)
04:46:33 <int-e> But now that I have already written that code... what's the point in using asprintf :)
04:48:08 <zzo38> If your program uses SQLite for whatever reason, you can use the SQL printf function if you need safe dynamic printf. (If not, you can still copy the printf implementation from SQLite into your own program, and modify it to work with your program rather than SQLite.)
04:51:44 <callforjudgement> <shachaf> It's too bad libc mixes "language" convenience things (that maybe ought to just be a regular library statically linked into your program) with "OS" things. ← it's unclear what should be an "OS" thing anyway, just system calls?
04:51:59 <callforjudgement> part of the reason libcs exist is that some things are system calls on some OSes but library functions on others
04:52:55 <callforjudgement> also, I think you can get a lot of efficiency out of MMU abuse nowadays
04:53:12 <zzo38> Glulx has both (although you cannot use both at the same time).
04:53:44 <callforjudgement> I wonder how fast a queue implementation is that just writes through address space continuously, freeing the back of the queue when getting close to memory exhaustion
04:53:58 <shachaf> I think it's very reasonable for programs to include their own malloc implementation rather than defer to libc.
04:54:38 <shachaf> I saw this post about that mentioned it (among other things) the other day: https://tratt.net/laurie/blog/entries/why_arent_more_users_more_happy_with_our_vms_part_1.html
04:54:42 <callforjudgement> I wrote a malloc of my own for fun a while back, it seemed to have decent performance in benchmarks (although I could only find one malloc benchmarker)
04:54:44 <shachaf> (Search for "binary trees", I think.)
04:55:21 <callforjudgement> (i.e. you could malloc or free from a signal handler, without causing issues as long as you don't free something that's currently in use)
04:57:46 <shachaf> Hmm, this might be a silly question, but if I have an array [..., a0, a1, a2, b0, b1, ...] and I want to swap the as and bs in-place, is there a good thing to do?
04:58:19 <shachaf> I mean, two contiguous subarrays.
04:58:24 <callforjudgement> the most efficient swap algorithm on x86 is probably read, read, write, write
04:58:24 <shachaf> as and bs aren't the same length.
04:58:41 <shachaf> I guess the fact that they're subarrays of a bigger array is irrelevant here.
04:59:40 <callforjudgement> the hardest case mathematically appears to be the case where one of the arrays is only one element long
04:59:58 <shachaf> I think in my actual case the second array is always either one or two elements long.
04:59:59 <callforjudgement> then you clearly have to store it in temporary storage, move all the elements of the other array one element along, and put that one element back
05:00:11 <zzo38> Glulx has both malloc and sbrk as instructions (not system calls).
05:00:19 <callforjudgement> the other cases all reduce to this one after some silly modular arithmetic
05:00:22 <shachaf> That's a constant amount of temporary storage, though, that's fine.
05:00:48 <callforjudgement> if it's greater than 1 you operate on every gcdth element independently
05:01:01 <shachaf> You can do everything in-place by moving one element at a time, but I'm hoping there's something better.
05:01:34 <callforjudgement> if the lengths of the two arrays are coprime, then you can move one element at a time, yes
05:02:14 <callforjudgement> to be fair, probably the fastest algorithm is just three memcpys
05:02:42 <shachaf> These are arrays of pointers in this case.
05:03:10 <callforjudgement> although caching hints on modern x86_64 aren't very good, you basically have a choice of "I will use the data again soon" and "I will not use this data again soon"
05:03:26 <shachaf> Or what do you mean by three memcpys?
05:04:15 <callforjudgement> memcpy the shorter array to temporary storage, memmove (not memcpy, sorry) the longer array into position, memcpy the shorter array back
05:04:42 <shachaf> That was probably going to be my default thing.
05:05:07 <callforjudgement> there's also the special case when the arrays are nicely page-aligned, where you just reconfigure the MMU so that the logical memory maps into physical memory in a different way, but that's not going to be very applicable and probably produces hilarious results if you do it repeatedly
05:05:51 <callforjudgement> modern processors are pretty good at block copies of memory, though
05:06:12 <callforjudgement> I did some benchmarking a while back on what the fastest way to write the results of a calculation into memory were
05:06:19 <shachaf> Speaking of which: Is it actually the case that many modern CPU L1 caches are limited to 32 KB because that's the page size times the number of cache ways?
05:06:37 <shachaf> (As opposed to other factors?)
05:07:39 <callforjudgement> that's unlikely to be a limiting factor, the main limiting factor on L1 caches is connecting them to the rest of the CPU
05:08:19 <shachaf> But what else does a virtually-indexed physically-tagged cache do if not that?
05:09:37 <callforjudgement> making the cache use a different sort of addressing internally would be a pretty minor change, compared to trying to figure out how to connect more memory to the CPU at L1 speeds
05:10:20 <shachaf> I expected that it would be something more like what you're saying, but I heard this claim, and I'm not sure. In practice you do see this kind of limit.
05:11:11 <callforjudgement> it wouldn't surprise me if physical limits on the L1 cache meant that it could only be a certain size, so there was no need to create a caching algorithm that could deal with larger sizes because it wouldn't be useful anyway
05:11:22 <shachaf> It's also not clear to me that it would be a minor change. I think people do it to be able to start the L1 cache lookup earlier, before the TLB lookup, which people say is pretty important to make it fast enough.
05:14:37 <callforjudgement> or, well, I think that even if you don't prefetch data, it makes a huge amount of sense to prefetch TLB entries
05:15:00 <callforjudgement> to the extent that it could reasonably not even be a cache, just a "prepare to read/write here…read/write here" sequence
05:15:58 <callforjudgement> it would also kind-of make sense to have a manually managed L1 cache (this presumably has to get flushed to at least L2 during a context switch, but the L1 cache rarely survives a context switch anyway)
05:16:40 <callforjudgement> sort-of like zero page on the 6502, as a sort of memory bank that's particularly fast to use
05:46:34 -!- callforjudgement has quit (Quit: quit).
06:32:17 <b_jonas> int-e: libc has functions to open a FILE* that's a stringstream, or one that is attached to a file descriptor but doesn't close it on fclose. the former lets you implement sscanf from fscanf, the latter is more useful, it lets you fprintf to a file descriptor, or more importantly, mix other kinds of file abstractions (eg. C++, perl, python, rust file handles) easily with FILE*.
06:32:27 -!- adu has quit (Quit: adu).
06:32:42 <b_jonas> int-e: but as for formatting to a fixed-sized buffer, that's what snprintf is for
06:33:19 <shachaf> snprintf is for formatting to a buffer that's big enough to print everything all in one go.
06:33:48 <b_jonas> shachaf: yes, glibc also has a way to create a FILE* with custom read/write callbacks
06:33:58 <shachaf> Yes. That is what int-e used.
06:34:24 <b_jonas> has a documented API for it
06:34:32 <shachaf> But my string formatter doesn't need any of those, not even callbacks.
06:34:50 <shachaf> It's resumable so you can format into a buffer, do something with it, and then use it again.
06:44:22 <b_jonas> ais523: "with a 2⁶⁴ address space you never run out" => yes, but (a) sometimes you want to malloc to a smaller arena in order to have multiple buffers each of which you can free at once without iterating on all its blocks (b) or to be able to use 32-bit indexes within an arena; (c) the address space is 47 bits in practice, not 64 bits;
06:45:50 <b_jonas> (d) even aside from those I have the feeling that your malloc has some non-obvious drawbacks, such as using too many page table entries and so making the page table cache (called "translation something buffer" or TLB on x86) inefficient and so slowing all memory access down, even the memory access outside your malloced space, and possibly making the OS work harder to handle the metadata for your address
06:46:55 <b_jonas> shachaf: right, so why isn't snprintf good for you? do you want to be able to continue formatting with the same arguments after your buffer runs out or something? if you want that, that's basically all that a FILE* does, with a few more words of metadata for how to read and seek
06:47:30 <shachaf> Well, FILE * doesn't present this interface at all, in general.
06:47:42 <shachaf> glibc does give you the interface, but it makes you use callbacks.
06:48:16 <b_jonas> shachaf: ok, so why is snprintf not good for what you want?
06:48:27 <b_jonas> or its openbsd variant, if there's one
06:48:40 <shachaf> snprintf requires you to have a buffer that's big enough for the entire output.
06:49:02 <shachaf> You can't write fprintf in terms of snprintf without something like allocation.
06:49:26 <b_jonas> shachaf: right, so what do you want to do if the buffer runs out, other than detecting that condition like snprintf does and possibly getting a prefix?
06:49:53 <shachaf> I want to be able to do something with the buffer (like write it to a file) and then continue where I left off.
06:50:00 -!- sprocklem has quit (Ping timeout: 258 seconds).
06:50:21 <b_jonas> shachaf: ok, but do you want that as a callback, or do you want to call the formatting function back, or something else?
06:50:33 <shachaf> I want to call the formatting function.
06:50:41 <shachaf> That's more flexible than a callback.
06:50:44 <b_jonas> and it has to somehow remember where it stopped?
06:50:54 -!- deltadoge23 has quit (Quit: Leaving).
06:51:05 <shachaf> For example the library I linked above does that.
06:51:07 <b_jonas> well that's harder to implement from the formatter side, unless you want to give it a stack so it works as a user-space coroutine
06:51:34 <b_jonas> I don't think I ever wanted such an interface, but if you want that, sure
06:51:52 <shachaf> Yes, it's more work to make flexible general libraries than ones that only work for a particular use.
06:52:08 <b_jonas> because then my code has to remember all the formatting arguments too, and what memory they refer to, and all that
06:52:10 <shachaf> I think a callback alternative would probably be OK, just more annoying to use. But standard C doesn't even give you that.
06:52:27 <shachaf> It's true. Maybe C varargs just aren't up to the task.
06:52:31 <b_jonas> the callback alternative is the FILE*-based one in glibc
06:52:49 <b_jonas> you say it uses a few extra calls of malloc, which is admittedly true
06:52:53 <shachaf> Yes, in glibc you can do it.
06:53:09 <shachaf> No, I wasn't really objecting to that malloc, I think that was someone else.
06:53:23 <b_jonas> well it has to be implemented somewhere first. "it's not standardized" is not an excuse, you start with an implementation for stuff like this, not with a standard.
06:53:53 <b_jonas> and there are similar implementations of custom streams in lots of other libraries
06:55:12 <b_jonas> the C++ standard library has something like that now I think, I think boost had something similar but probably with a worse formatter,
06:55:12 <shachaf> Well, I doubt I'd want the glibc solution to be standardized.
06:55:16 <int-e> shachaf: The toy program is a proxy that provides SSL wrapping for a local service... with the twist that it also tells the local service where the request came from.
06:55:34 <b_jonas> these are based on something like C++ streams
06:55:38 <shachaf> Anyway, I was only saying why I don't want to use the glibc function, not whether it's an excuse or not.
06:56:35 <b_jonas> a moment, there was another non-libc library that may have one but I can't find it
06:56:40 <shachaf> Hmm, TLS with TCP fast open is still not really workable, right?
06:57:10 <int-e> not sure what that is
06:57:26 <shachaf> b_jonas: Anyway, difficulty of standardization is the reason I was saying I don't really want to be using a standardized library for this.
06:57:45 * int-e looks at https://en.wikipedia.org/wiki/TCP_Fast_Open
06:57:53 <shachaf> The thing they do to save a roundtrip establishing a TLS connection. Since normally you have the TCP handshake first, followed by the TLS negotiation.
06:58:26 <shachaf> Oh, now I remember, TCP fast open uses this cookie.
06:58:32 <shachaf> So it's probably not even something you want to use.
06:58:42 <int-e> Yeah, hmm, that's irrelevant for what I'm doing.
07:00:22 <b_jonas> I thought apache APR has something like this, but no
07:00:43 <b_jonas> shachaf: anyway, the hardest part of implementing something like this is that printing and scanning floating-point numbers correctly is crazy hard.
07:00:53 <b_jonas> correctly and efficiently, even harder
07:01:10 <int-e> C code always gets so long.
07:01:30 <int-e> This trivial-ish program is 301 lines now.
07:01:39 <int-e> with hardly any comments
07:01:58 <int-e> and nothing to make it user-friendly.
07:02:00 <b_jonas> int-e: that's why I don't write C programs anymore, only C++.
07:02:49 <int-e> I guess you can reduce the effect that every 2nd line is for error handling.
07:04:04 <shachaf> Every second line being error handling sounds more like a library problem than a language problem.
07:04:07 <shachaf> I guess it depends on the code.
07:04:50 <int-e> shachaf: every function can potentially fail, and there's no exceptions that would maybe allow to collect several kinds of errors in a single place.
07:05:06 <int-e> (at least for this kind of IO heavy code)
07:05:07 <b_jonas> shachaf: re move one array before the other when they're adjacent, there's a function that does that, https://en.cppreference.com/w/cpp/algorithm/rotate , but usually it's easier if you have a separate buffer that you can move into
07:06:12 <b_jonas> "probably the fastest algorithm is just three memcpys" => basically yes, although one of them should be a memmove unless you're careful
07:06:46 <shachaf> But this is a C++ page. I know: I'll look in /usr/include/c++/ and see if I can figure out what it does.
07:07:50 <b_jonas> ais523: 'you basically have a choice of "I will use the data again soon" and "I will not use this data again soon"' => technically there's also "I'll never use this data again, don't bother flushing it from cache"
07:08:23 <shachaf> How many levels of indirection before finding the implementation?
07:10:14 <b_jonas> ais523: "trying to figure out how to connect more memory to the CPU at L1 speeds" => I'm convinced the thing that stops that is the minimum page size, which is 4096 bytes on x86, and can't be increased unless you break compatibility with a lot of existing software, because the L1 cache has to do enough address calculation to know where to start to look before the results from the TLB arrives, so you
07:10:20 <b_jonas> can't have more than 8*4096 bytes of L1 cache (per type (data vs code) and cpu core)
07:10:39 <myname> just rust everything c/c++ :p
07:10:41 <shachaf> b_jonas: That's what I was saying.
07:11:05 <b_jonas> "prefetch TLB entries" => you could do that by prefetching one word from each page
07:11:06 <shachaf> But I'm not sure whether that's really the limiting factor. It seems pretty silly compared to the thing ais523 was saying.
07:11:26 <b_jonas> but I think even then I do want a TLB to exist, and a large one ideally
07:11:30 <b_jonas> I don't see why it disappoints you
07:11:55 <b_jonas> shachaf: yes, it's a C++ page, because it has a C++ interface
07:12:20 -!- FAKTOR7 has quit (Remote host closed the connection).
07:12:52 <b_jonas> shachaf: also be careful when using the actual function, I think it had a bug in older versions of gcc where it wasn't binary compatible between two versions of gcc if you ever called it with zero offset or some such nonsense
07:13:02 <b_jonas> I don't want to look it up now
07:13:11 <shachaf> I'm not using C++ so it doesn't matter.
07:13:47 <b_jonas> shachaf: I think that's the limiting factor *now*. obviously if you increase the minimum page size, there'll be another limiting factor very soon, but even just doubling the L1 cache size would help a lot
07:14:09 <b_jonas> well, it would help a lot for some code, obviously; some code isn't bound by that
07:14:18 <shachaf> b_jonas: Another thing that could help is page coloring, requiring physically adjacent pages to be mapped together.
07:14:41 <b_jonas> shachaf: I don't know what that means
07:14:55 <shachaf> https://en.wikipedia.org/wiki/Cache_coloring
07:15:41 <shachaf> It's sort of intermediate between the current situation and actually changing the page size.
07:15:43 <b_jonas> color all your hot memory regions red with the blood of your enemies that you sacrifice to the gods thanking them for giving your computer better performance for memory accesses
07:16:14 <b_jonas> and from the blood of sacrifical animals as well
07:16:50 <b_jonas> use their livers for haruspexy to predict near future memory access and prefetch them as well while you're there
07:16:55 <shachaf> For example, require each even page n to be mapped next to page n+1.
07:27:21 -!- arseniiv has joined.
07:32:36 -!- hendursaga has quit (Remote host closed the connection).
07:33:41 -!- sprocklem has joined.
07:33:49 -!- hendursaga has joined.
07:36:55 <int-e> oh, cookie write functions are not allowed to return negative values
08:06:23 -!- Sgeo has quit (Read error: Connection reset by peer).
08:08:54 -!- hendursa1 has joined.
08:11:03 -!- hendursaga has quit (Ping timeout: 240 seconds).
08:19:07 -!- M8Crumble has joined.
09:08:59 <esowiki> [[7]] M https://esolangs.org/w/index.php?diff=78015&oldid=76480 * SunnyMoon * (+2) Make it into a paragraph so it can be more readable.
09:18:04 -!- imode has quit (Ping timeout: 260 seconds).
10:38:59 -!- M8Crumble has quit (Remote host closed the connection).
10:55:40 -!- t20kdc has joined.
11:06:46 -!- Frater_EST has joined.
11:09:16 -!- LKoen has joined.
11:35:09 -!- tromp has quit.
11:53:30 -!- tromp has joined.
12:00:17 -!- tromp has quit (Remote host closed the connection).
12:29:39 -!- tromp has joined.
12:33:42 -!- FreeFull has joined.
13:07:56 -!- hendursa1 has quit (Quit: hendursa1).
13:08:17 -!- hendursaga has joined.
13:11:16 <esowiki> [[Streetcode]] M https://esolangs.org/w/index.php?diff=78016&oldid=73180 * PythonshellDebugwindow * (-1) /* Ambiguous turns */ Fix a grammar which is the bad grammar
14:05:37 -!- Frater_EST has quit (Read error: Connection reset by peer).
14:22:59 -!- FreeFull has quit.
14:34:38 -!- Arcorann has quit (Read error: Connection reset by peer).
14:45:48 -!- MDude has joined.
14:55:10 -!- FreeFull has joined.
15:16:28 -!- LKoen has quit (Remote host closed the connection).
15:24:18 <esowiki> [[OpenStreetCode]] N https://esolangs.org/w/index.php?oldid=78017 * PythonshellDebugwindow * (+12178) Created page with "{{WIP}} '''OpenStreetCode''' is an esolang by [[User:PythonshellDebugwindow]] based on [https://josm.openstreetmap.de/ JOSM], an editor for [https://www.openstreetmap.org/ Ope..."
15:35:49 <esowiki> [[Talk:Modulous]] M https://esolangs.org/w/index.php?diff=78018&oldid=77131 * Abyxlrz * (+161)
15:36:00 <esowiki> [[Talk:Modulous]] M https://esolangs.org/w/index.php?diff=78019&oldid=78018 * Abyxlrz * (+1)
16:37:52 <esowiki> [[OpenStreetCode]] M https://esolangs.org/w/index.php?diff=78020&oldid=78017 * PythonshellDebugwindow * (+404) /* Use of elements */
16:42:56 <esowiki> [[Special:Log/newusers]] create * Aryantech123 * New user account
16:45:22 <esowiki> [[Esolang:Introduce yourself]] M https://esolangs.org/w/index.php?diff=78021&oldid=77942 * Aryantech123 * (+88)
16:47:15 <esowiki> [[Esolang:Introduce yourself]] M https://esolangs.org/w/index.php?diff=78022&oldid=78021 * Aryantech123 * (+30)
16:52:50 <esowiki> [[Brainflub]] https://esolangs.org/w/index.php?diff=78023&oldid=53136 * Aryantech123 * (+154)
17:01:03 <esowiki> [[OpenStreetCode]] M https://esolangs.org/w/index.php?diff=78024&oldid=78020 * PythonshellDebugwindow * (+10) /* Instruction table */ Fix table and header
17:10:46 <esowiki> [[Language list]] https://esolangs.org/w/index.php?diff=78025&oldid=77993 * Masldobehere * (+11) /* S */
17:16:56 <esowiki> [[OpenStreetCode]] M https://esolangs.org/w/index.php?diff=78026&oldid=78024 * PythonshellDebugwindow * (+116) /* Instruction table */
17:17:07 <esowiki> [[OpenStreetCode]] M https://esolangs.org/w/index.php?diff=78027&oldid=78026 * PythonshellDebugwindow * (-2) /* Memory */
17:45:49 -!- rain1 has quit (Quit: Leaving).
17:54:58 -!- Sgeo has joined.
18:18:38 -!- aaaaaa has joined.
18:46:26 -!- LKoen has joined.
19:03:08 -!- imode has joined.
19:07:09 -!- Frater_EST has joined.
19:08:19 <esowiki> [[OpenStreetCode]] M https://esolangs.org/w/index.php?diff=78028&oldid=78027 * PythonshellDebugwindow * (+593) /* Use of elements */
19:22:00 <esowiki> [[OpenStreetCode]] M https://esolangs.org/w/index.php?diff=78029&oldid=78028 * PythonshellDebugwindow * (+468) /* Relations */
19:22:30 <esowiki> [[OpenStreetCode]] M https://esolangs.org/w/index.php?diff=78030&oldid=78029 * PythonshellDebugwindow * (-8) No longer WIP
19:23:27 <esowiki> [[User:PythonshellDebugwindow]] M https://esolangs.org/w/index.php?diff=78031&oldid=75825 * PythonshellDebugwindow * (+91)
19:23:46 <esowiki> [[User:PythonshellDebugwindow]] M https://esolangs.org/w/index.php?diff=78032&oldid=78031 * PythonshellDebugwindow * (-2) /* Languages */ fix name
19:24:38 <esowiki> [[Language list]] M https://esolangs.org/w/index.php?diff=78033&oldid=78025 * PythonshellDebugwindow * (+21) /* O */ Add [[OpenStreetCode]]
19:27:17 <esowiki> [[OpenStreetCode]] M https://esolangs.org/w/index.php?diff=78034&oldid=78030 * PythonshellDebugwindow * (+177) /* Use of elements */
19:31:38 <esowiki> [[Owk]] M https://esolangs.org/w/index.php?diff=78035&oldid=66419 * PythonshellDebugwindow * (+10) Fix page formatting
19:46:56 <esowiki> [[Special:Log/upload]] upload * PythonshellDebugwindow * uploaded "[[File:OpenStreetScript print A.png]]": File for an [[OpenStreetScript]] example
19:47:27 <esowiki> [[File:OpenStreetScript print A.png]] M https://esolangs.org/w/index.php?diff=78037&oldid=78036 * PythonshellDebugwindow * (-2) /* Summary */
19:47:45 <esowiki> [[Special:Log/move]] move * PythonshellDebugwindow * moved [[File:OpenStreetScript print A.png]] to [[File:OpenStreetCode print A.png]]: Correct name
19:49:34 <esowiki> [[OpenStreetCode]] M https://esolangs.org/w/index.php?diff=78040&oldid=78034 * PythonshellDebugwindow * (+69) /* Print the letter A */
19:49:41 <esowiki> [[OpenStreetCode]] M https://esolangs.org/w/index.php?diff=78041&oldid=78040 * PythonshellDebugwindow * (-6) /* Examples */ image
19:49:59 <esowiki> [[Special:Log/upload]] overwrite * PythonshellDebugwindow * uploaded a new version of "[[File:OpenStreetCode print A.png]]": Shrink a bit
19:51:08 <esowiki> [[Special:Log/upload]] overwrite * PythonshellDebugwindow * uploaded a new version of "[[File:OpenStreetCode print A.png]]": Upload a smaller version (no white-space to the right and bottom)
19:56:34 -!- rain1 has joined.
20:36:30 -!- moony has quit (Quit: Bye!).
20:36:30 -!- Bowserinator has quit (Quit: Blame iczero something happened).
20:36:30 -!- iovoid has quit (Quit: iovoid has quit!).
20:36:30 -!- ATMunn has quit (Quit: lol rip).
20:49:15 -!- Bowserinator has joined.
20:52:28 -!- moony has joined.
20:52:43 -!- ATMunn has joined.
20:58:31 -!- iovoid has joined.
21:07:22 -!- ski has quit (Ping timeout: 246 seconds).
21:12:05 -!- rain1 has quit (Quit: Leaving).
21:19:03 <esowiki> [[Almost Binary]] https://esolangs.org/w/index.php?diff=78044&oldid=73149 * Wsdt * (+74)
21:19:39 <esowiki> [[Almost Binary]] https://esolangs.org/w/index.php?diff=78045&oldid=78044 * Wsdt * (-27)
21:46:20 -!- arseniiv has quit (Ping timeout: 256 seconds).
21:51:05 -!- Frater_EST has quit (Read error: Connection reset by peer).
21:59:31 -!- tromp has quit (Remote host closed the connection).
22:01:17 -!- t20kdc has quit (Remote host closed the connection).
22:14:05 -!- tromp has joined.
22:24:28 -!- deltadoge23 has joined.
22:24:38 -!- deltadoge23 has changed nick to deltaepsilon23.
22:25:18 -!- deltaepsilon23 has quit (Client Quit).
22:25:47 -!- deltaepsilon23 has joined.
22:27:08 -!- deltaepsilon23 has changed nick to delta23.
22:33:55 -!- Arcorann has joined.
22:38:28 -!- tromp has quit (Remote host closed the connection).
23:15:01 -!- tromp has joined.
23:16:35 <b_jonas> rofl... I'm reading the specifications of a desktop speaker, and there's an entry saying "Waterproof: no"
23:18:41 <int-e> Well, waterproofing is important for the times when you drink and read or watch something funny at the same time.
23:20:01 -!- tromp has quit (Ping timeout: 264 seconds).
23:28:41 <shachaf> Aren't waterproof speakers pretty common?
23:29:52 <int-e> I don't know. But "desktop" doesn't suggest any need for waterproofing to me.
23:30:49 <int-e> And speakers tend not to be waterproof by themselves... they're roomy, have cardboard pieces, possibly some cloth...
23:32:41 <b_jonas> on the plus side, the specifications are detailed. finally.
23:33:12 -!- adu has joined.
23:48:08 <b_jonas> crap, I pressed the wrong button
23:51:52 <b_jonas> closed the browser at just the critical time when I have submitted the card payment details that would finalize my order, but it hasn't told me that the order is confirmed yet
23:52:19 <b_jonas> it looks like it didn't go through, but if it did then I'll end up in a stupid wedged state where I have to cancel an order
23:54:48 <fizzie> C-d (mute/unmute microphone in Google Meet) and C-r (reload a tab in Chrome) are relatively close by, I've dropped off a few meetings that way.
23:55:43 <b_jonas> ok, now this attempt succeeded, I have ordered the goodies
23:56:03 <b_jonas> including that speaker set
23:57:11 <b_jonas> also a mechanical keyboard that's more expensive than my previous one, the one that felt really great to type on but lasted for only two and a half years
23:58:53 <fizzie> I've got a pair of speakers, and the right channel has started to go silent; happened twice now, each time coming back after maybe half an hour. I hope that doesn't mean it's going to break. It doesn't seem like it's just flaky connectors or cables or anything; also the right speaker's the one that's got the amplifier and volume knob, while the entirely passive left one (that's connected to the right
23:59:54 <b_jonas> fizzie: hmm. and it's a problem with the signal that you're feeding into it either, or a volume or balance setting somewhere, right?