| --- Log opened Tue Jul 23 00:00:41 2019 |
| 01:27 | | Degi [Degi@Nightstar-as9iq6.dyn.telefonica.de] has quit [Connection closed] |
| 01:55 | <@celmin|away> | [Jul 22@2:11:09pm] jeroud: I know this because I am at band practice trying to think about music instead of being angry about how so many people seem okay with the garbage fire that is so much of the software the modern world is built on. |
| 01:55 | | * celmin|away clicks the Like button. |
| 01:57 | | celmin|away is now known as celticminstrel |
| 03:17 | | McMartin [mcmartin@Nightstar-ipm463.ca.comcast.net] has quit [[NS] Quit: Reboot] |
| 03:19 | | McMartin [mcmartin@Nightstar-ipm463.ca.comcast.net] has joined #code |
| 03:19 | | mode/#code [+ao McMartin McMartin] by ChanServ |
| 03:21 | <@Reiv> | Signs you know this one is gonna be a bit of a ride: "I’m actually using the Virtual AGC simulator for the AGC, as there are very few running AGCs in the world. One, to be precise. There may be one other functional AGC somewhere in interplanetary space, but as it hasn’t been powered on for over fifty years it could probably use some work. Plus, acc |
| 03:21 | <@Reiv> | ess is hard" |
| 04:05 | | celticminstrel [celticminst@Nightstar-6an2qt.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 06:25 | | Reiv [NSkiwiirc@Nightstar-ih0uis.global-gateway.net.nz] has quit [[NS] Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] |
| 07:24 | <&jeroud> | The AGC was not the first major project to use ICs (it was the second), but it was the first to use them successfully. |
| 07:26 | <&jeroud> | Primarily because the clever people at the MIT Instrumentation Lab figured out how to do QC on them and rejected the >50% that were likely to fail. |
| 07:28 | <&jeroud> | Derakon: I'm not arguing for "craftsmanship" (although I think that's pretty important too), I'm arguing for "build tools that are not trivially unfit for purpose outside of a very narrow range of environments". |
| 07:36 | | Alek [Alek@Nightstar-o723m2.cicril.sbcglobal.net] has quit [Ping timeout: 121 seconds] |
| 07:45 | | Alek [Alek@Nightstar-o723m2.cicril.sbcglobal.net] has joined #code |
| 07:45 | | mode/#code [+o Alek] by ChanServ |
| 07:52 | <&jerith> | Oh, Derakin's not here. |
| 07:54 | <&jerith> | A while ago I thought about starting a software methodology movement called "stop for five minutes and think about it", which would advocate for stopping to think about the thing you're about to do before charging ahead with it. |
| 09:01 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 09:01 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 09:51 | <@TheWatcher> | jerith: aintnobodygottimeforthat.jpg :/ |
| 09:52 | <&jerith> | Yeah, that's the problem. |
| 10:33 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 12:20 | <&jeroud> | While I'm still on this topic, I burned two hours today trying to deal with an undocumented change in `kustomize` that broke everything with a patently incorrect error message. (Something along the lines of "can't find <thing>" where thing is clearly there and previous versions can find it just fine.) |
| 12:29 | | celticminstrel [celticminst@Nightstar-6an2qt.dsl.bell.ca] has joined #code |
| 12:29 | | mode/#code [+o celticminstrel] by ChanServ |
| 12:37 | | Vash [Vash@Nightstar-sjaki9.res.rr.com] has joined #code |
| 13:01 | | celticminstrel [celticminst@Nightstar-6an2qt.dsl.bell.ca] has quit [[NS] Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.] |
| 15:36 | | Vash [Vash@Nightstar-sjaki9.res.rr.com] has quit [[NS] Quit: Leaving] |
| 16:43 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has joined #code |
| 18:55 | <&McMartin> | My main project lately has been trying to get MediaToolbox to actually do the things its documentation says it should do |
| 18:55 | <&McMartin> | I acknowledge that they are attempting to do the MIT approach here |
| 18:55 | <&McMartin> | They failed, and then didn't document it |
| 18:55 | <&McMartin> | Now I have to find out what the API restrictions actually are, and the primary reliable way of discovering such is to alter things and then ship them and see what that does to crash rates. >_< |
| 18:56 | <&McMartin> | "We can no longer repro the crash with our testing regimen, which we keep expanding each time" has had no relationship to crashes up or crashes down, but it has yet to mean "crash eliminated". |
| 19:06 | <&jerith> | "MIT approach"? |
| 19:07 | <&McMartin> | The one that is the alternative to "Worse is Better" in the "Worse is Better" talk. |
| 19:07 | <&jerith> | Ah. |
| 19:07 | <&McMartin> | I refuse to refer to it by its name in-talk of "The Right Thing" because it crashes all the time and has no documentation of its internals, which is clearly not The Right Thing. |
| 19:08 | <&McMartin> | But since this API was also added in iOS 11, and I started working in this problem space when iOS 9 was the new hotness |
| 19:09 | <&McMartin> | I can also say with confidence that it's still doing better than our own attempts at solving the problem acceptably |
| 19:15 | <&jerith> | I find I use a combination of those approaches, depending on the needs of the task at hand. |
| 19:16 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has joined #code |
| 19:16 | | mode/#code [+ao ToxicFrog ToxicFrog] by ChanServ |
| 19:18 | <&jerith> | Now that I am more at leisure to discuss things, I'd like to argue that Erlang is actually a tremendously successful (for... niche values of tremendously) example of the MIT approach. |
| 19:21 | <&jerith> | The core philosphy of the language and runtime is that the correctness (and by extension the continued correct operation) of any given part of a system should not be affected by failures of other parts of the system. |
| 19:22 | <&jerith> | Not even when those "failures" are intentional actions taken to modify/upgrade the system. |
| 19:24 | <&jerith> | The design of the language is both simple and consistent. (Excluding parts of the standard library, I guess, but much of that came later.) |
| 19:27 | <&jerith> | On top of the low level core, there's an extremely elegant set of abstractions (OTP) that provide a clean and simple framework for building highly reliable distributed systems. |
| 19:31 | <&jerith> | I shall now place my tongue firmly in my cheek and contrast that with a similar system designed to solve similar problems but using the New Jersey approach: Go.~ |
| 19:34 | <&jerith> | Anyway, it's easy to confuse the mechanics of Erlang's failure handling (crash early and let your supervisor decide what to do about it) with a cavalier attitude toward correctness. |
| 19:36 | <&jerith> | The trick is to understand that failures of all kinds are inevitable, and the only robust way to protect against them is isolation and recovery. |
| 19:40 | <&jerith> | Once you have mechanisms for that, there isn't much point in adding additional mechanisms for dealing with failures -- you'd be reducing simplicity (both in interface and implementation) and consistency without any real benefit. |
| 20:02 | | * Vornicus hunts through his math trying to figure out exactly what situation ends up causing it to end up with a degenerate finite triangle |
| 20:03 | <~Vornicus> | So: the way these dfts work is they are always 1. on the convex hull and 2. directly in line with the distant points direction - that is to say they are a flat top or bottom to the finite portion of the triangulation |
| 20:04 | <~Vornicus> | In order for a point to land there it must land on either 1. the line between two finite points or 2. the line between a finite point and an infinite point. |
| 20:05 | <~Vornicus> | In either case, it generates four triangle. |
| 20:05 | <~Vornicus> | s. |
| 20:06 | <&McMartin> | I would suggest that Go is a terrible example of the New Jersey/Berkeley approach, though it does have the appropriate lineage all right~ |
| 20:08 | <&McMartin> | But I must also admit that I am hard-pressed to find a good example of the NJ design methodology in a modern successful product. |
| 20:08 | <&McMartin> | I do not count Linux here, because the open-source methodologies don't really mix in to either situation yet because it is 1989 and the closest analogues in widespread computing culture are almost entirely dead. |
| 20:09 | <&McMartin> | Er, are almost entirely dead in 2019. |
| 20:09 | <&McMartin> | ... but I bet you can make a case for the Raspberry Pi, come to think of it. |
| 20:10 | <&McMartin> | It's not, like actually good at anything in particular, but it's kind of all right at lots of things and it has an impossibly low manufacturing cost |
| 20:19 | <~Vornicus> | If it lands on the finite one, then I end up with a triangle with Left distant and a triangle with Right distant. |
| 20:20 | <~Vornicus> | those should both flip. |
| 20:20 | <~Vornicus> | should. |
| 20:26 | <&McMartin> | In happier news apparently our last perterbation of that code dropped the crash rate by 67% |
| 20:34 | <~Vornicus> | Well that's good |
| 20:34 | <&McMartin> | Unfortunately our local crash rate with the unperterbed code is still 0% even when we attempt to directly programmatically create the crash trace >_< |
| 20:35 | <~Vornicus> | what the hell |
| 20:37 | <&McMartin> | Also none of our code is in the crashing stack trace |
| 20:42 | <~Vornicus> | And the response from, uh, apple or whoever is "you're doing it wrong but we won't tell you how", or something? |
| 20:43 | <&McMartin> | I mean, if they could tell us how based on the information available to us I would know better than them how to fix it |
| 20:43 | <&McMartin> | I'm quite convinced that nobody actually fully understands the systems here, since there are at least three companies providing IP into it before we or any other developer even shows up |
| 20:44 | <&McMartin> | The kind where the official sample code is not licensed for use in actual software |
| 20:44 | <&McMartin> | And not in the "THE PRECIOUS IS OURS IT IS" style but in the "FOR THE LOVE OF GOD DO NOT ACTUALLY DO THIS THING THAT IS THE ONLY EXAMPLE IN ANY OF OUR DOCUMENTATION" kind. |
| 20:44 | <&McMartin> | But hey, they're electrical engineers, I guess. |
| 20:45 | <~Vornicus> | I think I must reiterate: what the hell |
| 20:47 | <&McMartin> | Fortunately, I have now found an actual memory corruption bug in our use of an open-source library |
| 20:47 | <&McMartin> | Caused by violating an invariant that I have also found documented nowhere |
| 20:47 | <&McMartin> | But we don't need documentation, I guess, because the source code is available! \m/_(>_<)_\m/ |
| 20:49 | <&McMartin> | So hey, maybe this is all secondary damage and everything will magically be fixed after that goes away |
| 20:49 | <&McMartin> | NARRATOR: It was not all merely secondary damage from an unrelated bug. |
| 20:55 | <~Vornicus> | Yeah I've been pretty grumpy about documentation on Vornonoi. I've got some drawing files here to turn my notebook drawings into something that can actually be understood by someone else |
| 21:11 | <&jerith> | Yeah, documentation. |
| 21:11 | <&jerith> | It's a lot like sex. |
| 21:11 | <&jerith> | When it's good, it's really good. |
| 21:12 | <&jerith> | When it's bad, it's still better than nothing. |
| 21:13 | <&jerith> | But if you're not careful, you could catch something nasty that will make you unhappy for a long time. |
| 21:15 | <&McMartin> | I have lost the thread of this metaphor there at the end. |
| 21:21 | <&jerith> | Reading documentation from the wrong kinds of sources could give you the equivalent of an STI. |
| 21:22 | <&jerith> | With symptoms that include memory corruption, endless debugging with no resolution, etc. |
| 21:41 | | Vash [Vash@Nightstar-sjaki9.res.rr.com] has joined #code |
| 21:51 | | Reiv [NSkiwiirc@Nightstar-ih0uis.global-gateway.net.nz] has joined #code |
| 21:51 | | mode/#code [+o Reiv] by ChanServ |
| 21:55 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has quit [Ping timeout: 121 seconds] |
| 22:39 | | Vash [Vash@Nightstar-sjaki9.res.rr.com] has quit [[NS] Quit: Leaving] |
| 22:57 | <&McMartin> | So, git question |
| 22:57 | <&McMartin> | Someone has me as upstream, and has made some changes. |
| 22:57 | <&McMartin> | I want to fetch commits from their master onto one of my branches |
| 22:57 | <&McMartin> | What's the incantation for this? |
| 22:58 | <&ToxicFrog> | Can you access their repo directly (e.g. over ssh, or http, or via a network drive, or whatever)? |
| 22:58 | <&ToxicFrog> | if so: |
| 22:58 | <&ToxicFrog> | git remote add <human-readable name> <url of their repo> |
| 22:58 | <&ToxicFrog> | git fetch <name> |
| 22:59 | <&ToxicFrog> | git checkout <local branch> |
| 22:59 | <&ToxicFrog> | git merge <other options as needed, e.g. --ff-only> <repo name/master> |
| 22:59 | <&McMartin> | Aha, that was the bit I'd missed: merge allows repo names without checking them out directly |
| 23:00 | <&McMartin> | Cheers |
| 23:01 | <&ToxicFrog> | I believe there's some set of arguments you can pass to `git pull` that lets you do this in fewer commands, but I rarely use `pull`. |
| 23:05 | <&McMartin> | I use pull quite regularly but I don't know ways to not have that ultimately trash my master. |
| --- Log closed Wed Jul 24 00:00:42 2019 |