I mean that is literally what is done in other places, the P Invoke stubs are generate very well opt

I 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)

KKai I mean that is literally what is done in other places, the P Invoke stubs are ge...

Alexx999•4/19/22, 6:38 PM

easy: imagine string with 1073741791 characters

Alexx999•4/19/22, 6:39 PM

or even 715827882

Alexx999•4/19/22, 6:40 PM

and before you ask - yeah, I've seen systems operating on such strings

Perksey•4/19/22, 6:41 PM

I mean, all you’d need to do is try to marshal the bee movie script and suddenly your system doesn’t cut it

Alexx999•4/19/22, 6:44 PM

also, memory is not always free, there's cost for having 3x mem usage

Perksey•4/19/22, 7:22 PM

@alexx999_ sorry for the delay, will have a poke around your draft PR now!

PPerksey @alexx999_ sorry for the delay, will have a poke around your draft PR now!

Alexx999•4/19/22, 7:51 PM

btw, I can prove that moving structs is not a breaking change

KaiOP•4/19/22, 7:51 PM

hate 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

KaiOP•4/19/22, 7:54 PM

Also sleepy brian messing up indent and intend again

Perksey•4/19/22, 7:56 PM

sleepy brian

Lyris the Kitori•4/19/22, 7:57 PM

who

KaiOP•4/19/22, 7:57 PM

as you can see, I'm sleepy

KaiOP•4/19/22, 7:57 PM

Hi Sleepy, I'm brian

Lyris the Kitori•4/19/22, 7:57 PM

hi brian, im dead inside

Perksey•4/19/22, 7:59 PM

byeee briann

Alexx999•4/19/22, 8:07 PM

@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

Perksey•4/19/22, 8:08 PM

how are extension functions even loaded then

Perksey•4/19/22, 8:09 PM

that was the best guess i had at the time

Alexx999•4/19/22, 8:10 PM

yeah, 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

Alexx999•4/19/22, 8:11 PM

so you must enumerate platform objects and then query extensions per platform

Alexx999•4/19/22, 8:12 PM

it's done this way because each platform may reside in separate standalone .dll

Perksey•4/19/22, 8:12 PM

yeah course, like vulkan

Perksey•4/19/22, 8:12 PM

ughhhhhh

Perksey•4/19/22, 8:12 PM

well we can do what we did for vulkan and have a TryGetPlatformExtension

Perksey•4/19/22, 8:13 PM

anyways, i want to curl up in a ball in bed now, so putting the laptop away for this evening

PPerksey well we can do what we did for vulkan and have a TryGetPlatformExtension

Alexx999•4/19/22, 8:13 PM

yeah, that's what has to be done

Alexx999•4/19/22, 8:14 PM

and a different NativeLoader impl

Alexx999•4/19/22, 10:27 PM

I'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

Perksey•4/20/22, 11:09 AM

@kaijellinghaus what do you feel about the above

KaiOP•4/20/22, 11:09 AM

If it 100% didn't work before no reason to ensure that it stays that way

Perksey•4/20/22, 11:10 AM

@alexx999_ ok cool, you've won us over on the struct package refactoring

Alexx999•4/20/22, 11:10 AM

LOL

Perksey•4/20/22, 11:10 AM

but i think on the enums front we'd probably want to generate overloads on top of the naked uintuint types

Perksey•4/20/22, 11:11 AM

whereas rn they just get mapped directly to the enum type

PPerksey but i think on the enums front we'd probably want to generate overloads _on top_...

Perksey•4/20/22, 11:11 AM

with the only exception being cases where the enums are not 32-bit, we can just map those willy nilly

PPerksey but i think on the enums front we'd probably want to generate overloads _on top_...

Alexx999•4/20/22, 11:11 AM

we circle back to the problem that not all enums are uints, and having CLEnum64 sounds a bit... over the top

Perksey•4/20/22, 11:12 AM

yep, 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

Alexx999•4/20/22, 11:12 AM

and having some one way and some the other is... very inconsistent?...

Perksey•4/20/22, 11:12 AM

it's about not breaking where we're not already broken

Alexx999•4/20/22, 11:13 AM

the extensions are transparent, and having uint CLenum extension overload over ulong native enum is fine for the most part

Perksey•4/20/22, 11:14 AM

tbh rn i'm leaning towards just merging as is and then adding overloads for bits where we don't want to break.

Perksey•4/20/22, 11:14 AM

the struct stuff is pretty much good to go as i see it

Alexx999•4/20/22, 11:23 AM

btw, I have one more idea (breaking)

Alexx999•4/20/22, 11:24 AM

which is, have typed, ugh, "object handles"?

Alexx999•4/20/22, 11:25 AM

would be handy to have "Device" struct that will be only accepted by "clDevice...()" methods

Alexx999•4/20/22, 11:26 AM

now 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

KaiOP•4/20/22, 3:25 PM

I think done with struct layouts (pending review) and will start working on the Scraper now

PPerksey just not that we had a RID for it

frenzibyte•4/20/22, 8:55 PM

not sure if you're aware of this by now, but osxosx should be a valid runtime identifier for fat libs (x86_64+arm64)

Ffrenzibyte not sure if you're aware of this by now, but `osx` should be a valid runtime ide...

Perksey•4/20/22, 9:16 PM