Jump to Content
Register Log in

Bitwise
Blog
Forums
Episode Guide
twitter
We are currently in the process of converting the website to the new design. Some pages, like this one, are still broken. We appreciate your patience.
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
🗩