Lthis should be fixable though too
Lwip patch
Lthe reason i said this was that my original plan was to write a script to find all the differences and then generate a MASSIVE typemap file to just typemap away all the shit
Lthen i realized that was stupid and just started looking into the actual problem
Li want you to know that it WOULD have worked i tested my typemap theory and i was able to manually fixup large parts of shaderc
Lfun fact: i have no idea what canonical type vs named type means: but it gets shaderc into a better state changing what i did so therefor im on the right path
TCanonical type is the most underlying type after all typedefs, attributes, elaborations, and other C/C++ modifiers have been stripped away
TThis is where modern ClangSharp often has a self recursive function that steps through each step of the typedef and manually accounts for certain kinds of abstractions(like typedefs) or makes observations based on others (attibutations, etc) and rarely goes straight for canonical
Loh yeah thats what we used to do as well however thats Not Working
Lso im doing a mix of proper recursion and also just straight up canonicaltype
TAs otherwise you can miss important info, like something being intptr_t or size_t and therefore needing to be nint
Or you also miss stuff like function pointer calling conventions
Or you also miss stuff like function pointer calling conventions
TWhy isn't that working? Are you missing a particular Type kind that needs handling as part of the recursion? Some were introduced in newer Clang due to how the language works
Luhhhh i dont know honestly i just poked at it until i did what i wanted and when it didnt i just changed something random until it looked more correct
just something in the chain isnt finding the underlying type and so the name of the typedef instead of the underlying type is being used when generating for some reason now
just something in the chain isnt finding the underlying type and so the name of the typedef instead of the underlying type is being used when generating for some reason now
Tthis was when moving to Clang 16 from 15?
Leg given
typedef struct shaderc_compiler* shaderc_compiler_t; BuildTools thinks any usages of shaderc_compiler_t are shaderc_compiler_t instead of shaderc_compiler* nowLwhen moving from 15 to 16 yes
Tright, this was also when they changed from
(anonymous enum at to (unnamed enum at, or vice versaTI'd recommend looking at all athe stuff I had to do in https://github.com/dotnet/ClangSharp/pull/456/files#diff-bac9b18ad93dc3cb267b2bd241193960d517fac455eb8b12e8e8e7aa8020108c
TThere was also: https://github.com/dotnet/ClangSharp/pull/438/files, where I improved type checking in general
TTall were iterative towards making v16 happy, which wasn't fun 
Thttps://github.com/dotnet/ClangSharp/releases/tag/v16.0.0 has the full diff, most are irrelevant towards type lookup
but might be something else worth looking at in that list too
but might be something else worth looking at in that list too
C@SilkX Team Aside from the math, what do we have left to do for SilkX to be ready for review?
Kgenerator
Mthe rest of the fucking owl
Ptbh, not a lot, we can go with just what we have now but I’d worry that it’d essentially be the same as the last coffee and code where we discussed it
Pthe proposal needs updating based on what we’ve decided
PI feel like the most ideal scenario would be getting a GL triangle working
CSo minimum:
- update proposal docs to match implementation
preferably:
- get OpenGL generated w/ example (hello triangle)
- Math library
I know there are a few cleanup tasks as well:
- add native versions of the functions
- fix the response file handling (searching and better logging when not found)
- update proposal docs to match implementation
preferably:
- get OpenGL generated w/ example (hello triangle)
- Math library
I know there are a few cleanup tasks as well:
- add native versions of the functions
- fix the response file handling (searching and better logging when not found)
Mi start work on monday so i hope you guys can do the other half of the maths library
Pyeah so I’ll push up what I’ve done on VTs now if I haven’t already, I think there’s everything implemented except for the thread-local statics which realistically isn’t needed
CThread-local statics?
CAlso does silk have a trello/Jira/etc.?
Myes
Mgithub issues
Lwe also have a github project for more fine grained task tracking
L(we forget it exists most of the time though)
P
CYeah that is more what I was thinking of.
Github issues is difficult to at a glance tell what's open, in progress, or ready for review (though PRs are good for this).
Github issues is difficult to at a glance tell what's open, in progress, or ready for review (though PRs are good for this).
Pthis is the "calling a static function on
Glfw and it forwarding to a ThreadLocal IGlfw" thing needed to use OpenGL with static functionsPShould we organise a coffee and code?
CI think a coffee and code would be productive once SilkX is in the minimum state to present (your VTable changes go in and we update the proposals).
PI think once we’ve done that we’re ready for a full fat working group meeting haha
Cyeah, but is there a reason to get everyone together before that? As long as we can update the proposals relatively quickly (was going to look at that maybe sometime this week). we should be good with minimal in the next week or two.
Cor maybe I'm misunderstanding coffee and code, since I've only caught bits and pieces. To me it seems like a periodic meeting to get all the major contributors/stakeholders in a call together and discuss state and any upcoming decisions.
PC&C is just an informal community call yeah. We tend not to get the whole audience though because they’re a lot more impromptu than the working group meetings, which usually have more than a week of notice.
PI mean we can do but I don’t think a lot has changed since the last C&C in which we discussed it
Pwe’ve flipped flopped to const correctness and back again, so really it’ll just be the name trimming and the vtable stuff
Pwhich will probably be unobjectionable
Pit may be worth it as a triage session though, though technically we should wait for WG go-ahead for that as SilkX is still separate
