scitex 2.13.0__py3-none-any.whl → 2.15.1__py3-none-any.whl

scitex/scholar/docs/to_claude/guidelines/programming_common/IMPORTANT-cleanliness.md

@@ -1,18 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-06-07 02:32:37
-!-- Author: ywatanabe
-!-- File: /ssh:ywatanabe@sp:/home/ywatanabe/.claude/to_claude/guidelines/programming_common/IMPORTANT-cleanliness.md
-!-- --- -->
-
-
-## Code Organization
-- src and tests: no mngs dependency
-- src, tests, and examples: 
-  - strictly mirror structure to link each other
-  - Understand different roles
-- Use .playground for temporal testing
-- Relocate valuable .playground files to permanent locations
-- Remove or hide obsolete, dirty, misleading files
-- Keep production-ready codebase for publishing anytime
-
-<!-- EOF -->

scitex/scholar/docs/to_claude/guidelines/programming_common/IMPORTANT-documentation-performance-claims.md

@@ -1,163 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-06-06 09:05:00
-!-- Author: ywatanabe
-!-- File: /home/ywatanabe/.claude/to_claude/guidelines/programming_common/IMPORTANT-documentation-performance-claims.md
-!-- --- -->
-
-# Performance Claims in Documentation Guidelines
-
-## Core Principle
-**NEVER include unverified performance claims in source documentation.**
-Performance numbers become outdated, environment-dependent, and damage credibility when wrong.
-
-## Documentation Hierarchy for Performance Claims
-
-### 1. README/Source Documentation: Functionality Only
-- **DO**: Describe what the code does and how to use it
-- **DO**: Explain architectural decisions that enable performance
-- **DON'T**: Include specific numbers (e.g., "100x faster", "0.5ms latency")
-- **DON'T**: Make comparative claims without current verification
-
-**Good Example:**
-```markdown
-## Performance
-Designed for GPU acceleration with vectorized operations processing 
-all operations simultaneously. See `examples/benchmarks/` for 
-performance comparisons in your environment.
-```
-
-**Bad Example:**
-```markdown
-## Performance
-| Implementation | Time (ms) | Speedup |
-|---------------|-----------|---------|
-| Legacy        | 1000      | 1.0x    |
-| Our Solution  | 10        | 100x    |
-```
-
-### 2. Examples/Benchmarks: Measurement Scripts
-- **DO**: Provide runnable comparison scripts
-- **DO**: Show users how to measure performance
-- **DO**: Include comparison with reference implementations
-- **DO**: Document measurement methodology
-
-**Structure:**
-```
-examples/
-├── benchmarks/
-│   ├── performance_comparison.py
-│   ├── memory_usage_analysis.py
-│   └── README.md  # Explains how to run and interpret
-```
-
-### 3. Tests: Correctness & Regression Only
-- **DO**: Test accuracy against reference implementations
-- **DO**: Include basic regression tests (relative performance)
-- **DON'T**: Test absolute performance numbers
-- **DON'T**: Fail tests based on environment-dependent timing
-
-## Language-Specific Guidelines
-
-### Python
-```python
-# Good: Architecture description
-class VectorizedProcessor:
-    """
-    Processes all items simultaneously using vectorized operations
-    for improved performance over sequential processing.
-    """
-
-# Bad: Specific claims
-class VectorizedProcessor:
-    """
-    100x faster than sequential processing (measured on RTX 4090).
-    """
-```
-
-### Documentation Comments
-```python
-def optimized_algorithm(data):
-    """
-    Optimized implementation using parallel processing.
-    
-    See examples/benchmarks/algorithm_comparison.py for 
-    performance analysis against standard implementations.
-    """
-```
-
-## When Performance Claims Are Acceptable
-
-### 1. Big-O Complexity
-```markdown
-## Complexity
-- Time: O(n log n) vs O(n²) for naive implementation
-- Space: O(1) additional memory
-```
-
-### 2. Algorithmic Improvements
-```markdown
-## Algorithm
-Uses XYZ algorithm which provides theoretical speedup over 
-ABC algorithm for large datasets. See [paper reference].
-```
-
-### 3. Qualified Statements
-```markdown
-## Design Goals
-Designed to minimize memory allocations and leverage GPU 
-parallelization for compute-intensive workloads.
-```
-
-## Migration Strategy for Existing Claims
-
-### Step 1: Audit Current Documentation
-```bash
-# Find performance claims
-grep -r -i "faster\|speedup\|performance\|benchmark" docs/ README.md
-```
-
-### Step 2: Move Numbers to Examples
-1. Create `examples/benchmarks/` directory
-2. Move specific claims to runnable scripts
-3. Update documentation to reference examples
-
-### Step 3: Rewrite Claims
-- "100x faster" → "designed for high performance"
-- "0.5ms latency" → "optimized for low latency"
-- "Uses 50% less memory" → "memory-efficient implementation"
-
-## Anti-Patterns to Avoid
-
-### ❌ Outdated Benchmarks
-```markdown
-# Benchmarked on Python 3.6, NumPy 1.14 (2018)
-```
-
-### ❌ Hardware-Specific Claims
-```markdown
-# 50x speedup on RTX 4090 with CUDA 11.8
-```
-
-### ❌ Version-Specific Numbers
-```markdown
-# 20% faster than v1.2.3
-```
-
-### ❌ Unqualified Comparisons
-```markdown
-# Fastest JSON parser available
-```
-
-## Benefits of This Approach
-
-1. **Credibility**: Documentation stays accurate over time
-2. **Flexibility**: Users measure in their specific environment
-3. **Education**: Examples teach users how to benchmark
-4. **Maintenance**: No need to update numbers constantly
-5. **Honesty**: Clear about what's verified vs claimed
-
-## Your Understanding Check
-Did you understand the guideline? If yes, please say:
-`CLAUDE UNDERSTOOD: <THIS FILE PATH HERE>`
-
-<!-- EOF -->

