but i think on the enums front we'd probably want to generate overloads _on top_ of the naked `uint`
but i think on the enums front we'd probably want to generate overloads on top of the naked
uint types
Pwhereas rn they just get mapped directly to the enum type
Pwith the only exception being cases where the enums are not 32-bit, we can just map those willy nilly
Awe circle back to the problem that not all enums are uints, and having CLEnum64 sounds a bit... over the top
Pyep, i agree. i want to phase out CLEnum tbh in favour of new overloads/completely refactoring the signature where it's just broken so far
Aand having some one way and some the other is... very inconsistent?...
Pit's about not breaking where we're not already broken
Athe extensions are transparent, and having uint CLenum extension overload over ulong native enum is fine for the most part
Ptbh rn i'm leaning towards just merging as is and then adding overloads for bits where we don't want to break.
Pthe struct stuff is pretty much good to go as i see it
Abtw, I have one more idea (breaking)
Awhich is, have typed, ugh, "object handles"?
Awould be handy to have "Device" struct that will be only accepted by "clDevice...()" methods
Anow it's nint which is nice and all but not helpful, I had a bug where I passed wrong nint to the method and it... partially misbehaved? Like, no error just wrong result, very "fun" to debug
KI think done with struct layouts (pending review) and will start working on the Scraper now
Fnot sure if you're aware of this by now, but
osx
Psee also help-and-questions
Vroeyskoe#4938
I just tested with my M1, and actually I need to fix my pr a bit. For some reason the
osxosx-arm64Original Message
Quoted by Perksey#6579
Tjust look at how SkiaSharp does it
Pno thanks
Pthis isn’t even my code/library
PI don’t know why I’m hearing about it haha
Finteresting... can someone link the PR? we've used
osxI suppose our loader could just not account for it, but that’s unlikely
Pwe have to do a lot of hand holding for the runtime when it pokes in NuGet packages
Fyeah I'm in the middle of commenting to that rn
F@roeyskoe so I've created a local package and tested against a fresh project similar to what I did in https://github.com/mellinoe/veldrid-spirv/pull/24
Fand it's working for me here on macOS m1
FI believe you mentioned macOS m1 still requires
osx-arm64
RI already replied in github, but
osxlet's keep discussing in github, better visibility there
Lstuff like this flags cast is making me actually want to start playing with the generator a bit https://i.beyleyisnot.moe/YQk3nmQ.png
Ayou can't fix it - that's a breaking change
Li mean
Li could just have both
Lalso doesnt a number implicitly cast to an enum of the same type?
Lim not sure
Amaybe in new C# versions, I've been surprised to see it accepts "0" now
A...but it seems that nothing except "0" is working, so - no
VC# never does implicit conversions between an enum and the underlying type
VAlways requires an explicit cast
Asure as shit it does 
Vsquints what...
VSince when...
Ayeah, like I said: I've been pleasantly surprised myself
Abut anything except 0 is not accepted
VOh! I think that's specifically because it is a
[Flags]as expected
V0yeah, quite likely