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
Pwe could have an ideas session though
Pmainly around windowing and extension design I think
Pas we haven’t even thought about the extension system yet and how that works with VTs
CThat's fair, especially since any meeting about the go-ahead for SilkX will probably be better separate
Lid be down for a C&C at some point soon, even if theres not too much to discuss
PLooking back at the rejected proposals, there’s one that looks suspiciously like SilkX haha: https://github.com/dotnet/Silk.NET/blob/main/documentation/proposals/(Rejected)%20Proposal%20-%20Better%20Strings.md
PThat proposal nearly made it in as well, but I changed my mind last minute and withdrew the proposal
Mwhat was wrong with it?
Pno idea, the only meeting notes I have from that working group meeting is “General consensus was that this is ok-ish, needs WG approval.” and then I withdrew it after rectifying all of the review comments
PI have genuinely no idea why
Mre-propose it :)
Pyep there’s no real conjecture around it
Pthe first link doesn’t really say much, more me going “oh this was rejected, must’ve meant it was shit” forgetting that I voluntarily withdrew it
PI have no idea why I withdrew it but we’ll be re-proposing it in the form of the SilkX proposal
Pclearly just didn’t feel like it idk
Pman
Pi've just realised
Pi'm going to have to make another bakery in SilkTouchX
Phopefully it Won't Suck
this time
this timePeither that or we just use a fat GLAD header with everything included
Phrmf that seems like a meh option as well
Pok the mod pipeline system actually makes for a pretty smart implementation of the bakery.
1. generate bindings for both GL and GLES headers. this will have duplicates
2. flow that through the
3. flow the merged bindings through
4. setup
1. generate bindings for both GL and GLES headers. this will have duplicates
2. flow that through the
AddApiProfiles mod with a BakeToRoot setting (i.e. merge all of the duplicate APIs in these subdirectories into just one set of APIs). This adds basic SupportedApiProfile attributes in the process (obviously we don't have access to versioning here)3. flow the merged bindings through
AddKhronosMetadata which will further clarify the info in those attributes (i.e. extension names, supported versions, etc). could also add goodies like Count attributes etc.4. setup
AddVTables to decompose the API interfaces based on that metadata (bringing back IGLVersion30, IKhrDebug, etc) but also to even further decompose duplicate APIs between the decomposed interfaces themselves. that way IKhrDebug, IArbDebugOutput can both be used from just IDebugFunctions or something like thatPthe interesting thing i haven't quite figured out how to deal with is API removals
Pthere are cases where APIs were added in OpenGL, then deprecated (removed), then brought back in a later version
Kthats pretty nice sounding
Mthat's a dangerous hyphen to miss
Keh?
Manyways
L
Kim so confused
