Merge pull request #156 from QuillPusher/Add_Blogs_Page_And_Nav

Adding Blog Functionality and New Blog Posts

_layouts/blog.html

@@ -0,0 +1,15 @@
+---
+layout: default
+title: Blog
+---
+<h3>Latest Posts</h3>
+
+<div>
+  {% for post in site.posts %}
+    <div class="well">
+      <h3>{{ post.title }}</h3>
+      {{ post.excerpt }}
+      <p>Read more <a href="{{ post.url }}">here</a></p>
+    </div>
+  {% endfor %}
+  </div>

_pages/blog.md

@@ -0,0 +1,13 @@
+---
+title: "Blog"
+layout: blog
+excerpt: "Blog Posts"
+sitemap: false
+permalink: /blog/
+---
+
+<div id="textid" class="col-sm-12">
+  {{ content }}
+</div>
+
+

_pages/blogs/GSoC22_M_Izvekov_Project_Experience.md → _posts/2022-11-30-extend-clang-to-resugar-template-specialization-accesses.md

@@ -1,34 +1,23 @@
 ---
-title: "GSoC 2022 Experience of Matheus Izvekov"
-layout: gridlay
-excerpt: "GSoC 2022 Experience of Matheus Izvekov"
+title: "Extend Clang to Resugar Template Specialization Accesses"
+layout: post
+excerpt: "Clang is an LLVM native C/C++/Objective-C compiler, which aims to
+ deliver amazingly fast compiles, extremely useful error and warning messages
+  and to provide a platform for building great source level tools. The Clang
+   Static Analyzer and clang-tidy are tools that automatically find bugs in 
+   your code, and are great examples of the sort of tools that can be built 
+   using the Clang frontend as a library to parse C/C++ code. When 
+   instantiating a template, the template arguments are canonicalized 
+   before being substituted into the template pattern. Clang does not 
+   preserve type sugar when subsequently accessing members of the instantiation. 
+   This leads to many infamous pathological errors which have haunted C++ 
+   developers for decades."
 sitemap: false
 permalink: blogs/gsoc22_izvekov_experience_blog/
+date: 2022-11-30
 ---
 
