Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Marijn
    @marijns95:matrix.org
    [m]
    If it wasn't for a handwritten changelog being a bit easier to redact (ie. omit internal changes, clean up PR titles), I'd go for GH automatically generating it from commits when "publishing" a release on a tag
    Ralith
    @ralith:ralith.com
    [m]
    yeah, mixed bag
    fortunately low stakes
    Marijn
    @marijns95:matrix.org
    [m]
    Ralith: I'm also starting to get internal complaints about performing breaking ash releases relatively often for "minor" improvements
    Perhaps it really is time to start actively maintaining a 0.37-stable branch that we'll either directly merge non-breaking changes into, or manually cherry-pick merged PRs to?
    This one is on me though, the last (also breaking, for extremely minor things) Ash release felt ages ago but it's only been just over a month 😅
    Marijn
    @marijns95:matrix.org
    [m]
    And in the event that people like to see their breaking changes published to crates.io, but we don't yet feel like we have enough material for yet another breaking release, we can publish a prerelease for the next version while prolonging the non-breaking patch cycle much longer
    Regarding cherry-picking though, this may end up in conflicts real fast given that we have lots of autogenerated code that will get out of sync
    So we might as well create a special breaking label and keep (as maintainers) rebase feature PRs until we merge them all at once (into / on top of the stable branch)
    Ralith
    @ralith:ralith.com
    [m]
    dealing with the generated code isn't too bad, you just ignore conflicts there and rerun the generator
    Marijn
    @marijns95:matrix.org
    [m]
    Fair enough, same for merging PRs later
    Still cumbersome when rebasing (would love the ci to run on everything individually), really don't like large merge commits with lots of conflict resolution (unless it's exclusively generated changes, can make an exception for that)
    Joshua Suskalo
    @IGJoshua
    Hey, I'm just getting back into using ash after a long time away, and I notice that there's the new const names that use the CStr::from_bytes_with_nul_unchecked which requires a feature flag in the attributes of the crate. Is there something I have to do in my local project to use it? Or is this a problem with the published 0.37 version not having the feature flag enabled?
    Ralith
    @ralith:ralith.com
    [m]
    is your rustc up to date?
    Joshua Suskalo
    @IGJoshua
    I think so, I'm running arch and I've updated all my packages recently. Do I have to do some cargo command to ensure it's fully updated?
    $ rustc --version
    rustc 1.56.1 (59eed8a2a 2021-11-01)
    ah, looks like it's not fully updated since 1.59 is the most updated now
    hmm
    ah, I see, the project was old enough that I had not yet updated the edition from the 2018 edition
    Joshua Suskalo
    @IGJoshua
    sorry about the trouble. Looks like I just needed to do a rustup update
    Marijn
    @marijns95:matrix.org
    [m]
    @IGJoshua: Too late for your situation now, but hopefully this is going to help in the future: MaikKlein/ash#604
    I also wasn't actively aware that from_bytes_with_nul_unchecked got bumped to const only in 1.59, quite bummed that we didn't get to know that up-front
    Marijn
    @marijns95:matrix.org
    [m]
    Ralith: Should we just go ahead and merge your breaking PR straight to master already?
    Ralith
    @ralith:ralith.com
    [m]
    suits me, it's a big rebase hazard so it'd be nice not to have it lurking
    Marijn
    @marijns95:matrix.org
    [m]
    Then over time, as nonbreaking stuff appears, I'll create a 0.37-stable branch and start cherry-picking stuff (merged to master first) to it that we'd like for a patch release
    And then see if we can do a couple months without a breaking release - but I'm still more than happy to start with 0.38-pre.X releases as soon as we have some tangible UI changes ready we'd like to throw in the wild
    Ralith
    @ralith:ralith.com
    [m]
    fwiw I'm skeptical that it can ever be sound to assume ABI-equivalence between struct Foo { ..., length: usize, ptr: *const T, ... } and struct Foo { ..., field: (usize, *const T), ... }
    Marijn
    @marijns95:matrix.org
    [m]
    Fair enough, I hadn't given that much thought just yet
    And we'd have the edge-case of one length value being shared by multiple pointers, so it might not be worth pursuing this at all
    Ralith
    @ralith:ralith.com
    [m]
    maybe if we explicitly restrict targets to those for which that is true, which might plausibly be all the important ones, but it's an unsettling prospect
    right
    the current approach is pleasantly uniform
    Marijn
    @marijns95:matrix.org
    [m]
    Are you done with #602 btw? As in, #[inline]'ing the rest of the functions shoul;d be done in a separate PR anyways?
    Ralith
    @ralith:ralith.com
    [m]
    yeah, I'm inclined to pursue that in a separate PR; no need to make things too monolithic
    there's even a case to be made for splitting the existing inlining out entirely, but eh :P
    I think the bulk of the remaining inlining work is to go through all the handwritten stuff, which will be tedious
    though I've gotten a ton of mileage out of cheeky regexps so far
    Marijn
    @marijns95:matrix.org
    [m]
    SSR from rust-analyzer has treated me well back in the day too...
    Until needing some very specific stuff with multiple statements, where it all fell apart :D
    Regarding ABI compliance, I guess the only issue here is alignment?
    (/me doesn't remember if sizeof(usize) == sizeof(*const) in Rust)
    (Same for their alignment)
    Right, usize is literally defined as The pointer-sized unsigned integer type.
    But it seems unlikely that their alignment is forced to be the same, which could indeed cause ABI differences between the two
    Ralith
    @ralith:ralith.com
    [m]
    SSR?
    the main issue in my mind is that structs are not semantically transparent in C ABI; placing fields in a struct can in principle change how they interact with the layout algorithm all on its own
    Marijn
    @marijns95:matrix.org
    [m]
    Structured Search and Replace
    Marijn
    @marijns95:matrix.org
    [m]
    On top of your PR, with a literal return None; coded at the beginning of derive_setters() and regenerating:
    $ hyperfine -p 'cargo clean -p ash' 'cargo b -p ash'
    Benchmark 1: cargo b -p ash
      Time (mean ± σ):      5.174 s ±  0.027 s    [User: 5.914 s, System: 0.319 s]
      Range (min … max):    5.101 s …  5.193 s    10 runs
    So removing setters entirely is only ~550ms, and that's going to be less when we can't omit ~half of those for having pointers/slices/other magic sauce
    Curious where we're loosing out now