Cider 2023 Lab Notebook

[Basant-khalil]

1. had to install rust manually on Windows due to configuration issues with visual studio code.

week of June 5th:
1.compile calyx and cider
3. Add colors via owo-colors to debugger printouts

• value inspection printouts
• calyx source tree (where)
• info statements
• breakpoint hits

4. extend the where or pc command with an optional boolean flag to print the Calyx calyx group tree when source info is present.

week of June 12th:
investigated dap-rs and trying to build version 0 of the DAP server.

June 27th: Building version 0 of the DAP server:

1. Server Startup/Attachment: The logic to start the DAP server was implemented, ensuring it could accept incoming TCP connections. The server was attached to the TCP connection.

2. TCP Connection Handling: The server was able to accept incoming TCP connections from clients. Requests sent by the client over the TCP connection were read. Basic error handling for connection errors and request parsing errors was implemented.

3. Request Handling: The server.run method was called to parse the incoming requests from the client. This allowed the server to identify the type of request and proceed accordingly.

4. Response Generation: Once the request was parsed, the server generated the appropriate response based on the request.

5. Writing the Response: After generating the response, the response was written to the TCP connection using the stream.write_all method.

Summary of Final Result

The final result is version 0 of the DAP server, which starts up, attaches to a TCP connection, and can read requests sent by the client.

The server successfully accepts incoming TCP connections, reads the requests using the send_request function, and writes the response to the TCP connection. The code also includes basic error handling for connection errors and request parsing errors.

Areas for Improvement

1. Enhancing error handling: While basic error handling is implemented in the code, it can be further improved to handle a wider range of errors and provide more informative error messages to the client.

2. Adding robustness: The code can be enhanced to handle edge cases, handle multiple clients concurrently, and gracefully recover from errors or unexpected disconnections.

3. Testing and validation: Thorough testing should be performed to ensure the server functions correctly under various scenarios, including handling different types of requests and responses.

Next Steps

1. Review the existing DAP server implementation and identify the necessary modifications and additions for supporting Calyx debugging features.
2. Develop VSCode extension to integrate with the DAP server and provide Calyx debugging capabilities.

\

First week of July

1. Installed the extension with Griffin's help after facing various issues relevant to symlink integration with wsl.
2. Encountered an issue where the extension was not being enabled due to a symlink pointing to itself, causing an infinite loop and resolved the issue by updating the symlink to point to the correct location, enabling the extension successfully locally.
3. Modified the adapter.rs code by updating the accept method to handle commands generically so that the adapter is agnostic to read/write operations for flexibility.

[Basant-khalil]

Debugging Extension Progress

I will be documenting the progress made in developing the "Cider DAP" debugging extension. The extension currently supports both single session and multi-session debugging using TCP. As of now, the main goal is to implement panel printing in the output to display the status of the debugging process when the extension starts attaching as well as other relevant messages.

Initial Challenges: Symlink Issues

At the beginning of the development process, I encountered challenges that prevented the extension to show up locally in the list of extensions. These issues were all caused by symlink configurations and I got them fixed with the help of Griffin. For that, the extension is currently visible and functional.

Current Progress

Now, when launching a Futil file in debug mode, the debugging output is efficiently directed to the "Cider DAP" output channel. This immediate display of debugging information allows users to stay updated on the ongoing debugging process. That means that the extension can attach and the program can recognize the existence of the extension and automatically launch the cider-dap in the output channels for debugging.

Next Steps

I am currently focusing on refining the panel printing functionality to provide useful logging information in the output that communicates the status of the debugging process starting with logging for when the extension attaches all the way until it closes like with single-session. Different logging might be used for single session vs multi session for the differences in their functionality. To do that, I have created an extension.js file that launches from the launch.json. In the extension.js file, I have created a function called startDebugging() that initiates the debugging process. Within this function, I log the status of the debugger being attached and debugging being started using the logToPanel() function. The logToPanel() function is responsible for printing messages both to the output channel and as information pop-ups in the panel which might have different logging for single-session vs multi-session.