Merge branch 'master' into jiufong

students/gok99/knowledge.md

@@ -1,3 +1,21 @@
+## CS3282
+
+In general, the theme of my explorations and work in CS3282 revolves around ideas in programming language research and functional programming, which are all things I'd like to pursue in the future. The lightning talks exposed me to new ideas in programming languages (some described below). The book review assignment gave me the valuable counter-opinion that formal methods and newer fancy-type systems might actually limit the flexibility of real-world software. Java, which is very much an unfancy language, is certainly very practical and doesn't have support for many of these techniques. Regardless, we can borrow ideas like immutability and apply them to any practical system. To that effect, I've also tried to start refactors of the RepoSense backend to introduce principles like immutability and optional monads to make things easier to maintain and reason about.
+
+Overall, I really appreciated the flexibility afforded by CS3282, which allowed me to explore more fringe and niche ideas that are starting to make their way into the programming practitioner's toolkit.
+
+### Functional logic programming
+
+In my explorations for the first lightning talk, I also came across functional logic programming. I had previously been separately familiar with functional and logic programming, and it was nice to see a foundational work for a core calculus for the combination of these paradigms, each of which has rich literature. The [Verse Calculus](https://simon.peytonjones.org/assets/pdfs/verse-conf.pdf) provides a minimal language that can be evaluated with a consistent set of rewrite rules that have a number of nice properties. This work comes out of Epic Games by researchers like Simon Peyton Jones, Lennart Augustsson, Guy Steele, and Ranjit Jhala, all people I've heard of before relating to other highly influential work.
+
+### Effect systems
+
+Research for my second lightning talk got me interested in and learning about effect systems. Effect systems refer to systems that track and allow reasoning about unobvious side effects that functions and routines could have, like mutation, divergence (possible nontermination), network access, exceptions, etc. I found several real-world (used in practice) examples of effect systems like Scala Zio, Effect-TS (inspired heavily by Zio), and algebraic effects in OCaml (which very recently got significant syntactical updates in OCaml 5.3). The theory for algebraic effect systems is very rich and shows that effect systems are at least as expressive as monadic effects, which are widely adopted in pure functional programming languages like Haskell.
+
+---
+
+## CS3281
+
 ### Gradle
 
 Gradle is a very flexible build automation tool used for everything from testing and formatting, to builds and deployments. Unlike with other build automation tools like Maven where build scripts written in XML (a widely hated feature of the tool), Gradle build scripts are written in a domain specific language based on Groovy or Kotlin, which are both JVM based languages. This means that it can interact seamlessly with Java libraries.

students/gok99/observations.md

@@ -1,11 +1,31 @@
 ### Project: Pandoc
 
-Pandoc is a Haskell library and command-line tool for converting between various document formats. It is a powerful tool that can convert between many different formats, including Markdown, LaTeX, HTML, and many others. It is also extensible, allowing for the creation of custom readers and writers for new formats. Pandoc has 31.8k stars on GitHub and is used by many people and organizations for its powerful and flexible document conversion capabilities.
+Pandoc is a Haskell library and command-line tool for converting between various document formats. It is a powerful tool that can convert between many different formats, including Markdown, LaTeX, HTML, and many others. It is also extensible, allowing for the creation of custom readers and writers for new formats. Pandoc has 31.8k stars on GitHub and is used widely by individuals for personal workflows and within deployment pipelines by larger organizations.
 
 ### My Contributions
 
-- Fixed an issue involving Pandoc's Texinfo Writer: [PR #9359](https://github.com/jgm/pandoc/pull/9359)
+- Fixed an issue involving Pandoc's Texinfo Writer: [Add @var support in Texinfo Writer #8534](https://github.com/jgm/pandoc/pull/9359) (merged)
+- Fixed an issue involving Pandoc's RST Reader: [RST reader: fix figclass and align annotations for figures](https://github.com/jgm/pandoc/pull/9744) (merged)
 
 ### My Learning Record
 
-The Haskell tooling ecosystem (GHC, Cabal, Stack, Haskell LSP) makes writing Haskell quite enjoyable. In particular, Haskell's type inferencing and parametric polymorphism makes it easy to understand and modify code in a general and well-abstracted way. The language also allows for strong editor tooling that also helps make development a smooth experience.
+The Haskell tooling ecosystem (GHC, Cabal, Stack, Haskell LSP, etc) makes writing Haskell quite enjoyable. In particular, Haskell features like abstract data types, parametric polymorphism, and type inferencing make understanding and modifying code in a general and well-abstracted way really easy to do. The language also allows for strong editor tooling that also helps improve the developer experience. Contributing to Pandoc allowed me to get a deep look at practical Haskell in a widely adopted and loved tool—something I've always wanted to do.
+
+Pandoc is also a really great and flexible tool that has taught me a great deal about software design practices. Pandoc has lofty goals of providing good document conversion from a large number of input formats to a really large number of output formats. This is done by converting to and from Pandoc's own document intermediate representation, which has a large subset of the intersection of features of the input and output formats. By being very clear about the extent and specification of the intermediate representation, it is easy for several developers to concurrently add, modify, and fix existing readers and writers by mapping the semantics of the source or target specification to those of the Pandoc intermediate representation. In general, being very clear and thorough with interfaces between software segments seems to be an important and crucial aspect of any sufficiently sophisticated system. To a first approximation, Pandoc does a really good job of picking good defaults for the output format; if users want additional customizability, they can have that by writing their own custom Lua filters.
+
+#### Observations from contribution process
+
+Great practices:
+- The maintainer, John MacFarlane (a philosophy professor at Berkeley), and other core maintainers are incredibly active. Both my PRs got attention within a day. The first PR was merged in under a day, and the second PR was merged in under an hour! Fast and active review provides contributors with quick feedback and, personally, was a very strong motivator for making more contributions. I definitely see myself tackling deeper issues over the summer.
+- Great user documentation: The user documentation is really thorough and covers just about everything a user might need to get started and to get going with advanced features like Lua filters.
+- `good first issue` tags are a great entry point to the codebase. They cover issues that can be tackled without a very deep understanding of the codebase, but that still familiarize the contributor with the workflow of dealing with an issue and adding tests.
+
+Possible improvements:
+- Since not as many people contribute to Pandoc (likely due to the Haskell learning curve) outside of the core team compared to other large open source projects, there has not been much of a need for PR workflow automation. While CI's are run, more checks could be conducted with bots and other tools provided by Github actions to automate more of the review process (as is quite common with most big open source projects).
+- I found developer documentation to be a little lacking (again likely due to the small number of contributors). It would have been nice to see details of things like editor set-up with the Haskell LSP, build instructions for particular pandoc applications, and a more detailed look at the codebase architecture.
+
+#### Suggestions for the internal project based on external project observations
+
+- I think the biggest takeaway personally was the importance of active maintenance and support. A community is only as active as its maintainers, and knowing that work will be promptly reviewed is crucial for the life and longevity of the community. This is definitely something we can improve on with RepoSense. It is, however, certainly a challenge with nus-oss, given that students come and go fairly frequently and attention has to contend with school work and other activities.
+- Experience with Pandoc and Haskell has convinced me that advanced-type systems and function style programming help programmers write safer and more resilient software. Unfortunately, Java's type system (even with newer versions) is not nearly as powerful as Haskell's and limits how far we can take these ideas. Nevertheless, we can make some progress with making Reposense easier to reason about with refactors involving [immutability and optional monads](https://github.com/reposense/RepoSense/pull/2144).
+

students/gok99/progress.md

@@ -31,3 +31,13 @@
 | 7 | Reviewed PR: [Improve performance #2108](https://github.com/reposense/RepoSense/pull/2108) |
 | 7 | Reviewed PR: [Add originality threshold flag #2122](https://github.com/reposense/RepoSense/pull/2122) |
 | 7 | Reviewed PR: [Resolve Merge Conflict #2139](https://github.com/reposense/RepoSense/pull/2139) |
+| 9 | Reviewed PR: [[#2141] Use optionals for return values that may be null to enforce a client check](https://github.com/reposense/RepoSense/pull/2144) |
+| 9 | Reviewed PR: [[#2164] Revert "[#2109] Add search by tag functionality"](https://github.com/reposense/RepoSense/pull/2165) |
+| 10 | Reviewed PR: [[#944] Implement authorship analysis](https://github.com/reposense/RepoSense/pull/2140) |
+| 10 | Reviewed PR: [Add more testcases](https://github.com/reposense/testrepo-Alpha/pull/21) |
+| R | Reviewied PR: [[#2177] Migrate to Java 11 Syntax and Features](https://github.com/reposense/RepoSense/pull/2183) |
+| R | Reviewed PR: [[#2170] Add Blurbs for Repos](https://github.com/reposense/RepoSense/pull/2191) |
+| R | Reviewed PR: [[#2161] One-Stop Config File for Code Portfolio](https://github.com/reposense/RepoSense/pull/2192) |
+| R | Contributed to discussion in: [Surge preview deployments for many of our latest PRs are not working](https://github.com/reposense/RepoSense/issues/2194) |
+| R | Opened Issue: [Use GitBlameLineInfo for processing git blame output in aggregateBlameAuthorModifiedAndDateInfo](https://github.com/reposense/RepoSense/issues/2196) |
+| R | Contributed to discussion in: [Simplify Config File Creation and Project Scaffolding Process](https://github.com/reposense/RepoSense/issues/2199) | 

students/sopa301/progress.md

@@ -1,6 +1,7 @@
 # Progress
 ## Summary
 - Added new Title component and documentation
+- Replace Vue CLI build tool with Vite
 - Updated frontend dependencies
 - Refactored frontend code
 - Added style rules
@@ -26,6 +27,7 @@
 | Reading | [#2184] Fix Inconsistent Line Number Colours |
 | Reading | [#2151] Update Typescript-related Major Dependencies | 
 | Reading | [#2001] Extract c-file-type-checkboxes from Summary, Authorship and Zoom |
+| Reading | [#2176] Move from Vue CLI to Vite |
 
 | Week | PRs Reviewed |
 | --- | --- |
@@ -65,4 +67,5 @@
 | 10 | Add Blurbs for Repos |
 | 10 | Enforce No Spacing Between Methods in Vue Files |
 | 10 | Replace Vue CLI with Vite |
+| Reading | Refactor c-title to use c-markdown-chunk |