├── .gitignore ├── 2024_NewBeginnings ├── final-reports │ ├── README.md │ ├── pr05_2024_Final_report_DoraDo.md │ ├── pr05_2024_final_report_Claudine_Chen.md │ ├── pr05_2024_final_report_Diya_Solanki.md │ └── pr05_2024_final_report_Miaoye_Que.md └── monthly-reports │ ├── README.md │ ├── pr05_2024_August_report_Claudine_Chen.md │ ├── pr05_2024_August_report_Diya_Solanki.md │ ├── pr05_2024_August_report_Dora_Do.md │ ├── pr05_2024_August_report_Miaoye_Que.md │ ├── pr05_2024_August_report_Nahee_Kim.md │ ├── pr05_2024_July_report_Claudine_Chen.md │ ├── pr05_2024_July_report_Diya_Solanki.md │ ├── pr05_2024_July_report_Dora_Do.md │ ├── pr05_2024_July_report_Miaoye_Que.md │ ├── pr05_2024_July_report_Nahee_Kim.md │ ├── pr05_2024_September_report_Claudine_Chen.md │ ├── pr05_2024_September_report_Diya_Solanki.md │ ├── pr05_2024_September_report_Dora_Do.md │ ├── pr05_2024_September_report_Miaoye_Que.md │ └── pr05_2024_September_report_Nahee_Kim.md ├── CODE_OF_CONDUCT.md └── README.md /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store -------------------------------------------------------------------------------- /2024_NewBeginnings/final-reports/README.md: -------------------------------------------------------------------------------- 1 | # Final Reports 2 | 3 | This directory contains comprehensive final reports from the 2024 pr05 cohort projects, documenting the project journey, covering technical decisions, challenges, tasks completed, limitations, and future steps. 4 | 5 | ## Naming Files 6 | 7 | Please use the following naming convention: 8 | 9 | `pr05__final_report__.md`. 10 | 11 | For example, if your name is Katherine Johnson, the file should be called: 12 | 13 | `pr05_2024_final_report_Katherine_Johnson.md` 14 | 15 | ## Report Structure 16 | 17 | Reports should cover the project as a whole, including but not limited to: 18 | 19 | - **Technical decisions** — Key choices made and alternative options considered. 20 | - **Challenges** — Difficulties encountered and how they were addressed. 21 | - **Tasks completed** — Summary of major accomplishments. 22 | - **Limitations** — Constraints or limitations of the current project. 23 | - **Work remaining and next steps** — Suggested future improvements. 24 | - **Relevant commits/PRs** — Links to key commits or pull requests. 25 | 26 | For personal reflections and broader project insights, see our wrap-up posts on [Medium](https://medium.com/processing-foundation). 27 | -------------------------------------------------------------------------------- /2024_NewBeginnings/final-reports/pr05_2024_Final_report_DoraDo.md: -------------------------------------------------------------------------------- 1 | # Prototype a Collaborative Editor for Processing - Final Report 2 | ## Technical Decisions 3 | Throughout this project, several technical choices were crucial in achieving a stable, cross-platform application. Here are the primary decisions: 4 | 5 | - UI Design & Development: 6 | - React & Zustand: React was chosen for its component-based architecture and Zustand for state management. This combination provided a scalable and maintainable structure for the UI. 7 | - Radix UI Component Library: Integrated Radix UI components to enhance the app's visual design and user experience. This library provided a consistent design system for future contributors and improved the overall UI. 8 | - Codemirror: Originally, we considered Theia, but opted for CodeMirror due to its ease of implementation, extensive use in the p5 Web Editor, existing collaborative features, and faster development potential. This choice was validated by the successful integration of CodeMirror with Electron. 9 | 10 | - Real-time Collaboration: 11 | - CodeMirror & YJS Integration: We successfully integrated the YJS framework with the CodeMirror editor to enable real-time collaboration. This integration was essential for the core functionality of the app and laid the foundation for collaborative editing. We used the `y-codemirror.next` package with the `y-websocket` provider for real-time synchronization of CodeMirror documents. 12 | - Websockets: We used `y-websocket` for the WebSocket provider to enable real-time collaboration. This choice was made after evaluating WebRTC's limitations in handling larger groups effectively due to performance issues. We decided that Websockets were more stable for our use case and provided better support for scaling. Currently, the server is hosted on a cloud service called Render on their free-tier plan, which puts the server to sleep after a period of inactivity. The repository to the server can be found [here](https://github.com/doradocodes/pce-server). When a user hosts a collaborative session, a room is created on the server with a unique ID (the Room ID). This ID is then shared to the other users who want to join the session. Since the implementation was a bit crude for this prototype, rooms are not deleted after the session ends. But if a user drops from a session, they can still rejoin the session using the same Room ID, even if the host disconnects. 13 | 14 | - Running Processing Sketches: 15 | - Integrating Processing sketches was foundational to the app’s core functionality. In this prototype, sketches are saved locally as `.pde` files and Electron runs the `processing-java` executable to execute Processing sketches with a path to the file. It is not the most efficient method of running sketches, but it allowed us to demonstrate the collaborative editing of Processing code. Future iterations will include a headless version of Processing for more efficient sketch execution. 16 | 17 | - App Build and Distribution: 18 | - We initially tested app distribution using electron-builder, but challenges in handling Apple’s certificate verification led to adopting electron-forge, which streamlined the macOS notarization process. electron-forge provided more reliable handling for platform-specific requirements, making it easier to sign and notarize the app for Mac and set up for Windows. There was also an issue with notarizing the Processing library, which was resolved by creating a script called `sign_jnilib_files.js` to sign the library for notarization. 19 | - In order for others to build the app, contributors can use the provided `.env.example` file to set up their environment variables. 20 | 21 | 22 | ## Tasks Completed 23 | - Created a functional prototype of a collaborative code editor for Processing using Electron and CodeMirror. 24 | - Allow creation, editing, renaming, deleting, and running of local Processing sketches. 25 | - Integrated YJS with CodeMirror for real-time collaboration, enabling multiple users to edit a Processing sketch simultaneously. 26 | - Allows user selection of dark or light mode for the editor. 27 | - Builds for macOS and Windows. 28 | 29 | 30 | ## Challenges 31 | - Certificate and Notarization Issues: Encountering "damaged app" errors when testing macOS builds on other machines highlighted the need for proper app signing. After troubleshooting with Apple Developer tools and certificates, switching to electron-forge resolved this issue. 32 | 33 | - Cross-Platform Compatibility: Distribution on Windows and Linux introduced different runtime and dependency challenges. Upcoming tasks will focus on thoroughly testing builds on these platforms. 34 | 35 | - UI Bug Fixes: Addressing minor yet crucial UI bugs required repeated testing. Adding collapsible panels and submenus also introduced layout adjustments that required careful tuning to avoid disrupting the user flow. 36 | 37 | 38 | ## Limitations 39 | - Apple Developer Account Dependency: Open-source contributors must have Apple Developer credentials for macOS builds, which may limit participation without a centralized solution. 40 | - Websocket server: A crude websocket server was used for real-time collaboration, which may not be scalable for larger groups. Future iterations will explore more robust solutions for handling collaborative editing. 41 | - Processing Java library and JDK storage: For this project, the Processing Java library, nor the JDKm were committed to the repository due to its size. Contributors must download the Processing4 application, go into it's Contents folder and copy the Java folder into the tools/PlugIns folder. This is a temporary solution until a more automated process is implemented. 42 | - Windows build: The Windows build has not been fully developed or tested, since my development environment is macOS. Future work will focus on ensuring the app runs smoothly on Windows systems. 43 | - Single Tab View: The current version only supports a single tab for editing sketches since it was out of scope for the timeline of this prototype. 44 | - Separate Collaboration Window: In order to keep the Websocket connection straightforward, when the user starts a collaborative session, a new window is opened with the collaborative session. This was a solution to make connection/disconnection to specific rooms easier, since connection to a room is by URL. A future iteration should maintain rooms via Websocket messages so that the user could have multiple collaborative sessions open at once on the same window. 45 | 46 | ## Future Vision & Improvements 47 | - Running sketches with a headless Processing Library: This will streamline the execution of Processing sketches within the app, improving performance and user experience. 48 | - LSP Integration: Implementing the Processing Language Server Protocol will enhance coding features, such as autocompletion and syntax highlighting, for a more robust editing experience. 49 | - Allow Imports of External Processing Libraries: Enabling users to import external Processing libraries will expand the app's functionality and utility for Processing users. 50 | - Importing Assets: Adding support for importing assets like images and sounds into the Processing sketch will enhance the creative capabilities of users. 51 | - Peer-to-peer Collaboration: Exploring peer-to-peer connections with WebRTC for real-time collaboration will provide an alternative to WebSocket-based collaboration, offering more flexibility and scalability. 52 | -------------------------------------------------------------------------------- /2024_NewBeginnings/final-reports/pr05_2024_final_report_Claudine_Chen.md: -------------------------------------------------------------------------------- 1 | # Final Report for Simplifying the workflow for Processing libraries 2 | 3 | | **Project** | [Simplifying the workflow for Processing libraries, tools, and modes](https://github.com/processing/pr05-grant/wiki/2024-Project-List-for-%60pr05%60-=-Processing-Foundation-Software-Development-Grant#%F0%9F%85%BF%EF%B8%8F-simplify-the-workflow-for-processing-libraries-tools-and-modes) | 4 | | :--- | :--- | 5 | | **Grantee** | [Claudine Chen](https://github.com/mingness) | 6 | | **Mentor** | [Stef Tervelde](https://github.com/Stefterv) | 7 | | **Repos**| https://github.com/processing/processing-library-template
https://github.com/processing/processing-contributions
documentation repo: https://github.com/mingness/pr05-simplify-workflows| 8 | 9 | 10 | ## Technical Decisions 11 | 12 | ### Library template 13 | 1. The Gradle build file written in Kotlin, for the library template. Kotlin is now the default script language. This decision, however, forced us to put everything in one file, rather than having editable fields in one file, and release tasks in another. This is because Kotlin doesn't allow the build file to be split into multiple files. 14 | 2. Gradle is not easy, which is probably why the template `processing-library-template-gradle` seemed to take a 15 | design approach of eliminating any interactions by the user with Gradle scripts, opting instead to have the user input all relevant build parameters into a config file. Propagating the information from this config file into Gradle tasks required 16 | additional code. So while this approach does work, it comes at a cost of readability of the Gradle scripts. We opted to not protect the user from Gradle, but let this be an opportunity to learn how to interact with Gradle. We tried to simplify the interaction as much as possible, and to instruct and explain as much as possible. In our template, the user will add their library name, domain, and dependencies into the Gradle file, guided by comments. 17 | 3. We had a principle, to define values only once. Therefore, the version is defined in Gradle once, and propagated to the library properties file. Previously the version was also reported back by the library, but all the options available to accomplish this without setting the version twice were unappealing, and we chose to not implement this. 18 | 4. We chose to promote the use of MkDocs for creating documentation websites via Github project pages. This provides straightforward documentation websites based on markdown. Hosting documentation is a requirement for publishing a library in the Contribution Manager. The old documentation recommended people build and host their own documentation website which adds a lot of complexity. The main goal of this project was to simplify the process of creating and publishing a library, so it made sense to automate the process of creating/hosting this documentation as much as possible. 19 | 5. We chose to have a `release.properties` file, where the user will input values for the library properties text file. All fields are mapped directly, and the `version` in the 20 | Gradle build file is mapped to `prettyVersion` in the properties file. 21 | 22 | ### Add contributions workflow 23 | 1. We decided to make a new database file, called `contributions.yaml`. The format of the database file was selected to be a list of objects, in yaml format. Yaml format allows for ease of understanding any edits in the database. Each edit will appear per line with the field name, making each edit easy to see using Github's interface, compared to tabular formats, like csv. For tabular formats, Github's interface, which shows if a row has an edit, would highlight more which contribution had and edit, but the edit itself would be harder to see, especially since the column label would be on a different line. 24 | 2. In the previous repository, some data from the properties files are overwritten by design, based on the categories the source url was listed under, or if it's a "broken" contribution. To make it intuitive to compare values in the database against the properties file, it was decided that the data in the database directly reflect the data in the properties files. To be able to overwrite this data in the output files, we've implemented an `override` field. The value of the `override` field is an object, where any component field values will replace the existing field values. For example, libraries in the `broken.conf` file are outdated, and we want to cap the `maxRevision` to `228`. This cap can be applied by setting `override` to {`maxRevision`: `228`} 25 | 3. We want the database file to contain all contributions ever. This means, we need to store contributions that are deprecated, and we need to store that state. This is set by a new `status` field. If we know a library has been deprecated, then we can manually set the `status` to `DEPRECATED` and updates for library will no longer be attempted. A value of `VALID` indicates the library is live. `BROKEN` indicates that the url did not serve the properties file as expected, but we will continue to check the source url for the properties. This `status` value is automatically set if the properties are not found at the url during an update. 26 | 4. The previous process required the new contributor to email the Processing librarian. 27 | We have replaced this initial contact with an issue form. The issue form makes it 28 | clear as to what is required to register the library, and can be used to trigger workflows. 29 | 5. The creation of the issue form triggers a Github workflow, which automatically 30 | retrieves the properties file, parses and validates it, and if valid, creates a 31 | pull request for the Processing librarian to review. The way the workflow was designed, 32 | was to allow for a rerun of the workflow, in case of edits to the repository. In order to do this, the branch is deleted before being recreated again by the workflow. 33 | 6. To ensure readability and to use preexisting documentation, use of third-party 34 | actions was preferred. 35 | 7. The workflow that checks the urls daily needs to merge its changes automatically, without human intervention. For this reason, we make direct changes into the default branch `main`. This workflow will check the url of every contribution that doesn't have a `status` of `DEPRECATED`, and will update the contribution if the `version` changes. If there isn't a properties file at the url, the contribution will be marked with a status of `BROKEN` until it is live again. 36 | 8. In the new repository, the output files are no longer a part of the repository, 37 | to make source of truth clear - the database file. These output files will instead 38 | reside as workflow artifacts. 39 | 9. Two different levels of validation are used, where the validation for new contributions is more strict than for existing contributions. This is because some older properties files have different field names than currently expected. Currently we look for `authors` and `categories`, but in older files they might be `authorList` or `category`. 40 | 10. We implemented validation using Pydantic's built in validation, simply because considering all the cases manually became too much. Pydantic wasn't used from the start, because it was intended to write the scripts in a language in the Java family, like Kotlin. However, they currently are in Python. 41 | 42 | 43 | ## Challenges 44 | 45 | - Writing the Gradle build file was a challenge. Gradle is not well documented, and while I had used it before, coding in it is another matter. Also, we chose to write the build file in Kotlin, for which there is even less documentation. 46 | - Gradle does not work well when run from command line. I had an apparent issue with caching when running Gradle from command line. It worked perfectly from the Gradle menus in Intellij and VS Code. 47 | - There were some difficulties in implementing the contributions database file, simply because, data is messy, and is rarely as theoretically clean as expected. This work needed to convert logic enshrined in config files and a script into data. The process of doing this required iterations of trial and error. 48 | 49 | 50 | ## Tasks Completed 51 | 52 | ### Library template 53 | 54 | - [x] A Gradle build file, that 55 | - uses jitpack to resolve Processing, instead of local jar files. Once Processing is offered on Maven, this will be changed to resolve via official sources. 56 | - has Gradle tasks for building the library, creating the properties file, creating all release artifacts, and installing the library in a local Processing instance. 57 | - [x] The template contains an example library that uses an external dependency, as an a functioning example to work from. The template can be compiled as is. This template provides an example that can be easily accessed in Processing from the examples menu. 58 | - [x] The template has a workflow that includes the necessary release artifacts in a Github release. The default release artifacts only include the source code. 59 | - [x] It provides a new mkdocs powered documentation website example. This framework provides a simple format suitable for documentation websites, based on markdown files. 60 | - [x] The template includes documentation, including detailed instructions on getting started, using the Gradle build file, and how to release and publish. 61 | - [x] The library template is now integrated into the processing account. 62 | - The previously named `processing/processing-library-template` is now named 63 | `processing/processing-library-template-ant`. 64 | - The previously named `mingness/processing-library-template` is now named 65 | `processing/processing-library-template`. 66 | 67 | ### Add contributions workflow 68 | - [x] Create new database file, called `contributions.yaml`, as designed. The design is described in https://github.com/mingness/pr05-simplify-workflows/blob/main/Adding_contribution_workflow_notes.md#design-of-database-file 69 | - [x] Write script for checking online property txt files for each contribution. 70 | - [x] Create scripts to create `pde/contribs.txt`, and `content/contributions/*.json` files. 71 | - [x] Create issue form for new library contributors to fill, which then automatically creates the pull request that changes the database file. 72 | - [x] Test output files with website and contribution manager. 73 | - [x] Create workflow such that, if there is an update, edit the database file, and recreate contribs.txt and json files. The output files are stored as workflow artifacts. 74 | - [x] The processing contributions repository is now integrated into the processing account. 75 | - The previously named and private repository `processing/processing-contributions` is now named `processing/processing-contributions-legacy`. 76 | - There is now a repository named `processing/processing-contributions`, which contains 77 | only the important files of `mingness/processing-contributions-new`. 78 | 79 | 80 | ## Limitations 81 | 82 | - The library template at `processing/processing-library-template` has been tested only for a simple case. We will have to wait for a crowd of people to test the template, and hopefully let us know if something is not working well. 83 | - The scripts in `processing/processing-contributions` do not have tests. 84 | - The `contributions.yaml` database file in `processing/processing-contributions` has three fields which do not have comprehensive data. These fields are `dateAdded`, `dateUpdated`, and `previousVersions`. To fill in this data will require delving into the archives the Github commit history. 85 | - Only a template for libraries was created. A template for tools and modes was not investigated. 86 | - Originally there was an idea to run the examples from the library template using the IDE, but this was not implemented. However, it is possible to run the examples in Processing, so perhaps this is not a limitation. 87 | 88 | ## Work Remaining & Next Steps 89 | 90 | - [ ] Write tutorial, and publish on Processing website 91 | - [ ] Compare the output files from the daily update workflow of `processing/processing-contributions` with the output files from `processing/processing-contributions-legacy` 92 | - [ ] Use the output files from the daily update workflow of `processing/processing-contributions` for Contribution Manager and Processing website 93 | - [ ] Review feedback on the library template at `processing/processing-library-template`, and iterate on improvements 94 | - [ ] Delve into archives of contributions, and add data for fields `dateAdded`, `dateUpdated`, and `previousVersions` in the `contributions.yaml` database file in `processing/processing-contributions`. 95 | -------------------------------------------------------------------------------- /2024_NewBeginnings/final-reports/pr05_2024_final_report_Diya_Solanki.md: -------------------------------------------------------------------------------- 1 |

