This wasn't a planned session, it was an urgent one that got forced a few days ago. I despise MEP absenteeism but I think these were properly scheduled vacations.
We already had two votes to renew it before it expired, and both failed. The second one was forced by the EPP immediately after the first, and then they voted against it too because they failed to amend it even stronger before the vote.
Not quite, the EU parliament can't propose new laws nor repeal existing ones, only amend them and vote on proposals from the commission.
The Stop Killing Games campaign, for example, has noticed that the EU commission keeps repeating lobbyist lies and has no expectations of new laws actually passing, so they're focusing on amending existing law through parliament.
xAI is discounting the first few months of their rental to Anthropic, which will help them seem profitable for a bit longer. We'll need to see if that lasts.
This is an abuse of this term, which refers to immutable transformations that reuse memory, as in Roc and Koka, not to hiding effects within a function.
> It's the code you would write in Python with types you get from OCaml and no monads.
It's also the code you could write in OCaml itself.
---
Having used OCaml 5 effects, I'm convinced that the trend of globally scoped effect constructors, dynamically scoped handlers and effect-typed functions are the wrong approach. They couple too many orthogonal features.
Handlers should be consumed as (records of) functions that can't leak from their scope (see 'local' in OxCaml, 'ref struct' in C#) and are passed down as a capability. Now you're using two more general mechanisms to express your effects, and other forms of dynamic scoping or dynamic dispatch can be made orthogonal to effects themselves.
Proton itself doesn't exist for macOS, but CrossOver already existed instead, which is mostly the same tech, and indeed supports D3D either through DXVK over MoltenVK, or through Apple's D3DMetal.
Fable should take credit for porting to iOS with a touch UI. But that's about it, looks like the renderer and macOS port were already done, in which case I agree that OP is paltering.
Technically there're just 3 layers: DXVK over MoltenVK over Metal. D3D8 and Vulkan here are just the APIs implemented by those adapter layers.
There're some D3D implementations over Metal that could skip the Vulkan layer but none implement the old D3D8 so you'd still need another layer that implements e.g. D3D8 over D3D9-11. Also, DXVK and MoltenVK have got a lot of traction and fixes on their own, so they're probably the most accurate pipeline for D3D on Metal.
Here's the 2022 release announcement for Podman 4.1 claiming support for compose v2. Your distro may have been stuck with an older Podman version for much longer though.
Podman has supported plugin compose (v2) for years now, and I believe that's the version I used before I switched to Quadlets, but I must have not needed Buildkit features back then because those are apparently still unsupported over v2.
I know, and those can keep using Framework 4.8, but the topic here is attracting developers to Windows, and the primary toolchain for that today definitely isn't Framework 4.8, so the top comment is moot.
The .NET that comes with Windows is the ridiculously outdated .NET Framework 4.8. But most greenfield projects should have been using the newer .NET (previously .NET Core) for several years now, which is installed separately or deployed as self-contained apps.
https://howtheyvote.eu/votes/195775
Check the political groups tab. Yes means reject here.