Athat's because you're not developing any frameworks
Aor runtimes 
Aotherwise you'd be rather hated for wasting THAT much memory
A...or even not running your code in 32bit mode
SIt actually isn't used here.
I use 1024 bytes of stack memory
I use 1024 bytes of stack memory
SRegardless of what i actually need
SCuz performance
S(That i never had problems with there)
SI have defines for CONSERVATIVE STACK and CONSERVATIVE HEAP btw, they're compiling options
KI mean that is literally what is done in other places, the P Invoke stubs are generate very well optimized. I'm assuming they have a good reason why the length was required here (feel free to go back and check, can't be bothered rn)
Aeasy: imagine string with 1073741791 characters
Aor even 715827882
Aand before you ask - yeah, I've seen systems operating on such strings
PI mean, all you’d need to do is try to marshal the bee movie script and suddenly your system doesn’t cut it
Aalso, memory is not always free, there's cost for having 3x mem usage
P@alexx999_ sorry for the delay, will have a poke around your draft PR now!
Abtw, I can prove that moving structs is not a breaking change
Khate to brag, but 14 lines of change to go from empty struct to struct with full member functionality https://github.com/dotnet/Silk.NET/commit/f948995066801ddd53b0cc9d8363f1ca84c18485
Don't think I've ever managed incremental dev to this degree
Don't think I've ever managed incremental dev to this degree
KAlso sleepy brian messing up indent and intend again 
Psleepy brian
Lwho
K as you can see, I'm sleepyKHi Sleepy, I'm brian
Lhi brian, im dead inside
Pbyeee briann
A@Perksey namely, struct names doesn't really matter because extensions are broken - you cannot use GetProcAddress for OpenCL
and if you can't use any extensions with Silk then it's not a breaking change to break them
and if you can't use any extensions with Silk then it's not a breaking change to break them
Phow are extension functions even loaded then
Pthat was the best guess i had at the time
Ayeah, that's the funny bit: even the official Khtonos ICD dll (that I'm using) is not exposing cl_khr_icd extension method (clIcdGetPlatformIDsKHR) which is literally the only feature this DLL has
Aso you must enumerate platform objects and then query extensions per platform
Ait's done this way because each platform may reside in separate standalone .dll
Pyeah course, like vulkan
Pughhhhhh
Pwell we can do what we did for vulkan and have a TryGetPlatformExtension
Panyways, i want to curl up in a ball in bed now, so putting the laptop away for this evening
Ayeah, that's what has to be done
Aand a different NativeLoader impl
AI've even tried on Linux machine and it's the same - extension entrypoints aren't exported
soooo breaking changes to extensions are 100% fine - no one complained about this so no one is using them anyway
soooo breaking changes to extensions are 100% fine - no one complained about this so no one is using them anyway
P@kaijellinghaus what do you feel about the above
KIf it 100% didn't work before no reason to ensure that it stays that way
P@alexx999_ ok cool, you've won us over on the struct package refactoring
ALOL
Pbut i think on the enums front we'd probably want to generate overloads on top of the naked
uint typesPwhereas 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