| --- Log opened Mon Oct 30 00:00:57 2017 |
| 01:36 | <&ToxicFrog> | Goddamnit Python |
| 01:42 | | Kindamoody is now known as Kindamoody[zZz] |
| 01:45 | <~Vornicus> | what'd it do today |
| 02:04 | <&ToxicFrog> | Thread error handling is still garbage (an uncaught exception in a thread kills the thread and leaves the rest of the program running, and there's no way to change this external to the thread, so I'm having to monkeypatch classes in external libraries to catch and handle exceptions in worker threads) |
| 02:04 | <&ToxicFrog> | And on top of that, sys.exit() is implemented as an exception, so if called from not-the-main-thread it does not in fact exit the program. |
| 02:47 | <&Derakon> | Wow, I didn't know that one. |
| 02:47 | <&Derakon> | The "threads die silently if they have an uncaught exception" one has been biting me at work though. |
| 02:48 | <&Derakon> | I have a program with a lot of execution contexts, and the number of times I've discovered that one of them just...isn't running, and nothing got logged except to the console? Is too damn high. |
| 03:50 | | Vornlicious [Vorn@Nightstar-0g595c.sub-70-197-68.myvzw.com] has joined #code |
| 03:52 | | Vorntastic [Vorn@Nightstar-1l3nul.res.rr.com] has quit [Ping timeout: 121 seconds] |
| 04:01 | | Vornlicious [Vorn@Nightstar-0g595c.sub-70-197-68.myvzw.com] has quit [Connection closed] |
| 04:01 | | Vorntastic [Vorn@Nightstar-1l3nul.res.rr.com] has joined #code |
| 04:06 | | Derakon is now known as Derakon[AFK] |
| 04:40 | | Vornlicious [Vorn@Nightstar-0g595c.sub-70-197-68.myvzw.com] has joined #code |
| 04:42 | | Vorntastic [Vorn@Nightstar-1l3nul.res.rr.com] has quit [Ping timeout: 121 seconds] |
| 05:35 | | celticminstrel [celticminst@Nightstar-0q5lkf.dsl.bell.ca] has quit [[NS] Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.] |
| 06:36 | | Vornicus [Vorn@Nightstar-1l3nul.res.rr.com] has quit [Ping timeout: 121 seconds] |
| 07:09 | | mac is now known as macdjord|slep |
| 07:53 | | [R] [rstamer@genoce.org] has quit [Ping timeout: 121 seconds] |
| 07:57 | | [R] [rstamer@Nightstar-d7h8ki.org] has joined #code |
| 07:57 | | mode/#code [+ao [R] [R]] by ChanServ |
| 08:52 | | Jessikat [Jessikat@Nightstar-nmvip8.dab.02.net] has joined #code |
| 09:00 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 09:05 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has joined #code |
| 09:05 | | mode/#code [+o Alek] by ChanServ |
| 10:31 | | Kindamoody[zZz] is now known as Kindamoody |
| 10:34 | | Jessikat` [Jessikat@Nightstar-ocpgul.dab.02.net] has joined #code |
| 10:35 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 10:37 | | Jessikat [Jessikat@Nightstar-nmvip8.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 10:39 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has joined #code |
| 10:39 | | mode/#code [+o Alek] by ChanServ |
| 10:40 | | Reiv [NSkiwiirc@Nightstar-ih0uis.global-gateway.net.nz] has quit [[NS] Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] |
| 10:43 | | Kindamoody is now known as Kindamoody|afk |
| 12:43 | | Jessikat` is now known as Jessikat |
| 13:10 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 13:13 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has joined #code |
| 13:13 | | mode/#code [+o Alek] by ChanServ |
| 13:33 | | Vornlicious [Vorn@Nightstar-0g595c.sub-70-197-68.myvzw.com] has quit [The TLS connection was non-properly terminated.] |
| 13:41 | | Vorntastic [Vorn@Nightstar-0g595c.sub-70-197-68.myvzw.com] has joined #code |
| 14:20 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 14:23 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has joined #code |
| 14:23 | | mode/#code [+o Alek] by ChanServ |
| 14:41 | <@TheWatcher> | WTF. I know I worked on this project, but I'm buggered if I can find where |
| 14:42 | <&McMartin> | log + grep? |
| 14:42 | <&McMartin> | Works better on svn, admittedly, since you can search all branches at once |
| 14:43 | <@TheWatcher> | I hadn't pushed the git repo anywhere. And it's not on any of the four machines I'd normally work on. |
| 14:44 | <@TheWatcher> | So either I was working on a different machine for some bizarre reason, or I'm going crazy. |
| 14:44 | <@TheWatcher> | Well, crazier. |
| 14:44 | | Vorntastic [Vorn@Nightstar-0g595c.sub-70-197-68.myvzw.com] has quit [[NS] Quit: Bye] |
| 14:44 | | Vorntastic [Vorn@Nightstar-1l3nul.res.rr.com] has joined #code |
| 14:45 | <@TheWatcher> | Suspecting I should put money on the latter, really. |
| 14:52 | <@TheWatcher> | Aha, no, I wasn't completely insane; I'd just put it in a total;y stupid place. |
| 15:21 | <&ToxicFrog> | McMartin: git log --all searches all branches at once |
| 15:21 | <&McMartin> | aha |
| 15:22 | <&ToxicFrog> | (git log --all --oneline --decorate --graph is basically the tty-friendly equivalent to gitk) |
| 15:23 | <&ToxicFrog> | This is not immediately obvious from the man page (because WHY WOULD IT BE), but --all is an argument to rev-list and log forwards arguments it doesn't understand to rev-list to get the list of actual things to display. |
| 15:58 | | Irssi: #code: Total of 33 nicks [25 ops, 0 halfops, 0 voices, 8 normal] |
| 17:04 | | Jessikat` [Jessikat@Nightstar-li7kri.dab.02.net] has joined #code |
| 17:07 | | Jessikat [Jessikat@Nightstar-ocpgul.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 18:04 | | Jessikat` is now known as Jessikat |
| 18:14 | <@Tamber> | Git? Be obvious from the man-page? Don't be silly. Useful documentation is for /plebs/~ |
| 18:16 | <&jeroud> | Threads in Python are a tyre fire. |
| 18:17 | <&McMartin> | It just makes more sense if you start from the source code and work up to the docs, really. |
| 18:17 | <&McMartin> | (I am attempting sarcasm, but for all I know this is actually accepted best practice) |
| 18:18 | <&jeroud> | I just treat git as an imp in a box that I feed esoteric incantations to. |
| 18:19 | <&jeroud> | If I haven't offended it too badly, it'll often do what I want. |
| 18:19 | <&ToxicFrog> | McMartin: to be fair, the documentation is actually complete, accurate, and almost always unambiguous. It's just that it's very easy to overlook things like "also, this command accepts abosolutely anything you could pass to git-rev-list", and it's really bad on high-level concepts, or at least the stuff in man1 is. |
| 18:19 | <&ToxicFrog> | I don't know how good the man7 stuff is these days., |
| 18:22 | <&jeroud> | Meanwhile, every time I use hg I rediscover that "hg resolve" is not the thing I want (that would be "hg resolve -m") and in fact discards your tedious and painstaking conflict resolution work in favour of its own naive algorithm that failed the first time. |
| 18:27 | <&[R]> | What's worse: java threads or python threads? |
| 18:28 | <&jeroud> | Python threads. |
| 18:28 | <&McMartin> | Java is, if nothing else, intentionally designed to support heavily multithreaded applications. |
| 18:29 | <&McMartin> | However, it also hails from an era where you were expected to do that by hand with maybe a little cyborg augmentation at best |
| 18:29 | <&jeroud> | They have all the downsides of threads in general and the GIL means that you only get to use one core anyway. |
| 18:29 | <&McMartin> | This is presently frowned upon under most circumstances. |
| 18:30 | <&McMartin> | But the enormous, sprawling, and generally mature Java ecosystem means that you can get behaviour broadly similar to that designed into later languages that attempt to abstract threads away entirely by building your software around a handful of pre-written and de facto (and occasionally de jure) standardized classes. |
| 18:31 | <&ToxicFrog> | jeroud: I'm using hg some at work and keep being surprised by commands that look superficially like their git equivalents but don't do the same thing, like `hg grep` |
| 18:32 | <&McMartin> | cough |
| 18:32 | <&McMartin> | checkout, revert |
| 18:32 | <&ToxicFrog> | (I complained about that one to someone who turned out to be a hg developer, and they said changing it to match the git behaviour is actually in the works) |
| 18:32 | <&ToxicFrog> | McMartin: well, yes, git is also guilty of this wrt subversion, but I never internalized the svn commands. |
| 18:32 | <&ToxicFrog> | Also, I will never try to claim that the git UX isn't, in many ways, a disasterfire. |
| 18:33 | <&jeroud> | I care less about the different commands than I do about default behaviour that silently obliterates data. |
| 18:33 | <&ToxicFrog> | jeroud: re python threads: yeah, lots of people complain about the GIL, but now that I'm actually hacking on software that uses them the GIL is by far the least objectionable thing |
| 18:34 | <&ToxicFrog> | Like, oh no, it's only utilizing one core to silently fail and give me the wrong answers and stop working for days at a time without logging anything |
| 18:34 | <&ToxicFrog> | This would be so much better if it could fail using eight cores at once |
| 18:34 | <&jeroud> | ToxicFrog: The GIL definitely isn't the worst thing, but it means that threads are almost never the right solution for anything. |
| 18:35 | <&ToxicFrog> | jeroud: IMO threads can be extremely useful for code organization even when they confer no performance benefit. |
| 18:35 | <&jeroud> | Twisted is by far the least bad of the do-multiple-things-interleaved machanisms I've used. |
| 18:36 | <&ToxicFrog> | (although there is an argument to be made that in that case you should just have coroutines with explicit yield points, but OTOH doing it this way lets the runtime stick automatic yield points into anything that does IO and let the OS handle the stack shuffling) |
| 18:36 | <&jeroud> | And hopefully asyncio and the new async/await syntax will make that more approachable. |
| 18:36 | <&ToxicFrog> | (and having tried to implement coroutines myself, I can't really blame them for it) |
| 18:36 | <&McMartin> | I still find myself skeptical of async/await compared to direct yield points or event-chaining. |
| 18:37 | <&ToxicFrog> | I'm not sold on async/await; it seems like it's solving the wrong problem (i.e. how to make giant chains of callbacks somewhat less unreadable, as opposed to how to make them unnecessary in the first place) |
| 18:37 | <&McMartin> | And yeah, Java has a lot of "you know, you have an OS and a runtime for a reason in it" |
| 18:39 | <&jeroud> | The main benefit of the coroutine approach is that you don't need a fragile pile of locks to protect shared mutable state. |
| 18:40 | <&ToxicFrog> | jeroud: threads don't require shared mutable state either. |
| 18:40 | <&jeroud> | But in Python they're just syntactic sugar around generators. |
| 18:41 | <&ToxicFrog> | I've now entirely lost track of what point you're trying to make. |
| 18:41 | <&jeroud> | ToxicFrog: You misunderstood. Assuming you already have shared mutable state, coroutines mean that you don't need to micromanage locks because you're not going to context switch arbitrarily. |
| 18:42 | <&jeroud> | The syntactic sugar comment is unrelated. It just means that Python coroutines are made of spiders under the hood. |
| 18:43 | <&jeroud> | I generally avoid threads in all languages because I'm nowhere near smart enough to get them right. |
| 18:44 | <&jeroud> | I guess I'm mostly just being grumpy about the terrible state of tooling in this area. |
| 18:45 | <&McMartin> | I have had coroutines backfire on me in ways that are semantically equivalent to "your locking was way too coarse-grained" |
| 18:45 | <&jeroud> | Yeah, that's one of their flaws. |
| 18:46 | <&jeroud> | Another is "don't block or do anything computationally expensive or you'll be very sad". |
| 18:46 | <&McMartin> | That's also a flaw for certain kinds of threads~ |
| 18:48 | <&jeroud> | The only sane way I've found to do this stuff is immutable data structures and more or less functional approach to doing whatever it is you're doing. |
| 18:49 | <&jeroud> | But the languages that support that tend to be sufficiently unpopular that you get to roll all your own dependencies. |
| 18:50 | <&jeroud> | (I say as someone who ended up writing an AMQP client library in OCaml for this very reason.) |
| 18:51 | <&jeroud> | Annoyingly, the closest thing we have to this kind of thing in a mainstream language is JavaScript, and that's fundamentally broken in various other ways. |
| 18:57 | <&jeroud> | I'm not entirely convinced Erlang-style actors and supervisors are the right solution for the general case, but I haven't seen anything better. |
| 19:21 | <&ToxicFrog> | I guess clojure doesn't count as mainstream yet~ |
| 19:23 | <&McMartin> | Clojure's own docs admit Erlang solves distributed computation better~ |
| 19:33 | <&ToxicFrog> | McMartin: yeah, I was responding to "the closest thing we have to [immutable data structures and a more or less functional approach] in a mainstream language is JavaScript" |
| 19:34 | <&ToxicFrog> | And I feel comfortable saying that Clojure is both better at this than JS and more mainstream than Erlang |
| 19:35 | <&ToxicFrog> | jeroud: unwinding the stack a bit -- "Assuming you already have shared mutable state" -- this is an assumption I explicitly reject; my approach to threads tend to be entirely based on message passing. |
| 19:35 | <&ToxicFrog> | (this also means that my threaded code in coroutines and my threaded code in Actual Threads tend to look pretty similar; you just put your yield/resume points inside send() and receive()) |
| 19:58 | <&jeroud> | ToxicFrog: It's depressingly hard to get away from mutable state in Python. |
| 19:59 | <&ToxicFrog> | Fair, but I'm not usually working in python. |
| 19:59 | <&ToxicFrog> | This is my first experience with python threads, and it's not even my code. |
| 19:59 | | Reiv [NSkiwiirc@Nightstar-ih0uis.global-gateway.net.nz] has joined #code |
| 19:59 | | mode/#code [+o Reiv] by ChanServ |
| 19:59 | <&jeroud> | And yes, clojure also does this reasonably well and isn't really mainstream. |
| 20:02 | <&ToxicFrog> | So my experiences with threading tend to be drawn from clojure (already covered), lua (coroutines, or message-passing between completely isolated VMs), or C/++ (which heavily informs my disliking of shared state~) |
| 20:02 | <&ToxicFrog> | (although it was actually a C++ platform that introduced me to message-passing) |
| 20:03 | | Kindamoody|afk is now known as Kindamoody |
| 20:05 | <&ToxicFrog> | (on an embedded system with no memory protection of any kind, so iron discipline was necessary, and the message-passing API helped with that) |
| 20:35 | <@gnolam> | https://twitter.com/business/status/923896028721504256 >_< |
| 20:36 | <@Tamber> | bwaha |
| 20:54 | <@gnolam> | ... |
| 20:54 | | * gnolam learns of World Standards Day. |
| 20:55 | <@gnolam> | The IEC, ITU and ISO now celebrate it on October 14. |
| 20:55 | <@gnolam> | ANSI celebrates it on October 19. |
| 21:18 | | Jessikat` [Jessikat@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
| 21:20 | <@Tamber> | hee |
| 21:24 | <@Alek> | pfft |
| 21:33 | <@abudhabi> | Hahaha. |
| 21:49 | | macdjord|slep is now known as macdjord |
| 22:09 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has quit [Connection closed] |
| 22:14 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has joined #code |
| 22:14 | | mode/#code [+o Alek] by ChanServ |
| 23:34 | | Jessikat`` [Jessikat@Nightstar-8m86eh.dab.02.net] has joined #code |
| 23:37 | | Jessikat [Jessikat@Nightstar-li7kri.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 23:38 | | Jessikat`` [Jessikat@Nightstar-8m86eh.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 23:43 | | Jessikat` is now known as Jessikat |
| 23:53 | | Derakon[AFK] is now known as Derakon |
| --- Log closed Tue Oct 31 00:00:59 2017 |