Jump to Content
Register
Forgot your password?
Third-party login
Log in with Discord

Bitwise
Blog
Forums
Episode Guide
twitter
Bitwise»Episode Guide
Noir Demo & Dynamic Type Info
Filter mode:
Topics
audio
code generation
data structure
input handling
language
library
parsing
platform layer
window management
(null topic)
Media
🗪Chat Comment
🏃In-Game
🖮Programming🟉
📖Research
🗩Speech
🎭
🏟
🔗
Link to: current timestamp
Credits
Host
Per Vognsen
Indexer
Matt Mascarenhas
?
?

Keyboard Navigation

Global Keys

[, < / ], > Jump to previous / next episode
W, K, P / S, J, N Jump to previous / next marker
t / T Toggle theatre / SUPERtheatre mode
V Revert filter to original state Y Select link (requires manual Ctrl-c)

Menu toggling

q Quotes r References f Filter y Link c Credits

In-Menu Movement

a
w
s
d
h j k l
←
↑
↓
→

Quotes and References Menus

Enter Jump to timecode

Quotes, References and Credits Menus

o Open URL (in new tab)

Filter Menu

x, Space Toggle category and focus next
X, ShiftSpace Toggle category and focus previous
v Invert topics / media as per focus

Filter and Link Menus

z Toggle filter / linking mode

Credits Menu

Enter Open URL (in new tab)
0:00Recap and set the stage for the day
🗩
0:00Recap and set the stage for the day
🗩
0:00Recap and set the stage for the day
🗩
1:09Jump right in to a demo of Noir
🗩
1:09Jump right in to a demo of Noir
🗩
1:09Jump right in to a demo of Noir
🗩
2:49Note why some of it is written in C, and some in Ion
🗩
2:49Note why some of it is written in C, and some in Ion
🗩
2:49Note why some of it is written in C, and some in Ion
🗩
3:26Run Noir to demo its printouts, input handling and window management capabilities
🏃
3:26Run Noir to demo its printouts, input handling and window management capabilities
🏃
3:26Run Noir to demo its printouts, input handling and window management capabilities
🏃
10:09Describe the window management code and the utility of its state-based, bidirectional state-synchronisation approach, as opposed to a function-based API
📖
10:09Describe the window management code and the utility of its state-based, bidirectional state-synchronisation approach, as opposed to a function-based API
📖
10:09Describe the window management code and the utility of its state-based, bidirectional state-synchronisation approach, as opposed to a function-based API
📖
17:31Demo the audio
🏃
17:31Demo the audio
🏃
17:31Demo the audio
🏃
18:45Describe the audio code, with a few words on audio synthesis
📖
18:45Describe the audio code, with a few words on audio synthesis
📖
18:45Describe the audio code, with a few words on audio synthesis
📖
24:48Demo the synthesisers
🏃
24:48Demo the synthesisers
🏃
24:48Demo the synthesisers
🏃
29:15Describe state-based style code
🗩
29:15Describe state-based style code
🗩
29:15Describe state-based style code
🗩
31:45Q&A
🗩
31:45Q&A
🗩
31:45Q&A
🗩
32:22nothings2 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.)
🗪
32:22nothings2 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.)
🗪
32:22nothings2 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.)
🗪
34:44nxsy Why is synced_title a char[MAX_TITLE] while title is char const*?
🗪
34:44nxsy Why is synced_title a char[MAX_TITLE] while title is char const*?
🗪
34:44nxsy Why is synced_title a char[MAX_TITLE] while title is char const*?
🗪
36:12synchronizerman 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?
🗪
36:12synchronizerman 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?
🗪
36:12synchronizerman 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:54Dynamic type info: Unique type identifiers with typeof
🗩
37:54Dynamic type info: Unique type identifiers with typeof
🗩
37:54Dynamic type info: Unique type identifiers with typeof
🗩
44:24Dynamic type info: Runtime type info
🗩
44:24Dynamic type info: Runtime type info
🗩
44:24Dynamic type info: Runtime type info
🗩
48:55Implement parsing for type info, including test_typeof()
48:55Implement parsing for type info, including test_typeof()
48:55Implement parsing for type info, including test_typeof()
52:41Enable resolve_expected_expr() to handle EXPR_TYPEOF_TYPE and EXPR_TYPEOF_EXPR, augmenting the Type struct with a typeid
52:41Enable resolve_expected_expr() to handle EXPR_TYPEOF_TYPE and EXPR_TYPEOF_EXPR, augmenting the Type struct with a typeid
52:41Enable resolve_expected_expr() to handle EXPR_TYPEOF_TYPE and EXPR_TYPEOF_EXPR, augmenting the Type struct with a typeid
1:02:43Run it, hit an assert in the generator, and note the reason for assert(0)
🏃
1:02:43Run it, hit an assert in the generator, and note the reason for assert(0)
🏃
1:02:43Run it, hit an assert in the generator, and note the reason for assert(0)
🏃
1:03:32Enable gen_expr() to handle EXPR_TYPEOF_EXPR and EXPR_TYPEOF_TYPE, with a few words on the benefit of the hash table approach
1:03:32Enable gen_expr() to handle EXPR_TYPEOF_EXPR and EXPR_TYPEOF_TYPE, with a few words on the benefit of the hash table approach
1:03:32Enable gen_expr() to handle EXPR_TYPEOF_EXPR and EXPR_TYPEOF_TYPE, with a few words on the benefit of the hash table approach
1:08:41Run it and take a look at our generated C code
🏃
1:08:41Run it and take a look at our generated C code
🏃
1:08:41Run it and take a look at our generated C code
🏃
1:09:37Introduce Any struct, a typeid typedef and print_any()
1:09:37Introduce Any struct, a typeid typedef and print_any()
1:09:37Introduce Any struct, a typeid typedef and print_any()
1:13:19Run 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
🏃
1:13:19Run 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
🏃
1:13:19Run 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
🏃
1:14:37Q&A
🗩
1:14:37Q&A
🗩
1:14:37Q&A
🗩
1:15:08A few words on the future of handling runtime type info using a typeinfo_table
🗩
1:15:08A few words on the future of handling runtime type info using a typeinfo_table
🗩
1:15:08A few words on the future of handling runtime type info using a typeinfo_table
🗩
1:16:48xanatos387 Would typeinfo exist for any Ion-visible type, or would there be situations where even Ion-declared types might not have typeinfo?
🗪
1:16:48xanatos387 Would typeinfo exist for any Ion-visible type, or would there be situations where even Ion-declared types might not have typeinfo?
🗪
1:16:48xanatos387 Would typeinfo exist for any Ion-visible type, or would there be situations where even Ion-declared types might not have typeinfo?
🗪
1:18:03nothings2 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)
🗪
1:18:03nothings2 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)
🗪
1:18:03nothings2 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)
🗪
1:19:44nothings2 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
🗪
1:19:44nothings2 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
🗪
1:19:44nothings2 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
🗪
1:20:39nothings2 Yeah, fair. (Especially for something targeting embedded)
🗪
1:20:39nothings2 Yeah, fair. (Especially for something targeting embedded)
🗪
1:20:39nothings2 Yeah, fair. (Especially for something targeting embedded)
🗪
1:21:44Cut the stream over to the extra stream
🗩
1:21:44Cut the stream over to the extra stream
🗩
1:21:44Cut the stream over to the extra stream
🗩