05:22 <rqou> apparently my apartment can pretty-consistently handle about two and a half minutes of microwaving before the circuit breaker trips

05:23 <rqou> obviously the solution is to break up microwaving into two-and-a-half-minute chunks :P

05:24 <rqou> alternately, we can engineer an InternetOfShit device that detects tripping and uses a little servo to reset the breaker immediately

05:24 <rqou> :P

05:25 <rqou> it'll be no worse than the product featured on InternetOfShit that you plug your shitty wifi router into so that it detects when the router froze up and reboots it for you

05:35 <whitequark> rqou: just tape it in the "ON" state

05:35 <whitequark> same result, less effort

05:35 <rqou> is that how it works in russia? :P :P

05:36 <whitequark> dunno

05:37 <whitequark> I just changed the RCD when I had a similar problem (the RCD was faulty in that case)

05:37 <whitequark> have you tried, I dunno, plugging in less shit?

05:37 <rqou> well, we kinda tried

05:37 <rqou> it turns out that it then becomes too cold because the wall insulation is shit

05:38 <whitequark> have you tried using clothes

05:38 <whitequark> it's far cheaper than heating, generally

05:39 <rqou> so right now i'm apparently using in total about 450W

05:39 <whitequark> that's 4A.

05:39 <whitequark> your microwave is what, 10A?

05:40 <rqou> our breaker is 2x 30A, but i have no idea how the phases are balanced

05:40 <whitequark> have you measured the actual current.

05:40 <rqou> i haven't because there isn't any obvious way to do that

05:40 <whitequark> um

05:40 <whitequark> https://en.wikipedia.org/wiki/Current_clamp

05:41 <rqou> there's no obvious way to clamp on the right wires

05:41 <rqou> have you _seen_ the "wiring closet" here? :P

05:41 <rqou> i'll get a picture tomorrow (it's raining right now and i don't want to go outside again

05:42 <rqou> almost all of my equipment is going through a UPS (not including the electronics lab that isn't in use right now) so that is measuring the 450W

07:03 <openfpga-github> [openfpga] rqou commented on issue #79: So from a combination of Google and poking around the Linux source code (combined with the fact that it works), I'm pretty sure you do need to prepend a 0 byte. The Linux hidraw source code contains the [same report-ID-skipping logic](http://lxr.free-electrons.com/source/drivers/hid/usbhid/hid-core.c#L933) as the hidapi libusb backend.... https://git.io/vylOx

07:06 <openfpga-github> [openfpga] rqou commented on issue #79: According to [this blog post](http://eleccelerator.com/tutorial-about-usb-hid-report-descriptors/), report IDs only appear on the wire **iff there is a possibility of having more than one** (as determined by the presence of `REPORT_ID`). If there isn't, you just send on the wire the bytes described by the descriptor which in our case is "64 bytes of undefined contents." https://git.io/vyl3f

07:24 <openfpga-github> [openfpga] rqou commented on issue #79: So what seems to be happening in the data[0]=0x01 case (at least on Linux) is that the kernel layers end up seeing a report ID of 1 followed by 63 report bytes. The kernel doesn't care that the descriptor doesn't specify that a report ID of 1 exists and just concatenates these (implemented by never splitting them in the first place) and sends 64 bytes onto the wire. Without the patch, the kernel se

08:04 <openfpga-github> [openfpga] whitequark commented on issue #79: So... with absolutely no disrespect to @cyrozap, whose work I appreciate, I'm not sure if merging this PR is a good idea. It adds a dependency that's rather annoying to build on Windows (because Windows) and macOS (because it requires autotools), and libhidraw does not have particularly good code (just try reading some of it). I would much rather see a clean reimplementation of libhidraw that

08:08 <openfpga-github> [openfpga] rqou commented on issue #79: Hmm, I had no trouble at all cross-building hidapi for Windows from a Linux host. Building it for macOS didn't work with either autocrap or the manual makefile, but one of them managed to produce a .o file that you can pretend is the .a file and it will still work. The code is a little bit disgusting, but IMHO so would "working with IOKit" and "working with hid.dll/the DDK" become after a while. We

12:03 <whitequark> wtf, apple

12:03 <whitequark> why does xcode 8.2 deploy *only* to ios 10

12:03 <whitequark> why do you not offer older sdk for download separately

12:04 <whitequark> I don't want to download a 4.8GB dmg only to find out that it inexplicably doesn't support 9.3 anyway

12:04 <nats`> trololololo

12:04 <nats`> APPLE !

12:05 <whitequark> all this to debug a single armv7 segfault in a single configuration

12:08 <whitequark> azonenberg: if you thought flash was hard to secure... https://twitter.com/elisewho/status/838337519515140096

14:20 <qu1j0t3> whitequark: I wonder if this helps? https://github.com/devernay/xcodelegacy

14:21 <qu1j0t3> whitequark: Although the work here is for OS X SDKs. They say the same technique could add iOS SDKs

17:44 <manderbrot> whitequark: sign in with apple id and you can download older xcode versions here: https://developer.apple.com/download/more/

17:45 <manderbrot> if you're in the mood for potential headaches, you can have multiple versions installed and use xcode-select

17:47 <manderbrot> I wouldn't recommend trying to add older SDKs to a newer install. There's likely build scripts reliant on subtleties in the xcode is was shipped with