# notebooks

title: Auto-detection Improvements
data:
  1. `time docker exec...` This feels like an improvement we should make to the completion engine
  2. `()` is not properly parsed by the completion parser\. The arguments within are considered as commands\. This is trickier to fix because this is a valid shell syntax
  3. There is still some issues with leading contractions \(e\.g\. `What's` or `Can't`\)

  Some examples\:
  * Android MediaPlayer error \-1004 \(ERROR\_IO\)
  * What\'s the difference between String\(value\) vs value\.toString\(\)
  * curl\: \(56\) LibreSSL SSL\_read\: SSL\_ERROR\_SYSCALL\, errno 54
  * How does getWriter\(\) function in an HttpServletResponse\?
  * How to color sliderbar \(sliderInput\)\?
  ### Numbers
  True Positive\: 6395
  False Negative\: 8
  True Negative\: 918
  False Positive\: 82
  True Negative \(Large dataset\)\: 8799
  False Positive \(Large dataset\)\: 1201
  ### Lanugages
  English\, Spanish\, German\, Hindi\, Chinese


title: INTEGRATION_TESTING.md
data:
  # Integration tests in Warp
  This is a short guide into writing integration tests in Warp.

  ## When to add a new integration test?
  Our general philosophy around how we see unit vs integration testing can be summarized as follows:
  ### Write unit tests when:
  * Testing a single function;
  * Function has minimal deps and no pty deps;
  * Can run purely in rust, e.g. a parser.

  ### Integration testing can help:
  * Test some use-case from the user perspective;
  * In scenarios that are slower or require a shell.

  ## What makes a good integration test?
  Test typically has the format:
  * Setup some state in the app;
  * Simulate a user action (e.g. type or click);
  * Verify that the app is in the expected state.

  ## How to add a new integration test?
  Our integration tests currently require you to work with **3** files: [integration/tests/integration.rs](integration.rs), [integration/src/bin/integration.rs](../src/bin/integration.rs), and [integration/src/test.rs](../src/test.rs). (Most tests live in `test.rs` today, but you might want to write yours in a separate file.)

  Let's start with writing a *new integration test* for your feature. To do that, simply add a new method to [integration/src/bin/integration.rs](../src/bin/integration.rs). It should take **0 arguments** and **return `TestDriver`** object. You should also register it in `register_tests()` method in the same file, and later on (to ensure it's being executed) adding it to [integration/tests/integration.rs](integration.rs) in the `integration_tests!` macro. As a convention, each test method name starts with `test_` prefix (note, however, that it doesn't require the `#[test]` annotation like usual unit tests in Rust).

  Now that you've made the first step, it's time to make use of the integration test framework. Let's use the following example to talk more about what's possible to do in integration tests (you'll find more explanation in the comments):

  ```rs
  fn test_simple_example() -> TestDriver {
      new_builder() // initializes the integration test builder
          // each test can have multiple steps, which are more or less complicated,
          // for example - you can wait for a specific action to happen, like in the line below!
          .with_step(wait_for_bootstrapping(0))
          .with_step(
              // You can also create your own `TestStep`!
              TestStep::new("Run ls and verify block exists") // Each `TestStep` has a name
                  // ...and later lets you specify what happens. You can verify which characters were typed:
                  .with_keystrokes(&[
                      Keystroke::parse("l").unwrap(),
                      Keystroke::parse("s").unwrap(),
                      Keystroke::parse("enter").unwrap(),
                  ])
                  // ...set timeouts after which the test is doomed:
                  .set_timeout(Duration::from_secs(5))
                  // ...specify certain assertions:
                  .set_assertion(Box::new(|app, window_id, presenter| {
                      let presenter = presenter.expect("presenter should be set");
                      assert!(presenter.scene().is_some());
                      let views = app.views_of_type(window_id).unwrap();
                      let terminal_view: &ViewHandle<TerminalView> = views.get(0).unwrap();
                      terminal_view.read(app, |view, _ctx| {
                          let model = view.model.lock();
                          async_assert!(
                              !model.is_block_list_empty(),
                              "Block list should not be empty"
                          )
                      })
                  })),
          )
          .build()
  }
  ```

  I find `with_keystrokes` and `with_input_string` most helpful methods, so far. You can check the implementation (and expand it!) in [ui/src/integration/test_driver.rs](../../ui/src/integration/test_driver.ts).

  ## When to use `assert!` vs `async_assert!`
  The former will fail the test the first time it's false. The latter will fail the test if we don't ever see a success in the timeout. If you don't specify a timeout, the default timeout is used.

  In our UI framework, dispatching events and actions are generally synchronous. Concurrency comes mainly from the event loop.

  Example of synchronous assertion:
  This panicks if it fails the first time. Otherwise, it succeeds.
  ```rs
  assert_eq!(
      view.buffer_text(ctx),
      "".to_string(),
      "Input should be empty"
  );
  AssertionOutcome::Success
  ```

  Example of async assertion:
  ```rs
  async_assert_eq!(
      expect_bootstrapped,
      bootstrapped,
      "terminal should be bootstrapped ({})",
      expect_bootstrapped
  )
  ```

  Since many of our tests are async, I would recommend running in a loop locally before merging to avoid flakes e.g.
  ```sh
  for i in {0..100}; do
      RUST_BACKTRACE=full WARP_SHELL_PATH=/bin/bash cargo run --bin integration --features=with_real_display_in_integration_tests -- test_simple_example
      if [ $? -ne 0 ]; then return; fi
  done
  ```

  This has helped us catch a lot of existing bugs in the system.

  Note that for `async_assert` to actually work, the `set_assertion` needs to **return** with the `async_assert`.

  ## How to add a sqlite snapshot?
  * You can copy over a warp.sqlite file from ~/Library/Application\ Support/{warp, dev.warp.Warp-(Dev|Beta|Stable)} directly
  * You may want to sanitize some info that is specific to you (i.e. cwd https://staging.warp.dev/block/FNBafyVtxvjmdNIx6HxUM5)


  ### How to run integration tests?
  To run a specific integration test you can use:
  ```
    cargo run --bin integration --features with_real_display_in_integration_tests -- test_simple_example
  ```

  The `--features with_real_display_in_integration_tests` will force the new terminal window to open, which helps a lot when iterating on your integration test implementation!

  ### Known isssues / limitations
  * To determine (from the `TestStep`) which shell is used for the test, you can try checking `WARP_SHELL_PATH` environment variable (that works within the CI on github) or check the passwd for the user (for local runs).
  * Similarly you can run the test with a specific shell by setting the `WARP_SHELL_PATH` and then running the test. Note that if you're running with fish, you also need to pass in `--features fish_shell` until that feature flag is removed. For example: `WARP_SHELL_PATH=/usr/local/bin/fish`, then `cargo run --bin integration --features fish_shell with_real_display_in_integration_tests -- test_simple_example`
  * Bindings aren't exposed by default in integration tests, add them in the file of the original binding. Example from `editor/view.rs`:

  ```rust
  if ChannelState::channel() == Channel::Integration {
          app.register_fixed_bindings([
              // Hack: Add explicit bindings for the tests, since the tests' injected
              // keypresses won't trigger Mac menu items. Unfortunately we can't use
              // cfg[test] because we are a separate process!
              Binding::new(
                  "cmd-z",
                  EditorAction::Undo,
                  Some("EditorView && !IMEOpen")
              ),
          ]);
      }
  ```


title: Debugging missing shortcuts
data:
  Keyboard shortcuts in terminal editor:
  * Cmd-backspace to delete the line
  * Cmd-x to cut content
  * Cmd-a to select all
  A line that is super long and it softwraps A line that is super long and it softwrapsA line that is super long and it softwraps
  A line that is super long and it softwraps
  ```
  Command 1
  ```
  Command 2




  longgg
  para
  abe
  ```
  Command 1
  ```
  Command 2
   Weh
  dalfjkelad


title: Working with our docker setup
data:
  First make sure you have latest version of our docker image
  ```warp-runnable-command
  docker pull warp-client@latest
  ```
  Start the image
  ```warp-runnable-command
  docker run warp-client@latest

  ```
  Get a shell in the image
  ```warp-embedded-object
  ---
  id: Workflow-cyfSykGLyKbZrfiko0bOi2

  ```


title: Graphite cheat sheet
data:
  gWhile you can find a full list of gt commands in the command reference further down the docs page\, there are a few commands\/combinations of commands we find our engineers and power users use very frequently on a day\-to\-day basis\. For your convenience\, we\'ve grouped these commands by their primary function\, and included their equivalent command in git \(if relevant\)\.
  ## Basic workflow commands
  These are commands that we\'re using constantly whenever we\'re creating and pushing changes to a repository with Graphite\.
  ```warp-runnable-command
  gt ls
  ```
  Compare to\: git log
  This might be glaringly obvious\, but any time branches are created\/manipulated\/changed\, we run this command as if it were second nature\. Most of our engineers prefer the truncated \(ls\) log to the full log\.

  ```warp-runnable-command
  gt bc -am {{commit message}}
  ```
  Compare to\: `git checkout -b <branch_name> && git add . && git commit -m "<commit message>"`
  Creating some changes\, staging those changes\, creating a new branch and committing those changes to the new branch is way too much work\. Create your changes and run this single\-line command to do all of that in one go\.
  ```warp-runnable-command
  gt cc -m "<commit message>"
  gt ca
  ```
  To update an existing branch with new changes\, you can gt cc to create an entirely new commit on that branch or you can gt ca to amend the existing commit on that branch\. Some of our users follow a workflow that encourages a 1\:1 relationship between commits and branches \- if this is you\, gt ca is your friend\.
  ```warp-runnable-command
  gt status
  ```
  Compare to\: git status
  See which files have been changed\.
  ```warp-runnable-command
  gt restore <file_name>
  gt restore .
  ```
  Compare to\: git checkout \-\- filename
  On the same vein as gt status\, restore files to their original state if you accidentally made changes\.
  ```warp-runnable-command
  gt rs -r
  ```
  Compare to\: git pull
  A quick command to pull changes from your trunk branch and subsequently restack upstack changes\. Same as gt repo sync \&\& gt stack restack under the hood\.
  ```warp-runnable-command
  gt ss
  ```
  Compare to\: git push
  Submit your changes across all PRs on a stack\.
  Collaborating on a stack
  Graphite is ultimately a collaboration tool \- there are a suite of commands we use daily to see teammates code and communicate changes\.
  ```warp-runnable-command
  gt dsg <branch_name>
  ```
  Compare to\: git checkout \<branch\_name\>
  A popular command for getting a stack locally that\'s been created\/manipulated by someone else\. Oftentimes followed up with gt bdl to delete irrelevant branches locally\.
  ```warp-runnable-command
  gt bco
  ```
  Compare to\: git checkout branch \<branch\_name\>
  Often used when wanting to check out a singular branch for collaboration OR personal use\.
  Stack navigation\/manipulation commands
  These are commands that we\'re using to move up and down the stack and to restack branches if necessary\.
  ```warp-runnable-command
  gt branch [up|down]
  ```
  Quickly move up and down a stack of branches\. By default\, takes a step argument of 1\, but can add a step value \(ex\. gt branch up 2\) to skip a certain number of branches\.
  ```warp-runnable-command
  gt [bb|bt]
  ```
  Quickly move all the way down \(bb\) or all the way up \(bt\) a stack\.
  Troubleshooting the CLI
  We all run into situations where we need to start from scratch \- here are a few commands we frequent on the rare occasion that we run into a messed up state on the CLI\.
  ```warp-runnable-command
  gt repo init --reset && gt dev cache --clear
  ```
  This combination of commands resets Graphite repo metadata and clears the cache\.

  To upgrade Graphite\:
  ```warp-embedded-object
  ---
  id: Workflow-qmsLbgomWVBdoFzDEDMkkp

  ```


title: README.md
data:
  # Dockerfile for Linux Development

  The Dockerfile in this directory defines a container that has all of the necessary tools installed to quickly get engineers up and running with building Warp on Linux.

  This container is based on Debian Sid, Debian's unstable branch.  It ensures that you are running the latest versions of things like `mesa` (an open-source 3D graphics library, providing implementations of OpenGL and Vulkan).

  ## Prerequisites

  You'll need to install:
  * Docker (e.g.: Docker Desktop)
  * XQuartz (download [here](https://www.xquartz.org/))
    * You'll want to enable iGLX (indirect GL extensions) for proper rendering by running `defaults write org.xquartz.X11 enable_iglx -bool true`; you can do this before you install XQuartz.
    * After installing XQuartz, run it, and enable "Allow connections from network clients" in the Security tab in its settings.  You'll need to quit and relaunch XQuartz after making this change.

  ## Setup

  You'll run all of these commands from the `warp-internal` repository's root directory.

  First, build the docker container image:

  ```
  CONTAINER_NAME="warp-client-linux-dev"
  docker build -t $CONTAINER_NAME docker/linux-dev
  ```

  Next, run the container:

  ```
  # The path to the source code directory that you want to mount in the
  # container. This can be the `warp-internal` repository or some parent
  # directory of your choice.
  LOCAL_PATH="/Users/$USER/src"

  # Run the image as a container, bridging port 22 for SSH connections,
  # mounting the provided directory into the container as `/src`, mounting
  # your SSH key directory into the container (so you don't need to create a
  # new GitHub SSH key), and mounting gcloud configuration (and auth information,
  # so you can run SSH integration tests).
  docker run -dp 127.0.0.1:22:22/tcp -v $LOCAL_PATH:/src -v $HOME/.ssh:/home/dev/.ssh -v $HOME/.config/gcloud:/home/dev/.config/gcloud $CONTAINER_NAME
  ```

  ## Usage

  Every time you start XQuartz, you'll need to run this once in order for programs running in the container to connect to it:

  ```
  xhost +localhost
  ```

  You should be able to SSH into the container and build and run warp without any additional setup (dev account password is "password"):

  ```
  ssh dev@localhost
  cd /src
  cargo run --features fast_dev
  ```

  It's possible you'll run into some odd errors while trying to compile Warp; if so, just keep rerunning the cargo command and it should work eventually.


title: README.md
data:
  # WarpUI

  ## Whirlwind tour

  WarpUI contains many interlocking concepts. It's difficult to explain any one part of the system without reference to other parts. Because of this, this guide tries to provide an overview by exploring the relationships between the major concepts before providing a lot of detail on any one of them.

  Rust's strict ownership rules are a challenge for user interfaces, where multi-directional dataflow is often critical. If every object has one and only one owner, how do we express things like event handlers?

  ## The global App object, entities, and handles

  WarpUI solves this problem with the `App` object, which is the sole owner of all the views and models in the application. We collectively refer to views and models as **entities**. Entities can hold references to other entities via **handles**. A handle provides access to an entity in specific, limited circumstances. Take for example a multi-tabbed terminal. The application window is occupied by a `WorkspaceView`, and we want this workspace to contain multiple `TerminalView`s. Rather than holding the `TerminalView`s directly, the `Workspace` instead holds a vector of `ViewHandle<TerminalView>`.

  ```rust
  struct WorkspaceView {
      sessions: Vec<ViewHandle<TerminalView>>,
  }
  ```

  On its own, a `ViewHandle` can't do much. Its existence prevents the referenced view from being discarded by the global `App` object, but it doesn't provide direct access to the referenced view. A handle is basically a glorified identifier. To convert a handle into an actual reference, you need a reference to an **app context** object, which will be provided by the global `App` object at specific points in time.

  An example of one of those times could be the `render` method on `WorkspaceView`, which will be called by the framework whenever the workspace's on-screen representation is updated. One of the parameters to `render` is an `&AppContext`, which can be passed to the `as_ref` method on a `ViewHandle` to retrieve a reference to the underlying object.

  Many details are elided in the code example below so we can focus on the topic at hand, but imagine we wanted to know the titles of all our terminal sessions so we could render them in tabs:

  ```rust
  impl View for WorkspaceView {
      fn render<'a>(&self, ..., ctx: &AppContext) -> ... {
          let titles = self.sessions.iter().map(|handle| handle.as_ref(ctx).title()).collect::<Vec<String>>;
          ...
      }

      ...
  }
  ```

  After we return from the `render` method and lose access to the `&AppContext` parameter provided during its call, we no longer have access to the terminal views they reference.

  Entities are of course entitled to own any state they like directly as well. Handles are only required when an entity needs to reference an entity. The reasons it would make sense to express a piece of application state as its own entity will become clearer as we sketch in more aspects of the system.

  ## Elements

  The framework requires all views to implement the `View` trait, and a key method of this trait is `render`, which we showcased above. This method's job is to compute a visual description of the view based on its current state, and it is called whenever the view's state changes.

  To do describe the view's appearence, render returns an **element**. While a single view may exist for an arbitrary amount of time, changing its state as the user interacts with the application, an element is designed to exist for only a single frame. More precicely, elements returned by views that haven't changed are recycled across multiple frames, but conceptually you can think of an element as a throwaway object that is discarded and replaced whenever the view that returned it changes.

  The framework ships with several elements that can be composed to perform common tasks such as drawing backgrounds and borders, adding padding, rendering label text, laying out elements horizontally and vertically, handlign events, etc. The stock elements are loosely based on the Flutter framework. It's also straightforward to define your own custom elements, giving you detailed control over layout and the ability to imperatively paint pixels on scene via the hardware-accelerated `Scene` API.

  ## Actions

  ### Action handlers

  ### Action dispatch

  ## Views


title: Getting Started with Warp
data:
  How to run warp locally
  * Visit the [warp\-internal](https://github.com/warpdotdev/warp-internal) repo in warpdotdev\'s GitHub org and run `git clone git@github.com:warpdotdev/warp-internal.git` to get a local copy of the code
  * Install Xcode from the Apple apple store\, if you haven\'t installed it already
      * Note\: The command line dev tools are not sufficient\, you need to install the full Xcode application\.
  * Make sure your GitHub SSH key is set up
      * [Create an SSH key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent)
  ```warp-runnable-command
  ssh-keygen -t ed25519 -C '{{your_name}}@warp.dev' -f ~/.ssh/github
  ```
      * [Add SSH key to GitHub](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account)
  ```warp-runnable-command
  # if you don't have this yet
  brew install gh
  # if you haven't authenticated yet. otherwise use "refresh" instead of "login"
  # use SSH, not HTTPS, because some of our cargo crates will require SSH
  gh auth login -h github.com -s admin:public_key
  gh ssh-key add ~/.ssh/github.pub --title "Warp dev machine"
  ```
      * [Add your SSH key to the ssh\-agent](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#adding-your-ssh-key-to-the-ssh-agent)
  * Then run the following commands\:
  ```warp-runnable-command
  ./script/bootstrap
  ```
  ```warp-runnable-command
  ./script/run
  ```
  ## Developing locally\:
  * For VSCode\, `rust-analyzer` is well\-supported and is very powerful\.
  * CLion is the JetBrains product for Rust\. It has a great debugger\. rust analyzer doesn\'t work as well for it\.
  * `./script/presubmit` For tests \& lint locally
  * We prefix remote branches with our names e\.g\. zheng\/feature\.
      * Linear has a feature to generate branch names for specific tasks\. You\'ll have to create the branch locally though
  ### If the bundled app deviates from local cargo run\.\.\.
  * `cargo run --release`
  * Bundle command `./script/bundle --nouniversal --nosign -o -c beta --release-tag "1.2.3"` to bundle from the repo
  ## Accessing Warp Dev and Beta
  In general all engineers on Warp should be using Warp dev as their day to day terminal\. To download the latest Warp dev\, find the latest dev release on the [Github releases page](https://github.com/warpdotdev/warp-internal/releases)\.
  You can also download Warp beta in the same way if needed for testing\.
  Before you can log in to Warp dev or beta\, you’ll need to add your IP address to the allowlist for the staging server\: Accessing staging\.
  ## Feature Flags
  * These are currently set at compile time\, so we can check in code \& turn on features for select channels \(e\.g\. Dev\, Local development\)
  * Example of adding a feature flag\:
      * [https\:\/\/github\.com\/warpdotdev\/warp\-internal\/pull\/4863](https://github.com/warpdotdev/warp-internal/pull/4863)
  Adding a feature flag \+ turning it on for dev\:
  1.  Add it to `app/Cargo.toml` \(NOT under the `default` nested stanza\)
  2.  Add it to `features.rs` enum
  3.  Add it to `app/src/lib.rs` with an attribute
  4.  In your code\, `FeatureFlag::FeatureName.is_enabled()`
  Rolling out to Warp Stable\:
  * Put it in the `default` array in the Cargo\.toml
  After the feature is stable for a while\:
  * Remove the feature flag and relevant code
  To run with feature flags
  * `cargo run --features=foo`
  * `cargo run --features=foo,bar`
  ## Accessing staging
  You’ll need to add your external IP address \(allowlist\) using one of the following\:
  * The easiest way to get your external IP address is to google “my ip address” and Google will show it to you \(probably no need to click any of the results\)\. Another way is to lookup our team workflow\, search “IP address”\.
  * Web console\: [https\:\/\/console\.cloud\.google\.com\/net\-security\/securitypolicies\/details\/deny\-all\-ip\?project\=warp\-server\-staging\&tab\=rules\.](https://console.cloud.google.com/net-security/securitypolicies/details/deny-all-ip?project=warp-server-staging&tab=rules.)
  * Warp repository workflow\:

  ```warp-embedded-object
  ---
  id: Workflow-FypTmCeczEBC5ekwiRWKFn

  ```
  * Please use a descriptive rule with your name\!
  * The limit is 100 rules per security policy\, and we’ve hit it\!
      * If you need to add multiple IP addresses\, please add them to the same rule
      * You can delete rules without a meaningful description if you need to
  ## To prevent clicking through \"warp wants to use your confidential information\" dialog\:
  * Add `--features fast_dev` when running `cargo run` or `./script/run` to set some feature flags which improve development ergonomics\.
      * One of the features enabled uses a test user instead of your actually authenticated user\.  If you need to test features that depend on having a valid logged\-in state\, `fast_dev` will cause problems
  * Inconsistent but has worked for some people\:
      * cmd \+ space
      * keychain access
      * find \"warp\" and set in \"Access Control\" \"Allow all applications to access this item\"
  ## Tech documentation\:
  * Warp Editor [README](https://github.com/warpdotdev/warp-internal/blob/master/app/src/editor/README.md)
      * A lot of code forklifted from Zed editor
  * [Warp UI intro](https://github.com/warpdotdev/warp-internal/tree/master/ui) \(incomplete\)
  * [Objective\-C docs](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html#//appl%5B%E2%80%A6%5DCH1-SW1) \(if you\'re working on that code\)
  * [Alacritty](https://github.com/alacritty/alacritty)
  ## How to run the server\:
  * By default\, the client goes to staging
      * To target localhost\, build the client with\, `--features=with_local_server`
  * Get the warpdotdev\/warp\-server repo
  * Install Golang [https\:\/\/go\.dev\/doc\/install](https://go.dev/doc/install)\. Note that you need to add the GOPATH to your PATH
  * `./script/bootstrap`
  * Download google cloud cli
  * `./script/server`
  ### Crate Overview
  `warp-internal` is split into a few crates\. Some important ones are\:
  * [`ui`](./ui)\: contains the UI framework \([README](./ui/README.md)\)
  * [`app`](./app)\: the main Warp application crate \(the crate itself is named `warp`\)
  * [`sum_tree`](./sum_tree)\: implements the [`SumTree` datastructure](https://www.warp.dev/blog/how-warp-works) we use throughout Warp
  * [`warpui_extras`](./warpui_extras)\: extensions to the UI framework like cross\-platform user preferences
  * [`warp_util`](./warp_util)\: Utilities used across Warp crates\, like path escaping
  * [`graphql`](./graphql)\: Autogenerated client stubs for our GraphQL API


title: README.md
data:
  # Testing Warp Functionality over SSH

  ## Pre-req: Install Docker
  1. `brew install --cask docker`
  2. Open the Docker desktop app. This is necessary to create the symbolic links that will make the `docker` CLI available.

  ## Running Warp over SSH
  There's a workflow called "Build image and start container for SSH testing" in this repo. After that, you may SSH in by running bash@0.0.0.0 or zsh@0.0.0.0. It'll prompt for a password which is `password` for these VMs.

  After you've built the image, you can just launch the container again with the second command in the workflow.

  Note that you can only have one docker container in your system that has port 22.

  ## More advanced use
  Sometimes SSH users have issues based on their SSH server configs which is usually `/etc/ssh/sshd_config` (this is also the case in Ubuntu, which the Dockerfile in this repo uses). If you need to edit it, you'll have to reboot the SSH daemon afterwards to have the changes reflected with `sudo service ssh restart`. This will cause the container to be stopped, and you'll have to
  restart it in the Docker Desktop app (click the play button) in order to restart it with the new config.


title: README.md
data:
  This directory is used for any static assets we want to load in the app (e.g. svg icons, images, fonts, etc.)


title: Collaboration Focus Area Weekly
data:
  # May 3
  ## **Make working together in Warp the best way for developers to deliver software\.**
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Announcements \& Discussion

  ## Technical Deep Dive
  * Discussion of launch risks for SS\, WoW and WDoW\.
  * Fixing Firefox performance
  # April 26
  ## **Make working together in Warp the best way for developers to deliver software\.**
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Announcements \& Discussion

  ## Technical Deep Dive
  * Discussion of launch risks for SS\, WoW and WDoW\.
  # April 19
  ## **Make working together in Warp the best way for developers to deliver software\.**
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Announcements \& Discussion
  * Session Sharing and WoW joining Collab\, welcome\!
  ## Technical Deep Dive
  * Discussion of launch risks for SS\, WoW and WDoW\.
      * By April 25th 
          * Prioritize productionizing `app.warp.dev/session` links 
          * Session links should open within native 
      * Post April 25th
          * Enable session links to open on web\. This will release when available\. 
      * May 10th
          * Minimum requirement is the april 25th behavior \(session links \-\-\> native\)


  * See launch plan doc [https\:\/\/docs\.google\.com\/document\/d\/1cBZu77z2dKa4frIbolPHXhMQEl5WeQpw9PUqpL0wAcc\/](https://docs.google.com/document/d/1cBZu77z2dKa4frIbolPHXhMQEl5WeQpw9PUqpL0wAcc/edit#heading=h.ost8d15vw8lj)
  * Session sharing pod probably wraps up in June\, WDoW folks move onto ACLs sometime after May 10th\.
  ## Notes
  # April 12
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  * PSA\: [notebooks P0 followups](https://linear.app/warpdotdev/view/a276d641-13c3-428d-b8e7-909c4d7fc09f?layout=list&ordering=priority&grouping=workflowState&subGrouping=none&showCompletedIssues=all&showSubIssues=true) also count as product quality issues\! 
  ## Technical Deep Dive
  * John\: FA structure changes
  * Ben\: Notebooks fast follows
  * Ben\: How we\'re breaking up Linkability\/WDOW work
  ## Notes
  # Mar 29
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  * Discussing [Q2 OKRs](https://docs.google.com/document/d/17JOr7ubIZlx-HHbfegmmCd0q6tA6rL3t6R4TOZKMZjg/edit#heading=h.oui1oarkycqm)
  * We\'ll also need a BOD demo volunteer in that 3\/29 meeting\!
  ## Technical Deep Dive
  * \(More of a conversation\) Scope of issues for oncall to handle directly
      * If fixing an issue takes \< 1 hour\, go ahead and fix it
      * If the issue is larger scale\, then file a ticket\, add context\, go through triage process
  * John\: \"don\'t worry the reaper will come for everyone\"
  ## Notes
  # Mar 22
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  * OKR timeline
      * Ben\/John will share OKR ideas doc next week\, and discuss in 3\/29 FA meeting\.
          * Collaboration FA will be smaller in Q2\, more folks will join in Q3
      * We\'ll also need a BOD demo volunteer in that 3\/29 meeting\!
  ## Technical Deep Dive
  * Ben \- ID\-related bug from a couple weeks ago
  ## Notes
  # Mar 15
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  * FA Kickoff
  ## Technical Deep Dive
  * New oncall tooling
  ## Notes
  # Mar 8
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  ## Technical Deep Dive
  * Kevin \- Warp Text kickoff
  * Ben \- client\-side flows for listening to RTC and team updates
  ## Notes
  # Mar 1
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  ## Technical Deep Dive
  * CCA\!
      * Won\'t be possible to have someone stop their work and build out entire CCA
      * Different projects need different pieces of the CCA\, so it\'d be helpful to identify the most meaningful pieces 
          * Allow users to be on multiple drives
          * Split up teams into drives and organizations\/networks
          * Allow guests on object\- and drive\-level
  * Phase 1
      * Attach membership and billing to organizations\, not drives \- fast follow to current billing and org support work
      * ACLs\, guests\, permissions \- will start in WDOW work
  * Phase 2
      * Multiple drives \- may come as a fast follow after team discovery
      * Switching profiles
      * Etc
  ## Notes
  # Feb 23
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  ## Technical Deep Dive
  * Ben \- client\-side flows for listening to RTC and team updates
  ## Notes
  * V0 linkability launch timeline
      * V0\: native to native sharing for team objects \(links to objects will always open in client\, not on web yet\)
      * Ideally launch with notebooks release in May
  * Ben is starting ACLs work
  # Feb 16
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  ## Technical Deep Dive
  * Ben \- An overview of our monitoring and how it gets into Grafana
  ## Notes
  # Feb 9
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  ## Technical Deep Dive
  * Gradual rollout
  ## Notes
  * New notebook launch plan\: bigger marketing launch in April to resurface Warp Drive
      * In the meantime\, we\'ll expand notebook beta to all teams \> 2 people \(3000 people\) next week
  # Feb 2
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  ## Notes
  * Cloud roadmap post\-Notebooks
      * Catherine will be working on team discovery
      * Ian and Sega will be working on linkability
      * Future projects [stack rank](https://docs.google.com/spreadsheets/d/1bPFp__r1geSXYVurGMR81kKbd4ss6UEx16mLXXzTcgc/edit#gid=1583170004)
      * How much further time we invest in notebooks depends on user feedback
          * While we\'re learning\, focus on fixing bugs and blockers\, hold off from new features
      * New FAs likely will be restructured by March
  # Jan 19
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  ## Technical Deep Dive
  * Observations from disaster response test
  ## Notes
  # Jan 12
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  ## Technical Deep Dive
  * 
  ## Notes
  # Jan 5
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  ## Technical Deep Dive
  * Disaster recovery plan
  ## Notes
  # Dec 15
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  ## Technical Deep Dive
  * Zheng on UUIDs
      * UUIDs are external facing \(exposed by API\)\, int IDs are internal facing
  * Terraform
  * John \& Zheng on component\/DRI matrix\:
      * Notebooks \- Ben
      * WaW \- Jeff
          * SOC2\/GDPR
          * Billing
          * Turn off AI 
          * SSO
      * Permissions \& CCA \- Zheng
      * WDOW \- Zheng
  * Seikun on Billing design decisions
      * Proposal doc\: [https\:\/\/docs\.google\.com\/document\/d\/1\_lP5QZbr16XVJIoYT55CnguaK7M2PAM0p0rOnYDqYt0\/edit\?usp\=sharing](https://docs.google.com/document/d/1_lP5QZbr16XVJIoYT55CnguaK7M2PAM0p0rOnYDqYt0/edit?usp=sharing)
  ## Notes
  # Dec 8
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Metrics \/ user feedback \@Noah
  * Over 100 notebooks have been created \(from non Warp team members\)\!
  * Potential fast follow\: adding image support to notebooks
  * Design demo\: creating and editing a notebook template \(Figma [link](https://www.figma.com/proto/d20YoYJR1v6JGJJ93A7x7v/Future-of-Notebooks)\)
  ## Announcements \& Discussion
  * Notebook launch set for Feb 8\!
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  ## Technical Deep Dive
  * OKR discussion\! 
      * Next quarter
          * WAW \- Jeff and Seikun
          * NB \- Ben\, Ian\, Kevin
          * WDOW \(Warp Drive on Web\) \- Zheng\, Catherine
          * Jack \- WOW
          * Dan \- Linux
      * Warp Drive OKR thoughts\: [https\:\/\/docs\.google\.com\/document\/d\/1FFKYTWkBxRY0ZtM9lf8Hza\-8kEsGj\-uea0guUCCEwtY\/edit](https://docs.google.com/document/d/1FFKYTWkBxRY0ZtM9lf8Hza-8kEsGj-uea0guUCCEwtY/edit)
  ## Notes
  # Dec 1
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Metrics \/ user feedback \@Noah
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  ## Technical Deep Dive
  * OKR discussion\! 
  * Ian\/Jack\/Zheng RTC discussion\!
  ## Notes
  # Nov 17
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Metrics \/ user feedback \@Noah
  * We should figure out 
      * How to activate workflow usage from the start
          * Metrics show that users use Warp more if they use more workflows early on
      * How to educate\/encourage existing Warp users about workflows
          * 50\-60\% of workflow users every week are new Warp users in general
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  ## Technical Deep Dive
  * OKR discussion\! [https\:\/\/docs\.google\.com\/document\/d\/1oyPvqTBSRkZTyTurERwp\_vkH2epIHY3Evt5bA\_tdNHs\/edit](https://docs.google.com/document/d/1oyPvqTBSRkZTyTurERwp_vkH2epIHY3Evt5bA_tdNHs/edit)
  ## Notes
  # Nov 3
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Metrics \/ user feedback \@Noah
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  ## Technical Deep Dive
  * Zheng on Sqlite\!
  ## Notes
  # Oct 20
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Metrics \/ user feedback \@Noah
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  ## Technical Deep Dive
  * Jeff\/Jack\/Catherine on batch jobs
  ## Notes
  # Oct 13
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Metrics \/ user feedback \@Noah
  ## Announcements \& Discussion
  * Rest in peace\, Ian\'s dog 😢
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  * Bugs go in Linear\, not \(just\) Slack\!
  ## Technical Deep Dive
  * Discussion about Technical Deep Dives\!
      * How valuable\?
      * What would you like to see\?
      * What format\? Loom\?
  * Suggestions on technical deep dives
      * Need to keep it from feeling rushed\, either a separate meeting or reserved time
      * The discussion is valuable
      * Do it last\, so folks not interested in the content can bail
  ## Notes
  # Oct 6
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Metrics \/ user feedback \@Noah
  ## Announcements \& Discussion
  * Checking in on product quality issues [https\:\/\/linear\.app\/warpdotdev\/view\/d786fdcd\-aee9\-4a39\-aca2\-17a4d743fb1d\?layout\=list\&ordering\=priority\&grouping\=workflowState\&showCompletedIssues\=month\&showSubIssues\=true](https://linear.app/warpdotdev/view/d786fdcd-aee9-4a39-aca2-17a4d743fb1d?layout=list&ordering=priority&grouping=workflowState&showCompletedIssues=month&showSubIssues=true)
  ## Technical Deep Dive
  * Jack talk on GCP \(make sure this is recorded\!\)
  ## Notes
  # Sep 29
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Metrics \/ user feedback \@Noah
  ## Announcements \& Discussion
  * JR\: Let\'s talk about bugs\!
      * Zheng and John working on populating a Linear View to track high\-priority product improvements\, bugs and reliability fixes
      * In the interim\, we\'ve got a small hand\-selected list to talk about\!
  1. [https\:\/\/linear\.app\/warpdotdev\/issue\/CLD\-852\/gh03667\-everytime\-i\-update\-warp\-the\-workflows\-are\-reset\-really](https://linear.app/warpdotdev/issue/CLD-852/gh03667-everytime-i-update-warp-the-workflows-are-reset-really) \- Ian
  2. [https\:\/\/linear\.app\/warpdotdev\/issue\/CLD\-370\/error\-saving\-folders\-brokentransactionmanager](https://linear.app/warpdotdev/issue/CLD-370/error-saving-folders-brokentransactionmanager) \- Ian \- related to \(1\)
  3. [https\:\/\/linear\.app\/warpdotdev\/issue\/CLD\-841\/better\-observability\-for\-panics\-within\-rtc\-worker\-groups](https://linear.app/warpdotdev/issue/CLD-841/better-observability-for-panics-within-rtc-worker-groups) \- Jack
  4. [https\:\/\/linear\.app\/warpdotdev\/issue\/CLD\-739\/investigate\-safer\-enum\-pattern\-for\-golang](https://linear.app/warpdotdev/issue/CLD-739/investigate-safer-enum-pattern-for-golang) \- Looking for owner\!
  5. [https\:\/\/linear\.app\/warpdotdev\/issue\/CLD\-843\/alert\-on\-rtc\-message\-error\-rate](https://linear.app/warpdotdev/issue/CLD-843/alert-on-rtc-message-error-rate) \- Zheng
  ## Technical Deep Dive
  * Ian technical deep\-dive on RTC incident
  ## Notes
  # Sep 22
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Metrics \/ user feedback \@Noah
  ## Announcements \& Discussion
  * John\: Let\'s record some dates in Linear\!
  * Zheng\: Doc on server best practices
      * Seikun will own writing this
      * High\-level engineering practices should live in Notion
  * Zheng\: Building GCP knowledge
  ## Technical Deep Dive
  * Ian technical deep\-dive on last week\'s RTC incident
  ## Notes
  # Sep 15
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Metrics \/ user feedback \@Noah
  ## Announcements \& Discussion
  * John\: standardized project milestones\?
  * Zheng\: demo\'ing infra\/PQ work
  * John\: project buddies check\-in
  ## Technical Deep Dive
  * Jack technical deep\-dive on last week\'s post mortem
  ## Notes
  # Sep 8
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Metrics \/ user feedback \@Noah
  * We now collpase the input box\, shift\-tab is not intuitive
  * Changelog is overwhelming\, relevant for drive users\, but not for all users
      * Should we have a seperate onboarding for drive users specifically\? 
      * Melanie\: These small launches aren\'t really features and we should be relying on design for people to find these
      * Drive Onboarding is very distince from terminal onboarding \- should we be thinking about the differently\?
          * Melanie\: I am allergic to dragging people through UIs
          * Stuff should be inline with habits from other tools\, we can revisit this 
      * Noah\: How can we tie the update to the actual product better so people can see and understand it better
  ## Announcements \& Discussion
  * Reliability
      * Zheng \- same speech I\'ve been giving
          * Reliability is one of our OKRs\, it\'s of the uptmost importance to server and deliver a reliable product
          * We are not just headsdown building features\, but we are invested in deteching issues\, preventing failure modes
      * If anything is nullable on the DB or graphql layer \- it must also be nullable on the client
          * These constraints can cause issues elsewhere in the system
  ## Technical Deep Dive
  * Zheng to discuss eventual consistency
  * We have an event bus that we rely to recieve live updates on different clients
      * This is something that is important and Zheng will investigate futher
  ## Notes
  # Sep 1
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Metrics \/ user feedback \@Noah
  ## Announcements \& Discussion
  Rollout of responsibility restructure
  * Overview and goals
  * JR taking over more PjM work
      * Keeping Linear in good order
      * JR helping folks find bugs\/features\/projects to work on
      * Managing weekly meetings
  * Project Reviewer \(naming open to suggestion\)
      * Joins kickoff\, design jams
      * First reviewer on PRD\, TDD
      * First outside\-pod PR reviewer
      * ZT still DRI for product and tech
      * Assigning to existing projects
          * Kevin for invite\-by\-email
          * Ian for perma\-delete
          * Jeff for metadata visibility
          * Jeff for Notebooks
          * Ben for WAW
  * Per\-label owners
      * We should have a set of labels
          * WD FF
          * Starter Projects
          * Etc
      * Responsible for backlog grooming\, prioritization of those labels\, PR review
      * Looking for an owner for each of those
      * ZT still DRI for product and tech
  * PR reviewers taking over ZT’s testing crusade
  * Discussion of how we delegate and build alignment
      * More like interviewer training \(shadow\, reverse\-shadow\)
  Notebooks team tester
  Need someone to run Cloud meeting on 9\/8
  * \(Melanie\) \:wave\: I need help understanding the success criteria for Notebooks \= complete and launch\-ready\; goal is to plan a launch 4 weeks out from product ready so we have time to get animations done well with no stress\; this feature is very visual and I want to make sure the product images reflect the close\-to\-final UI\/UX and don\'t deviate too much\; \@noah maybe this is something we can meet 1\:1 to hash out\.\.\.\?
      * \(Zheng\) We want to \"GA Notebooks based on product readiness\"
      * Critera \= \"enthusiasm\"
  ## Technical Deep Dive
  * Not this week\!
  ## Notes
  # Aug 25
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  ## Metrics \/ user feedback \@Noah
  ## Announcements \& Discussion
  * Cloud persistence model vs view model \@Ian
  * Culture of Reliability \+ Blameless culture \@Zheng
  ## Technical Deep Dive
  * SQLite
  ## Notes
  # Aug 18
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  [Link](https://warpdev.slack.com/archives/C052ST7VBRC)
  ## Demos
  sdfsdf
  ## Metrics \/ user feedback \@Noah
  ## Announcements \& Discussion
  * Atlassian got budget approved\!
  * Goodbye Liam\! \:\'\(
  * Culture of reliability\. Especially important when persisting user data
  ## Technical Deep Dive
  * Staging cloud objects disappearing
  * Number of transaction rollbacks grows over time
  ## Notes
  # Aug 11
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  ## Demos
  ## Metrics \/ user feedback \@Noah
  ## Announcements \& Discussion
  * Welcome Seikun\!
  * WaW pod in cloud FA \@John
  * How object updates work \@zheng
  ## Notes
  * Jack\'s demo \-\- show the creator in object previews\! We\'ll also add execution\/viewing\/editing metadata based on object type\.
  * Noah collecting feedback from teams users\. There\'s a catch\-22 when onboarding \- need other people to be using Warp Drive\, more useful once there\'s content\.
  * Interesting in starring\/favoriting workflows \(teams with lots of them\)\; using workflows in vim\, via aliases\, and in other contexts
  * Kicking off Warp At Work pod as part of cloud FA\, led by Jeff
  * Scrolling in the Warp Drive index is slow \(theory\: we re\-sort on every render\, and have lots of objects\)
  * Discussion on whether or not permadeletion blocks launching untrashing\. We\'ll sync offline and decide if this is the case and how we want to update copy\. The PRD plan was to roll out permadeletion and trashing together\, and permadelete all previously\-trashed objects immediately before\.
  ### How do object content updates work\?
  * Product requirements\: offline creation and editing of offline\-created objects\; local state always immediately reflects the outcome of the last action
  * The server has the authoritative state of each object\. If there\'s a conflict \(e\.g\. because you lost internet\)\, we let you copy out your changes \(for notebooks\)\, but the server version still wins\. For workflows\, the server version is chosen automatically \(because of the form UI\)\.
  * \`content\_last\_updated\_at\` is a DB\-determined timestamp \(so no clock skew\)\. In order for the server to accept an update\, the client\'s revision timestamp must be \>\= content\_last\_updated\_at\.
  * There are 2 ways for a client to get updates\: RTC messages and explicit fetches \(periodic or from initial load\)
  * When updating\: first update the CloudModel \(in memory\)\, then update SQLite \(to prevent data loss\)\, then add to SyncQueue
  * Next Week\: How we\'re planning to make the cloud code and APIs more generic\!
  # Aug 4
  ## Updates \(\#focus\-area\-cloud\-updates on slack\)
  ## Demos
  \[Noah\] Can we get a volunteer for Performance Analysis \-\> Notebook
  ## Metrics \/ user feedback \@Noah
  * [https\:\/\/warp\.metabaseapp\.com\/dashboard\/166\-warp\-drive\-dashboard\-all\-usage](https://warp.metabaseapp.com/dashboard/166-warp-drive-dashboard-all-usage)
  * [https\:\/\/warp\.metabaseapp\.com\/dashboard\/35\-warp\-teams\-dashboard](https://warp.metabaseapp.com/dashboard/35-warp-teams-dashboard)
  ## Announcements \& Discussion
  * Warp Drive Mandate [https\:\/\/docs\.google\.com\/document\/d\/1R96B7Oj\-ikZ\-As59hwuEghlE2epq\-16F3cpj5P3Qriw\/edit](https://docs.google.com/document/d/1R96B7Oj-ikZ-As59hwuEghlE2epq-16F3cpj5P3Qriw/edit)
  * 20\% time \- how are we doing on this\?
  * Syncing non\-content updates \@Ian and \@Liam
  ## Notes
  * Ben has a demo\! Let\'s see\. Ooh\, it\'s viewing a \.md file in Warp\! And commands are executable\! This is *HUGE*
  * User feedback from Noah\:
   version control is super important \(not necessarily with git\)

   rendering layer for other types of docs \(Confluence\, Notion\, etc\.\)

   object metadata \/ sorting \/ syntax highlighting in workflow editor \/ autocompletions

   low awareness of \"Save As Workflow\"\. should prioritize auto\-detection\?

  * How often is there an existing workflow that your teammate made that you\'re not aware of\?
  * Zheng\: make sure you\'re thinking about objects as generically as possible\! This is more important with the new WD mandate
  * Zheng\: more knowledge sharing will happen in this meeting re\: our cloud architecture\, so there are more people who can review things and make sure they\'re being done the right way
  * Ian and Liam are sharing a cool doc about cloud object metadata\!
  * Jeff can\'t wait for alt\-backspace to delete words at a time in notebooks


title: Send Custom Build to Users
data:
  If you're  working on a bug fix or otherwise want users to try out a commit before it's on stable, you can send them a custom Warp build:
   Follow the steps in the Release Cop Instructions to [cherry-pick a commit onto stable](https://docs.google.com/document/d/1qxvgiy9Pj631YUADDBvsF7I1zL6d_OQMATsBmaYiYoo/edit#heading=h.ols4bt7yuvw9](https://docs.google.com/document/d/1qxvgiy9Pj631YUADDBvsF7I1zL6d_OQMATsBmaYiYoo/edit#heading=h.ols4bt7yuvw9)

   Find the new release candidate version in the **Cut New Release Candidate** workflow output (it should be in the "Bundle and Upload" sub-workflow under the "Upload DMG to Google Cloud Storage" step). Alternatively it should be the most recent [GitHub release]([https://github.com/warpdotdev/warp-internal/releases](https://github.com/warpdotdev/warp-internal/releases).

   Find the release DMG in the warp-releases GCS bucket: [https://console.cloud.google.com/storage/browser/warp-releases](https://console.cloud.google.com/storage/browser/warp-releases)

   Send users the public URL for the DMG (this has to be the public GCS URL, not the GitHub release URL or the authenticated GCS URL)


title: README.md
data:
  # Develop Documentation

  This page contains internal documentation for development.

  ## Code Signing

  This repository follows the [codesiging.guide](https://codesigning.guide/) in combination with [fastlane match](https://docs.fastlane.tools/actions/match/).
  Therefore the sample apps use manual code signing, see [fastlane docs](https://docs.fastlane.tools/codesigning/xcode-project/):
  > In most cases, fastlane will work out of the box with Xcode 9 and up if you selected manual code signing and choose a provisioning profile name for each of your targets.

  Reach out to @philipphofmann if you need access to the match git repository.

  ## Unit Tests with Thread Sanitizer

  CI runs the unit tests for one job with thread sanitizer enabled to detect race conditions.
  The Test scheme of Sentry uses `TSAN_OPTIONS` to specify the [suppression file](../Tests/ThreadSanitizer.sup) to ignore false positives or known issues.
  It's worth noting that you can use the `$(PROJECT_DIR)` to specify the path to the suppression file.
  To run the unit tests with the thread sanitizer enabled in Xcode click on edit scheme, go to tests, then open diagnostics, and enable Thread Sanitizer.

  ### Further Reading

  * [ThreadSanitizerSuppressions](https://github.com/google/sanitizers/wiki/ThreadSanitizerSuppressions)
  * [Running Tests with Clang's AddressSanitizer](https://pspdfkit.com/blog/2016/test-with-asan/)
  * [Diagnosing Memory, Thread, and Crash Issues Early](https://developer.apple.com/documentation/xcode/diagnosing-memory-thread-and-crash-issues-early)
  * [Stackoverflow: ThreadSanitizer suppression file with Xcode](https://stackoverflow.com/questions/38251409/how-can-i-suppress-thread-sanitizer-warnings-in-xcode-from-an-external-library)

  ## UI Tests

  CI runs UI tests on simulators via the `test.yml` workflow, and on devices via `saucelabs-UI-tests.yml`. All are run for each PR, and Sauce Labs tests also run on a nightly cron schedule.

  ### Saucelabs

  You can find the available devices on [their website](https://saucelabs.com/platform/supported-browsers-devices). Another way to check their available devices is to go to [live app testing](https://app.saucelabs.com/live/app-testing), go to iOS-Swift and click on choose device. This brings the full list of devices with more details.

  ### Performance benchmarking

  Once daily and for every PR via [Github action](../.github/workflows/benchmarking.yml), the benchmark runs in Sauce Labs, on a [high-end device](https://github.com/getsentry/sentry/blob/8986f81e19f63ee370b1649e08630c9b946c87ed/src/sentry/profiles/device.py#L43-L49) we categorize. Benchmarks run from an XCUITest (`PerformanceBenchmarks` target) using the iOS-Swift sample app, under the `iOS-Swift-Benchmarking` scheme. [`PerformanceViewController`](../Samples/iOS-Swift/iOS-Swift/ViewControllers/PerformanceViewController.swift) provides a start and stop button for controlling when the benchmarking runs, and a text field to marshal observations from within the test harness app into the test runner app. There, we assert that the P90 of all trials remains under 5%. We also print the raw results to the test runner's console logs for postprocessing into reports with `//scripts/process-benchmark-raw-results.py`.

  #### Test procedure

  - Tap the button to start a Sentry transaction with the associated profiling.
  - Run a loop performing large amount of calculations to use as much CPU as possible. This simulates something an app developer would want to profile in a real world scenario.
  - While benchmarking, run a sampling profiler at 10 Hz to calculate the CPU usage of each thread, in particular the Sentry profiler's, to calculate its relative usage.
  - Tap the button to stop the transaction after waiting for 15 seconds.
  - Calculate the total time used by app threads and separately, the profiler's thread. Keep separated by system call and user call times.
  - Write these four values as CSV into the text field accessible as an XCUIElement in the runner app.

  #### Test Plan

  - Run the procedure 20 times, then assert that the 90th percentile remains under 5% so we can be alerted via CI if it spikes.
      - Sauce Labs allows relaxing the timeout for a suite of tests and for a `XCTestCase` subclass' collection of test case methods, but each test case in the suite must run in less than 15 minutes. 20 trials takes too long, so we split it up into multiple test cases, each running a subset of the trials. 
      - This is done by dynamically generating test case methods in `SentrySDKPerformanceBenchmarkTests`, which is necessarily written in Objective-C since this is not possible to do in Swift tests. By doing this dynamically, we can easily fine tune how we split up the work to account for changes in the test duration or in constraints on how things run in Sauce Labs etc.

  ## Auto UI Performance Class Overview

  ![Auto UI Performance Class Overview](./auto-ui-performance-tracking.svg)

  ## Performance API Overview

  ![Performance API Overview](./performance-api.svg)

  ## Generating classes

  You can use the `generate-classes.sh` to generate ViewControllers and other classes to emulate a large project. This is useful, for example, to test the performance of swizzling in a large project without having to check in thousands of lines of code.

  ## Generating Diagrams

  The diagrams are created with [PlantUml](http://plantuml.com). The advantage of PlantUml
  over other diagram tools is that you describe the diagrams with text, and you don't have
  to worry about UML and layout, which can be time-consuming for changes. Furthermore, the
  diagrams can be stored in git.

  With [Visual Studio Code](https://code.visualstudio.com/) and the
  [PlantUml Plugin](https://marketplace.visualstudio.com/items?itemName=jebbs.plantuml#user-content-use-plantuml-server-as-render)
  you can create diagrams, view them and export them. If you don't want to use Visual Studio Code,
  there are many [alternatives](http://plantuml.com/running).

  For learning the syntax and quickly playing around you can check out [Plant Text](https://www.planttext.com/).

  ### Visual Studio Code Setup

  Visual Studio Code needs a rendering engine for PlantUml. We recommend using the following Docker image:

  ```sh
  docker run -d -p 8080:8080 plantuml/plantuml-server:jetty
  ```

  To ensure the rendering server is running properly, visit with `localhost:8080`.

  Finally, you have to configure the rendering server in Visual Studio Code. For this, open the settings of Visual Studio Code. Choose `Extensions > PlantUML configuration`. Click on `Edit in settings.json`. Then paste the following into the config:

  ```json
  {
    "plantuml.server": "http://localhost:8080",
    "plantuml.render": "PlantUMLServer"
  }
  ```

  Save the settings and you should be able to render a diagram.

  You can find the official guide here: [configure a rendering server](https://marketplace.visualstudio.com/items?itemName=jebbs.plantuml#user-content-use-plantuml-server-as-render).

  ## Decision Log

  ### Not capturing screenshots for crashes

  Date: April 21st 2022
  Contributors: @philipphofmann, @brustolin

  We decided against capturing screenshots for crashes because we must only call [async-safe functions](https://man7.org/linux/man-pages/man7/signal-safety.7.html) in signal handlers. Capturing a screenshot requires Objcetive-C code, which is not async safe.
  We could create the crash report first, write it to disk and then call Objective-C to get the screenshot. The outcome in such a scenario would be undefined, potentially breaking other signal handlers. We decided against this approach because we don't want to break the contract of signal handlers only calling async-safe functions.

  Related links:

  - https://github.com/getsentry/sentry-cocoa/pull/1751


title: BOD demo
data:
  ## Step 1\: One\-time setup
  [This is my doc](https://github.com/warpdotdev/warp-internal/blob/master/app/src/persistence/README.md) 
  If you\'ve never run the app before locally\, you\'ll have to create the app support dir for your local app\.
  ```
  mkdir -p /Users/$USER/Library/Application Support/warp
  ```
  Additionally\, the sqlite3 binary is useful in development\. The one on your Macbook is ok\, but likely will be missing some basic language features\. You can grab the latest binary from the official website [https\:\/\/www\.sqlite\.org\/download\.html](https://www.sqlite.org/download.html)\. Note that you\'ll have to approve it to be run in your mac system preferences\.
  abcdef
  ## Step 2\: Write the migration
  ```
  diesel migration generate {{description}}
  ```
  This will create a new folder with an up\.sql and down\.sql\.


title: README.md
data:
  # Carthage Samples

  This directory contains samples to validate installing the SDK via Carthage.

  Carthage can resolve a dependency by downloading the source code into `Carthage/Checkouts` or downloading a pre-compiled framework. The library authors can either attach the pre-compiled framework to a GitHub release or use a [binary project specification][1] for binary-only frameworks that don't provide the source code.
  Carthage encourages its users [to use XCFrameworks][2] since version 0.37.0, released in January 2021. The SentrySDK also still supports using normal frameworks.

  Given the above, there are three different ways of installing a dependency via Carthage:

  1. pre-compiled XCFramework
  2. pre-compiled framework
  3. downloading the source code

  Since Carthage only downloads the source code if no pre-compiled binaries are available and we upload these binaries for every release, we only have to validate the first two.

  [1]: https://github.com/Carthage/Carthage/blob/master/Documentation/Artifacts.md#binary-project-specification
  [2]: https://github.com/Carthage/Carthage#getting-started

  Take a look at [GitHub Actions](../../.github/workflows/buildandtest.yml) to see how the validation works.


title: Testing Warp Functionality over SSH
data:
  # Pre\-req\: Install Docker
  ```warp-runnable-command
  brew install --cask docker
  ```
   Open the Docker desktop app\. This is necessary to create the symbolic links that will make the docker CLI available\.
  # Running Warp over SSH
  There\'s a workflow called \"Build image and start container for SSH testing\" in this folder\.
  ```warp-embedded-object
  ---
  id: Workflow-VoTGs3HZx8C3DPvH9DUViK

  ```
  After that\, you may SSH in as `bash@0.0.0.0` or `zsh@0.0.0.0`\. It\'ll prompt for a password which is password for these VMs\.
  ```warp-runnable-command
  ssh bash@0.0.0.0
  ```
  After you\'ve built the image\, you can just launch the container again with the second command in the workflow\.
  Note that you can only have one docker container in your system that has port 22\.
  ## More advanced use
  Sometimes SSH users have issues based on their SSH server configs which is usually \"\/etc\/ssh\/sshd\_config\" \(this is also the case in Ubuntu\, which the Dockerfile in this repo uses\)\. If you need to edit it\, you\'ll have to reboot the SSH daemon afterwards to have the changes reflected with \"sudo service ssh restart\"\. This will cause the container to be stopped\, and you\'ll have to restart it in the Docker Desktop app \(click the play button\) in order to restart it with the new config\.


title: LICENSE.md
data:
  The MIT License (MIT)

  Copyright (c) 2015 Sentry

  Permission is hereby granted, free of charge, to any person obtaining a copy
  of this software and associated documentation files (the "Software"), to deal
  in the Software without restriction, including without limitation the rights
  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
  copies of the Software, and to permit persons to whom the Software is
  furnished to do so, subject to the following conditions:

  The above copyright notice and this permission notice shall be included in all
  copies or substantial portions of the Software.

  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
  SOFTWARE.


title: CHANGELOG.md
data:
  # Changelog

  ## 7.27.1

  ### Fixes

  - Add app start measurement to first finished transaction (#2252)
  - Return SentryNoOpSpan when starting a child on a finished transaction (#2239)
  - Fix profiling timestamps for slow/frozen frames (#2226)

  ## 7.27.0

  ### Features

  - Report [start up crashes](https://docs.sentry.io/platforms/apple/guides/ios/) (#2220)
  - Add segment property to user (#2234)
  - Support tracePropagationTargets (#2217)

  ### Fixes

  - Correctly attribute enterprise builds (#2235)

  ## 7.26.0

  ### Features

  - [Core Data Tracking](https://docs.sentry.io/platforms/apple/performance/instrumentation/automatic-instrumentation/#core-data-tracking) is stable (#2213)
  - [File I/O Tracking](https://docs.sentry.io/platforms/apple/performance/instrumentation/automatic-instrumentation/#file-io-tracking) is stable (#2212)
  - Add flush (#2140)
  - Add more device context (#2190)

  ### Fixes

  - Sentry-trace header incorrectly assigned to http requests (#2167)
  - Use the `component` name source for SentryPerformanceTracker (#2168)
  - Add support for arm64 architecture to the device context (#2185)
  - Align core data span operations (#2222)

  ## 7.25.1

  ### Performance Improvements

  - Prewarmed app start detection (#2151)

  ## 7.25.0

  ### Features

  - Users can [customize the error description](https://docs.sentry.io/platforms/apple/usage/#customizing-error-descriptions) shown in the Sentry UI by providing an NSDebugDescriptionErrorKey value in the error user info dictionary. (#2120)
  - Add support for dynamic library (#1726)

  ### Fixes

  - Can't find app image when swizzling (#2124)
  - Crash with screenshot is reported twice (#2134)
  - Setting SDK name through `options[sdk][name]` shouldn't clear version (#2139)

  ## 7.24.1

  ### Fixes

  - Remove Media Library Permission check from permission observer (#2123)

  ## 7.24.0

  ### Features

  - App permissions are now also included when running from an app extension (#2106)
  - Report App Memory Usage (#2027)
  - Include app permissions with event (#1984)
  - Add culture context to event (#2036)
  - Attach view hierarchy to events (#2044)
  - Clean up SentryOptions: added `enableCrashHandler` and deprecated `integrations` (#2049)
  - Integrations send the [transaction name source](https://develop.sentry.dev/sdk/event-payloads/transaction/#transaction-annotations) (#2076)
  - Added extra logs when creating automatic transactions and spans (#2087)

  ### Fixes

  - Fix Swift 5.5 compatibility (#2060)
  - Add span finish flag (#2059)
  - SentryUser.userId should be nullable (#2071)
  - Send time zone name, not abbreviation (#2091)
  - Use a prime number for the profiler's sampling rate to reduce the potential for [lock-step](https://stackoverflow.com/a/45471031) issues (#2055).
  - Improve App Hangs detection (#2100)
  - Send `environment` set from `SentryOptions` or `configureScope` with profiling data (#2095)

  ## 7.24.0-beta.0

  ### Features

  - Report App Memory Usage (#2027)
  - Include app permissions with event (#1984)
  - Add culture context to event (#2036)
  - Attach view hierarchy to events (#2044)
  - Clean up SentryOptions: added `enableCrashHandler` and deprecated `integrations` (#2049)
  - Integrations send the [transaction name source](https://develop.sentry.dev/sdk/event-payloads/transaction/#transaction-annotations) (#2076)
  - Added extra logs when creating automatic transactions and spans (#2087)

  ### Fixes

  - Fix Swift 5.5 compatibility (#2060)
  - Add span finish flag (#2059)
  - SentryUser.userId should be nullable (#2071)
  - Send time zone name, not abbreviation (#2091)
  - Use a prime number for the profiler's sampling rate to reduce the potential for [lock-step](https://stackoverflow.com/a/45471031) issues (#2055).
  - Improve App Hangs detection (#2100)
  - Send `environment` set from `SentryOptions` or `configureScope` with profiling data (#2095)

  ## 7.23.0

  ### Features

  - Add sampling configuration for profiling (#2004)
  - Add transaction to baggage and trace headers (#1992)

  ### Fixes

  - Log empty samples instead of collecting stacks for idle threads (#2013)
  - Remove logging that could occur while a thread is suspended (#2014)
  - Handle failure to read thread priority gracefully (#2015)
  - Fix address sanitizer compilation error (#1996)

  ## 7.22.0

  ### Features

  - Read free_memory when the event is captured, not only at SDK startup (#1962)
  - Provide private access to SentryOptions for hybrid SDKs (#1991)

  ### Fixes

  - Remove Sentry keys from cached HTTP request headers (#1975)
  - Collect samples for idle threads in iOS profiler (#1978)
  - Fix removeNonSdkFrames working incorrectly for os users named sentry(#2002)
  - Don't override already-set timestamp when finishing Span (#1993)
  - Respect existing baggage header instead of overwriting it (#1995)

  ## 7.21.0

  ### Features

  - Enhance the UIViewController breadcrumbs with more data (#1945)
  - feat: Add extra app start span (#1952)
  - Add enableAutoBreadcrumbTracking option (#1958)
  - Automatic nest spans with the UI life cycle (#1959)
  - Upload frame rendering timestamps to correlate to sampled backtraces (#1910)
  - Remove PII from auto-generated core data spans (#1982)

  ### Fixes

  - Don't track OOMs for simulators (#1970)
  - Properly sanitize the event context and SDK information (#1943)
  - Don't send error 429 as `network_error` (#1957)
  - Sanitize Span data (#1963)
  - Deprecate not needed option `sdkInfo` (#1960)
  - Crash in profiling logger (#1964)

  ## 7.20.0

  ### Features

  - Add screenshot at crash (#1920)
  - Track timezone changes as breadcrumbs (#1930)
  - Add sample rate in the baggage header, remove Userid and Transaction (#1936)

  ## 7.19.0

  ### Features

  - Add main thread ID to profiling payload (#1918)
  - Add App Hangs tracking (#1906)

  ### Fixes

  - Remove WebKit optimization check (#1921)
  - Detect prewarmed starts with env variable (#1927)

  ## 7.18.1

  ### Fixes

  - Fix high percentage of slow frames (#1915)

  ## 7.18.0

  ### Features

  - Replace tracestate header with baggage (#1867)

  ### Fixes

  - Discard long-lasting auto-generated transactions (#1903)
  - Unset scope span when finishing idle transaction (#1902)
  - Set max app start duration to 60s (#1899)
  - Screenshot wrongly attached in crash events (#1901)

  ## 7.17.0

  ### Features

  - Implement description for SentryBreadcrumb (#1880)

  ### Fixes

  - Propagate configured SDK info from options to events (#1853)
  - Stop reporting pre warmed app starts (#1896)

  ## 7.16.1

  ### Fixes

  - Fix reporting wrong OOM when starting SDK twice (#1878)
  - Fix JSON conversion error message (#1856)
  - Transaction tag and data serialization (#1826)

  ## 7.16.0

  ### Features

  - UI event transactions for clicks (#1784)
  - Collect queue label information for profiles (#1828)
  - Use the macho format for debug information in Profiling (#1830)
  - Allow partial SDK info override (#1816)

  ### Fixes

  - Hub uses its scope (#1821)

  ## 7.15.0

  ### Features

  - Add profile data category for rate limiting (#1799)
  - Allow setting SDK info with Options initWithDict (#1793)
  - Remove ViewController name match for swizzling (#1802)

  ### Fixes

  - Apply patch for SentryCrashCachedData (#1790)
  - Fix getting class data mask in SentryCrash (#1788)
  - Use pod_target_xcconfig for Podspec #1792
  - Case sensitive header import error (#1794)
  - Parsing of output from backtrace_symbols() (#1782)

  ## 7.14.0

  - fix: User feedback crash (#1766)
  - feat: Attach screenshots for errors (#1751)
  - fix: Remove authenticated pointer stripping for iOS backtraces (#1757)
  - perf: Filter binary images on Sentry Crash (#1767)
  - fix: NSURL warning during SDK initialization (#1764)

  ## 7.13.0

  If you are using self-hosted Sentry, this version requires Sentry version >= [21.9.0](https://github.com/getsentry/relay/blob/master/CHANGELOG.md#2190)
  to work or you have to manually disable sending client reports via the `sendClientReports` option.

  - feat: Add Client Reports (#1733)
  - fix: enableProfiling option via initWithDict (#1743)

  ## 7.12.0

  ### Important notice

  This release contains a fix for the sampling of transactions. The SDK applied both sample rates for events and transactions when capturing transactions. Previously, when setting sampleRate to 0.0, the SDK would discard all transactions.
  This is fixed now by ignoring the sampleRate for transactions. If you use custom values for sampleRate and traceSampleRate or traceSampler, this change will have an impact on you.

  If you are using profiling and self-hosted Sentry, this version requires Sentry version >= [22.3.0](https://github.com/getsentry/relay/releases/tag/22.3.0).

  ### Various fixes & improvements

  - fix: Avoid race condition in SentryCrash (#1735)
  - fix: Possible endless loop for onCrashedLastRun (#1734)
  - fix: Wrongly sampling transactions (#1716)
  - feat: Add flag for UIViewControllerTracking (#1711)
  - feat: Add more info to touch event breadcrumbs (#1724)
  - feat: Add support for profiling on iOS (#1652) by @armcknight

  ## 7.12.0-beta.0

  ### Various fixes & improvements

  - feat: Add support for profiling on iOS (#1652) by @armcknight

  ## 7.11.0

  - feat: Add CoreData performance tracking (#1682)
  - fix: Detecting ANRs as false OOMs (#1695)

  ## 7.10.2

  - fix: Crash in UIViewControllerSwizzling (#1692)

  ## 7.10.1

  - fix: Swizzling UIViewControllers crash (#1670)
  - feat: Expose Installation ID for Hybrid SDKs (#1680)
  - fix: SentryNSURLSessionTaskSearch using invalid nil parameter with NSURLSession (#1669)

  ## 7.10.0

  - fix: Always tracks App start for Hybrid SDKs (#1662)
  - feat: Send SDK integrations (#1647)
  - fix: Don't track OOMs for unit tests (#1651)
  - fix: Add verification for vendor UUID in OOM logic (#1648)
  - fix crash in dirContentsCount() when dir == NULL (#1658)

  ## 7.9.0

  - fix: Crash in SentrySubClassFinder (#1635)
  - fix: Set timestamp in init of event (#1629)
  - fix: Load invalid CrashState json (#1625)
  - feat: Auto I/O spans for NSData (#1557)

  ## 7.8.0

  - feat: Support for fatalError, assert, precondition (#1596)
  - feat: Include unfinished spans in transactions (#1592)
  - build: Disable NSAssertions for Release Builds (#1545)

  ## 7.7.0

  - feat: Send Locale with Events (#1539)

  ## 7.6.1

  - fix: iOS13-Swift build (#1522)
  - fix: Check task support on setState: (#1523)

  ## 7.6.0

  - fix: Create span for loadView (#1495)
  - feat: Add flag to control network requests breadcrumbs (#1505)
  - feat: Support for ignored signals with SIGN_IGN (#1489)

  ## 7.5.4

  - fix: Sending OOM when SDK is closed (#1487)

  ## 7.5.3

  - fix: Use swizzling instead of KVO for network tracking (#1452)

  ## 7.5.2

  ### Various fixes & improvements

  - fix: AppStart Transaction for Apps Using UIScenes (#1427) by @brustolin

  ## 7.5.1

  - fix: SentryOptions initWithDict type errors (#1443)
  - fix: Transaction default status should be OK (#1439)
  - fix: AppStart Transaction for Apps Using UIScenes (#1427)

  ## 7.5.0

  - feat: Add one flag to disable all swizzling (#1430)
  - fix: Dispatch Queue ARC Warning for RN (#1424)
  - fix: Dictionary Key cannot be nil, in SentryPerformanceTracer (#1434)

  ## 7.4.8

  - fix: Crash when objc_getClassList returns different values (#1420)

  ## 7.4.7

  - fix: Only enable APM when traceRate set (#1417)
  - fix: Crash in Span when Tracer nil (#1416)
  - fix: Instrumenting multiple UIViewControllers (#1409)
  - fix: Clear unfinished transaction in UIViewController APM (#1408)

  ## 7.4.6

  - fix: Crash when Getting Subclasses (#1396)

  ## 7.4.5

  - fix: Remove Check for Original Method Call When Swizzling (#1383)
  - fix: Init for Span, Tracer, Transaction (#1385)

  ## 7.4.4

  - fix: Crash for Call Should be on Main Thread (#1371)

  ## 7.4.3

  - fix: Crash for Custom ViewController init on iOS 15 (#1361)

  ## 7.4.2

  - fix: Crash When Observing Span Finished (#1360)

  ## 7.4.1

  - fix: HTTP instrumentation KVO crash (#1354)

  ## 7.4.0

  - feat: Add enableNetworkTracking flag (#1349)
  - fix: Memory Leak for Span (#1352)

  ## 7.3.0

  - fix: Trying to swizzle a class without a library name (#1332)

  ## 7.3.0-beta.0

  - fix: maxBreadcrumb zero crashes when adding (#1326)

  - feat: Add tracestate HTTP header support (#1291)

  ## 7.2.10

  - No documented changes.

  ## 7.2.9

  - Nothing

  ## 7.2.8

  - fix: SpanProtocol add setData for Swift (#1305)
  - fix: SentryHub not checking spanContext sampled value (#1318)

  ## 7.2.7

  - fix: Remove Trace Headers below iOS 14.0 (#1309)
  - fix: XCFramework output not preserving symlinks for macOS (#1281)

  ## 7.2.6

  - fix: Add Trace Headers below iOS 14.0 (#1302)

  ## 7.2.5

  - fix: Swizzling crash on iOS 13 (#1297)

  ## 7.2.4

  - fix: Sentry HTTP Trace Header Breaking Requests (#1295)
  - fix: Apps crash when using a URLSessionTask subclass with currentRequest unavailable (#1294)

  ## 7.2.3

  - fix: Build failure for SPM (#1284)
  - fix: Set app state on main thread when terminating (#1272)

  ## 7.2.2

  - fix: Crash when swizzling Nib UIViewController (#1277)

  ## 7.2.1

  This release fixes a crucial issue for auto performance instrumentation that caused crashes when using nested ViewControllers.

  - fix: Callback issue for auto performance (#1275)

  ## 7.2.0

  This release contains support for [auto performance instrumentation](https://docs.sentry.io/platforms/apple/performance/instrumentation/automatic-instrumentation/)
  for ViewControllers, HTTP requests, app start and slow and frozen frames.

  ### Auto Performance Features

  - feat: Auto UI Performance Instrumentation (#1105, #1150, #1136, #1139, #1042, #1264, #1164, #1202, #1231, #1242)
  - feat: Measure slow and frozen frames (#1123)
  - feat: Measure app start time (#1111, #1228)
  - feat: Add automatic HTTP request performance monitoring (#1178, #1237, #1250, #1255)
  - feat: Add tags to Sentry Span (#1243)
  - feat: Sub-millis precision for spans and events (#1234)
  - feat: Add Sentry Trace HTTP Header (#1213)

  ### More Features

  - feat: Add flag stichAsyncCode (#1172)
  - feat: Support XCFramework for Carthage (#1175)
  - feat: Add isEnabled property in SentrySDK (#1265)
  - feat: Add breadcrumbs for HTTP requests (#1258)
  - feat: Add clearAttachments to Scope (#1195)
  - feat: Expose tracked screen frames (#1262)
  - feat: Expose AppStartMeasurement for Hybrid SDKs (#1251)

  ### Fixes

  - fix: Remove invalid excludes from `Package.swift` (#1169)
  - fix: Compile failure with C99 (#1224)
  - fix: Race on session task (#1233)
  - fix: Remove tags and data if empty for Span (#1246)

  ### Performance Improvements

  - perf: Scope sync to SentryCrash (#1193)

  ## 7.2.0-beta.9

  - feat: Expose tracked screen frames (#1262)
  - feat: Expose AppStartMeasurement for Hybrid SDKs (#1251)
  - fix: Span serialization HTTP data in wrong place. (#1255)
  - feat: Add tags to Sentry Span (#1243)

  ## 7.2.0-beta.8

  - fix: Remove tags and data if empty for Span (#1246)
  - fix: Race Conditions in NetworkTracker (#1250)
  - fix: Don't create transactions for HTTP Requests. (#1237)

  ## 7.2.0-beta.7

  - fix: Swizzle only inApp ViewControllers (#1242)
  - feat: Add Sentry Trace HTTP Header (#1213)
  - feat: Sub-millis precision for spans and events (#1234)
  - fix: Race on session task (#1233)

  ## 7.2.0-beta.6

  - fix: ViewController swizzling before iOS 13 (#1231)
  - fix: AppStartMeasurement didFinishLaunching is nil (#1228)

  ## 7.2.0-beta.5

  - perf: Scope sync to SentryCrash (#1193)
  - fix: Compile failure with C99 (#1224)

  ## 7.2.0-beta.4

  - fix: Add viewAppearing to UIViewController spans (#1202)

  ## 7.2.0-beta.3

  - feat: Add automatic http request performance monitoring (#1178)
  - feat: Add clearAttachments to Scope (#1195)

  ## 7.2.0-beta.2

  - feat: Add flag stichAsyncCode (#1172)
  - feat: Support XCFramework for Carthage (#1175)
  - fix: Remove invalid excludes from `Package.swift` (#1169)

  ## 7.2.0-beta.1

  - feat: Measure slow and frozen frames (#1123)
  - fix: Operation names for auto instrumentation (#1164)

  ## 7.2.0-beta.0

  - feat: Measure app start time (#1111)
  - feat: Auto UI Performance Instrumentation (#1105, #1150, #1136, #1139, #1042)

  ## 7.1.4

  - fix: Compile failure with C99 (#1224)

  ## 7.1.3

  - feat: Add PrivateSentrySDKOnly (#1131)

  ## 7.1.2

  - fix: Serialization of span description (#1128)

  ## 7.1.1

  - No documented changes. This is the same as 7.1.0. Ignore this release and please use 7.1.2 instead.

  ## 7.1.0

  - fix: Remove SentryUnsignedLongLongValue (#1118)
  - feat: Expose SentryDebugImageProvider (#1094)
  - docs: Improve code doc on start and endSession (#1098)

  ## 7.0.3

  - fix: Add SentryMechanismMeta to Sentry.h (#1102)

  ## 7.0.2

  - No documented changes. This is the same as 7.0.1. Ignore this release and please use 7.0.3 instead.

  ## 7.0.1

  ref: Prefix TracesSampler with Sentry (#1091)

  ## 7.0.0

  This is a major bump with the [Performance Monitoring API](https://docs.sentry.io/platforms/apple/performance/) and [Out of Memory Tracking](https://docs.sentry.io/platforms/apple/configuration/out-of-memory/), many improvements and a few breaking changes.
  For a detailed explanation how to upgrade please checkout the [migration guide](https://docs.sentry.io/platforms/apple/migration/).

  ### Breaking Changes

  - ref: Add SentryMechanismMeta (#1048)
  - ref: Align SentryException with unified API (#1026)
  - ref: Remove deprecated SentryHub.getScope (#1025)
  - ref: Make closeCachedSessionWithTimestamp private (#1022)
  - ref: Improve envelope API for Hybrid SDKs (#1020)
  - ref: Remove currentHub from SentrySDK (#1019)
  - feat: Add maxCacheItems (#1017)
  - ref: SentryEvent.timestamp changed to nullable.
  - ref: Add read-only scope property to Hub (#975)
  - ref: Remove SentryException.userReported (#974)
  - ref: Replace SentryLogLevel with SentryLevel (#979)
  - fix: Mark frames as inApp (#956)

  ### Features

  - feat: Performance Monitoring API (#909, #977, #961, #932, #919, #992, #1065, #1042, #1079, #1061, #1069, #1066, #1040, #1084)
  - feat: Out Of Memory Tracking (#1001, #1015)
  - feat: Add close method to SDK (#1046)
  - feat: Add start and endSession to SentrySDK (#1021)
  - feat: Add urlSessionDelegate option to SentryOptions (#965)

  ### Fixes

  - ref: Set sample rates to default if out of range (#1074): When setting a value `SentryOptions.sampleRate` that is not >= 0.0 and <= 1.0 the SDK sets it to the default of 1.0.
  - fix: Release builds in CI (#1076)
  - perf: Avoid allocating dict in BreadcrumbTracker (#1027)
  - fix: Crash when passing garbage to maxBreadcrumbs (#1018)
  - fix: macOS version for Mac Catalyst (#1011)

  ## 7.0.0-beta.1

  ### Features and Fixes

  - ref: Set sample rates to default if out of range (#1074): When setting a value `SentryOptions.sampleRate` that is not >= 0.0 and <= 1.0 the SDK sets it to the default of 1.0.
  - feat: Add trace information from scope to event capture (#1065)
  - fix: SentryOptions.tracesSampleRate default value (#1069)
  - ref: Discard unfinished spans when capturing transaction (#1066)
  - ref: Make calls to customSamplingContext nonnull (#1061)
  - ref: Mark async call chains explicitly as such (#1071)
  - fix: fix: performance headers (#1079)
  - fix: performance headers (#1079)
  - fix: Release builds in CI (#1076)

  ## 7.0.0-beta.0

  - feat: Add close method to SDK #1046

  ## 7.0.0-alpha.5

  ### Breaking Changes

  - ref: Add SentryMechanismMeta #1048: Replaced dict `SentryMechanism.meta` with new class `SentryMechanismMeta`. Moved `SenryNSError` to `SentryMechanismMeta`.

  ### Features and Fixes

  - feat: Async callstacks are being tracked by wrapping the `dispatch_async` and related APIs. #998
  - feat: Add transaction to the scope #992
  - fix: Pass SentryTracer to span child #1040
  - feat: Add span to SentrySDK #1042
  - feat: Add urlSessionDelegate option to SentryOptions #965

  ## 7.0.0-alpha.4

  ### Breaking Changes

  - ref: Align SentryException with unified API #1026: Replaced `SentryException.thread` with `SentryException.threadId` and `SentryException.stacktrace`.
  - ref: Remove deprecated SentryHub.getScope #1025: Use `SentryHub.scope` instead.
  - ref: Make closeCachedSessionWithTimestamp private #1022
  - ref: Improve envelope API for Hybrid SDKs #1020: We removed `SentryClient.storeEnvelope`, which is reserved for Hybrid SDKs.
  - ref: Remove currentHub from SentrySDK #1019: We removed `SentrySDK.currentHub` and `SentrySDK.setCurrentHub`. In case you need this methods, please open up an issue.
  - feat: Add maxCacheItems #1017: This changes the maximum number of cached envelopes from 100 to 30. You can configure this number with `SentryOptions.maxCacheItems`.

  ### Features and Fixes

  - perf: Avoid allocating dict in BreadcrumbTracker #1027
  - feat: Add start and endSession to SentrySDK #1021
  - fix: Crash when passing garbage to maxBreadcrumbs #1018
  - fix: OutOfMemory exception type #1015
  - fix: macOS version for Mac Catalyst #1011

  ## 7.0.0-alpha.3

  - feat: Out Of Memory Tracking #1001

  ## 7.0.0-alpha.2

  ### Features

  - feat: Performance Monitoring API (#909, #977, #961, #932, #919)

  ### Breaking Changes

  - SentryEvent.timestamp changed to nullable.

  ## 7.0.0-alpha.1

  Features and fixes:

  - ref: Add read-only scope property to Hub #975

  ### Breaking Changes

  - ref: Add read-only scope property to Hub #975
  - ref: Remove SentryException.userReported #974
  - ref: Replace SentryLogLevel with SentryLevel #978

  ## 7.0.0-alpha.0

  **Breaking Change**: This version introduces a change to the grouping of issues. The SDK now sets the `inApp`
  flag for frames originating from only the main executable using [CFBundleExecutable](https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleexecutable).
  In previous versions, all frames originating from the application bundle were marked as `inApp`. This had the
  downside of marking frames of private frameworks inside the bundle as `inApp`. This problem is fixed now.
  Applications using static frameworks shouldn't be affected by this change.
  For more information on marking frames as inApp [docs](https://docs.sentry.io/platforms/apple/data-management/event-grouping/stack-trace-rules/#mark-in-app-frames).

  - fix: Mark frames as inApp #956

  ## 6.2.1

  - fix: Redundant x29 GP register on arm64 and UBSan crash #964

  ## 6.2.0

  With this version, Sentry groups errors by domain and code. MyDomain 1 and MyDomain 2
  are going to be two separate issues in Sentry. If you are using self-hosted Sentry,
  it requires Sentry version >= v21.2.0 to work. Staying on Sentry < v21.2.0 and upgrading
  to this version of the SDK won't do any damage. Sentry will group like in previous
  versions, but you will see a new group because we slightly changed the wording. If you
  are using sentry.io no action is needed. In case you are not satisfied with this change,
  you can take a look at
  [SDK fingerprinting](https://docs.sentry.io/platforms/apple/data-management/event-grouping/sdk-fingerprinting/)
  to group by domain only.

  - fix: Use mechanism meta for error grouping #946
  - fix: Sanitize SentryMechanism.data on serialize #947
  - feat: Add error to SentryEvent #944
  - fix: Mark SentryEvent.message as Nullable #943
  - fix: Stacktrace inApp marking on Simulators #942
  - feat: Group NSError by domain and code #941
  - fix: Discard Sessions when JSON is faulty #939
  - feat: Add sendDefaultPii to SentryOptions #923

  ## 6.1.4

  - fix: Sessions for Hybrid SDKs #913

  ## 6.1.3

  - fix: Capture envelope updates session state #906

  ## 6.1.2

  - fix: Clash with KSCrash functions #905

  ## 6.1.1

  - fix: Duplicate symbol clash with KSCrash #902

  ## 6.1.0

  - perf: Improve locks in SentryScope #888

  ## 6.1.0-alpha.1

  - fix: Change maxAttachmentSize from MiB to bytes #891
  - feat: Add maxAttachmentSize to SentryOptions #887
  - ref: Remove SentryAttachment.isEqual and hash #885
  - ref: Remove SentryScope.isEqual and hash #884

  ## 6.1.0-alpha.0

  - feat: Add basic support for attachments #875

  ## 6.0.12

  - fix: Crash in SentrySession.serialize #870

  ## 6.0.11

  - perf: Drop global dispatch queue (#869)
  - fix: Increase precision of iso8601 date formatter #860

  ## 6.0.10

  - feat: Add onCrashedLastRun #808
  - feat: Add SentrySdkInfo to SentryOptions #859

  ## 6.0.9

  - fix: Serialization of SentryScope #841
  - fix: Recrash parsing in SentryCrash #850
  - fix: Not crash during crash reporting #849

  ## 6.0.8

  - feat: Add storeEnvelope on SentryClient #836
  - perf: Async synching of scope on to SentryCrash #832

  ## 6.0.7

  - fix: Drop Sessions without release name #826
  - feat: Bring back SentryOptions.enabled #818
  - fix: Remove enum specifier for SentryLevel #822
  - feat: Send environment 'production' if nothing was set #825
  - fix: Typo for Swift name: UserFeedback #829

  ## 6.0.6

  - fix: Call beforeBreadcrumb for Breadcrumb Tracker #815

  ## 6.0.5

  - fix: Add eventId to user feedback envelope header #809
  - feat: Manually capturing User Feedback #804

  ## 6.0.4

  - fix: Sanitize UserInfo of NSError and NSException #770
  - fix: Xcode 12 warnings for Cocoapods #791

  ## 6.0.3

  - fix: Making SentrySdkInfo Public #788

  ## 6.0.2

  - fix: iOS 13.4 Runtime Crash #786
  - fix: Using wrong SDK name #782
  - feat: Expose `captureEnvelope` on the client #784
  - fix: Remove initWithJSON from SentryEvent #781
  - fix: Carthage for Xcode 12 #780
  - fix: Add missing SentrySdkInfo.h to umbrella header #779
  - ref: Remove event.json field #768

  ## 6.0.1

  - fix: Warning Duplicate build file in Copy Headers #761
  - fix: Warning when integrating SDK via Carthage #760
  - feat: Set installationId to userId if no user is set #757

  ## 6.0.0

  This is a major bump with lots of internal improvements and a few breaking changes.
  For a detailed explanation how to updgrade please checkout the [migration guide](https://docs.sentry.io/platforms/apple/migration/).

  Breaking changes:

  - fix: Make SentryMessage formatted required #756
  - feat: Add SentryMessage #752
  - feat: Replace passing nullable Scope with overloads #743
  - feat: Remove SentryOptions.enabled #736
  - fix: Public Headers #735
  - feat: Attach stacktraces to all events by default #705
  - feat: Replace NSNumber with BOOL in SentryOptions #719
  - feat: Enable auto session tracking per default #689
  - feat: Remove deprecated SDK inits #673
  - feat: Bump minimum iOS version to 9.0 #669
  - fix: Umbrella header #671
  - feat: Replace NSString for eventId with SentryId #668
  - feat: Use envelopes for sending events #650

  Features and fixes:

  - fix: Make public isEqual _Nullable #751
  - feat: Use error domain and code for event message #750
  - feat: Remove SDK frames when attaching stacktrace #739
  - fix: captureException crates a event type=error #746
  - fix: Setting environment for Sessions #734
  - feat: Crash event and session in same envelope #731
  - feat: Allow nil in setExtraValue on SentryScope to remove key #703
  - fix: Header Imports for the Swift Package Manager #721
  - fix: Async storing of envelope to disk #714
  - feat: Migrate session init for stored envelopes #693
  - fix: Remove redundant sdk options enable check in SentryHttpTransport #698
  - fix: Sending envelopes multiple times #687
  - fix: Rate limiting for cached envelope items #685
  - feat: Errors and sessions in the same envelope #686
  - feat: Implement NSCopying for SentrySession #683
  - fix: Crash when SentryClient is nil in SentryHub #681
  - feat: Send cached envelopes first #676

  ## 6.0.0-beta.2

  Breaking changes:

  - feat: Remove SentryOptions.enabled #736
  - fix: Public Headers #735

  Fix:

  - fix: Setting environment for Sessions #734

  ## 6.0.0-beta.1

  This release also enables by default the option `attackStacktrace` which includes
  the stacktrace in all events, including `captureMessage` by default.

  Breaking Changes:

  - feat: Attach stacktraces to all events by default #705

  Features and fixes:

  - feat: Crash event and session in same envelope #731
  - feat: Allow nil in setExtraValue on SentryScope to remove key #703

  ## 6.0.0-beta.0

  Breaking changes:

  - feat: Replace NSNumber with BOOL in SentryOptions #719

  Features and fixes:

  - fix: Header Imports for the Swift Package Manager #721
  - fix: Async storing of envelope to disk #714
  - feat: Migrate session init for stored envelopes #693
  - fix: Remove redundant sdk options enable check in SentryHttpTransport #698

  ## 6.0.0-alpha.0

  **Breaking Change**: This version uses the [envelope endpoint](https://develop.sentry.dev/sdk/envelopes/).
  If you are using an on-premise installation it requires Sentry version
  `>= v20.6.0` to work. If you are using sentry.io nothing will change and
  no action is needed. Furthermore, with this version
  [auto session tracking](https://github.com/getsentry/sentry-cocoa/blob/7876949ca78aebfe7883432e35727993c5c30829/Sources/Sentry/include/SentryOptions.h#L101)
  is enabled per default.
  [This feature](https://docs.sentry.io/product/releases/health/)
  is collecting and sending health data about the usage of your
  application.
  We are going to add the official migration guide in one of the next beta releases.

  Here is an overview of all the breaking changes:

  - feat: Enable auto session tracking per default #689
  - feat: Remove deprecated SDK inits #673
  - feat: Bump minimum iOS version to 9.0 #669
  - fix: Umbrella header #671
  - feat: Replace NSString for eventId with SentryId #668
  - feat: Use envelopes for sending events #650

  Other new features and fixes:

  - fix: Sending envelopes multiple times #687
  - fix: Rate limiting for cached envelope items #685
  - feat: Errors and sessions in the same envelope #686
  - feat: Implement NSCopying for SentrySession #683
  - fix: Crash when SentryClient is nil in SentryHub #681
  - feat: Send cached envelopes first #676

  ## 5.2.2

  - feat: Add crashedLastRun to SentrySDK #688

  ## 5.2.1

  - fix: Add IP address to user serialization #665
  - fix: Crash in SentryEnvelope.initWithEvent #643
  - fix: Build failure for Apple Silicon Macs #588
  - feat: capture userinfo from NSError and NSException #679

  ## 5.2.0

  - fix: nxgetlocalarch app store #651

  ## 5.1.10

  - fix: Crash when converting Recrash Report #627
  - feat: Add SdkInfo to Envelope Header #626
  - fix: Deserialize envelope with header and item #620
  - fix: Set LogLevel in startWithConfigureOptions #613

  ## 5.1.10-beta.0

  - fix: Abnormal sessions #607

  ## 5.1.9

  - fix: beforeSend callback in SentryClient #608

  ## 5.1.8

  - fix: Cocoapods build

  ## 5.1.7

  - fix: Overwriting stack trace for crashes #605
  - fix: Deployment target warning for Swift Package Manager for Xcode 12 #586

  ## 5.1.6

  - feat: Simplified SDK start #580
  - fix: Custom release name for crash reports #590

  ## 5.1.5

  - feat: Attach the stacktrace to custom events #583
  - fix: SentryCrashJSON encodeObject crash #576
  - feat: Added automatic breadcrumbs for system events #559

  ## 5.1.4

  - fix: Increase max report length #569
  - fix: Remove weak ref file contents #571

  ## 5.1.3

  - fix: UUID for SentryCrashReport is null #566

  ## 5.1.2

  - feat: Attach stacktrace of current thread to events #561

  ## 5.1.1

  - fix: Prefix categories methods with sentry #555
  - feat: Attach DebugMeta to Events #545
  - fix: Duplicate symbol for SentryMeta #549
  - feat: Set SUPPORTS_MACCATALYST to YES explicitly #547

  ## 5.1.0

  - fix: Make properties of Session readonly #541
  - fix: Remove MemoryWarningIntegration #537
  - fix: Avoid Implicit conversion in SentrySession #540
  - fix: Change SentryScope setTagValue to NSString #524

  ## 5.0.5

  - feat: Add remove methods for SentryScope #529
  - fix: Failing MacOS build #530
  - ref: Session values are unsigned #527

  ## 5.0.4

  - fix: End file at the right place with #ifdef #521

  ## 5.0.3

  - fix: Exit session with timestamp #518
  - feat: Add sentry_sanitize for NSArray #509

  ## 5.0.2

  - fix: Keep maximum rate limit #498
  - fix: Ignore unknown rate limit categories #497
  - fix: On app exit, close session as healthy #500

  ## 5.0.1

  - fix: Flakey concurrent test for RateLimits #493
  - fix: missing breadcrumbs data on hardcrash #492

  ## 5.0.0

  - GA of major version 5

  ## 5.0.0-rc.1

  - feat: Add support for mac catalyst #479
  - fix: RateLimitCategories #482
  - fix: RetryAfter treated like all categories #481
  - feat: RateLimiting for cached events and envelopes #480
  - fix: EnvelopeRateLimit init envelope with header #478

  ## 5.0.0-beta.7

  - feat: RateLimit for non cached Envelopes #476
  - fix: Use RateLimitCategoryError for events #470
  - feat: Store SentryEnvelopes in extra path #468
  - feat: Adds setUser to SentrySDK and SentryHub #467
  - feat: Add auto session starting for macOS #463
  - fix: Take release name from options #462
  - feat: Use new envelope endpoint #475
  - feat: App lifecycle events as breadcrumbs #474

  ## 5.0.0-beta.6

  - feat: RateLimit for sendAllStoredEvents #458
  - fix: Use maxBreadcrumbs from options #451
  - fix: Send vmaddr if available for apple crash reports #459

  ## 5.0.0-beta.5

  - fix: Limit number of breadcrumbs #450

  ## 5.0.0-beta.4

  - feat: Add Sentry initialization function 'start' #441
  - fix: Crashed sessions are marked as such #448

  ## 5.0.0-beta.3

  - fix: Persisting Scope with CrashReport
  - fix: Frame in app detection #438
  - fix: Session ending as Crashed #439

  ## 5.0.0-beta.2

  - fix: The order of how integrations are initialized (fixes not sending crashes on startup)
  - fix: Add missing header files to umbrella header

  ## 5.0.0-beta.1

  - feat: Added Session Feature
  - feat: New option `enableAutoSessionTracking` set to `true` if you want sessions to be enabled
  - feat: Add `_crashOnException:` to handle exceptions for AppKit apps on macOS

  ## 5.0.0-beta.0

  - feat: Added internal `captureEnvelope` method

  ## 5.0.0-alpha.0

  **_BREAKING_**: This is the first public release of our new `5.0.0` #339 version of the SDK.
  The majority of the public API of the SDK changed, now it's more streamlined with other Sentry SDKs and prepared for future updates.
  Please read the migration guide how to use the new SDK [MIGRATION.MD](MIGRATION.md)

  ## 4.5.0

  - fix: Mac Catalyst detection
  - fix: Add null checks in crash reporter
  - fix: Check type of key before use it as NSString (#383)
  - fix: Use rawKey to get object from dictionary (#392)
  - fix: Change instantiating SentryMechanism of unknown exception type (#385)

  ## 4.4.3

  - feat: Swift Package Manager support #352
  - fix: travis lane lint #345

  ## 4.4.2

  - feat: Prefer snprintf over sprintf #342

  ## 4.4.1

  - feat: Add support for custom context and event types

  ## 4.4.0

  - feat: Helper property on event to send raw payload

  ## 4.3.4

  - fix: #305

  ## 4.3.3

  - fix: 64 int conversion #296
  - fix: Extracting reason of NSException

  ## 4.3.2

  - fix: [SentryThread serialize] will crash when threadId is nil #292

  ## 4.3.1

  - ref: Make `event_id` all lowercase
  - feat: Emit log error in case no shared client is set and crash handler was started
  - ref: Renamed `Container+DeepSearch` to `Container+SentryDeepSearch`
  - ref: Renamed `NSData+Compression` to `NSData+SentryCompression`
  - ref: Renamed `NSDate+Extras` to `NSDate+SentryExtras`
  - ref: Renamed `NSDictionary+Sanitize` to `NSDictionary+SentrySanitize`

  ## 4.3.0

  - feat: Added `initWithOptions` function, it takes an Dictionary of key value. Possible values are `dsn`, `enabled`, `environment`, `release`, `dist`
  - feat: Added `enabled` on the `Client`
  - feat: Added `environment` on the `Client`
  - feat: Added `release` on the `Client`
  - feat: Added `dist` on the `Client`
  - ref: Renamed `NSError+SimpleConstructor.h` to `NSError+SentrySimpleConstructor.h`

  ## 4.2.1

  - fix: Add environment to Event in JavaScriptHelper

  ## 4.2.0

  - feat: Add `Client.shared?.trackMemoryPressureAsEvent()` to emit an event if application receives memory pressure notification
  - feat: `Client.shared?.enableAutomaticBreadcrumbTracking()` now adds a breadcrumb in case of memory pressure notification

  ## 4.1.3

  - Fix: WatchOS build

  ## 4.1.2

  - fix(react-native): Correctly label fingerprints for JS bridge. (#279)
  - Fix error for empty array creation (#278)
  - Fix NSInvalidArgumentException in SentryBreadcrumbStore (#272)

  ## 4.1.1

  - Add fingerprint support to JavaScript bridge
  - Fix internal variable naming conflict with KSCrash

  ## 4.1.0

  - Introduce `maxEvents` `maxBreadcrumbs` to increase the max count of offline stored assets

  ## 4.0.1

  - Fixes CocoaPods build to include C++ as a library #252

  ## 4.0.0

  - Moved KSCrash into Codebase while renaming it to SentryCrash.
    Removed KSCrash dep in Podspec.
    Still if you do not call `startCrashHandlerWithError` crash handlers will not be installed.

  **This should be safe to upgrade from 3.x.x, there are no code changes what so ever.
  If you are using CocoaPods or Carthage an update should take care of everything, if you were using the source code directly, make sure to remove KSCrash if you were using it.**

  We recommend updating if you experience any KSCrash related crashes since we fixed bunch of stuff directly in our codebase now.

  ## 3.13.1

  - Updated KSCrash project to SKIP_INSTALL

  ## 3.13.0

  - Update docs to use public DSN
  - Don't emit nslog if loglevel is none
  - Send new mechanism
  - Add transaction of current uiviewcontroller

  ## 3.12.4

  - Fixed a bug for empty timestamp if created from JavaScript

  ## 3.12.3

  - Fixed #239

  ## 3.12.2

  - Synchronize storing of breadcrumbs and events

  ## 3.12.1

  - Fixed and error in javascript helper for new exception structure

  ## 3.12.0

  - Fixed #235
  - Fixed #236

  ## 3.11.1

  - Fixed #231

  ## 3.11.0

  - Greatly improved handling for rate limiting see: #230
  - Added `shouldQueueEvent`
  - There is a hardlimit for offline stored events of 10 and 200 for breadcrumbs

  ## 3.10.0

  - This update will create a subfolder for each instance of SentryClient depending on the DSN.
    This also fixes a bug where under rare circumstances on MacOS for not sandboxed apps got sent with the wrong SentryClient.
    **We recommend updating to this version if you are running a un-sandboxed macOS app**
  - Fixes #216

  ## 3.9.1

  - Fixed #213

  ## 3.9.0

  - Added JavaScriptBridgeHelper for react-native, cordova SDK

  ## 3.8.5

  - Send breadcrumbs in the order in which they got created

  ## 3.8.4

  - Tick allow-app-extension-API-only box for Carthage builds

  ## 3.8.3

  - Fixed an issue where a crash and the actual event diverge in release version/ dist #218

  ## 3.8.2

  - Fixed #217
  - Fixed #214

  ## 3.8.1

  - Fixed failing test

  ## 3.8.0

  - Make KSCrash default CocoaPod subspec
  - macOS: Call super exception handler when crash happens
  - Added `sampleRate` parameter to configure the likelihood of sending an event [0.0-1.0]

  ## 3.7.1

  - Fixes a bug where stack trace is nil when snapshotting stacktrace

  ## 3.7.0

  - Bump KSCrash to `1.15.12`
  - Add `SentryCrashExceptionApplication` for macOS uncaught exception handling

  ## 3.6.1

  - Add `storeEvent` function, mainly used for `react-native`

  ## 3.6.0

  - Fixed a bug in crash Thread detection which caused the Sentry web interface to sometimes show the wrong culprit

  ## 3.5.0

  - Fixed https://github.com/getsentry/sentry-cocoa/issues/200 Make userId optional of `SentryUser`
  - Fixed https://github.com/getsentry/sentry-cocoa/issues/198

  ## 3.4.3

  - Initialize extra and tags in private instead of setter in Client init

  ## 3.4.2

  - Fixed #196

  ## 3.4.1

  Fixed messed up Travis build.

  ## 3.4.0

  Expose `sdk` property for `SentryEvent` to allow users to set specific SDK information. -> mainly used in react-native

  ## 3.3.3

  Remove stripping of \_\_sentry extra because it breaks if the event is serialized more than once.

  ## 3.3.2

  Fix `integrations` for `sdk` context.

  ## 3.3.1

  Pretty print json request when verbose logging is active.

  ## 3.3.0

  Change the way `extra` `tags` and `user` is stored.

  ## 3.2.1

  - Fixed #190
  - Fixed #191

  ## 3.2.0

  - Add `appendStacktraceToEvent` function in addition to `snapshotStacktrace` to add stacktraces reliably.

  ## 3.1.3

  - Bump KSCrash to `1.15.11`

  ## 3.1.2

  - Add support for SDK integrations

  ## 3.1.1

  - Prefix internal category function

  ## 3.1.0

  - Added new callback `shouldSendEvent` to make it possible to prevent the event from being sent.
  - Fixes #178

  ## 3.0.11

  - Fix `snapshotStacktrace` to also include `debug_meta` to fix grouping

  ## 3.0.10

  - Sanitize all extra's array before serialization (Convert NSDate -> NSString)

  ## 3.0.9

  - Change internal locking mechanism for swizzling

  ## 3.0.8

  - Use `KSCrash` `1.15.9` `Core` subspec which only uses bare minimum for Crash reporting
  - Fixes #174

  ## 3.0.7

  - Fix system name

  ## 3.0.6

  - Fix `NSNumber` properties in DebugMeta

  ## 3.0.5

  - Rename `RSSwizzle` to `SentrySwizzle`

  ## 3.0.4

  - Fix empty frames on specific crash

  ## 3.0.3

  - Fix carthage builds

  Bundled KSCrash into Sentry. Note that this is just for Carthage, CocoaPods knows how to link 2 dynamic frameworks together.

  ## 3.0.2

  - Fix Sentry dynamic framework

  ## 3.0.1

  - Fix carthage build

  ## 3.0.0

  This release is a rewrite of the existing codebase, `sentry-cocoa` now uses Objective-C instead of Swift.
  Please make sure to check out the docs since this update introduced many breaking changes.
  https://docs.sentry.io/clients/cocoa/

  `KSCrash` is now optional, you can use Sentry without it, we still recommend using KSCrash by default otherwise Sentry will not catch any crashes.

  ## 2.1.11

  - Fix swift 3 async operation -> Operation never got removed from queue due using private vars instead of setter

  ## 2.1.10

  - Fixed release naming to `bundleIdentifier`-`shortVersion`

  ## 2.1.9

  - Add support for distributions in sentry
  - Make `eventID` `var` instead of `let`

  ## 2.1.8

  - Update KSCrash

  ## 2.1.7

  - Fix duplicate symbols in crash report

    1884.42s user 368.70s system 171% cpu 21:55.70 total

  ## 2.1.6

  - Add additional Info about device

  ```
  ("app_identifier", bundleID)
  ("app_name", bundleName)
  ("app_build", bundleVersion)
  ("app_version", bundleShortVersion)
  ```

  ## 2.1.5

  - Only switflint in Xcode builds, do not while building with CARTHAGE

  ## 2.1.4

  - No longer automatically clear breadcrumbs when an event is sent

  ## 2.1.3

  - Set `ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES` back to `NO` since it prevents upload to iTunes Connect

  ## 2.1.2

  - Prefix react-native frames with `app://`

  ## 2.1.1

  - Update swiftlint to whitelist rules
  - Add app context

  ## 2.1.0

  - Added `addTag` `addExtra` function to `SentryClient` and `Event`
    e.g.:

  ```
  SentryClient.shared?.addExtra("key", value: "value")
  event.addTag("key", value: "value")
  ```

  - Fixed a bug where 64bit uInt got converted to 32bit
  - Added compatiblity for incomplete Crashreports from KSCrash
  - Added internal support for upcoming react-native support
  - Exposed `maxCrumbs` so the maximum amount of breadcrumbs can be adjusted

  ## 2.0.1

  - Fixed a bug with not sending `release` with event
  - Changed the way how swizzling works, there should not be a problem with e.g.: New Relic anymore

  ## 2.0.0 - Rename from SentrySwift to Sentry

  - We decided to rename `SentrySwift` to just `Sentry`

    Version `2.0.0` has the same features as `1.4.5`.
    The name of the Framework has been changed from:
    `import SentrySwift`
    to
    `import Sentry`
    Also in the `Podfile` you have to change to `pod Sentry` instead of `pod SentrySwift`.
    Everything else stayed the same.

  ## 1.4.5

  - Now sending `registers` with stacktrace for better symbolication results
  - Added `verbose` logging option which outputs raw events and crash reports
  - Add `relevant_address` to stacktrace
  - Extended `mechanism`
  - Add `build` to `release` e.g.: `1.0 (1337)`
  - Added `objcBeforeSendEventBlock` as equivalent to swifts `beforeSendEventBlock`

  ## 1.4.4

  - Removed `SentryClient.shared?.enableThreadNames` because KSCrash changed the mechanism on how threadnames are fetched. They will show up in sentry if available.
  - Now sending build number with every event.

  ## 1.4.3

  - Fixed an issue where properties of an event will be overwritten before sending
  - Added `SentryClient.shared?.enableThreadNames` variable which can be set to true in order to retrieve the thread names when a crash happens. Enable this on you own risk this could deadlock you app therefore its not yet officially documented.

  ## 1.4.2

  - Fixed Xcode 7 support

  ## 1.4.1

  - enable `searchThreadNames` to display thread names in sentry

  ## 1.4.0

  - Update KSCrash to 1.13.x

  **Warning**

  - Added namespace for Objc
    e.g.: `User` -> `SentryUser` but Xcode should suggest the new class names ... Swift code does not change

  ## 1.3.4

  - Store events now in `Library/Caches` instead of `Documents` folder

  ## 1.3.3

  - Add `RequestManager` for improved handling on many requests

  ## 1.3.2

  - Reuse `URLSession` when sending events
  - Optimize `BreadcrumbStore`

  ## 1.3.1

  - Default log level `.Error`
  - Don't strip filepath from frames
  - Add `reportReactNativeFatalCrash`

  ## 1.3.0

  - Moved `docs/` to this repo
  - You can now take a snapshot of the stacktrace and send it with your event ... see https://docs.sentry.io/clients/cocoa/advanced/#adding-stacktrace-to-message for more information
  - Added `beforeSendEventBlock` to change a event before sending it https://docs.sentry.io/clients/cocoa/advanced/#change-event-before-sending-it

  ## 1.2.0

  - Reverse frames in stacktrace
  - Remove in_app from stacktrace

  ## 1.1.0

  - Added `SentryClient.shared?.enableAutomaticBreadcrumbTracking()` for iOS which sends all actions and viewDidAppear as breadcrumbs to the server
  - Fixed podspec for all target
  - Improved UserFeedback controller
  - Updated KSCrash to 1.11.2

  ## 1.0.0

  - Refactored a lot of internal classes
  - Added `UserFeedback` feature to iOS
  - Added basic support for watchOS

  ## 0.5.0 - Remove Apple Crash Report

  - Remove appleCrashReport from request
  - Add mechanism to request
  - Switch version/build to make iOS version in sentry more understandable
  - Use `diagnosis` from KSCrash for crash reasons

  ## 0.4.1

  Fixed for breadcrumbs not always sending on fatal

  ## 0.4.0

  - Support for Swift 2.3 and Swift 3.0

  ## 0.3.3

  - Fixes issue in where capturing `NSError` was not sending up to API

  ## 0.3.2

  - Release was not getting sent up on crashes
  - Contexts was getting sent up on wrong key

  ## 0.3.1

  - Defaulting release to main bundle version

  ## 0.3.0

  - Added support for crashing reporting for Mac apps
  - Requests are now gzip before going off to Sentry API

  ## 0.2.1

  - Fixed breadcrumbs for updated spec
  - Removed all references of "raven"
    - Fixed #13
  - Changed merging behaviour in EventProperties
    - Event takes priority over client

  ## 0.2.0

  - Added tvOS support
  - Fixes with KSCrash that will build KSCrash for all platforms

  ## 0.1.0

  First pre-release that is ready for testers


title: README.md
data:
  <p align="center">
    <a href="https://sentry.io/?utm_source=github&utm_medium=logo" target="_blank">
      <img src="https://sentry-brand.storage.googleapis.com/sentry-wordmark-dark-280x84.png" alt="Sentry" width="280" height="84">
    </a>
  <br/>
      <h1>Official Sentry SDK for iOS / tvOS / macOS / watchOS <sup>(1)</sup>.</h1>
  </p>

  _Bad software is everywhere, and we're tired of it. Sentry is on a mission to help developers write better software faster, so we can get back to enjoying technology. If you want to join us [<kbd>**Check out our open positions**</kbd>](https://sentry.io/careers/)_

  [![Build](https://img.shields.io/github/workflow/status/getsentry/sentry-cocoa/Build%20%26%20Test)](https://github.com/getsentry/sentry-cocoa/actions?query=workflow%3A%22Build+%26+Test%22)
  [![codebeat badge](https://codebeat.co/badges/07f0bc91-9102-4fd8-99a6-30b25dc98037)](https://codebeat.co/projects/github-com-getsentry-sentry-cocoa-master)
  [![codecov.io](https://codecov.io/gh/getsentry/sentry-cocoa/branch/master/graph/badge.svg)](https://codecov.io/gh/getsentry/sentry-cocoa)
  [![CocoaPods compadible](https://img.shields.io/cocoapods/v/Sentry.svg)](https://cocoapods.org/pods/Sentry)
  [![Carthage compatible](https://img.shields.io/badge/Carthage-compatible-4BC51D.svg?style=flat)](https://github.com/Carthage/Carthage)
  [![SwiftPM compatible](https://img.shields.io/badge/spm-compatible-brightgreen.svg?style=flat)](https://swift.org/package-manager)
  ![platforms](https://img.shields.io/cocoapods/p/Sentry.svg?style=flat)
  [![Swift Package Index](https://img.shields.io/endpoint?url=https%3A%2F%2Fswiftpackageindex.com%2Fapi%2Fpackages%2Fgetsentry%2Fsentry-cocoa%2Fbadge%3Ftype%3Dswift-versions)](https://swiftpackageindex.com/getsentry/sentry-cocoa)
  [![Discord Chat](https://img.shields.io/discord/621778831602221064?logo=discord&logoColor=ffffff&color=7389D8)](https://discord.gg/PXa5Apfe7K)  

  This SDK is written in Objective-C but also provides a nice Swift interface.

  # Initialization

  *Remember to call this as early in your application life cycle as possible*
  Ideally in `applicationDidFinishLaunching` in `AppDelegate`

  ```swift
  import Sentry

  // ....

  SentrySDK.start { options in
      options.dsn = "___PUBLIC_DSN___"
      options.debug = true // Helpful to see what's going on
  }    
  ```

  ```objc
  @import Sentry;

  // ....

  [SentrySDK startWithConfigureOptions:^(SentryOptions *options) {
      options.dsn = @"___PUBLIC_DSN___";
      options.debug = @YES; // Helpful to see what's going on
  }];

  ```

  For more information checkout the [docs](https://docs.sentry.io/platforms/apple).

  <sup>(1)</sup>limited symbolication support and no crash handling.

  # Blog posts

  [Mobile Vitals - Four Metrics Every Mobile Developer Should Care About](https://blog.sentry.io/2021/08/23/mobile-vitals-four-metrics-every-mobile-developer-should-care-about/).

  [How to use Sentry Attachments with Mobile Applications](https://blog.sentry.io/2021/02/03/how-to-use-sentry-attachments-with-mobile-applications/?utm_source=github&utm_medium=readme&utm_campaign=sentry-cocoa).

  [Close the Loop with User Feedback](https://blog.sentry.io/2021/02/16/close-the-loop-with-user-feedback/?utm_source=github&utm_medium=readme&utm_campaign=sentry-cocoa).

  [A Sanity Listicle for Mobile Developers](https://blog.sentry.io/2021/03/30/a-sanity-listicle-for-mobile-developers/?utm_source=github&utm_medium=readme&utm_campaign=sentry-cocoa).

  # Resources

  * [![Documentation](https://img.shields.io/badge/documentation-sentry.io-green.svg)](https://docs.sentry.io/platforms/apple/)
  * [![Discussions](https://img.shields.io/github/discussions/getsentry/sentry-cocoa.svg)](https://github.com/getsentry/sentry-cocoa/discussions)
  * [![Discord Chat](https://img.shields.io/discord/621778831602221064?logo=discord&logoColor=ffffff&color=7389D8)](https://discord.gg/PXa5Apfe7K)  
  * [![Stack Overflow](https://img.shields.io/badge/stack%20overflow-sentry-green.svg)](http://stackoverflow.com/questions/tagged/sentry)
  * [![Code of Conduct](https://img.shields.io/badge/code%20of%20conduct-sentry-green.svg)](https://github.com/getsentry/.github/blob/master/CODE_OF_CONDUCT.md)
  * [![Twitter Follow](https://img.shields.io/twitter/follow/getsentry?label=getsentry&style=social)](https://twitter.com/intent/follow?screen_name=getsentry)


title: README.md
data:
  # Tests

  For test guidelines please checkout the [Contributing Guidelines](../CONTRIBUTING.md).

  # Integration tests

  * [SessionGeneratorTests](./SentryTests/Integrations/SentrySessionGeneratorTests.swift) generates session data to validate release health.
  * [External integration tests](../.github/workflows/integration-tests.yml) integrate the Sentry SDK via CocoaPods into some open source apps and run their tests.


title: README.md
data:
  # MacOS User Notifcations

  The Apple framework we use to support notifications is `UNUserNotifications`: https://developer.apple.com/documentation/usernotifications?language=objc

  ## Developing notifications locally
  The framework needs a signed app to be able to request authorization and schedule notifications to Apple's Notification Center. For this reason, it is not enough to `cargo build && cargo run`. Instead, there are a couple of options:

  ### 1. Bundle the app
  This takes a longer time than option 2, but it is more stable, and it is what the user will ultimately experience.

  1. Run `script/user_notifications --nouniversal --open`

  If you want to test the authorization flow specifically, you will have to:
  1. Delete all the `WarpDev` apps you have installed locally
  2. Ensure that `WarpDev` isn't an app in your Notification Center by checking which apps show up in `Notifications` in your System Preferences.
  3. Log out*
  4. Log back in and bundle&run the app again.

  ### 2. Nosign the local build (script)
  This is less stable than option 1 and is not recommended if you're testing the authorization flow.

  1. Ensure that you have a WarpDev app installed, _and in your Applications folder_. It's important to have the app in your Applications, or Apple won't be able to find the app while testing notifications.
  2. Run `script/local_build_and_sign`

  If you want to test the authorization flow specifically, you will have to:
  1. Delete all the `WarpDev` apps you have installed locally, including the one in your Applications folder.
  2. Ensure that `WarpDev` isn't an app in your Notification Center by checking which apps show up in `Notifications` in your System Preferences.
  3. Log out* and log back in.
  4. Move the `WarpDev` from `Bin` to `Applications` (i.e. install `WarpDev`).
  5. Run the script to nosign and run the app again: `script/local_build_and_sign`.

  *NB: If you already have all the permissions to send notifications, and you're not testing the authorization flow, you should be able to do the following instead of logging out & in:
  1. Delete all `WarpDev` apps.
  2. Run `sudo lsof | grep usernoted | grep db2` to find the path to a database that Notification Center uses.
  3. Run `killall usernoted && killall NotificationCenter`
  4. Run `rm <path-to-notification-center-db>`
  5. Build and run the app again (if you're not bundling, you still have to move `WarpDev` back to your `Applications` folder).

  ## Debugging notifications
  Some useful methods for debugging errors / if things aren't working as expected:
  - Check Notification Center to figure out if `WarpDev` is a registered app and to play around with the settings (e.g. turning on/off, enabling sound, etc)
  - Use `NSLog` to print debug statements in local builds
  - Use the Console app for more helpful framework errors - this is particularly helpful when you don't see any error from your own logs. Filter the messages by `NotificationCenter` or `usernoted` or `dev`
  - When in doubt, delete all `WarpDev` apps and restart your laptop. Sometimes Notification Center needs a gentle nudge.


title: Self-Hosted Runners
data:
  ### Register a runner with GitHub
  [This page](https://github.com/warpdotdev/warp-internal/settings/actions/runners/new) contains the instructions on how to add a new GitHub actions runner to the warp\-internal repository\.  Make sure you select the appropriate OS type and architecture before continuing\.  \(The M1 Macs currently in use in the NYC office are the ARM64 architecture\.\)
  You can skip over the \"Download\" section \- the necessary files have already been downloaded to the device\.
  You\'ll want to cd into \`\~\/actions\-runner\`\, then run the first line in the \"Configure\" section \(that starts with \`\.\/config\.sh \-\-url\`\)\- this will take you through a series of steps to register the device as a new runner\.
  You\'ll be asked a series of questions to finish configuration\:
  1. It will ask you for a runner group \- leave this as the default\.
  2. It will ask you for the name of the runner\.  If you\'re re\-creating an existing runner\, use the same name it previously had\.  If you\'re creating a new runner\, pick a name matching the existing convention \(e\.g\.\: \"nyc\-office\-laptop\#\"\)\.
  3. It will ask you for a set of labels \- use the default\.
  4. It will ask you for the path to the work folder \- use the default\.
  Note that you *shouldn\'t* use the \`run\.sh\` script to start the runner\, as our \`start\-runner\.sh\` script does some additional important setup before it invokes \`run\.sh\`\.
  ### Starting the runner on the device
  There is a script in the \`runner\` user\'s home directory named \`start\-runner\.sh\`\.  If you run this script on an already\-configured runner\, it will do all of the necessary initialization and connect to GitHub and be ready to execute workflow jobs\.
  ```warp-runnable-command
  ~/start-runner.sh
  ```
  ## Device passwords
  The passwords for the two devices are the same as the NYC office wifi\.
  ## Troubleshooting
  ### Fixing an offline runner
  If the self\-hosted runner is still listed on the GitHub [runners page](https://github.com/warpdotdev/warp-internal/settings/actions/runners)\, the machine probably restarted itself for some reason\, and the runner needs to be started by running \`start\-runner\.sh\`\.
  ### Fixing a device whose runner is no longer registered
  If the self\-hosted runner has been offline for more than a week\, GitHub will drop it\.
  First\, reset the device state\:
  ```warp-runnable-command
  cd ~/actions-runner
  rm .runner
  ./config.sh remove
  ```
  Then\, follow the steps above for adding a new runner to GitHub\.


title: Release Cop Instructions
data:
  The Release Tracker is the step\-by\-step guide that the release cop should follow as the release cop\. In general you should start by duplicating the \"Template\" sheet and filling it out with the current week\.
  ### Channels
  We create separate releases per\-channel\. Currently we have five channels\:
  * Dev \- developer facing builds \(least stable\)
  * Canary \- externally\-available nightly builds with the same feature flags as stable
  * Preview \- externally\-available nightly builds with some additional pre\-release feature flags enabled
  * Beta \- beta builds\, more stable\. Was used internally to to verify the changelog was correct before releasing the stable build
  * Stable \- release builds\, most stable
  Each channel generates distinct dmgs \(it is possible to have all installed at once\)
  ### Release Schedule
  **The release cop schedule runs from Monday to Friday\. In general\, we cut a release and push it to Beta on Tuesday \(we can ignore Beta\) and push the release to Stable on Thursday\.**
  ### Rolling out a Release
  The channel versions repo lists which version of the app is currently live\, e\.g\.
  ```JSON
  {
     "dev": {
         "version": "latest"
      },
     "beta": {
         "version": "v0.21.3.22.1631"
      },
     "stable": {
         "version": "v0.21.3.22.1631"
     }
  }
  ```
  When changed\, channel versions updates a similar file on GCP that all Warp clients read to determine whether they need to be updated\.
  The special value \"latest\" means that the channel release process will create a new tag based on HEAD and push it live\. This only works for dev\. It does not work for beta or stable \(work in progress for beta\, but it does not work with the release workflows\)\.
  Every Thursday\, there will be a PR automatically created against this repo which will update the \`version\` for stable\. If you’d like to manually update the version\, you can
  * use the \"Create PR\.\.\.\" in this repo
  * or\, manually create a new PR that updates the version on channel\_versions for the channel to a new valid version
  In all cases\, once this PR gets merged\, a GitHub action will pick this up and update the channel\_versions file in GCP\.
  ### Rollbacks
  To roll a channel back to a prior version\, just make a PR updating channel\_versions\.json and merge it to master\. No new build necessary\. Obviously be very careful doing this to make sure that nothing breaks if we go backwards\.
  Note that if you roll back the dev channel to a specific version\, you will need to eventually unpin it by setting the version back to \"latest\"\.
  ### Cherrypicks
  **Cherrypicks should first be merged into beta and verified\, before merging into stable\. In general\, be pragmatic\, if there is an urgent cherrypick it’s reasonable to cherrypick directly into stable in order to save time\.**
  After cherry\-picks are confirmed on the beta branch\, send out a PR to merge the beta branch into the stable branch\, and close out the PR using a *merge* commit \(**not** a squash commit \- we want to preserve the individual CP commits in the stable branch commit history\)\.  By merging beta into stable instead of duplicating the cherry\-picks\, you both save time and avoid somehow accidentally introducing differences between the beta and stable releases\.

  Once the cherry\-picks have merged\, you will need to create a new release build with the cherry\-picks by starting the **Cut New Release Candidate** action on the appropriate release branch\.
  ### Semi\-automated
  There is a workflow in the warp\-internal repository to facilitate release branch cherrypicks\, named “Cherrypick commit into a release branch”\.  This workflow takes the commit hash and target release branch as parameters\, and sets up a cherry\-pick branch from which a PR can be created\.  This workflow effectively performs the steps in the Manual section below\.
  If a conflict is encountered during git cherry\-pick\, the workflow will terminate without a push\, and you will need to resolve the conflict manually\, finish the cherry\-pick \(git cherry\-pick –continue\)\, and push the branch to GitHub\.
  ### Manual
  To manually cherry\-pick a commit into a release branch\:
  * Check out the release branch locally \(beta\_release\/\* if for beta and stable\_release\/\* if for stable\) \! \(you can find the name of the current release branch in the release tracker\)\.
  ```warp-runnable-command
  git checkout origin/beta_release/{}.beta
  ```
  * Checkout a new branch off of this branch\.
  ```warp-runnable-command
  git checkout -b cherrypick/beta_release/{}.beta_{COMMIT_SHA}
  ```
  * Run git cherry\-pick \{COMMIT\_SHA\}
  ```warp-runnable-command
  git cherry-pick {COMMIT_SHA}
  ```
  To get the commit SHA\, go to the PR on Github\. The commit SHA will be at the bottom
  * Create PR from your current branch onto the release branch\. Once approved\, merge\.
  ### Hotfixes
  For a hotfix\, in addition to building the new release candidate with the cherrypicks\, the release cop should update the changelog\. This is necessary to make the new release version available\, because the C\.I\. will fail without a change log entry\.
  In the normal release process\, this is something that the DevX\/Support team does\, but for hotfixes\, the release cop should do this to accelerate things
  * Copy the changelog for the previous release\, and update any inaccuracies \(i\.e\. remove lines for any reverted changes\)
  Example\: [https\:\/\/github\.com\/warpdotdev\/channel\-versions\/actions\/runs\/4515865461\/jobs\/7953630755\?pr\=338](https://github.com/warpdotdev/channel-versions/actions/runs/4515865461/jobs/7953630755?pr=338)
  * Validate locally that this is well\-formed
  You can use the command our C\.I\. uses [https\:\/\/github\.com\/warpdotdev\/channel\-versions\/blob\/main\/\.github\/workflows\/update\_channels\.yml\#L49](https://github.com/warpdotdev/channel-versions/blob/main/.github/workflows/update_channels.yml#L49)
  IDE is also helpful here
  * Send a PR with the channel version bump and the changelog together


title: Deleting GCP PubSub subscriptions
data:
  ### What
  This guide details how to delete multiple subscriptions from a GCP PubSub topic\. Unfortunately\, GCP doesn\'t have an API to batch\-delete\.
  ### Why
  GCP has a max limit of 10000 subs per topic\. If we reach the max for a topic \(and haven\'t been cleaning them up\, either automatically or manually\)\, we will need to delete some before we can create any more\.
  **Only use this if you do not care about which of the subscriptions are deleted\.**
  ### How
  1. Install the `google-cloud-pubsub` python package\.
  ```warp-runnable-command
  pip3 install google-cloud-pubsub
  ```
  2. Run the following script\, changing parameters accordingly\.
  ```Python
  from google.cloud import pubsub_v1

  # The number of subscriptions to delete
  n = 200

  # TODO: set these parameters
  project_id = "{{PROJECT_ID}}"
  topic_id = "{{TOPIC_ID}}"

  subscriber = pubsub_v1.SubscriberClient()
  publisher = pubsub_v1.PublisherClient()
  topic_path = publisher.topic_path(project_id, topic_id)

  subscriptions = publisher.list_topic_subscriptions(request={"topic": topic_path})

  deleted = 0
  with subscriber:
      for subscription in subscriptions:
          print(f"Going to delete sub: {subscription}")
          subscriber.delete_subscription(request={"subscription": subscription})
          
          deleted = deleted + 1
          if deleted > n:
              break

  ```
  From Jeff\: this is a slightly modified script which will delete subs that have the old expiration TTL \(31 days rather than 1 day\)\. I need to use this when session\-sharing\-server gets deployed to prod to clean up the subs with the old config\.
  ```Python
  from google.cloud import pubsub_v1
  from google.protobuf.timestamp_pb2 import Timestamp
  from datetime import datetime, timedelta

  # The number of subscriptions to delete
  n = 200

  # TODO: set these parameters
  project_id = "{{PROJECT_ID}}"
  topic_id = "{{TOPIC_ID}}"

  subscriber = pubsub_v1.SubscriberClient()
  publisher = pubsub_v1.PublisherClient()
  topic_path = publisher.topic_path(project_id, topic_id)

  subscriptions = publisher.list_topic_subscriptions(request={"topic": topic_path})

  deleted = 0
  with subscriber:
      for subscription in subscriptions:        
          subscription_details = subscriber.get_subscription(request={"subscription": subscription})

          if not subscription_details.expiration_policy or (int(subscription_details.expiration_policy.ttl.total_seconds()) == 2678400):
              print(f"Going to delete sub: {subscription}")
              subscriber.delete_subscription(request={"subscription": subscription})
              
              deleted += 1
              if deleted >= n:
                  break
          else:
              print(f"Skipping sub: {subscription} due to expiration policy.")


  ```


title: Remaining Tasks
data:
  ## 08\/30
  1. Review Ian\'s PR on notebook search caching
  2. Review Seikun\'s tech doc on invite by email 
  3. \(Stretch\) Think about how to represent the enter on start of line behavior
  ## 08\/31
  1. Merge in all open PRs \(Done\)
  2. Send out the updated import PRD for review \(Done\)
  3. Continue on the import prototype \(Done\)
  4. \(High priority\) Get the logistics sort out for Hack the north \(Done\)
  5. Sent out triaged bug tickets for review \(Done\)
  ## 09\/01
  1. Look into team tester produced bug \(Done\)
  2. Continue on the import prototype
  3. Record loom for BOD demo
      1. Notebook in panes
      2. Different block types \(lists\, markdown shortcut\)
      3. Copy \/ paste
      4. Block navigation and execution
  4. File notebook project update \(Done\)
  ## 09\/05
  1. Chat with immigration lawyer \(Done\)
      1. Follow\-up on lawyer tasks
  2. Update BOD demo
  3. Sync with Ben on notebook usability tasks \(Done\)
  4. Sync with Seikun on how to submit telemetry \(Done\)
  5. Fix link tooltip issue \(Done\)
  6. Continue prototyping import panel
  7. Review Seikun docs and RTE PR \(Done\)
  ## 09\/07
  1. Debug notebook issue \(Done\)
  2. Wrap up inline code \(Done\)
  3. PR reviews \(Done\)
  4. Usability fixes \(Done\)
  ## 09\/08
  1. Meetings
  2. Merge in all usability fixes
  3. Explore inline code cursor movement
  4. Fix inline code style inheritance
  ## 09\/11
  1. Hackathon coordination \(Done\)
  2. Fix regression on the workflow parameter text spacing \(Done\)
  3. Merge in all the usability fixes PRs \(Done\)
  4. Review RTE PRs \(Done\)
  5. Review tech doc on invite by email \(Done\)
  ## 09\/12
  1. Tech doc review on invite by email \(Done\)
  2. Prototype import\/export \(goal is to demo by the EOW\)
  3. Wrap up open PRs \(Done\)
  ## 09\/13
  1. Focus on getting prototype UI done
      1. Get high\-level structure of UI rendering \(Done\)
      2. Change font size and spacing to match design \(Done\)
      3. Add loading state and actually import the item \(Done\)
  ## 09\/14
  1. Catch up on RTE PR reviews \(Done\)
  2. Wrap up Warp Import prototype
  ## 09\/15
  1. Coordinate hackathon stuff \(Done\)
  2. Get first PR on import modal merged in \(Done\)
  3. Open the rest of the import modal PRs
  4. Demo import \(Done\)
  5. Figure out the errors in the second notebook launch \(Done\)
  6. Address AI from last incident \(Done\)
  ## 09\/18
  1. PR review on email invite flow and local notebooks \(Done\)
  2. Interview \& team meeting \(Done\)
  3. Help on a misconfigured IME bug on new windows \(Done\)
  4. Open remaining import modal PRs \(Done\)
  ## 09\/19
  1. PR Review on the notebook infinite loop \(Done\)
  2. Wrap up import modal PRs \(Done\)
  3. Open new PR to add file loading logic
  ## 09\/20
  1. Pairing with Eric \(Done\)
  2. Looked into a notebooks z\-index panic bug \(Done\)
  3. Invite by email PRs \(Done\)
  4. Finish the file loading logic PR
  5. UI improvements in import
  ## 09\/26
  1. Wrap up all in flight import modal PRs \(Done\)
  2. Interview \/ Syntax highlighting sync \(Done\)
  3. Prototype on the inline code style new behavior \(Done\)
  4. Fix inline code style \(Done\)
  5. Draft kickoff for warp drive object embedding
  ## 09\/27
  1. Wrap up fix for inline code style \(Done\)
  2. RTE PR review \(Done\)
  3. \(Maybe\) Clean up cursor bias PR \(Done\)
  4. Send out the kickoff doc \(Done\)
  5. Start looking into separating out syntax highlighting and autosuggestion logic
  ## 09\/28
  1. Merge in cursor bias PR \(Done\)
  2. Address comments from kickoff doc \(Done\)
  3. Wrap up import and enable on dogfood \(Done\)
  4. Tech doc for syntax highlighting and autosuggestion
  ## 09\/29
  1. Merge in import modal \(Done\)
  2. Markdown parser PR \+ Invite by email review \(Done\)
  3. Prototype `syntax highlighting` and `autosuggestion`
  4. Write integration test for import modal
  ## 10\/02
  1. Write integration test for import modal \(Done\)
  2. Build `notebook` feature flag into the import modal \(Done\)
  3. Addressing feedback on notebooks \(Done\)
  4. Prototype `autosuggestion` in notebooks
  5. PR reviews \(Done\)
  ## 10\/03
  1. Fix small bug in link tool\-tip \(Done\)
  2. Merge in all PRs \(Done\)
  3. Send out alignment on Design jam \(Done\)
  4. Prototype `autosuggestion` in notebooks
  5. PR reviews \(Done\)
  ## 10\/04
  1. Merge in PRs \(Done\)
  2. PR review \(Done\)
  3. Send out small import and RTE fixes
      1. Import modal border issue \(Done\)
      2. Strip out empty linebreaks when importing \(Done\)
      3. Block selection autoscroll should scroll the entire block \(Done\)
      4. Pasting on active block selection \(Done\)
  4. Prototype `autosuggestion` in notebooks \(Done\)
  ## 10\/05
  1. Start on the `autosuggestion` and `syntax highlighting` tech design doc
  2. Cloud 20\% fix \(Done\)
  3. Immigration stuff \(Done\)
  4. PR reviews \(Done\)
  ## 10\/09
  1. Update import modal to support clicking on completed files and folders
  2. Import modal UX update \(add cancel \/ close button\)
  3. Bump on tech design and address comments \(Done\)
  ## 10\/10
  1. Release cop cherry\-picks \(Done\)
  2. Look into a graphql latency spike on server \(Done\)
  3. Interviews \(Done\)
  4. Pair with Aloke \(Done\)
  5. PR reviews \(Done\)
  ## 10\/11
  1. Release cop duties \(Finish CP\)
  2. Send out command entry experience alignment doc \(Done\)
  3. Add logging for DB transactions \(Done\)
  4. Fix tasklist PR \(Done\)
  5. \(Stretch\) Add context menu to notebooks
  ## 10\/12
  1. Interview \+ Interview debrief \(Done\)
  2. Get the release out \(Done\)
  3. Write command entry agenda and discussion \(Done\)
  4. New doc for decoupling session from completion \(Done\)
  5. Wrap up the server logging PR \(Done\)
  6. Add task list to notebooks
  ## 10\/13
  1. Fix server logging PR mocks \(Done\)
  2. Comment on decoupling session from completion doc \(Done\)
  3. Ask for next step for import modal \(Done\)
  4. Add task list to notebooks
  5. PR Reviews \(Done\)
  6. Immigration stuff
  ## 10\/14
  1. Finish in progress PR reviews \(Done\)
  2. Send out Task list PR \(Done\)
  3. Add telemetry to import modal \(Done\)
  4. Horizontal Rule parser support \(Done\)
  ## 10\/15
  1. Address comments in decouple session doc \(Done\)
  2. Merge in \/ Address comments in in\-flight PRs \(Done\)
  3. Prototype horizontal rules
  ## 10\/16
  1. PR review \(Done\)
  2. Prototype decoupled completion in workflow editor
  ## 10\/17
  1. PR review \(Done\)
  2. Send out first part of the refactoring PR \(Done\)
  3. Address comments in tech doc \(Done\)
  4. Look into task list copy \/ paste
  ## 10\/18
  1. Look into task list copy \/ paste
  2. Refactor completion into its own crate
  3. Look into repro\-ing WarpDrive sync bug
  ## 10\/19
  - [x] Send out PR to refactor completion into its own crate
  - [x] Look into a weird Warp Drive bug
  - [x] PR reviews
  ***
  ## 10\/20
  - [x] Dig into Warp Drive syncing bug
  After looking into this issue\, the culprit was a minor change we made to the conflict resolution logic about a month ago [here](https://github.com/warpdotdev/warp-internal/pull/7152/files#diff-e4a8c1d530e1d0e7e2e1543f778acbd361286e190d76732d08b96052b8712c41R257)\. It changes the conflict resolution dialog to only display if\:
  1. The object has conflicting changes
  2. The object does not have pending changes\.
  However\, if user gets into a conflict state by editing an object offline and fall behind in revision when coming back online\, the second condition will be false and causing the entire`has_conflicts` check to return false\. And thus the conflict resolution dialog will not display\.
  But since we don\'t have anyway to get users out of this state without conflict resolution dialog\, users are effectively locked into this state forever\.
  - [x] Merge in refactor PR
  - [ ] Peer reviews
      - [x] Ben
      - [ ] Noah
      - [ ] Rob
      - [ ] Roshan
  - [ ] Self review
  - [ ] Start working on adding block level object to buffer
  ***
  ## 10\/21
  - [x] PR Reviews
  - [x] Peer reviews
      - [x] Ben
      - [x] Noah
      - [x] Rob
      - [x] Roshan
  - [x] Self review
  - [ ] Start working on adding block level object to buffer
  ***
  ## 11\/06
  - [x] Merge in first block item refactor PR
  - [x] RTE PR review
  - [x] Pair with DStern on Grafana
  - [ ] Send out second PR on buffer\-level refactor
  ***
  ## 11\/14
  - [x] AI jam
  - [x] Send out doc for syntax highlighting library
  - [ ] Add markdown shortcut for creating horizontal rule
  - [x] Address comments for syntax highlighting PR
  - [x] Immigration stuff
  ***
  ## 11\/15
  - [x] Review AI\+\+ doc
  - [x] Review arbitrary list numbering doc
  - [ ] PR Reviews
  - [x] Add debouncing for syntax highlighting
  - [ ] Add autosuggestion for shell blocks
  ***
  ## 11\/16
  - [x] PR Reviews
  - [ ] Add markdown shortcut for creating horizontal rule
  - [ ] Address comments in the syntax highlighting PR
  - [ ] Prototype zero\-length placeholder
  ***
  ## 11\/16
  - [x] Add markdown shortcut for creating horizontal rule
  - [x] Address comments in the syntax highlighting PR
  - [x] Fix bug with button alignment
  ***
  ## 11\/20
  - [ ] Start a draft on Drive embed PRD
  - [x] Look into Grafana follow\-up tasks
  - [x] \(Stretch\) Send out PR for code syntax highlighting support
  ***
  ## 11\/21
  - [x] Send out proposal for notebook feature cut\-off date
  - [x] Fix Javascript bug for syntax highlighting
  - [x] Pair with David on Grafana configurations
  - [x] Look into cloud reliability issues
  - [ ] Start a draft on Drive embed PRD
  ***
  ## 11\/22
  - [ ] Start a draft on Drive embed PRD
  ***
  ## 12\/11
  - [x] Catch up on tasks
      - [x] Review messages
      - [x] Winter retreat stuff
      - [x] Immigration
  - [x] Look into server release latency issue
  - [ ] Start working on notebook embed PRD
  ***
  ## 12\/12
  - [ ] Start working on notebook embed PRD
  - [x] Interview
  ***
  ## 12\/14
  - [x] Send out notebook embed PRD
  - [x] Look into removing the transaction rollback alert
  - [x] Fix syntax highlighting leaking bug
  - [x] Notebook slash menu
  ***
  ## 12\/15
  - [x] Explore natural language vs shell command input classification
  - [x] Fix checked list click handling in unfocused notebooks
  - [x] Fix checked list incorrectly autoscrolls content
  - [x] Write summary of the sync in the \#pod\-notebooks channel
  - [x] Merge in slash menu experience
  ***
  ## 12\/18
  - [x] Add code language parsing for HTML imports 
  - [x] Prototype embedded workflows in notebook
  ***
  ## 12\/19
  - [x] Fix tests in the code language parsing PR
  - [x] Sync on notebook embeds next steps
  - [x] PR review
  - [x] Grafana sync
  - [ ] Refactor notebook embeds to take generic view
  ***
  ## 12\/20
  - [x] Refactor notebook embeds to take generic view
  - [x] Wire notebook embeds to a sub model
  - [x] Respond to feedback on the embeds PRD
  ***
  ## 12\/21
  - [x] Respond to feedback on the embeds PRD
  - [x] Add entry point to select target embedded workflow
  - [x] Review async layout PR
  - [ ] Start checking in in\-buffer representation of embedded object
  ***
  ## 12\/26
  - [x] Release cop duties
  - [x] Parser for internal representation of embedded object
  - [x] In\-buffer representation of embedded object
  - [x] Embedded object rendering side
  - [ ] Review PRs
  ***
  ## 12\/27
  - [x] Review PRs
  - [x] Look into editor crashes
  - [x] Merge in 3 open PRs
  - [ ] Add notebook embedding submodel
  ***
  ## 12\/28
  - [x] Review PRs
  - [x] Look into editor crashes
  - [x] Add notebook embedding submodel
  ***
  ## 12\/29
  - [x] Look into editor crashes
  - [x] Merge in embedding submodel
  - [ ] Add selection model to notebook embeds
  - [ ] Add syntax highlighting
  ***
  ## 1\/08
  - [x] PR reviews
  - [x] Merge in open PRs on notebook search panels and syntax highlighting
  - [x] Add max width limit for notebook
  - [x] Add broken link state for notebook
  ***
  ## 1\/09
  - [x] Merge in broken link state
  - [x] Fix small embedded workflow issues
      - [x] Search panel zero state
      - [x] Command selection
      - [x] Render cursor
  - [x] Add support for embedded workflow rich copy and paste
  - [x] Turn on workflow embed feature flag
  ***
  ## 1\/10
  - [x] Merge in open PRs
  - [x] Fix slash menu behavior
  - [x] Send out Github issue for Grafana Terraform
  - [x] Add styling for strikethroughs
  - [ ] Prototype some rich block behavior
  ***
  ## 1\/11
  - [x] Fix overflow menu
  - [x] Fix command selection for block items
  - [x] Fix omnibar dropdown
  - [ ] Start a doc on forward compatibility of markdown formats
  ***
  ## 1\/12
  - [x] Fix oncall rotation notification
  - [x] Fix notebook usability issues
  - [x] Look into why selection autoscrolling is broken
  - [x] Start a doc on forward compatibility of markdown formats
  - [x] Prototype supporting semantic search for WarpDrive
  ***
  ## 1\/16
  - [ ] Look into RTC issue
  - [x] Address feedback on notebook forward compatibility
  - [x] Look into the server experimentation framework
  - [x] More usability fixes
  ***
  ## 1\/17
  - [x] Send out eng estimate for semantic search
  - [x] Send out proposal for server experimentation framework
  - [ ] Start working on the server experimentation framework
  - [ ] Look into RTC issue
  ***
  ## 1\/18
  - [x] Address feedback on\:
      - [x] Eng estimate
      - [x] Gradual rollout
  - [x] Review Ben\'s PR
  - [ ] Fix block prefix mis\-alignment
  - [ ] Start working on the server experimentation framework
  - [ ] Look into RTC issue
  ***
  ## 1\/19
  - [x] Fix notebook bug bash launch blockers
      - [x] [CLD\-1261](https://linear.app/warpdotdev/issue/CLD-1261/need-minimum-contrast-for-syntax-highlighting-on-themes-like-tomorrow) Minimum contrast for syntax highlighting
      - [x] [CLD\-1260](https://linear.app/warpdotdev/issue/CLD-1260/ruby-and-json-syntax-highlighting-dont-work) Ruby and JSON highlighting doesn\'t work
      - [x] [CLD\-1253](https://linear.app/warpdotdev/issue/CLD-1253/syntax-highlighting-isnt-reapplied-on-theme-change-esp-hard-to-read-on) Syntax highlighting not applied on theme change
  - [x] Fix block prefix mis\-alignment
  - [x] Help with ZachB on WarpAI block rendering
  - [x] Investigate work to remove team tester check
  - [ ] Start working on the server experimentation framework
  - [ ] Look into RTC issue
  ***
  ## 1\/26
  - [x] Notebook syncs
  - [x] PR reviews
  - [x] Get server side experimentation PR out
  ***
  ## 1\/29
  - [x] Polish the server side experimentation PR \(Add tests\)
  - [x] Notebook usability blockers\:
      - [x] [CLD\-1280](https://linear.app/warpdotdev/issue/CLD-1280/embedded-workflow-should-have-an-edit-button)
      - [x] [CLD\-1257](https://linear.app/warpdotdev/issue/CLD-1257/deleting-a-block-item-after-a-code-block-un-highlights-the-block)
      - [x] [CLD\-1300](https://linear.app/warpdotdev/issue/CLD-1300/position-of-block-insertion-menu-button-on-embedded-workflow-should-be)
      - [x] [CLD\-1296](https://linear.app/warpdotdev/issue/CLD-1296/workflow-icon-is-not-properly-aligned-with-title-text-baseline)
  - [x] Fix markdown parser panicking PII
  - [x] Email lawyers about
      - [x] Roshan\'s question
      - [ ] Where to get visa stamps
  ***
  ## 1\/30
  - [x] Merge in server side experimentation PR and schedule a dry\-run
  - [x] Prepare for the gradual rollout test run
  - [x] Send out updated fix for beachballing issue
  - [x] Work on showing notebook not accessible banner
  - [ ] Notebook usability blockers\:
      - [ ] [CLD\-1282](https://linear.app/warpdotdev/issue/CLD-1282/code-block-should-look-visually-different-from-embedded-workflows)
      - [ ] [CLD\-1313](https://linear.app/warpdotdev/issue/CLD-1313/slash-menu-should-insert-block-item-on-the-same-line-if-it-is)
      - [ ] [CLD\-1283](https://linear.app/warpdotdev/issue/CLD-1283/clicking-on-an-embedded-workflow-should-command-select-that-workflow)
  ***
  ## 1\/31
  - [x] Review PRs
  - [ ] Notebook usability blockers\:
      - [ ] [CLD\-1282](https://linear.app/warpdotdev/issue/CLD-1282/code-block-should-look-visually-different-from-embedded-workflows)
      - [ ] [CLD\-1313](https://linear.app/warpdotdev/issue/CLD-1313/slash-menu-should-insert-block-item-on-the-same-line-if-it-is)
      - [x] [CLD\-1283](https://linear.app/warpdotdev/issue/CLD-1283/clicking-on-an-embedded-workflow-should-command-select-that-workflow)
  - [x] Work on offline caching of experiment result
  - [x] Merge in notebook not accessible banner and schedule a bug bash
  ***
  ## 2\/01
  - [x] Review PRs
  - [x] Notebook usability blockers\:
      - [x] [CLD\-1282](https://linear.app/warpdotdev/issue/CLD-1282/code-block-should-look-visually-different-from-embedded-workflows)
      - [x] [CLD\-1313](https://linear.app/warpdotdev/issue/CLD-1313/slash-menu-should-insert-block-item-on-the-same-line-if-it-is)
  - [x] Gradual rollout bug bash
  ***
  ## 2\/02
  Review
  - [x] Review PRs
  - [x] Fix panick when deleting leading block item
  - [x] Notebook usability blockers\:
      - [ ] Add movement by logical line
  - [x] Add new server experiments
  ***
  ## 2\/05
  - [x] Review PRs
  - [x] Notebook usability blockers
  - [x] Look into RTC success metrics
  ***
  ## 2\/06
  - [x] Grafana oncall issues
  - [ ] Start investigating into inline text embedding
  ***
  ## 2\/07
  - [x] Oncall query latency investigation
  - [x] Review selectable text element doc
  - [x] Look into why `GetUpdatedCloudObjects` endpoint is slowing down
  - [ ] Start investigating into inline text embedding
  ***
  ## 2\/08
  - [x] Start investigating into inline text embedding
  - [x] Play around and document Sublime\'s feature
  ***
  ## 2\/09
  - [x] Prototype SFTP editor
  - [x] Look into CRDT logic \(timebox to an hour\)
  ***
  ## 2\/12
  - [x] Wrap up CRDT investigation
  - [x] Prototype E2E SFTP editor
  - [x] Prototype E2E docker session editor
  - [x] Notebooks work
      - [x] PR review
      - [x] Get RTE inline design doc over the line
  ***
  ## 2\/14
  - [x] Address comments on remote editing high\-level tech doc
  - [x] Some oncall issue
  - [x] Review follow\-ups for CRDT infra change doc
  - [x] Input detection kickoff doc
  - [x] PR reviews
  ***
  ## 2\/15
  - [x] Build prototype for AI input auto\-detection
  - [x] Clean up and send out the AI input auto\-detection PR
  - [x] Send out proposal for oncall rotation onboarding
  ***
  ## 2\/16
  - [x] Update new oncall rotation doc and ask for reviews
  - [x] PR Review
  - [x] Build some test cases for the Warp AI autodetection
  - [x] Merge in initial AI input implementation
  - [x] Test the AI heuristic
  ***
  ## 2\/20
  - [x] Think about ways to improve the AI autodetection algorithm
  - [ ] Implement the improvements
  ***
  ## 2\/21
  - [x] Implement and merge in improvements
  - [x] Review Zach\'s PR
  - [x] Update to use only prefix mode as AI input UI
  - [x] Immigration
  ***
  ## 2\/22
  - [x] Another iteration of improvements
  - [x] Explicitly ask for LGTM from remote editing derisk doc
  - [x] Schedule a callback in 100ms if the first pass did not result in positive classification
  - [x] PR Reviews
  ***
  ## 2\/23
  - [x] Push AI improvements fix
  - [x] Review Zach\'s PR
  - [x] More autodetection nits\:
      - [x] Fix syntax highlighting and error underlying issue
      - [x] Fix input flickering issue Roland reported
      - [x] Unlock input when user clears buffer
      - [x] Add whether query is triggered by autodetection in the telemetry payload
  ***
  ## 2\/26
  - [x] Oncall duties
  - [x] Review Zach\'s PR
  - [x] Review Suraj\'s PRs
  - [x] Fix `how does this` flickering issue
  - [x] Add history fuzzy matching as a source for AI autodetection
  ***
  ## 2\/27
  - [x] Oncall issues
  - [x] Sync with Dave on options if we do not proceed with autodetection
  - [x] Review Suraj\'s PR
  - [x] CPs
  - [ ] Send out new oncall rotation
  - [x] More fix to the AI autodetection
  ***
  ## 2\/28
  - [x] Oncall duties
  - [x] Address comments on new oncall rotation
  - [x] More fix to the AI autodetection
  - [x] Prototype language support
  - [ ] Start working on exit criteria doc
  ***
  ## 2\/29
  - [x] Fix in flight AI error
  - [x] Start working on exit criteria doc
  ***
  ## 3\/01
  - [x] Wrap up exit criteria doc
  - [x] Look into AI autodetection telemetry issue
  - [ ] Start working on getting the plugins setup for next week\'s oncall rotation
  ***
  ## 3\/04
  - [x] Set up new oncall rotation
  - [x] Address comments in autodetection exit doc
  - [x] Send out options for next projects
  - [x] Thoughts on WarpAI context
  - [x] Review Suraj\'s PR
  ***
  ## 3\/05
  - [x] More improvements to the oncall rotation
  - [x] PR reviews
  - [x] Fix input mode flickering
  - [x] Fix parser issue
  ***
  ## 3\/06
  - [x] Draft up thoughts on autodetection internationalization
  - [ ] Prototype n\-gram model for autodetection
  - [x] Review PR
  - [ ] Look into how Zed handles LSP and syntax highlighting
  ***
  ## 3\/07
  - [x] Sync on editor changes
  - [x] PR review
  - [x] Read how Zed handles syntax highlighting update
  - [x] Start prototyping basic editor support
  ***
  ## 3\/08
  - [ ] Continue prototyping basic editor support
      - [x] Get plain text editor working
      - [ ] Start working on incremental syntax highlighting
  - [x] Fix Oncall Rotation
  - [x] Review Ben\'s doc
  - [ ] PR review
  ***
  ## 3\/12
  - [ ] Continue prototyping basic editor support
      - [x] Get incremental AST working
      - [ ] Work on generating syntax coloring
      - [ ] Get API to apply decoration \(coloring to start\) at paint stage
  - [x] Send out the design jam summary
  - [ ] Review Ben\'s doc
  - [ ] PR review
  ***
  ## 3\/13
  - [x] Share editor research doc
  - [x] Work on core editing
      - [x] Share with DStern
      - [x] Share with Ben
      - [x] Share with Aloke
  - [x] PR Review
  - [x] Review Ben\'s doc
  - [x] Work on Kevin\'s starter tasks
  - [ ] Prepare B\&L
  ***
  ## 3\/14
  - [x] Work on core editing use cases
      - [x] Share with Zach
  - [x] Schedule a design jam
  - [x] RTE B\&L
  - [x] Writing down a list of rich text primitives VSCode supports
  - [x] PR \+ doc review
  ***
  ## 3\/15
  - [x] Test out the new interview question
  - [x] PR reviews
  - [x] Address feedback from the pain points doc
  - [x] Put pain points doc into terraform
      - [ ] Send it out
  ***
  ## 3\/16
  - [x] Send out the code editor pain point survey
  - [x] Draft up
      - [x] Message for how we are approaching Warp Code
      - [x] Message for filling out the survey
  - [x] Onboard Kevin
      - [x] Assign starter tasks
      - [x] Tech onboarding session
      - [x] Can run Warp locally
  - [x] Review PRs
  ***
  ## 3\/21
  - [x] Catching up
  - [x] KevinC onboarding
  - [x] Review PRs
  - [x] Look into cloud reliability
  - [ ] Check why AI autodetection is not working for `what went wrong`
  ***
  ## 3\/22
  - [x] Send out fix for replica lag behind
  - [x] Review PRs
  - [ ] Prototype syntax coloring
  - [x] Check why AI autodetection is not working for `what went wrong`
  ***
  ## 3\/25
  - [x] Start working on the high\-level tech design for Warp Text
  - [x] PR Reviews
  - [ ] \(Stretch\) Prototype syntax coloring
  ***
  ## 3\/26
  - [x] PR Reviews
  - [x] Continue working on the high\-level tech design doc
      - [x] Send out a draft doc at EOD
  ***
  ## 3\/29
  - [x] Address comments on Warp Text design
  - [x] PR reviews
  - [x] Figure out the performance issue with syntax highlighting
  - [x] Fix AI autodetection
  - [x] Fix replica behind error
  - [x] Fix experimentation framework error
  ***
  ## 4\/01
  - [x] Address all syntax highlighting performance bottlenecks
  - [x] PR Reviews
  - [x] Get syntax coloring right
  ***
  ## 4\/02
  - [x] Update Warp Text design doc
  - [x] Explore collaborative editing in other apps\: VSCode \/ Zed
  - [x] Prepare for design jam on collaboration in Warp Text
  - [x] Prototype bracket coloring
  - [ ] Prototype buffer tree change
  - [ ] Clean up autodetection PR
  ***
  ## 4\/03
  - [x] Address comments in Warp Text design doc
  - [ ] ~~Explore parallel layout of text frames~~
  - [x] PR reviews
  - [ ] Prototype buffer tree change
  - [ ] Prototype horizontal scrolling
  ***
  ## 4\/04
  - [x] Get all explicit approvals on Warp Text tech doc
  - [x] PR reviews
  - [x] Onboard KevinC to multi\-selection project
  - [x] Clean up prototype line height
  - [x] Prototype horizontal scrolling
  - [ ] Start implementing a base editor
  ***
  ## 4\/09
  - [x] Implement trait to pull some editor actions into a common trait
  - [ ] Get \^\^ merged
  - [x] Start sending out Scrollable PRs
          - [x] Record BOD demo
  - [x] PR Reviews
  ***
  ## 4\/10
  - [x] Review Zach\'s code script
  - [x] Get editor actions common trait PR merged
  - [ ] Get the Scrollable API approved \/ merged
  - [x] Start working on adding base code editor view \/ models
  - [x] Enable replica behind fix on prod
  ***
  ## 4\/11
  - [x] Get the base code editor view \/ model merged
  - [x] Add usage examples to the scrollable API
  - [x] Prep for BOD demo
  - [ ] Get scrollable API merged
  - [ ] Allow space configuration in render state 
  ***
  ## 4\/12
  - [x] Allow space configuration in render state 
  - [ ] Get scrollable API merged
  - [x] Warp Text status update
  - [x] Merge in entry point
  - [ ] Start adding rest of implementation for new scrollable
  ***
  ## 4\/15
  - [x] Get scrollable API merged
  - [ ] Start adding rest of implementation for new scrollable
  - [ ] Tech jam on pulling code editor out of main crate
  - [x] Tech jam on text layout
  - [x] Oncall issue\: [https\:\/\/linear\.app\/warpdotdev\/issue\/CLD\-1597\/warp\-server\-ghsa\-h755\-8qp9\-cq85\#comment\-85b46fc1](https://linear.app/warpdotdev/issue/CLD-1597/warp-server-ghsa-h755-8qp9-cq85#comment-85b46fc1)
  - [x] PR reviews
  ***
  ## 4\/17
  - [ ] Get element layout for scrollable merged
  - [x] Figure out pprof breakdown of text\_layout time
      - [x] Document the learnings
  - [x] Fill\-in sections for the warp\_core migration doc
      - [ ] Send it out
  - [ ] Setup the decoration layer
  - [x] Remove feature flags
  ***
  ## 4\/18
  - [x] Review KevinC\'s tech design
  - [ ] Send out PR to remove debouncing for AI autodetection
  - [ ] Prototype refactor buffer leafs from char \-\> ArrayString
  - [x] Send out a check\-in
  - [x] PR reviews
  ***
  ## 4\/19
  - [ ] Prototype refactor buffer leafs from char \-\> ArrayString
  ***
  ## 4\/23
  - [x] PR \& Doc review
  - [x] Jam on view macros and check\-in buffer base size change
  - [x] Fully rollout server side experiment for replica behind
  - [x] Check\-in Scrollable element
  - [x] Remove AI input autodetection debounce
  ***
  ## 4\/24
  - [x] PR review
  - [ ] Check\-in Scrollable element
  - [x] Send out PR for supporting overriding a range of highlights in a laid out text frame
  - [x] Merge in utility functions for SumTree
  ***
  ## 4\/29
  - [x] Merge in open PRs
      - [x] Horizontal scrolling fix
      - [x] Session sharing scrollable migration
      - [x] New warp\_core crate
  - [x] PR reviews
  - [ ] Start thinking about how to introduce decoration state in editor crate
  - [x] Continue work on migrating to warp\_core
  ***
  ## 4\/30
  - [x] PR reviews
  - [x] Fix notebook regression
  - [x] Continue work on migrating to warp\_core
  - [x] Start thinking about how to introduce decoration state in editor crate
  ***
  ## 5\/01
  - [x] Merge in syntax tree setup PR
  - [x] Continue work on migrating to warp\_core
  - [ ] Setup warp code to only compile on non\-wasm
  - [x] PR Review
  ***
  ## 5\/02
  - [x] Continue work on migrating to warp\_core
  - [x] Setup warp code to only compile on non\-wasm
  - [x] PR Review
  - [x] Write up plan for autodetection improvements
  ***
  ## 5\/03
  - [x] Get syntax highlighting working on code editor
  - [x] Add telemetry for autodetection false negatives
  - [ ] Look into horizontal scrollable bug
  - [x] PR Review
  ***
  ## 5\/06
  - [ ] Look into horizontal scrollable bug
  - [x] Double check the root cause of flickering
  - [x] warp\_core migrations
  - [x] Start implementing fix for flickering
  - [x] PR reviews
  ***
  ## 5\/07
  - [x] PR reviews
  - [x] Remove flickering in syntax highlighting
  - [x] warp\_core migrations
  - [x] Remove hint text in warp text
  - [x] Fix semantic selection in warp text
  - [ ] Add different language sources
  ***
  ## 5\/08
  - [x] Open PR for adding different language sources
  - [x] Fix input syncing bug
  - [x] Fix Warp Text line height
  - [x] Migrate warp\_core
  - [ ] Look into horizontal scrollable bug
  - [x] PR reviews
  - [ ] Start thinking about interaction with the file system


title: Accessing the database runbook
data:
  ## Step 1\: Install newest cloud\-sql\-proxy
  ```warp-embedded-object
  ---
  id: Workflow-DodoFCjhOzCJdxqYkWQDCS

  ```
  ## Step 2\: Starting a cloudsql\_proxy with service account
  This command will start a proxy from your machine to the postgres database\.
  * `project_id` can either be `warp-server-staging` or `astral-field-294621`
  * Postgres typically runs on port `5432`\, but this may conflict if you have a local postgres instance running\, so we default`port` to`5433` instead
  ```warp-embedded-object
  ---
  id: Workflow-QAFjzuZc3L9aEk9timkVGr

  ```
  ## Step 3\: Connect to the database
  Connect to the database using the same `port` that the proxy is setup on in the previous step\.
  ```warp-embedded-object
  ---
  id: Workflow-aTkylDbOlBF8341RYtVm2o

  ```
  ## Step 4\: Profit
  \$\$\$


title: Key Feedback
data:
  1. PRD feedback
      1. Build as much alignment as possible before the official PRD \-\- ask questions in Slack
      2. List out ambiguities explicitly as requirements\. Always ask if a feature is addressing an explicit requirement
  2. Make sure we continue to scope out product ambiguities within notebooks \-\- there are still lots of them

  1\-1 with Zach
  1. Visa progress
  2. Recent doc feedback
  3. Notebook progress
  ```Rust
  let x = 4
  // This is a function
  let y: String = "bdef"
  a + b

  fn start_a_question(para) {
     
  }
  ```


data:
  # Integration Test

  This is a Markdown file read by the `test_restore_snapshot_with_markdown_file` integration test.


title: README.md
data:
  # Samples

  Sample applications used as test hosts and manual acceptance testing.

  Most subdirectories contain an xcodeproj per platform/version, with one or more targets describing variants of applications targeting it, and including the Sentry SDK via a subproject reference. Each sample xcodeproj is included in the top level Sentry.xcworkspace.


title: README.md
data:
  # watchOS-Swift Sample

  Run `make build-for-watchos` to build the Sentry.xcframework on which this
  sample project depends on.


  **Why XCFramework and not include a normal Framework as the other samples do it?**

  With the current project setup we can't add the Sentry.framework, like we do for the other sample projects, to a watchOS project. If we try to add it 
  we get the following error:

  ```
  Building for watchOS Simulator, but the linked framework 'Sentry.framework' is building for iOS Simulator. You may need to configure 'Sentry.framework' to build for watchOS Simulator.
  ```

  A solution would be to add Sentry via as a Swift Package, but this would
  slow down the development cycle.

  A [XCFramework](https://help.apple.com/xcode/mac/11.4/#/dev6f6ac218b) can be
  used on multiple platforms. As of July 2020 we need to manually create
  XCFrameworkes with [xcodebuild](https://help.apple.com/xcode/mac/11.4/#/dev544efab96) and therefore we can't link directly to a XCFramework so
  Xcode builds it for us.


title: pull_request_template.md
data:
  ## :scroll: Description

  <!--- Describe your changes in detail -->

  ## :bulb: Motivation and Context

  <!--- Why is this change required? What problem does it solve? -->
  <!--- If it fixes an open issue, please link to the issue here. -->

  ## :green_heart: How did you test it?

  ## :pencil: Checklist

  <!--- Put an `x` in the boxes that apply -->

  - [ ] I reviewed the submitted code
  - [ ] I added tests to verify the changes
  - [ ] I updated the docs if needed
  - [ ] Review from the native team if needed
  - [ ] No breaking changes

  ## :crystal_ball: Next steps


title: Connecting to the staging database
data:
  ```warp-embedded-object
  ---
  id: Workflow-fy17CDnWC974yAiYtKoGsI

  ```

  ```warp-embedded-object
  ---
  id: Workflow-DodoFCjhOzCJdxqYkWQDCS

  ```

  ```warp-embedded-object
  ---
  id: Workflow-QAFjzuZc3L9aEk9timkVGr

  ```

  ```warp-embedded-object
  ---
  id: Workflow-aTkylDbOlBF8341RYtVm2o

  ```


title: CONTRIBUTING.md
data:
  <p align="center">
    <a href="https://sentry.io" target="_blank" align="center">
      <img src="https://sentry-brand.storage.googleapis.com/sentry-logo-black.png" width="280">
    </a>
    <br />
  </p>

  # Contributing

  We welcome suggested improvements and bug fixes for `sentry-cocoa`, in the form of pull requests. To get early feedback, we recommend opening up a [draft PR](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests). Please follow our official [Commit Guidelines](https://develop.sentry.dev/code-review/#commit-guidelines) and also prefix the title of your PR according to the [Commit Guidelines](https://develop.sentry.dev/code-review/#commit-guidelines). The guide below will help you get started, but if you have further questions, please feel free to reach out on [Discord](https://discord.gg/Ww9hbqr).

  ## PR reviews

  For feedback in PRs, we use the [LOGAF scale](https://blog.danlew.net/2020/04/15/the-logaf-scale/) to specify how important a comment is:

  * `l`: low - nitpick. You may address this comment, but you don't have to.
  * `m`: medium - normal comment. Worth addressing and fixing.
  * `h`: high - Very important. We must not merge this PR without addressing this issue.

  You only need one approval from a maintainer to be able to merge. For some PRs, asking specific or multiple people for review might be adequate.

  Our different types of reviews:
    
    1. **LGTM without any comments.** You can merge immediately.
    2. **LGTM with low and medium comments.** The reviewer trusts you to resolve these comments yourself, and you don't need to wait for another approval. 
    3. **Only comments.** You must address all the comments and need another review until you merge.
    4. **Request changes.** Only use if something critical is in the PR that absolutely must be addressed. We usually use `h` comments for that. When someone requests changes, the same person must approve the changes to allow merging. Use this sparingly.

  ## Setting up an Environment

  Run `make init` to get started. This will install `pre-commit`, `bundler` and `Homebrew` and their managed dependencies (see `Gemfile` and `Brewfile`).

  ## Tests

  The tests depend on our test server. To run the automated tests, you first need to have the server running locally with

  ```sh
  make run-test-server
  ```

  Test guidelines:

  * We write our tests in Swift. When touching a test file written in Objective-C consider converting it to Swift and then add your tests.
  * Make use of the fixture pattern for test setup code. For examples, checkout [SentryClientTest](/Tests/SentryTests/SentryClientTest.swift) or [SentryHttpTransportTests](/Tests/SentryTests/SentryHttpTransportTests.swift).
  * Use [TestData](/Tests/SentryTests/Protocol/TestData.swift) when possible to avoid setting up data classes with test values.
  * Name the variable of the class you are testing `sut`, which stands for [system under test](https://en.wikipedia.org/wiki/System_under_test).

  Test can either be ran inside from Xcode or via

  ```sh
  make test
  ```

  ### Flaky tests

  If you see a test being flaky, you should ideally fix it immediately. If that's not feasible, you can disable the test in the test scheme, add a suffix _disabled to the test, so it's clear when looking at the test that it is disabled, and create a GH issue with the label flaky test. Disabling the test in the scheme has the advantage that the test report will state "X tests passed, Y tests failed, Z tests skipped".

  ## Code Formatting

  Please follow the convention of removing the copyright code comments at the top of files. We only keep them inside [SentryCrash](/SentryCrash/),
  as the code is based on [KSCrash](https://github.com/kstenerud/KSCrash).

  All Objective-C, C and C++ needs to be formatted with [Clang Format](http://clang.llvm.org/docs/ClangFormat.html). The configuration can be found in [`.clang-format`](./.clang-format). Simply run the make task before submitting your changes for review:

  ```sh
  make format
  ```

  ## Linting

  We use [Swiftlint](https://github.com/realm/SwiftLint) and Clang-Format. For Swiftlint we keep a seperate [config file](/Tests/.swiftlint) for the tests. To run all the linters locally execute:

  ```sh
  make lint
  ```

  ## Environment

  Please use `Sentry.xcworkspace` as the entry point when opening the project in Xcode. It also contains all samples for different environments.

  ## Public Headers

  To make a header public follow these steps:

  * Move it into the folder [Public](/Sources/Sentry/Public). Both [CocoaPods](Sentry.podspec) and [Swift Package Manager](Package.swift) make all headers in this folder public.
  * Add it to the Umbrella Header [Sentry.h](/Sources/Sentry/Public/Sentry.h).
  * Set the target membership to public.

  ## Final Notes

  When contributing to the codebase, please make note of the following:

  * Non-trivial PRs will not be accepted without tests (see above).
  * Please do not bump version numbers yourself.


title: README.md
data:
  # Basic parser

  This parser is a type driven, recursive descent parser. This work in progress guide goes over a friendly overview of the workings of it with examples. In some places `Did you know?` notes are included, they are good to know tips because the parser relies on them.

  # Steps
  1. Lex. - [What happens when we start the parse](#what-happens-when-we-start-the-parse)
  2. Lite Parse. - [Working with the tokens](#working-with-the-tokens)
  3. Type driven full parse. - [Full parse](#)

  ## What happens when we start the parse?

  Let's say we are interested in parsing the input `warp --disable-telemetry`. Command calls generally have the form `cmd <arg1> <arg2> <argN>` where `<arg>`s are positional parameters. Let's use the primary functions of the parser and inspect. The first step we do is calling the tokenizer (the function `lex` here):

  ```rust
  let input = "warp --disable_telemetry";
  let start_offset = 0;

  let (tokens, _) = lex(input, start_offset);
  println!("{:#?}", tokens);
  ```

  The output is:

  ```rust
  (
      [
          Token {
              contents: Baseline(
                  "warp",
              ),
              span: Span {
                  start: 0,
                  end: 4,
              },
          },
          Token {
              contents: Space,
              span: Span {
                  start: 4,
                  end: 5,
              },
          },
          Token {
              contents: Baseline(
                  "--disable-telemetry",
              ),
              span: Span {
                  start: 5,
                  end: 24,
              },
          },
      ],
      None,
  )
  ```

  In effect, we receive here the input source *tokenized*. The `start_offset` is used by the parser to calculate the spans of each bare word. Inspecting a little more we can notice the tokens with a `span` field on them. The `Span` [struct type](../../util/meta.rs) has the fields `start` and `end` number that are helpful for knowing where something is. 

  #### Did you know? The `Span` struct type.

  Let's use the span numbers from the output above, and use the `Span` struct associated `slice` function. This function takes a string as input and will return a slice of it using the `Span`'s `start` and `end` values. Let's create three `Span`s with the numbers from the output above and slice each from the input string fed to the lexer.

  ```rust
  let input = "warp --disable-telemetry";

  let word1 = Span::new(0,4);
  let word2 = Span::new(4,5);
  let word3 = Span::new(5,24);

  assert_eq!(word1.slice(input), "warp");
  assert_eq!(word2.slice(input), " ");
  assert_eq!(word3.slice(input), "--disable-telemetry");
  ```

  ## Working with the tokens

  The next step of the basic parser isn't all that different from lexing/parsing from traditional parsing. The task right now is to understand the boundaries of the tokens and get the general forms ready for a full parse. We are not interested here in doing anything more just yet since each of these tokens can be passed to commands that have no signature registered (*more on this later*). We call this step the `Lite` parse step.

  A very simplistic view of the grammar rules below:

  ```
  LiteRootNode    := LiteGroup
  LiteGroup       := LitePipeline (';' LitePipeline)*
  LitePipeline    := LiteCommand ('|' LiteCommand)*
  LiteCommand     := argument+

  // (*more grammar later*)
  ```

  These are represented as structs that basic parser generates, they are:

  ```rust
  pub struct LiteRootNode {
      pub groups: Vec<LiteGroup>,
  }

  pub struct LiteGroup {
      pub pipelines: Vec<LitePipeline>,
  }

  pub struct LitePipeline {
      pub commands: Vec<LiteCommand>,
  }

  pub struct LiteCommand {
      // this is important!
      pub parts: Vec<Spanned<String>>,
      pub post_whitespace: Option<Span>,
  }
  ```

  #### Did you know? The `Spanned<T>` generic struct.

  The `LiteCommand` has a `parts` field that holds a vector of `Spanned<String>`. We mentioned about the `Span` type before. Here, we talk about a generic `Spanned<T>` that allows wrapping any `T` with a `Span` value along with it. Here is the type along with a few examples using it's helper functions.

  ```rust
  pub struct Spanned<T> {
      pub span: Span,
      pub item: T,
  }

  let example = Spanned { item: String::from("warp"), span: Span::new(0,4) };
  assert_eq!(example.item, "warp".to_string());
  assert_eq!(example.span, Span::new(0,4));

  let example = String::from("warp").spanned(Span::new(0,4));
  assert_eq!(example.item, "warp".to_string());
  assert_eq!(example.span, Span::new(0,4));

  let example = "warp -p --disable-telemetry";

  let full_span = Span::new(0, example.len());
  let first_flag_span = Span::new(5,7);

  assert_eq!(first_flag_span.slice(example), "-p");
  assert_eq!(first_flag_span.until(full_span), Span::new(5,27));
  assert_eq!(first_flag_span.until(full_span).slice(example), "-p --disable-telemetry");

  ```

  This is useful because as soon as the `lite` parse step happens. We get as output everything we need with `spans` correctly calculated. Let's go ahead and do a lite parse (the function `parse_tokens`) to our original example using as input the tokens generated by the lexer when processing the input `warp --disable-telemetry`, like so:

  ```rust
  let input = "warp --disable-telemetry";
  let start_offset = 0;
      
  let (tokens, _) = lex(input, start_offset);
  let (lite_node, _) = parse_tokens(tokens);
      
  let expected_word1 = String::from("warp").spanned(Span::new(0,4));
  let expected_word2 = String::from("--disable-telemetry").spanned(Span::new(5,24));
      
  assert_eq!(lite_node.groups[0].pipelines[0].commands[0].parts, vec![expected_word1, expected_word2]);
  assert_eq!(lite_node.groups[0].pipelines[0].commands.len(), 1);
      
  println!("{:#?}", lite_node);
  ```

  We get a nice lite node:
  ```rust
  LiteRootNode {
      groups: [
          LiteGroup {
              pipelines: [
                  LitePipeline {
                      commands: [
                          LiteCommand {
                              parts: [
                                  Spanned {
                                      span: Span {
                                          start: 0,
                                          end: 4,
                                      },
                                      item: "warp",
                                  },
                                  Spanned {
                                      span: Span {
                                          start: 5,
                                          end: 24,
                                      },
                                      item: "--disable-telemetry",
                                  },
                              ],
                              post_whitespace: None,
                          },
                      ],
                  },
              ],
          },
      ],
  }
  ```

  For more involved inputs (say commands separated by `|` and/or having `;`) the lite parser will effectively create the necessary `LitePipeline`s to express it, let's explore what happens if we lite parse the input `warp config-set --extension-path="/path/to/dir" ; echo $WARP_VAR"` (*two pipelines here due to the ; character*), like so:

  ```rust
  let input = "warp config-set --extension-path=\"/path/to/dir\" ; echo $WARP_VAR";
  let start_offset = 0;
      
  let (tokens, _) = lex(input, start_offset);
  let (lite_node, _) = parse_tokens(tokens);

  println!("{:#?}", lite_node);
  ```

  ```rust
  LiteRootNode {
      groups: [
          LiteGroup {
              pipelines: [
                  LitePipeline {
                      commands: [
                          LiteCommand {
                              parts: [
                                  Spanned {
                                      span: Span {
                                          start: 0,
                                          end: 4,
                                      },
                                      item: "warp",
                                  },
                                  Spanned {
                                      span: Span {
                                          start: 5,
                                          end: 15,
                                      },
                                      item: "config-set",
                                  },
                                  Spanned {
                                      span: Span {
                                          start: 16,
                                          end: 47,
                                      },
                                      item: "--extension-path=\"/path/to/dir\"",
                                  },
                              ],
                              post_whitespace: Some(
                                  Span {
                                      start: 47,
                                      end: 48,
                                  },
                              ),
                          },
                      ],
                  },
                  LitePipeline {
                      commands: [
                          LiteCommand {
                              parts: [
                                  Spanned {
                                      span: Span {
                                          start: 50,
                                          end: 54,
                                      },
                                      item: "echo",
                                  },
                                  Spanned {
                                      span: Span {
                                          start: 55,
                                          end: 64,
                                      },
                                      item: "$WARP_VAR",
                                  },
                              ],
                              post_whitespace: None,
                          },
                      ],
                  },
              ],
          },
      ],
  }
   ```

   ## Type driven full parse

  TODO


title: How are we approaching Warp Code
data:
  1. Warp Code is a long term project that aim to bring code editing functionalities into Warp\. Note that we want to approach this problem from first principle instead of recreating VSCode in Rust\, there are a lot of pain points in the existing code editors\.
  2. Warp Text is the immediate next deliverable we are working on\. We want to gradually build out these code editing features in a way that brings value to our users instead of commiting to an IDE right away\. The first iteration could be thought of as building a sublime\-like lightweight editor that addresses some terminal adjacent code editing flows
  3. Before we start on specing out the tech design for Warp Text\, we want to make sure we are building for the long term \(e\.g\. we don\'t want to have to rebuild our foundation in the future when we are adding X in Warp Code\)\. So we are devoting 2\-week of product effort with the goal to nail down some gaming changing feature and primitive mocks we want to include in Warp Code\.

  Things we could potentially mock up\:
  1. Having different parallel edit sets and switch easily between them
  2. Integration with Github on PR reviews and edit history
  3. AI integration
      1. Query to ask AI
      2. Suggested changeset
      3. User should be able to provide feedback and AI could further iterate on them


title: warp-server/client Readme
data:
  ## **Overview**
  The client piece of warp\-server handles miscellaneous browser\-based functionality\, such as login or block sharing\. It\'s hosted on `app.warp.dev` \(prod\)\, `staging.warp.dev` \(staging\)\, and either `localhost:8080` or `localhost:3000` locally \(depending on your method of running\; see below\)\.
  ## Running
  The best way of developing the frontend is\:
  1\. In one pane\, run\:
  ```warp-runnable-command
  ./script/server 
  ```
  2\. In another pane\, run\:
  ```warp-runnable-command
  cd client && yarn start:dev
  ```
  3\. The app is now available at `localhost:3000`\.
  You technically don\'t have to run `yarn start:dev`\, as `./script/server` does build the frontend assets\, and the Go server returns the built HTML at `localhost:8080`\. However\, you don\'t get live reloading for whenever you make changes to frontend files\, and running `./script/server` takes a bit of time\. The GraphQL client we use on the frontend is configured to route requests to `localhost:8080` locally\, so you can still hit your local server and test your code on `localhost:3000`\.


title: Link testing
data:
  # IInput Box tthis should not be djaklfjelija
  ```warp-embedded-object
  ---
  id: Workflow-SmDOw0p6cFWoCeL8NELi4f

  ```
  ```warp-embedded-object
  ---
  id: Workflow-O6bODLpMRs4LE7cCe246mq

  ```
   
  # APIs of the Input Box
  The input box is a child view named `EditorView` instantiated within `TerminalView`\.
  For the editor view to communicate with the tertminal view\, have the editor view send an action and register the action in the parent view\.
  For the terminal view to communicate with the editor view\, the terminal view can directly access the editor view via a field in its struct\. For it to input a newline\, for example\, it calls\:
  ```warp-runnable-command
  function my_test() {
      console.log("hi")
  }
  ```
  ### Buffer
  The data structure that contains the text in the EditorView is the `Buffer`\.
  Its most commonly used API of the `Buffer` is `chars_at()`\, which returns an iterator we can use to traverse characters from a certain point\.
  Under the hood\, the buffer is a `SumTree<Fragment>`\. Each `Fragment` has a `Text`\. The `Text` consists of `text` which is an `Arc<str>` and `runs` which is a `SumTree<Run>`\. A run describes how much space the fragment is taking\.
  Another useful API of `Buffer` is `line_len(row_number)` which gives you the length of a row number\.
  ### Indexing into the Buffer
  We use `Point` and `Offset` to index into the buffer\. `Point` is a 2\-dimensional location with `row` and `column` within the `Buffer`\. `Offset` is a 1\-dimensional `usize` within the `Buffer`\. You can easily convert `Point` and `Anchor` to `Offset` via `to_offset()`\. `Offset` is useful for traversing through the characters without having to wory about changing row and column numbers\.
  ### DisplayPoints and DisplayMap
  Another struct with `row` and `column` is the `DisplayPoint`\. `DisplayPoint` is only relevant in `EditorView` and `DisplayMap`\, but not the `Buffer`\. `DisplayPoint` describes the location in the `DisplayMap`\. The `DisplayMap` describes how the points **appear**—the visual coordinate system\. The `Buffer` has no concept of how it\'s being displayed and could in fact be displayed in multiple views\.
  The values of `DisplayPoint`s and `Point`s differ when code folding or softwrapping occurs\. We can translate between the `DisplayPoint` and `Point` using the `DisplayMap`\.
  ### Selections and Cursors
  The input box supports the multiple selections we are used to in VSCode\. So our `EditorView` has a `Vec<Selection>`\.
  A `Selection` has a `start` anchor and an `end` anchor to denote its start and end position\.
  Selections and cursors are closely intertwined—whereever there is a selection\, there is a cursor\. **A cursor on its own is just an empty selection where `start==end`\.** As such\, there is always at least one `Selection`\, with the first selection being the cursor\.
  ### Anchors
  An `Anchor` is a bookmark into the text\. It allows us to index for a relative position in the text even if its absolute position has changed\. An `Anchor` can be converted to a `DisplayPoint` or a `Point`\.
  For example\, imagine my cursor is between the characters \'l\' and \'E\' in \'PartialEq\'\. Say the absolute position is row 3 column 7\:
  ```Go
  Partial|Eq
  ```
  - [ ] defadfedaf
  * zcvjdkjz
  Then\, we add 10 characters\:
  `BRANCH` `branch`
  ```C++
  Partial1234567890|Eq
  /
  ```
  The cursor\'s absolute position is now at row 3 column 17\. To easily calculate this position\, we can convert the `Anchor` to row 3 column 17\.
  `AnchorBias::Left`\, `AnchorBias::Right`
  The AnchorBias determines whether the cursor ends up on the right side or the left side of the inserted text\. The above example is when AnchorBias is `Right`\. `AnchorBias::Left` looks like this\:
  ```warp-runnable-command
  Partial|1234567890Eq

  ```
  `Anchor`s are most useful when we introduce collaborative editing\, and it is important for users to know where they are typing in even when another user inserts text in the line they are on\.


title: Tailing logs on warp staging
data:
  ```
  gcloud auth login
  gcloud config set project warp-server-staging
  ```
  You may need to run\:
  ```
  sudo pip3 install grpcio
  export CLOUDSDK_PYTHON_SITEPACKAGES=1

  ```
  ```
  gcloud beta logging tail "resource.type=cloud_run_revision AND resource.labels.service_name=warp-server"
  ```


title: Building a Code Editor From Scratch
data:
  ## Stage 1\: Most Basic Text Editor
  1. Refactor rich text editor to support a plain text view \(Tech Jam\?\)
  2. Basic file system operations
      1. Read from local file
      2. Watcher for file changes \/ place a file lock\?
      3. Save to local file
  ## Stage 2\: Dogfood Code Editor
  1. Syntax highlighting
  2. Support multi\-cursor
  3. Jump to \/ open with line number


title: SumTrees API
data:
  Given a tree with two dimensions\: Sum and Count
  This is the current tree state\: \[1\, 1\, 0\, 0\, 4\, 1\, 0\, 0\, 1\]
  Define a cursor with\:
  1. Seek dimension\: Sum
  2. Sum dimension\:  Count

  Cursor seek\: 2\, bias\:\:Left
  * End position\: Count\(1\)
  * Cursor is on\: Count\(2\)
  * Seek Dimension\: Sum\(1\)car

  Cursor seek\: 2\, bias\:\:Right
  * End position\: Count\(4\)
  * Cursor is on\: Count\(5\)
  * Seek Dimension\: Sum\(2\)

  Cursor seek\: 3\, bias\:\:Left
  * End position\: Count\(4\)
  * Cursor is on\: Count\(5\)
  * Seek Dimension\: Sum\(2\)

  Cursor seek\: 3\, bias\:\:Right
  * End position\: Count\(4\)
  * Cursor is on\: Count\(5\)
  * Seek Dimension\: Sum\(2\)

  Cursor seek\: 6\, bias\:\:Left
  * End position\: Count\(4\)
  * Cursor is on\: Count\(5\)
  * Seek Dimension\: Sum\(2\)

  Cursor seek\: 6\, bias\:\:Right
  * End position\: Count\(5\)
  * Cursor is on\: Count\(6\)
  * Seek Dimension\: Sum\(6\)


title: Performance Analysis
data:
  # CPU Profiling
  ## pprof
  pprof is a tool developed by Google for analyzing performance profiles taken from a process\.  It provides a web\-based interface for looking at flamegraphs and other visualizations of CPU usage\.
  ### Initial Setup
  Install the latest version of pprof\:
  * `go install github.com/google/pprof@latest`
  ### Profile a Binary
  * Build and run the binary\, enabling use of pprof for profiling with `--features pprof_cpu_profiling`\.
      * It’s strongly recommended to use `--release` when profiling\, as otherwise you may end up trying to optimize “slow” code that gets optimized for you by the compiler\.
  * At the end of execution\, quit the running Warp Local with CMD\-Q\. The process will write out profiling data to `profile.pb` in the current directory \(if it is not under the current directory\, check if it’s under the root directory\)\.
  * Run the pprof web UI\, loading the provided profile output data\:
      * `~/go/bin/pprof --nodecount=3000 --http=":" profile.pb`
  * You probably want to change to the flamegraph view for an easier\-to\-digest visualization of the profiling results\.
  ### Troubleshooting
  * **Missing function info for system libraries \(macOS\)**
      * This is due to the fact that\, for MacOS Big Sur \(and later\)\, Apple no longer stores the system libraries on the filesystem\; they’re dynamically loaded into memory as needed by applications\.
      * To address this\, the system library cache needs to be dumped\, so that `pprof` can find the libraries and complete symbolization\.
          * This requires downloading or building `dyld_shared_cache_util` \- this archive contains a working pre\-compiled version of the tool\:
              [dyld\_shared\_cache\_util\-dyld\-733\.8\.zip](Performance%20Analysis%202bc347b6edba4579afa6f1051861bda3/dyld_shared_cache_util-dyld-733.8.zip)
          * After extracting\, run `./dyld_shared_cache_util -extract output /System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/dyld_shared_cache_arm64e` to dump the `aarch64` \(Apple Silicon\) versions of the shared libraries to the `./output` directory
      * Set the `PPROF_BINARY_PATH` environment variable to the output directory where the libraries were dumped\.  This will fix symbolization of system library function calls on subsequent runs of `~/go/bin/pprof` from this shell session\.
  * **Could not execute dot\; may need to install graphviz\.**
      * graphviz is a dependency of pprof\. You could install it with `brew install graphviz` and restart the web UI
  ## Old\, more\-manual method \(for posterity\)
  ### Initial Setup
  Install gperftools\:
  * `brew install gperftools`
  Install graphviz\:
  * `brew install graphviz`
  Install the latest version of pprof\:
  * `go install github.com/google/pprof@latest`
  ### Profile a Binary
  Build the binary\, linking in the profiler library\:
  * `RUSTFLAGS='-C link-args=-lprofiler -C link-args=-L/opt/homebrew/Cellar/gperftools/2.13/lib' cargo build -p warp --bin warp --release`
      * It’s strongly recommended to use `--release` when profiling\, as otherwise you may end up trying to optimize “slow” code that gets optimized for you by the compiler\.
  * If you run into an error saying something like `ld: library not found for -lprofiler`\, try running `brew update && brew upgrade gperftools`  to make sure you are running the latest version of `gperftools`\.
      * You could also be running a newer version of `gperftools`\, in which case you should update the path in your `RUSTFLAGS` string \(and please update it in this doc too\!\)\.
  Run the binary\, writing the profile to the given file\:
  * `CPUPROFILE="/tmp/prof.out" ./target/release/warp`
  * Make sure you run the correct binary \- `./target/release/warp` when building in release mode and `./target/debug/warp` when building in debug mode\.
  Run the pprof web UI\, loading the provided profile output data\:
  * `~/go/bin/pprof --nodecount=3000 --http=":" /tmp/prof.out`
  * You probably want to change to the flamegraph view for an easier\-to\-digest visualization of the profiling results\.
  ### Troubleshooting
  * **\/tmp\/prof\.out does not exist**
      * Verify that the `RUSTFLAGS` variable is being taken into account by changing `-lprofiler` within it to a non\-existent library\, e\.g\.\: `-lasdfasdf` and verifying that compilation fails\.
      * Double\-check that you are running the binary that was linked with the `profiler` library \- if you’re using `--release`\, run `./target/release/warp`\. If you’re not building in release mode\, run `./target/debug/warp`\.
  * **Missing function info for system libraries**
      * This is due to the fact that\, for MacOS Big Sur \(and later\)\, Apple no longer stores the system libraries on the filesystem\; they’re dynamically loaded into memory as needed by applications\.
      * To address this\, the system library cache needs to be dumped\, so that `pprof` can find the libraries and complete symbolization\.
          * This requires downloading or building `dyld_shared_cache_util` \- this archive contains a working pre\-compiled version of the tool\:
              [dyld\_shared\_cache\_util\-dyld\-733\.8\.zip](Performance%20Analysis%202bc347b6edba4579afa6f1051861bda3/dyld_shared_cache_util-dyld-733.8.zip)
          * After extracting\, run `./dyld_shared_cache_util -extract output /System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/dyld_shared_cache_arm64e` to dump the `aarch64` \(Apple Silicon\) versions of the shared libraries to the `./output` directory
      * Set the `PPROF_BINARY_PATH` environment variable to the output directory where the libraries were dumped\.  This will fix symbolization of system library function calls on subsequent runs of `~/go/bin/pprof` from this shell session\.


title: Run docker extension locally, opening subshell in Warp Dev
data:
  hi\!
  ```warp-runnable-command
  cd ui;
  npm run dev
  ```
  ```warp-runnable-command
  docker extension dev ui-source warpdotdev/warp http://localhost:3000
  ```
  * Run the above two in separate panes
  * Docker should then run locally
  * make sure we set this var\:
  ```text
  let url: string = `warpdev://action/docker/open_subshell?container_id=${containerId}&shell=${shell}`;
  ```


title: Updating the GraphQL Schema
data:
  ## warp\-server
  High\-level\, there is a set of schema files in the server codebase in `warp-server/graphql`\. After you edit them\, you will need to run from the server directory
  ```warp-embedded-object
  ---
  id: Workflow-h2zC57EViLf6RFVCXzp70t

  ```
  Also\, here is a good loom from Suraj on how to use Graphiql\: [https\:\/\/www\.loom\.com\/share\/2c77743a857443278449e197c13b6a34](https://www.loom.com/share/2c77743a857443278449e197c13b6a34)
  ## warp\-internal
  1. Have the server be running locally\.
  2. **If you\'re adding a new endpoint\:** make sure to add it to the allowlist in [`graphql/client-schema.ts`](./graphql/client-schema.ts)\.
  3. The client bindings \(the code in [`graphql/src/schema/generated`](./graphql/src/schema/generated)\) are created by running this command below\. Note that the server needs to be running for this to work\. 
  ```warp-embedded-object
  ---
  id: Workflow-QNVuQTxK2mtbgkYw4NqNYR

  ```
  You may first need to run\:
  ```warp-runnable-command
  yarn --cwd graphql install
  ```
  4. Create or edit the endoint you created\/modified in `graphql/schema/*.graphql` \(e\.g\.\, `create_generic_string_object.graphql`\)\. Here\'s an example\:
  ```warp-runnable-command
   mutation DeleteObject($uid:ID!) {
    deleteObject(input: { objectUID: $uid }) {
      success
      objectUidAndTypeArr {
        uid
        objectType
      }
    }
  }
  ```
  Here\'s another example of  a mutation\, one that includes the new error handling interface\:
  ```warp-runnable-command
  mutation RenameTeam($input: RenameTeamInput!) {
      renameTeam(input: $input) {
          __typename
          ... on RenameTeamSuccess {
              success
          }
          ... on UserFacingError {
              error {
                  message
                  __typename
              }
          }
      }
  }
  ```
  5. Once you\'ve updated the schema and the endpoint graphql file `cargo run`\. 
  You should now see the updated generated files in `graphql/src/schema/generated/*.rs`\!


title: Server Side Experiment Improvements
data:
  ### What is needed for server percentage rollout
  1. Client needs to cache experimentation results locally
      1. This is so users in the experiment group could use notebooks locally
      2. We should cache \(experiment\_id\, experiment\_arm\_id\)
  2. We need to be able to declare percentage\-based enablement for teams and individuals
      1. For an experiment\, the developer should be able to define a percentage of experiment vs control for both teams and individuals \(e\.g\. 10\% teams and 10\% users\)
          1. If a user is in either team or individuals control group\, disable the notebook\.
          2. If a user is in either team or individuals experiment group AND in neither team or individuals control group\, enable the notebook\.
      2. Note that in the original proposal\, the user specific arm is supposed to take precedance over the server specific arm\. This could be problematic if a user is in a control group and the team is in the experimentation group and the user might not have access to that feature\.
      3. Similar to client side experimentation framework\, server side experimentation would also require definition of both `traffic_allocation` by percentage and `bucket_range` for changing traffic allocation for existing users\.
  3. \(Maybe\) Increase the refresh frequency of fetching experimentation status
      1. Right now experimentation graphql is piggybacked on team metadata fetch request
      2. This might not be worth prioritizing if we are okay with the 10 mins delay \& want to avoid adding more query load to the server
  ## Changed needed for notebook experiments
  1. We could disable 


title: Known Issues for Linkability V0
data:
  - [x] ~~Workflow links do not properly open when section is collapsed \@sega~~ \([https\:\/\/github\.com\/warpdotdev\/warp\-internal\/pull\/9109](https://github.com/warpdotdev/warp-internal/pull/9109)\)
  - [x] ~~Personal Objects should not have links \(for now\) \@ian~~
  - [x] ~~Error toast if the link can\'t resolve on the client \@sega~~ \([https\:\/\/github\.com\/warpdotdev\/warp\-internal\/pull\/9157](https://github.com/warpdotdev/warp-internal/pull/9157)\)
  - [x] ~~Correct the URl to the correct object type \@sega~~ \([https\:\/\/github\.com\/warpdotdev\/warp\-server\/pull\/1664](https://github.com/warpdotdev/warp-server/pull/1664)\)
  - [x] Clearing sqlite or not having notebook in memory doesn\'t work on app start up \@ian
      - [x] Same thing for workflows
  - [x] ~~Check to make sure a workflow\/notebook is trashed on the web client \@sega~~ \([https\:\/\/github\.com\/warpdotdev\/warp\-server\/pull\/1663](https://github.com/warpdotdev/warp-server/pull/1663)\)
  - [x] Copy link button should exist in the notebook header \@ian
  - [x] Linking allows you to open multiple of the same notebook\, which we normally don\'t allow 
  - [x] If we are in Trash view\, and open a link we remain in Trash view\. \(notebook is still opened but workflow is not highlighted\)\.


title: Fixing the main branch on warp-server
data:
  If a server release is merged as a squash commit\, any future server releases will have \"merge conflicts\"\. To resolve\, we need to
  1. Pin Cloud Run traffic to latest revision to prevent any consumer\-facing changes during this process\.
  2. Checkout latest `main` locally\.
  3. Push current `main` as `old-main-<todays-date>`
  4. Drop the squash commit locally and force push `main`\.
      1. Note that this will require branch protection rule changes to `main`\. Specifically\, we need to allow force pushes for the person who will be pushing and disable the pull requests requirement\.
      2. While Step 1 will prevent any new release from getting traffic\, it\'s also probably a good idea to cancel the Cloud Builds that were created as a result of commiting to `main`\.
  5. Recreate server release or using existing server release\.

  The git history will appear as though we skipped the server release identified by the squash commit but that\'s not a big deal\. The Cloud Run revision history should be the source of truth for releases\.

  This is temporary until we make improvements to the server release process\, in general\.


title: Restoring warp-db from a backup
data:
  This notebook will help you restore our primary database\, `warp-db`\, to a backup from an earlier point in time\. You don\'t need to have created the backup prior to following this guide\.
  First\, a few notes on our database configuration\:
  * We have a main database `warp-db` and a read replica for it `warp-db-replica`\.
  * `warp-db` is configured to take an automatic backup once per day\.
  * Backups cannot be applied to any instance with a read replica attached\.
  * We have point\-in\-time recovery enabled\, which means that we can recover data from any moment in time as long as we have a backup for that day\. For example\, if a backup was taken at 1am on Dec 18th\, we can recover data from 9am on the same day \- Google uses logs to \"catch up\" with the operations taken in those 8 hours\.
  Okay\, onto the steps\:
  ## Notifying users
  1. If you haven\'t already\, notify [\#oncall](https://warpdev.slack.com/archives/C03943NUQUU) that this work is happening \- some functionality\, such as RTC\, will go down during this process\.
  2. If this is on prod\, update the [status page](https://status.warp.dev/) and let users know that some cloud functionality will be down as the maintenance completes\.
  ## Creating a point\-in\-time clone
  1. Go to the Cloud SQL page in GCP for the environment you want to perform the restoration in\. For example\, here\'s [staging](https://console.cloud.google.com/sql/instances?project=warp-server-staging)\.
  2. Click the triple dots under \"Actions\" for `warp-db` and select \"Create clone\"\.
  3. If you\'re preemptively making a clone in preparation for something dangerous\, you can keep the radio button set to \"Clone current state of instance\"\. If everything\'s on fire and you\'re trying to restore back to an earlier time\, change the radio button selection to \"Clone from an earlier point in time\" and select the latest time when everything was working properly\.
  4. Wait for `warp-db-clone` to be created\, about 15 minutes\.
  ## \(Sort of optional\) Saving the read replica settings
  1. Navigate back to the main SQL page\.
  2. Click the triple dots under \"Actions\" for `warp-db-replica` and select \"Edit\"\.
  3. Jot down or screenshot all the settings you see\, such as machine configuration and flags\. Be sure to expand all the sub\-sections\. We\'re going to lose this replica in a moment\, and the GCP defaults may be different than how we have them configured\, so it\'s good to know what the working setup looked like previously\.
  ## Deleting the read replica
  1. Navigate back to the main SQL page\.
  2. Click the triple dots under \"Actions\" for `warp-db-replica` and select \"Delete\"\.
  3. Wait for this operation to complete\, about 2 minutes\.
  ## Restoring `warp-db`
  1. Navigate back to the main SQL page\.
  2. Click on `warp-db-clone`\.
  3. Go to \"Backups\" on the left side navigation\.
  4. There should be a single backup listed\. Click \"Restore\" on that line item\.
  5. Keep the radio button selected on \"Overwrite an existing instance\"\. Select `warp-db` from the dropdown menu\, confirm the name\, and click \"Restore\"\.
  6. Wait for this operation to complete\, about 10 minutes\.
  ## Recreating the read replica
  1. Navigate back to the main SQL page\.
  2. Click the triple dots under \"Actions\" for `warp-db` and select \"Create read replica\"\.
  3. Apply all the settings to match the configuration of the previous read replica\. For the time we tried this on staging on 12\/18\/23\, these were the exact settings we had to change\, but your mileage may very depending on environment and current configuration\. \[UPDATE 3\/5\/24\] Some flags have been updated\.
      1. Changed \"Machine configuration\" from the default of 1vCPU\, 1\.7GB to 1vCPU\, 0\.614 GB\.
      2. Enabled \"Enable private path\" under \"Connections\"\.
      3. Make sure these are the **exact and only** six flags present\:
          1. `cloudsql.iam_authentication` set to `on`
          2. `log_lock_waits` set to `on`
          3. `log_connections` set to `on`
          4. `log_disconnections` set to `on`
          5. `log_temp_files` set to `0`
          6. `log_checkpoints` set to `on`
  4. Click \"Create replica\"\.
  5. Wait for this operation to complete\, about 15 minutes\.
  ## Cleanup
  1. Restart Warp\, and verify that RTC messages are being delivered as intended\.
  2. Navigate back to the main SQL page in GCP\.
  3. Click the triple dots under \"Actions\" for `warp-db-clone` and select \"Delete\"\.
  4. Confirm in the modal that appears that you want to delete `warp-db-clone`\.
  5. If this is on prod\, update the status page to let users know the maintenance should be complete\, and that they should restart Warp to fully restore cloud functionality\.


title: Reducing WASM binary size
data:
  # How to bundle for web\:
  I can create the WASM binary by running\:
  ```warp-runnable-command
  script/wasm/bundle
  ```
  That sends the \.wasm file to `./target/wasm32-unknown-unknown/release-wasm/bundle/wasm/dev_bg.wasm`\.
  I can check the size of the binary by running\:
  ```warp-runnable-command
  open ./target/wasm32-unknown-unknown/release-wasm/bundle/wasm/
  ```
  As of 2\/8\, this is **53\.6 Megabytes**\.
  # Compiler flags
  ```warp-runnable-command
  # inherits from the release profile
  inherits = "release"

  # optimizes for size rather than performance
  opt-level = "z" (saves us an extra 3 MB)

  # Link-time-optimization (not sure what this is yet?)
  lto = true (removes a megabyte)

  # Includes debug symobls, "binary size is increased by 20%?"
  debug = true

  ```
  ### Debug \= true
  - [x] Check to see if this actually bloats the binary
  * Setting debug \= false doesn\'t seem to decrease the binary size
  * Wheras\, opt\-level to 1 raises the level to 58\.3 MB \(this confirms that opting for size really works \/ is best\)
  - [ ] Investigate how we strip debug symbols 
  - [ ] Investigate sourcemaps in WASM such that we can strip the binary files

  49\.9MB
  If I add all these I get an extra three MB\:
  ```text
  strip = true (increases binary size)
  codegen-units = 1 (reduces by 300KB)
  panic = "abort" (adds size)


  ```
  ### WASM\-snip
  If we know a method is unreachable but the compiler doesn\'t\. So far\, not helpful
  # Gains from gzip
  The binary seems to be zipped up nice and tight when it\'s stored on gcp and served over the network\: [https\:\/\/cloud\.google\.com\/storage\/docs\/transcoding](https://cloud.google.com/storage/docs/transcoding)\.
  You can emulate the compression that GCP does on the file by installing and running gzip\:
  ```warp-runnable-command
  brew install gzip
  ```
  ```warp-runnable-command
  gzip ./target/wasm32-unknown-unknown/release-wasm/bundle/wasm/dev_bg.wasm
  ```
  This reduces the wasm\. GZip does lossless compression on source code \- it does not reduce the size of our assets in any meaningful way\.
  Now the binary is down to **20\.4 Megabytes**
  # Asset dissection
  The assets folder contains about **13MB** of data when not compressed\.
  If I clear everything out of the Assets folder\, the overall binary goes down to **40\.4MB**
  After zipping this goes to **8\.7MB**\. This implies that every byte in our assets folder\, is a byte in our binary
  From largest to smallest\:
  1. jpg\: 7\.6MB \(themes\) \(not compressible\)
  2. png\: 2MB \(other images\) \(not compressible\)
  3. fonts\: 2MB \(roboto \+ hack\) \-\-\> goes down to 1MB when compressed
  4. svg\: 740K \(icons\) \-\> 640K \(goes down to 400K when compressed\)
  5. resources\: 308K
  6. bootstrap\: 180K \(bootstrapping scripts\)
  7. onboarding\: 12K \(text file\)
  8. syntax\_theme\: 19K \(\?\?\)
  9. scripts\: 4\.0K
  does gzip condense fonts\?
  Proposal\: let\'s get rid of the things that can\'t compress more \(JPG\/PNG\)\. **This saves us 9\.6MB**
  # Binary dissection
  * `TYPE`\: 2\.6 KB
  * `IMPORT`\: 20\.7 KB
  * `FUNCTION`\: 22\.8 KB
  * `TABLE`\: 7 bytes
  * `MEMORY`\: 4 bytes
  * `GLOBAL`\: 9 bytes
  * `EXPORT`\: 10\.8 KB
  * `ELEM`\: 29 KB
  * `CODE`\: 15\.3 MB
  * `DATA`\: 34 MB
  * `producers`\: 101 bytes
  * `target_features`\: 28 bytes

  These converted sizes provide a clearer understanding of the memory usage of each section in the WebAssembly binary file\.
  the assets are in the data section
  # Twiggy dissection
  I need to figure out how to compile with debug symbols\?\?

  # libstd
  this is an unstable feature

  # global workflows
  removing this crate gets us down to \?\?\?
  We pull the global workflows from the github repo\. Let\'s see how we can get rid of this crate\.

  This only reduces us to **7\.6MB**
  ***
  # Command signatures
  Gets us down to **5\.8MB**

  # PSL
  how big is this crate\?

  # Ideas
  * cargo\-bloat
  * cargo\-unused\-features
  * Twiggy
      * I\'m not sure what this tells us\. other than a bunch of data takes up space
  * wasm\-snip
  * wasm\-gc panics everytime\. I\'m not sure why\?
  * command signatures\?
  * functions with lots of variables from dependencies
  * different memory allocators\? \(seems sus\)
  * completion specs
  * global workflows
  # Questions
  * Am I running with release\-wasm or dev\-wasm
  * How can I not compile resources\/mac into other bundles\?
  * CI check that alert to unused files
  * why does wasm\-gc not work\?


title: Run Warp on Web Against a Local Session
data:
  You can run a local session on Warp\-on\-Web using the [SSH proxy server](https://github.com/warpdotdev/ssh-proxy-server)\. This server starts an SSH connection against your local machine and proxies bytes to a websocket\.

  Follow these instructions to run\:
  * Enable ssh on your local machine\. For MacOS\:
      1. Open \"System Settings\"
      2. Search for \"Remote Login\" and toggle the setting on\.
  * Checkout the SSH proxy server repo
  ```warp-runnable-command
  git clone git@github.com:warpdotdev/ssh-proxy-server.git
  ```
  * cd into the git repo `ssh-proxy-server` and start the server\. It will ask you for your password\, so it can authenticate you against the SSH server\.
  ```warp-runnable-command
  cargo run --release
  ```
  * Run Warp\-on\-Web\. You have two options here\:
      * Go to [https\:\/\/staging\.warp\.dev\/dev\_session](https://staging.warp.dev/dev_session)\. This URL will automatically fetch the latest WarpDev binary and run it in the browser
      * From `warp-internal` run Warp\-on\-Web\, indicating we should use a \"remote\-backed\" PTY \(the `remote_tty` feature\)
  ```warp-embedded-object
  ---
  id: Workflow-QqHK1VrbgYt4jXGODIb81o

  ```
  Note that if you need to add a feature flag to the local WASM build\, the easiest way for now to do it is to alter the FEATURES env var in [script\/wasm\/bundle](./script/wasm/bundle)\.
  ### Developing for WoW
  `rust-analyzer` won\'t give language server features \(completions\, go\-to\-definition\, etc\.\) for WASM\-specific areas of the codebase unless it knows to build for target `wasm32-unknown-unknown`\. You can configure this in the settings of your code editor\.
  **VSCode**
  1. Open your `settings.json` file \(should be located under `~/Library/Application Support/Code/User/`\, or can be accessed by searching from the command palette\)\.
  2. Add `"rust-analyzer.cargo.target": "wasm32-unknown-unknown"`\.
  3. Reload your workspace or restart VSCode
  ### Known Issues
  There are a few known issues right now that we are actively working through\:
  * There is occassionally latency with running executing a command or seeing tab completions
      *  This is partly a bug with in\-band generators
  * Live updates from RTC don\'t yet work


title: Client-Side Polling/RTC Flows
data:
  ### Goals
  * Summarize how \+ when the client gets data from the server
  ### Overview
  * Client gets updates via a mix of polling \(making a GraphQL query every so often\) getting pushed messages over a websocket \(RTC \/ GraphQL subscription\)
  * Can\'t rely on the websocket \/ RTC updates alone
      * Not every client has a websocket \(yet\) \- it\'s expensive\, so we only start them if needed
      * Clients could miss messages \(e\.g\. lose internet\, discard an out\-of\-order message they don\'t understand\)
  ### Update Flows
  * How does the client know what to do\?
      * Today\: polling loops driven by polling loops
      * First\: Warp polls the `IsTeamsTester` endpoint at startup and [every hour](./app/src/teams/team_tester.rs:17) \(now\: `IsTeamsTester ~= IsAllowedToUseWarpDrive`\)
          * If [offline](./app/src/teams/team_tester.rs:75)\, default to \"yes\" if there\'s a team or objects cached locally\, and we don\'t know they\'re *not* allowed access
          * If someone joins a team via an intent link\, we treat that as them becoming a teams tester too
          * We also check if a user is a teams tester [when they login](./app/src/auth/auth_view_modal.rs:275)
      * Whenever the `IsTeamsTester` check changes to `true` \(including at startup\)\, we\:
          * Start polling for [team membership](./app/src/teams/update_manager.rs:90)
          * Start polling for [object updates](./app/src/server/cloud_objects/update_manager.rs:226)
          * Update the above *right away*\, if joining a team from a link
          * [Ensure](./app/src/teams/team_tester.rs:167) `FeatureFlag::CloudObjects` is enabled
      * Both the team\-membership and object\-update loops follow similar flows\:
          * If the client goes offline\, stop polling\. Start again when they\'re back online \([ex](./app/src/teams/update_manager.rs:71)\)
          * While polling is on\, check every [10 minutes](./app/src/server/retry_strategies.rs:12)
          * Do not poll if `FeatureFlag::CloudObjects` is disabled
      * Special things about team membership
          * We reuse the team\-membership poll to check for server\-side experiments
      * Special things about `GetCloudObjectUpdates`
          * Usually\, the server only sends back changed objects \(vs\. the client\'s understanding of the world\)
          * Every so often\, we ask the server for the [canonical state of *every* object](https://docs.google.com/document/d/16dpRxrAP-2_cAzfzK5bm3cyWmRm9P87TOznJ6waaAJo/edit) \(initial motivation\: making sure the client gets object actions\, even if the object itself didn\'t change\)
          * It also [fetches user profiles](app/src/server/cloud_objects/update_manager.rs:693) \- display names and avatars of team members
          * It also [tells the sync queue](./app/src/server/cloud_objects/update_manager.rs:736) to start sending local object edits to the server
  * But what about websockets\?
      * Managed by the [`Listener`](./app/src/server/cloud_objects/listener.rs)
      * General rule\: only start a websocket if the user \(a\) is on a team\, or \(b\) has non\-welcome objects
          * Check this [at app startup](./app/src/server/cloud_objects/listener.rs:113) based on SQLite cache
          * Listen to the models storing [user teams](./app/src/server/cloud_objects/listener.rs:140) and [cloud objects](./app/src/server/cloud_objects/listener.rs:157)
      * If the websocket is enabled\, we toggle it when\:
          * [the client goes offline\/online](./app/src/server/cloud_objects/listener.rs:188)
          * [the computer goes to sleep or wakes up](./app/src/server/cloud_objects/listener.rs:168)
      * When the websocket first starts\, *also* [do a long poll for updated objects](./app/src/server/cloud_objects/listener.rs:232)\, in case we missed anything while the websocket was inactive
          * Note\: this means we can do *two* long polls\, since the `UpdateManager` *also* does a poll at startup \(based on `IsTeamsTester`\) and when going online
      * Cloud Run has a 15\-minute timeout for requests\, so we restart the websocket every \~15 minutes
      * RTC messages from the websocket are [sent back to the update manager](./app/src/server/cloud_objects/listener.rs:266)
  ### End\-to\-end
  To start long polling\:
  1. The client calls `IsTeamsTester` at startup and hourly after that\.
  2. Once `IsTeamsTester` returns `true`\, the client starts polling for updated Warp Drive objects and team memberships every 10 minutes\.
  To start a websocket\, the client must know that the user is on a team or has objects\.
  So\:
  * For new users\, we\'re reliant on `IsTeamsTester` to kick off any of the update flows
  * Existing users with cached objects in SQLite will get a websocket
  * Existing users won\'t start long\-polling without a successful `IsTeamsTester`check \(unless they\'re offline and have cached data\)
  ### What\'s Next\?
  1. We\'re removing `IsTeamsTester` as \(somewhat risky\) tech debt \- thanks Sega and Ian\!
  2. We\'re going to scale to *every* user having a websocket \(for cloud settings sync\)


title: Export v0 Known Issues
data:
  [Linear](https://linear.app/warpdotdev/project/warp-drive-export-2d7bf0cf81f0?layout=list&ordering=priority&grouping=workflowState&subGrouping=none&showCompletedIssues=all&showSubIssues=true)
  - [ ] Folders and drives can\'t be exported


title: New: Notebooks in Warp Drive
data:
  Notebooks for Warp Drive are here\! Now you can create and share your own interactive runbooks in Warp\. Embed runnable code or Workflows that update everywhere they\'re referenced as you edit them\.
  ```warp-runnable-command
  echo "Let's run your first notebook command" 
  ```
  What\'s next\:
  - [ ] Open \[Getting started with Notebooks\]\(getting started\) to learn how the editor works
  - [ ] Create your first notebook
  - [ ] Share a notebook with your team

  You can also\:
  * [Read the announcement blog post](https://www.warp.dev/blog)
  * [Visit the docs](https://docs.warp.dev/features/warp-drive/notebooks)

  *Happy documenting\!* 
  \-\- The team at Warp
  ***
  P\.S\. We\'re showing you this Notebook as a one\-time announcement\, instead of the typical [Changelog update](Changelog)\. Check out the other features and bug fixes in this week\'s release\. 


title: Integration test cheat sheet
data:
  There is an integration test binary that lives in 
  * [\.\/integration\/src\/bin\/integration\.rs](./integration/src/bin/integration.rs)
  And a macro definition is in
  * [\.\/integration\/tests\/integration\.rs](./integration/tests/integration.rs)
  The macro definition file also includes a list of all of the tests to run\, so if you are making a new test you should add it there\.
  The test themselves are definied in
  * [\.\/integration\/src\/test\.rs](./integration/src/test.rs)
  To run all the integration tests\, execute the following 
  ```warp-runnable-command
  cargo nextest run --no-fail-fast --workspace
  ```
  To run just a specific test\, execute the following from the `./integration/` dirctory\:
  ```warp-runnable-command
  cargo nextest run --workspace -- {{test_name}}
  ```
  To run a test in a loop\:
  ```warp-runnable-command
  for i in {0..100}; do
    RUST_BACKTRACE=full WARP_SHELL_PATH=/bin/zsh cargo nextest run --workspace -- {{test_name}}
  if [ $? -ne 0 ]; then return; fi
  done
  ```
  If you have a test that fails and you want to see what state it\'s in\, set

  ```Rust
  println!("Hello, world!")
  ```
  ***
  ### Relevant flags that you might want to set
  `pause_integration_test_on_failure`
  Pauses integration tests on the first failure \-\- particularly useful when running with a real display\.
  `pause_integration_test_at_every_step`
  Pauses integration tests at every step \-  useful when you want to slowly see what\'s happening as you run a test\.  Most              useful when running with a real integration test\.
  **If your test requires env vars to be set\:**
  Using utils\.set\_env\(\) only sets the env vars at runtime\, whereas if your code checks for the env var using option\_env\(\)\, it does this at compile time\. To get around this\, you can read env vars in your code at runtime using env\:\:var\(\"VAR NAME\"\)\.


title: Mystery. History. Link it To Me.
data:
  ### **Verse 1\:**
  Two engineers\, tech game so ferocious\,
  Cookin\' up a product\, both focused and precocious\.
  Deep links in the mix\, collaboration\'s the potion\,
  Team objects link up\, smooth\, no commotion\.

  ### **Chorus\:**
  Deep linking\, yeah\, we got that connection\,
  Teamwork on fleek\, perfecting that perfection\.
  Objects intertwine\, like rhythm and its rhyme\,
  Engineering marvels\, ahead of their time\.

  ### **Verse 2\:**
  From the boardroom to the chat room\, they got it linked\,
  Efficiency off the charts\, quicker than you blink\.
  No obstacle too big\, no challenge too steep\,
  They\'re laying down the code\, while the world\'s asleep\.

  ### **Chorus\:**
  Deep linking\, yeah\, we got that connection\,
  Teamwork on fleek\, perfecting that perfection\.
  Objects intertwine\, like rhythm and its rhyme\,
  Engineering marvels\, ahead of their time\.

  ### **Outro**
  Yeah\, they\'re not just making links\, they\'re making history\,
  Yeah\, they\'re not just making links\, they\'re making history\,
  Yeah\, they\'re not just making links\, they\'re making history\,
  Mystery\. History\. Link it to me\. 


title: Database Migration on Cloud SQL
data:
  ## Database Migrations
  By default\, the Golang server connects to your local DB\. We can also point the Golang server to the staging DB\.

  1. Open our Warp service account with the Cloud SQL Client permissions\. Download a JSON key to use to authenticate your connection\.

  2. Launch a proxy with Unix Domain Socket \. Make sure to fill out the DB\_PASSWORD

  ```warp-runnable-command
  sudo mkdir ./cloudsql
  sudo chown -R $USER ./cloudsql

  ```
  Set environment variables\. 

  ```warp-runnable-command
  export GOOGLE_APPLICATION_CREDENTIALS=/path/to/service/account/key.json
  export INSTANCE_CONNECTION_NAME='/cloudsql/$PROJECT_ID:us-east4:warp-db-develop'
  export DB_USER='postgres'
  export DB_PASS='<DB_PASSWORD>'
  export DB_NAME='warp_db'
  ```
  3. Launch the proxy in the background

  ```warp-runnable-command
  ./cloud_sql_proxy -dir=$DB_SOCKET_DIR --instances=$INSTANCE_CONNECTION_NAME --credential_file=$GOOGLE_APPLICATION_CREDENTIALS &
  ```
  4. Now\, you can point the server to the staging database by setting the environment to develop\:

  ```warp-runnable-command
  export ENV=develop
  go run .
  ```


title: WDOW WorkItems for V1
data:
  - [ ] Ability display workflow in pane \(for web\) \- needs final design sign\-off
  - [ ] Add user preference setting for opening links \(web vs native\)
      * This also includes adding it to the settings modal \(should work with synced settings also\)\.
  - [ ] Default opening drive object to open on web client\.
  - [ ] Add toast for choosing open preference on first time open on web\.
  - [ ] On Web add open in client to the context menu of notebooks and workflows


title: Code Editor Reading
data:
  * VSCode [bracket colorization](https://code.visualstudio.com/blogs/2021/09/29/bracket-pair-colorization)
  * VSCode [text buffer implementation](https://code.visualstudio.com/blogs/2018/03/23/text-buffer-reimplementation)
  * VSCode renderer [interval tree](https://github.com/microsoft/vscode/blob/534c529c292a96eb775c74dfcee2d733380ed629/src/vs/editor/common/model/intervalTree.ts)

  ## Thoughts
  1. I think we should use tree\-sitter as our main AST tree builder\. This could be used for things like syntax highlighting and bracket matching\. It also supports incrementally building AST with local edits\.
  2. Our current renderer implementation is probably not performant enough\. We should make sure the editor could handle re\-coloring documents with \>10k lines with ease\. \(VSCode renderer uses an interval tree to \)
  3. Forget about LSP for now
  ## Zed\'s Approach To Syntax Coloring
  It\'s pretty straightforward as far as I can tell\:
  1. User makes an edit\, which triggers a reparse of the syntax tree
      1. They schedule the parsing on the background thread\. If it doesn\'t complete within a time limit\, re\-read the language and syntax state and initiate a second parsing
  2. Tree\-sitter handles the incremental parsing part by taking in the old tree and the range that has changed
      1. This returns a new syntax tree which could be stored in the view\.
  3. On layout\, read out the syntax tree and its coloring for each text chunk\. There doesn\'t seem to have any incremental rendering\.
  ## Questions
  1. Which editor should we use\? RTE or our plain text editor\?
  2. How do we handle edit \-\> re\-render right now in our plain text editor\? We should think about how to optimize it
  3. We should think about how to support horizontal scrolling

  ## Current Warp bundle size\:
  1. Warp\.dmg\: 34\.7MB
  2. Warp app\: 105\.4MB


title: Static v.s. Dynamic Dispatch
data:
  Both static and dynamic dispatch is used for selecting a concrete implementation of a polymorphic operation \(traits\)\:
  * Static dispatch\: Rust uses monomorphization which turns generic code into specific code by filling in each possible concrete type implementation at compile time\. \(An example is `impl`\)
  * Dynamic dispatch\: Rust builds a virtual function table \(vtable\) which maps function names to its implementation\. This is excuted at runtime\. \(An example is `dyn`\)

  The tradeoff between static and dynamic dispatch is compile time vs runtime\. Static dispatch is faster because it has one fewer layer of indirection\. But it also means Rust generates more code at compile time\.

  We should try to use generics in places where it should be accepting different concrete types \(e\.g\. `AppContext`\, `ViewContext`\)\. But there is also a concern here that this might cause over\-morphization\. For example\, before the function only accepts AppContext\, if we change it to ModelAsRef\, this will cause us to potentially generate more copies of the code at compile time whereas we should really be casting contexts to AppContext\.

  Note that dynamic dispatch will not work if the trait itself has generic type parameters \(too many indirections\)\. In these cases\, use static dispatch instead\.


title: Enterprise Account Testing Instructions
data:
  ## Enterprise Account Testing Instructions
  We have a separate domain that we own \(`warp.dog`\) which is configured on staging through WorkOS to use SSO with Okta as its IdP \(identity provider\)\. Any email inputted in our auth flow with this domain will trigger SSO\, and any resulting account will be on the enterprise plan\. Thus\, if you ever want to\, for example\, test enablement of client features when a user\'s on an enterprise\, it\'s helpful to know how to gain access to them\. This notebook tells you how\!
  \(You could also hack network responses to trick the client into believing it\'s on an enterprise account\, but this is cooler\.\)
  ## Testing with an existing account
  If you just want to test an account that is on an enterprise plan\, you can log in using the generic user email address\.
  1. Go to staging \(or clone staging\'s DB onto your local machine\, then run the server\)\.
  2. Log in with the email `user+other@warp.dog`\. You should receive a pop\-up asking you to sign in with Okta credentials\.
  3. Check RPass for the credentials listed as \"Okta Generic User\"\. Sign in with those\.
  4. You should be good to go\!
  ## Testing with a new account
  If you want to test with a brand new account\, it\'s a little more involved\, but will let you verify that signups work and that domain capture works\.
  1. Check RPass for the credentials listed as \"Okta Admin User\"\. Click on those credentials to be redirected and signed into Okta as the admin account\.
  2. On the left side\, under \"Directory\"\, choose \"People\"\.
  3. Click the button to add a person\.
  4. Give them any first\/last name\. For the username\, ensure it\'s of the form `user+<something>@warp.dog`\.
  5. Check the \"I will set password\" box\, and type in your own password\. Doesn\'t have to be complex\, but try to remember it\. Uncheck the \"User must change password on first login\" box\.
  6. Go to staging \(or clone staging\'s DB onto your local machine\, then run the server\)\.
  7. Log in with the email you created\. You should receive a pop\-up asking you to sign in with Okta credentials\.
  8. Enter the credentials you created\.
  9. You should be good to go\!


title: Macros
data:
  Macros is expanded before compiler tries to interpret the meaning of the code\. So it comes with a couple of upsides\:
  1. It can define a variable number of parameters
  2. It can do a lot of things that are not possible in a function \(e\.g\. implement a trait for an struct\)

  The downsides are\:
  1. Macros are more difficult to read \/ write \/ maintain
  ### Declarative Macros
  Allows one to define a pattern that matches against the incoming Rust source code and then run the code associated with the matched pattern\.
  ```Rust
  #[macro_export]
  macro_rules! vec {
      ( $( $x:expr ),* ) => {
          {
              let mut temp_vec = Vec::new();
              $(
                  temp_vec.push($x);
              )*
              temp_vec
          }
      };
  }
  ```
  An example definition of the `vec!` macro\.
  ### Procedural Macros
  Different from declarative macros\, there is no matching in procedural macros\. It allows one to take in some code \(in the form of `TokenStream`\)\, operates on it\, and produce some code as output \(also in the form of `TokenStream`\)\. This is more involved because it requires a separate crate and usually include some operating on the AST level\.
  There are three forms of procedural macros\:
  1. Custom Derive \(e\.g\. `#[derive(some_custom_attr)]`\)\. This only works on structs and enums
  2. Attribute\-like macros \(e\.g\. `#[allow(clippy...)`\]\)
  3. Function\-like macros \(e\.g\. `sql!(SELECT * FROM posts WHERE id=1);`\]\)


title: RTC Development
data:
  If you\'re adding a new topic that the server needs to subscribe to\,
  you will need to make sure the topic exists in the right project\.
  If you\'re testing locally\, that involves adding the creation of the topic
  [here](https://github.com/warpdotdev/warp-server/blob/a6b552255e29b674b48f66571856b3c3a140fa89/pubsub/pubsub.go#L63)\.

  For staging and production\, you will need to create the topic in GCP before
  you can subscribe to it or publish over that topic\.

  For singleton topics \(these are topics that are meant to be created
  once and used indefinitely\)\, you can run the following command\, replacing
  * `PROJECT_NAME` with the name of the environment the topic is being created for \(`warp-server-staging` for staging and `astral-field-294621` for production\)
  * `TOPIC_NAME` with the name of the topic you want to create
  ```warp-runnable-command
  gcloud --project PROJECT_NAME pubsub topics create TOPIC_NAME 
  ```
  Alternatively\, you can create the topic in the GCP Console UI\.

  For dynamic topics \(these are topics whose lifetimes are variable\)\,
  you can create the topic in code using the PubSub Client `CreateTopic` API\.

  ## Testing
  ### Local
  To test the GCP PubSub implementation locally\, you can run 
  ```warp-runnable-command
  ./script/server --with-rtc
  ```
  and it should start up a local PubSub emulator for you\. Note you might need to install
  any relevant dependencies \(see output\)\.

  If you need to test with a new singleton topic you\'re introducing\, add it 
  [here](https://github.com/warpdotdev/warp-server/blob/a6b552255e29b674b48f66571856b3c3a140fa89/pubsub/pubsub.go#L63)\.

  Here\'s an example of testing cloud object updates with the PubSub emulator\:
  [https\:\/\/www\.loom\.com\/share\/2c77743a857443278449e197c13b6a34](https://www.loom.com/share/2c77743a857443278449e197c13b6a34)

  TO BE CONTINUED
  * running multiple server instances against a single PubSub instance

  Notes about the GCP emulator\:
  * it doesn\'t support message filtering\, so filters will be ignored\.
  * the emulator is ephemeral and stores its state in\-memory\. Once you restart it\,
  you\'ll need to recreate any topics you want to use\.


title: BoD Demo Q2 2024 Setup
data:
  # Setup
  1. Ensure we\'re starting from an up\-to\-date database
  ```warp-embedded-object
  ---
  id: Workflow-uPTaihFBYA6JjGlY33Fd0a

  ```
  2. Create a stale migration
  ```warp-runnable-command
  rm db/migrations/*_demo.sql
  goose -dir db/migrations postgres "user=postgres dbname=warp_db sslmode=disable" create demo sql
  mv db/migrations/*_demo.sql db/migrations/20240320185323_demo.sql
  ```
  # Demo
  1. Try to apply migrations
  ```warp-embedded-object
  ---
  id: Workflow-uPTaihFBYA6JjGlY33Fd0a

  ```
  2. Show migration log
  ```warp-runnable-command
  goose -dir db/migrations postgres "user=postgres dbname=warp_db sslmode=disable" status
  ```
  3. Use Warp AI to rename the migration file\:
  ```warp-runnable-command
  mv db/migrations/*_demo.sql db/migrations/$(date +"%Y%m%d%H%M%S")_demo.sql
  ```
  4. Re\-apply the migrations
  ```warp-embedded-object
  ---
  id: Workflow-uPTaihFBYA6JjGlY33Fd0a

  ```
  # Teardown
  Undo and remove the demo migration
  ```warp-runnable-command
  goose -dir db/migrations postgres "user=postgres dbname=warp_db sslmode=disable" down
  rm db/migrations/*_demo.sql
  ```


title: New: Notebooks in Warp Drive (2)
data:
  Notebooks for Warp Drive are here! Now you can create and share your own interactive runbooks in Warp. Embed runnable code or Workflows that update everywhere they're referenced as you edit them.
  ```warp-runnable-command
  echo "Let's run your first notebook command"
  ```
  What's next:
  - [ ] Open *Getting started with Notebooks*, in your personal Warp Drive, to learn how the editor works
  - [ ] Create your first notebook
  - [ ] Share a notebook with your team

  You can also:
  * [Read the announcement blog post](https://www.warp.dev/blog/notebooks-in-warp-drive)
  * [Visit the docs](https://docs.warp.dev/features/warp-drive/notebooks)

  *Happy documenting!*
  — The team at Warp
  ---
  P\.S\. We're showing you this Notebook as a one-time announcement, instead of the typical [Changelog update](https://docs.warp.dev/getting-started/changelog). Check out the other features and bug fixes in this week's release.


title: Test Joining Team on Staging Server
data:
  1. Login with the local server
  2. Grab an invite code from `team_invite_codes` table\. Use the localhost\:8080\/team\/\{team\_invite\_code\} link
  3. If the team is full \(needs team SSB upgrade\)\, we need to use graphiql to update the service agreement
  ```text
  mutation addServiceAgreement($input: AddOrUpdateServiceAgreementInput!) {
    addServiceAgreement(input:$input) { 
      id 
      teamId
      tierId
      type
      status
      stripeSubscriptionId
      currentPeriodEnd
      createdAt
      updatedAt
    }
  }
  ```
  ```JSON
  { 
    "input": {
      "teamId": {TARGET TEAM ID},
      "tierId": "SELF_SERVE",
      "type": "LEGACY",
      "status": "ACTIVE",
      "currentPeriodEnd": "2030-09-25T00:00:00.000000000Z",
    }
  }
  ```
  Update the header to also include
  ```text
  "X-Warp-Eng-Token": "warp-eng-token",
  ```


title: Vec / Array / Slice
data:
  ### Array `[]`
  Resides completely on a stack\. It has a constant size at compile time \(given it is fixed size\)
  ### Slice `&[]`
  A reference to an array\. It could be immutable or mutable\. The underlying data structure is a fat pointer \(see below\)
  ### Vector `vec![]`
  Dynamically allocated vector\. Its data resides on the heap\. We store the pointer to the underlying data on heap and the length \+ capacity metadata on the stack\.
  ## Fat Pointers
  Fat pointer is used to reference DSTs \(dynamically sized types\)\. It usually consists the raw pointer and some additional metadata that makes the reference complete\. That additional piece of metadata could be\:
  1. For slices and \&str\, the metadata is length\, since an array could be any size N\.
  2. For trait objects \(dyn trait\)\, the metadata is a pointer to the vtable for dynamically getting the underlying implementation\.


title: Test
data:
  This is a [link](https://console.cloud.google.com/traces/list?project=astral-field-294621&pageState=(%22traceIntervalPicker%22:(%22groupValue%22:%22P1D%22,%22customValue%22:null),%22traceFilter%22:(%22chips%22:%22%255B%257B_22k_22_3A_22%252Fhttp%252Furl_22_2C_22t_22_3A10_2C_22v_22_3A_22_5C_22https_3A%252F%252Fapp.warp.dev%252Fgraphql_5C_22_22_2C_22s_22_3Atrue_2C_22i_22_3A_22%252Fhttp%252Furl_22%257D%255D%22))&minl=0&maxl=53.33333333333334&tid=c3c3ffc64f74f16a1015e3f2d105c3d9&spanId=0ddd4991fda16831)


title: JPM Node version
data:
  When you run \.\/script\/server\, you might  encounter the following node version error\: 
  ```warp-runnable-command
  Please install 18.19.1 version of node.
  If you're already using your node version manager of choice - follow up with the commands needed.
  Otherwise run `sudo n install 18.19.1` to install the supported node version.

  ```
  Please solve via
  ```warp-runnable-command
  nvm install 18.19.1 && nvm use 18.19.1
  ```


title: Profiling
data:
  Follow [performance analysis](https://staging.warp.dev/drive/notebook/Performance-Analysis-LkDlnAe34vfYD2JXsAkssc) for the setup

  Definitions
  * **Flat**\: the value of the location itself
  * **Cum**\: the value of the location \+ all of its descendents

  Two views\:
  1. Call graph
      1. Larger font size \=\> larger location flat value
      2. Gray \=\> Red
          1. Grey\: Close to zero cum value
          2. Red\: Large cum value
  2. Flame graph

  Some notes\:
  1. You could prevent inlining \(which makes it harder to figure out which part of the code is taking more time\) by adding `#[cold]` to the function
  2. Using non\-release build might give more signals \-\- but also it could include more noise
  3. The source code time inference feature is not really accurate


title: Known issues / ongoing work for collaborative input
data:
  ### Ongoing work
  - [x] Real\-time selection \/ cursor updates\.
  - [x] Command execution abilities for participants \(ETA\: 04\/19\)
  - [x] Input cursors w\/ avatar face
  ### Bugs
  - [x] \[suraj\] If a viewer leaves after editing the input\, new viewers won\'t see that person\'s edits when they join\.
  - [ ] \[suraj\] There is a race condition where if a viewer is making edits while their access is removed\, the edit might still be applied\. This should be fixed soon\.
  - [ ] \[suraj\] Editing while reconnecting does not yet fully work\.
  If you run into any bug\, especially a consistency bug\, please add it above \(with repro steps\, if possible\)\! In most cases\, you can run a command \(e\.g\. empty block\) which should reset the input and put you in a fresh state\.
  ### Out of scope
  * No secondary input features for the viewer \(completions\, syntax highlighting\, up\-arrow history\)\. Most of these are scoped out of the MVP\, except up\-arrow history\.


title: Development Profiles
data:
  On macOS\, Warp supports development profiles\, which namespace user state\. This lets you run multiple instances of the same Warp build and have them act as if they\'re different computers\:
  * Each profile has its own user defaults \(settings\)\, application data \(SQLite and logs\)\, and secure storage \(auth tokens\)
  * Linux and web don\'t have profiles yet
  * Development profiles *only* work on local development builds\, not `--release` builds
  To run Warp with a development profile\:
  ```warp-runnable-command
  WARP_DATA_PROFILE={{profile}} ./script/run
  ```
  This also works with `cargo run` \(e\.g\. to run the Preview channel\)\:
  ```warp-runnable-command
  WARP_DATA_PROFILE={{profile}} cargo run -p warp --bin {{channel}}
  ```
  This works by changing the application ID used for storage to have the profile name as a suffix\: `dev.warp.Warp-Local-myprofile`\, for example\.
  ### Where\'s my SQLite\?
  ```warp-runnable-command
  sqlite3 "~/Library/Application Support/dev.warp.Warp-Local-{{profile}}"
  ```
  ### How do I read defaults\?
  ```warp-runnable-command
  defaults read "~/Library/Application Support/dev.warp.Warp-Local-{{profile}}"
  ```
  ### Running with RTC
  if the reason you\'re running with multiple profiles is to check multiple clients interacting with Warp Drive\, you also need to run your server with rtc\, like so
  ```warp-runnable-command
  ./script/server --with-rtc
  ```


title: Presubmit
data:
  This is a notebook version of the [presubmit script](https://github.com/warpdotdev/warp-internal/blob/master/script/presubmit)\.
  ### Formatting
  This runs [Rustfmt](https://github.com/rust-lang/rustfmt) to make sure code matches our style guidelines and fails if it does not\.
  ```warp-runnable-command
  cargo fmt -- --check || echo 'Run cargo fmt to fix'
  ```
  ### Clippy
  Using [cargo\-diff\-tools](https://github.com/warpdotdev/cargo-diff-tools)\, run a stricter set of Clippy lints against code changed by the current diff\.
  ```warp-runnable-command
  cargo-clippy-diff origin/master HEAD -- --no-deps -- -W clippy::unwrap_used -W clippy::unwrap_in_result
  ```
  Then\, run Clippy on everything\.
  ```warp-runnable-command
  cargo clippy --all-targets --all-features --tests -- -D warnings
  ```
  ### Objective\-C Formatting
  Like Rustfmt\, but for any C\/C\+\+\/Objective\-C code\.
  ```warp-runnable-command
  ./script/run-clang-format.py -r --extensions 'c,h,cpp,m' ./ui/src/ ./app/src/
  ```
  ### Tests
  This runs *all* our unit and integration tests\. Remove \`\-\-no\-fail\-fast\` if you want it to stop as soon as a test fails\.
  ```warp-runnable-command
  cargo nextest run --no-fail-fast --workspace
  ```
  Currently\, nextest [can\'t run doctests](https://github.com/nextest-rs/nextest/issues/16)\, so we test those separately\:
  ```warp-runnable-command
  cargo test --doc
  ```
  ### Done\!
  Congrats\! If the steps above all succeeded\, then all presubmit checks have passed\.


title: Rebase on main branch (1)
data:
  How to rebase on the main branch

  ```warp-runnable-command
  git checkout {{main_branch}}
  ```
  ```warp-runnable-command
  git checkout {{your_branch}}
  ```
  ```warp-runnable-command
  git fetch; git rebase -i origin/{{main_branch}}
  ```


title: Errors and Fixes
data:
  If you get this block
  ```warp-runnable-command
  yarn install
  error This project's package.json defines "packageManager": "yarn@4.0.1". However the current global version of Yarn is 1.22.21.

  Presence of the "packageManager" field indicates that the project is meant to be used with Corepack, a tool included by default with all official Node.js distributions starting from 16.9 and 14.19.
  Corepack must currently be enabled by running corepack enable in your terminal. For more information, check out https://yarnpkg.com/corepack.
  ```
  The fix for me \(zach\) was to make sure I wasn\'t using the version of yarn installed through brew\.
  ```warp-runnable-command
  brew uninstall yarn
  Uninstalling /opt/homebrew/Cellar/yarn/1.22.21... (15 files, 5MB)
  ```


title: Running DB migrations locally
data:
  # Database
  ## Migrations
  We use [goose](https://github.com/pressly/goose) as our DB migration tool\. The steps for migrating are as follows\:
  1\) Create a new DB migration file
  ```warp-embedded-object
  ---
  id: Workflow-K2bj4ZEPJRVURkp8TVYPh0

  ```
  or using `Create a new DB server migration file` workflow\.
  This will create a migration file at `db/migrations/{migration_name}.sql` where you can the changes to the schema\.
  2\) Run `goose up` on your local DB to ensure the migration is working as expected\:
  ```warp-embedded-object
  ---
  id: Workflow-uPTaihFBYA6JjGlY33Fd0a

  ```
  You should also `goose down` so the down SQL statements are also executed and verified to be working\.
  3\) Send out PR with the changes and merge them into `develop`\.
  Your migration will then run automatically on both staging and production during the respective server builds\.
  If you run into an error\, you might want to dump the migration log to debug further\:
  ```warp-runnable-command
  goose -dir db/migrations  postgres "user=postgres dbname=warp_db sslmode=disable" status
  ```
  ### Running migrations manually on staging \/ prod
  Note that with the updated server release process\, we no longer need to run the migrations manually\, as this happens **automatically** on each server push\.
  This section should then be reserved for advanced emergency usage\. Note that it\'s not safe \(migrations executed manually use **your local** copy of the server and migration list\) so be extra cautious\.
  Take a note of what GCP project you want to use \- production or staging\?
  For production run\:
  ```warp-runnable-command
  PROJECT_ID='astral-field-294621'
  ```
  For staging run\:
  ```warp-runnable-command
  PROJECT_ID='warp-server-staging'
  ```
  The newly created environment variable will be useful later\.
  Fist\, start [Cloud SQL Proxy](https://cloud.google.com/sql/docs/postgres/sql-proxy)\.
  * Follow the instructions from the link above to install the Cloud SQL proxy\.
  * Ensure you have logged in to gcloud via `gcloud auth login`\. The cloud sql proxy reads these credentials to
      authenticate you\.
  * Start the proxy for either staging or prod\.
  ```warp-runnable-command
  ~/cloud_sql_proxy --instances=${PROJECT_ID}:us-east4:warp-db=tcp:5430 &
  ```
  You can then run the migration with the following commands\:
  ```warp-runnable-command
  DB_PASSWORD=`gcloud secrets versions access latest --secret="db-password" --project="${PROJECT_ID}"`
  goose -dir db/migrations  postgres "user=postgres dbname=warp_db sslmode=disable port=5430 password=$DB_PASSWORD" up
  ```
  **Do not** save the password on your local machine\, or copy it manually\. Also note that access to the password is monitored and [audited](https://warp.grafana.net/d/00Fa3lz4k/audit-log?orgId=1)\.


title: Warp Text TODOs
data:
  ## Rope Leaf size
  RTE\'s buffer tree leaf size should be more than 1 char\. This helps us reduce the tree height and make querying buffer much more efficient\. \(WIP\: `kevin/experiment-with-increasing-buffer-tree-leaf-size`\)\. Currently in a production build\, collecting chars from the buffer could take \~50\% of CPU time when rendering updates for files of 10k lines\.
  Current usage of cursor slicing and seeking\:
  1. Slice to an end range\. Get the sub\-tree between start and end
  2. Get the suffix of the current cursor
  3. Get current sum dimension at the cursor
  4. Get current cursor item
  5. Get item \(char\_at\)

  Open Changes\:
  1. Apply color needs to be changed \(`color_code_block_ranges`\)
  2. 


data:
  [https\:\/\/github\.com\/warpdotdev\/warp\-internal\/actions\/runs\/8944774590\/job\/24572428228\?pr\=9733](https://github.com/warpdotdev/warp-internal/actions/runs/8944774590/job/24572428228?pr=9733)
  [https\:\/\/github\.com\/warpdotdev\/warp\-internal\/actions\/runs\/8944750581\/job\/24572351867\?pr\=9690](https://github.com/warpdotdev/warp-internal/actions/runs/8944750581/job/24572351867?pr=9690)
  [https\:\/\/github\.com\/warpdotdev\/warp\-internal\/actions\/runs\/8943134490\/job\/24569031077](https://github.com/warpdotdev/warp-internal/actions/runs/8943134490/job/24569031077)
  [https\:\/\/github\.com\/warpdotdev\/warp\-internal\/actions\/runs\/8941547424\/job\/24562138203](https://github.com/warpdotdev/warp-internal/actions/runs/8941547424/job/24562138203)


