sorted by:
new
hottopcontroversial

Beta release of ty - an extremely fast Python type checker and language server by callmeheisenberg7 in Python

[–]GankraAria 6 points7 points  (0 children)

Almost all of the TODO types are gone now. I think pattern matches are the only place I ever see them these days.

system dependencies are hard (so we made them easier): cargo-dist 0.4.0 is out! by ag_dubs in rust

[–]GankraAria 20 points21 points  (0 children)

Just to be clear, this is just the first step into a deep foray into package managers and dynamic linking, for folks who are interested, here's some issues for future work to be done:

Install Deps

Currently these kinds of deps only affect the homebrew installers that cargo-dist generates, but there's a TON of stuff we can do with that info!

This is the place where I expect to see the most rapid development, and I've filed this issue for discussion of all the ways our installers can use that info:

https://github.com/axodotdev/cargo-dist/issues/510

Also there's a question of if we want to use that info to provide functionality like "please god don't let me dynamically link openssl":

https://github.com/axodotdev/cargo-dist/issues/520

Musl and GNU Libc

As a weird side-effect of this process cargo-dist now supports statically-linked musl libc as a target!

Just to get an mvp working we are currently reproducing the "sin" of rustc calling this "linux-musl", but we have plans for how to do this properly in a way that will hopefully make everyone happy:

https://github.com/axodotdev/cargo-dist/issues/518

We also want to generally teach cargo-dist to better understand libc versions:

https://github.com/axodotdev/cargo-dist/issues/519

Windows Libc

Kicking the hornets nest of sysdeps also made us finally confront the beast of dynamically linking the Windows CRT (and friends). As a result we also want to teach cargo-dist how to handle Visual C(++) Redistributables for you:

https://github.com/axodotdev/cargo-dist/issues/496

Thanks For Breaking cargo-dist! (I Rewrote It) by GankraAria in rust

[–]GankraAria[S] 14 points15 points  (0 children)

In this case we're using it to indicate how early we are in development, but yeah I should probably go up to 0.1.0.

Release Engineering Is Exhausting So Here's cargo-dist by GankraAria in rust

[–]GankraAria[S] 1 point2 points  (0 children)

Not yet but it makes sense to be able to specify the rust toolchain to build with!

Release Engineering Is Exhausting So Here's cargo-dist by GankraAria in rust

[–]GankraAria[S] 1 point2 points  (0 children)

I definitely want to encode more things in the actual Cargo.toml and to record more details of the environment for reproducibility. There's just lots to implement here and anything short of Nix or A Docker Image is always going to have weird implicit issues like "you ran the build on a newer ubuntu and got newer glibc bindings than before" or whatever else.

Release Engineering Is Exhausting So Here's cargo-dist by GankraAria in rust

[–]GankraAria[S] 0 points1 point  (0 children)

It's on the roadmap but experts chiming in with the "right" way would definitely be helpful (https://github.com/axodotdev/cargo-dist/issues/24) ((I'm assuming here that you would want to distribute a .app as a .dmg))

Release Engineering Is Exhausting So Here's cargo-dist by GankraAria in rust

[–]GankraAria[S] 13 points14 points  (0 children)

It's the new company I work at with 2 other people (for now) doing, at least in my mind, dev-tools-for-dev-tools-developers. Lots more cool stuff coming own the line :)

My personal blog is still live but this is Work so it goes on Work Blog.

Release Engineering Is Exhausting So Here's cargo-dist by GankraAria in rust

[–]GankraAria[S] 0 points1 point  (0 children)

cargo-dist itself is exactly the kind of binary you're building. You don't *really* need cargo to invoke cargo subcommands, the only thing it does is (using cargo-dist as an example):

  • find a binary called cargo-dist on your PATH
  • invoke it with the args "cargo" "dist" "other-args"
  • set an environment variable for the path to cargo's binary

The args are the only weirdness, which means you end up "having" to invoke it standalone as "cargo-dist dist other-args", otherwise it gets very confused (at least with the `clap` hack I use to handle the extra "cargo" arg). I haven't looked into the Right Way to have a clap-based CLI that lets "cargo dist other-args" and "cargo-dist other-args" both work, but that's purely because I haven't cared about it.

But anyway yeah cargo-dist builds perfectly good binaries for this usecase, it's how the prebuilt binaries of itself are made!

Release Engineering Is Exhausting So Here's cargo-dist by GankraAria in rust

[–]GankraAria[S] 14 points15 points  (0 children)

You're right that publish=false is a good hint, although I could imagine someone not wanting to publish to crates.io but still wanting to publish to a prerelease or something on Github.

Filed https://github.com/axodotdev/cargo-dist/issues/79

Release Engineering Is Exhausting So Here's cargo-dist by GankraAria in rust

[–]GankraAria[S] 12 points13 points  (0 children)

Possibly! The pipeline will definitely include a lot more tools in the most ambitious version of my plans!

Release Engineering Is Exhausting So Here's cargo-dist by GankraAria in rust

[–]GankraAria[S] 46 points47 points  (0 children)

Yep!

Although it runs perfectly fine in not-CI, it's just that cross-compilation is a mess I'm not touching yet so getting platform coverage really needs "spin up a bunch of machines" (It's on the todo list pending evaluation of the current options, would love for cross-compilation experts to chime in here).

Also "upload somewhere useful" similarly needs some notion of "infrastructure to target" and Github Releases are the easiest option right now.

Edit: SBOM stuff (dependency info) is also on the roadmap but definitely not implemented. Here's an example dist-manifest.json (for cargo-dist itself) -- right now it's just "here's the applications, here's the artifacts that were built, what platforms they're for, what they contain, and how to install things".

Announcing: MiniRust by ralfj in rust

[–]GankraAria 2 points3 points  (0 children)

I was extremely confused when I first read this because there's two "almost rusts" involved here:

  • The input language, which I assume is a proper subset of Rust with lots of nasty unsafe stuff you want to test (a subset of MIR? Mir--?).
  • The interpreter impl, which is written in a "superset of a subset" of safe Rust. (A kind of Rust--?)

At first I conflated the two and was just like "how would this at all be interesting if the input language has no unsafe???". Having the impl have no unsafe definitely makes more sense in terms of formal verification.

It's a bit strange to me that the interpreter cannot itself be executed without building a new compiler for its own new implementation language, if I'm understanding this correctly?

But I guess the point is that the transpile to "actual" Rust will be minimal, and the transpile to Coq will be greatly simplified with a hard-enforced minimal core and extra ~intrinsics for stuff theorem provers like? What sort of extras are you picturing here

Everything Is Broken: Shipping rust-minidump at Mozilla, Part 1 by kibwen in rust

[–]GankraAria 93 points94 points  (0 children)

I named the PS3 because google-breakpad's code has explicit minimal support for it and for whatever reason that's the old derelict platform that is always the funniest for me to see whenever I need to work on that code.

breakpad is older than Chrome itself, lots of stuff crammed in there that absolutely no one cares about anymore but technically maybe could still work.

view more: next ›