Add more examples for few-shot learning

pyproject.toml

@@ -14,6 +14,18 @@ anthropic = "^0.30.0"
 [tool.poetry.scripts]
 sum-diff = "sum_diff:main"
 
+[tool.poetry.group.dev.dependencies]
+pytest = "^8.3.2"
+
+[tool.pytest.ini_options]
+addopts = [
+    "--import-mode=importlib",
+]
+pythonpath = "."
+testpaths = [
+    "tests",
+]
+
 [build-system]
 requires = ["poetry-core"]
 build-backend = "poetry.core.masonry.api"

sum_diff/__init__.py

@@ -1,4 +1,5 @@
 import os
+from os import path
 import re
 import click
 import xml.etree.ElementTree as ET
@@ -12,6 +13,7 @@
     git_parent_branch,
     git_diff_from_parent,
 )
+from sum_diff.utils import parse_pr_example
 
 load_dotenv(".env")
 
@@ -91,41 +93,6 @@
 **IMPORTANT**:
 
 - Output should be in {lang}.
-
-## Example Output
-
-Here's an example of how your output might look:
-
-<pr_title>
-Add `UserAuthentication` class to improve login process (#123)
-</pr_title>
-
-<pr_description>
-This PR introduces a new `UserAuthentication` class to enhance the login process and improve overall
-security.
-
-Key changes:
-- Create `UserAuthentication` class in `auth/user_authentication.rb`
-- Implement password hashing using `bcrypt` gem
-- Update `User` model to utilize the new authentication class
-
-The `UserAuthentication` class encapsulates the login logic and password management, separating
-these concerns from the `User` model. This change improves code organization and makes it easier to
-maintain and extend authentication functionality in the future.
-
-Example usage of the new class:
-
-```ruby
-user_auth = UserAuthentication.new(user)
-if user_auth.authenticate(password)
-  # Proceed with login
-else
-  # Handle authentication failure
-end
-```
-
-This new implementation ensures that passwords are securely hashed and compared, reducing the risk of password-related vulnerabilities.
-</pr_description>
 """
 
 
@@ -139,19 +106,44 @@
     help="Choose the language for the output.",
 )
 def main(lang):
+    output_lang = "Japanese" if lang == "ja" else "English"
+
+    # Git operations
     current_branch = git_current_branch()
     parent_branch = git_parent_branch(current_branch)
     diff = git_diff_from_parent(parent_branch)
     # print(current_branch)
     # print(parent_branch)
     # print(diff)
 
+    # Read example outputs for few shots learning from the directory "examples/"
+    examples_dir = path.join(path.dirname(__file__), "examples")
+    examples = []
+
+    for filename in os.listdir(examples_dir):
+        if filename.endswith(".md"):
+            with open(path.join(examples_dir, filename)) as f:
+                examples.append(parse_pr_example(f.read()))
+
+    # print(examples)
+
+    # Construct the user prompt
+    user_prompt = USER_PROMPT.format(
+        branch_name=current_branch, diff=diff, lang=output_lang
+    ).strip()
+
+    for i, example in enumerate(examples):
+        user_prompt += f"\n\n## Example Output ({i+1})\n\n"
+        user_prompt += f"<pr_title>\n{example.title}\n</pr_title>\n\n"
+        user_prompt += f"<pr_description>\n{example.description}\n</pr_description>"
+
+    # print(user_prompt)
+
     client = anthropic.Anthropic(
         # defaults to os.environ.get("ANTHROPIC_API_KEY")
         api_key=ANTHROPIC_API_KEY,
     )
 
-    output_lang = "Japanese" if lang == "ja" else "English"
     message = client.messages.create(
         model="claude-3-5-sonnet-20240620",
         max_tokens=1024,

sum_diff/examples/001.md

@@ -0,0 +1,31 @@
+<!--
+This is the first example of pull request.
+-->
+
+# Add `UserAuthentication` class to improve login process (#123)
+
+This PR introduces a new `UserAuthentication` class to enhance the login process and improve overall
+security.
+
+Key changes:
+
+- Create `UserAuthentication` class in `auth/user_authentication.rb`
+- Implement password hashing using `bcrypt` gem
+- Update `User` model to utilize the new authentication class
+
+The `UserAuthentication` class encapsulates the login logic and password management, separating
+these concerns from the `User` model. This change improves code organization and makes it easier to
+maintain and extend authentication functionality in the future.
+
+Example usage of the new class:
+
+```ruby
+user_auth = UserAuthentication.new(user)
+if user_auth.authenticate(password)
+  # Proceed with login
+else
+  # Handle authentication failure
+end
+```
+
+This new implementation ensures that passwords are securely hashed and compared, reducing the risk of password-related vulnerabilities.

sum_diff/examples/002.md

@@ -0,0 +1,49 @@
+<!--
+Based on https://github.com/etcd-io/etcd/pull/14627
+-->
+
+# raft: support asynchronous storage writes
+
+This change adds opt-in support to perform local storage writes asynchronously, reducing interference and increasing batching of log appends and state machine applications.
+
+## Summary
+
+A new `AsyncStorageWrites` option allows the raft node to handle storage asynchronously using a message-passing interface instead of the default `Ready`/`Advance` call. This can reduce commit latency and increase throughput.
+
+When enabled, the `Ready.Message` slice includes `MsgStorageAppend` and `MsgStorageApply` messages, processed by `LocalAppendThread` and `LocalApplyThread`. Messages to the same target must be processed in order.
+
+## Design Considerations
+
+- No regression for users not using `AsyncStorageWrites`.
+- Asynchronous work uses message-passing, with symmetry between leaders and followers.
+- Snapshots can be applied asynchronously, making it easy for users.
+
+## Usage
+
+With `AsyncStorageWrites`, users still read from `Node.Ready()` but handle storage messages differently. The example loop below shows message routing and local storage operations:
+
+```go
+for {
+	select {
+	case <-s.Ticker:
+		n.Tick()
+	case rd := <-s.Node.Ready():
+		for _, m := range rd.Messages {
+			switch m.To {
+			case raft.LocalAppendThread:
+				toAppend <- m
+			case raft.LocalApplyThread:
+				toApply <- m
+			default:
+				sendOverNetwork(m)
+			}
+		}
+	case <-s.done:
+		return
+	}
+}
+```
+
+## Compatibility
+
+This change remains fully backward-compatible and has no cross-version compatibility issues. Nodes can mix synchronous and asynchronous writes without noticeable differences in cluster behavior.

sum_diff/examples/003.md

@@ -0,0 +1,67 @@
+<!--
+Based on https://github.com/facebook/react/pull/14853
+-->
+
+# await act(async () => ...)
+
+I hacked together an asynchronous version of `act(...)`, and it's kinda nice.
+
+You've seen the synchronous version:
+
+```javascript
+act(() => {
+  // updates and stuff
+});
+// make assertions
+```
+
+This still works, and gives the same warnings. But if you pass an async function:
+
+```javascript
+await act(async () => {
+  // updates and stuff
+});
+// expect commits and effects to be flushed
+// make assertions
+```
+
+Neat! I set it up so if you *don't* `await` the result from `act`, a warning gets triggered (with `setImmediate`) to do so. That makes it a bit harder to have rogue async `act()` calls in the ether.
+
+You can nest `act()` calls:
+
+```javascript
+await act(async () => {
+  // nest synchronous calls
+  act(() => {
+    // updates and such
+  });
+  // as before, updates and effects are flushed
+
+  // make assertions
+  await sleep(500); // or for a promise to resolve, or whatever
+  // more assertions maybe
+
+  // nest asynchronous calls too
+  await act(async () => {
+    // mutations and such
+    // more awaits
+    // and maybe an event or two
+  });
+  // more assertions
+});
+```
+
+I implemented a cheap form of unrolling safety, so if a previous `act()` gets closed before any subsequent `act()` calls, a warning gets triggered. This should prevent most interleaving attempts, and maintain a tree-like shape of `act()` blocks.
+
+**pros**
+
+- works with async/await, solves oss problems cleanly
+- the sync api is preserved
+- the warning is preserved
+- works with fake timers/fb
+
+**cons**
+
+- can't guarantee batching after the first await in an act block (this will get better when concurrent?)
+- less restrictive than the sync model, and starts to feel more opt-in than opt-out (eg- someone could just wrap their entire test with an `act()` call... which might be fine?)
+- exposes a secret api on react dom to implement it, dunno how you feel about that