32 lines
3.6 KiB
Plaintext
32 lines
3.6 KiB
Plaintext
[video member=pervognsen stream_platform=twitch project=bitwise title="Noir Demo & Dynamic Type Info" vod_platform=youtube id=PfDIP96xEdM annotator=Miblo]
|
|
[0:00][Recap and set the stage for the day][:speech]
|
|
[1:09][Jump right in to a demo of Noir][:library :"platform layer" :speech]
|
|
[2:49][Note why some of it is written in C, and some in Ion][:language :speech]
|
|
[3:26][:Run Noir to demo its printouts, :"input handling" and :"window management" capabilities][:library :"platform layer"]
|
|
[10:09][Describe the :"window management" code and the utility of its state-based, bidirectional state-synchronisation approach, as opposed to a function-based API][:research]
|
|
[17:31][Demo the :audio][:"input handling" :library :run]
|
|
[18:45][Describe the :audio code, with a few words on audio synthesis][:library :research]
|
|
[24:48][Demo the synthesisers][:audio :run]
|
|
[29:15][Describe state-based style code][:speech]
|
|
[31:45][Q&A][:speech]
|
|
[32:22][@nothings2][@pervognsen It is kinda possible to do push buffer sound. stb_platform provides a low-latency push buffer for short sounds and a high-latency buffer that allows continuous, more-than-a-single-buffer sounds with dropout-protection. (But it also does a LOT of extra mixing of 0s because of this. So it does also provide the callback way too.)][:audio]
|
|
[34:44][@nxsy][Why is synced_title a char\[MAX_TITLE\] while title is char const*?]
|
|
[36:12][@synchronizerman][@pervognsen For the :audio demo, are you doing anything significantly differently in Ion using some :language feature, or could I (for example) do the same thing in C with few or no syntactic changes?]
|
|
[37:54][Dynamic type info: Unique type identifiers with typeof][:language :speech]
|
|
[44:24][Dynamic type info: Runtime type info][:language :speech]
|
|
[48:55][Implement :parsing for type info, including test_typeof()][:language]
|
|
[52:41][Enable resolve_expected_expr() to handle EXPR_TYPEOF_TYPE and EXPR_TYPEOF_EXPR, augmenting the Type struct with a typeid][:parsing :language]
|
|
[1:02:43][:Run it, hit an assert in the generator, and note the reason for assert(0)][:parsing :language]
|
|
[1:03:32][Enable gen_expr() to handle EXPR_TYPEOF_EXPR and EXPR_TYPEOF_TYPE, with a few words on the benefit of the hash table approach][:"code generation" :"data structure" :language]
|
|
[1:08:41][:Run it and take a look at our generated C code][:"code generation" :language]
|
|
[1:09:37][Introduce Any struct, a typeid typedef and print_any()][:language]
|
|
[1:13:19][:Run it to see our beautiful type printouts, with a few words on the assumptions we can make with whole-program-compilation and absence of dynamic libraries][:language]
|
|
[1:14:37][Q&A][:speech]
|
|
[1:15:08][A few words on the future of handling runtime type info using a typeinfo_table][:language :speech]
|
|
[1:16:48][@xanatos387][Would typeinfo exist for any Ion-visible type, or would there be situations where even Ion-declared types might not have typeinfo?][:language]
|
|
[1:18:03][@nothings2][@pervognsen How about get rid of TypeId and just have IonType* everywhere, and typeof(x) returns IonType*? You have to have dummy IonType for types with no typeinfo, and you can't make the types constant for switch, but I think getting rid of the extra get_typeinfos everywhere would be worth it. (And you could make Ion support switch on IonType* but generate if / else chains when outputting C)][:language]
|
|
[1:19:44][@nothings2][@pervognsen If the dummy values can be all-0 structs, you can pack them together with pointer-alignment spacing, so 4 / 8 bytes per type][:language]
|
|
[1:20:39][@nothings2][Yeah, fair. (Especially for something targeting embedded)][:language]
|
|
[1:21:44][Cut the stream over to the extra stream][:speech]
|
|
[/video]
|