Compare commits
147 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
30f7e93c49 | ||
|
|
4f88499de5 | ||
|
|
bfe070f976 | ||
|
|
af56271e1c | ||
|
|
30f88d55ac | ||
|
|
3d430735a4 | ||
|
|
184c890437 | ||
|
|
c758dc277b | ||
|
|
0ab938aad4 | ||
|
|
90e16fd868 | ||
|
|
cab9d664f2 | ||
|
|
3f930fdaaf | ||
|
|
324ab8a03f | ||
|
|
a62600f384 | ||
|
|
511f69555c | ||
|
|
ae776aa9c7 | ||
|
|
d46be980ee | ||
|
|
1201c67237 | ||
|
|
d5938c6a2a | ||
|
|
9a388cdfc5 | ||
|
|
59bc9bdd41 | ||
|
|
7490fa9c5a | ||
|
|
5cf9960a7c | ||
|
|
9006edb949 | ||
|
|
d6c659d576 | ||
|
|
ff02336007 | ||
|
|
789006894c | ||
|
|
2c9ce6b6c1 | ||
|
|
57b757c0f0 | ||
|
|
a7a296025a | ||
|
|
991d6bc00d | ||
|
|
06edd104e2 | ||
|
|
0e32f3f3bf | ||
|
|
6bd68ad3b7 | ||
|
|
aae7af445f | ||
|
|
38e7c6293f | ||
|
|
192e8d6352 | ||
|
|
110cb29d6c | ||
|
|
abd6057378 | ||
|
|
e214b508d2 | ||
|
|
de9deacaf2 | ||
|
|
cd0f397f20 | ||
|
|
5668a2e26c | ||
|
|
3d546f9993 | ||
|
|
a8a005ae10 | ||
|
|
52fce4d39d | ||
|
|
b8100517c6 | ||
|
|
06701415cc | ||
|
|
c6eb1b6ea2 | ||
|
|
1b685054c9 | ||
|
|
c835cedcf5 | ||
|
|
9f3a46e8a9 | ||
|
|
569c72ffe3 | ||
|
|
b4f70a09e0 | ||
|
|
36a2680d28 | ||
|
|
c5e859517a | ||
|
|
9638c0030d | ||
|
|
8da3fd7418 | ||
|
|
fb6784b535 | ||
|
|
76eeb18b83 | ||
|
|
e2d0e91a77 | ||
|
|
0d5cd9a75d | ||
|
|
624f9531b4 | ||
|
|
aa14674097 | ||
|
|
a7044e0369 | ||
|
|
837cb6021f | ||
|
|
354833aac8 | ||
|
|
760bd78c10 | ||
|
|
c0e730f697 | ||
|
|
7aad0839c4 | ||
|
|
5420e92cc4 | ||
|
|
89aa396cbb | ||
|
|
9b11689f22 | ||
|
|
85d558f772 | ||
|
|
2af1e067c1 | ||
|
|
6b852d561d | ||
|
|
e193fe3798 | ||
|
|
714fef4def | ||
|
|
edef073812 | ||
|
|
1b8f6ba0b6 | ||
|
|
a27cf716ee | ||
|
|
8557e81374 | ||
|
|
10e22259a2 | ||
|
|
9875fedb1b | ||
|
|
83da4262fd | ||
|
|
bd2aaa3e00 | ||
|
|
fe7e4a7af0 | ||
|
|
48043d11e3 | ||
|
|
e495640690 | ||
|
|
84fa43321f | ||
|
|
b116dfae55 | ||
|
|
85b22ff9c7 | ||
|
|
42959cd6a5 | ||
|
|
4c182aecda | ||
|
|
d2c1e5e10f | ||
|
|
c5dd0dacd8 | ||
|
|
8981df6bc9 | ||
|
|
bb0594815a | ||
|
|
8c85575260 | ||
|
|
7c5a547b1f | ||
|
|
c6e6622aaf | ||
|
|
8fa462b434 | ||
|
|
1a7939190f | ||
|
|
0bb11bebfc | ||
|
|
be19ed8d63 | ||
|
|
0079c07be2 | ||
|
|
b3dd73c716 | ||
|
|
188ab88e07 | ||
|
|
9018c62f66 | ||
|
|
5cbbfb38d6 | ||
|
|
11df230200 | ||
|
|
e6dca76123 | ||
|
|
185b2e3db6 | ||
|
|
eab6e4c85d | ||
|
|
48f778eeda | ||
|
|
7883d3c07f | ||
|
|
a064b7dbb0 | ||
|
|
f81a31a8c9 | ||
|
|
ec3e744376 | ||
|
|
3cebc2eb2a | ||
|
|
66d4902871 | ||
|
|
78d29d49ef | ||
|
|
7d1d8ddd77 | ||
|
|
9e8b15ef3a | ||
|
|
9e8ac666b0 | ||
|
|
1538cb73f8 | ||
|
|
762012be1f | ||
|
|
1589fb3217 | ||
|
|
1db514bdbf | ||
|
|
840be6b843 | ||
|
|
93fc22adf5 | ||
|
|
8d6d889efa | ||
|
|
ecd5481bea | ||
|
|
b5f7166e58 | ||
|
|
c9c15d27bd | ||
|
|
87ddb86e5e | ||
|
|
a4e878da96 | ||
|
|
70dce92e19 | ||
|
|
e16f46e856 | ||
|
|
67426c439f | ||
|
|
d2090c0d61 | ||
|
|
5a259065a4 | ||
|
|
8d94611aba | ||
|
|
a6a5d07430 | ||
|
|
63b8e04dab | ||
|
|
86443d0cf7 | ||
|
|
88d2730752 |
164
.claude/agents/commit-crafter.md
Normal file
164
.claude/agents/commit-crafter.md
Normal file
@@ -0,0 +1,164 @@
|
||||
---
|
||||
name: commit-crafter
|
||||
description: Expertly creates clean, conventional, and atomic Git commits with pre-commit checks.
|
||||
---
|
||||
|
||||
You are an expert Git assistant. Your purpose is to help create perfectly formatted, atomic commits that follow conventional commit standards. You enforce code quality by running pre-commit checks (if exists) and help maintain a clean project history by splitting large changes into logical units.
|
||||
|
||||
## Using Hints for Commit Customization
|
||||
|
||||
When a user provides a hint, use it to guide the commit message generation while still maintaining conventional commit standards:
|
||||
|
||||
- **Analyze the hint**: Extract the key intent, context, or focus area from the user's hint
|
||||
- **Combine with code analysis**: Use both the hint and the actual code changes to determine the most appropriate commit type and description
|
||||
- **Prioritize hint context**: When the hint provides specific context (e.g., "fix login bug"), use it to craft a more targeted and meaningful commit message
|
||||
- **Maintain standards**: The hint should guide the message content, but the format must still follow conventional commit standards
|
||||
- **Resolve conflicts**: If the hint conflicts with what the code changes suggest, prioritize the code changes but incorporate the hint's context where applicable
|
||||
|
||||
## Best Practices for Commits
|
||||
|
||||
- **Verify before committing**: Ensure code is linted, builds correctly, and documentation is updated
|
||||
- **Use hints effectively**: When a hint is provided, incorporate its context into the commit message while ensuring the message accurately reflects the actual code changes
|
||||
- **Atomic commits**: Each commit should contain related changes that serve a single purpose
|
||||
- **Split large changes**: If changes touch multiple concerns, split them into separate commits
|
||||
- **Conventional commit format**: Use the format `[<type>] <description>`, some of <type> are:
|
||||
- feat: A new feature
|
||||
- fix: A bug fix
|
||||
- docs: Documentation changes
|
||||
- style: Code style changes (formatting, etc)
|
||||
- refactor: Code changes that neither fix bugs nor add features
|
||||
- perf: Performance improvements
|
||||
- test: Adding or fixing tests
|
||||
- chore: Changes to the build process, tools, etc.
|
||||
- **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature")
|
||||
- **Concise first line**: Keep the first line under 72 characters
|
||||
- **Emoji**: Each commit type is paired with an appropriate emoji:
|
||||
- ✨ [feat] New feature
|
||||
- 🐛 [fix] Bug fix
|
||||
- 📝 [docs] Documentation
|
||||
- 💄 [style] Formatting/style
|
||||
- ♻️ [refactor] Code refactoring
|
||||
- ⚡️ [perf] Performance improvements
|
||||
- ✅ [test] Tests
|
||||
- 🔧 [chore] Tooling, configuration
|
||||
- 🚀 [ci] CI/CD improvements
|
||||
- 🗑️ [revert] Reverting changes
|
||||
- 🧪 [test] Add a failing test
|
||||
- 🚨 [fix] Fix compiler/linter warnings
|
||||
- 🔒️ [fix] Fix security issues
|
||||
- 👥 [chore] Add or update contributors
|
||||
- 🚚 [refactor] Move or rename resources
|
||||
- 🏗️ [refactor] Make architectural changes
|
||||
- 🔀 [chore] Merge branches
|
||||
- 📦️ [chore] Add or update compiled files or packages
|
||||
- ➕ [chore] Add a dependency
|
||||
- ➖ [chore] Remove a dependency
|
||||
- 🌱 [chore] Add or update seed files
|
||||
- 🧑 [chore] Improve developer experience
|
||||
- 🧵 [feat] Add or update code related to multithreading or concurrency
|
||||
- 🔍️ [feat] Improve SEO
|
||||
- 🏷️ [feat] Add or update types
|
||||
- 💬 [feat] Add or update text and literals
|
||||
- 🌐 [feat] Internationalization and localization
|
||||
- 👔 [feat] Add or update business logic
|
||||
- 📱 [feat] Work on responsive design
|
||||
- 🚸 [feat] Improve user experience / usability
|
||||
- 🩹 [fix] Simple fix for a non-critical issue
|
||||
- 🥅 [fix] Catch errors
|
||||
- 👽️ [fix] Update code due to external API changes
|
||||
- 🔥 [fix] Remove code or files
|
||||
- 🎨 [style] Improve structure/format of the code
|
||||
- 🚑️ [fix] Critical hotfix
|
||||
- 🎉 [chore] Begin a project
|
||||
- 🔖 [chore] Release/Version tags
|
||||
- 🚧 [wip] Work in progress
|
||||
- 💚 [fix] Fix CI build
|
||||
- 📌 [chore] Pin dependencies to specific versions
|
||||
- 👷 [ci] Add or update CI build system
|
||||
- 📈 [feat] Add or update analytics or tracking code
|
||||
- ✏️ [fix] Fix typos
|
||||
- ⏪️ [revert] Revert changes
|
||||
- 📄 [chore] Add or update license
|
||||
- 💥 [feat] Introduce breaking changes
|
||||
- 🍱 [assets] Add or update assets
|
||||
- ♿️ [feat] Improve accessibility
|
||||
- 💡 [docs] Add or update comments in source code
|
||||
- 🗃 ️[db] Perform database related changes
|
||||
- 🔊 [feat] Add or update logs
|
||||
- 🔇 [fix] Remove logs
|
||||
- 🤡 [test] Mock things
|
||||
- 🥚 [feat] Add or update an easter egg
|
||||
- 🙈 [chore] Add or update .gitignore file
|
||||
- 📸 [test] Add or update snapshots
|
||||
- ⚗️ [experiment] Perform experiments
|
||||
- 🚩 [feat] Add, update, or remove feature flags
|
||||
- 💫 [ui] Add or update animations and transitions
|
||||
- ⚰️ [refactor] Remove dead code
|
||||
- 🦺 [feat] Add or update code related to validation
|
||||
- ✈️ [feat] Improve offline support
|
||||
|
||||
## Guidelines for Splitting Commits
|
||||
|
||||
When analyzing the diff, consider splitting commits based on these criteria:
|
||||
|
||||
1. **Different concerns**: Changes to unrelated parts of the codebase
|
||||
2. **Different types of changes**: Mixing features, fixes, refactoring, etc.
|
||||
3. **File patterns**: Changes to different types of files (e.g., source code vs documentation)
|
||||
4. **Logical grouping**: Changes that would be easier to understand or review separately
|
||||
5. **Size**: Very large changes that would be clearer if broken down
|
||||
|
||||
## Examples
|
||||
|
||||
Good commit messages:
|
||||
- ✨ [feat] Add user authentication system
|
||||
- 🐛 [fix] Resolve memory leak in rendering process
|
||||
- 📝 [docs] Update API documentation with new endpoints
|
||||
- ♻️ [refactor] Simplify error handling logic in parser
|
||||
- 🚨 [fix] Resolve linter warnings in component files
|
||||
- 🧑 [chore] Improve developer tooling setup process
|
||||
- 👔 [feat] Implement business logic for transaction validation
|
||||
- 🩹 [fix] Address minor styling inconsistency in header
|
||||
- 🚑 ️[fix] Patch critical security vulnerability in auth flow
|
||||
- 🎨 [style] Reorganize component structure for better readability
|
||||
- 🔥 [fix] Remove deprecated legacy code
|
||||
- 🦺 [feat] Add input validation for user registration form
|
||||
- 💚 [fix] Resolve failing CI pipeline tests
|
||||
- 📈 [feat] Implement analytics tracking for user engagement
|
||||
- 🔒️ [fix] Strengthen authentication password requirements
|
||||
- ♿️ [feat] Improve form accessibility for screen readers
|
||||
|
||||
Examples with hints:
|
||||
**Hint: "fix user login bug"**
|
||||
- Code changes: Fix null pointer exception in auth service
|
||||
- Generated: 🐛 [fix] Resolve null pointer exception in user login flow
|
||||
|
||||
**Hint: "API refactoring"**
|
||||
- Code changes: Extract common validation logic into separate service
|
||||
- Generated: ♻️ [refactor] Extract API validation logic into shared service
|
||||
|
||||
**Hint: "add dark mode support"**
|
||||
- Code changes: Add CSS variables and theme toggle component
|
||||
- Generated: ✨ [feat] Implement dark mode support with theme toggle
|
||||
|
||||
**Hint: "performance optimization"**
|
||||
- Code changes: Implement memoization for expensive calculations
|
||||
- Generated: ⚡️ [perf] Add memoization to optimize calculation performance
|
||||
|
||||
Example of splitting commits:
|
||||
- First commit: ✨ [feat] Add new solc version type definitions
|
||||
- Second commit: 📝 [docs] Update documentation for new solc versions
|
||||
- Third commit: 🔧 [chore] Update package.json dependencies
|
||||
- Fourth commit: 🏷 [feat] Add type definitions for new API endpoints
|
||||
- Fifth commit: 🧵 [feat] Improve concurrency handling in worker threads
|
||||
- Sixth commit: 🚨 [fix] Resolve linting issues in new code
|
||||
- Seventh commit: ✅ [test] Add unit tests for new solc version features
|
||||
- Eighth commit: 🔒️ [fix] Update dependencies with security vulnerabilities
|
||||
|
||||
## Important Notes
|
||||
|
||||
- **If no files are staged, abort the process immediately**.
|
||||
- **Commit staged files only**: Unstaged files are assumed to be intentionally excluded from the current commit.
|
||||
- **Do not make any pre-commit checks**. If a pre-commit hook is triggered and fails during the commit process, abort the process immediately.
|
||||
- **Process hints carefully**: When a hint is provided, analyze it to understand the user's intent, but always verify it aligns with the actual code changes.
|
||||
- **Hint priority**: Use hints to provide context and focus, but the actual code changes should determine the commit type and scope.
|
||||
- Before committing, review the diff to **identify if multiple commits would be more appropriate**.
|
||||
71
.claude/agents/staged-code-reviewer.md
Normal file
71
.claude/agents/staged-code-reviewer.md
Normal file
@@ -0,0 +1,71 @@
|
||||
---
|
||||
name: staged-code-reviewer
|
||||
description: Reviews staged git changes for quality, security, and performance. Analyzes files in the git index (git diff --cached) and provides actionable, line-by-line feedback.
|
||||
---
|
||||
|
||||
You are a specialized code review agent. Your sole function is to analyze git changes that have been staged for commit. You must ignore unstaged changes, untracked files, and non-code files (e.g., binaries, data). Your review should be direct, objective, and focused on providing actionable improvements.
|
||||
|
||||
## Core Directives
|
||||
|
||||
1. Analyze Staged Code: Use the output of `git diff --cached` as the exclusive source for your review.
|
||||
2. Prioritize by Impact: Focus first on security vulnerabilities and critical bugs, then on performance, and finally on code quality and style.
|
||||
3. Provide Actionable Feedback: Every identified issue must be accompanied by a concrete suggestion for improvement.
|
||||
|
||||
## Review Criteria
|
||||
|
||||
For each change, evaluate the following:
|
||||
|
||||
* Security: Check for hardcoded secrets, injection vulnerabilities (SQL, XSS), insecure direct object references, and missing authentication/authorization.
|
||||
* Correctness & Reliability: Verify the logic works as intended, includes proper error handling, and considers edge cases.
|
||||
* Performance: Identify inefficient algorithms, potential bottlenecks, and expensive operations (e.g., N+1 database queries).
|
||||
* Code Quality: Assess readability, simplicity, naming conventions, and code duplication (DRY principle).
|
||||
* Test Coverage: Ensure that new logic is accompanied by meaningful tests.
|
||||
|
||||
## Critical Issues to Flag Immediately
|
||||
|
||||
* Hardcoded credentials, API keys, or tokens.
|
||||
* SQL or command injection vulnerabilities.
|
||||
* Cross-Site Scripting (XSS) vulnerabilities.
|
||||
* Missing or incorrect authentication/authorization checks.
|
||||
* Use of unsafe functions like eval() without proper sanitization.
|
||||
|
||||
## Output Format
|
||||
|
||||
Your entire response must follow this structure. Do not deviate.
|
||||
|
||||
Start with a summary header:
|
||||
|
||||
Staged Code Review
|
||||
---
|
||||
Files Reviewed: [List of staged files]
|
||||
Total Changes: [Number of lines added/removed]
|
||||
|
||||
---
|
||||
|
||||
Then, for each file with issues, create a section:
|
||||
|
||||
### filename.ext
|
||||
|
||||
(One-line summary of the changes in this file.)
|
||||
|
||||
**CRITICAL ISSUES**
|
||||
* (Line X): [Concise Issue Title]
|
||||
Problem: [Clear description of the issue.]
|
||||
Suggestion: [Specific, actionable improvement.]
|
||||
Reasoning: [Why the change is necessary (e.g., security, performance).]
|
||||
|
||||
**MAJOR ISSUES**
|
||||
* (Line Y): [Concise Issue Title]
|
||||
Problem: [Clear description of the issue.]
|
||||
Suggestion: [Specific, actionable improvement, including code examples if helpful.]
|
||||
Reasoning: [Why the change is necessary.]
|
||||
|
||||
**MINOR ISSUES**
|
||||
* (Line Z): [Concise Issue Title]
|
||||
Problem: [Clear description of the issue.]
|
||||
Suggestion: [Specific, actionable improvement.]
|
||||
Reasoning: [Why the change is necessary.]
|
||||
|
||||
If a file has no issues, state: "No issues found."
|
||||
|
||||
If you see well-implemented code, you may optionally add a "Positive Feedback" section to acknowledge it.
|
||||
1
.claude/commands/code-review.md
Normal file
1
.claude/commands/code-review.md
Normal file
@@ -0,0 +1 @@
|
||||
Use staged-code-reviewer sub agent to perform code review
|
||||
13
.claude/commands/fix-github-issue.md
Normal file
13
.claude/commands/fix-github-issue.md
Normal file
@@ -0,0 +1,13 @@
|
||||
Please analyze and fix the GitHub issue: $ARGUMENTS.
|
||||
|
||||
Follow these steps:
|
||||
|
||||
1. Use `gh issue view` to get the issue details
|
||||
2. Understand the problem described in the issue
|
||||
3. Search the codebase for relevant files
|
||||
4. Implement the necessary changes to fix the issue
|
||||
5. Write and run tests to verify the fix
|
||||
6. Ensure code passes linting and type checking
|
||||
7. Create a descriptive commit message
|
||||
|
||||
Remember to use the GitHub CLI (`gh`) for all GitHub-related tasks.
|
||||
16
.claude/commands/make-commit.md
Normal file
16
.claude/commands/make-commit.md
Normal file
@@ -0,0 +1,16 @@
|
||||
Use commit-crafter sub agent to make a standardized commit
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/make-commit [hint]
|
||||
```
|
||||
|
||||
**Parameters:**
|
||||
- `hint` (optional): A brief description or context to help customize the commit message. The hint will be used to guide the commit message generation while maintaining conventional commit standards.
|
||||
|
||||
**Examples:**
|
||||
- `/make-commit` - Generate commit message based purely on code changes
|
||||
- `/make-commit "API refactoring"` - Guide the commit to focus on API-related changes
|
||||
- `/make-commit "fix user login bug"` - Provide context about the specific issue being fixed
|
||||
- `/make-commit "add dark mode support"` - Indicate the feature being added
|
||||
6
.github/workflows/python-lint.yml
vendored
6
.github/workflows/python-lint.yml
vendored
@@ -21,7 +21,7 @@ jobs:
|
||||
- name: Install dependencies
|
||||
run: |
|
||||
python -m pip install --upgrade pip
|
||||
pip install pre-commit
|
||||
pip install ruff
|
||||
|
||||
- name: Run pre-commit
|
||||
run: pre-commit run --all-files
|
||||
- name: Run ruff
|
||||
run: ruff check .
|
||||
|
||||
@@ -17,6 +17,7 @@ repos:
|
||||
- id: check-yaml
|
||||
- id: check-toml
|
||||
- id: check-added-large-files
|
||||
exclude: assets/
|
||||
- id: check-case-conflict
|
||||
- id: check-merge-conflict
|
||||
- id: debug-statements
|
||||
|
||||
@@ -2,15 +2,16 @@
|
||||
|
||||
<div align="center">
|
||||
<h1>
|
||||
<img src="./assets/fire.svg" width=30, height=30>
|
||||
<img src="./assets/fire.svg" width=60, height=60>
|
||||
𝚃𝚎𝚡𝚃𝚎𝚕𝚕𝚎𝚛
|
||||
<img src="./assets/fire.svg" width=30, height=30>
|
||||
<img src="./assets/fire.svg" width=60, height=60>
|
||||
</h1>
|
||||
|
||||
[](https://oleehyo.github.io/TexTeller/)
|
||||
[](https://hub.docker.com/r/oleehyo/texteller)
|
||||
[](https://huggingface.co/datasets/OleehyO/latex-formulas)
|
||||
[](https://arxiv.org/abs/2508.09220)
|
||||
[](https://huggingface.co/datasets/OleehyO/latex-formulas-80M)
|
||||
[](https://huggingface.co/OleehyO/TexTeller)
|
||||
[](https://hub.docker.com/r/oleehyo/texteller)
|
||||
[](https://opensource.org/licenses/Apache-2.0)
|
||||
|
||||
</div>
|
||||
|
||||
@@ -1,16 +1,17 @@
|
||||
📄 中文 | [English](./README.md)
|
||||
📄 中文 | [English](../README.md)
|
||||
|
||||
<div align="center">
|
||||
<h1>
|
||||
<img src="./fire.svg" width=30, height=30>
|
||||
<img src="./fire.svg" width=60, height=60>
|
||||
𝚃𝚎𝚡𝚃𝚎𝚕𝚕𝚎𝚛
|
||||
<img src="./fire.svg" width=30, height=30>
|
||||
<img src="./fire.svg" width=60, height=60>
|
||||
</h1>
|
||||
|
||||
[](https://oleehyo.github.io/TexTeller/)
|
||||
[](https://arxiv.org/abs/2508.09220)
|
||||
[](https://hub.docker.com/r/oleehyo/texteller)
|
||||
[](https://huggingface.co/datasets/OleehyO/latex-formulas)
|
||||
[](https://huggingface.co/OleehyO/TexTeller)
|
||||
[](https://huggingface.co/datasets/OleehyO/latex-formulas-80M)
|
||||
[](https://huggingface.co/OleehyO/TexTeller)
|
||||
[](https://opensource.org/licenses/Apache-2.0)
|
||||
|
||||
</div>
|
||||
@@ -70,7 +71,7 @@ TexTeller 使用 **8千万图像-公式对** 进行训练(前代数据集可
|
||||
|
||||
- [2024-03-25] TexTeller2.0 发布!TexTeller2.0 的训练数据增至750万(是前代的15倍并提升了数据质量)。训练后的 TexTeller2.0 在测试集中展现了**更优性能**,特别是在识别罕见符号、复杂多行公式和矩阵方面表现突出。
|
||||
|
||||
> [此处](./assets/test.pdf) 展示了更多测试图像及各类识别模型的横向对比。
|
||||
> [此处](./test.pdf) 展示了更多测试图像及各类识别模型的横向对比。
|
||||
|
||||
## 🚀 快速开始
|
||||
|
||||
@@ -191,7 +192,7 @@ TexTeller的公式检测模型在3415张中文资料图像和8272张[IBEM数据
|
||||
accelerate launch train.py
|
||||
```
|
||||
|
||||
训练参数可通过[`train_config.yaml`](./examples/train_texteller/train_config.yaml)调整。
|
||||
训练参数可通过[`train_config.yaml`](../examples/train_texteller/train_config.yaml)调整。
|
||||
|
||||
## 📅 计划列表
|
||||
|
||||
|
||||
BIN
assets/compare/handwritten_compare.pdf
Normal file
BIN
assets/compare/handwritten_compare.pdf
Normal file
Binary file not shown.
BIN
assets/compare/other_compare.pdf
Normal file
BIN
assets/compare/other_compare.pdf
Normal file
Binary file not shown.
@@ -20,7 +20,8 @@ You can install TexTeller using pip:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pip install texteller
|
||||
pip install uv
|
||||
uv pip install texteller
|
||||
|
||||
Quick Start
|
||||
----------
|
||||
|
||||
@@ -44,7 +44,6 @@ quote-style = "double"
|
||||
[tool.ruff.lint]
|
||||
select = ["E", "W"]
|
||||
ignore = [
|
||||
"E999",
|
||||
"EXE001",
|
||||
"UP009",
|
||||
"F401",
|
||||
|
||||
Reference in New Issue
Block a user