I’ve had to fill in one in my entire lifetime I think
I’ve had to fill in one in my entire lifetime I think
KSeems like the UK just has a fairly decent system to streamline processes + digitalization
Khere digital files are still considered not legally binding so Fax is the most digital you'll get
Kpfffffff germans love their burocracy so that will never happen here
Ktbf US authorities seem to just kind have fucked themselves. .... SSN is a good system
PSSN is not a good system
Pstill lots of very absurd paper forms
PSSA offices needed everywhere
Pthey have nothing on UK’s NINO
KI only had to deal with the like tax exemption related papers so far and have just winged it - never heard anything from it and I'm not planning to ask them about it again
Pah the W-8BEN
PI’m stuck on the W-7 which literally won’t let me apply for an ITIN (basically an SSN stand-in for tax purposes) until April because of all the silly rules
C@Perksey Where is a good place to handle the initial Pointer class generation?
also do we have a place where we will make decisions on when we use these types, and would need to add additional higher dimension types?
also do we have a place where we will make decisions on when we use these types, and would need to add additional higher dimension types?
PI’ve just been shoving rarely-used code and scripts somewhere in the
Not sure what you mean for the second question. The proposal process basically involves us making a decision and documenting it in the proposal (optionally including alternatives), and then debating and/or justifying decision to the working group in a meeting. Often this involves a few proposal revisions before it gets approved.
eng folder.Not sure what you mean for the second question. The proposal process basically involves us making a decision and documenting it in the proposal (optionally including alternatives), and then debating and/or justifying decision to the working group in a meeting. Often this involves a few proposal revisions before it gets approved.
Pas for the usage and dimensions, these need to be documented in the proposal I think - I don’t remember writing any words around it yet.
The code that generates code that uses it is in SilkTouchX
The code that generates code that uses it is in SilkTouchX
CI meant more in code, the proposal discusses higher dimensions than 3 being built as needed on the fly as needed. I was thinking about whether it was feasible to add those in now as well, whether as as a mod or part of some generation step.
If we still aren't sure I can just get the generator stood up and we can decide on how it is used later.
If we still aren't sure I can just get the generator stood up and we can decide on how it is used later.
PI think 3 is the highest dimension I’ve ever seen in a silk binding, so 3 makes sense until we spot a use case (in the form of a generator crash :P) that warrants increasing it
Pwhich is why I’m keen on keeping the generation code you’re writing around in hopes that if that day comes it’s just a case of increasing a number somewhere
CThe way it is setup currently, I was just going to back it with a binary tree to track what exists and then we request a type to be generated it either generates it on the spot or when we are finished we generate all the types in the tree. This would keep to only the types we need and expand without crashing. Since the types are reliant on the outer type being available (aka PtrMutPtr requires MutPtr) this method should work fairly well and require little upkeep.
I would just populate it with the base 3 levels ahead of time to catch the general cases.
I would just populate it with the base 3 levels ahead of time to catch the general cases.
Pit’s a smart idea, and one we could implement if ever we want to add a “coreless” mode to SilkTouchX.
Pi mean we could do that if you wanted to add that to SilkTouchX. i'm keen to have dimensions up to three present in Silk.NET.Core, and also keen to make sure that for Silk.NET first-party we crash if a binding needs more than 4 (so we can add these to Silk.NET.Core instead of potentially multiple assemblies having duplicate higher-dimension pointers), but for third-party users that may not want to use Silk.NET.Core it certainly makes sense
Pi have no idea how all of those constraints would look when added to the generator though, probably some code-sharing between
UseSilkDSL and a new mod for generating the Silk.NET.Core sources.CIs there any reason we cannot add these files on the fly to Core and then rebuild?
Pgenerator jobs don't have knowledge of other generator jobs, they're all executing in parallel, so you wouldn't really be able to keep track of what's used well without conflicting or having other horrible things happen
P(they're also scoped to a specific source folder, so it'd be very inconsistent to escape from that configured folder)
CThis is where I don't know necessarily enough about the generation process. My thoughts would be that we would collect the clangsharp output, apply any mods (this might be within clangsharp), generate our C# files, and then build the project. is that about right?
Pbasically yeah, only it doesn't build it after. ClangSharp generates raw sources, we load them into Roslyn, do the silky mods, and then outputs them to disk.
Pthere's an example generator config here https://github.com/Perksey/SilkX/blob/main/sources/SilkTouchX/test.json
Cso are we not generating the binaries during the generation?
Pnope
Cokay, so then we can generate sources that rely on types that technically don't exist until after generation is complete. My thought would be a final step, running after all jobs have finished, that takes in the pointer types were used. We can handle this by either using a readwritelock to update a master binary tree. Or we have each job keeps its own tree and we merge them down when we are done. Then generate the sources to Core, minimum being our first 3 levels.
CThe big advantage here is we generate these classes every time, avoiding any potential out of date classes ending up in core. We also then can also fire and forget, requiring less things to worry about later.
Pthe thing is with Silk.NET.Core is that it is likely to be used both everywhere in silk but also everywhere in third-party bindings that use SilkTouchX. we won't want one lone pointer type for a given dimension, if we're adding any of new dimensions to Silk.NET.Core we will want all of the types generated.
Pand that becomes quite a huge type explosion, so it's best to have a human in the loop to accept that.
Cokay, yeah if we are concerned about making sure all variants of a particular dimension are present then I agree we want to avoid auto generating, since that explodes fairly quickly.
CThe only question I have is, is there a use-case to need a type in a specific dimension which none of silk consumes?
Cthat may be worded a little poorly.
CI mean like if we find one use for MutPtrMutPtr is there are use-case for PtrMutPtrMut?
Presponse before clarification: the only thing I can think of is a third-party binding needing a pointer of a specific dimension and not wanting to open a feature request for said dimension with us (which is understandable). in this use case, it may be acceptable for us to generate on-the-fly but this would be explicitly user opt-in.
response after clarification: it mostly comes down to user expectations. it would be inconsistent for us to have a pointer type of a given dimension for one mutability variation without having all of the mutability variations given that we'll be having all variations for dimensions up to 3
response after clarification: it mostly comes down to user expectations. it would be inconsistent for us to have a pointer type of a given dimension for one mutability variation without having all of the mutability variations given that we'll be having all variations for dimensions up to 3
Cafter clarification: I personally, don't feel like we do it because it looks nice to the user, but has no function is a good reason. For instance if we find one use-case for a 5th dimension ptr we want to add, we go up to 124 types, for what seems to amount to completion's sake, rather than simply adding the 4 types we needed (2 generic, 2 non-generic). Even a 4-depth would move us from 28 types to 60.
This debate is really rather pointless, since I do agree that all of the 3-depth seems reasonable, and I doubt we will see 4+ depths often, if ever. It just seems like if we do run into this case we would be adding bloat for aesthetics of the codebase.
This debate is really rather pointless, since I do agree that all of the 3-depth seems reasonable, and I doubt we will see 4+ depths often, if ever. It just seems like if we do run into this case we would be adding bloat for aesthetics of the codebase.
CFor now I'll write it to generate all types up to a specific dimension in an output directory, and this can easily be revisited at a later date.
Psounds good. i think the likelihood of silk encountering a 4+ dimension pointer is extremely unlikely, but if that does happen these are the things we as the first-party need to think about.
for third-parties it is more likely (in the sense that we have no idea what they're going to throw at our generator), but if a need arises we could just advise users to opt-in to a property that generates the specific variant as needed.
for third-parties it is more likely (in the sense that we have no idea what they're going to throw at our generator), but if a need arises we could just advise users to opt-in to a property that generates the specific variant as needed.
Ctest output from the generator
PTRMUTPTR.gen.cs10.59KB
PTRMUTPTR.generic.gen.cs10.88KB
CI just took over the pointergen project
Cit now generates all 3 levels
Pah good, I was hoping you would.
Also the to-pointer casts should be explicit instead of implicit - uses
Same comments apply pretty much by the looks of things.
Non-Generic
T doesn't seem to exist, this seems to be the non-generic variantwhere T : unmanaged
This needs to bepublic readonly ref T Ref
readonly ref MutPtr (basically it's equivalent to this[0]. you could even implement it like that if you want)This should be a reference to the raw pointer form of its inner dimension. to forpublic ref PTRMUT* GetPinnableReference()
PtrMutPtr this would be ref readonly byte** (so that when used in a fixed statement it becomes byte***)Missed a space.public static bool operator ==(object? lh, PTRMUTPTRrh) => lh == null ? (void*)rh == null : false;
My my that's a little over 3 dimensions!public static implicit operator byte******(PTRMUTPTR ptr) => (byte******)Unsafe.AsPointer(ref Unsafe.AsRef(in ptr.Ref));
Also the to-pointer casts should be explicit instead of implicit - uses
Unsafe.AsPointer does not fix the ref and therefore should only be used for known-stack pointers (i.e. the user has to be explicit about this to ensure they don't accidentally do anything dangerous)Generic
Same comments apply pretty much by the looks of things.
Pthank you so much for doing this! this is one of the most integral parts of SilkX, and super glad to have community contributions here as a result.
P(I presume the type names are caps to prevent conflicts when trying it out)
Mdoes all of this really need inline IL?
Ponly the single-dimension ones can be native C#
Pyou can't have ref fields to ref structs