scitex/scholar/docs/to_claude/guidelines/programming_common/IMPORTANT-general.md

@@ -1,156 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-05-25 23:21:35
-!-- Author: ywatanabe
-!-- File: /ssh:sp:/home/ywatanabe/.claude/to_claude/guidelines/programming_common/general.md
-!-- --- -->
-
-
-## General Programming Rules
-- **Focus on code clarity and maintainability**
-  - Do Not Repeat Yourself (DRY principle)
-  - Use symbolic links wisely, especially for large data to keep clear organization and easy navigation
-  - Prepare `./scripts/utils/<versatile_func.py>` for versatile and reusable code
-  - If versatile code is applicable beyond projects, implement in the `scitex` package
-  - Avoid unnecessary comments as they can be disruptive
-  - Return only the updated code without comments
-  - Code should be self-explanatory; variable, function, and class names are crucial
-  - Comments can be distracting if the code is properly written
-
-- **Add executable permissions**
-  - Ensure to add `chmod +x /path/to/script.ext`
-  - `ext` will be in:
-    - `py`, `el`, `sh`, and so on
-
-- **Avoid 1-letter variable names**
-  - They make searching challenging
-  - For example, rename variable x to xx for better readability and searchability
-
-- **Commenting style**
-  - Subjects of comments should be "this file/code/function" implicitly
-  - Verbs should be in singular form (e.g., "# Computes ..." instead of "# Compute ...")
-
-- **Documentation**
-  - Always include docstrings with example usage
-  - Follow language-specific docstring format standards
-
-- **Imports and Dependencies**
-  - Keep importing packages MECE (Mutually Exclusive and Collectively Exhaustive)
-  - Remove unnecessary packages and add necessary ones
-
-- **Code Structure**
-  - Use modular approaches for reusability, readability, maintainability, and scalability
-  - Split functions into subroutines or meaningful chunks whenever possible
-
-- **PATH Conventions**
-  - Use relative paths from the project root
-  - Relative paths should start with dots, like "./relative/example.py" or "../relative/example.txt"
-  - All scripts are assumed to be executed from the project root (e.g., ./scripts/example.sh)
-
-- **Code Block Indicators**
-  - Use appropriate code block indicators:
-  ```python
-  # Python example
-  ```
-  ```shell
-  # Shell example
-  ```
-  ```elisp
-  ;; Elisp example
-  ```
-  ``` pseudo-code
-    # Pseudo-code
-  ```
-  ``` plaintext
-  Plain text
-    ```
-  ``` markdown
-  Markdown Contents
-  ```
-
-- **String Formatting**
-  - Split strings into shorter lines
-  - For example, with f-string concatenation with parentheses in Python:
-  ```python
-  # Good
-  error_msg = (
-      f"Failed to parse JSON response: {error}\n"
-      f"Prompt: {self._ai_prompt}\n"
-      f"Generated command: {commands}\n"
-      f"Response: {response_text}"
-  )
-  
-  # Not Good
-  error_msg = f"Failed to parse JSON response: {error}\nPrompt: {self._ai_prompt}\nGenerated command: {commands}\nResponse: {response_text}"
-  ```
-
-- **Headers and Footers**
-  - Do not change headers (e.g., time stamp, file name, authors) and footers (e.g., # EOF)
-
-- **Indentation**
-  - Pay attention to indentation
-  - Code will be copied/pasted as is
-
-- **Org Report**
-  - When asked, prepare report in `.org` file under `./reports` directory
-  - Also, convert to PDF
-
-- **README.md**
-  - Include README.md in ALL directories
-
-  - Add figures, diagrams (using mermaid):
-    - Visual information is much better than thousands of text
-    - Place images under `./docs/images/`
-    - Width would be around 400; but adjust by yourself
-
-  - README.md files must be concise as much as possible
-    - DO NOT INCLUDE:
-      - Overview
-      - Features
-
-  - THE CONTENTS OF README.md ARE:
-
-    - Title and one-line explanation
-      ```markdown
-      # TITLE
-      This repository ...
-      ```
-
-    - Installation
-      - (First, prepare `./docs/installation.md`.)
-      ```
-      ## Installation
-      Installation guide is available at [`./docs/installation.md`](./docs/installation.md)
-      ```
-    - Quick Start
-      e.g.,
-      ```markdown
-      ## Quick Start
-      \`\`\` python
-      import xxx
-      ...
-      \`\`\`
-      ```
-
-    - Details
-      - Instead of writing all details in README.md, prepare dedicated markdown files as `./docs/*.md`
-      - Just add link to the detailed markdown files.
-      ```markdown
-      ## Details
-      - xxx [`./docs/details/xxx.md`]
-      - yyy [`./docs/details/yyy.md`]
-      ```
-
-    - Contact
-      ```markdown
-      ## Contact
-      Yusuke Watanabe (ywatanabe@alumni.u-tokyo.ac.jp)
-      ```
-
-  - Use tables if applicable
-
-
-## Your Understanding Check
-Did you understand the guideline? If yes, please say:
-`CLAUDE UNDERSTOOD: <THIS FILE PATH HERE>`
-
-<!-- EOF -->

scitex/scholar/docs/to_claude/guidelines/programming_common/IMPORTANT-refactoring.md

@@ -1,32 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-06-01 00:00:28
-!-- Author: ywatanabe
-!-- File: /home/ywatanabe/.dotfiles/.claude/to_claude/guidelines/programming_common/IMPORTANT-refactoring.md
-!-- --- -->
-
-## Refactoring Rules
-- During development, do not change names of files, variables, functions, and so on
-- Refactoring will be separately requested
-- Work in `feature/refactoring`
-
-## Renaming
-- Use `./docs/to_claude/bin/rename.sh`
-
-## Refactoring Workflows
-1. Commit the current status with appropriate chunks and comments
-2. If `feature/refactor` already exits, determine if the current refactoring is in the step or just it is obsolete, already merged branch. In the latter case, please delete the existing `feature/refactor` branch to work on clean environment.
-3. If current branch is not `feature/refactor`, create and switch to a new branch called `feature/refactor`.
-4. Please try the followings as long as they will improve simplicity, readability, maintainability, while keeping original functionalities.
-   - Prioritize incremental refactoring, starting with smaller, manageable changes that can be tested in isolation."
-   - Re-organize project structure, standardize names of directories, files, variables, functions, classes/ and so on, move obsolete files under `.old` directory (e.g., `/path/to/obsolete/file.ext` -> `/path/to/obsolete/.old/file.ext`).
-5. After refactoring, ensure functionalities are not changed by running tests
-6. Once these steps are successfully completed, `git merge` the `feature/refactor` branch into the original branch.
-
-## Useful Tools
-See `~/.claude/bin`
-
-## Your Understanding Check
-Did you understand the guideline? If yes, please say:
-`CLAUDE UNDERSTOOD: <THIS FILE PATH HERE>`
-
-<!-- EOF -->

scitex/scholar/docs/to_claude/guidelines/programming_common/IMPORTANT-regression-prevention.md

@@ -1,14 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-06-07 02:32:20
-!-- Author: ywatanabe
-!-- File: /ssh:ywatanabe@sp:/home/ywatanabe/.claude/to_claude/guidelines/programming_common/IMPORTANT-regression-prevention.md
-!-- --- -->
-
-## Regression Prevention
-- Check for regressions after any implementation changes
-- Use test codes and example codes for validation
-  - ./tests/run_tests.sh
-  - ./examples/run_examples.sh
-- Maintain dedicated testing attitude
-
-<!-- EOF -->

scitex/scholar/docs/to_claude/guidelines/programming_common/IMPORTANT-slurm.md

@@ -1,73 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-06-14 06:50:01
-!-- Author: ywatanabe
-!-- File: /home/ywatanabe/.dotfiles/.claude/to_claude/guidelines/programming_common/IMPORTANT-slurm.md
-!-- --- -->
-
-# SLURM Utilities
-
-Simple SLURM workflow for persistent GPU nodes.
-
-## `module load`
-In spartan HPC, module load may be required.
-
-``` bash
-module load \
-    GCCcore/11.3.0 \
-    Python/3.10.4 \
-    Tkinter/3.10.4 \
-    OpenSSL/1.1 \
-    Apptainer/1.3.3 \
-    bzip2 \
-    slurm/latest \
-    GLib/2.72.1 \
-    GTK3/3.24.33 \
-    Gdk-Pixbuf/2.42.8 \
-    nodejs/18.17.1
-    # texlive/20230313
-```
-
-## Quick Start
-
-1. Request persistent node:
-```bash
-sbatch request.sh
-```
-
-2. Run commands on allocated node:
-```bash
-srun.sh python train.py
-srun.sh script.py
-srun.sh nvidia-smi
-```
-
-3. Login to node directly:
-```bash
-./login.sh
-```
-
-## Files
-
-- `request.sh` - Requests 4-GPU node for 7 days, saves node info to slurm-persistent.txt
-- `run.sh` - Runs commands on allocated node via srun
-- `login.sh` - SSH login to allocated node
-
-## Python Command Processing
-
-- `python script.py` → `python -u script.py`  
-- `script.py` → `python -u script.py`
-- `python -u script.py` → unchanged
-
-## GPU Control
-
-- Default: Uses all 4 GPUs (0,1,2,3)
-- Custom: `CUDA_VISIBLE_DEVICES=0,1 ./run.sh python script.py`
-
-## Resource Allocation
-
-- 4 GPUs (A100)
-- 32 CPU cores (8 per GPU)
-- 256GB RAM
-- 7 days runtime with auto-resubmission
-
-<!-- EOF -->

scitex/scholar/docs/to_claude/guidelines/programming_common/IMPORTANT-start-from-small.md

@@ -1,30 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-05-31 23:55:14
-!-- Author: ywatanabe
-!-- File: /home/ywatanabe/.dotfiles/.claude/to_claude/guidelines/programming_common/IMPORTANT-start-from-small.md
-!-- --- -->
-
-# Start Small: An Iterative Approach to Development
-
-Start development from small, isolated components before integrating them into a large codebase. This iterative approach fosters clearer design, easier debugging, and more robust systems.
-
-## Define a Minimal Viable Component (MVC)
-Before tackling a large problem, identify the smallest, independent piece of functionality that can be built and tested in isolation. This might be a single function, a small module, or a self-contained class.
-
-## Prototype and Experiment
-Use this MVC to experiment with different approaches, algorithms, or data structures. It's much faster to iterate and fail on a small scale.
-
-## Thoroughly Test the MVC
-Ensure the small component is fully functional, well-tested, and robust before expanding its scope. This means writing comprehensive unit tests that cover expected behavior and edge cases.
-
-## Validate and Refine
-Once the MVC is solid, integrate it into a slightly larger context. Continuously validate its performance and correctness.
-
-## Scale Incrementally
-Avoid "big bang" integrations. Gradually combine working, small components into larger systems, testing at each step. This significantly reduces the risk of introducing widespread bugs.
-
-## Your Understanding Check
-Did you understand the guideline? If yes, please say:
-`CLAUDE UNDERSTOOD: <THIS FILE PATH HERE>`
-
-<!-- EOF -->

scitex/scholar/docs/to_claude/guidelines/programming_common/IMPORTANT-test-driven-workflow.md

@@ -1,80 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-05-31 23:59:07
-!-- Author: ywatanabe
-!-- File: /home/ywatanabe/.dotfiles/.claude/to_claude/guidelines/programming_common/IMPORTANT-test-driven-workflow.md
-!-- --- -->
-
-## !!! IMPORTANT !!! Test-Driven Development (TDD) Workflow !!! IMPORTANT !!!
-The most important guideline in this document is that we adopt test-driven development workflow explained below.
-
-1. **Start with tests**
-   - **PRIORITIZE TEST OVER SOURCE**
-     - The quality of test is the quality of the project
-   - We strictly follow **TEST-DRIVEN DEVELOPMENT**
-   - Write MEANINGFUL tests BEFORE implementing source code
-   - Write MEANINGFUL tests BASED ON EXPECTED INPUT/OUTPUT PAIRS
-   - AVOID MOCK IMPLEMENTATIONS
-   - In this stage, TESTS SHOULD TARGET FUNCTIONALITY THAT DOESN'T EXIST YET
-   - Focus on isolated, small testing units.
-   - Use `./run_tests.sh --debug` for running tests
-   - Also, read `./docs/guidelines/IMPORTANT-guidelines-programming-Elisp-CI-Framework-Rules.md` and follow the rules for pure environments if the project is Elisp-based.
-   - Test code should have expected directory structure based on project goals and conventions in the used language
-
-2. **Verify test failures**
-   - Run the tests to confirm they fail first
-     - Our aim is now clear; all we need is to solve the failed tests
-   - Not to write implementation code yet
-
-3. **Git commit test files**
-   - Review the tests for completeness to satisfy the project goals and requirements
-     - Not determine the qualities of test files based on source files
-       - Prioritize test code over source code
-       - Thus, test code MUST BE SOLID
-   - Commit the tests when satisfied
-
-4. **Implement functionality**
-   - If the above steps 1-3 completed, now you are allowed to implement source code that passes the tests
-   - !!! IMPORTANT !!! NOT TO MODIFY THE TEST FILES IN THIS STEP
-   - Iterate until all tests pass
-
-5. **Verify implementation quality**
-   - Use independent subagents to check if implementation overfits to tests
-   - Ensure solution meets broader requirements beyond tests
-
-6. **Summarize the current iteration by listing:**
-   - What were verified
-   - What are not verified yet
-     - Reasons why they are not verified if not expected
-
-7. **Commit implementation**
-   - Commit the source code once satisfied
-
-## About `./run_tests.sh`
-- `./run_tests.sh` MUST BE VERSATILE AMONG PROJECTS.
-  - THUS, NEVER USE PROJECT-SPECIFIC INFORMATION, SUCH AS DIRECTORY STRUCTURE, IN THE SCRIPT.
-  - It is expected that test codes are located under `./tests`.
-  - In `./run_tests.sh`, paths must be added to source and test codes recursively, without considering project-specific factors.
-- Log file (`./.run_tests.sh.log`) may catch errors
-
-## Test in Elisp Projects
-- Read the report `./*REPORT*.org`
-- THINK next steps based on test results and project progress
-- ~~Known issues are often related to path settings in `./src` and `./test`~~
-
-## Test in Python Projects
-- In Python projects, `./run_tests.sh -s` will synchronize `./tests` directories: test structure is validated and the corresponding source code is embedded as comments
-- Since I am not familiar with `mock` tests, do not use it. Instead, write simple tests.
-- Custom tests should be placed under `./tests/custom`. Otherwise, test code with no corresponding source script will be automatically removed.
-
-## Test Code Quality Checklist
-- Are test code SPLIT INTO SMALL TEST FUNCTIONS?
-- Are test functions explain the functionality in their names?
-- Are test code MEANINGFUL to check required functionalities?
-- Are test code not obsolete?
-- Are test code mirrors source code in its structure?
-
-## Your Understanding Check
-Did you understand the guideline? If yes, please say:
-`CLAUDE UNDERSTOOD: <THIS FILE PATH HERE>`
-
-<!-- EOF -->

scitex/scholar/docs/to_claude/guidelines/programming_common/IMPORTANT-version-control.md

@@ -1,47 +0,0 @@
-<!-- ---
-!-- Timestamp: 2025-06-14 06:21:02
-!-- Author: ywatanabe
-!-- File: /home/ywatanabe/.dotfiles/.claude/to_claude/guidelines/programming_common/IMPORTANT-version-control.md
-!-- --- -->
-
-## Test-Driven Development
-ANY COMMIT MUST BE ASSOCIATED WITH THE LATEST TESTING REPORT
-This ensures the quality of the commited contents
-
-## Git/GitHub Availability
-- `git` and `gh` commands available
-- SSH public key is registered in GitHub account `ywatanabe1989`
-- `git push` to `origin/main` is not accepted
-
-## Our Version Control Workflow
-
-### Standard Workflow (Single Working Directory)
-01. Using `git status`, `git log`, `git stash list`, and so on, understand our step in the workflow
-02. Start from `develop` branch
-03. Checkout to `feature/<verb>-<object>`
-04. Confirmed `feature/<verb>-<object>` is correctly implemented
-05. Once the feature implementation is verified using tests, merge back `feature/<verb>-<object>`into `develop`
-06. Once `feature/<verb>-<object>` branch merged correctly without any problems, delete `feature/<verb>-<object>` branch for cleanliness
-07. Push to origin/develop
-08. For important update, create PR with auto merging from `origin/develop` to `origin/main`
-09. Once PR merged, udpate local `main`
-10. Add tag based on the previous tags conventions
-11. Add release using the tag with descriptive messages
-12. Don't forget to switch back to `develop` branch locally
-
-
-## Merge Rules
-When conflicts found, check if they are minor problems. If it is a tiny problem solve it immediately. Otherwise, let's work on in a safe, dedicated manner
-
-## Before Git Handling
-Let me know your opinion, available plans (e.g., Plan A, Plan B, and Plan C), and reasons in the order of your recommendation
-Once agreed plans determined, process git commands baesd on the agreements
-
-## Rollback
-If the project gets stacked or going not well. Roll back to the recent stable commit.
-
-## Your Understanding Check
-Did you understand the guideline? If yes, please say:
-`CLAUDE UNDERSTOOD: <THIS FILE PATH HERE>`
-
-<!-- EOF -->