| --- Log opened Fri Aug 18 00:00:08 2017 |
| 00:15 | <&McMartin> | Proposal: the opposite of "dryrun" should be "wetwork" |
| 00:35 | <@gnolam> | Running is work. |
| 00:36 | <@gnolam> | Rather, the opposite of a dry run should be a wet bar. |
| 00:37 | <&McMartin> | Well, part of the idea here is that when it isn't a dry run, you are killing things for real. |
| 00:42 | <@gnolam> | Brain cells. |
| 00:59 | | * McMartin learns about the Fast Inverse Square technique. |
| 01:00 | <&McMartin> | https://en.wikipedia.org/wiki/Fast_inverse_square_root |
| 01:00 | <&McMartin> | This is attn Vorn, for sure |
| 01:01 | <&McMartin> | // evil floating point bit level hacking |
| 01:01 | <&McMartin> | // what the fuck? |
| 01:01 | <~Vornicus> | It is indeed attn: vorn |
| 01:02 | <&McMartin> | "however, it is much slower and less accurate than using the SSE instruction rsqrtss on x86 processors also released in 1999" |
| 01:03 | <&McMartin> | I am always sad when people type pun with dereferences instead of with unions. |
| 01:05 | < RchrdB> | Every time I re-read the bit of the C99 spec about effective types of memory, the less I want to use anything other than memcpy(). |
| 01:05 | < RchrdB> | er |
| 01:05 | < RchrdB> | sentences |
| 01:07 | <@himi> | McMartin: unions are so inflexible . . . you can't just make shit up as you go along |
| 01:07 | <&McMartin> | himi: Sure, but you don't want to make shit up: you want access to the IEEE 754 bits. |
| 01:08 | <@himi> | Nonono, you want to make shit up! This the whole /point/ of using C, isn't it? |
| 01:08 | <&McMartin> | Not when computing fast inverse square root! |
| 01:08 | < RchrdB> | Let's try that again: every time I re-read that bit of the C99 spec about effective types of objects in memory, I trust existing C code less, and feel less comfortable about relying on anything other than memcpy() into a local variable. |
| 01:08 | <@himi> | . . . why wouldn't you just use the hardware? |
| 01:09 | | * himi goes to look at the article |
| 01:09 | <&McMartin> | ... because the instruction was introduced in 1999, and the technique was devised in 1986 |
| 01:09 | < RchrdB> | because the hardware didn't exist at the time |
| 01:10 | < RchrdB> | and the Quake team had to ship a game that worked on, well, let's say the median computer available at the time it came out, not the absolute latest chip that anyone had ever released |
| 01:10 | <@himi> | Okay, I /love/ the comments in the code sample |
| 01:10 | <&McMartin> | That is, as noted, 100% replicated Quake III Arena source code |
| 01:10 | < RchrdB> | I thought the approximate inverse square root was a 3DNow extension and that 3DNow eventually kinda got dropped? |
| 01:11 | <&McMartin> | 3DNow may have gotten dropped, but SSE sure didn't. |
| 01:11 | <&McMartin> | (Which also has it) |
| 01:11 | < Mahal> | those comments are DELIGHTFUL |
| 01:12 | <@himi> | My initial reading was that it was from the same era as Q3, but yeah, it's a lot earlier |
| 01:13 | | * McMartin digs through other stuff |
| 01:13 | < RchrdB> | to be fair the actual method has a perfectly rational, understandable explanation. |
| 01:13 | <&McMartin> | Indeed. |
| 01:14 | < RchrdB> | instead of "what the fuck" someone could have written 3 or 4 paragraphs explaining why it works |
| 01:14 | <&McMartin> | One merely needs to know basic differential calculus and the details of the IEEE 754 single-precision format |
| 01:14 | <&McMartin> | I am guessing the dude at id knew the technique but wasn't the dude at SGI who devised it, so it was A Magic Spell From Decades Past. |
| 01:14 | <&McMartin> | The evil/wtf stuff replaces what would otherwise be a lookup table |
| 01:15 | <&McMartin> | It seems 3DNow/SSE was originally an AMD/Intel split, but Intel's extensions became the norm so 3DNow was dropped. |
| 01:16 | <@himi> | I wouldn't be surprised if using unions would have blocked some optimisation path that wasn't affected by the casting, but it could also just be a case of taking the simplest approach 'cause it works |
| 01:17 | < RchrdB> | This was the 90s and "type based alias analysis" wasn't a thing that C compilers did at the time so everyone acted as though type punning through pointers was legal. |
| 01:18 | <@himi> | This is C - it's all just memory |
| 01:18 | < RchrdB> | Not even slightly true. |
| 01:18 | <&McMartin> | Unless you count every C system that existed in 1999 |
| 01:18 | < RchrdB> | According to the strict letter of the C99 spec, that pointer cast and dereference is UB and the program is meaningless. |
| 01:19 | <@himi> | While it's not true in the strict sense defined by the C standard, that's how C worked for most of its history |
| 01:19 | < RchrdB> | I'm not sure how strict the C89 standard was. |
| 01:19 | <&McMartin> | UB doesn't mean the program is meaningless. |
| 01:19 | < RchrdB> | Nobody took any notice of this because C compilers didn't start doing any of this until the 00s. |
| 01:19 | < RchrdB> | himi, yeah, de facto C differed from de jure C a lot. |
| 01:19 | <@himi> | And I expect most C compilers can still be coaxed into acting like this |
| 01:21 | <&McMartin> | This in fact works on clang with not a single byte of lint output under -Wall. |
| 01:22 | <@himi> | Did you specify any C standard level? Or is that just using whatever it decides to do on its own? |
| 01:22 | <&McMartin> | Default, which would be --gnu89, yeah, let's try std=c99 |
| 01:22 | | * himi isn't familiar with using clang |
| 01:22 | <&McMartin> | --std=c99 also produces no complaints and identical results. |
| 01:23 | <@himi> | What does gcc say with c99 specified? |
| 01:23 | <&McMartin> | that said, the fact that 1.0f turns into 0x3f800000 is here relying on two rather important things |
| 01:23 | <&McMartin> | (a) that sizeof(int) == sizeof(float) |
| 01:23 | <&McMartin> | (b) That float means IEEE 754 single precision |
| 01:23 | <&McMartin> | Neither of those has to be true |
| 01:24 | <&McMartin> | But "memcpy()ing into a local variable" also relies on both of those things. |
| 01:24 | <&McMartin> | I don't have gcc on this system, funnily enough |
| 01:24 | <@himi> | This is pretty much the definition of unsafe code, though - if you're willing to use this you're not too concerned about correctness in most senses |
| 01:24 | <&McMartin> | I consider it the equivalent of including inline assembler |
| 01:25 | <~Vornicus> | (you can come up with equivalents for other precisions, of course) |
| 01:29 | <@himi> | gcc doesn't complain at all either |
| 01:32 | < RchrdB> | C compilers aren't required to give you a diagnostic when you feed them code that will perform UB. |
| 01:32 | <&McMartin> | Hm. I wonder if cc65 uses the five-byte floats. |
| 01:33 | <@himi> | Adding the extra iteration makes a /big/ difference to the accuracy |
| 01:36 | <&McMartin> | It would be interesting to see the situations in which this UB actually doesn't do the obvious thing: viz. why they elected to not specify the behavior even informally. |
| 01:37 | < RchrdB> | Ah I think I know why I'm wrong about this one. |
| 01:37 | <&McMartin> | (a la C++'s reinterpret_cast<>, which is defined as doing the type pun and then specifying the maximal set of cases where this must make sense) |
| 01:38 | <&McMartin> | (But implementations are *allowed* to have it make sense in broader contexts, and bits_of_float/float_of_bits is a very common one) |
| 01:38 | < RchrdB> | The C99 spec says «An object shall have its stored value accessed only by an lvalue expression that has one of the following types…» where that "shall" means "you get UB if you violate this rule" |
| 01:39 | < RchrdB> | I've interpreted that rule overly broadly. This rule does not make it UB to *read* through a pointer of the wrong type, just write through one. |
| 01:40 | <&McMartin> | Does the C99 spec distinguish UB from, um, ID the way Scheme does? |
| 01:40 | <&McMartin> | (Though for scheme, UB is "it is an error" and part of an entirely different conceptual class of things than "implementation-dependent") |
| 01:40 | <@himi> | I can't actually see any warning options in the gcc man page (v6.3) that look like they'd complain about this usage |
| 01:40 | < RchrdB> | implementation defined is a very separate thing |
| 01:41 | <@himi> | RchrdB that's kind of implying what I said way back, then - it's all just memory (with the proviso that this is only true if you're reading) |
| 01:41 | < RchrdB> | UB is formally "the implementation is allowed to ignore the possibility of you doing this, so if you do then there are no restrictions whatsoever on the code that the implementation produces", which is why I use the word "meaningless" for programs. |
| 01:42 | < RchrdB> | himi, this isn't the only problem with acting like the C99 abstract machine acts identically to a 386 from the 90s, though. |
| 01:43 | <&McMartin> | RchrdB: Right, that's why I want to see the counterexample, as it were. |
| 01:43 | < RchrdB> | There's also stuff like "computing a pointer which points anywhere other than (inside a valid object) or (one past a valid object) is illegal" |
| 01:43 | <&McMartin> | Because ARM seems to work the same way and I'm pretty sure MIPS does too. |
| 01:43 | <@himi> | Oh, definitely - you can't treat any modern system that way safely, which is why C is such a clusterfuck for security |
| 01:44 | <@himi> | But that /is/ a large part of the C paradigm |
| 01:44 | < RchrdB> | McMartin, what I mean is the C abstract machine doesn't behave like *any* physical architecture |
| 01:44 | <&McMartin> | Basically, I'm curious as to when doing the int/float type pun (when sizeof(int)==sizeof(float)) *doesn't* produce something like |
| 01:44 | <&McMartin> | 0000000100000f55movss%xmm0, -0x14(%rbp) |
| 01:44 | <&McMartin> | 0000000100000f5amovl-0x14(%rbp), %edi |
| 01:44 | <&McMartin> | 0000000100000f5dmovl%edi, -0x18(%rbp) |
| 01:46 | < RchrdB> | McMartin, I think this specifically is fine. There are some gotchas where the C spec says doing some questionable things with floats counts as UB because hypothetically that float could have a trap representation and trapping is undefined. |
| 01:47 | <&McMartin> | This isn't just "sure, no real machine is the C99 machine", it's "we can't assume _____ because _____" |
| 01:48 | <&McMartin> | (And as noted, the ultimate escape on this would be to drop into assembler to do it, which is presumably what Ocaml does for its primitives that perform that type pun) |
| 01:48 | <@himi> | McMartin I assume you wouldn't count multiprocessor issues? |
| 01:48 | <&McMartin> | himi: I mean, there's more going on in those three instructions than just the type pun, too; it's filling two local variables with "the float" and "the int" |
| 01:49 | < RchrdB> | an example: we can't assume "just because the hardware would do something sensible with a bit shift exceeding the width of the integral type it was performed on, that doing that is okay" because "cc is allowed to compile code that does that into anything" |
| 01:49 | <@himi> | 'cause that's a hell hole as far as the broad "it's all memory" view goes |
| 01:49 | <&McMartin> | But the general technique would be "write from the FP register bank into memory" then "read from the same memory into the integral register bank" |
| 01:50 | <&McMartin> | There are trivial reasons that can put you in Dragons territory, such as, say, floating point numbers being 5 or 7 bytes long, as in the C64's ROM-based software FP. |
| 01:50 | <&McMartin> | But I set an additional compiler-checkable assertion first |
| 01:51 | <&McMartin> | the other part of UB here is "can you assume you will get any particular value out" and the answer to that is "no" from a "specified behavior" standpoint but "examining the results is a method of interrogating the hardware" elsewhere. |
| 01:52 | <&McMartin> | If I send the multiplicative identity in and I don't get 0x3f800000 out, I can conclude I'm not using IEEE floating point |
| 01:52 | <@himi> | The only thing I can think of that might cause issues would be whether the read and write might not be done in the correct order, and I'm struggling to think of a situation where that wouldn't be guaranteed? |
| 01:53 | | * himi is ill and not thinking all the clearly, though |
| 01:53 | <&McMartin> | -0x14(%rbp) is written, then read in the next instruction |
| 01:53 | <&McMartin> | That "should" introduce a data hazard |
| 01:53 | <@himi> | As in, the hardware not necessarily guaranteeing it |
| 01:53 | <&McMartin> | Right |
| 01:54 | <&McMartin> | OK, that could do it if the compiler did not treat FP writes and integer reads as interfering |
| 01:54 | <&McMartin> | But that would be very odd because -0x14(%rbp) is getting "a write" followed by "a read" |
| 01:54 | <@himi> | obviously if you're in a multiprocessor setup weird shit can happen, but I can't think of any OoO architectures that would mess that ordering up within a thread of execution |
| 01:54 | <&McMartin> | MIPS might. |
| 01:55 | <&McMartin> | ... wait no |
| 01:55 | <&McMartin> | That's backwards |
| 01:55 | <&McMartin> | A hazard on a *register* could do it |
| 01:55 | <&McMartin> | If I load into r2 and then use r2 in the very next instruction, I think you end up getting the old value |
| 01:56 | <&McMartin> | But if there are *two* memory delays the whole thing is delayed. |
| 01:56 | < RchrdB> | On MIPS? |
| 01:56 | <&McMartin> | I's been a really long time since I read my Intro to Architecture class. |
| 01:57 | <@himi> | We're assuming these are 32 bit, so there shouldn't be any need to do anything outside of single register operations |
| 01:57 | <&McMartin> | But I definitely remember that MIPS manages to avoid needing a "Return from Interrupt" instruction because some instructions (in particular, jump-to-register) don't take effect until the next instruction commits. |
| 01:58 | <&McMartin> | (And thus you can slot in your "re-enable interrupts" command there~) |
| 01:58 | < RchrdB> | I think I heard Itanium was supposed to have "the ISA doesn't require writes to registers to turn up straight away, you have to do something else (even if just NOPing) for a defined number of cycles before you can read the result of assigning a register back" baked in |
| 01:59 | <&McMartin> | MIPS *definitely* had a bit of that going on, but didn't have the VLIW part. |
| 01:59 | < RchrdB> | as opposed to all the CPUs that weren't colossal market failures on which reading a register you just wrote stalls execution. |
| 01:59 | <&McMartin> | What I don't remember is if loading a register from memory did that |
| 01:59 | <@himi> | RchrdB Itanic was insane, though |
| 01:59 | <&McMartin> | I would not call MIPS a colossal market failure. |
| 01:59 | <&McMartin> | It dominated the fifth generation of video game consoles. |
| 02:00 | <@himi> | MIPS wasn't a market failure any more than SPARC was, or any of the other big RISC architectures that aren't POWER or ARM |
| 02:00 | <&McMartin> | It then promptly sank without a trace outside of being the default instructional architecture in the United States |
| 02:00 | <&McMartin> | But. |
| 02:00 | <@himi> | None of them /won/, but none of them were backed by Intel |
| 02:00 | < RchrdB> | I was dissing Itanic there rather than MIPS but uh |
| 02:01 | <&McMartin> | That said |
| 02:01 | <&McMartin> | I blame the Itanic's VLIW focus for its unusability |
| 02:02 | <&McMartin> | Correcting for delayed-effect instructions is literally an undergrad lab assignment. |
| 02:02 | < RchrdB> | mm |
| 02:02 | <&McMartin> | You have the assembler emit no-ops, or do the hazard analysis and reorder appropriatetly if you're feeling cocky. |
| 02:03 | < RchrdB> | I've heard the conspiracy theory that Itanium was actually a good thing for Intel, not as a product that sold and made money, but because Intel convinced so many companies that otherwise might have tried to compete with Intel to stop making their own RISC architectures and jump on the Itanium bandwagon |
| 02:04 | <&McMartin> | ... who would those companies be? |
| 02:04 | <@himi> | RchrdB: if that was the result I'm about 99% sure it was a fortuitous accident for Intel, and I don't really think it's a valid argument |
| 02:04 | <&McMartin> | The only one I can think of was DEC |
| 02:04 | < RchrdB> | There were at least 4 of 5 of them I think. HP killing HP-PA is the only one I can remember right now. |
| 02:05 | < RchrdB> | *4 or 5 |
| 02:05 | <&McMartin> | Well, there's two |
| 02:05 | <@himi> | Yeah, HP/Compaq after taking on DEC is the only one that might have been a threat to /some/ of Intel's market, I think |
| 02:06 | <&McMartin> | I tend to think that what did in Itanium was not intentional fuckwittery but simply failing to account for the power superscalar architectures ultimately provided. |
| 02:06 | <@himi> | HP-PA was probably going away anyway, Alpha at least had potential (with proper support) for high end computational stuff |
| 02:06 | <&McMartin> | Alpha was indeed what I was thinking of up there |
| 02:07 | < RchrdB> | Wikipedia cites SGI abandoning further work on MIPS too. |
| 02:08 | <@himi> | Alpha had a /significant/ lead in the HPC area, which Intel makes big chunks of cash off and which helps drive their never-ending push for bigger and better vector units |
| 02:08 | <&McMartin> | Yeah. As I said, its only remaining use is as an instructional architecture |
| 02:08 | <&McMartin> | And while it was omnipresent in my academic career, (a) that was in the late 1990s and early 2000s and (b) I went to both Patterson *and* Hennessey's universities. |
| 02:08 | <@himi> | Take away a big chunk of that maket and Intel wouldn't have the computational architecture lead it does now |
| 02:08 | < RchrdB> | *as a consequence of a decision to jump on Itanium I mean |
| 02:09 | <@himi> | MIPS was still big in the embedded space, though? |
| 02:10 | <&McMartin> | "As of April 2017, MIPS processors are used in embedded systems such as residential gateways and routers." |
| 02:10 | < RchrdB> | Lots of embedded MIPS cores are still being manufactured. The embedded space doesn't have the same kind of pressures resisting ISA diversity that the workstation space has. |
| 02:10 | <&McMartin> | ARM pretty much crushed the rest of that space |
| 02:10 | <@himi> | McMartin: yeah, but back when Itanic launched MIPS was still a contender for beating ARM |
| 02:10 | <&McMartin> | But the MIPS usage people *remember* are the N64, PS1, PS2, and PSP. |
| 02:11 | < RchrdB> | I believe the situation now is that, if you're designing a new small electronic thing that needs some CPUs, and you choose an ISA other than ARM, then you need to be quite convincing in order to justify that decision to your boss. |
| 02:11 | < RchrdB> | but like there's still weird shit like stack based CPUs designed by STMicro kicking around in TV set-top boxes |
| 02:11 | <@himi> | RchrdB: unless you're going /really/ small, but these days even there ARM is muscling in thanks to process imrpovements |
| 02:12 | <&McMartin> | Atmel and (of all people) Zilog are still doing pretty brisk business there. |
| 02:12 | | * McMartin also re-checks. "MIPS does indeed have a load delay slot." |
| 02:12 | < RchrdB> | Does it have a branch delay thing too? |
| 02:12 | <&McMartin> | Yes. |
| 02:13 | <&McMartin> | That one I *knew* existed, though, because of the whole no-RTI trick. |
| 02:13 | < RchrdB> | I think I remember hearing SPARC had a thing where you couldn't jump too soon after deciding which instruction you were going to jump to. |
| 02:13 | < RchrdB> | I didn't know if MIPS had that too. |
| 02:13 | <@himi> | Atmel is definitely still doing well, but they're seeing more competition - there's less and less need to stick with something as limited as what Atmel provides when there are stupidly tiny ARM SoCs that are only /slightly/ bigger and more expensive |
| 02:14 | <&McMartin> | RchrdB: That sounds more like an arithmetic delay slot |
| 02:14 | <&McMartin> | ... also, apparently, post-1989, MIPS did not have a load delay slot, so, welp |
| 02:15 | < RchrdB> | McMartin, I think SPARC has "you have to have a 1-instruction gap between the instruction that sets a flag and a conditional jump that examines that flag" |
| 02:15 | <&McMartin> | Correction: architectures past 1989 didn't have the load delay slot, but the chips that had them stiltl existed |
| 02:16 | <&McMartin> | In particular, the N64 and PS2 did not have load delays but the PS1 did. |
| 02:16 | < RchrdB> | oh wait I just remembered something |
| 02:16 | < RchrdB> | McMartin, MIPS! Have you heard of a thing called Loongson? |
| 02:16 | <&McMartin> | Not offhand, one moment |
| 02:17 | < RchrdB> | the PRC had a project called Loongson where they designed some new CPUs implementing the MIPS architecture from scratch |
| 02:17 | < RchrdB> | totally from-scratch implementation from the Chinese Academy of Sciences |
| 02:17 | <&McMartin> | So it seems. |
| 02:17 | < RchrdB> | er, MIPS64 |
| 02:18 | <&McMartin> | This Wiki article includes a lot of future tense when referring to years like 2010 |
| 02:18 | < RchrdB> | I think there's more than one theory about why they did it but I have a conspiracy theory about why that hinges entirely on commies |
| 02:18 | <&McMartin> | "Expected to launch in August 2011" |
| 02:19 | < RchrdB> | I think they did it because they wanted to be able to manufacture computers for military use that they know pretty much definitely aren't suborned by the US or any foreign power because the entire supply chain sits inside China |
| 02:19 | <&McMartin> | That's not much of a conspiracy theory |
| 02:19 | <&McMartin> | This is pretty much why the US still has its own semiconductor industry |
| 02:20 | < RchrdB> | yeah but the Financial Times theory is that the project was going to try to out compete Intel or some shit like that |
| 02:21 | < RchrdB> | so, punchline |
| 02:21 | < RchrdB> | * Yes they were actually manufactured. I believe you can still buy the hardware. Not all that much of it was sold internationally though. |
| 02:23 | <@himi> | I believe I've seen reviews of that chip, or something similar, which showed it performing decently compared to near-current CPUs |
| 02:23 | < RchrdB> | * Some free software nerds got super excited about them because I think they have little to no closed-source firmware and also they almost certainly aren't suborned by the NSA. I think Richard Stallman might have bought one? I believe OpenBSD supports it too for about this reason. |
| 02:24 | < RchrdB> | * The chips are really entertainingly buggy. There's a hard-lockup bug in the NOP instruction. |
| 02:24 | < RchrdB> | (or at least there was in some generations of the hardware) |
| 02:26 | <&McMartin> | "They almost certainly haven't been suborned by the NSA" |
| 02:26 | < RchrdB> | So a bunch of open source compiler backends that can target MIPS64 (like gcc, llvm) got patched shortly after Loongson came out that allowed them to emit a different "do nothing" instruction in places where they need a NOP. |
| 02:26 | <&McMartin> | How close did they look for it being suborned by anyone else~ |
| 02:26 | < RchrdB> | Heehee I said that deliberately. I was being quite precise. :) |
| 02:27 | <~Vornicus> | how do you manage hard-lockup in NOP |
| 02:27 | <~Vornicus> | and furthermore, how do you manage to not find and fix that |
| 02:27 | <&McMartin> | You just NOP right the fuck out |
| 02:27 | < RchrdB> | I think for some threat models, such as "being a commie living in the United States", using a laptop that is suborned by the PRC isn't really a problem but using a laptop that is suborned by the NSA is a huge problem. |
| 02:27 | <~Vornicus> | *sad trombones* |
| 02:28 | <&McMartin> | s/commie/Klansman/ |
| 02:28 | <&McMartin> | I don't think CPUSA ever managed to accomplish anything dramatic and that's the one that actually *was* up to its ears in KGB. |
| 02:29 | < RchrdB> | I would assume that the PRC's state organs don't really give a fuck about, say, Richard Stallman, whereas the USA's state organs still have a McCarthyite streak. |
| 02:30 | <&McMartin> | Honest question: Is there any evidence whatsoever that the USA's state organs give the tiniest of fucks about Richard Stallman beyond heavily funding shitloads of projects that use GNU software in the stack |
| 02:30 | < RchrdB> | Unlikely, but dumber things have happened. |
| 02:30 | | Turaiel[Offline] is now known as Turaiel |
| 02:31 | < RchrdB> | e.g. Ernest Hemingway got gaslit by secret agents following him around for decades of his life. |
| 02:32 | <&McMartin> | That's why I'm asking if there's evidence |
| 02:32 | < RchrdB> | But there wouldn't be? |
| 02:32 | <&McMartin> | ... but there is? |
| 02:32 | < RchrdB> | Hemingway never had any evidence because, y'know, spies are kind of sneaky? |
| 02:32 | <&McMartin> | Oh |
| 02:32 | <&McMartin> | OK then |
| 02:33 | <&McMartin> | Is there any evidence of that, then |
| 02:33 | <&McMartin> | Because we *do* have evidence for, say, MLK Jr |
| 02:33 | <&McMartin> | And know that they tried to drive him to suicide |
| 02:33 | < RchrdB> | yeah it got proven after his death from records being unsealed |
| 02:33 | < RchrdB> | the spies were keeping paperwork |
| 02:33 | <@himi> | I'm not sure how easily you could tell with rms |
| 02:33 | <@himi> | The guy's a little . . . odd |
| 02:33 | <&McMartin> | And yeah, like |
| 02:34 | <&McMartin> | the idea that the US government is opposed to free software is laughable on its face |
| 02:34 | <@himi> | Disturbingly likely to be right about how shitty things can get, but very much odd |
| 02:35 | <&McMartin> | The idea that it would be specifically opposed because zomgcommies is "I am using a cartoon version of the US that sounds like it's coming from communist propaganda itself" |
| 02:36 | <@himi> | The US government is more likely to be opposed because it challenges corporate hegemonies |
| 02:36 | <&McMartin> | Reminder that GNAT and Tor both exist |
| 02:36 | <&McMartin> | Also, reminder that Tor is a project of US Naval Intelligence, so using it to hide from the US is possibly not a great plan if you are conspiracy-minded |
| 02:37 | | jeroud [sid10043@Nightstar-6br85t.irccloud.com] has quit [Ping timeout: 121 seconds] |
| 02:37 | | jeroud [sid10043@Nightstar-6br85t.irccloud.com] has joined #code |
| 02:37 | | mode/#code [+ao jeroud jeroud] by ChanServ |
| 02:38 | < RchrdB> | You don't have to have the whole US govt wanting you dead to have trouble with the US govt though; you just have to have one or more people who've got power who have an irrational dislike of you. |
| 02:38 | < RchrdB> | or any government |
| 02:39 | < RchrdB> | You could have the metropolitan police beating up your landlord in the morning and the British army inviting you around for tea and crumpets in the afternoon if you manage to get exactly the right set of people to adore and despise you |
| 02:45 | | Degi_ [Degi@Nightstar-q8g29f.dyn.telefonica.de] has joined #code |
| 02:45 | | Degi [Degi@Nightstar-klgs3m.dyn.telefonica.de] has quit [Ping timeout: 121 seconds] |
| 02:47 | | Degi_ [Degi@Nightstar-q8g29f.dyn.telefonica.de] has quit [[NS] Quit: Leaving] |
| 02:47 | | Degi [Degi@Nightstar-q8g29f.dyn.telefonica.de] has joined #code |
| 02:48 | | * Vornicus writes the final lines of code for his collision checker |
| 02:48 | <~Vornicus> | ...which is to say, an augmented max. |
| 03:21 | | RchrdB [RchrdB@Nightstar-qe9.aug.187.81.IP] has quit [Connection closed] |
| 03:53 | | * Vornicus perpares a graphical demo, determines he must have done *something* wrong, tries to figure out what that is. |
| 03:57 | < Mahal> | try preparing it next time, not perparing? |
| 03:57 | <~Vornicus> | it was pebcak. I put the vertices in in the wrong order. Also I put the wrong signs on the radii. |
| 03:57 | <~Vornicus> | Holy shit guys. |
| 03:58 | <~Vornicus> | https://www.twitch.tv/vornotron holy shit guys |
| 03:59 | <~Vornicus> | oop. there are a couple of not perfect spots. More work to do. |
| 04:41 | | Degi [Degi@Nightstar-q8g29f.dyn.telefonica.de] has quit [Connection reset by peer] |
| 04:41 | <~Vornicus> | oh. derp, that has nothing at all to do with arcs. It's the way I handle *corners* that's a problem, and that's higher up. |
| 04:43 | | Reiv [NSkiwiirc@Nightstar-ih0uis.global-gateway.net.nz] has joined #code |
| 04:43 | | mode/#code [+o Reiv] by ChanServ |
| 05:00 | | Jessikat` [Jessikat@Nightstar-sra32q.dab.02.net] has joined #code |
| 05:01 | | Jessikat [Jessikat@Nightstar-471.159.132.82.IP] has quit [Ping timeout: 121 seconds] |
| 05:29 | | Derakon is now known as Derakon[AFK] |
| 06:27 | | Turaiel is now known as Turaiel[Offline] |
| 09:21 | | Kindamoody[zZz] is now known as Kindamoody |
| 09:36 | | macdjord|slep [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 09:36 | | mode/#code [+o macdjord|slep] by ChanServ |
| 09:38 | | mac [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 10:09 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 10:12 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has joined #code |
| 10:12 | | mode/#code [+o Alek] by ChanServ |
| 11:10 | | Jessikat` is now known as Jessikat |
| 11:30 | | Jessikat` [Jessikat@Nightstar-7kilur.dab.02.net] has joined #code |
| 11:33 | | Jessikat [Jessikat@Nightstar-sra32q.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 12:36 | | Reiv [NSkiwiirc@Nightstar-ih0uis.global-gateway.net.nz] has quit [Ping timeout: 121 seconds] |
| 14:04 | | Kindamoody is now known as Kindamoody|out |
| 14:31 | | Degi [Degi@Nightstar-q8g29f.dyn.telefonica.de] has joined #code |
| 14:47 | | mac [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 14:47 | | mode/#code [+o mac] by ChanServ |
| 14:49 | | macdjord|slep [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 14:58 | | bowlich [bowlich@Nightstar-su4ao3.kynda.net] has quit [Ping timeout: 121 seconds] |
| 14:58 | | bowlich [bowlich@Nightstar-su4ao3.kynda.net] has joined #code |
| 16:49 | | Jessikat` is now known as Jessikat |
| 17:47 | | Turaiel[Offline] is now known as Turaiel |
| 17:56 | | Turaiel is now known as Turaiel[Offline] |
| 18:00 | | Jessikat` [Jessikat@Nightstar-183a7n.dab.02.net] has joined #code |
| 18:01 | | Jessikat [Jessikat@Nightstar-7kilur.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 18:01 | | Turaiel[Offline] is now known as Turaiel |
| 19:31 | | Jessikat [Jessikat@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
| 19:35 | | Jessikat` [Jessikat@Nightstar-183a7n.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 20:43 | | Degi [Degi@Nightstar-q8g29f.dyn.telefonica.de] has quit [Connection closed] |
| 20:44 | | Degi [Degi@Nightstar-q8g29f.dyn.telefonica.de] has joined #code |
| 20:44 | <@mac> | a^2 + b^2 = E/m |
| 20:45 | | Degi_ [Degi@Nightstar-lse1e4.dyn.telefonica.de] has joined #code |
| 20:46 | <~Vornicus> | ellipses time? |
| 20:48 | <@mac> | Vornicus: c^2 |
| 20:48 | | Degi [Degi@Nightstar-q8g29f.dyn.telefonica.de] has quit [Ping timeout: 121 seconds] |
| 20:49 | <~Vornicus> | oh, being silly |
| 21:20 | <@TheWatcher> | Interesting fact: you can't count how many characters are in uppercase in a string, if you convert it all to lowercase before counting the characters. |
| 21:20 | <~Vornicus> | pff |
| 21:24 | < Jessikat> | LoL |
| 21:24 | <@Tamber> | Oh, you can! But it saves time if you just hardcode it~ |
| 21:25 | <@TheWatcher> | Anyway, now killbot should be more sensitive to our shouty spammer. |
| 21:27 | <@TheWatcher> | (Which includes the glorious line 'my $count = () = $msg =~ m/[\p{IsLt}\p{IsLu}]/g;') |
| 21:28 | <&[R]> | <bk> I haven't seen anything pro-trump, but I think I'll spamfilter .onion IRC links |
| 21:28 | <&[R]> | (ircop elsenetwork) |
| 21:31 | | Kindamoody|out is now known as Kindamoody |
| 21:55 | | Kindamoody is now known as Kindamoody[zZz] |
| 22:25 | <@mac> | TheWatcher: Are you summoning codethulu again? |
| 22:26 | <@TheWatcher> | Maaaayyybeee |
| 22:33 | <~Vornicus> | oh god so happy i have finishes the collider |
| 22:33 | <~Vornicus> | Now it's time to write ... a whole bunch of other shit |
| --- Log closed Sat Aug 19 00:00:09 2017 |