< 1602979366 119614 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :zzo38: yes, but where's the rule that says you can't cast a land? < 1602979382 453618 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :it looks like there's none, though this may get fixed in the next update < 1602979733 642895 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :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. < 1602980251 249787 :ais523!~ais523@unaffiliated/ais523 QUIT :Read error: Connection reset by peer < 1602980289 977794 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1602980358 492871 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if you have a card with no types, can you cast it? < 1602980367 604403 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(assuming it's in your hand and has a mana cost) < 1602980434 978333 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :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) < 1602980597 325392 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :I don't know. < 1602980753 919732 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :ais523: I don't think there's a way to have a card with no types outside the battlefield < 1602980812 143163 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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 < 1602980865 268068 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :ais523: but I don't think there's anything to stop you from casting it from your hand if it has a mana cost < 1602980882 332011 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :The rules say a object with instant or sorcery type cannot enter the battlefield, but I don't know about other ones < 1602980937 123371 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :hmm wait < 1602980941 623125 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :I don't know what would happen < 1602981009 504152 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1602981009 650365 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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" < 1602981108 367796 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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 < 1602981124 87802 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :and 608.2k also talks about resolving abilities < 1602981137 17725 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :combat damage on stack no longer exists < 1602981181 890971 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :there are of course some replacement abilities that can make a spell move to exile instead of the graveyard when resolving < 1602981222 674588 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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 < 1602981242 194763 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :but I don't think this can happen in first place < 1602981301 471897 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 244 seconds < 1602981442 426885 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :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. < 1602981452 986215 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the same thing would happen with a land spell, wouldn't it? < 1602981461 342205 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :instant draw, unless someone chooses to counterspell it < 1602981511 378172 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :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) < 1602981519 922058 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :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 < 1602981569 993002 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so there's never any problem about how to remove them from the play area after they resolve < 1602981601 868861 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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 < 1602981618 957382 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :because the type gets copied from the original spell < 1602981620 283933 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(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) < 1602981643 782516 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :ais523: hmm. you have a point about the land spell < 1602981719 57803 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :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) < 1602981756 454615 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that said, Netrunner also doesn't have a problem with just leaving things in the play area, over multiple turns if necessary < 1602981790 171024 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you can think of events/operations as having triggered abilities that trigger on them being played, causing them to resolve and be trashed < 1602981804 164240 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if something goes wrong with the ability, they just kind-of sit there until something happens to them < 1602981821 163298 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this wouldn't work in Magic, because you can counter triggered abilities there < 1602981828 293066 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but it's a clever way to avoid having both spells and abilities on the stack < 1602981901 703392 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and it's sometimes used to make operations that take multiple turns to resolve < 1602981930 881771 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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. < 1602982001 899199 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :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 < 1602982008 30114 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :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) < 1602982016 52348 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(land is more of a keyword ability, and creatures and planeswalkers have a lot of rules of their own) < 1602982019 854811 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :ais523: yes, but we want to have effects printed on cards that let you cast or play sorceries and creatures uniformly < 1602982032 410007 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :ais523: and keywords like suspend < 1602982039 821297 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: Netrunner has plentry of the former, they just say "play or install" < 1602982081 575245 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :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. < 1602982189 262091 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :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" < 1602982210 649822 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(I don't think it'd be modal, Netrunner doesn't do modal effects very often, so it'd just have the suspend cost") < 1602982234 894393 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :actually that wouldn't work for suspend permanents, those would be awkward < 1602982256 360153 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :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 < 1602982404 162272 :FreeFull!~freefull@defocus/sausage-lover QUIT : < 1602982470 969351 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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 < 1602982490 679527 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :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. < 1602982518 822313 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :those work even if they're Arrested and Turned to Frog < 1602982601 530687 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes < 1602982604 345982 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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 < 1602982628 630419 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it wouldn't surprise me if the Arena programmers just read the rules and implemented them as written < 1602982658 830415 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :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 < 1602982662 608104 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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, < 1602982673 204971 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :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. < 1602982708 196702 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :plus there will probably be more modal double-faced cards in near future sets, for which he'll look at the rules too < 1602982723 800547 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :so I'll just have to wait for the next update and then read what the rules say again < 1602983076 272846 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :lol! today's SMBC is great https://www.smbc-comics.com/comic/nudge < 1602983113 856791 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :that's a take on Allosaurus president plus asteroid defense mission that didn't come up in Irregular < 1602983304 69825 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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 < 1602983310 100641 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :to amber color than those lights used as signals for road traffic. < 1602983559 737744 :aaaaaa!~ArthurStr@host-91-90-11-13.soborka.net QUIT :Quit: leaving < 1602984592 468854 :adu!~arobbins@c-76-111-99-194.hsd1.md.comcast.net JOIN :#esoteric < 1602985340 988677 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1602986540 480899 :adu!~arobbins@c-76-111-99-194.hsd1.md.comcast.net QUIT :Quit: adu < 1602987357 992064 :dcristofani!~dcristofa@69-71-183-170.mammothnetworks.com JOIN :#esoteric < 1602988558 973326 :dcristofani!~dcristofa@69-71-183-170.mammothnetworks.com QUIT :Ping timeout: 260 seconds < 1602989462 715540 :MDude!~MDude@71.50.47.112 QUIT :Quit: Going offline, see ya! (www.adiirc.com) < 1602990669 220588 :adu!~arobbins@c-76-111-99-194.hsd1.md.comcast.net JOIN :#esoteric < 1602990928 892653 :Sgeo!~Sgeo@ool-18b982ad.dyn.optonline.net QUIT :Read error: Connection reset by peer < 1602991183 989101 :Sgeo!~Sgeo@ool-18b982ad.dyn.optonline.net JOIN :#esoteric < 1602991455 277819 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Oh there's a dprintf() for printing to fds, interesting. < 1602991576 866963 :int-e!~noone@int-e.eu PRIVMSG #esoteric :(in POSIX, since 2008) < 1602991871 281154 :dcristofani!~dcristofa@69-71-183-170.mammothnetworks.com JOIN :#esoteric < 1602992334 964681 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :My formatting API lets you printf into a fixed-size buffer. It would be nice if sprintf did that. < 1602992358 521368 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :As it is you can't implement fprintf in terms of sprintf or vice versa. < 1602992630 889842 :deltaepsilon23!~deltaepsi@cpe-24-208-148-153.insight.res.rr.com JOIN :#esoteric < 1602992937 455240 :int-e!~noone@int-e.eu PRIVMSG #esoteric :. o O ( fork off a thread and fprintf to a pipe ) < 1602993068 785806 :int-e!~noone@int-e.eu PRIVMSG #esoteric :(But I get what you mean.) < 1602993121 253408 :deltaepsilon23!~deltaepsi@cpe-24-208-148-153.insight.res.rr.com NICK :deltadoge23 < 1602993588 306868 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :https://shachaf.net/tmp/fmt/fmt.h < 1602993604 616559 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think C varargs makes this pretty tricky for printf, though. < 1602993611 426901 :int-e!~noone@int-e.eu PRIVMSG #esoteric :I also still remember that you've worked on this. < 1602993625 787150 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh no, do I just post the same things in here over and over again? < 1602993676 851822 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Anyway, C varargs are invalidated as soon as the function returns, which makes it harder. < 1602993706 319550 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I guess you could scan over the format string once to copy the varargs values? But I'm not sure you'd want to. < 1602993812 742736 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :There is fmemopen and open_memstream, and all of the printf variants return the length of the result, in case those things are needed. < 1602993862 140629 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Although there is that problem with varargs that you mention. < 1602993883 722838 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, but that still needs you to have enough memory for the result at once, I suppose. < 1602993902 122390 :int-e!~noone@int-e.eu PRIVMSG #esoteric :shachaf: We all have our own little pet topics, I suppose. < 1602993928 728092 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :musl libc uses a FILE * with a write callback argument for vfprintf. < 1602993981 316035 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh, maybe glibc does something similar. < 1602993992 831590 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :int-e: I did change the API since last time I mentioned it, I think. < 1602994108 697334 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Oh poking in FILE * interna, hmm. < 1602994142 612285 :int-e!~noone@int-e.eu PRIVMSG #esoteric :ah. fopencookie < 1602994158 4108 :int-e!~noone@int-e.eu PRIVMSG #esoteric :what a fun name... < 1602994171 331022 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh, I didn't know that. < 1602994176 569757 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Well, it's a GNU extension. < 1602994196 764703 :ais523!~ais523@unaffiliated/ais523 QUIT :Read error: Connection reset by peer < 1602994202 581858 :callforjudgement!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1602994239 296193 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Yes, it is. And it's still a funny name. < 1602994340 977931 :int-e!~noone@int-e.eu PRIVMSG #esoteric :It's too bad that this isn't standardized so you get reimplementations like https://wiki.openssl.org/index.php/BIO < 1602994355 212600 :int-e!~noone@int-e.eu PRIVMSG #esoteric :where nothing ever fits with anything else < 1602994505 704208 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :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. < 1602995310 269650 :dcristofani!~dcristofa@69-71-183-170.mammothnetworks.com QUIT :Ping timeout: 272 seconds < 1602995633 552551 :int-e!~noone@int-e.eu PRIVMSG #esoteric :shachaf: I guess you wouldn't really like fopencookie anyway... because it allocates from the heap. < 1602995651 163371 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Do I hate all heap allocations? < 1602995679 231617 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :When you're interacting with libc things like FILE * functions it seems too far gone to worry about things like that. < 1602995684 966591 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Not quite, just the not strictly necessary ones. < 1602995690 406405 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It probably calls malloc 20 times before breakfast. < 1602995919 831326 :int-e!~noone@int-e.eu PRIVMSG #esoteric :but it leads to things like FILE *f = fopencookie(s, "a", cb); if (!f) { errno = ENOMEM; return -1; } < 1602995941 172779 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh, sure, that seems annoying. < 1602996018 814772 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Certainly it seems entirely gratuitous when an API makes you do that many times for no reason, like posix_spawn. < 1602996168 747675 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Oh well. It seems to work... https://paste.debian.net/1167655/ < 1602996197 320701 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Good thing malloc failures never happen. < 1602996203 658058 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :At least on Linux. < 1602996222 984888 :int-e!~noone@int-e.eu PRIVMSG #esoteric :that's an entirely different pet peeve :P < 1602996264 981978 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :I often use a macro to check for memory allocation errors < 1602996277 73635 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Of course, if you're OK with GNU extensions + allocation, you could use asprintf. < 1602996280 430406 :int-e!~noone@int-e.eu PRIVMSG #esoteric :But whatever, I need some fresh air, and then I can figure out how to wrap up this toy program. < 1602996306 821535 :int-e!~noone@int-e.eu PRIVMSG #esoteric :shachaf: Which would be perfectly okay for my use, but less interesting :P < 1602996307 506993 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The allocation is theoretically variable-sized but maybe it's fine in practice for all uses of printf. < 1602996339 742499 :int-e!~noone@int-e.eu PRIVMSG #esoteric :(no attacker controlled format strings or format lengths or string sizes) < 1602996393 533095 :int-e!~noone@int-e.eu PRIVMSG #esoteric :But now that I have already written that code... what's the point in using asprintf :) < 1602996488 128181 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :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.) < 1602996518 623658 :int-e!~noone@int-e.eu PRIVMSG #esoteric :not happening < 1602996611 521375 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What is this toy program? < 1602996704 873033 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric : 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? < 1602996719 54628 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :part of the reason libcs exist is that some things are system calls on some OSes but library functions on others < 1602996730 8577 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :MS-DOS has malloc as a system call, for example (not sbrk) < 1602996775 752114 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also, I think you can get a lot of efficiency out of MMU abuse nowadays < 1602996792 979482 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Glulx has both (although you cannot use both at the same time). < 1602996824 101515 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :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 < 1602996838 123020 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think it's very reasonable for programs to include their own malloc implementation rather than defer to libc. < 1602996853 442172 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :with a 2⁶⁴ address space you never run out < 1602996878 381463 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :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 < 1602996882 538713 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :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) < 1602996884 460390 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :(Search for "binary trees", I think.) < 1602996894 596664 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also was async-signal-safe, which is useful for some purposes < 1602996921 123713 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(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) < 1602997066 115598 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :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? < 1602997091 34763 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :swap a0 and b0, then a1 and b1, etc. < 1602997099 942288 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I mean, two contiguous subarrays. < 1602997104 75957 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the most efficient swap algorithm on x86 is probably read, read, write, write < 1602997104 502735 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :as and bs aren't the same length. < 1602997121 700012 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I guess the fact that they're subarrays of a bigger array is irrelevant here. < 1602997122 855435 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, you mean move the bs to before the as < 1602997130 234814 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so abcdAB becomes ABabcd < 1602997134 334110 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, that's right. < 1602997180 884717 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the hardest case mathematically appears to be the case where one of the arrays is only one element long < 1602997198 372506 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think in my actual case the second array is always either one or two elements long. < 1602997199 784609 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :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 < 1602997211 80843 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Glulx has both malloc and sbrk as instructions (not system calls). < 1602997219 701610 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the other cases all reduce to this one after some silly modular arithmetic < 1602997222 154210 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That's a constant amount of temporary storage, though, that's fine. < 1602997234 209606 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :like, you take the gcd of the lengths of the two arrays < 1602997248 657742 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if it's greater than 1 you operate on every gcdth element independently < 1602997261 827725 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You can do everything in-place by moving one element at a time, but I'm hoping there's something better. < 1602997294 466042 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if the lengths of the two arrays are coprime, then you can move one element at a time, yes < 1602997302 67467 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but the cache locality of that has to be horrible < 1602997334 145984 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :to be fair, probably the fastest algorithm is just three memcpys < 1602997348 706208 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(with appropriate caching hints set) < 1602997362 555631 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :These are arrays of pointers in this case. < 1602997390 151984 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :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" < 1602997406 692563 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Or what do you mean by three memcpys? < 1602997455 270733 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :memcpy the shorter array to temporary storage, memmove (not memcpy, sorry) the longer array into position, memcpy the shorter array back < 1602997469 486991 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :OK, sure. < 1602997482 733083 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That was probably going to be my default thing. < 1602997507 878513 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :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 < 1602997551 3373 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :modern processors are pretty good at block copies of memory, though < 1602997572 779734 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I did some benchmarking a while back on what the fastest way to write the results of a calculation into memory were < 1602997579 309099 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :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? < 1602997597 736421 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :(As opposed to other factors?) < 1602997659 632592 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that's unlikely to be a limiting factor, the main limiting factor on L1 caches is connecting them to the rest of the CPU < 1602997668 752426 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in a way that allows the data to get there fast < 1602997699 657659 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But what else does a virtually-indexed physically-tagged cache do if not that? < 1602997777 298873 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :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 < 1602997820 254087 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :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. < 1602997871 297341 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :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 < 1602997882 69069 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :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. < 1602998051 198225 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the existence of the TLB disappoints me < 1602998077 841707 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :or, well, I think that even if you don't prefetch data, it makes a huge amount of sense to prefetch TLB entries < 1602998100 782541 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :to the extent that it could reasonably not even be a cache, just a "prepare to read/write here…read/write here" sequence < 1602998158 276169 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :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) < 1602998200 48228 :callforjudgement!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :sort-of like zero page on the 6502, as a sort of memory bank that's particularly fast to use < 1602999994 538707 :callforjudgement!~ais523@unaffiliated/ais523 QUIT :Quit: quit < 1603002737 291863 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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*. < 1603002747 718442 :adu!~arobbins@c-76-111-99-194.hsd1.md.comcast.net QUIT :Quit: adu < 1603002762 552115 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :int-e: but as for formatting to a fixed-sized buffer, that's what snprintf is for < 1603002799 298091 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :snprintf is for formatting to a buffer that's big enough to print everything all in one go. < 1603002828 630228 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :shachaf: yes, glibc also has a way to create a FILE* with custom read/write callbacks < 1603002838 175601 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes. That is what int-e used. < 1603002864 778391 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :has a documented API for it < 1603002872 258082 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But my string formatter doesn't need any of those, not even callbacks. < 1603002890 604711 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It's resumable so you can format into a buffer, do something with it, and then use it again. < 1603003462 536148 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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; < 1603003550 795581 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :(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 < 1603003556 852168 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :space < 1603003615 872432 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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 < 1603003650 153014 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Well, FILE * doesn't present this interface at all, in general. < 1603003662 576519 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :glibc does give you the interface, but it makes you use callbacks. < 1603003696 346486 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :shachaf: ok, so why is snprintf not good for what you want? < 1603003707 210128 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :or its openbsd variant, if there's one < 1603003720 521723 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :snprintf requires you to have a buffer that's big enough for the entire output. < 1603003737 454445 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :nope, no openbsd variant < 1603003742 299324 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You can't write fprintf in terms of snprintf without something like allocation. < 1603003766 884861 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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? < 1603003793 733699 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I want to be able to do something with the buffer (like write it to a file) and then continue where I left off. < 1603003800 531662 :sprocklem!~sprocklem@unaffiliated/sprocklem QUIT :Ping timeout: 258 seconds < 1603003821 692865 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :shachaf: ok, but do you want that as a callback, or do you want to call the formatting function back, or something else? < 1603003833 904085 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I want to call the formatting function. < 1603003841 692967 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That's more flexible than a callback. < 1603003844 773940 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :and it has to somehow remember where it stopped? < 1603003854 19200 :deltadoge23!~deltaepsi@cpe-24-208-148-153.insight.res.rr.com QUIT :Quit: Leaving < 1603003857 934331 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes. < 1603003865 522941 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :For example the library I linked above does that. < 1603003867 651470 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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 < 1603003894 399595 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :I don't think I ever wanted such an interface, but if you want that, sure < 1603003912 183802 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, it's more work to make flexible general libraries than ones that only work for a particular use. < 1603003928 439445 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :because then my code has to remember all the formatting arguments too, and what memory they refer to, and all that < 1603003930 772734 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think a callback alternative would probably be OK, just more annoying to use. But standard C doesn't even give you that. < 1603003947 712342 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It's true. Maybe C varargs just aren't up to the task. < 1603003951 501335 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :the callback alternative is the FILE*-based one in glibc < 1603003969 104988 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :you say it uses a few extra calls of malloc, which is admittedly true < 1603003973 965389 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, in glibc you can do it. < 1603003989 9649 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :No, I wasn't really objecting to that malloc, I think that was someone else. < 1603004003 394622 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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. < 1603004033 530458 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :and there are similar implementations of custom streams in lots of other libraries < 1603004112 56428 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :the C++ standard library has something like that now I think, I think boost had something similar but probably with a worse formatter, < 1603004112 200708 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Well, I doubt I'd want the glibc solution to be standardized. < 1603004116 962313 :int-e!~noone@int-e.eu PRIVMSG #esoteric :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. < 1603004134 299551 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :these are based on something like C++ streams < 1603004138 674438 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Anyway, I was only saying why I don't want to use the glibc function, not whether it's an excuse or not. < 1603004195 311589 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :a moment, there was another non-libc library that may have one but I can't find it < 1603004200 905453 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hmm, TLS with TCP fast open is still not really workable, right? < 1603004230 962750 :int-e!~noone@int-e.eu PRIVMSG #esoteric :not sure what that is < 1603004246 184490 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :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. < 1603004265 988903 :int-e!~noone@int-e.eu PRIVMSG #esoteric :ACTION looks at https://en.wikipedia.org/wiki/TCP_Fast_Open < 1603004273 129935 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :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. < 1603004306 92281 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh, now I remember, TCP fast open uses this cookie. < 1603004312 976715 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So it's probably not even something you want to use. < 1603004322 396614 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Yeah, hmm, that's irrelevant for what I'm doing. < 1603004422 392511 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :I thought apache APR has something like this, but no < 1603004443 604702 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :shachaf: anyway, the hardest part of implementing something like this is that printing and scanning floating-point numbers correctly is crazy hard. < 1603004452 617331 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I agree. < 1603004453 247451 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :correctly and efficiently, even harder < 1603004470 399191 :int-e!~noone@int-e.eu PRIVMSG #esoteric :C code always gets so long. < 1603004490 790948 :int-e!~noone@int-e.eu PRIVMSG #esoteric :This trivial-ish program is 301 lines now. < 1603004499 197816 :int-e!~noone@int-e.eu PRIVMSG #esoteric :with hardly any comments < 1603004518 312741 :int-e!~noone@int-e.eu PRIVMSG #esoteric :and nothing to make it user-friendly. < 1603004520 10882 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :int-e: that's why I don't write C programs anymore, only C++. < 1603004531 598507 :int-e!~noone@int-e.eu PRIVMSG #esoteric :... < 1603004569 386243 :int-e!~noone@int-e.eu PRIVMSG #esoteric :I guess you can reduce the effect that every 2nd line is for error handling. < 1603004644 338472 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Every second line being error handling sounds more like a library problem than a language problem. < 1603004647 563225 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I guess it depends on the code. < 1603004690 7669 :int-e!~noone@int-e.eu PRIVMSG #esoteric :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. < 1603004706 949261 :int-e!~noone@int-e.eu PRIVMSG #esoteric :(at least for this kind of IO heavy code) < 1603004707 54363 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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 < 1603004772 713876 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :"probably the fastest algorithm is just three memcpys" => basically yes, although one of them should be a memmove unless you're careful < 1603004806 64134 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :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. < 1603004870 688849 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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" < 1603004903 278768 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :How many levels of indirection before finding the implementation? < 1603004939 976802 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh, only two, very good. < 1603005014 130446 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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 < 1603005020 53112 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :can't have more than 8*4096 bytes of L1 cache (per type (data vs code) and cpu core) < 1603005039 941649 :myname!~myname@ks300980.kimsufi.com PRIVMSG #esoteric :just rust everything c/c++ :p < 1603005041 51740 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :b_jonas: That's what I was saying. < 1603005065 362454 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :"prefetch TLB entries" => you could do that by prefetching one word from each page < 1603005066 676895 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But I'm not sure whether that's really the limiting factor. It seems pretty silly compared to the thing ais523 was saying. < 1603005086 291548 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :but I think even then I do want a TLB to exist, and a large one ideally < 1603005090 402895 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :I don't see why it disappoints you < 1603005115 180843 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :shachaf: yes, it's a C++ page, because it has a C++ interface < 1603005140 816240 :FAKTOR7!~FAKTOR7@130.255.19.203 QUIT :Remote host closed the connection < 1603005172 746864 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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 < 1603005182 890833 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :I don't want to look it up now < 1603005191 717226 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I'm not using C++ so it doesn't matter. < 1603005227 350323 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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 < 1603005249 581398 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :well, it would help a lot for some code, obviously; some code isn't bound by that < 1603005258 632174 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :b_jonas: Another thing that could help is page coloring, requiring physically adjacent pages to be mapped together. < 1603005270 880186 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :"physically" adjacent < 1603005281 564981 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :shachaf: I don't know what that means < 1603005286 790844 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :page coloring? < 1603005295 527502 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :https://en.wikipedia.org/wiki/Cache_coloring < 1603005341 372852 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It's sort of intermediate between the current situation and actually changing the page size. < 1603005343 191396 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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 < 1603005374 956812 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :and from the blood of sacrifical animals as well < 1603005410 290525 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :use their livers for haruspexy to predict near future memory access and prefetch them as well while you're there < 1603005415 511329 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :For example, require each even page n to be mapped next to page n+1. < 1603005472 86942 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :hmm < 1603006041 174449 :arseniiv!~arseniiv@136.169.204.164 JOIN :#esoteric < 1603006356 690533 :hendursaga!~weechat@gateway/tor-sasl/hendursaga QUIT :Remote host closed the connection < 1603006421 693331 :sprocklem!~sprocklem@unaffiliated/sprocklem JOIN :#esoteric < 1603006429 378939 :hendursaga!~weechat@gateway/tor-sasl/hendursaga JOIN :#esoteric < 1603006615 277524 :int-e!~noone@int-e.eu PRIVMSG #esoteric :oh, cookie write functions are not allowed to return negative values < 1603008383 362619 :Sgeo!~Sgeo@ool-18b982ad.dyn.optonline.net QUIT :Read error: Connection reset by peer < 1603008534 496068 :hendursa1!~weechat@gateway/tor-sasl/hendursaga JOIN :#esoteric < 1603008663 928341 :hendursaga!~weechat@gateway/tor-sasl/hendursaga QUIT :Ping timeout: 240 seconds < 1603009147 734470 :M8Crumble!6e938618@110.147.134.24 JOIN :#esoteric < 1603009162 626501 :M8Crumble!6e938618@110.147.134.24 PRIVMSG #esoteric :52*"!dlroW olleH">:# ,# _@ > 1603012139 179512 PRIVMSG #esoteric :14[[07714]]4 M10 02https://esolangs.org/w/index.php?diff=78015&oldid=76480 5* 03SunnyMoon 5* (+2) 10Make it into a paragraph so it can be more readable. < 1603012684 79125 :imode!~linear@unaffiliated/imode QUIT :Ping timeout: 260 seconds < 1603017539 916777 :M8Crumble!6e938618@110.147.134.24 QUIT :Remote host closed the connection < 1603018540 922993 :t20kdc!~20kdc@cpc139384-aztw33-2-0-cust220.18-1.cable.virginm.net JOIN :#esoteric < 1603019206 630192 :Frater_EST!adrianbibl@75.107.60.35 JOIN :#esoteric < 1603019356 65943 :LKoen!~LKoen@81.255.219.130 JOIN :#esoteric < 1603020909 753450 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT : < 1603022010 203539 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1603022417 864218 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1603024179 115819 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1603024422 957341 :FreeFull!~freefull@defocus/sausage-lover JOIN :#esoteric < 1603026476 132959 :hendursa1!~weechat@gateway/tor-sasl/hendursaga QUIT :Quit: hendursa1 < 1603026497 9404 :hendursaga!~weechat@gateway/tor-sasl/hendursaga JOIN :#esoteric > 1603026676 605393 PRIVMSG #esoteric :14[[07Streetcode14]]4 M10 02https://esolangs.org/w/index.php?diff=78016&oldid=73180 5* 03PythonshellDebugwindow 5* (-1) 10/* Ambiguous turns */ Fix a grammar which is the bad grammar < 1603029937 104545 :Frater_EST!adrianbibl@75.107.60.35 QUIT :Read error: Connection reset by peer < 1603030979 410622 :FreeFull!~freefull@defocus/sausage-lover QUIT : < 1603031678 150109 :Arcorann!~awych@121-200-5-186.79c805.syd.nbn.aussiebb.net QUIT :Read error: Connection reset by peer < 1603032348 716981 :MDude!~MDude@71.50.47.112 JOIN :#esoteric < 1603032910 882246 :FreeFull!~freefull@defocus/sausage-lover JOIN :#esoteric < 1603034188 267563 :LKoen!~LKoen@81.255.219.130 QUIT :Remote host closed the connection > 1603034658 182239 PRIVMSG #esoteric :14[[07OpenStreetCode14]]4 N10 02https://esolangs.org/w/index.php?oldid=78017 5* 03PythonshellDebugwindow 5* (+12178) 10Created 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..." > 1603035349 825098 PRIVMSG #esoteric :14[[07Talk:Modulous14]]4 M10 02https://esolangs.org/w/index.php?diff=78018&oldid=77131 5* 03Abyxlrz 5* (+161) 10 > 1603035360 370752 PRIVMSG #esoteric :14[[07Talk:Modulous14]]4 M10 02https://esolangs.org/w/index.php?diff=78019&oldid=78018 5* 03Abyxlrz 5* (+1) 10 > 1603039072 601837 PRIVMSG #esoteric :14[[07OpenStreetCode14]]4 M10 02https://esolangs.org/w/index.php?diff=78020&oldid=78017 5* 03PythonshellDebugwindow 5* (+404) 10/* Use of elements */ > 1603039376 702019 PRIVMSG #esoteric :14[[07Special:Log/newusers14]]4 create10 02 5* 03Aryantech123 5* 10New user account > 1603039522 113908 PRIVMSG #esoteric :14[[07Esolang:Introduce yourself14]]4 M10 02https://esolangs.org/w/index.php?diff=78021&oldid=77942 5* 03Aryantech123 5* (+88) 10 > 1603039635 178927 PRIVMSG #esoteric :14[[07Esolang:Introduce yourself14]]4 M10 02https://esolangs.org/w/index.php?diff=78022&oldid=78021 5* 03Aryantech123 5* (+30) 10 > 1603039970 642331 PRIVMSG #esoteric :14[[07Brainflub14]]4 10 02https://esolangs.org/w/index.php?diff=78023&oldid=53136 5* 03Aryantech123 5* (+154) 10 > 1603040463 177753 PRIVMSG #esoteric :14[[07OpenStreetCode14]]4 M10 02https://esolangs.org/w/index.php?diff=78024&oldid=78020 5* 03PythonshellDebugwindow 5* (+10) 10/* Instruction table */ Fix table and header > 1603041046 233171 PRIVMSG #esoteric :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=78025&oldid=77993 5* 03Masldobehere 5* (+11) 10/* S */ > 1603041416 435641 PRIVMSG #esoteric :14[[07OpenStreetCode14]]4 M10 02https://esolangs.org/w/index.php?diff=78026&oldid=78024 5* 03PythonshellDebugwindow 5* (+116) 10/* Instruction table */ > 1603041427 103870 PRIVMSG #esoteric :14[[07OpenStreetCode14]]4 M10 02https://esolangs.org/w/index.php?diff=78027&oldid=78026 5* 03PythonshellDebugwindow 5* (-2) 10/* Memory */ < 1603043149 473995 :rain1!~rain1@unaffiliated/rain1 QUIT :Quit: Leaving < 1603043698 996019 :Sgeo!~Sgeo@ool-18b982ad.dyn.optonline.net JOIN :#esoteric < 1603045118 897846 :aaaaaa!~ArthurStr@host-91-90-11-13.soborka.net JOIN :#esoteric < 1603046786 362919 :LKoen!~LKoen@81.255.219.130 JOIN :#esoteric < 1603047788 967367 :imode!~linear@unaffiliated/imode JOIN :#esoteric < 1603048029 956013 :Frater_EST!~adrianbib@75.107.60.35 JOIN :#esoteric > 1603048099 629534 PRIVMSG #esoteric :14[[07OpenStreetCode14]]4 M10 02https://esolangs.org/w/index.php?diff=78028&oldid=78027 5* 03PythonshellDebugwindow 5* (+593) 10/* Use of elements */ > 1603048920 524145 PRIVMSG #esoteric :14[[07OpenStreetCode14]]4 M10 02https://esolangs.org/w/index.php?diff=78029&oldid=78028 5* 03PythonshellDebugwindow 5* (+468) 10/* Relations */ > 1603048950 509568 PRIVMSG #esoteric :14[[07OpenStreetCode14]]4 M10 02https://esolangs.org/w/index.php?diff=78030&oldid=78029 5* 03PythonshellDebugwindow 5* (-8) 10No longer WIP > 1603049007 554616 PRIVMSG #esoteric :14[[07User:PythonshellDebugwindow14]]4 M10 02https://esolangs.org/w/index.php?diff=78031&oldid=75825 5* 03PythonshellDebugwindow 5* (+91) 10 > 1603049026 402945 PRIVMSG #esoteric :14[[07User:PythonshellDebugwindow14]]4 M10 02https://esolangs.org/w/index.php?diff=78032&oldid=78031 5* 03PythonshellDebugwindow 5* (-2) 10/* Languages */ fix name > 1603049078 485403 PRIVMSG #esoteric :14[[07Language list14]]4 M10 02https://esolangs.org/w/index.php?diff=78033&oldid=78025 5* 03PythonshellDebugwindow 5* (+21) 10/* O */ Add [[OpenStreetCode]] > 1603049237 428121 PRIVMSG #esoteric :14[[07OpenStreetCode14]]4 M10 02https://esolangs.org/w/index.php?diff=78034&oldid=78030 5* 03PythonshellDebugwindow 5* (+177) 10/* Use of elements */ > 1603049498 127455 PRIVMSG #esoteric :14[[07Owk14]]4 M10 02https://esolangs.org/w/index.php?diff=78035&oldid=66419 5* 03PythonshellDebugwindow 5* (+10) 10Fix page formatting > 1603050416 695329 PRIVMSG #esoteric :14[[07Special:Log/upload14]]4 upload10 02 5* 03PythonshellDebugwindow 5* 10uploaded "[[02File:OpenStreetScript print A.png10]]": File for an [[OpenStreetScript]] example > 1603050447 904282 PRIVMSG #esoteric :14[[07File:OpenStreetScript print A.png14]]4 M10 02https://esolangs.org/w/index.php?diff=78037&oldid=78036 5* 03PythonshellDebugwindow 5* (-2) 10/* Summary */ > 1603050465 650217 PRIVMSG #esoteric :14[[07Special:Log/move14]]4 move10 02 5* 03PythonshellDebugwindow 5* 10moved [[02File:OpenStreetScript print A.png10]] to [[File:OpenStreetCode print A.png]]: Correct name > 1603050574 622860 PRIVMSG #esoteric :14[[07OpenStreetCode14]]4 M10 02https://esolangs.org/w/index.php?diff=78040&oldid=78034 5* 03PythonshellDebugwindow 5* (+69) 10/* Print the letter A */ > 1603050581 172019 PRIVMSG #esoteric :14[[07OpenStreetCode14]]4 M10 02https://esolangs.org/w/index.php?diff=78041&oldid=78040 5* 03PythonshellDebugwindow 5* (-6) 10/* Examples */ image > 1603050599 606728 PRIVMSG #esoteric :14[[07Special:Log/upload14]]4 overwrite10 02 5* 03PythonshellDebugwindow 5* 10uploaded a new version of "[[02File:OpenStreetCode print A.png10]]": Shrink a bit > 1603050668 942369 PRIVMSG #esoteric :14[[07Special:Log/upload14]]4 overwrite10 02 5* 03PythonshellDebugwindow 5* 10uploaded a new version of "[[02File:OpenStreetCode print A.png10]]": Upload a smaller version (no white-space to the right and bottom) < 1603050994 227947 :rain1!~rain1@unaffiliated/rain1 JOIN :#esoteric < 1603053390 253709 :moony!moony@hellomouse/dev/moony QUIT :Quit: Bye! < 1603053390 253788 :Bowserinator!Bowserinat@hellomouse/dev/Bowserinator QUIT :Quit: Blame iczero something happened < 1603053390 253804 :iovoid!iovoid@hellomouse/dev/iovoid QUIT :Quit: iovoid has quit! < 1603053390 400478 :ATMunn!ATMunn@gateway/shell/hellomouse/x-gvfwvshntysrjsbr QUIT :Quit: lol rip < 1603054155 507373 :Bowserinator!Bowserinat@hellomouse/dev/Bowserinator JOIN :#esoteric < 1603054348 132763 :moony!moony@hellomouse/dev/moony JOIN :#esoteric < 1603054363 201549 :ATMunn!ATMunn@gateway/shell/hellomouse/x-crqptgmczkinoork JOIN :#esoteric < 1603054711 100716 :iovoid!iovoid@hellomouse/dev/iovoid JOIN :#esoteric < 1603055242 687476 :ski!~ski@nc-2504-30.studat.chalmers.se QUIT :Ping timeout: 246 seconds < 1603055525 458403 :rain1!~rain1@unaffiliated/rain1 QUIT :Quit: Leaving > 1603055943 276161 PRIVMSG #esoteric :14[[07Almost Binary14]]4 10 02https://esolangs.org/w/index.php?diff=78044&oldid=73149 5* 03Wsdt 5* (+74) 10 > 1603055979 323784 PRIVMSG #esoteric :14[[07Almost Binary14]]4 10 02https://esolangs.org/w/index.php?diff=78045&oldid=78044 5* 03Wsdt 5* (-27) 10 < 1603057580 76735 :arseniiv!~arseniiv@136.169.204.164 QUIT :Ping timeout: 256 seconds < 1603057865 572121 :Frater_EST!~adrianbib@75.107.60.35 QUIT :Read error: Connection reset by peer < 1603058371 326440 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1603058477 141928 :t20kdc!~20kdc@cpc139384-aztw33-2-0-cust220.18-1.cable.virginm.net QUIT :Remote host closed the connection < 1603059245 256517 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1603059868 205827 :deltadoge23!~deltaepsi@cpe-24-208-148-153.insight.res.rr.com JOIN :#esoteric < 1603059878 202865 :deltadoge23!~deltaepsi@cpe-24-208-148-153.insight.res.rr.com NICK :deltaepsilon23 < 1603059918 214889 :deltaepsilon23!~deltaepsi@cpe-24-208-148-153.insight.res.rr.com QUIT :Client Quit < 1603059947 35546 :deltaepsilon23!~deltaepsi@cpe-24-208-148-153.insight.res.rr.com JOIN :#esoteric < 1603060028 700031 :deltaepsilon23!~deltaepsi@cpe-24-208-148-153.insight.res.rr.com NICK :delta23 < 1603060435 710276 :Arcorann!~awych@121-200-5-186.79c805.syd.nbn.aussiebb.net JOIN :#esoteric < 1603060708 746343 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Remote host closed the connection < 1603062901 633613 :tromp!~tromp@dhcp-077-249-230-040.chello.nl JOIN :#esoteric < 1603062995 620951 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :rofl... I'm reading the specifications of a desktop speaker, and there's an entry saying "Waterproof: no" < 1603063121 635725 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Well, waterproofing is important for the times when you drink and read or watch something funny at the same time. < 1603063201 655567 :tromp!~tromp@dhcp-077-249-230-040.chello.nl QUIT :Ping timeout: 264 seconds < 1603063721 300977 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Aren't waterproof speakers pretty common? < 1603063765 465900 :int-e!~noone@int-e.eu PRIVMSG #esoteric :For outdoor use? < 1603063792 121985 :int-e!~noone@int-e.eu PRIVMSG #esoteric :I don't know. But "desktop" doesn't suggest any need for waterproofing to me. < 1603063849 795096 :int-e!~noone@int-e.eu PRIVMSG #esoteric :And speakers tend not to be waterproof by themselves... they're roomy, have cardboard pieces, possibly some cloth... < 1603063961 906899 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :on the plus side, the specifications are detailed. finally. < 1603063964 316000 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :I'll buy this one. < 1603063992 17846 :adu!~arobbins@c-76-111-99-194.hsd1.md.comcast.net JOIN :#esoteric < 1603064888 399183 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :crap, I pressed the wrong button < 1603065002 430866 :int-e!~noone@int-e.eu PRIVMSG #esoteric :mmm < 1603065112 442254 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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 < 1603065139 779109 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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 < 1603065288 426147 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :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. < 1603065319 589526 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :fizzie: heh < 1603065343 448884 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :ok, now this attempt succeeded, I have ordered the goodies < 1603065363 132587 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :including that speaker set < 1603065431 36147 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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 < 1603065533 736358 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :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 < 1603065539 708891 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :one) works just fine. < 1603065594 855645 :b_jonas!~x@catv-176-63-12-22.catv.broadband.hu PRIVMSG #esoteric :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?