-# Extend Clang to resugar template specialization accesses
-
-**Developer:** Matheus Izvekov
-
-**Mentors:** Richard Smith (Google), Vassil Vassilev (Princeton University/CERN)
-
-**Funding:** [Google Summer of Code 2022](https://summerofcode.withgoogle.com/)
-
----
-
-**Contact me!**
-
-Email: [email protected]
-
-Github Username: [mizvekov](https://github.com/mizvekov)
-
-**Link GSoC project proposal:** [Matheus_Izvekov_Proposal_2022](https://compiler-research.org/assets/docs/Matheus_Izvekov_Proposal_2022.pdf)
-
-
----
-
-
-## Overview of the Project
+### Overview of the Project
 
 Clang is an "LLVM native" C/C++/Objective-C compiler, which aims to deliver
 amazingly fast compiles, extremely useful error and warning messages and to
@@ -56,7 +45,7 @@ Clang has the
 [clang::preferred_name](https://clang.llvm.org/docs/AttributeReference.html#preferred-name)
 attribute to improve the situation but with limited success.
 
-## My approach
+### My approach
 
 To further enhance Clang’s expressive error diagnostics system, I implemented an
 eager approach to syntactic resugaring in Clang. The novel approach does not
@@ -72,7 +61,7 @@ approach, although more efficient, required some intrusive modifications on the
 way substitutions are represented in the AST.
 
 
-## Contributions
+### Contributions
 
 The main contributions to this project are listed here.
 
@@ -90,7 +79,7 @@ Pull Requests:
 8. [D127695 - Implement Template Specialization Resugaring](https://reviews.llvm.org/D127695)
 
 
-## Contributions
+### Contributions
 
 1. Syntactic resugar of Non Type Template Parameters (NTTPs) is still under
 development. When checking template arguments, we perform substitutions on NTTPs
@@ -110,8 +99,28 @@ terms of desugared code, improving the relationship between the user's source
 program and the program evaluation.
 
 
-## Acknowledgements
+### Acknowledgements
 
 I thank my mentors Richard Smith and Vassil Vasilev for their excellent
 support, their welcoming behavior motivated me and gave me the opportunity to
 increase my confidence as a developer in the LLVM open community!
+
+---
+
+### Credits
+
+**Developer:** Matheus Izvekov
+
+**Mentors:** Richard Smith (Google), Vassil Vassilev (Princeton University/CERN)
+
+**Funding:** [Google Summer of Code 2022](https://summerofcode.withgoogle.com/)
+
+---
+
+**Contact me!**
+
+Email: [email protected]
+
+Github Username: [mizvekov](https://github.com/mizvekov)
+
+**Link GSoC project proposal:** [Matheus_Izvekov_Proposal_2022](https://compiler-research.org/assets/docs/Matheus_Izvekov_Proposal_2022.pdf)

_pages/blogs/GSoC22_J_Zhang_P_Chaudhari_Experience.md → _posts/2022-12-02-recovering-from-errors-in-clang-repl-and-code-undo.md

@@ -1,35 +1,25 @@
 ---
-title: "Summer 2022 Experience of Jun Zhang and Purva Chaudhari"
-layout: gridlay
-excerpt: "Summer 2022 Experience of Jun Zhang and Purva Chaudhari"
+title: "Recovering from Errors in Clang-Repl and Code Undo"
+layout: post
+excerpt: "Incremental C++ enables exploratory programming by considering the 
+translation unit to be an ever-growing entity. This allows implementation of 
+interpreter-like tools such as Cling and Clang-Repl, which consume C++ code 
+piece by piece and use the JIT infrastructure to run each piecewise.  One of 
+the challenges of Incremental C++ is the reliable recovery from errors which 
+allows the session to continue after faulty user code. Supporting reliable 
+error recovery requires splitting the translation unit into a sequence of 
+Partial Translation Units (PTUs). Each declaration is associated with a 
+unique PTU that owns it. Owning PTU isn’t always the “active” (most recent) 
+PTU and it isn’t always the PTU that the declaration comes from. Even a new 
+declaration that isn’t a declaration or or specialization of anything 
+belongs to the active PTU. However, in case of a template specialization, 
+it can be pulled into a more recent PTU by its template arguments."
 sitemap: false
 permalink: blogs/gsoc22_zhang_chaudhari_experience_blog/
+date: 2022-12-02
 ---
 
-# Recovering from Errors in Clang-Repl and Code Undo
-
-**Developers:** Jun Zhang (Software Engineering, Anhui Normal University, WuHu,
-  China) and Purva Chaudhari (California State University Northridge, Northridge
-  CA, USA)
-
-**Mentor:** Vassil Vassilev (Princeton University/CERN)
-
----
-
-**Contact us!**
-
-Jun: [email protected]
-
-GitHub username: [junaire](https://github.com/junaire)
-
-
-Purva: [Webpage](https://purva-chaudhari.github.io/My-Portfolio/)
-
-GitHub username: [Purva-Chaudhari](https://github.com/Purva-Chaudhari)
-
----
-
-## Overview of the Project
+### Overview of the Project
 
 Incremental C++ enables exploratory programming by considering the translation
 unit to be an ever-growing entity. This allows implementation of
@@ -82,7 +72,7 @@ clang-repl> float x = 24 // not an error
 ```
 
 
-## Contributions
+### Contributions
 
 The main contributions to this project are listed here.
 
@@ -102,7 +92,7 @@ Pull Requests:
 11. [D130831 - Track DeferredDecls that have been emitted](https://reviews.llvm.org/D130831)
 12. [Code gen passing](https://gist.github.com/Purva-Chaudhari/1555b887618cec569b638e96056d9679)
 
-## Results
+### Results
 
 1. We implemented the initial code undo for Clang-Repl, the patch we submitted
 extends the functionality used to recover from errors and adds functionality to
@@ -133,11 +123,34 @@ auto r4 = printf("bar() = %d\n", bar()); // This fails before my patch. Note thi
 ```
 5. We fixed some issues in lambda usage in Clang-Repl.
 
-## Conclusion
+### Conclusion
 
 During this summer, I not only improved my technical skills but also enhanced my ability to work with others and
 appreciate the charm of open source. I would like to thank all the people who helped me, especially my mentor Vassil,
 who is not only an experienced programmer but also a respected life teacher. I'm also pretty happy working with my
 partner Purva, who made a great effort when preparing our LLVM Dev lightning talk this year.
 
 In the future, I'll continue my journey into the world of open source, and bring the code and love to all!
+
+---
+
+### Credits
+
+**Developers:** Jun Zhang (Software Engineering, Anhui Normal University, WuHu,
+  China) and Purva Chaudhari (California State University Northridge, Northridge
+  CA, USA)
+
+**Mentor:** Vassil Vassilev (Princeton University/CERN)
+
+---
+
+**Contact us!**
+
+Jun: [email protected]
+
+GitHub username: [junaire](https://github.com/junaire)
+
+
+Purva: [Webpage](https://purva-chaudhari.github.io/My-Portfolio/)
+
+GitHub username: [Purva-Chaudhari](https://github.com/Purva-Chaudhari)

_pages/blogs/GSoC22_A_Ghosh_Project_Experience.md → _posts/2022-12-07-shared-memory-based-jitlink-memory-manager.md

@@ -1,37 +1,21 @@
 ---
-title: "GSoC 2022 Experience of Anubhab Ghosh"
-layout: gridlay
-excerpt: "GSoC 2022 Experience of Anubhab Ghosh"
+title: "Shared Memory Based JITLink Memory Manager"
+layout: post
+excerpt: "LLVM JIT APIs include JITLink, a just-in-time linker that links 
+together objects code units directly in memory and executes them. It uses the
+JITLinkMemoryManager interface to allocate and manage memory for the generated
+code. When the generated code is run in the same process as the linker, memory
+is directly allocated using OS APIs. But for code that runs in a separate
+executor process, an RPC scheme Executor Process Control (EPC) is used. The
+controller process invokes RPCs in the target or executor process to allocate
+memory and then when the code is generated, all the section contents are
+transferred through finalize calls."
 sitemap: false
 permalink: blogs/gsoc22_ghosh_experience_blog/
+date: 2022-12-07
 ---
 
-# Shared Memory Based JITLink Memory Manager
-
-**Developer:** Anubhab Ghosh (Computer Science and Engineering, Indian Institute
-  of Information Technology, Kalyani, India)
-
-**Mentors:** Stefan Gränitz (Freelance Compiler Developer, Berlin, Deutschland),
-  Lang Hames (Apple), Vassil Vassilev (Princeton University/CERN)
-
-**Funding:** [Google Summer of Code 2022](https://summerofcode.withgoogle.com/)
-
----
-
-**Contact me!**
-
-Email: [email protected]
-
-Github Username: [argentite](https://github.com/argentite)
-
-**Link to GSoC project proposal:** [Anubhab_Ghosh_Proposal_GSoC_2022](https://compiler-research.org/assets/docs/Anubhab_Ghosh_Proposal_2022.pdf)
-
-**Link to GSoC project proposal:** [Anubhab_Ghosh_Final_Report_GSoC_2022](https://compiler-research.org/assets/docs/Anubhab_Ghosh_GSoC2022_Report.pdf)
-
----
-
-
-## Overview of the Project
+### Overview of the Project
 LLVM JIT APIs include JITLink, a just-in-time linker that links together objects
 code units directly in memory and executes them. It uses the
 JITLinkMemoryManager interface to allocate and manage memory for the generated
@@ -42,14 +26,14 @@ controller process invokes RPCs in the target or executor process to allocate
 memory and then when the code is generated, all the section contents are
 transferred through finalize calls.
 
-### Shared Memory
+#### Shared Memory
 The main problem was that EPC runs on top of file descriptor streams like Unix
 pipes or TCP sockets. As all the generated code and data bytes are transferred
 over the EPC this has some overhead that could be avoided by using shared
 memory. If the two processes share the same physical memory pages then we can
 completely avoid extra memory copying.
 
-### Small code model
+#### Small code model
 While we are at it, another goal was to introduce a simple slab-based memory
 manager. It would allocate a large chunk of memory in the beginning from the
 executor process and allocate smaller blocks from that entirely at the
@@ -97,9 +81,9 @@ Small code model is the default for most compilations so this is actually
 required to load ordinary precompiled code, e.g., from existing static archives.
 
 
-## My Approach
+### My Approach
 
-### Memory Mappers
+#### Memory Mappers
 I introduced a new `MemoryMapper` abstraction for interacting with OS APIs at
 different situations. It has separate implementations based on whether the code
 will be executed in the same or different process. The `InProcessMemoryMapper`
@@ -116,7 +100,7 @@ address. Once JITLink has written the code to those mapped addresses, they are
 now already in place in the executor processes so finalization is just a matter
 of sending the memory protections.
 
-### Slab-based allocator
+#### Slab-based allocator
 Furthermore, I developed a slab-based memory allocator for JITLink, reserving a
 large region of memory in the address space of the target process on the first
 allocation. All subsequent allocations result in sub-regions of that to be
@@ -125,7 +109,7 @@ involvement. Furthermore as our all the allocation are from a contiguous memory
 region, it also guarantees that JIT’d memory satisfies the layout constraints
 required by the small code model.
 
-### Concurrency problems
+#### Concurrency problems
 After the implmentation, I tried JIT linking the CPython interpreter to
 benchmark the implementation. We discovered that our overall CPU execution time
 decreased by 45% but somewhat paradoxically clock time increased by 45%. In
@@ -149,9 +133,33 @@ For a more detailed description and all the patches, please consult my
 [GSoC final report](https://compiler-research.org/assets/docs/Anubhab_Ghosh_GSoC2022_Report.pdf).
 
 
-## Acknowledgements
+### Acknowledgements
 
 I would like to share my gratitude for the LLVM community members and my mentors
 Stefan Gränitz, Lang Hames, and Vassil Vassilev, who shared their suggestions
 during the project development. I hope that this project will find its place in
 many applications.
+
+---
+
+### Credits
+
+**Developer:** Anubhab Ghosh (Computer Science and Engineering, Indian Institute
+  of Information Technology, Kalyani, India)
+
+**Mentors:** Stefan Gränitz (Freelance Compiler Developer, Berlin, Deutschland),
+  Lang Hames (Apple), Vassil Vassilev (Princeton University/CERN)
+
+**Funding:** [Google Summer of Code 2022](https://summerofcode.withgoogle.com/)
+
+---
+
+**Contact me!**
+
+Email: [email protected]
+
+Github Username: [argentite](https://github.com/argentite)
+
+**Link to GSoC project proposal:** [Anubhab_Ghosh_Proposal_GSoC_2022](https://compiler-research.org/assets/docs/Anubhab_Ghosh_Proposal_2022.pdf)
+
+**Link to GSoC project proposal:** [Anubhab_Ghosh_Final_Report_GSoC_2022](https://compiler-research.org/assets/docs/Anubhab_Ghosh_GSoC2022_Report.pdf)