#State of two SDKs
sour vapor
I have been traveling for work for a week so I haven't had time yet to engage with Wyn on a merge plan. I'll start on that next week. It will probably be a slow roll.
hollow basin
The one merged in works, but it doesnt work from the dagger module pov, win had a branch that was looking into this, but the merged in sdk does work, just not like the offical ones with custom functions. M-Pixels one does and for sure, i think merging is what we need to do
I do have some thoughts around the the SDK being a bit different from the other sdks, i.e attributes on functions, along with module init (if possible?) and the dll instead of how other modules include the source as part of compilation rather than a compiled dll dependency but i think all of this can be discussed
the thunking concept is pretty neat
and yeah, its very fast
@sour vapor did some amazing stuff!
sour vapor
I wondered if not using attributes would be a consistency issue at one point but then realized that the Go SDK also uses whatever functions are exported (public), doesn't use attributes/annotations/decorators except for optional and path. That's unique to TypeScript and Python.
C# modules will compile from source, actually. The version in the video didn't support that yet, but what's on GitHub right now does.
hollow basin
Is there a way to have the source generator produce the source so its visible in the output and not a compiled binary?
sour vapor
... but it's probably easier to just use a decompiler, or a good IDE that lets you traverse into the generated functions (by decompiling on the fly).
craggy iron
I second this, if you are developing .NET you should already be able to do this, when inspecting nuget source or system libraries.
hollow basin
I think it's because the source generator isn't part of the project. rider usually already shows me source generator code but I think it's because its an imported dll and so is different.