Interested in the intersections between policy, law and technology. Programmer, lawyer, civil servant, orthodox Marxist. Blind.


Interesado en la intersección entre la política, el derecho y la tecnología. Programador, abogado, funcionario, marxista ortodoxo. Ciego.

  • 5 Posts
  • 40 Comments
Joined 1 year ago
cake
Cake day: June 5th, 2023

help-circle

  • modulus@lemmy.mltoGenZedong@lemmygrad.mlToo big to win
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    4 months ago

    Kind of interesting, especially on the diagnosis of the problem. The proposed solutions seem way out there, though, as one might expect from the founder of Blackwater.

    Edit: Needless to say, I have no desire for imperialism to become more effective. But even in its own terms, the pro-market, private sector stuff is really odd and doesn’t explain how all those rivals and enemies are doing so much better.





  • Not sure I understand. What I’m trying to do is something like this:

    • Poll a stream which takes fedi events. Read player commands.
    • If an event comes from a known player, check which match they are into.
    • With that info, get their opponents/coplayers etc and perform the change of state in the game (send replies, next turn, etc).

    So what I have as a key is a player name (AP username) and from that I need to find which match they’re in.

    There’s nothing semantically useful about a match ID.


  • Thanks, the RC is a possible approach. It seems to violate DRY a bit but maybe there’s no way around it.

    The reason I had the players outside the match is that I need them there anyway, because when I get a player action I need to check in which match they are, who are their opponent(s) and so on. So even if they’re in, they’ll have to be out too as there are concurrent matches and the player actions come all through the same network stream.



  • Very well-reasoned article, though the political constraints might end up making implementing its recommendations impossible. Hard to see how the US and EU could make the rhetorical shifts it would take. If events continue as they are now, the military realities may preclude it. While it seems advantageous to reach a negotiated settlement for all sides at the moment, this will not remain the case forever.


  • I can think of alternatives. For example, the server could keep the user’s private key, encrypted with a passphrase that the user must have. So key loss wouldn’t be an issue. (Yes, passphrase loss might, but there are lots of ways to keep those safely already, compared to key material which is difficult to handle.)









  • Apparently the problem is due to an incompatibility between the use of certain libraries (winapi and windows-sys) which use different versions of COM. At least so I deduce from the documentation I’ve read.

    There’s a workaaround:

    On Cargo.toml, use.

    [build-dependencies]
    embed-manifest = "1.3.1"
    

    And on the root of the project (not the src dir) create a build.rs file with the following content:

    use embed_manifest::{embed_manifest, new_manifest};
    
    fn main() {
        if std::env::var_os("CARGO_CFG_WINDOWS").is_some() {
            embed_manifest(new_manifest("Contoso.Sample")).expect("unable to embed manifest file");
        }
        println!("cargo:rerun-if-changed=build.rs");
    }
    

    This embeds a manifest together with the executable, solving the issue.




  • The way I look at this is I have a reasonable understanding of rust. I’m not an expert but I can more or less do whatever computation I need to do, use crates, and so on. But with async it’s like learning another language. Somewhat of an exaggeration, but it’s not just what code you need to write, but also being able to read the error messages from the compiler, understanding the patterns and so on. So yes, it’s probably fine, but it does take work.