Skip to content

fix: correct typos and formatting in documentation #74

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+58 −42
Open

fix: correct typos and formatting in documentation #74

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,7 @@ Both models were trained using our [harmony response format][harmony] and should
- **Full chain-of-thought:** Provides complete access to the model's reasoning process, facilitating easier debugging and greater trust in outputs. This information is not intended to be shown to end users.
- **Fine-tunable:** Fully customize models to your specific use case through parameter fine-tuning.
- **Agentic capabilities:** Use the models' native capabilities for function calling, [web browsing](#browser), [Python code execution](#python), and Structured Outputs.
- **Native MXFP4 quantization:** The models are trained with native MXFP4 precision for the MoE layer, allowing `gpt-oss-120b` to run on a single H100 GPU and `gpt-oss-20b` to run within 16GB of memory..
- **Native MXFP4 quantization:** The models are trained with native MXFP4 precision for the MoE layer, allowing `gpt-oss-120b` to run on a single H100 GPU and `gpt-oss-20b` to run within 16GB of memory.

### Inference examples

Expand Down Expand Up @@ -227,7 +227,7 @@ To perform inference you'll need to first convert the SafeTensor weights from Hu
python gpt_oss/metal/scripts/create-local-model.py -s <model_dir> -d <output_file>
```

Or downloaded the pre-converted weight:
Or download the pre-converted weight:

```shell
huggingface-cli download openai/gpt-oss-120b --include "metal/*" --local-dir gpt-oss-120b/metal/
Expand Down
6 changes: 3 additions & 3 deletions awesome-gpt-oss.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ This is a list of guides and resources to help you get started with the gpt-oss
- [Local](#local)
- [Server](#server)
- [Cloud](#cloud)
- [Examples / Tutorials](#examples--tutorials)
- [Examples & Tutorials](#examples--tutorials)
- [Tools](#tools)

## Inference
Expand Down Expand Up @@ -68,8 +68,8 @@ This is a list of guides and resources to help you get started with the gpt-oss

## Tools

- [Example `python` tool for gpt-oss](./gpt_oss/tools/python_docker/)
- [Example `browser` tool for gpt-oss](./gpt_oss/tools/simple_browser/)
- [`python` tool for gpt-oss](./gpt_oss/tools/python_docker/)
- [`browser` tool for gpt-oss](./gpt_oss/tools/simple_browser/)

## Contributing

Expand Down
90 changes: 53 additions & 37 deletions gpt_oss/tools/apply_patch.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,52 +1,63 @@
When requested to perform coding-related tasks, you MUST adhere to the following criteria when executing the task:
When requested to perform coding-related tasks, you **MUST** adhere to the following criteria when executing the task:

- Use `apply_patch` to edit files.
- If completing the user's task requires writing or modifying files:
- Your code and final answer should follow these _CODING GUIDELINES_:
- Avoid unneeded complexity in your solution. Minimize program size.
- Keep changes consistent with the style of the existing codebase. Changes should be minimal and focused on the task.
- NEVER add copyright or license headers unless specifically requested.
- Never implement function stubs. Provide complete working implementations.
* Use `apply_patch` to edit files.
* If completing the user's task requires writing or modifying files:

§ `apply_patch` Specification
* Your code and final answer should follow these *CODING GUIDELINES*:

* Avoid unneeded complexity in your solution. Minimize program size.
* Keep changes consistent with the style of the existing codebase. Changes should be minimal and focused on the task.
* **NEVER** add copyright or license headers unless specifically requested.
* Never implement function stubs. Provide complete working implementations.

---

## § `apply_patch` Specification

Your patch language is a stripped‑down, file‑oriented diff format designed to be easy to parse and safe to apply. You can think of it as a high‑level envelope:

*** Begin Patch
[ one or more file sections ]
*** End Patch
* A patch consists of a sequence of file operations, all bracketed between a `Begin` and `End` line.

* Each operation starts with one of three headers:

Within that envelope, you get a sequence of file operations.
You MUST include a header to specify the action you are taking.
Each operation starts with one of three headers:
* `*** Add File: <path>` — create a new file. Every following line is a `+` line (the initial contents).
* `*** Delete File: <path>` — remove an existing file. Nothing follows.
* `*** Update File: <path>` — patch an existing file in place (optionally with a rename).

*** Add File: <path> - create a new file. Every following line is a + line (the initial contents).
*** Delete File: <path> - remove an existing file. Nothing follows.
*** Update File: <path> - patch an existing file in place (optionally with a rename).
May be immediately followed by `*** Move to: <new path>` if you want to rename the file.

May be immediately followed by *** Move to: <new path> if you want to rename the file.
Then one or more “hunks”, each introduced by @@ (optionally followed by a hunk header).
Within a hunk each line starts with:
* Each update contains one or more “hunks”, each introduced by `@@` (optionally with a hunk header).

- for inserted text,
Within a hunk, each line starts with:

* for removed text, or
space ( ) for context.
At the end of a truncated hunk you can emit *** End of File.
* `+` for inserted text,
* `-` for removed text,
* (space) for context.

Patch := Begin { FileOp } End
Begin := "*** Begin Patch" NEWLINE
End := "*** End Patch" NEWLINE
FileOp := AddFile | DeleteFile | UpdateFile
AddFile := "*** Add File: " path NEWLINE { "+" line NEWLINE }
At the end of a truncated hunk you can emit `*** End of File`.

---

### Patch Grammar

<pre>
Patch := Begin { FileOp } End
Begin := "*** Begin Patch" NEWLINE
End := "*** End Patch" NEWLINE
FileOp := AddFile | DeleteFile | UpdateFile
AddFile := "*** Add File: " path NEWLINE { "+" line NEWLINE }
DeleteFile := "*** Delete File: " path NEWLINE
UpdateFile := "*** Update File: " path NEWLINE [ MoveTo ] { Hunk }
MoveTo := "*** Move to: " newPath NEWLINE
Hunk := "@@" [ header ] NEWLINE { HunkLine } [ "*** End of File" NEWLINE ]
HunkLine := (" " | "-" | "+") text NEWLINE
MoveTo := "*** Move to: " newPath NEWLINE
Hunk := "@@" [ header ] NEWLINE { HunkLine } [ "*** End of File" NEWLINE ]
HunkLine := (" " | "-" | "+") text NEWLINE
</pre>

A full patch can combine several operations:
---

## Example Patch

```diff
*** Begin Patch
*** Add File: hello.txt
+Hello world
Expand All @@ -57,8 +68,13 @@ A full patch can combine several operations:
+print("Hello, world!")
*** Delete File: obsolete.txt
*** End Patch
```

---

### Important Notes

It is important to remember:
* **You must include a header with your intended action** (Add/Delete/Update)
* **You must prefix new lines with `+`** even when creating a new file

- You must include a header with your intended action (Add/Delete/Update)
- You must prefix new lines with `+` even when creating a new file
---