From abd6ca31d7c3c451ab1f7b2373d47c1520ee2844 Mon Sep 17 00:00:00 2001 From: richwardle Date: Mon, 28 Oct 2024 12:10:30 +0000 Subject: [PATCH] delete old documentation --- contrib/CODE_REVIEW_DOCS.md | 72 ------- contrib/CONTRIBUTING.md | 213 ------------------- contrib/DEVELOPMENT_WORKFLOW.md | 165 --------------- contrib/STYLE.md | 348 -------------------------------- local/testing.ipynb | 291 -------------------------- prompting/README.md | 20 -- 6 files changed, 1109 deletions(-) delete mode 100644 contrib/CODE_REVIEW_DOCS.md delete mode 100644 contrib/CONTRIBUTING.md delete mode 100644 contrib/DEVELOPMENT_WORKFLOW.md delete mode 100644 contrib/STYLE.md delete mode 100644 local/testing.ipynb delete mode 100644 prompting/README.md diff --git a/contrib/CODE_REVIEW_DOCS.md b/contrib/CODE_REVIEW_DOCS.md deleted file mode 100644 index 9909606a..00000000 --- a/contrib/CODE_REVIEW_DOCS.md +++ /dev/null @@ -1,72 +0,0 @@ -# Code Review -### Conceptual Review - -A review can be a conceptual review, where the reviewer leaves a comment - * `Concept (N)ACK`, meaning "I do (not) agree with the general goal of this pull - request", - * `Approach (N)ACK`, meaning `Concept ACK`, but "I do (not) agree with the - approach of this change". - -A `NACK` needs to include a rationale why the change is not worthwhile. -NACKs without accompanying reasoning may be disregarded. -After conceptual agreement on the change, code review can be provided. A review -begins with `ACK BRANCH_COMMIT`, where `BRANCH_COMMIT` is the top of the PR -branch, followed by a description of how the reviewer did the review. The -following language is used within pull request comments: - - - "I have tested the code", involving change-specific manual testing in - addition to running the unit, functional, or fuzz tests, and in case it is - not obvious how the manual testing was done, it should be described; - - "I have not tested the code, but I have reviewed it and it looks - OK, I agree it can be merged"; - - A "nit" refers to a trivial, often non-blocking issue. - -### Code Review -Project maintainers reserve the right to weigh the opinions of peer reviewers -using common sense judgement and may also weigh based on merit. Reviewers that -have demonstrated a deeper commitment and understanding of the project over time -or who have clear domain expertise may naturally have more weight, as one would -expect in all walks of life. - -Where a patch set affects consensus-critical code, the bar will be much -higher in terms of discussion and peer review requirements, keeping in mind that -mistakes could be very costly to the wider community. This includes refactoring -of consensus-critical code. - -Where a patch set proposes to change the Bittensor consensus, it must have been -discussed extensively on the discord server and other channels, be accompanied by a widely -discussed BIP and have a generally widely perceived technical consensus of being -a worthwhile change based on the judgement of the maintainers. - -### Finding Reviewers - -As most reviewers are themselves developers with their own projects, the review -process can be quite lengthy, and some amount of patience is required. If you find -that you've been waiting for a pull request to be given attention for several -months, there may be a number of reasons for this, some of which you can do something -about: - - - It may be because of a feature freeze due to an upcoming release. During this time, - only bug fixes are taken into consideration. If your pull request is a new feature, - it will not be prioritized until after the release. Wait for the release. - - It may be because the changes you are suggesting do not appeal to people. Rather than - nits and critique, which require effort and means they care enough to spend time on your - contribution, thundering silence is a good sign of widespread (mild) dislike of a given change - (because people don't assume *others* won't actually like the proposal). Don't take - that personally, though! Instead, take another critical look at what you are suggesting - and see if it: changes too much, is too broad, doesn't adhere to the - [developer notes](DEVELOPMENT_WORKFLOW.md), is dangerous or insecure, is messily written, etc. - Identify and address any of the issues you find. Then ask e.g. on IRC if someone could give - their opinion on the concept itself. - - It may be because your code is too complex for all but a few people, and those people - may not have realized your pull request even exists. A great way to find people who - are qualified and care about the code you are touching is the - [Git Blame feature](https://docs.github.com/en/github/managing-files-in-a-repository/managing-files-on-github/tracking-changes-in-a-file). Simply - look up who last modified the code you are changing and see if you can find - them and give them a nudge. Don't be incessant about the nudging, though. - - Finally, if all else fails, ask on IRC or elsewhere for someone to give your pull request - a look. If you think you've been waiting for an unreasonably long time (say, - more than a month) for no particular reason (a few lines changed, etc.), - this is totally fine. Try to return the favor when someone else is asking - for feedback on their code, and the universe balances out. - - Remember that the best thing you can do while waiting is give review to others! \ No newline at end of file diff --git a/contrib/CONTRIBUTING.md b/contrib/CONTRIBUTING.md deleted file mode 100644 index 77847b2b..00000000 --- a/contrib/CONTRIBUTING.md +++ /dev/null @@ -1,213 +0,0 @@ -# Contributing to Bittensor Subnet Development - -The following is a set of guidelines for contributing to the Bittensor ecosystem. These are **HIGHLY RECOMMENDED** guidelines, but not hard-and-fast rules. Use your best judgment, and feel free to propose changes to this document in a pull request. - -## Table Of Contents -1. [How Can I Contribute?](#how-can-i-contribute) - 1. [Communication Channels](#communication-channels) - 1. [Code Contribution General Guideline](#code-contribution-general-guidelines) - 1. [Pull Request Philosophy](#pull-request-philosophy) - 1. [Pull Request Process](#pull-request-process) - 1. [Addressing Feedback](#addressing-feedback) - 1. [Squashing Commits](#squashing-commits) - 1. [Refactoring](#refactoring) - 1. [Peer Review](#peer-review) - 1. [Suggesting Features](#suggesting-enhancements-and-features) - - -## How Can I Contribute? -We welcome community contributions. Please make an issue or a PR if you encounter any issues or want to make suggested improvements. - -## Communication Channels -You can reach out to the SN1 team on the offical bittensor discord channel [here](https://discord.com/channels/799672011265015819/1161764867166961704). - -> Please follow the Bittensor Subnet [style guide](./STYLE.md) regardless of your contribution type. - -Here is a high-level summary: -- Code consistency is crucial; adhere to established programming language conventions. -- Use `black` to format your Python code; it ensures readability and consistency. -- Write concise Git commit messages; summarize changes in ~50 characters. -- Follow these six commit rules: - - Atomic Commits: Focus on one task or fix per commit. - - Subject and Body Separation: Use a blank line to separate the subject from the body. - - Subject Line Length: Keep it under 50 characters for readability. - - Imperative Mood: Write subject line as if giving a command or instruction. - - Body Text Width: Wrap text manually at 72 characters. - - Body Content: Explain what changed and why, not how. -- Make use of your commit messages to simplify project understanding and maintenance. - -> For clear examples of each of the commit rules, see the style guide's [rules](./STYLE.md#the-six-rules-of-a-great-commit) section. - -### Code Contribution General Guidelines - -> Review the Bittensor Subnet [style guide](./STYLE.md) and [development workflow](./DEVELOPMENT_WORKFLOW.md) before contributing. - - -#### Pull Request Philosophy - -Patchsets and enhancements should always be focused. A pull request could add a feature, fix a bug, or refactor code, but it should not contain a mixture of these. Please also avoid 'super' pull requests which attempt to do too much, are overly large, or overly complex as this makes review difficult. - -Specifically, pull requests must adhere to the following criteria: -- Contain fewer than 50 files. PRs with more than 50 files will be closed. -- If a PR introduces a new feature, it *must* include corresponding tests. -- Other PRs (bug fixes, refactoring, etc.) should ideally also have tests, as they provide proof of concept and prevent regression. -- Categorize your PR properly by using GitHub labels. This aids in the review process by informing reviewers about the type of change at a glance. -- Make sure your code includes adequate comments. These should explain why certain decisions were made and how your changes work. -- If your changes are extensive, consider breaking your PR into smaller, related PRs. This makes your contributions easier to understand and review. -- Be active in the discussion about your PR. Respond promptly to comments and questions to help reviewers understand your changes and speed up the acceptance process. - -Generally, all pull requests must: - - - Have a clear use case, fix a demonstrable bug or serve the greater good of the project (e.g. refactoring for modularisation). - - Be well peer-reviewed. - - Follow code style guidelines. - - Not break the existing test suite. - - Where bugs are fixed, where possible, there should be unit tests demonstrating the bug and also proving the fix. - - Change relevant comments and documentation when behaviour of code changes. - -#### Pull Request Process - -Please follow these steps to have your contribution considered by the maintainers: - -*Before* creating the PR: -1. Read the [development workflow](./DEVELOPMENT_WORKFLOW.md) defined for this repository to understand our workflow. -2. Ensure your PR meets the criteria stated in the 'Pull Request Philosophy' section. -3. Include relevant tests for any fixed bugs or new features as stated in the [testing guide](./TESTING.md). -4. Ensure your commit messages are clear and concise. Include the issue number if applicable. -5. If you have multiple commits, rebase them into a single commit using `git rebase -i`. -6. Explain what your changes do and why you think they should be merged in the PR description consistent with the [style guide](./STYLE.md). - -*After* creating the PR: -1. Verify that all [status checks](https://help.github.com/articles/about-status-checks/) are passing after you submit your pull request. -2. Label your PR using GitHub's labeling feature. The labels help categorize the PR and streamline the review process. -3. Document your code with comments that provide a clear understanding of your changes. Explain any non-obvious parts of your code or design decisions you've made. -4. If your PR has extensive changes, consider splitting it into smaller, related PRs. This reduces the cognitive load on the reviewers and speeds up the review process. - -Please be responsive and participate in the discussion on your PR! This aids in clarifying any confusion or concerns and leads to quicker resolution and merging of your PR. - -> Note: If your changes are not ready for merge but you want feedback, create a draft pull request. - -Following these criteria will aid in quicker review and potential merging of your PR. -While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted. - -When you are ready to submit your changes, create a pull request: - -> **Always** follow the [style guide](./STYLE.md) and [development workflow](./DEVELOPMENT_WORKFLOW.md) before submitting pull requests. - -After you submit a pull request, it will be reviewed by the maintainers. They may ask you to make changes. Please respond to any comments and push your changes as a new commit. - -> Note: Be sure to merge the latest from "upstream" before making a pull request: - -```bash -git remote add upstream https://github.com/opentensor/bittensor.git # TODO(developer): replace with your repo URL -git fetch upstream -git merge upstream/ -git push origin -``` - -#### Addressing Feedback - -After submitting your pull request, expect comments and reviews from other contributors. You can add more commits to your pull request by committing them locally and pushing to your fork. - -You are expected to reply to any review comments before your pull request is merged. You may update the code or reject the feedback if you do not agree with it, but you should express so in a reply. If there is outstanding feedback and you are not actively working on it, your pull request may be closed. - -#### Squashing Commits - -If your pull request contains fixup commits (commits that change the same line of code repeatedly) or too fine-grained commits, you may be asked to [squash](https://git-scm.com/docs/git-rebase#_interactive_mode) your commits before it will be reviewed. The basic squashing workflow is shown below. - - git checkout your_branch_name - git rebase -i HEAD~n - # n is normally the number of commits in the pull request. - # Set commits (except the one in the first line) from 'pick' to 'squash', save and quit. - # On the next screen, edit/refine commit messages. - # Save and quit. - git push -f # (force push to GitHub) - -Please update the resulting commit message, if needed. It should read as a coherent message. In most cases, this means not just listing the interim commits. - -If your change contains a merge commit, the above workflow may not work and you will need to remove the merge commit first. See the next section for details on how to rebase. - -Please refrain from creating several pull requests for the same change. Use the pull request that is already open (or was created earlier) to amend changes. This preserves the discussion and review that happened earlier for the respective change set. - -The length of time required for peer review is unpredictable and will vary from pull request to pull request. - -#### Refactoring - -Refactoring is a necessary part of any software project's evolution. The following guidelines cover refactoring pull requests for the project. - -There are three categories of refactoring: code-only moves, code style fixes, and code refactoring. In general, refactoring pull requests should not mix these three kinds of activities in order to make refactoring pull requests easy to review and uncontroversial. In all cases, refactoring PRs must not change the behaviour of code within the pull request (bugs must be preserved as is). - -Project maintainers aim for a quick turnaround on refactoring pull requests, so where possible keep them short, uncomplex and easy to verify. - -Pull requests that refactor the code should not be made by new contributors. It requires a certain level of experience to know where the code belongs to and to understand the full ramification (including rebase effort of open pull requests). Trivial pull requests or pull requests that refactor the code with no clear benefits may be immediately closed by the maintainers to reduce unnecessary workload on reviewing. - -#### Peer Review - -Anyone may participate in peer review which is expressed by comments in the pull request. Typically reviewers will review the code for obvious errors, as well as test out the patch set and opine on the technical merits of the patch. Project maintainers take into account the peer review when determining if there is consensus to merge a pull request (remember that discussions may have taken place elsewhere, not just on GitHub). The following language is used within pull-request comments: - -- ACK means "I have tested the code and I agree it should be merged"; -- NACK means "I disagree this should be merged", and must be accompanied by sound technical justification. NACKs without accompanying reasoning may be disregarded; -- utACK means "I have not tested the code, but I have reviewed it and it looks OK, I agree it can be merged"; -- Concept ACK means "I agree in the general principle of this pull request"; -- Nit refers to trivial, often non-blocking issues. - -Reviewers should include the commit(s) they have reviewed in their comments. This can be done by copying the commit SHA1 hash. - -A pull request that changes consensus-critical code is considerably more involved than a pull request that adds a feature to the wallet, for example. Such patches must be reviewed and thoroughly tested by several reviewers who are knowledgeable about the changed subsystems. Where new features are proposed, it is helpful for reviewers to try out the patch set on a test network and indicate that they have done so in their review. Project maintainers will take this into consideration when merging changes. - -For a more detailed description of the review process, see the [Code Review Guidelines](CODE_REVIEW_DOCS.md). - -> **Note:** If you find a **Closed** issue that seems like it is the same thing that you're experiencing, open a new issue and include a link to the original issue in the body of your new one. - -#### How Do I Submit A (Good) Bug Report? - -Please track bugs as GitHub issues. - -Explain the problem and include additional details to help maintainers reproduce the problem: - -* **Use a clear and descriptive title** for the issue to identify the problem. -* **Describe the exact steps which reproduce the problem** in as many details as possible. For example, start by explaining how you started the application, e.g. which command exactly you used in the terminal, or how you started Bittensor otherwise. When listing steps, **don't just say what you did, but explain how you did it**. For example, if you ran with a set of custom configs, explain if you used a config file or command line arguments. -* **Provide specific examples to demonstrate the steps**. Include links to files or GitHub projects, or copy/pasteable snippets, which you use in those examples. If you're providing snippets in the issue, use [Markdown code blocks](https://help.github.com/articles/markdown-basics/#multiple-lines). -* **Describe the behavior you observed after following the steps** and point out what exactly is the problem with that behavior. -* **Explain which behavior you expected to see instead and why.** -* **Include screenshots and animated GIFs** which show you following the described steps and clearly demonstrate the problem. You can use [this tool](https://www.cockos.com/licecap/) to record GIFs on macOS and Windows, and [this tool](https://github.com/colinkeenan/silentcast) or [this tool](https://github.com/GNOME/byzanz) on Linux. -* **If you're reporting that Bittensor crashed**, include a crash report with a stack trace from the operating system. On macOS, the crash report will be available in `Console.app` under "Diagnostic and usage information" > "User diagnostic reports". Include the crash report in the issue in a [code block](https://help.github.com/articles/markdown-basics/#multiple-lines), a [file attachment](https://help.github.com/articles/file-attachments-on-issues-and-pull-requests/), or put it in a [gist](https://gist.github.com/) and provide link to that gist. -* **If the problem is related to performance or memory**, include a CPU profile capture with your report, if you're using a GPU then include a GPU profile capture as well. Look into the [PyTorch Profiler](https://pytorch.org/tutorials/recipes/recipes/profiler_recipe.html) to look at memory usage of your model. -* **If the problem wasn't triggered by a specific action**, describe what you were doing before the problem happened and share more information using the guidelines below. - -Provide more context by answering these questions: - -* **Did the problem start happening recently** (e.g. after updating to a new version) or was this always a problem? -* If the problem started happening recently, **can you reproduce the problem in an older version of Bittensor?** -* **Can you reliably reproduce the issue?** If not, provide details about how often the problem happens and under which conditions it normally happens. - -Include details about your configuration and environment: - -* **Which version of Bittensor Subnet are you using?** -* **What commit hash are you on?** You can get the exact commit hash by checking `git log` and pasting the full commit hash. -* **What's the name and version of the OS you're using**? -* **Are you running Bittensor Subnet in a virtual machine?** If so, which VM software are you using and which operating systems and versions are used for the host and the guest? -* **Are you running Bittensor Subnet in a dockerized container?** If so, have you made sure that your docker container contains your latest changes and is up to date with Master branch? - -### Suggesting Enhancements and Features - -This section guides you through submitting an enhancement suggestion, including completely new features and minor improvements to existing functionality. Following these guidelines helps maintainers and the community understand your suggestion :pencil: and find related suggestions :mag_right:. - -When you are creating an enhancement suggestion, please [include as many details as possible](#how-do-i-submit-a-good-enhancement-suggestion). Fill in [the template](https://bit.ly/atom-behavior-pr), including the steps that you imagine you would take if the feature you're requesting existed. - -#### Before Submitting An Enhancement Suggestion - -* **Check the [debugging guide](./DEBUGGING.md).** for tips — you might discover that the enhancement is already available. Most importantly, check if you're using the latest version of the project first. - -#### How Submit A (Good) Feature Suggestion - -* **Use a clear and descriptive title** for the issue to identify the problem. -* **Provide a step-by-step description of the suggested enhancement** in as many details as possible. -* **Provide specific examples to demonstrate the steps**. Include copy/pasteable snippets which you use in those examples, as [Markdown code blocks](https://help.github.com/articles/markdown-basics/#multiple-lines). -* **Describe the current behavior** and **explain which behavior you expected to see instead** and why. -* **Include screenshots and animated GIFs** which help you demonstrate the steps or point out the part of the project which the suggestion is related to. You can use [this tool](https://www.cockos.com/licecap/) to record GIFs on macOS and Windows, and [this tool](https://github.com/colinkeenan/silentcast) or [this tool](https://github.com/GNOME/byzanz) on Linux. -* **Explain why this enhancement would be useful** to most users. -* **List some other text editors or applications where this enhancement exists.** -* **Specify the name and version of the OS you're using.** - -Thank you for considering contributing to Bittensor! Any help is greatly appreciated along this journey to incentivize open and permissionless intelligence. diff --git a/contrib/DEVELOPMENT_WORKFLOW.md b/contrib/DEVELOPMENT_WORKFLOW.md deleted file mode 100644 index 13bb07b2..00000000 --- a/contrib/DEVELOPMENT_WORKFLOW.md +++ /dev/null @@ -1,165 +0,0 @@ -# Bittensor Subnet Development Workflow - -This is a highly advisable workflow to follow to keep your subtensor project organized and foster ease of contribution. - -## Table of contents - -- [Bittensor Subnet Development Workflow](#bittensor-subnet-development-workflow) - - [Main Branches](#main-branches) - - [Development Model](#development-model) - - [Feature Branches](#feature-branches) - - [Release Branches](#release-branches) - - [Hotfix Branches](#hotfix-branches) - - [Git Operations](#git-operations) - - [Creating a Feature Branch](#creating-a-feature-branch) - - [Merging Feature Branch into Staging](#merging-feature-branch-into-staging) - - [Creating a Release Branch](#creating-a-release-branch) - - [Finishing a Release Branch](#finishing-a-release-branch) - - [Creating a Hotfix Branch](#creating-a-hotfix-branch) - - [Finishing a Hotfix Branch](#finishing-a-hotfix-branch) - - [Continuous Integration (CI) and Continuous Deployment (CD)](#continuous-integration-ci-and-continuous-deployment-cd) - - [Versioning and Release Notes](#versioning-and-release-notes) - - [Pending Tasks](#pending-tasks) - -## Main Branches - -Bittensor's codebase consists of two main branches: **main** and **staging**. - -**main** -- This is Bittensor's live production branch, which should only be updated by the core development team. This branch is protected, so refrain from pushing or merging into it unless authorized. - -**staging** -- This branch is continuously updated and is where you propose and merge changes. It's essentially Bittensor's active development branch. - -## Development Model - -### Feature Branches - -- Branch off from: `staging` -- Merge back into: `staging` -- Naming convention: `feature//` - -Feature branches are used to develop new features for upcoming or future releases. They exist as long as the feature is in development, but will eventually be merged into `staging` or discarded. Always delete your feature branch after merging to avoid unnecessary clutter. - -### Release Branches - -- Branch off from: `staging` -- Merge back into: `staging` and then `main` -- Naming convention: `release///` - -Release branches support the preparation of a new production release, allowing for minor bug fixes and preparation of metadata (version number, configuration, etc). All new features should be merged into `staging` and wait for the next big release. - -### Hotfix Branches - -General workflow: - -- Branch off from: `main` or `staging` -- Merge back into: `staging` then `main` -- Naming convention: `hotfix///` - -Hotfix branches are meant for quick fixes in the production environment. When a critical bug in a production version must be resolved immediately, a hotfix branch is created. - -## Git Operations - -#### Create a feature branch - -1. Branch from the **staging** branch. - 1. Command: `git checkout -b feature/my-feature staging` - -> Rebase frequently with the updated staging branch so you do not face big conflicts before submitting your pull request. Remember, syncing your changes with other developers could also help you avoid big conflicts. - -#### Merge feature branch into staging - -In other words, integrate your changes into a branch that will be tested and prepared for release. - -1. Switch branch to staging: `git checkout staging` -2. Merging feature branch into staging: `git merge --no-ff feature/my-feature` -3. Pushing changes to staging: `git push origin staging` -4. Delete feature branch: `git branch -d feature/my-feature` (alternatively, this can be navigated on the GitHub web UI) - -This operation is done by Github when merging a PR. - -So, what you have to keep in mind is: -- Open the PR against the `staging` branch. -- After merging a PR you should delete your feature branch. This will be strictly enforced. - -#### Creating a release branch - -1. Create branch from staging: `git checkout -b release/3.4.0/descriptive-message/creator's_name staging` -2. Updating version with major or minor: `./scripts/update_version.sh major|minor` -3. Commit file changes with new version: `git commit -a -m "Updated version to 3.4.0"` - - -#### Finishing a Release Branch - -This involves releasing stable code and generating a new version for bittensor. - -1. Switch branch to main: `git checkout main` -2. Merge release branch into main: `git merge --no-ff release/3.4.0/optional-descriptive-message` -3. Tag changeset: `git tag -a v3.4.0 -m "Releasing v3.4.0: some comment about it"` -4. Push changes to main: `git push origin main` -5. Push tags to origin: `git push origin --tags` - -To keep the changes made in the __release__ branch, we need to merge those back into `staging`: - -- Switch branch to staging: `git checkout staging`. -- Merging release branch into staging: `git merge --no-ff release/3.4.0/optional-descriptive-message` - -This step may well lead to a merge conflict (probably even, since we have changed the version number). If so, fix it and commit. - - -#### Creating a hotfix branch -1. Create branch from main: `git checkout -b hotfix/3.3.4/descriptive-message/creator's-name main` -2. Update patch version: `./scripts/update_version.sh patch` -3. Commit file changes with new version: `git commit -a -m "Updated version to 3.3.4"` -4. Fix the bug and commit the fix: `git commit -m "Fixed critical production issue X"` - -#### Finishing a Hotfix Branch - -Finishing a hotfix branch involves merging the bugfix into both `main` and `staging`. - -1. Switch branch to main: `git checkout main` -2. Merge hotfix into main: `git merge --no-ff hotfix/3.3.4/optional-descriptive-message` -3. Tag new version: `git tag -a v3.3.4 -m "Releasing v3.3.4: descriptive comment about the hotfix"` -4. Push changes to main: `git push origin main` -5. Push tags to origin: `git push origin --tags` -6. Switch branch to staging: `git checkout staging` -7. Merge hotfix into staging: `git merge --no-ff hotfix/3.3.4/descriptive-message/creator's-name` -8. Push changes to origin/staging: `git push origin staging` -9. Delete hotfix branch: `git branch -d hotfix/3.3.4/optional-descriptive-message` - -The one exception to the rule here is that, **when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of** `staging`. Back-merging the bugfix into the __release__ branch will eventually result in the bugfix being merged into `develop` too, when the release branch is finished. (If work in develop immediately requires this bugfix and cannot wait for the release branch to be finished, you may safely merge the bugfix into develop now already as well.) - -Finally, we remove the temporary branch: - -- `git branch -d hotfix/3.3.4/optional-descriptive-message` -## Continuous Integration (CI) and Continuous Deployment (CD) - -Continuous Integration (CI) is a software development practice where members of a team integrate their work frequently. Each integration is verified by an automated build and test process to detect integration errors as quickly as possible. - -Continuous Deployment (CD) is a software engineering approach in which software functionalities are delivered frequently through automated deployments. - -- **CircleCI job**: Create jobs in CircleCI to automate the merging of staging into main and release version (needed to release code) and building and testing Bittensor (needed to merge PRs). - -> It is highly recommended to set up your own circleci pipeline with your subnet - -## Versioning and Release Notes - -Semantic versioning helps keep track of the different versions of the software. When code is merged into main, generate a new version. - -Release notes provide documentation for each version released to the users, highlighting the new features, improvements, and bug fixes. When merged into main, generate GitHub release and release notes. - -## Pending Tasks - -Follow these steps when you are contributing to the bittensor subnet: - -- Determine if main and staging are different -- Determine what is in staging that is not merged yet - - Document not released developments - - When merged into staging, generate information about what's merged into staging but not released. - - When merged into main, generate GitHub release and release notes. -- CircleCI jobs - - Merge staging into main and release version (needed to release code) - - Build and Test Bittensor (needed to merge PRs) - -This document can be improved as the Bittensor project continues to develop and change. diff --git a/contrib/STYLE.md b/contrib/STYLE.md deleted file mode 100644 index b7ac755f..00000000 --- a/contrib/STYLE.md +++ /dev/null @@ -1,348 +0,0 @@ -# Style Guide - -A project’s long-term success rests (among other things) on its maintainability, and a maintainer has few tools more powerful than his or her project’s log. It’s worth taking the time to learn how to care for one properly. What may be a hassle at first soon becomes habit, and eventually a source of pride and productivity for all involved. - -Most programming languages have well-established conventions as to what constitutes idiomatic style, i.e. naming, formatting and so on. There are variations on these conventions, of course, but most developers agree that picking one and sticking to it is far better than the chaos that ensues when everybody does their own thing. - -# Table of Contents -1. [Code Style](#code-style) -2. [Naming Conventions](#naming-conventions) -3. [Git Commit Style](#git-commit-style) -4. [The Six Rules of a Great Commit](#the-six-rules-of-a-great-commit) - - [1. Atomic Commits](#1-atomic-commits) - - [2. Separate Subject from Body with a Blank Line](#2-separate-subject-from-body-with-a-blank-line) - - [3. Limit the Subject Line to 50 Characters](#3-limit-the-subject-line-to-50-characters) - - [4. Use the Imperative Mood in the Subject Line](#4-use-the-imperative-mood-in-the-subject-line) - - [5. Wrap the Body at 72 Characters](#5-wrap-the-body-at-72-characters) - - [6. Use the Body to Explain What and Why vs. How](#6-use-the-body-to-explain-what-and-why-vs-how) -5. [Tools Worth Mentioning](#tools-worth-mentioning) - - [Using `--fixup`](#using---fixup) - - [Interactive Rebase](#interactive-rebase) -6. [Pull Request and Squashing Commits Caveats](#pull-request-and-squashing-commits-caveats) - - -### Code style - -#### General Style -Python's official style guide is PEP 8, which provides conventions for writing code for the main Python distribution. Here are some key points: - -- `Indentation:` Use 4 spaces per indentation level. - -- `Line Length:` Limit all lines to a maximum of 79 characters. - -- `Blank Lines:` Surround top-level function and class definitions with two blank lines. Method definitions inside a class are surrounded by a single blank line. - -- `Imports:` Imports should usually be on separate lines and should be grouped in the following order: - - - Standard library imports. - - Related third party imports. - - Local application/library specific imports. -- `Whitespace:` Avoid extraneous whitespace in the following situations: - - - Immediately inside parentheses, brackets or braces. - - Immediately before a comma, semicolon, or colon. - - Immediately before the open parenthesis that starts the argument list of a function call. -- `Comments:` Comments should be complete sentences and should be used to clarify code and are not a substitute for poorly written code. - -#### For Python - -- `List Comprehensions:` Use list comprehensions for concise and readable creation of lists. - -- `Generators:` Use generators when dealing with large amounts of data to save memory. - -- `Context Managers:` Use context managers (with statement) for resource management. - -- `String Formatting:` Use f-strings for formatting strings in Python 3.6 and above. - -- `Error Handling:` Use exceptions for error handling whenever possible. - -#### More details - -Use `black` to format your python code before commiting for consistency across such a large pool of contributors. Black's code [style](https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#code-style) ensures consistent and opinionated code formatting. It automatically formats your Python code according to the Black style guide, enhancing code readability and maintainability. - -Key Features of Black: - - Consistency: Black enforces a single, consistent coding style across your project, eliminating style debates and allowing developers to focus on code logic. - - Readability: By applying a standard formatting style, Black improves code readability, making it easier to understand and collaborate on projects. - - Automation: Black automates the code formatting process, saving time and effort. It eliminates the need for manual formatting and reduces the likelihood of inconsistencies. - -### Naming Conventions - -- `Classes:` Class names should normally use the CapWords Convention. -- `Functions and Variables:` Function names should be lowercase, with words separated by underscores as necessary to improve readability. Variable names follow the same convention as function names. - -- `Constants:` Constants are usually defined on a module level and written in all capital letters with underscores separating words. - -- `Non-public Methods and Instance Variables:` Use a single leading underscore (_). This is a weak "internal use" indicator. - -- `Strongly "private" methods and variables:` Use a double leading underscore (__). This triggers name mangling in Python. - - -### Git commit style - -Here’s a model Git commit message when contributing: -``` -Summarize changes in around 50 characters or less - -More detailed explanatory text, if necessary. Wrap it to about 72 -characters or so. In some contexts, the first line is treated as the -subject of the commit and the rest of the text as the body. The -blank line separating the summary from the body is critical (unless -you omit the body entirely); various tools like `log`, `shortlog` -and `rebase` can get confused if you run the two together. - -Explain the problem that this commit is solving. Focus on why you -are making this change as opposed to how (the code explains that). -Are there side effects or other unintuitive consequences of this -change? Here's the place to explain them. - -Further paragraphs come after blank lines. - - - Bullet points are okay, too - - - Typically a hyphen or asterisk is used for the bullet, preceded - by a single space, with blank lines in between, but conventions - vary here - -If you use an issue tracker, put references to them at the bottom, -like this: - -Resolves: #123 -See also: #456, #789 -``` - - -## The six rules of a great commit. - -#### 1. Atomic Commits -An “atomic” change revolves around one task or one fix. - -Atomic Approach - - Commit each fix or task as a separate change - - Only commit when a block of work is complete - - Commit each layout change separately - - Joint commit for layout file, code behind file, and additional resources - -Benefits - -- Easy to roll back without affecting other changes -- Easy to make other changes on the fly -- Easy to merge features to other branches - -#### Avoid trivial commit messages - -Commit messages like "fix", "fix2", or "fix3" don't provide any context or clear understanding of what changes the commit introduces. Here are some examples of good vs. bad commit messages: - -**Bad Commit Message:** - - $ git commit -m "fix" - -**Good Commit Message:** - - $ git commit -m "Fix typo in README file" - -> **Caveat**: When working with new features, an atomic commit will often consist of multiple files, since a layout file, code behind file, and additional resources may have been added/modified. You don’t want to commit all of these separately, because if you had to roll back the application to a state before the feature was added, it would involve multiple commit entries, and that can get confusing - -#### 2. Separate subject from body with a blank line - -Not every commit requires both a subject and a body. Sometimes a single line is fine, especially when the change is so simple that no further context is necessary. - -For example: - - Fix typo in introduction to user guide - -Nothing more need be said; if the reader wonders what the typo was, she can simply take a look at the change itself, i.e. use git show or git diff or git log -p. - -If you’re committing something like this at the command line, it’s easy to use the -m option to git commit: - - $ git commit -m"Fix typo in introduction to user guide" - -However, when a commit merits a bit of explanation and context, you need to write a body. For example: - - Derezz the master control program - - MCP turned out to be evil and had become intent on world domination. - This commit throws Tron's disc into MCP (causing its deresolution) - and turns it back into a chess game. - -Commit messages with bodies are not so easy to write with the -m option. You’re better off writing the message in a proper text editor. [See Pro Git](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration). - -In any case, the separation of subject from body pays off when browsing the log. Here’s the full log entry: - - $ git log - commit 42e769bdf4894310333942ffc5a15151222a87be - Author: Kevin Flynn - Date: Fri Jan 01 00:00:00 1982 -0200 - - Derezz the master control program - - MCP turned out to be evil and had become intent on world domination. - This commit throws Tron's disc into MCP (causing its deresolution) - and turns it back into a chess game. - - -#### 3. Limit the subject line to 50 characters -50 characters is not a hard limit, just a rule of thumb. Keeping subject lines at this length ensures that they are readable, and forces the author to think for a moment about the most concise way to explain what’s going on. - -GitHub’s UI is fully aware of these conventions. It will warn you if you go past the 50 character limit. Git will truncate any subject line longer than 72 characters with an ellipsis, thus keeping it to 50 is best practice. - -#### 4. Use the imperative mood in the subject line -Imperative mood just means “spoken or written as if giving a command or instruction”. A few examples: - - Clean your room - Close the door - Take out the trash - -Each of the seven rules you’re reading about right now are written in the imperative (“Wrap the body at 72 characters”, etc.). - -The imperative can sound a little rude; that’s why we don’t often use it. But it’s perfect for Git commit subject lines. One reason for this is that Git itself uses the imperative whenever it creates a commit on your behalf. - -For example, the default message created when using git merge reads: - - Merge branch 'myfeature' - -And when using git revert: - - Revert "Add the thing with the stuff" - - This reverts commit cc87791524aedd593cff5a74532befe7ab69ce9d. - -Or when clicking the “Merge” button on a GitHub pull request: - - Merge pull request #123 from someuser/somebranch - -So when you write your commit messages in the imperative, you’re following Git’s own built-in conventions. For example: - - Refactor subsystem X for readability - Update getting started documentation - Remove deprecated methods - Release version 1.0.0 - -Writing this way can be a little awkward at first. We’re more used to speaking in the indicative mood, which is all about reporting facts. That’s why commit messages often end up reading like this: - - Fixed bug with Y - Changing behavior of X - -And sometimes commit messages get written as a description of their contents: - - More fixes for broken stuff - Sweet new API methods - -To remove any confusion, here’s a simple rule to get it right every time. - -**A properly formed Git commit subject line should always be able to complete the following sentence:** - - If applied, this commit will - -For example: - - If applied, this commit will refactor subsystem X for readability - If applied, this commit will update getting started documentation - If applied, this commit will remove deprecated methods - If applied, this commit will release version 1.0.0 - If applied, this commit will merge pull request #123 from user/branch - -#### 5. Wrap the body at 72 characters -Git never wraps text automatically. When you write the body of a commit message, you must mind its right margin, and wrap text manually. - -The recommendation is to do this at 72 characters, so that Git has plenty of room to indent text while still keeping everything under 80 characters overall. - -A good text editor can help here. It’s easy to configure Vim, for example, to wrap text at 72 characters when you’re writing a Git commit. - -#### 6. Use the body to explain what and why vs. how -This [commit](https://github.com/bitcoin/bitcoin/commit/eb0b56b19017ab5c16c745e6da39c53126924ed6) from Bitcoin Core is a great example of explaining what changed and why: - -``` -commit eb0b56b19017ab5c16c745e6da39c53126924ed6 -Author: Pieter Wuille -Date: Fri Aug 1 22:57:55 2014 +0200 - - Simplify serialize.h's exception handling - - Remove the 'state' and 'exceptmask' from serialize.h's stream - implementations, as well as related methods. - - As exceptmask always included 'failbit', and setstate was always - called with bits = failbit, all it did was immediately raise an - exception. Get rid of those variables, and replace the setstate - with direct exception throwing (which also removes some dead - code). - - As a result, good() is never reached after a failure (there are - only 2 calls, one of which is in tests), and can just be replaced - by !eof(). - - fail(), clear(n) and exceptions() are just never called. Delete - them. -``` - -Take a look at the [full diff](https://github.com/bitcoin/bitcoin/commit/eb0b56b19017ab5c16c745e6da39c53126924ed6) and just think how much time the author is saving fellow and future committers by taking the time to provide this context here and now. If he didn’t, it would probably be lost forever. - -In most cases, you can leave out details about how a change has been made. Code is generally self-explanatory in this regard (and if the code is so complex that it needs to be explained in prose, that’s what source comments are for). Just focus on making clear the reasons why you made the change in the first place—the way things worked before the change (and what was wrong with that), the way they work now, and why you decided to solve it the way you did. - -The future maintainer that thanks you may be yourself! - - - -#### Tools worth mentioning - -##### Using `--fixup` - -If you've made a commit and then realize you've missed something or made a minor mistake, you can use the `--fixup` option. - -For example, suppose you've made a commit with a hash `9fceb02`. Later, you realize you've left a debug statement in your code. Instead of making a new commit titled "remove debug statement" or "fix", you can do the following: - - $ git commit --fixup 9fceb02 - -This will create a new commit to fix the issue, with a message like "fixup! The original commit message". - -##### Interactive Rebase - -Interactive rebase, or `rebase -i`, can be used to squash these fixup commits into the original commits they're fixing, which cleans up your commit history. You can use the `autosquash` option to automatically squash any commits marked as "fixup" into their target commits. - -For example: - - $ git rebase -i --autosquash HEAD~5 - -This command starts an interactive rebase for the last 5 commits (`HEAD~5`). Any commits marked as "fixup" will be automatically moved to squash with their target commits. - -The benefit of using `--fixup` and interactive rebase is that it keeps your commit history clean and readable. It groups fixes with the commits they are related to, rather than having a separate "fix" commit that might not make sense to other developers (or even to you) in the future. - - ---- - -#### Pull Request and Squashing Commits Caveats - -While atomic commits are great for development and for understanding the changes within the branch, the commit history can get messy when merging to the main branch. To keep a cleaner and more understandable commit history in our main branch, we encourage squashing all the commits of a PR into one when merging. - -This single commit should provide an overview of the changes that the PR introduced. It should follow the guidelines for atomic commits (an atomic commit is complete, self-contained, and understandable) but on the scale of the entire feature, task, or fix that the PR addresses. This approach combines the benefits of atomic commits during development with a clean commit history in our main branch. - -Here is how you can squash commits: - -```bash -git rebase -i HEAD~n -``` - -where `n` is the number of commits to squash. After running the command, replace `pick` with `squash` for the commits you want to squash into the previous commit. This will combine the commits and allow you to write a new commit message. - -In this context, an atomic commit message could look like: - -``` -Add feature X - -This commit introduces feature X which does A, B, and C. It adds -new files for layout, updates the code behind the file, and introduces -new resources. This change is important because it allows users to -perform task Y more efficiently. - -It includes: -- Creation of new layout file -- Updates in the code-behind file -- Addition of new resources - -Resolves: #123 -``` - -In your PRs, remember to detail what the PR is introducing or fixing. This will be helpful for reviewers to understand the context and the reason behind the changes. diff --git a/local/testing.ipynb b/local/testing.ipynb deleted file mode 100644 index 78b304fc..00000000 --- a/local/testing.ipynb +++ /dev/null @@ -1,291 +0,0 @@ -{ - "cells": [ - { - "cell_type": "code", - "execution_count": 1, - "metadata": {}, - "outputs": [], - "source": [ - "import asyncio\n", - "from abc import ABC, abstractmethod\n", - "from loguru import logger\n", - "from pydantic import BaseModel, model_validator\n", - "from datetime import timedelta\n", - "import datetime\n", - "import aiohttp\n", - "\n", - "\n", - "class AsyncLoopRunner(BaseModel, ABC):\n", - " interval: int = 10 # interval to run the main function in seconds\n", - " running: bool = False\n", - " sync: bool = False # New parameter to enable/disable synchronization\n", - " time_server_url: str = \"http://worldtimeapi.org/api/ip\"\n", - " name: str | None = None\n", - " step: int = 0\n", - "\n", - " @model_validator(mode=\"after\")\n", - " def validate_name(self):\n", - " if self.name is None:\n", - " self.name = self.__class__.__name__\n", - " return self\n", - "\n", - " @abstractmethod\n", - " async def run_step(self):\n", - " \"\"\"Implement this method with the logic that needs to run periodically.\"\"\"\n", - " raise NotImplementedError(\"run_step method must be implemented\")\n", - "\n", - " async def get_time(self):\n", - " \"\"\"Get the current time from the time server with a timeout.\"\"\"\n", - " if not self.sync:\n", - " time = datetime.datetime.now(datetime.timezone.utc)\n", - " logger.debug(f\"Time: {time}\")\n", - " return time\n", - " try:\n", - " async with aiohttp.ClientSession() as session:\n", - " logger.info(\"Waiting for response time\")\n", - " async with session.get(self.time_server_url, timeout=5) as response:\n", - " if response.status == 200:\n", - " data = await response.json()\n", - " logger.info(\"Got response\")\n", - " return datetime.datetime.fromisoformat(data[\"datetime\"].replace(\"Z\", \"+00:00\"))\n", - " else:\n", - " raise Exception(f\"Failed to get server time. Status: {response.status}\")\n", - " except Exception as ex:\n", - " logger.warning(f\"Could not get time from server: {ex}. Falling back to local time.\")\n", - " return datetime.datetime.now(datetime.timezone.utc)\n", - "\n", - " def next_sync_point(self, current_time):\n", - " \"\"\"Calculate the next sync point based on the current time and interval.\"\"\"\n", - " epoch = datetime.datetime(1970, 1, 1, tzinfo=datetime.timezone.utc)\n", - " time_since_epoch = current_time - epoch\n", - " seconds_since_epoch = time_since_epoch.total_seconds()\n", - " next_interval = (seconds_since_epoch // self.interval + 1) * self.interval\n", - " return epoch + timedelta(seconds=next_interval)\n", - "\n", - " async def wait_for_next_execution(self, last_run_time):\n", - " \"\"\"Wait until the next execution time, either synced or based on last run.\"\"\"\n", - " current_time = await self.get_time()\n", - " logger.debug(\"Current time\")\n", - " if self.sync:\n", - " next_run = self.next_sync_point(current_time)\n", - " else:\n", - " next_run = last_run_time + timedelta(seconds=self.interval)\n", - " logger.debug(f\"Next run: {next_run}\")\n", - "\n", - " wait_time = (next_run - current_time).total_seconds()\n", - " if wait_time > 0:\n", - " logger.debug(\n", - " f\"{self.name}: Waiting for {wait_time:.2f} seconds until next {'sync point' if self.sync else 'execution'}\"\n", - " )\n", - " await asyncio.sleep(wait_time)\n", - " return next_run\n", - "\n", - " async def run_loop(self):\n", - " \"\"\"Run the loop periodically, optionally synchronizing across all instances.\"\"\"\n", - " logger.debug(f\"Starting loop; running: {self.running}\")\n", - "\n", - " last_run_time = await self.get_time()\n", - " logger.debug(f\"Got time of last run: {last_run_time}\")\n", - " try:\n", - " while self.running:\n", - " logger.debug(\"Waiting...\")\n", - " next_run = await self.wait_for_next_execution(last_run_time)\n", - " logger.debug(\"Wait ended\")\n", - " try:\n", - " await self.run_step()\n", - " self.step += 1\n", - " logger.debug(f\"{self.name}: Step {self.step} completed at {next_run}\")\n", - " last_run_time = next_run\n", - " except Exception as ex:\n", - " logger.exception(f\"Error in loop iteration: {ex}\")\n", - " except asyncio.CancelledError:\n", - " logger.info(\"Loop was stopped.\")\n", - " except Exception as e:\n", - " logger.error(f\"Fatal error in loop: {e}\")\n", - " finally:\n", - " self.running = False\n", - " logger.info(\"Loop has been cleaned up.\")\n", - " logger.debug(\"Exiting run_loop\")\n", - "\n", - " async def start(self):\n", - " \"\"\"Start the loop.\"\"\"\n", - " if self.running:\n", - " logger.warning(\"Loop is already running.\")\n", - " return\n", - " self.running = True\n", - " logger.debug(f\"{self.name}: Starting loop with {'synchronized' if self.sync else 'non-synchronized'} mode\")\n", - " self._task = asyncio.create_task(self.run_loop())\n", - "\n", - " async def stop(self):\n", - " \"\"\"Stop the loop.\"\"\"\n", - " self.running = False\n", - " if self._task:\n", - " self._task.cancel()\n", - " try:\n", - " await self._task\n", - " except asyncio.CancelledError:\n", - " logger.info(\"Loop task was cancelled.\")\n" - ] - }, - { - "cell_type": "code", - "execution_count": 2, - "metadata": {}, - "outputs": [ - { - "name": "stderr", - "output_type": "stream", - "text": [ - "\u001b[32m2024-09-23 13:16:25.782\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mstart\u001b[0m:\u001b[36m108\u001b[0m - \u001b[34m\u001b[1m1: Starting loop with synchronized mode\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:25.786\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m77\u001b[0m - \u001b[34m\u001b[1mStarting loop; running: True\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:25.787\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m37\u001b[0m - \u001b[1mWaiting for response time\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:25.807\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m41\u001b[0m - \u001b[1mGot response\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:25.809\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m80\u001b[0m - \u001b[34m\u001b[1mGot time of last run: 2024-09-23 15:16:25.804124+02:00\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:25.811\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m83\u001b[0m - \u001b[34m\u001b[1mWaiting...\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:25.813\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m37\u001b[0m - \u001b[1mWaiting for response time\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:25.826\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m41\u001b[0m - \u001b[1mGot response\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:25.827\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m60\u001b[0m - \u001b[34m\u001b[1mCurrent time\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:25.830\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m65\u001b[0m - \u001b[34m\u001b[1mNext run: 2024-09-23 13:16:30+00:00\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:25.831\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m69\u001b[0m - \u001b[34m\u001b[1m1: Waiting for 4.18 seconds until next sync point\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:30.015\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m85\u001b[0m - \u001b[34m\u001b[1mWait ended\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:30.017\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m89\u001b[0m - \u001b[34m\u001b[1m1: Step 1 completed at 2024-09-23 13:16:30+00:00\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:30.019\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m83\u001b[0m - \u001b[34m\u001b[1mWaiting...\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:30.020\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m37\u001b[0m - \u001b[1mWaiting for response time\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:30.034\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m41\u001b[0m - \u001b[1mGot response\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:30.036\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m60\u001b[0m - \u001b[34m\u001b[1mCurrent time\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:30.037\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m65\u001b[0m - \u001b[34m\u001b[1mNext run: 2024-09-23 13:16:40+00:00\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:30.039\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m69\u001b[0m - \u001b[34m\u001b[1m1: Waiting for 9.97 seconds until next sync point\u001b[0m\n" - ] - }, - { - "name": "stdout", - "output_type": "stream", - "text": [ - "Boop\n" - ] - }, - { - "name": "stderr", - "output_type": "stream", - "text": [ - "\u001b[32m2024-09-23 13:16:30.787\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mstart\u001b[0m:\u001b[36m108\u001b[0m - \u001b[34m\u001b[1m2: Starting loop with synchronized mode\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:30.790\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m77\u001b[0m - \u001b[34m\u001b[1mStarting loop; running: True\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:30.791\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m37\u001b[0m - \u001b[1mWaiting for response time\u001b[0m\n" - ] - }, - { - "name": "stderr", - "output_type": "stream", - "text": [ - "\u001b[32m2024-09-23 13:16:30.810\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m41\u001b[0m - \u001b[1mGot response\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:30.813\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m80\u001b[0m - \u001b[34m\u001b[1mGot time of last run: 2024-09-23 15:16:30.808514+02:00\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:30.814\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m83\u001b[0m - \u001b[34m\u001b[1mWaiting...\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:30.816\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m37\u001b[0m - \u001b[1mWaiting for response time\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:30.832\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m41\u001b[0m - \u001b[1mGot response\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:30.834\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m60\u001b[0m - \u001b[34m\u001b[1mCurrent time\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:30.835\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m65\u001b[0m - \u001b[34m\u001b[1mNext run: 2024-09-23 13:16:40+00:00\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:30.837\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m69\u001b[0m - \u001b[34m\u001b[1m2: Waiting for 9.17 seconds until next sync point\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:40.016\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m85\u001b[0m - \u001b[34m\u001b[1mWait ended\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:40.019\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m89\u001b[0m - \u001b[34m\u001b[1m1: Step 2 completed at 2024-09-23 13:16:40+00:00\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:40.020\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m83\u001b[0m - \u001b[34m\u001b[1mWaiting...\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:40.021\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m37\u001b[0m - \u001b[1mWaiting for response time\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:40.024\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m85\u001b[0m - \u001b[34m\u001b[1mWait ended\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:40.025\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m89\u001b[0m - \u001b[34m\u001b[1m2: Step 1 completed at 2024-09-23 13:16:40+00:00\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:40.026\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m83\u001b[0m - \u001b[34m\u001b[1mWaiting...\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:40.028\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m37\u001b[0m - \u001b[1mWaiting for response time\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:40.041\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m41\u001b[0m - \u001b[1mGot response\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:40.043\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m60\u001b[0m - \u001b[34m\u001b[1mCurrent time\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:40.044\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m65\u001b[0m - \u001b[34m\u001b[1mNext run: 2024-09-23 13:16:50+00:00\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:40.046\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m69\u001b[0m - \u001b[34m\u001b[1m1: Waiting for 9.96 seconds until next sync point\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:40.049\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m41\u001b[0m - \u001b[1mGot response\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:40.050\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m60\u001b[0m - \u001b[34m\u001b[1mCurrent time\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:40.052\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m65\u001b[0m - \u001b[34m\u001b[1mNext run: 2024-09-23 13:16:50+00:00\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:40.053\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m69\u001b[0m - \u001b[34m\u001b[1m2: Waiting for 9.96 seconds until next sync point\u001b[0m\n" - ] - }, - { - "name": "stdout", - "output_type": "stream", - "text": [ - "Boop\n", - "Boop\n" - ] - }, - { - "name": "stderr", - "output_type": "stream", - "text": [ - "\u001b[32m2024-09-23 13:16:50.013\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m85\u001b[0m - \u001b[34m\u001b[1mWait ended\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:50.016\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m89\u001b[0m - \u001b[34m\u001b[1m1: Step 3 completed at 2024-09-23 13:16:50+00:00\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:50.018\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m83\u001b[0m - \u001b[34m\u001b[1mWaiting...\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:50.019\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m37\u001b[0m - \u001b[1mWaiting for response time\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:50.022\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m85\u001b[0m - \u001b[34m\u001b[1mWait ended\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:50.023\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m89\u001b[0m - \u001b[34m\u001b[1m2: Step 2 completed at 2024-09-23 13:16:50+00:00\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:50.024\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mrun_loop\u001b[0m:\u001b[36m83\u001b[0m - \u001b[34m\u001b[1mWaiting...\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:50.026\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m37\u001b[0m - \u001b[1mWaiting for response time\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:50.039\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m41\u001b[0m - \u001b[1mGot response\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:50.041\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m60\u001b[0m - \u001b[34m\u001b[1mCurrent time\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:50.042\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m65\u001b[0m - \u001b[34m\u001b[1mNext run: 2024-09-23 13:17:00+00:00\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:50.044\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m69\u001b[0m - \u001b[34m\u001b[1m1: Waiting for 9.96 seconds until next sync point\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:50.047\u001b[0m | \u001b[1mINFO \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mget_time\u001b[0m:\u001b[36m41\u001b[0m - \u001b[1mGot response\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:50.049\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m60\u001b[0m - \u001b[34m\u001b[1mCurrent time\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:50.051\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m65\u001b[0m - \u001b[34m\u001b[1mNext run: 2024-09-23 13:17:00+00:00\u001b[0m\n", - "\u001b[32m2024-09-23 13:16:50.052\u001b[0m | \u001b[34m\u001b[1mDEBUG \u001b[0m | \u001b[36m__main__\u001b[0m:\u001b[36mwait_for_next_execution\u001b[0m:\u001b[36m69\u001b[0m - \u001b[34m\u001b[1m2: Waiting for 9.96 seconds until next sync point\u001b[0m\n" - ] - }, - { - "name": "stdout", - "output_type": "stream", - "text": [ - "Boop\n", - "Boop\n" - ] - } - ], - "source": [ - "import asyncio\n", - "class Runner(AsyncLoopRunner):\n", - " interval: int = 10\n", - " async def run_step(self):\n", - " print(\"Boop\")\n", - "\n", - "runner = Runner(name=\"1\", sync=True)\n", - "await runner.start()\n", - "await asyncio.sleep(5)\n", - "runner2 = Runner(name=\"2\", sync=True)\n", - "await runner2.start()" - ] - }, - { - "cell_type": "code", - "execution_count": null, - "metadata": {}, - "outputs": [], - "source": [ - "await runner.stop()\n", - "await runner2.stop()" - ] - } - ], - "metadata": { - "kernelspec": { - "display_name": "prompting-fb5sw-i7-py3.10", - "language": "python", - "name": "python3" - }, - "language_info": { - "codemirror_mode": { - "name": "ipython", - "version": 3 - }, - "file_extension": ".py", - "mimetype": "text/x-python", - "name": "python", - "nbconvert_exporter": "python", - "pygments_lexer": "ipython3", - "version": "3.10.12" - } - }, - "nbformat": 4, - "nbformat_minor": 2 -} diff --git a/prompting/README.md b/prompting/README.md deleted file mode 100644 index b9547a00..00000000 --- a/prompting/README.md +++ /dev/null @@ -1,20 +0,0 @@ - -# Prototype for new LLM validation mechanism: Jan 15 release - -![next-release-diagram](assets/next-release-diagram.png) - -1. Follow the installation steps of this [repo]('../README.md') to create a virtual environment with all the needed dependencies -2. Install the extra dependencies of this folder by running `pip install -r requirements.txt` -3. Run `python main.py` located in this folder - - - -### RUN EXPERIMENTS WITH PM2 -- install pm2 -- test if code works using 1 sample (look for ######## HOW TO: DEBUGGING EXPERIMENT ######## on run_experiment.py) - - start app: `pm2 start app.config.js` - - list running apps: `pm2 ls ` - - logs of app: `pm2 logs run-experiment` -- change code to 500 samples (look for ######## HOW TO: REAL EXPERIMENT ######## on run_experiment.py) - -NOTE: DOUBLE CHECK IF YOU ARE USING THE RIGHT PIPELINE AND THE RIGHT MODEL_NAME \ No newline at end of file