| --- Log opened Sun May 26 00:00:55 2019 |
| 00:04 | | catalyst [Jessikat@Nightstar-5dv16h.cable.virginm.net] has joined #code |
| 00:07 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has quit [Operation timed out] |
| 01:10 | | Kindamoody is now known as Kindamoody[zZz] |
| 02:15 | | Reiv [NSkiwiirc@Nightstar-ih0uis.global-gateway.net.nz] has joined #code |
| 02:15 | | mode/#code [+o Reiv] by ChanServ |
| 03:52 | <&McMartin> | New Bumbershoot post, after like a month. https://bumbershootsoft.wordpress.com/2019/05/26/migrating-from-python-2-to-3/ |
| 04:08 | | catalyst [Jessikat@Nightstar-5dv16h.cable.virginm.net] has quit [[NS] Quit: Leaving] |
| 04:56 | | Vorntastic [uid293981@Nightstar-6br85t.irccloud.com] has joined #code |
| 04:56 | | mode/#code [+qo Vorntastic Vorntastic] by ChanServ |
| 05:10 | | celticminstrel [celticminst@Nightstar-1kpqgc.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 07:14 | <&jeroud> | Python 2 to Python 3 has been a complete clusterfuck. |
| 07:15 | <&jeroud> | It took 5 years for Python 3 to become a tolerable replacement for Python 2. |
| 07:16 | <&jeroud> | And while the initial break in backcompat was there to fix some legitimate problems, it very quickly became an excuse to just change all sorts of random stuff. |
| 07:18 | <&jeroud> | Also, many problems that Python 3 was intended to fix were not actually fixed. Instead, they were replaced with different problems. |
| 07:21 | <&McMartin> | As I mentioned there, I do wonder if it took five years because five years were made available to do it in. |
| 07:22 | <&jeroud> | More importantly, the changes were significant enough to require substantial rewrites of rather a lot of code while not really providing much benefit for that effort. |
| 07:23 | <&jeroud> | There's definitely a lot of "we're not going to bother because we don't actually need to". |
| 07:24 | <&jeroud> | But there's also a large core of "the cost of doing this could sink our company". |
| 07:25 | <&jeroud> | Quite a lot of people, myself included, basically just switched from Python 2 to non-Python languages. |
| 07:29 | <&jeroud> | Also, Python 3 happened over the timeframe that multicore concurrency started getting really important. |
| 07:30 | <&jeroud> | And it doesn't have anything in it to deal with that. |
| 07:34 | <&jeroud> | In terms of how long it's taken to get stuff ported, a lot of that comes down to the attitudes of the core Python team. |
| 07:36 | <&jeroud> | Initially, the proposed migration plan was "run 2to3 on your codebase, throw away the py2 source, support only py3, done". |
| 07:36 | <&McMartin> | It has not escaped my notice that my C programs have resulted in more durable artifacts. |
| 07:37 | <&jeroud> | That very rapidly became "run 2to3, keep the py2 source, maintain two copies". |
| 07:39 | <&jeroud> | And then "run 2to3, tweak the py2 source until 2to3's output actually works without manual modification". |
| 07:40 | <&jeroud> | It took an absurdly long time to get some features necessary for single-codebase compatibility back into py3. |
| 07:40 | | Reiver [quassel@Nightstar-ksqup0.co.uk] has joined #code |
| 07:40 | | mode/#code [+ao Reiver Reiver] by ChanServ |
| 07:42 | <&McMartin> | Ophis 3 is very likely to end up being written in C. |
| 07:43 | <&jeroud> | For example, 3.0 dropped support for u"" strings. |
| 07:44 | <&McMartin> | Yes, AIUI, single-source compatibility was basically impossible until 3.2, and the libraries weren't actually ready until 3.5 or 3.6. |
| 07:44 | <&jeroud> | Which made it impossible to write string literals in a way that both versions understood. |
| 07:44 | <&McMartin> | You still can't, for byte literals! |
| 07:44 | <&McMartin> | You almost can. |
| 07:44 | <&jeroud> | It was eventually put back in 3.3 in late 2012. |
| 07:46 | <&McMartin> | Right, this is the part where I note that it's 2019 |
| 07:46 | <&jeroud> | For bytes you can use u"....".encode("latin1"). |
| 07:46 | <&McMartin> | Oh, you can say b"whatever" in 2.7 and 3.x |
| 07:46 | <&jeroud> | Yeah, that too. |
| 07:46 | <&McMartin> | But when you do, the thing you get back when you index it is of a different type depending. |
| 07:47 | <&McMartin> | Now, as it turns out, this isn't true for the mutable bytearray variant |
| 07:47 | <&McMartin> | Which in fact is what I should have been using in the first place, even in 2.x |
| 07:47 | <&McMartin> | Because that way building up a string by parts isn't possibly quadratic under the hood. |
| 07:47 | <&jeroud> | Yup, because py3 decided that many operations should be allowed on text but not bytes. |
| 07:47 | <&McMartin> | No, this one is on 2.x |
| 07:47 | <&McMartin> | I want integers, at the end of the day. |
| 07:48 | <&McMartin> | So indeed, you can't pass a byte or an integer to ord |
| 07:48 | <&McMartin> | I had a whole lot of [ord(c) for c in string_of_bytes] that got replaced with nothing. |
| 07:48 | <&jeroud> | Getting some "string" functions back on the bytes object only happened much more recently. |
| 07:50 | <&jeroud> | As someone who maintained a text messaging system during this transition, the bytes/unicode situation was incredibly problematic. |
| 07:52 | <&jeroud> | I tried porting bits of vumi to py3 several times between 2012 and 2015, and ran into issues that would basically require a massive rewrite every time. |
| 07:53 | <&jeroud> | It seems that py3 reallyreallyreally wants you to use unicode always everywhere and only has grudging support for bytes at all. |
| 07:54 | <&jeroud> | Primarily because none of the core Python team maintained templating systems or messaging frameworks or whatever. |
| 07:55 | <&McMartin> | This is also true of Rust, Java, and at the end of the day, C |
| 07:55 | <&jeroud> | And they were *far* too important and clever to listen to anyone else. |
| 07:55 | <&McMartin> | If you ever need to be Unicode aware *anywhere*, a C program should be using UCS-4 internally everywhere and encoding it only at the I/O layer. |
| 07:55 | <&jeroud> | Rust has sensible bytes and unicode support. |
| 07:57 | <&jeroud> | Also, utf-8 is probably better as an internal representation unless you know for a fact that you're primarily dealing with Japanese/Chinese text. |
| 07:57 | <&McMartin> | UTF-8 strings require linear time to index. |
| 07:58 | <&jeroud> | But then all your operations need to understand utf-8. |
| 07:58 | <&jeroud> | Yeah, but indexing into big chunks of text isn't a particularly common operation. |
| 07:59 | <&jeroud> | And cutting your memory requirements by 50-75% lets you keep more stuff in caches. |
| 08:00 | <&jeroud> | pypy got a nontrivial performance boost switching from ucs-4 to utf-8 internally. |
| 08:01 | <&jeroud> | I think they also keep a lazily populated index map in the data structure, though. |
| 08:02 | <&jeroud> | So if you're doing a lot of indexing you're not paying the cost every time. |
| 08:02 | <&McMartin> | The cases where I've had to contend with it have been things like MUD and IF clients, which are expected to maintain very large backscrolls that can be jumped-through. |
| 08:02 | <&McMartin> | Though in a lot of cases those get turned into UTF-8 on the way into the display widget. |
| 08:03 | <&jeroud> | That seems like an excellent candidate for utf-8 with an index map. |
| 08:05 | <&jeroud> | Anyway, I guess my point with all of this is that it has only very recently (in the past three years or so) become practical to port existing code to py3. |
| 08:06 | <&jeroud> | Well, application code. |
| 08:06 | <&jeroud> | Mostly because several important libraries were finally ported. |
| 08:08 | <&McMartin> | And next week we'll learn if Apple will actually bother shipping the version of Python that will still be getting security updates in 10.15~ |
| 08:08 | <&McMartin> | ... also whether 10.15 will run on Intel chips and whether or not OpenGL will continue to exist for another year -_- |
| 08:09 | <&jeroud> | Turns out alienating a lot of your community's volunteer developers by ignoring their concerns and dismissing their legitimate issues does not encourage them to do a whole lot of unpaid work on your behalf. |
| 08:09 | <&McMartin> | But apparently was less alienating than GNOME because as far as I can tell there isn't a renegade Python 2 core team in exile |
| 08:10 | <&McMartin> | While GNOME has like three |
| 08:11 | <&jeroud> | No, because being an exile is less pleasant than joining a new community. |
| 08:12 | <&jeroud> | Haskell, Clojure, Rust, and Elixir got a bunch of disgruntled py2ers. |
| 08:12 | <&jeroud> | Oh, *core* team. |
| 08:13 | <&jeroud> | The py2 core team became the py3 core team. |
| 08:13 | <&jeroud> | And as a group, they are a large part of the problem. |
| 08:14 | <&McMartin> | Right, what I mean here is that there is no equivalent of Cinnamon or MATE. |
| 08:15 | <&jeroud> | There's pypy, which isn't going to drop py2 support any time soon. |
| 08:16 | <&jeroud> | Rpython, the language in which pypy is written, is py2 shoved through a type inference and static transformation process. |
| 08:17 | <&jeroud> | Switching that to py3 would be a crazy amount of work, for exactly zero benefit. |
| 08:21 | <&jeroud> | So not so much "in exile" as "has always been a separate group and will continue as such". |
| 08:22 | <&jeroud> | But the volunteer devs I was referring to are the library maintainers. |
| 10:11 | | Degi [Degi@Nightstar-llj3bm.dyn.telefonica.de] has joined #code |
| 10:16 | <&Reiver> | Why is Py3's core team part of the problem |
| 10:17 | <&Reiver> | And why is OpenGL suddenly under so much threat after having actually finally become something of a de facto standard, which was /awesome/ |
| 10:25 | <~Vorntastic> | Vulkan |
| 10:27 | <&Reiver> | Is Vulkan really that good? |
| 10:29 | <~Vorntastic> | It's... Uh... How to explain |
| 10:30 | <~Vorntastic> | It's designed with the state of modern graphics systems in mind |
| 10:30 | | Kindamoody[zZz] is now known as Kindamoody |
| 10:31 | <~Vorntastic> | Which is to say it is designed as a way to talk to a computer that is super great at simd, as opposed to a thing that just slings triangles |
| 10:34 | <&Reiver> | And OpenGL just can't keep up, eh |
| 10:34 | <&Reiver> | I find this slightly ironic... OpenGL finally reaches industry parity, and then it's obsolete |
| 10:34 | <~Vorntastic> | Vulkan is designed by the OpenGL folks |
| 10:38 | <~Vorntastic> | It's also designed to slip in directly under OpenGL |
| 10:40 | <&Reiver> | ... okay now I'm confused as to what the fuss is about it then |
| 10:45 | <~Vorntastic> | I think Mac is using something different? Let me check |
| 10:47 | <~Vorntastic> | Yeah, Apple made their own called Metal, and Windows prefers Directx 12 |
| 10:49 | <&jerith> | OpenGL has always been rather awful. |
| 10:50 | <&jerith> | http://www.joshbarczak.com/blog/?p=154 is the explanation I've seen linked in various places. |
| 10:57 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has joined #code |
| 11:03 | <&jerith> | The Python core team is a problem because they're a fairly closed group of people who aren't really open to outside ideas and consider themselves smarter than the rest of the community. |
| 11:04 | <&jerith> | A great example of this is the asyncio design process. |
| 11:04 | <~Vorntastic> | But Apple used to run OpenGL as their thing, and they've been trying to get rid of it but everyone yells at them when they do |
| 11:05 | <~Vorntastic> | ... Which somehow works there but not elsewhere because the number of times Apple has made breaking changes is incredible |
| 11:05 | <&jerith> | Someone came up with a fairly naive (although not obviously so) design, and the Twisted maintainers (who had been doing sync stuff in Python for most of a decade) pointed out a few of the major flaws and made some suggestions for improvements. |
| 11:08 | <~Vorntastic> | Iirc McM complained about one time when an os update broke nearly all his software? |
| 11:09 | <&jerith> | They were basically ignored and/or told to go away and let the grownups do the important work several times, by people who had exactly zero practical experience with problem they were trying to solve. |
| 11:13 | <&jerith> | (Eventually Glyph and Guido discussed the design over coffee in San Francisco somewhere and some sanity was dragged back into asyncio.) |
| 11:42 | | * TheWatcher readsup |
| 11:51 | <@TheWatcher> | The cynic in me says that anyone worried about python 2's demise can just use RHEL/CentOS. They'll get at least another decade... |
| 11:52 | <&jerith> | Or just install the RedHat-maintained py2. |
| 13:31 | | Kindamoody is now known as Kindamoody|afk |
| 13:52 | | Degi [Degi@Nightstar-llj3bm.dyn.telefonica.de] has quit [Connection closed] |
| 15:06 | | celticminstrel [celticminst@Nightstar-1kpqgc.dsl.bell.ca] has joined #code |
| 15:06 | | mode/#code [+o celticminstrel] by ChanServ |
| 15:12 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 15:12 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 18:15 | | Vorntastic [uid293981@Nightstar-6br85t.irccloud.com] has quit [[NS] Quit: Connection closed for inactivity] |
| 20:38 | <&McMartin> | OpenGL isn't under threat in general |
| 20:38 | <&McMartin> | Particularly since Vulkan is in a very real sense part of OpenGL |
| 20:39 | <~Vornicus> | but Apple is going all "no no use metal" |
| 20:39 | <&McMartin> | Right |
| 20:39 | <&McMartin> | Apple has in fact deprecated the entirety of OpenGL on macOS, so the question is how long OpenGL apps will continue to work. |
| 20:40 | <&McMartin> | And yes, OpenGL 1.x and to a large degree 2.x are a whole lot like a computer you can only program by toggling switches on its faceplate |
| 20:40 | <&McMartin> | But also that computer is at the bottom of the sea so what you need to do is go program a robot to go flip those switches for you |
| 20:41 | <&McMartin> | OpenGL 3.x+ and Direct3D 10 and 11 are more about programming some huge vector processing system directly |
| 20:42 | <&McMartin> | Though most of those bits end up appearing as extensions to 1.x/2.x so basically all "legacy" code will still use stuff like vertex attribute buffers instead of individually calling glVertexAttribute4f or whatever. |
| 20:43 | <&McMartin> | (DX9c has all that too which is why DX9c is still actually a viable technology over a decade later) |
| 20:43 | <&McMartin> | What Vulkan, D3D12, and Metal seem to give you is better access to the GPU from bunches of CPUs at once |
| 20:44 | <&McMartin> | You can maintain independent command channels and the sets of commands you want to do get bundled up in buffers that get delivered to the GPU as a unit much the way geometry information was in that second era. |
| 20:46 | <@Alek> | I noticed recently Origin giving away Sims 4 (base) and also saying it will no longer support it on non-Metal-capable machines. >_> |
| 20:46 | <&McMartin> | (My grasp of this part is pretty weak, tbh. My experience with Metal is reading other people's code and I have no real experience with Vulkan or DX12 at all) |
| 20:46 | <&McMartin> | Metal support goes pretty far back |
| 20:47 | <&McMartin> | Most of the older graphics systems actually had their actual workings severely obfuscated by the huge layers of goo the OpenGL APIs demanded. |
| 20:47 | <&McMartin> | To this day, OpenGL drivers need to ship an entire compiler inside of them, because shader programs only get to exist as source code. |
| 20:47 | <&McMartin> | This is a thing Vulkan fixed and D3D never suffered from~ |
| 20:50 | <&McMartin> | So the other funny thing about this is that in some ways the system requirements for the later versions of the graphics APIs are lower |
| 20:51 | <&McMartin> | The card needs to be new enough to be shader-based (for the second era) or, I guess, have command buffers of some kind (for the third), but that goes back quite far. |
| 20:52 | <&McMartin> | Cards were shader-based under the hood within a few years after consumer-level 3D cards became a thing; the GameCube's super-beefy pre-shader tech was a wild anomaly, and one that can kind of fake many kinds of short shaders when it comes to it |
| 20:52 | <&McMartin> | And Vulkan has support going back to, um, the cheap onboard Intel GPUs from 2012. |
| 20:53 | <&McMartin> | HD4000? |
| 20:54 | | Kindamoody|afk is now known as Kindamoody |
| 20:56 | <~Vornicus> | yeah gamecube did some crazy crazy things with multitexturing apparently? |
| 20:57 | <&McMartin> | There's a nice big essay on this online I can dig up |
| 20:57 | <&McMartin> | But the short form is that shader units grew out of what were originally texture combiners |
| 20:57 | <~Vornicus> | THink I read it, by the dolphin madmen |
| 20:57 | <&McMartin> | No, different one |
| 20:57 | <~Vornicus> | ah |
| 20:58 | <~Vornicus> | yeah once you described it or something |
| 20:58 | <&McMartin> | The dolphin madman essay is also fabulous but it's about emulating the multitexturing unit on the GC with a real shader |
| 20:58 | <~Vornicus> | i can't brain give me a minute |
| 20:58 | <&McMartin> | "Ubershaders: a Ridiculous Solution to an Impossible Problem" or similar. |
| 20:59 | <&McMartin> | Anyway, yeah, if you had two texture units and you could tell them 'hey, blend these textures and then overlay this over one on top of it" that was basically multiply-and-select |
| 20:59 | <@TheWatcher> | Welp, that's 41 database tables, I guess I should write some code now... |
| 20:59 | <&McMartin> | So the earliest shaders exposed to the world were D3D 7 and 8's shader assemblers, which tended to be, like "you get eight instructions and two of them can be math" |
| 20:59 | <&McMartin> | And that was because your card had eight texture units and two combiners. |
| 21:00 | <&McMartin> | And then it started turning into the modern GPUs and people started writing high-level stuff to compile into them, and once they got more general they'd actually work |
| 21:00 | <&McMartin> | Which is why OpenGL drivers all have entire compilers in them |
| 21:00 | <&McMartin> | (D3D, Vulkan, and Metal turn them into bytecode in advance) |
| 21:01 | <&McMartin> | Anyway, the most programmable multitexturing but not full shader processor systems were called something like "texture environment units", and I think those gave you the equivalent of shader "uniforms" or something |
| 21:01 | | * McMartin isn't sure about that part |
| 21:01 | <&McMartin> | But yeah |
| 21:02 | <&McMartin> | The 'Cube had that instead of shaders. The Xbox had actual shaders, but barely, so you had to do the assembly-style shaders with them |
| 21:02 | <&McMartin> | The PS2 had a properly programmable GPU but you had to wrangle the programs completely by hand, which was apparently a hilarious nightmare |
| 21:04 | <&McMartin> | Aha, here it is. |
| 21:04 | <&McMartin> | https://paroj.github.io/gltut/History%20of%20Graphics%20Hardware.html |
| 21:05 | <&McMartin> | The main thing that surprised me about this one is how incredibly late hardware transform-and-lighting (modern-day vertex shading) was. |
| 21:15 | | catalyst [Jessikat@Nightstar-5dv16h.cable.virginm.net] has joined #code |
| 22:00 | | * McMartin finishes working through the Kotlin training challenges on their playground. |
| 22:01 | | * McMartin concludes that this is not a tool one can casually pick up and swing at a wall one needs knocked down, but it is probably the JVM-targeting tool that best fits his hands. |
| 22:01 | <&McMartin> | Maybe I'll throw together an Android port of Lights-Out in it or something. |
| 22:23 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has quit [Ping timeout: 121 seconds] |
| 22:40 | | himi [sjjf@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 23:46 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed] |
| --- Log closed Mon May 27 00:00:56 2019 |