I 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
I’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
@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?
I’ve just been shoving rarely-used code and scripts somewhere in the engeng 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.
I 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.
I 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
which 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
The 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 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
i have no idea how all of those constraints would look when added to the generator though, probably some code-sharing between UseSilkDSLUseSilkDSL and a new mod for generating the Silk.NET.Core sources.
generator 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
This 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?
basically 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.
K
P
ready for LTS
C
