Annotate bitwise014
This commit is contained in:
parent
942acbebd8
commit
c29e103e51
|
@ -0,0 +1,60 @@
|
||||||
|
[video member=pervognsen stream_platform=twitch project=bitwise title="Types Revisited" vod_platform=youtube id=Dq2gKTdL1uI annotator=Miblo]
|
||||||
|
[0:09][Recap and set the stage for the day, with a few words on homework assigning][:speech]
|
||||||
|
[2:34][Review the off-stream work on #line directive generation in terms of forward-declarations, and general cleanliness][:"code generation" :research]
|
||||||
|
[8:07][Review the fix in the C :"code generation" of Ion's implicitly sized arrays][:language :research]
|
||||||
|
[10:08][Review the introduction of Ion's switch case comma-notation][:"code generation" :language :research]
|
||||||
|
[10:51][Review Ion's compound initialising with casting][:"code generation" :language :research]
|
||||||
|
[13:24][Demo breaking into and stepping through Ion code and :asm, with a note on the utility of our use of the #line directive thanks to Ion's similarity to C][:language :run]
|
||||||
|
[18:48][Demo :profiling Ion code][:run]
|
||||||
|
[22:07][Q&A][:speech]
|
||||||
|
[22:52][@synchronizerman][Then what does \[#line\] actually do?]
|
||||||
|
[26:08][@captainkraft][@pervognsen I know that Nim has issues with debugging tools. They also compile down to C. Any idea why they can't take advantage of current tools like Ion does?][:language]
|
||||||
|
[29:04][Set up to fill in the rest of the type system][:"code generation" :language :parsing :speech]
|
||||||
|
[31:44][Point out where to find the C11 standard[ref
|
||||||
|
author=ANSI
|
||||||
|
title="ISO/IEC 9899:201x: Information technology – Programming languages – C"
|
||||||
|
url=http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf]][:language :research]
|
||||||
|
[32:53][A few words on learning C via DikuMUD[ref
|
||||||
|
site=GitHub
|
||||||
|
page="sneezymud / dikumud"
|
||||||
|
url=https://github.com/sneezymud/dikumud] and K&R[ref
|
||||||
|
author="Brian Kernighan and Dennis Ritchie"
|
||||||
|
title="The C Programming Language"
|
||||||
|
url=https://archive.org/details/TheCProgrammingLanguageFirstEdition]][:language :speech]
|
||||||
|
[35:28][Integer promotions[ref
|
||||||
|
author=ANSI
|
||||||
|
title="ISO/IEC 9899: Information technology – Programming languages – C"
|
||||||
|
url=http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf]][:language :speech]
|
||||||
|
[1:00:42][Usual arithmetic conversions[ref
|
||||||
|
author=ANSI
|
||||||
|
title="ISO/IEC 9899: Information technology – Programming languages – C"
|
||||||
|
url=http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf]][:language :speech]
|
||||||
|
[1:11:38][Seek advice on triggering the final operand promotion case under 6.3.1.8 Usual arithmetic conversions[ref
|
||||||
|
author=ANSI
|
||||||
|
title="ISO/IEC 9899: Information technology – Programming languages – C"
|
||||||
|
url=http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf]][:language :speech]
|
||||||
|
[1:13:01][Augment our TypeKind struct with all, except long double, of C's builtin types][:language :parsing]
|
||||||
|
[1:16:38][Introduce promote_operand(), Val union and operand_const(), and enable the resolver to handle our new type representation][:language :parsing]
|
||||||
|
[1:26:57][@thebuzzsaw][Is there a public repo for what he's working on?[ref
|
||||||
|
site=GitHub
|
||||||
|
page="pervognsen / bitwise"
|
||||||
|
url=https://github.com/pervognsen/bitwise]]
|
||||||
|
[1:27:12][Continue to enable the resolver to handle our new type representation, and to perform operand promotion][:language :parsing]
|
||||||
|
[1:38:31][:Run it and hit an assert somewhere][:language :parsing]
|
||||||
|
[1:39:02][Make resolve_typespec call fatal_error() emitting the line position in the TYPESPEC_ARRAY case][:"error handling"]
|
||||||
|
[1:39:45][:Run it to see that the assert fires on line 1][:language :parsing]
|
||||||
|
[1:39:59][Temporarily change sizeof to use type int][:language]
|
||||||
|
[1:40:13][:Run it to find that it actually works][:language :parsing]
|
||||||
|
[1:40:30][Q&A][:speech]
|
||||||
|
[1:40:48][@ws_ubi][I would like to understand why from :language syntax design not everything is like LISP and then you write macros on top of the language if you want to create a "nicer syntax" but the core is simpler, no?[ref
|
||||||
|
author="John McCarthy"
|
||||||
|
title="Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I"
|
||||||
|
url=http://www-formal.stanford.edu/jmc/recursive.pdf][ref
|
||||||
|
site=Wikipedia
|
||||||
|
page="Dylan (programming language)"
|
||||||
|
url=https://en.wikipedia.org/wiki/Dylan_(programming_language)]]
|
||||||
|
[1:44:30][@sergej_reich][@pervognsen At least on 64-bit Linux: sizeof(long) == 8. I think that's true for most other Unix-like systems]
|
||||||
|
[1:45:54][@dahlajn][Is the plan to port over the compiler itself to Ion once it can bootstrap itself?][:"code generation" :language]
|
||||||
|
[1:47:17][@jprzemieniecki][@pervognsen What is the reason to have the long type in Ion anyway?][:language]
|
||||||
|
[1:48:56][Stop recording][:speech]
|
||||||
|
[/video]
|
|
@ -0,0 +1,3 @@
|
||||||
|
[video member=pervognsen stream_platform=twitch project=bitwise title="Types Revisited (Extra)" vod_platform=youtube id=amSiLEFcjq4 annotator=Miblo]
|
||||||
|
[0:00][\[Entire stream, not annotated\]][:"code generation" :language :parsing]
|
||||||
|
[/video]
|
Loading…
Reference in New Issue