From c29e103e514991874bca8a76de82e937dc6f5b96 Mon Sep 17 00:00:00 2001 From: Matt Mascarenhas Date: Wed, 11 Apr 2018 20:20:42 +0100 Subject: [PATCH] Annotate bitwise014 --- pervognsen/bitwise/bitwise/bitwise014_1.hmml | 60 ++++++++++++++++++++ pervognsen/bitwise/bitwise/bitwise014_2.hmml | 3 + 2 files changed, 63 insertions(+) create mode 100644 pervognsen/bitwise/bitwise/bitwise014_1.hmml create mode 100644 pervognsen/bitwise/bitwise/bitwise014_2.hmml diff --git a/pervognsen/bitwise/bitwise/bitwise014_1.hmml b/pervognsen/bitwise/bitwise/bitwise014_1.hmml new file mode 100644 index 0000000..bc057b6 --- /dev/null +++ b/pervognsen/bitwise/bitwise/bitwise014_1.hmml @@ -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] diff --git a/pervognsen/bitwise/bitwise/bitwise014_2.hmml b/pervognsen/bitwise/bitwise/bitwise014_2.hmml new file mode 100644 index 0000000..a0c6e83 --- /dev/null +++ b/pervognsen/bitwise/bitwise/bitwise014_2.hmml @@ -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]