2 | pr05'24 Final Report 3 |

4 |

Create an Official Processing VSCode Extension 5 |

6 | 7 | | **Project** | [Processing Language Server Extension](https://github.com/processing/pr05-grant/wiki/2024-Project-List-for-%60pr05%60-=-Processing-Foundation-Software-Development-Grant#%F0%9F%85%BF%EF%B8%8F-create-an-official-processing-vscode-extension) | 8 | |-----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| 9 | | **Grantee** | [Diya Solanki](https://github.com/diyaayay) | 10 | | **Mentors** | [Sam Lavigne](https://lav.io/), [Justin Gitlin](https://cacheflowe.com/) | 11 | | **Repository** | [Processing-language-server-extension](https://github.com/diyaayay/processing-language-server-extension) | 12 | 13 | 14 | ## Description 15 | 16 | This report details my work, development processes, and insights gained during the pr05 2024 "New Beginnings" software development grant with the [Processing Foundation](https://processingfoundation.org/). During the past four months, I have focussed on developing the [Processing Language Server Extension](https://github.com/diyaayay/processing-language-server-extension/) for the Processing software for VSCode. Currently, Processing is distributed as a standalone software compatible with multiple platforms; this extension integrates `.pde` sketch files into VSCode, providing robust IntelliSense support to enhance the coding experience. 17 | It was a privilege to work under the mentorship of Sam Lavigne and advisor Justin Gitlin. Together, we conducted bi-weekly project check-ins to review progress and address challenges in development. 18 | The Language Server Extension includes a server-side implementation and a client interface within the VSCode editor, delivering IntelliSense functionality to developers working with .pde sketches. The complete project plan is accessible within the project's [roadmap](https://github.com/diyaayay/processing-language-server-extension/blob/Development/ROADMAP.md). 19 | 20 | 21 | ## What code got merged in 22 | - [Run Processing Sketches](https://github.com/diyaayay/processing-language-server-extension/blob/Development/client/src/sketchRunner.ts):  23 | The Run and Stop button toggle according to the state of the sketch. The sketchbook can contain multiple sketches each residing in a directory of the same name as that of the sketch. 24 | - [Grammar](https://github.com/diyaayay/processing-language-server-extension/tree/Development/server/src/grammar/terms): Defines Processing specific grammar model to parse the textDocument in workspace. 25 | - [Parser](https://github.com/diyaayay/processing-language-server-extension/blob/Development/server/src/parser.ts): The parser.ts file defines functions to parse Java code into an Abstract Syntax Tree (AST) and extract tokenized information from the code. The main function, parseAST, processes Java code and returns an array of token pairs representing each parse tree node and its parent. The lineMap function creates mappings of each word in a line to its start and end positions, helping locate tokens within specific lines. The parse function leverages the java-ast library to handle parsing while muting unnecessary console output through a redirectConsole utility, which temporarily disables logging during the parsing process. 26 | - [Sketch Runner](https://github.com/diyaayay/processing-language-server-extension/blob/Development/client/src/sketchRunner.ts): Defines a SketchRunner class that manages the execution of Processing sketches in a Visual Studio Code extension. It provides functionality to initialize the sketch runner with a specified Java Runtime Environment (JRE) path and a sketch directory. The class can run and stop sketches while handling output from the Processing environment through buffered channels to manage the display in the VSCode output window. It also includes error logging to capture issues during execution and during the copying of compiled sketches. The copyCompiledSketch method ensures that .class files are correctly transferred from the source to the destination directory, maintaining the structure of the original sketch. Additionally, the dispose method cleans up resources when the sketch runner is no longer needed, preventing memory leaks. Overall, the class encapsulates the functionality required to run and manage Processing sketches effectively within the editor environment. 27 | - [Sketch Errors](https://github.com/diyaayay/processing-language-server-extension/blob/Development/client/src/sketchRunner.ts): On Running a sketch, the LSP extension starts watching the sketch and logs errors in the Output tab. 28 | - [On-Hover Documentation](https://github.com/diyaayay/processing-language-server-extension/blob/Development/server/src/hover.ts): The on-hover feature would display the documentation for every keyword of the Processing language stored in [XML files](https://github.com/diyaayay/processing-language-server-extension/tree/Development/server/out/processing/lspinsights). 29 | - [Code Completion](https://github.com/diyaayay/processing-language-server-extension/blob/Development/server/src/completion.ts): Keywords are reserved keywords in the Processing language. This feature would display a pop-up menu containing a list of keywords aligning with the triggering character. 30 | - [Goto Reference](https://github.com/diyaayay/processing-language-server-extension/blob/Development/server/src/references.ts): This feature responds to the onReferences requests by the user when they select the option of, found in the context menu to navigate to the schemas that reference the location under the cursor. 31 | - [Goto Definition](https://github.com/diyaayay/processing-language-server-extension/blob/Development/server/src/definition.ts): This is vice-versa of the former issue i.e., jump to the schema a reference refers to. This is the same as going to the variable declaration through `Ctrl/Cmd + Click` or the context menu. This uses the `onDefinition` request from the user in the extension host to redirect the cursor to the definition the reference refers to. 32 | 33 | ## Techincal challenges and decisions taken: 34 | 35 | - **Running Processing headless** without requiring the user to set paths or require some complex setup was the main challenge to make the version migration work everywhere. 36 | - This required quite a bit of research and decisions taken regarding bundling everything in the extension:- We aimed to run the processing sketches inside the extension host (which is different from running the sketches in a JavaScript frontend, for example). We could simply call the binary using some `npm` package like `child_process`, `spawn-process`, etc., but then we need it inside the extension host as it should also have the client-server support - necessary to make all LSP features work smoothly. 37 | - For example, [vscode-languageserver-node](https://github.com/microsoft/vscode-languageserver-node) is using a custom script called `symlink` which can be executed normally as `npm run symlink`. It just executes a file called [symlink.js](https://github.com/microsoft/vscode-languageserver-node/blob/main/build/bin/symlink.js) which creates the hardlinks and softlinks between the protocol, the server, the client and the extension folder. Some languages have better low-level control, like [C](https://pubs.opengroup.org/onlinepubs/009696899/functions/symlink.html#:~:text=The%20symlink()%20function%20shall,contained%20in%20the%20symbolic%20link) and [Rust](https://doc.rust-lang.org/stable/std/os/unix/fs/fn.symlink.html) that support links creation. 38 | - Opting for a similar approach, the Processing distribution is binded to the extension. The large size of the extension is due to custom dependencies downloaded via the [dependency.bat](https://github.com/diyaayay/processing-language-server-extension/blob/Development/dependency.bat) script. The [dependency.zip](https://github.com/diyaayay/processing-language-server-extension/releases/download/v1.2/dependency.zip) contains the Processing distribution for Windows, which is extracted into `jre/deps`. 39 | - **Release binding with commit**: I encountered an unexpected issue with GitHub releases that took me some time to understand. When the maintainer creates a GitHub release, it automatically binds to a commit on the default branch. When this branch is cloned, it causes multiple issues, including connection failures with the LSP client and errors related to the VSCode API. After some research, I resolved the problem by binding GitHub releases to a commit on a branch other than the default branch. 40 | 41 | ## Current state of the Project: 42 | 43 | As outlined in the project roadmap, the LSP extension has been developed for cross-platform compatibility. Packaging Processing's latest version to bundle with the extension and run from its server was achieved by creating symlinks using Rust (a low-level language) for **Windows**. This eliminated the need for users to add the Processing path to their environment variable and enabled Processing to run in headless mode. This method in the future would enable the distribution to run directly from the extension on all platforms. The following milestones have been successfully achieved: 44 | 45 | - [x] Stable Architecture 46 | - [x] .vsix release and VSCode Marketplace release 47 | - [x] Integrate Processing 4.3 48 | - [x] Workspace management 49 | - [x] Run and Stop Buttons 50 | - [x] On-hover documentation 51 | - [x] Syntax highlights 52 | - [x] Sketch Errors 53 | - [x] Run Processing sketches headless 54 | - [x] Run Multiple Sketches 55 | - [x] Workspace Management (Sketch and Sketchbook) 56 | - [x] Go-to-definitions 57 | - [x] Go-to-References 58 | - [x] Code Completion 59 | 60 | 61 | ## Limitations 62 | - The LSP features work cross-platform, but sketch execution is currently limited to **Windows** due to the specific [symlink](https://doc.rust-lang.org/std/os/unix/fs/fn.symlink.html) setup for the Windows distribution. 63 | - The large size of the extension is due to custom dependencies downloaded via the `dependency.bat` script. The [dependency.zip](https://github.com/diyaayay/processing-language-server-extension/releases/download/v1.2/dependency.zip) contains the Processing distribution for Windows, which is extracted into `jre/deps`. 64 | - This limitation is due to the extension's JSON-RPC architecture, which enables client-server communication for IntelliSense features. A layered structure was established to connect the protocol, server, client, extension, and Processing distribution, using symlinks to package Processing and execute sketches from the sketch runner. 65 | - Future development could use similar setups for other platforms to expand compatibility. 66 | 67 | ## Future Goals 68 | The following objectives are prioritized for future contributions to the project: 69 | - Establish a comprehensive testing strategy with full feature tests. 70 | - Extend Processing's AST and AST-supported features. 71 | - Bundling of Processing distribution by creating symlinks for multiple platforms (current bundling approach). 72 | - Transition from the custom bundling of Processing with symlink creation for multiple platforms to a modular approach by shipping the core and pre-processor as Maven packages(WIP), and offering a comprehensive CLI interface for Processing and its Language Server, significantly reducing the extension size. 73 | - Enhance the extension's interface to provide an intuitive experience with labeled icons, separate run/stop toggle buttons for each sketch, and other improvements. Drawing inspiration from Antiboredom's [p5.vscode](https://github.com/antiboredom/p5.vscode). 74 | 75 | While VSCode remains one of the most widely used code editors, extending support for this LSP to other editors, including JetBrains, Eclipse, and CodeMirror, can also be a future goal. 76 | 77 | ## Relevant Commits and Issues 78 | - All feature commits are here: [merged code](#what-code-got-merged-in) 79 | - [LSP Release for Processing 4 Beyond the Current Workaround](https://github.com/diyaayay/processing-language-server-extension/issues/1) 80 | - [Licensing discussion](https://github.com/diyaayay/processing-language-server-extension/issues/1) 81 | - [Dynamic sketchpaths](https://github.com/diyaayay/processing-language-server-extension/commit/80e13ed678c8eb464fcccd9b2136fbbd543c25ba) 82 | 83 | ## Important Links 84 | - [Project Link](https://github.com/diyaayay/processing-language-server-extension/) 85 | - [Monthly Updates](https://github.com/processing/pr05-grant/tree/main/2024_NewBeginnings/monthly-reports) 86 | - Marketplace Release: [Download](https://marketplace.visualstudio.com/items?itemName=DiyaSolanki.processing-language-server-extension) 87 | - [GitHub release](https://github.com/diyaayay/processing-language-server-extension/releases/tag/v0.0.1) 88 | - Dependency release: [Processing bundle](https://github.com/diyaayay/processing-language-server-extension/releases/tag/v1.2) -------------------------------------------------------------------------------- /2024_NewBeginnings/final-reports/pr05_2024_final_report_Miaoye_Que.md: -------------------------------------------------------------------------------- 1 | 2 | # Revamp the Friendly Error System in p5.js 2.0 3 | 4 | | **Project** | [Revamp the Friendly Error System in p5.js 2.0](https://github.com/processing/pr05-grant/wiki/Revamp-the-Friendly-Error-System-(FES)-for-p5.js-2.0-(detailed-description)) | 5 | | :--- | :--- | 6 | | **Grantee** | [Miaoye Que](https://github.com/sproutleaf) | 7 | | **Mentors** | [Kenneth Lim](https://github.com/limzykenneth), [Dave Pagurek](https://github.com/davepagurek) | 8 | | **Repo**| https://github.com/processing/p5.js/tree/dev-2.0 | 9 | 10 | ## Technical Decisions 11 | 12 | ### Condensing `parameterData.json` for Parameter Validation 13 | 14 | - The existing `parameterData.json` file that we use to extract parameter information has a few problems: 15 | - It often contains unnecessary information, such as the function's return type. 16 | - It contains information that can be represented in a more concise manner, `?` at the end of the parameter name to indicate that the parameter is optional. 17 | - Has a nested structure that makes it difficult to parse. 18 | - The improved `parameterData.json` file, generated by `utils/convert.js`, resolves the above issues and saw a reduction of 80% in file size. 19 | 20 | ### [Zod](https://zod.dev/) for Parameter Validation 21 | 22 | - Zod is a powerful, flexible schema validation library withs static type inference. It provides all the use cases that parameter validation in p5.js requires. 23 | - Zod is [already used in the p5.js ecosystem](https://github.com/processing/p5.js-website/blob/main/src/content/tutorials/config.ts#L19)—in the process of building p5's website. 24 | - Zod is tree-shakable, meaning that unused library code will not be included in the final p5 bundle size. 25 | - **Do note that** initially, we considered generating `.d.ts` files from the library code, then using the generated files as input in `ts-to-zod`, which will conveniently generate Zod schemas that can be readily used for parameter validation. However, this approach presented a few challenges, including: 26 | - The generated `.d.ts` files were too big and had duplicated information. 27 | - Chainable methods return an interface for the whole p5 module, instead of just referencing the existing p5 type. 28 | - Even with the `.d.ts` files generated, `ts-to-zod` [might not support all the JSDoc tags](https://github.com/processing/p5.js/pull/6972). 29 | - As a result, we wrote custom logic that parses the `parameterData.json` file containing all the function signatures for parameter validation. 30 | - We also experimented with using [`zod-validation-error`](https://github.com/causaly/zod-validation-error) to generate error messages, but eventually did not move forward with it because the library has a narrow range of customization options, limiting our ability to present error messages that are accessible, informative, and beginner-friendly. 31 | 32 | ### `acorn` and `acorn-walk` for detecting accidentally overriden constants and functions 33 | 34 | - We evaluated multiple JavaScript parsers, including `acorn`, `esprima`, and `espree`, and ultimately decided to use `acorn` and `acorn-walk` because: 35 | - `acorn` has a smaller bundle size and is faster than `esprima`. 36 | - `acorn` has better support for ES2015+ syntax. 37 | - `acorn-walk` has a simpler API and is easier to understand and modify. 38 | - Both `acorn` and `acorn-walk` are tree-shakable. 39 | 40 | ## Challenges 41 | 42 | ### Achieving a balance between leveraging on external libraries and keeping FES well-built and accessible 43 | 44 | - `ts-to-zod` and `zod-validation-error` were both great libraries that we considered using, but had to give up after some exploration due to their incompatibility with our project goals. 45 | 46 | ### Developing FES within the new p5.js 2.0 architecture 47 | 48 | - Many new facets of the p5.js 2.0 architecture (dependency injection, decorator pattern, etc) were unfamiliar to me, and some trial-and-error was needed to understand how to implement the 2 priorities in the project properly and efficiently, which delayed the initial project timeline. 49 | 50 | ### Ensuring comprehensive coverage of use cases 51 | 52 | - Both parameter validation and accidental override detection have many use and edge cases. Working on the development of these features required a detail-oriented attitude, and a robust understanding of FES. I made sure to document all the things to note, and worked through them diligently. 53 | 54 | ## Tasks Completed 55 | 56 | - [x] Condensed `parameterData.json` for parameter validation 57 | - [x] Implemented parameter validation with Zod 58 | - [x] Implemented accidental override detection 59 | - [x] Wrote unit tests for both parameter validation and accidental override detection 60 | 61 | ## Limitations 62 | 63 | As of now, the two features have not been integrated into the dev-2.0 branch in p5's repo yet, meaning that old versions are still being used. There also needs to be more testing in real environments (p5.js editor, processing, etc) to ensure that they work as expected in real-world scenarios. 64 | 65 | ## Work Remaining & Next Steps 66 | 67 | - [ ] Address the comments in the [last PR](https://github.com/processing/p5.js/pull/7326), and merge it. 68 | - [ ] Add more robust loading of user scripts. 69 | - [ ] Use the decorator pattern to integrate the two features into p5.js 2.0. 70 | - [ ] Clean up old code that's no longer being used. 71 | - [ ] Go through all open issues in p5 repo related to FES, and respond to them if this project can address them. 72 | 73 | ## Relevant PRs and Issues 74 | 75 | Please refer to the two master issues for all PRs I've created, other issues that mention parameter validation / accidental override detection, and additional notes and to-do lists: 76 | 77 | - [Parameter Validation](https://github.com/processing/p5.js/issues/7178) 78 | - [Accidental Override Detection](https://github.com/processing/p5.js/issues/7269) -------------------------------------------------------------------------------- /2024_NewBeginnings/monthly-reports/README.md: -------------------------------------------------------------------------------- 1 | Monthly reports from the 2024 `pr05` cohort will be stored here. 2 | 3 | Please use the following naming convention: `pr05___report__.md`. 4 | 5 | For example, if your name is **Alice Pleasance Liddell** and you are writing your report for **July 2024**, the file should be called: 6 | 7 | `pr05_2024_July_report_Alice_PleasanceLiddell.md` 8 | -------------------------------------------------------------------------------- /2024_NewBeginnings/monthly-reports/pr05_2024_August_report_Claudine_Chen.md: -------------------------------------------------------------------------------- 1 | # August Monthly Report - for Simplifying the Workflow for Libraries, Tools, and Modes 2 | ## Claudine Chen 3 | 4 | ### Work Accomplished 5 | 6 | Work continued to finalize the library template. 7 | 1. This included debugging Gradle tasks, and refining flows and comments in 8 | the `build.gradle.kts` for usability and comprehension. 9 | 2. Also, the example library was extended to include an external dependency, 10 | to ensure that the build task worked. 11 | 3. MkDocs support was added. There is a starter website, and a Github workflow 12 | that deploys the website as a Github Pages project website. This starter website 13 | also documents the library template. 14 | 15 | We also started planning and designing the adding contribution workflow. 16 | In a new repo, the existing contributions source files will be processed into 17 | a new database file, in yaml format. This data will then be processed into 18 | the artifacts needed by the website and contributions manager. 19 | New contributions will come in as an issue via form, which will configure and 20 | create a new branch and pull request, with the contribution added to the 21 | yaml database file. 22 | This work will begin in September. 23 | 24 | 25 | ### Challenges Encountered 26 | One goal that in the end was cut from the template, was returning the version of the library as a library method, 27 | and synchronizing that version with gradle. To do this, either the user must maintain the version manually, or it 28 | could be synchronized via code. This was synchronized previously by inputting this value into the `library.properties` file, 29 | and propagating that value into the code with a search and replace script. Another solution could be to read in 30 | a properties file and return the value; this would require the properties file to be part of the library. Other 31 | ways were explored, to see if the Gradle file could be made aware of the Java method. In the end, it was decided 32 | not to pursue this further, since the need for the version to be reported by the library would only be in cases of 33 | debugging an error, so hopefully very rarely. We are also aware that any file or structure included in the template 34 | might be regarded as required, so we only want to offer what is required in the template. 35 | 36 | 37 | ### September Plans 38 | 39 | The plans in September are 40 | 1. to release the library template, on Discourse, and to invite feedback. 41 | 2. continue work on the add contributions flow. 42 | 1. create a new repo, and process the source data of processing-contributions into a new yaml database file. 43 | 2. create scripts that export the database into artifacts for the website 44 | 3. create scripts that export the database into artifacts for the contribution manager 45 | 4. create the workflow, such as the issue form template, and the automatic creation of the pull request 46 | -------------------------------------------------------------------------------- /2024_NewBeginnings/monthly-reports/pr05_2024_August_report_Diya_Solanki.md: -------------------------------------------------------------------------------- 1 | # August Monthly Report: Develop a VSCode LSP Server Extension for Processing 2 | By **Diya Solanki** 3 | 4 | - [Project Repository: Processing Language Server Extension](https://github.com/diyaayay/processing-language-server-extension/) 5 | - [Working Branch: main](https://github.com/diyaayay/processing-language-server-extension/blob/main) 6 | 7 | ## Completed Tasks (what's done so far) 8 | 9 | - [x] [Using the VSCode APIs](https://code.visualstudio.com/api/language-extensions/language-server-extension-guide) to set up a robust client-server architecture for establishing the connection between the server and the extension-host. 10 | - [x] Setup an `extension.ts` file which handles the spawning of the processing process, has the integrated `Run and Stop` buttons, processing commands for VSCode launch tasks, created a buffered channel, etc. 11 | - [x] [Resolved path](https://github.com/diyaayay/processing-language-server-extension/commit/dd887c14ef74cdba875abd59ecd210caf49b7c59) using `vscode-uri` which was earlier `filePathToURI` from `node:uri`. 12 | - [x] Researched into establishing an abstract syntax tree for processing language syntax; still wondering over ANTLR, lexer and parser; or writing a static AST. 13 | - [x] [Added Java Grammar support:](https://github.com/diyaayay/processing-language-server-extension/commit/7c91e7a99172740fda46ff796ea35af1a713cb55) Integrated the top level Java keywords like `private`, `static`; class body keywords like `extends`; method body keywords like `syscalls(), trim()` etc. 14 | - [x] [Added standard keyword support for processing](https://github.com/diyaayay/processing-language-server-extension/commit/74eb1cb54fef02381c3be6542b73b6c665425f3a) which includes the code snippets for Java processing. 15 | - [x] Analysed a Processing [VSCode Extension](https://github.com/avinZarlez/processing-vscode) by Avin to see the approach of running processing sketches inside the extension host. `Conclusion as of now`: We are using the similar approach as of now, i.e., to use the `child_process` library to spawn a processing process; this is a work in progress. 16 | - [x] `Solved`: Other features such as `Run & Stop` buttons (for running and stopping sketches from rendering) in the extension host for ease of use has been integrated in the client-side (can be found in the extension host). 17 | 18 | 19 | ## Challenges Encountered 20 | 21 | - Currently, I have created some [symlinks](https://www.linode.com/docs/guides/linux-symlinks) which : a) points to some [inodes](https://docs.rackspace.com/docs/what-are-inodes-in-linux), and b) references to some of the dependencies that are required to run the processing binary. So, as of now, the sketch renders (inside the extension host) but it requires some setup. The main challenge is to make the version migration work everywhere - which I am currently working on. 22 | - We aim to run the processing sketches inside the extension host (which is different from running the sketches in a JavaScript frontend, for example). We could simply call the binary using some `npm` package like `child_process`, `spawn-process`, etc., but then we need it inside the extension host as it should also have the client-server support - necessary to make all LSP features work smoothly. 23 | - I am reading a bit more on symlinks and exploring what all options do we have for the wrappers. For example, [vscode-languageserver-node](https://github.com/microsoft/vscode-languageserver-node) is using a custom script called `symlink` which can be executed normally as `npm run symlink`. It just executes a file called [symlink.js](https://github.com/microsoft/vscode-languageserver-node/blob/main/build/bin/symlink.js) which creates the hardlinks and softlinks between the protocol, the server, the client and the extension folder. Some languages have better low-level control, like [C](https://pubs.opengroup.org/onlinepubs/009696899/functions/symlink.html#:~:text=The%20symlink()%20function%20shall,contained%20in%20the%20symbolic%20link) and [Rust](https://doc.rust-lang.org/stable/std/os/unix/fs/fn.symlink.html), if that can help better with the system level symlinks; I am exploring these options also. 24 | - After this is done, it will be ready for testing and releasing, ASAP. 25 | 26 | ## Plans for September 27 | 28 | - [ ] `Goal`: Two features per week: 29 | - [ ] Code-completion 30 | - [ ] Diagonostics 31 | - [ ] Hover 32 | - [ ] Syntax highlighting 33 | - [ ] `onReferences` 34 | - [ ] `onDefinition` 35 | - [ ] `...` 36 | 37 | - [ ] Implement the fully-featured set LSP. 38 | - [ ] Export the extension into a `.vsix` file and publish it to the [VSCode Market Place](https://marketplace.visualstudio.com/vscode). 39 | - [ ] Detailed documentation for installing and configuring the extension. -------------------------------------------------------------------------------- /2024_NewBeginnings/monthly-reports/pr05_2024_August_report_Dora_Do.md: -------------------------------------------------------------------------------- 1 | # August monthly report: Prototyping a collaborative code editor for Processing 2 | By Dora Do 3 | 4 | ## Project Overview 5 | 6 | This month, we made significant progress on the Processing Collaborative Editor (PCE) project. Our focus was on evaluating technology options, designing the user interface, and beginning the implementation of core features. 7 | 8 | ## Key Decisions and Progress 9 | 10 | - Technology Stack: 11 | - After careful consideration and discussions with mentors, we decided to proceed with a custom build using CodeMirror rather than Theia. 12 | - This decision was based on CodeMirror's ease of implementation, existing collaborative features, and faster development potential. 13 | - User Interface Design: 14 | - Created wireframes and a Figma prototype for the PCE UI. 15 | - The design features a two-column layout with collapsible sections for improved usability. 16 | - Development Progress: 17 | - Successfully integrated CodeMirror editor with Electron. 18 | - Implemented basic functionality to run Processing sketches from within the application. 19 | - Began integration of CodeMirror's collaborative features. 20 | 21 | ## Challenges and Solutions 22 | 23 | We encountered some technical challenges, particularly with running the `processing-java` process when using Vite. This was resolved by adjusting our build process to use Vite only for the React app portion. 24 | 25 | ## Collaborative Features 26 | 27 | We're exploring two main approaches for implementing real-time collaboration: 28 | 29 | 1. Using a locally hosted intermediary server with web sockets 30 | 2. Using peer-to-peer connections with WebRTC 31 | 32 | Each approach has its pros and cons, and we're currently evaluating which will be the best fit for our project goals. 33 | 34 | ## Next Steps 35 | 36 | - Complete the integration of CodeMirror's collaborative features 37 | - Refine the UI design and implement remaining layout components 38 | - Decide on and implement the collaborative connection approach 39 | - Begin work on integrating Language Server Protocol (LSP) for enhanced coding features 40 | 41 | ## Conclusion 42 | 43 | August has been a productive month for the PCE project. We've made critical decisions on our technology stack, advanced our UI design, and begun implementing core features. As we move into September, our focus will be on refining the collaborative aspects of the editor and continuing to improve the overall user experience. 44 | -------------------------------------------------------------------------------- /2024_NewBeginnings/monthly-reports/pr05_2024_August_report_Miaoye_Que.md: -------------------------------------------------------------------------------- 1 | # August Monthly Report: Revamp the Friendly Error System (FES) in p5.js 2 | 3 | By Miaoye Que, mentored by Kenneth Lim and Dave Pagurek with support from Qianqian Ye. 4 | 5 | ## Work Completed 6 | 7 | ### Accidentally Overridden Constants and Functions 8 | 9 | - [x] Picked out a parser for detecting overridden constants and functions (`Espree`). 10 | 11 | ### Parameter Validation 12 | 13 | To see all PRs and real-time progress for parameter validation, check out the [master issue #7178](https://github.com/processing/p5.js/issues/7178). 14 | 15 | - [x] Start a new parameter validation file using Zod for p5.js. 16 | - [x] Update script that generates `parameterData.json` to further reduce the size of the file. 17 | - [x] Validate against real p5 constants. 18 | - [x] Handle schema generation for optional parameters. 19 | - [x] Implement a distance calculation mechanism similar to [`scoreOverload`](https://github.com/processing/p5.js/blob/ada3c05da35bb8daf3b9d0ca1dc5713bff0b95c1/src/core/friendly_errors/validate_params.js#L425) that gives users the proper error message when parameter validation fails. 20 | - [x] Start a test file for new parameter validator. 21 | - [x] Fix the case where a parameter can be a mix of constants and primitive types. 22 | 23 | ## Challenges Encountered 24 | 25 | ### General 26 | 27 | - At the end of July, I planned to set August as my implementation-heavy month, with the aim of getting both of the priorities for the FES project implemented or almost implemented. However, I ended up spending most of my time getting TypeScript exporting to work. Later, I realized that some parts of my plan, although conceptually ideal, might be more complicated and uncertain than I expected when it comes to implementation. To this end, I'm letting myself adjust my timeline a bit, to be more realistic with the amount of work that needs to be done. 28 | - More generally, I initially divided my grant period into clearly-defined, task-oriented milestones (i.e. research first, then implementation, ending with testing and integration). In reality, the process of coding and implementation often reveals oversight and issues that weren't apparent during the research phase. For future projects (both mine and other Processing Foundation associates'), it's better to envision grant periods in terms of _iterations_, instead of _phases_. 29 | 30 | ### Accidentally Overridden Constants and Functions 31 | 32 | - I spent minimal time on this task in July, so there's nothing much to report here. 33 | 34 | ### Parameter Validation 35 | 36 | - Approach: leverage on `zod`, a TypeScript-first schema validation library with static type inference. 37 | - Planned workflow: generate `.d.ts` file -> use the generated file as input in `ts-to-zod`, generate `zod` schema -> use the generated schema for parameter validation. 38 | - `.d.ts` file generated is currently too big and has many duplicated elements. 39 | - Methods that are chainable and return the p5 instance inline an interface for the whole p5 module as its return type. 40 | - Unsure if we can get clean TypeScript types; this might be a dead end that we simply haven't figured out yet, and it'd require a lot of work to have a clear answer. 41 | - New workflow: based on the JSON file that contains all the p5 methods and their accepted parameters, write a custom parser that generates `zod` schema for validation. 42 | - Writing a custom parser means that we need to explicitly define each parameter type and constant, which turned out to be rather complicated and requires a lot of attention to detail. 43 | - For object (both p5 objects such as `p5.Camera` and Web API objects such as `Audionode`) validation to work, I need to bring up an actual browser environment, which is more complicated than just runnign `node file.js` for testing. 44 | 45 | ## September Plans 46 | 47 | - Wrap up the implementation, testing, and integration for parameter validation. 48 | - Start working on the next priority: report accidentally overridden constants and functions; at least get to a 75% done state. 49 | -------------------------------------------------------------------------------- /2024_NewBeginnings/monthly-reports/pr05_2024_August_report_Nahee_Kim.md: -------------------------------------------------------------------------------- 1 | # Monthly Report - August 2024 2 | 3 | **Overview:** This month, I focused on resolving issues related to the `useEffect` dependency array and researched ways to improve the integration of `@uiw/react-codemirror` with React lifecycle events, particularly in the context of CodeMirror 6. Here’s a detailed breakdown of progress: 4 | 5 | ## 1. Resolving useEffect Dependency Array Issues: 6 | 7 | **Identifying the Issue:** 8 | I identified that most of the issues were stemming from the way the dependency array in `useEffect` was structured. This required further investigation to determine which variables could safely be removed from the array without affecting functionality. 9 | 10 | **Proposed Solutions:** 11 | 12 | Connie’s Idea: Connie suggested separating `useEffect` hooks as much as possible, so each one has its own relevant dependency array. This would minimize unnecessary re-renders and make the code cleaner. 13 | Additionally, Connie proposed that leaving the dependency array empty in cases where the `useEffect` acts like `componentDidMount` seemed to alleviate some issues, particularly around `tidyCode`. This needs further testing to confirm stability. 14 | 15 | ## 2. Researching and Testing @uiw/react-codemirror: 16 | 17 | **Goal:** 18 | My goal was to explore how to better incorporate React’s lifecycle with CodeMirror 6, improving overall integration and reducing potential issues. 19 | 20 | **Current Progress:** 21 | 22 | I worked on converting the `Editor/index.jsx` file using `@uiw/react-codemirror` and tested this integration extensively. A branch/PR has been created for tracking the changes: 23 | PR link 24 | 25 | **Key Changes Implemented:** 26 | 27 | Switched to using `EditorView` along with a editorView state in React instead of relying on `cmInstance.current`. 28 | Adopted `view.dispatch` for applying changes to the editor view, replacing the previous method of calling functions directly from the instance. 29 | Modified the usage of linter and Emmet to align with CodeMirror 6 updates. 30 | 31 | **Next Steps:** 32 | I plan to create a custom hook (`useCodemirror`) to streamline the setup process for the CodeMirror view, which will make the code more maintainable and reusable. 33 | 34 | ## 3. React Functional Component Conversion: 35 | 36 | **Changes Applied:** 37 | I completed the React functional component conversion for the following components: `CollectionList`, `SketchList`, `FileNode`, `ConsoleInput`, and `AssetList`. This was the last conversion ticket in the project, marking the completion of this task. 38 | 39 | **Looking Forward:** In the coming month, I will continue refining the use of the `@uiw/react-codemirror` library and conduct additional testing to ensure smooth integration. I will also explore further improvements to the `useEffect` implementation to optimize performance and stability in the application. 40 | -------------------------------------------------------------------------------- /2024_NewBeginnings/monthly-reports/pr05_2024_July_report_Claudine_Chen.md: -------------------------------------------------------------------------------- 1 | # July Monthly Report - for Simplifying the Workflow for Libraries, Tools, and Modes 2 | ## Claudine Chen 3 | 4 | ### Work Accomplished 5 | The main goal this month was to make initial strides in developing a library template using Gradle. Initial work was to explore what work had already been done by the community, and to understand what each repo did, and how they did it. From this understanding, a template that uses the best-of ideas is being assembled at https://github.com/mingness/processing-library-template. 6 | This template has been the collaborative work of myself and Katsuya Endoh, with helpful guidance from Stef Tervelde and Raphaël de Courville. 7 | 8 | Once work on the template is completed at this stage, we will have completed the following expected outcomes: 9 | - Repository templates for libraries using the new Gradle templates. 10 | - Automation for building and exporting artifacts, including PDEX/PDEZ bundles. 11 | - CI/CD deployment of the reference to GitHub pages including install links using the new pdez:// and pdex:// protocols. 12 | 13 | The main challenge met in this work was working with Gradle. The documentation has not been clarifying with respect to what plugins specifically do, and I would have to do extra searches to find out how to implement something using Kotlin, the new default and our chosen language, instead of Groovy, the previous long-time standard. Also, I had unexpected difficulties building from the commandline - the commandline build would break for situations that would build successfully from the Gradle menu in Intellij. 14 | 15 | Also, in an effort to create a process and resources that are intuitive and address the communities needs, a handful of people have been interviewed thus far about their own experiences developing libraries, which suggests some takeaways: 16 | - Most people expected documentation for building libraries to be on the website. This is a good idea, because not everyone knows to explore Github for information. 17 | - People eventually found resources using internet search. The information found and path followed varied by individual. This suggests existing information and resources are fractured and don't lead to predictable outcomes. 18 | - Needing to go to Processing to test the library grew tiresome after a while. Some would like a way to test library installation within intellij 19 | - The processing hosted gradle template is designed for the developer to interact with a build.properties file. While users found the template worked and was well documented, some didn't realize that dependencies were also to be listed in the build.properties file, and they interacted with the gradle file to add dependencies. This reminds us that users will not always interact with a design as expected. 20 | - Some people struggled with javadocs, and instead opted for mkdocs, which creates pages using markdown. 21 | - Intellij is a featureful IDE that is good for beginners. 22 | 23 | ### August Plans 24 | The plans for next month are twofold: 25 | 1. I plan to finish the initial draft of the library template, and then release it for testing. I would like to invite developers to test the new template at https://github.com/mingness/processing-library-template, but also the previous template at https://github.com/processing/processing-library-template-gradle. I will solicit feedback on their experiences. 26 | 2. Design and start the implementation of a more automated, simplified workflow for adding contributions to the processing website and contributions manager. 27 | 28 | 29 | -------------------------------------------------------------------------------- /2024_NewBeginnings/monthly-reports/pr05_2024_July_report_Diya_Solanki.md: -------------------------------------------------------------------------------- 1 | # July monthly report: Develop a VSCode LSP Server Extension for Processing 2 | By Diya Solanki 3 | 4 | - [Project repository](https://github.com/diyaayay/processing-language-server-extension/) 5 | - [Working branch](https://github.com/diyaayay/processing-language-server-extension/blob/main) 6 | 7 | 8 | ## Completed Tasks (what's done so far) 9 | 10 | - [x] Reviewed [Efratror's prior work](https://github.com/efratror/LS4P) on the LSP for Processing and explored the possibility of updating to Processing 4.1+ and 4.3 (that one works on `Processing 4.0.8b`) 11 | - [x] Built Efratror's LSP for `Processing 4.0.8b` using `Java 8` and the deprecated VSCode language server extension protocol. 12 | - [x] Set up a roadmap to track tasks and decide on the approach for the project. 13 | - [x] Successfully transitioned to Processing 4.3 by generating a release zip file containing `core.jar` and setting up the JRE zip files for running Processing sketches locally. 14 | - [x] Established that the LSP is running locally for all Processing sketches and began discussions to find the latest versions of classes required for `custom.jar`. 15 | - [x] Updated all NPM dependencies to use the latest packages. 16 | - [x] Using `JDK 17.0.8` and `node v20.15.1` (the current LTS) 17 | - [x] Managed to make the working version of the new transition! (but I still need to figure out the most concrete way of integrating the latest release and that is mainly for the ending part of the program so that is being researched simultaneously!) 18 | 19 | 20 | ## Challenges Encountered 21 | 22 | - Transitioning from `Processing 4.0.8b` to `Processing 4.3` was more complex than anticipated, requiring adjustments in dependencies and approach. 23 | - The `custom.jar` file in the old project [repo](https://github.com/efratror/LS4P) configuration involves significant changes from earlier versions, and specific classes need to be handpicked and updated. 24 | - In the latest version of processing, there are significant changes, e.g., `javafx` is not shipped with the core library now (it used to, earlier) so I compiled the new `javafx` (built it with `ant`, [reference repo here](https://github.com/processing/processing4-javafx/releases)) and integrated it with the latest `core.jar`. 25 | - I was facing some path issues also (probably due to new JRE) that I resolved. 26 | - I needed new `JRE` to make it compatible with the latest processing so I compiled it with the latest `core.jar` using [this repository](https://github.com/efratror/LS4P). 27 | - The NPM Java package currently used is optimized for OpenJDK 7, whereas `Processing 4.3` works best with `JDK 17`, causing compatibility issues. 28 | 29 | 30 | 31 | ## Plans for August 32 | 33 | - [ ] Now that `Processing 4.3` is integrated (as in running all kinds of sketches), the focus for August would be to figure out the most concrete way of integrating the latest release to be built on any system and build LSP features on the processing sketch document using the latest VSCode LSP extension API like code completion, hover, go-to definition, diagnostics, validate sketches, etc. 34 | - [x] The priority of choosing the features would be to start from the most essential features and release a version for testing. (Update 02/Sep/2024: I now have a [roadmap](https://github.com/diyaayay/processing-language-server-extension/blob/main/ROADMAP.md) for the project that has a tentative list of tasks!) 35 | - [x] August would also be focussed on integrating the `Processing 4.3` specific keywords in the AST which is the key to developing the the features on the text Document. 36 | - [x] Other features such as `Run and Stop` buttons in the extension host for ease of use. -------------------------------------------------------------------------------- /2024_NewBeginnings/monthly-reports/pr05_2024_July_report_Dora_Do.md: -------------------------------------------------------------------------------- 1 | # July monthly report: Prototyping a collaborative code editor for Processing 2 | By Dora Do 3 | 4 | ## Completed Tasks 5 | 6 | The focus of the first month of this project was about research, technical feasibility, and project scoping. 7 | 8 | - Created a [Github repo](https://github.com/doradocodes/processing-collab-editor) for this project and [Github Project](https://github.com/users/doradocodes/projects/1) to track tasks and progress 9 | - Created a prototype of an Electron app that can run Java processes and display logs from the process on the app 10 | - Create a [MVP](https://docs.google.com/document/d/1rbMAvGepee8lPmaNjLItSL4Ah5MW0jLUfjhWWO8HgyQ/edit?usp=sharing) 11 | - Researched different frameworks (ie. Theia, CodeMirror, JupyterLab, VSCodium) and tools (ie. yjs, CodeMirror collab editing) 12 | - Created a test project of Theia and experimented with customization 13 | - Created a test project of an Electron app with CodeMirror 14 | - Create a [Figma file](https://www.figma.com/design/SxmAa94lAP37OLPpY1hgVf/Processing-Collaborative-Editor-(PCE)?node-id=5-21&t=4mR3IQXoh30vJv6m-1) with initial wireframes and inspiration gathering 15 | 16 | ## Challenges 17 | 18 | - Testing some of the frameworks to see if they were customizable to our needs took a while. I ran into many errors trying to run the projects 19 | - Through researching the different options, we are still having a hard time choosing which direction to go since each have their own pros/cons 20 | - There are a lot of ideas about reimagining editor, versus matching the functionality of the current Processing IDE. There are many different directions for how this IDE could be used, and determining which audience or type of user that we want to target 21 | 22 | ## Upcoming plans 23 | 24 | - By the end of the first week of August, we should choose a direction for implementation, whether it be using an existing framework like Theia, or doing a custom build. During our next cohort meeting, I will be sharing out the findings from my research and to get the opinions of the cohort members, especially since some have experience with libraries we are thinking of using, like CodeMirror 25 | - While we decide on the direction of how this prototype should be built, I will also start creating wireframe sketches of how the editor would look, and start getting feedback on those designs 26 | - Once the designs are down, I will start breaking down MVP into tasks, and tracking them on Github Projects 27 | -------------------------------------------------------------------------------- /2024_NewBeginnings/monthly-reports/pr05_2024_July_report_Miaoye_Que.md: -------------------------------------------------------------------------------- 1 | # Revamp the Friendly Error System (FES) in p5.js 2 | 3 | ## Completed Tasks 4 | 5 | - Conducted research for the project's 2 top priorities: discover accidentally overridden constants and functions, and parameter validation. 6 | - Based on research, prior work, and guidance from mentors, drafted a [project plan](https://github.com/sproutleaf/pr05-fes/blob/main/project_plan.md) with proposed approaches, road map, and project timeline. 7 | 8 | ## Challenges Encountered 9 | 10 | The month of July was pretty smooth for me, because my focus was on research, experimentation, and writing. I anticipate encountering many more challenges once the implementation stage begins. 11 | 12 | ## Plan For the Upcoming Month 13 | 14 | I am currently on a break between grad school and a full-time job that is going to start in early September. Due to the way my obligations are set up, August will be a big implementation month for me with regards to grant work. On a high level, I plan to finish, or be close to finishing, the implementation of both FES priorities (accidentally overridden constants and functions, parameter validation). For more detailed plans, please refer to the [road map section](https://github.com/sproutleaf/pr05-fes/blob/main/project_plan.md) of my project plan. 15 | -------------------------------------------------------------------------------- /2024_NewBeginnings/monthly-reports/pr05_2024_July_report_Nahee_Kim.md: -------------------------------------------------------------------------------- 1 | # July Progress Report 2 | 3 | ## Project Title: Enhancing the p5.js Editor with CodeMirror 6 and React Functional Components 4 | 5 | ### Project Description 6 | Upgrade the CodeMirror component in the p5.js Editor from Version 5 to Version 6, implementing enhanced features for accessibility, mobile support, internationalization, and other editor improvements. This will also require refactoring related components from class-based to functional components using React. 7 | 8 | ### Execution Plan 9 | 1. **CodeMirror 5 to 6 Transition** 10 | - Identify and import necessary sub-packages under the @codemirror scope. 11 | - Refactor existing methods into transactions and dispatch them collectively. 12 | 2. **React Component Refactor** 13 | - Convert class-based React components to functional components. 14 | - Use tools like ChatGPT for initial translations, build and run the code to identify necessary corrections. 15 | 3. **TypeScript Conversion** 16 | - Convert JavaScript-based codebase to TypeScript for files that require immediate changes. 17 | - Understand variable and function definitions through TypeScript to improve development efficiency. 18 | 19 | ### Timeline 20 | **Month 1: Planning and Initial Setup** 21 | * **Week 1-2:** 22 | - Review the existing p5.js codebase. 23 | - Set up development environment. 24 | - Identify key components to be refactored and upgraded. 25 | - Start setting epics and adding tickets on Zenhub board 26 | * **Week 3-4:** 27 | - Begin the conversion of simple class components to functional components. 28 | - Start importing necessary sub-packages for CodeMirror 6. 29 | 30 | ## Progress for July 31 | 32 | ### Completed Tasks 33 | - Synced the personal forked repo with the most updated p5.js editor repo. 34 | - Met with the mentor Connie on July 5th, 2024. 35 | - Introduced ourselves to each other. 36 | - Set up the bi-weekly meeting schedule (Monday 8 PM EST). 37 | - Discussed scope, timeline, and conventions (synchronize prettier style with the original p5 editor branch). 38 | - Created a project plan document. 39 | 40 | ### Challenges Encountered 41 | - Initial synchronization of the forked repository took longer than expected due to merge conflicts and dependency updates. 42 | 43 | ### Plans for August 44 | - **Week 1-2:** 45 | - Continue conversion of simple class components to functional components. 46 | - Begin importing necessary sub-packages for CodeMirror 6. 47 | - Set up initial CodeMirror transactions. 48 | - **Week 3-4:** 49 | - Test and debug the refactored components. 50 | - Start the integration of CodeMirror 6 with the p5.js Editor. 51 | 52 | ### Note 53 | - I couldn't make significant progress in the last week of July due to personal reasons. -------------------------------------------------------------------------------- /2024_NewBeginnings/monthly-reports/pr05_2024_September_report_Claudine_Chen.md: -------------------------------------------------------------------------------- 1 | # August Monthly Report - for Simplifying the Workflow for Libraries, Tools, and Modes 2 | ## Claudine Chen 3 | 4 | ### Work Accomplished 5 | The Processing library template was completed to the point that we could invite feedback. 6 | This was done by announcement in the newsletter. 7 | 8 | Work was started on the adding contributions workflow. The existing workflow involves 9 | manual addition of new libraries to the data files of the repository 10 | `processing-contributions`. The new work refactors this repository. There are two main 11 | aspects to this work - converting the data store from the current configuration files 12 | to a consolidated yaml file, and setting up an automated workflow that creates the pull 13 | request with the new contribution added to the database file. 14 | 15 | The work accomplished this month on this workflow was 16 | 17 | 1. the creation of an initial version of the database yaml file 18 | 2. scripts that convert the data in the yaml file into the file formats needed for the 19 | contribution manager, and the website 20 | 3. an issue form, where new contributors input the url to their released properties file 21 | 4. a workflow triggered by the issue form, that retrieves the properties, edits the 22 | database file, and create a pull request. 23 | 24 | ### Challenges Encountered 25 | 26 | It was an interesting challenge, to submit a graphic to go along with the 27 | newsletter announcement. My initial attempts at manual graphic design were rather 28 | terrible. I'd like to think that the graphic I eventually submitted, coded in Processing, 29 | was a considerable improvement. 30 | 31 | In hindsight, I'd say a previous challenge was balancing work with documentation. 32 | This month, I allowed myself the space to write and sort out the brain, but I just 33 | wanted to highlight that it was a challenge previously. 34 | 35 | 36 | ### October Plans 37 | 38 | The plans in October are: 39 | 40 | 1. Finish work on the add contributions workflow. 41 | 2. Advertise the new library template more broadly, for instance in the discourse, 42 | discord for Processing, and writing an article. 43 | 3. Document the add contributions workflow 44 | 4. To refactor the Processing library wiki pages - these could be wiki pages for 45 | the template, for the processing repo, or on the website -------------------------------------------------------------------------------- /2024_NewBeginnings/monthly-reports/pr05_2024_September_report_Diya_Solanki.md: -------------------------------------------------------------------------------- 1 | # September Monthly Report: Develop a VSCode LSP Server Extension for Processing 2 | By **Diya Solanki** 3 | 4 | - [Project Repository: Processing Language Server Extension](https://github.com/diyaayay/processing-language-server-extension/) 5 | - [Working Branch: main](https://github.com/diyaayay/processing-language-server-extension/tree/main) 6 | - [Testing Branch: test](https://github.com/diyaayay/processing-language-server-extension/tree/test) 7 | 8 | ## Completed Tasks (what's done so far in September) 9 | 10 | - [x] [Test Branch Setup](https://github.com/diyaayay/processing-language-server-extension/tree/test) A test branch was created to install and run the extension on any platform, including the ability to run Processing sketches on Windows, along with LSP features. Clone the test branch to try out the Processing LSP Extension. 11 | - [x] [Project Setup Simplification](https://github.com/diyaayay/processing-language-server-extension/tree/test?tab=readme-ov-file#installation) Simplified the project setup process to use minimal commands, improving accessibility for users. 12 | - [x] [Project Dependencies release](https://github.com/diyaayay/processing-language-server-extension/releases/tag/v1.0) Downloads the Processing sketch-running dependencies on setting up the extension locally. 13 | - [x] [Deps download script](https://github.com/diyaayay/processing-language-server-extension/blob/test/dependency.bat) A script was created to run before `npm install`, automating the download and extraction of dependencies. 14 | - [x] [On-hover Description](https://github.com/diyaayay/processing-language-server-extension/tree/test?tab=readme-ov-file#on-hover-description) Hovering the mouse over a keyword now displays a pop-up with the meaning of the keyword. 15 | - [x] [Go-to Definition](https://github.com/diyaayay/processing-language-server-extension/tree/test?tab=readme-ov-file#go-to-definition) The "Go to Definition" feature allows users to navigate to the definition of a symbol using cmd+click or by right-clicking the variable name and selecting `Go To Definition`. 16 | - [x] [Go-to References](https://github.com/diyaayay/processing-language-server-extension/tree/test?tab=readme-ov-file#go-to-references) The references request is sent from the client to the server to resolve project-wide references for the symbol denoted by the given text document position. This feature finds all the references of a variable, class or a function used. 17 | Users can right-click or click on the `n` References link that appears over declarations. 18 | - [x] [Code Completion](https://github.com/diyaayay/processing-language-server-extension/tree/test?tab=readme-ov-file#code-completion) Context-aware suggestions are provided to speed up coding. 19 | - [x] `Running Processing Sketches Headless`: The `ctrl+shift+p` command or the `Run` button in the top right corner runs Processing sketch in the user's system. 20 | 21 | 22 | ## Challenges Encountered 23 | - **Diagnostics** for Processing sketches from Processing’s sketch validation logic is still a work in progress. 24 | - **Running Processing headless** without requiring the user to set paths or require some complex setup was the main challenge to make the version migration work everywhere. 25 | - **Dependency Management:** Handling external dependencies through symlinks and scripts proved tricky. Ensuring that the right libraries were accessible, while maintaining compatibility with different system environments, added complexity. 26 | - This required careful handling of directory structures, ensuring each symlink pointed to the correct target without causing confusion or overlap. 27 | - **Error Handling in Symlink Creation:** Error handling for symlink creation was important to ensure that if a symlink already existed or failed to be created, the system handled it gracefully without halting the entire setup process. 28 | - After setting up the script to download and unzip the dependencies, integrating them in the `sketchRunner.ts`, and testing them locally, I set up a Windows VM to clone the test branch and ensure that the extension is working on other machines. 29 | 30 | 31 | ## Plans for October 32 | 33 | - [ ] `Goal`: Bug Fixes in: 34 | - [ ] Code-completion 35 | - [x] Hover (no known bugs) 36 | - [x] Syntax highlighting (no known bugs) 37 | - [ ] `onReferences` 38 | - [ ] `onDefinition` 39 | - [ ] `...` 40 | 41 | - [ ] Enhance the UI for sketch/sketchbook and running the sketches. 42 | - [ ] Export the extension into a `.vsix` file and publish it to the [VSCode Market Place](https://marketplace.visualstudio.com/vscode). 43 | - [ ] Detailed documentation for further development of the project by new contributors. 44 | - [ ] Detailed documentation for installing and configuring the extension. -------------------------------------------------------------------------------- /2024_NewBeginnings/monthly-reports/pr05_2024_September_report_Dora_Do.md: -------------------------------------------------------------------------------- 1 | # September monthly report: Prototyping a collaborative code editor for Processing 2 | By Dora Do 3 | 4 | ## Project Overview 5 | 6 | This month focused on refining the collaborative editing functionality of our Electron-based code editor, designed for Processing sketches. We explored different real-time collaboration frameworks, worked on packaging the app for distribution, and continued improving the user interface. Notable progress was made in integrating YJS with CodeMirror for real-time collaboration and addressing the challenges of running processing-java within the app across different operating systems. 7 | 8 | ## Key Decisions and Progress 9 | 10 | We decided to use WebRTC for small groups (1-3 users) but identified its limitations in larger groups due to performance issues. Therefore, we are leaning towards WebSockets for text-based messaging due to their reliability and better support for scaling. We successfully integrated the YJS framework with the CodeMirror editor and tested it with WebSocket providers. The Radix UI component library was also integrated into the app to enhance the overall user interface and provide a consistent design system for future contributors. 11 | 12 | On the packaging front, we used `electron-builder` to package the app and have it running from the Applications folder. Some issues with paths required adjustments to the `package.json` and asset paths, but this was resolved, allowing for successful packaging. 13 | 14 | ## Challenges and Solutions 15 | 16 | - Scaling WebRTC: 17 | - We realized WebRTC could not handle larger groups effectively due to performance issues. We are now focused on WebSockets, which are more stable for our use case. 18 | - Handling initial state sync in collaborative sessions: 19 | - We faced a problem where new clients joining a collaborative sketch were not receiving the initial document state. The solution involved setting the entire document upon room creation, allowing new clients to receive the correct state. 20 | - Running Processing sketches in the packaged app: 21 | - Running the `processing-java` executable in the packaged app posed issues due to hardcoded paths for the Java library and JDK. The solution we implemented was a Settings popup where users can manually select the path to their Processing installation. This is a temporary workaround until more automated solutions, such as Stef's headless version of Processing, are available 22 | - Error handling when clients join non-existent sketches: 23 | - There was an issue with properly handling errors when clients try to join a sketch that doesn't exist. We're currently improving error handling to detect and notify users when they attempt to join an invalid sketch. 24 | 25 | ## Next Steps 26 | 27 | 1. **Further Testing**: We need to conduct more extensive tests on both macOS and Windows, especially ensuring that the `processing-java` executable works across platforms. 28 | 2. **Improve User Onboarding**: I plan to implement an onboarding flow that will guide users through setting up their Processing environment. This will include selecting their Processing installation path and verifying that their system is ready to run sketches. 29 | 3. **Enhance UI and UX**: Based on Ted’s feedback, we redesigned the side navigation and improved the sketch creation workflow. Further refinement is needed for a more intuitive user experience. 30 | 4. **Fixing Known Bugs**: Continue to refine error handling for clients joining invalid rooms and improve document state synchronization in collaborative sessions. 31 | 32 | ## Conclusion 33 | 34 | This month saw significant progress in real-time collaboration, UI refinement, and resolving packaging issues for app distribution. While there are still challenges, especially around running Processing sketches and scaling WebRTC, we've implemented viable solutions for the next phase of testing. With more rigorous testing planned, we're on track to deliver a stable prototype for broader feedback and iteration. 35 | -------------------------------------------------------------------------------- /2024_NewBeginnings/monthly-reports/pr05_2024_September_report_Miaoye_Que.md: -------------------------------------------------------------------------------- 1 | # September Monthly Report: Revamp the Friendly Error System (FES) in p5.js 2 | 3 | By Miaoye Que, mentored by Kenneth Lim and Dave Pagurek with support from Qianqian Ye. 4 | 5 | ## Work Completed 6 | 7 | ### Accidentally Overridden Constants and Functions 8 | 9 | To see all PRs and real-time progress for accidentally overriden constants and functions, check out the [master issue #7269](https://github.com/processing/p5.js/issues/7269). 10 | 11 | - [x] Started a new `sketch_verifier` file that will detect accidentally overriden constants and functions. 12 | - [x] Script can now retrieve user's code as a string and with the help of `Espree` (parser), identify user-defined functions and constants. 13 | 14 | ### Parameter Validation 15 | 16 | To see all PRs and real-time progress for parameter validation, check out the [master issue #7178](https://github.com/processing/p5.js/issues/7178). 17 | 18 | - [x] Parameter validation now validates against real p5 (i.e. `p5.Color`) and web API objects (i.e. `KeyboardEvent`). 19 | - [x] Updated `convert.js`, script that generates `parameterData.json` so that 1) we ignore false definitions and 2) deduplicate overloads with the same order and types. 20 | - [x] Implemented the new modular syntax and dependency injection pattern for parameter validation. 21 | - [x] Parameter validation now handles array-type arguments dynamically, i.e. identifies that an argument's type ends with `[]` and applies `z.array()` to object type. 22 | - [x] Instead of using `zod-validation-error` library, now prints error messages with custom logic catered towards beginners. 23 | - [x] Updated test file to cover all test cases from the old test file and then some. 24 | - [x] Added parameter validation support for paletteLerp, see [#6960](https://github.com/processing/p5.js/issues/6960). 25 | - [x] Some code cleanups now that the parameter validation is almost at completion. 26 | 27 | ## Challenges Encountered 28 | 29 | ### General 30 | 31 | - Again, I struggled with time management because I started a full-time job early September. I was working at a pretty erratic cadence. Fortunately, I'm only a little behind schedule so this was not a major concern. 32 | 33 | ### Accidentally Overridden Constants and Functions 34 | 35 | - Had trouble getting the user's code as a string and needed help from Ken and Dave. 36 | 37 | ### Parameter Validation 38 | 39 | - I don't think I faced challenges for parameter validation per se, but what I thought would be done swiftly turned out to require more of my care and attention, and follow-up issues kept emerging. For example, after I finished the initial implementation, we realized that the messages printed were not beginner-friendly because of how technical they were. So the approach I thought would save me time (leveraging on an existing library `zod-validation-error`) turned out to be inappropriate for the task, and custom logic was required after all. 40 | 41 | ## Remaining Tasks 42 | 43 | ### Accidentally Overridden Constants and Functions 44 | 45 | - [ ] Check if user-defined functions and variables have already been defined in `p5` and shouldn't be re-defined. 46 | - [ ] Generate friendly messages for re-definitions that shouldn't take place. 47 | - [ ] Write comprehensive testing for the feature. 48 | - [ ] Integrate it into the `dev-2.0` branch. 49 | 50 | ### Parameter Validation 51 | 52 | - [ ] Update friendly messages again if necessary. 53 | - [ ] Integrate it into the `dev-2.0` branch. 54 | 55 | ## October Plans 56 | 57 | - Wrap up the implementation, testing, and integration for both priorities. 58 | - Update documentation, wherever applicable. 59 | - Prepare for project wrap-up and presentation, i.e. interview with Yoon, the final group presentation. 60 | -------------------------------------------------------------------------------- /2024_NewBeginnings/monthly-reports/pr05_2024_September_report_Nahee_Kim.md: -------------------------------------------------------------------------------- 1 | # Editor Migration Progress Report - September 2024 2 | 3 | Throughout September, I've been working diligently to transition from the class-based React implementation using CodeMirror 5 to a more modern functional component approach with CodeMirror 6. This update aims to improve the editor's performance, maintainability, and align it with current best practices. 4 | 5 | ## 1. React Component Modernization 6 | 7 | - **Functional Component Conversion**: I've replaced the class-based structure with a functional component. This shift allows me to leverage React hooks, resulting in more concise and easier-to-understand code. 8 | 9 | - **State Management Overhaul**: By utilizing hooks like useState, useEffect, useRef, and useCallback, I've streamlined the state management process. This new approach provides better control over the component's lifecycle and state updates. 10 | 11 | - **Lifecycle Method Adaptation**: I've transitioned away from traditional lifecycle methods (such as componentDidMount and componentDidUpdate) to the more flexible useEffect hook. This change gives me finer-grained control over side effects and helps prevent some common bugs associated with class components. 12 | 13 | ## 2. CodeMirror 6 Integration 14 | 15 | - **Extension-Based Architecture**: CodeMirror 6 introduces a more modular, extension-driven system. I've adapted the codebase to this new paradigm, which allows for greater flexibility and easier customization of editor features. 16 | 17 | - **State and View Management**: I've implemented the new EditorState and EditorView concepts from CodeMirror 6. This gives me more granular control over the editor's behavior and rendering. 18 | 19 | - **Feature Reimplementation**: I've reestablished core functionalities like syntax highlighting, line numbers, and code folding using CodeMirror 6's extension system. This process required a deep dive into the new API but has resulted in a more robust implementation. 20 | 21 | ## 3. Editor Configuration and Customization 22 | 23 | - **Keymap Customization**: I've rebuilt the custom key bindings using CodeMirror 6's keymap extension. This includes shortcuts for actions like code formatting, find/replace operations, and indentation control. 24 | 25 | - **Prettier Integration**: I've updated the code formatting function to use Prettier's formatWithCursor method. This ensures that I maintain cursor position after formatting, which greatly improves the user experience when working with JavaScript, CSS, and HTML. 26 | 27 | - **Autocompletion Enhancements**: I've reimplemented the autocompletion system using a combination of Fuse.js for flexible matching and CodeMirror 6's autocompletion extension. This new setup provides more accurate and context-aware code suggestions. 28 | 29 | These customizations help maintain the familiar feel of the editor while leveraging the new capabilities of CodeMirror 6. 30 | 31 | ## 4. Runtime Error Visualization 32 | 33 | - **Error Parsing**: Using StackTrace.js, I now parse runtime errors to extract relevant information such as line numbers and error messages. 34 | 35 | - **Visual Error Highlighting**: Leveraging CodeMirror 6's Decoration API, I've implemented a system that visually highlights lines in the editor where runtime errors occur. This provides in-context feedback to users. 36 | 37 | - **Dynamic Update Mechanism**: I use CodeMirror 6's StateEffect system to manage these error decorations, ensuring that they update efficiently as the code changes or errors are resolved. 38 | 39 | This feature significantly improves the debugging process by providing immediate visual cues within the editing environment. 40 | 41 | ## 5. Challenges and Lessons Learned 42 | 43 | Throughout this migration, I've encountered and overcome several challenges: 44 | 45 | - Adapting to CodeMirror 6's more modular architecture required a shift in my thinking about how editor features are implemented and composed. 46 | - Ensuring feature parity with the previous implementation while leveraging new capabilities has been a balancing act. 47 | - Performance optimization, particularly for large files, has required careful consideration and testing. 48 | 49 | These challenges have provided valuable learning experiences and have ultimately led to a more robust and flexible editor implementation. 50 | 51 | ## 7. Next Steps 52 | 53 | As I move forward, my focus will be on: 54 | 55 | - Developing a custom React hook (useCodemirror) to encapsulate editor initialization logic, promoting code reuse and maintainability. 56 | - Conducting thorough performance testing and optimization, with a particular focus on handling large files and complex operations. 57 | - Further enhancing the error handling and debugging tools to provide an even better development experience. 58 | - Exploring additional CodeMirror 6 extensions that could bring new, valuable features to the editor. 59 | 60 | ## Conclusion 61 | 62 | The migration to a functional component using CodeMirror 6 represents a step forward for the editor. While there's still work to be done, the foundation I've laid this month sets us up for improved performance, better maintainability, and enhanced features in the future. 63 | 64 | Thank you for your ongoing support and collaboration on this project. 65 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # `pr05` Code of Conduct 2 | 3 | ## Who We Are 4 | 5 | The Processing Foundation is a nonprofit whose mission is to promote 6 | software literacy in the arts and visual literacy in the field of technology. 7 | 8 | Our efforts also aim to support people of all backgrounds and actively address 9 | systemic biases in art and tech spaces, in particular, those related to gender, 10 | race, class, and accessibility. 11 | 12 | This means that we: 13 | 14 | * Welcome contributors at any stage of their programming journey, from newcomers to professionals. 15 | * Do not assume knowledge or imply there are things that somebody should know. 16 | * Understand that people are the experts of their own experiences, and bring a variety of valid perspectives to the development of open source projects. 17 | * Know that contribution is not just limited to code, and can also include working on documentation, filing issues and bug reports, and other important forms of input. 18 | * Work to offer help and guidance when we are able to do so. 19 | 20 | ## Our Standards 21 | 22 | All grantees, mentors, advisors, and people involved in the `pr05` program agree to abide by the following code of conduct. 23 | 24 | ### Respect other people 25 | 26 | Treat other community members with respect and kindness. Examples of behavior that contributes to a positive environment for our community include: 27 | 28 | * Demonstrating empathy toward other people, and assuming best intentions; 29 | * Being mindful in how we approach and interact with others; 30 | * Being respectful of differing opinions, viewpoints, and experiences; 31 | * Listening in times of conflict, and communicating as best we can while acknowledging each other's feelings; 32 | * Giving and gracefully accepting constructive feedback; 33 | * Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience; 34 | * Making space for everyone to be heard. 35 | 36 | ### Be mindful of how you engage with others 37 | 38 | The following behavior will not be tolerated: 39 | 40 | * The use of sexualized or violent language or imagery; 41 | * Unwelcome sexual attention or advances of any kind; 42 | * Offensive comments related to race, class, gender identity and expression, 43 | neuro-type, ability, religion and culture, age, skill level, occupation, background, or political opinion; 44 | * Public or private harassment; 45 | * Publishing others' private information, such as a physical or email address, without their explicit permission; 46 | * Any other conduct which could reasonably be considered inappropriate in a professional setting. 47 | 48 | When in doubt, if it could make people uncomfortable, don't do it. 49 | 50 | ### Be open-minded 51 | 52 | We understand that technology changes all the time, and that contributors may bring new or different views based on their own experiences. Be open-minded when engaging with other people and their ideas, and embrace the new or unfamiliar as opportunities for positive change. 53 | 54 | ### Be considerate 55 | 56 | We focus on what is best not just for us as individuals, but for the health of the overall community. Be considerate of other people, and think about how your contributions will affect the community as a whole. 57 | 58 | 59 | ## Enforcement 60 | 61 | If you believe someone is violating the Code of Conduct, we ask that you report it by emailing safety@processing.org. Please include your name and a description of the incident, and we will get back to you as soon as possible. 62 | 63 | Sometimes, participants violating the Code of Conduct are unaware that their behavior is harmful, and an open conversation clears things up to move forward. However, if a participant continues with the behavior, the Processing Foundation team may take any action they deem appropriate, up to and including expulsion from all community spaces and identification of the participant as a harasser to other members or the general public. 64 | 65 | ## Attribution 66 | 67 | This Code of Conduct is adapted from the [Contributor Covenant version 2.1](https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1]); the [p5.js Code of Conduct](https://github.com/processing/p5.js/blob/main/CODE_OF_CONDUCT.md); and the [ml5.js Code of Conduct](https://github.com/ml5js/Code-of-Conduct). 68 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # `pr05` 2 | 3 | The Processing Foundation Software Development Grant or `pr05` (pronounced “pros”) is a grant and mentorship initiative by the Processing Foundation designed to support the professional growth of early to mid-career software developers through hands-on involvement in open-source projects. Participation in the program is entirely online. 4 | 5 | To see more about current and past program as well as any running open call, see the [`pr05` Wiki](https://github.com/processing/pr05-grant/wiki). 6 | --------------------------------------------------------------------------------