Use notion as cms

Started work on using notion as cms. Featured markets implemented, and initial work on banners

Properties the marketing team may want to control on the banner:
    screens: {
      sm: "600px",
      md: "905px",
      lg: "1240px",
      xl: "1440px",
      "2xl": "1728px",
    },

[ ] background position (for each breakpoint)
[ ]  title text and styles (color, size, font weight, margins, font family)
[ ]  secondary title text and styles  (color, size, font weight, margins, font family)
[ ]  CTA primary text, link, and styles (bg color, border color, text color)
[ ] CTA secondary text, link,  and styles (bg color, border color, text color)
[ ] image url

@robhyrk I would like to limit the input from the marketing team as much as possible for simplicity.
Regarding button style, it should be a list of presets like blue, black, red, or purple. And we set the text and border color accordingly.
Im not sure we should allow setting font families sizes etc. Or at least then make it a set of presets like large, small or medium.

@robhyrk I would like to limit the input from the marketing team as much as possible for simplicity.
Regarding button style, it should be a list of presets like blue, black, red, or purple. And we set the text and border color accordingly.
Im not sure we should allow setting font families sizes etc. Or at least then make it a set of presets like large, small or medium.

I would limit it even further to just the bare minimum styles and then see what the actual business needs are for adding custom styles on the banner. I personally would only like a single banner template with known constraints that can be met by design / marketing. This is so that we don't need to bother on worrying about making custom styles fit, and can just worry about making a single style template that should look good always.

@robhyrk I would like to limit the input from the marketing team as much as possible for simplicity.
Regarding button style, it should be a list of presets like blue, black, red, or purple. And we set the text and border color accordingly.
Im not sure we should allow setting font families sizes etc. Or at least then make it a set of presets like large, small or medium.

I would limit it even further to just the bare minimum styles and then see what the actual business needs are for adding custom styles on the banner. I personally would only like a single banner template with known constraints that can be met by design / marketing. This is so that we don't need to bother on worrying about making custom styles fit, and can just worry about making a single style template that should look good always.

Is this acceptable?

Promoted market design is here but not implemented yet https://www.figma.com/file/A0OEqjIWy6jL4Rk4kT8ddr/UX%2FUI_Workflow?node-id=4306%3A25062&t=0RBkkKyrs1Lt2JJA-0

May need some adjustments to the plaiceholder stuff after resolving conflicts


this fixes and closes issue #46

Add Steve Jobs

What does this PR do?:

Fixed bugs due to improper alignment and duplicates in contributors' list

Issue No: 46
Description of Task to be completed?

Re-arranged the table into rows of 7 columns

Removed the duplicates in contributors' list

@Evavic44
All right boss. I am on it.

Nice work @Jummate will fix the rest. 🙌🏾


depth image does not render with programmable renderer

hey,
if i turn on the programmable renderer,
something like...
    ofGLFWWindowSettings windowSettings;
    windowSettings.setGLVersion(4, 1);
    ....
    ofCreateWindow(windowSettings);

then the depth image no longer renders.

I've never checked.
I will check soon!

I found that same problem was reported at,
https://github.com/openframeworks/openFrameworks/issues/4378
Changing texture format resolved the problem.
For me, changing line 753 in ofxKinect2.cpp worked!
from:
tex.allocate(getWidth(), getHeight(), GL_RGBA, true, GL_LUMINANCE, GL_UNSIGNED_SHORT);
to:
tex.allocate(getWidth(), getHeight(), GL_R8, true, GL_RED, GL_UNSIGNED_SHORT);
tex.setRGToRGBASwizzles(true);


Same levels returning different IDs

A friend and I have been playing randomizers on CelesteNet, which had been working completely fine, except for some reason, after we played a level with the seed "nut" and these parameters, resulting in a heart saying "Huge Egg".:

The rooms excluded were Prologue, 1A, 2A, 3A, 4A, 5A, 6A.
After we completed this level without restarting the game or anything, we were for some reason unable to sync up our map IDs again.
For example, on my end, on the randomizer set to all options on the far left and all rooms, I would get this result.

On my friend's end, he would get this.

However, regardless of the difference in the ID at the end, it was very clear after playing the levels that the generated levels were completely identical. Same music, same room order, same backgrounds, and all.
After this, we both went to the original level that we were able to play together (the first level detailed at the start of the post), and we found we were still unable to sync up the IDs, but the level was very clearly the same as it originally was.

After setting both our settings to Ruleset A, and the seed "cucumber", suddenly everything synced up again.

I think the problem is something I’ve fixed already - there was an issue
with the internal representation of the enabled map list having duplicate
entries when you use the toggle all function. It’ll be fixed when the new
version comes out this weekend, but in the meantime if you run into this
again the “reset to default” on the map picker should clean up the bad
data.
On Thu, Sep 3, 2020 at 1:29 AM Bobberlington<EMAIL_ADDRESS>wrote:

After setting both our settings to Ruleset A, and the seed "cucumber",
suddenly everything synced up again.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rhelmot/CelesteRandomizer/issues/89#issuecomment-686338998,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AATCB5NKST5NCRHCTZMJYB3SD5HWBANCNFSM4QUPKQVQ
.
--
Audrey Dutcher
she/her/hers
http://rhelmot.io/


added () to config variant trimming character set

Hi @yonaskolb , I added some test cases and updated the changelog!

@yonaskolb removed that extra line.

@yonaskolb Fixed the incorrect test case

@yonaskolb I don't know why it's failing with fatal error.. I created a new pull request. https://github.com/yonaskolb/XcodeGen/pull/1080

@DavidWoohyunLee it's ok, it's an XcodeProj error. Linux builds have started failing on Github Actions. I've opened a PR here https://github.com/tuist/XcodeProj/pull/615


Debug Issue with Opera

This will require me to go to the Equipment Room at NYU to test on an Android device

We will be working with @dazuck on Monday at ADO, you can likely use his phone then @oznekenzo

From the Opera team:
Our team has verified and this is definitely a case of relying on web3 library injection.

`Uncaught TypeError: Cannot read property 'accounts' of undefined`

You need to include the library of your choice as part of your markup to resolve this issue.

Not sure why they are following a different paradigm from the other wallets, but will address this shortly

@michaelsena This is going to take a rework of the web3 logic behind the dapp - and then careful testing as it could break in some edge cases that are being influenced by the code - when do we want to do this?

Opera now working with web3connect


Sumatra fails when trying to parse JSON parameter file

When smt is run with the following file in an argument
{{{
{
"param1":false
}
}}}
an exception is raised:
{{{
Traceback (most recent call last):
File "/Users/bartosz/.virtualenvs/sumatra_devel/bin/smt", line 7, in
execfile(file)
File "/Users/bartosz/SVN/sumatra/src/smt", line 32, in
main(sys.argv[2:])
File "/Users/bartosz/SVN/sumatra/sumatra/commands.py", line 238, in run
parameters, input_data, script_args = parse_arguments(args)
File "/Users/bartosz/SVN/sumatra/sumatra/commands.py", line 74, in parse_arguments
parameter_sets.append(build_parameters(arg))
File "/Users/bartosz/SVN/sumatra/sumatra/parameters.py", line 229, in build_parameters
parameters = NTParameterSet("file://%s" % os.path.abspath(filename))
File "/Users/bartosz/SVN/sumatra/sumatra/external/NeuroTools/parameters.py", line 234, in init
initialiser = ParameterSet.read_from_str(pstr)
File "/Users/bartosz/SVN/sumatra/sumatra/external/NeuroTools/parameters.py", line 193, in read_from_str
D = eval(s, global_dict)
File "", line 2, in
NameError: name 'false' is not defined
}}}
The problem is probably with NTParameterSet which tries to parse a json file and fails on {{{false}}} value, which is valid in json but not in Python.
Imported from Bitbucket issue 65,  created by apdavison on 04-08-2011 at 13:51, last modified: 04-12-2011 at 13:54

Added support for using either "True" or "true" (similarly for fFalse) in NTParameterSet files - r233
Trac comment by apdavison on 04-12-2011 at 13:54


Not available using vs-code server

Not available to install via marketplace from vs-code server.
I'm using docker (linuxserver/code-server)
Manual installing vsix works without issue.

Can you show me what you're doing and whether you're getting any error message?

No error message, just says not listed.
https://user-images.githubusercontent.com/89784/215291023-12c961f1-0d84-45ff-9855-a32f83d2f34c.mp4
The docker compose file used:
version: "2.1"
services:
  code-server:
    image: lscr.io/linuxserver/code-server:latest
    container_name: code-server
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/London
      - DEFAULT_WORKSPACE=/config/workspace #optional
    volumes:
      - ./vscode/config:/config
    ports:
      - 8443:8443
    restart: unless-stopped


Backport #1764

Fixes #2106
I just cherry-picked https://github.com/webpack/webpack/commit/d883923da1b7fd5f7ef29a6b36357115488030c2

Hmm, the test failed as the index in the manifest is different. Is that a change in webpack 2 that it's zero-indexed?
Generated manifest in webpack 1:
{
  "name": "bundle0_5536af9024169d7fae43",
  "content": {
    "./index.js": 1
  }
}

And for webpack 2:
{
  "name": "bundle0_61dff25e034c4184621e",
  "content": {
    "./index.js": 0
  }
}

Thanks


[FEATURE] Add to calendar for each events.

Detailed description
An add to calendar feature would be nice to have on each event and hackathon card.
Context
This will allow user to mark the specific event in their calendar so they get notified when an event or hackathon is near.
Possible implementation
No response
Additional information
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

@Varghab can you explain a bit more so I can get clear understanding what  you are suggesting here to implement here.


New Master Duel update causing the mod to error out on "Connecting"

https://gyazo.com/79bd29d6c2d7abfb3d0164b5816ebfb0
The mod needs to be adapted to the new 8/6/2024 update, it seems.

Talked about it with Pixeltris. I was having Localsave problems again.

Talked about it with Pixeltris. I was having Localsave problems again.

Again? What was the issue? Did you get it fixed? Just in case I happen to run into it as well.

It was caused by a LocalSave bug that has existed for a little while which required opening the game with Steam again after attempting to open YgoMaster. This has been fixed in https://github.com/pixeltris/YgoMaster/commit/03eaa0336fd9378c6e035adcca8ccb12339907f1 so that workaround is no longer required


Any kind of vague list regarding what still needs to be fixed?

In your comment linking this repo you mention there's a lot of work that still needs to be done. Do you have a vague list of what things still need to be changed?
Also it seems that your fork still fails for me on building servo-fontconfig. Did you switch to a different create locally or are using something different for rendering?

There's now a larger list of issues that you could help with, check out the help-wanted label.


[Plot] Fix display of negative values with log scales

This PR fix display of negative values with log scale.
It replace values <= 0 with nan to show discontinuities.
It also filter xerror and yerror values if any of those is spanning error bars below 0 but changing those to nan.
Values stored with curves remains unchanged.
Closes #330

LGTM


Fix repeated "an" in the comments

Link to related issue (if applicable)
Summary of proposed changes

You're welcome.


Registered Ground Rules (Kernels) Memory Consumption

Every ground rule that gets created gets put into a Set (SetMultimap) in GroundAtom.
This is taking up a decent chunk of memory and is VERY rarely used.
Looks like only BernoulliMeanFieldEM and ConstraintBlocker (used by MaxPseudoLikelihood, LatentTopicNetworkMaxPseudoLikelihood_Naive, LatentTopicNetworkMaxPseudoLikelihood, BooleanMCSat, and BooleanMaxWalkSat) use this.
Since the most common (over 90%) use cases do not use this, we need to drop it down into some optional code path.

Registered ground rules have been dropped in lazy-grounding (af0bd0674ba8b373895a6d0a49c8bce3e2196809).
The map has been replaced with a specific atom manager (AtomRegisterGroundRuleStore) that keeps track of the GrondAtom <-> GroundRule mapping.


[WIP] Implementation of low-rank ADVI

Submission Checklist

[x] Write stan::variational::normal_lowrank: implement entropy, calc_grad, etc.
[ ] Implement sampling and other required functions
[ ] Add remaining boilerplate unit tests to src/test/unit/variational/families/normal_lowrank.cpp (e.g. for factor)
[ ] Write src/stan/services/experimental/advi/lowrank.hpp
[ ] Write documentation
[ ] Add required unit tests to src/test/unit/variational?
[ ] Write new model tests?
[ ] Run unit tests: ./runTests.py src/test/unit
[x] Run cpplint: make cpplint
[x] Declare copyright holder and open-source license: see below

Summary
Address the feature request in issue #2750. Implement the approach described in the original issue. A first pass at the math has already been completed. Although d seems to be used directly in the original paper, it might make more sense to reparameterize in terms of omega = log(d) (the gradient being equally easy to compute) as in the meanfield implementation.
How to Verify
Run new unit tests. Run new model tests.
Documentation
To do.
Copyright and Licensing
Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company):
Walter Nelson
By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:

Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

Thanks for submitting this.  It'd be greeat to have this feature.  @bbbales2 is working on something similar with @avehtari for HMC, so they probably want to have a look.
I added a [WIP] disclaimer (for "work in progress") in the title as this isn't yet ready to be merged.

Another note on process:  please don't push a lot of little commits as it puts undue pressure on our continuous integration, which fires a full round of tests after ever push.  Thanks.

Closing stale stan-dev/stan pull requests. This one has been a WIP for almost 2 years. Feel free to reopen if you wish to continue on this.

@rok-cesnovar hey, thanks for pinging me on this as it reminded me to actually get my work in a state where it might be merged! I'm about 1 cleanup commit away from having something ready for others to take a look at. Would you mind re-opening this for me, as it seems I don't have permissions? Many thanks!

@wjn0 I think just make a new pull. The button is greyed out for me as well and I should have permissions.

@bbbales2 cool, thanks!

I think you cant reopen until the branch has unresolved conflicts. But a new PR is fine by me.


I Cant start project on Flutter 3.10.0

Description
Hello
I Luv Very good cli
I has iusse yesterday
An error occurs when starting a project with Very good cli in a flutter 3.10.0 environment.
Expected Behavior
Because remove_app depends on flutter_localizations from sdk which depends on intl 0.18.0, intl 0.18.0 is required.
Screenshots

Additional Context
Add any other context about the problem here.

@BGM-109 its enough to update the pubspec.yaml it is easy....
name: my_app
description: A Very Good Project created by Very Good CLI.
version: 1.0.0+1
publish_to: none

environment:
  sdk: ">=2.19.0 <3.0.0"

dependencies:
  bloc: ^8.1.1
  flutter:
    sdk: flutter
  flutter_bloc: ^8.1.2
  flutter_localizations:
    sdk: flutter
  intl: ^0.18.0

dev_dependencies:
  bloc_test: ^9.1.1
  flutter_test:
    sdk: flutter
  mocktail: ^0.3.0
  very_good_analysis: ^4.0.0

flutter:
  uses-material-design: true
  generate: true

@mariopepe It's not being created project, Friend 🥲

This is known problem, known fixes exist - problem really isn't at VG Cli, but it surely feels strange to see it crashing..
https://github.com/dart-lang/i18n/issues/458
fixes: use transitive dependency from flutter directly or use dependency override
dependencies:
  intl: any # uses transitive dependency from flutter_localizations


Add nodeSelector to deployments

The following deployments have to be updated with a new nodeSelector:

example-quayecosystem-quay-config
example-quayecosystem-quay

The setting should be:
nodeSelector:
       node-role.kubernetes.io/infra: "true"

Closed via #54


Graph Support for GA4GH API

This PR adds graph support to the References, Reads, and Variant APIs in a backwards-compatible way.
common.avdl is enhanced with Segment and Path types, as well as the notion of a sequence and a sequence graph, which is described at length at the top of the file.
References can now have associated Segments, placing them in a sequence graph for the ReferenceSet.
Reads in the Reads API can now be aligned using GraphAlignments as well as LinearAlignments.
Variants in the Variants API can have Alleles defining their reference and alternate forms as paths in a sequence graph, and Calls can call copy numbers for individual Alleles as well as genotypes for Variants.
Closes #233

Thanks very much @adamnovak, this looks great. I can't see any backwards compatibility issues, so I would vote to merge this ASAP and start getting some real experience working with the graph model. A couple of minor, non-blocking issues:

Why UUIDs for sequences? This seems like an unnecessary requirement to me; implementation private IDs would be sufficient surely.
It would be good to clarify the relationship between a sequence/reference/segment, as they are used somewhat interchangeably in the documentation and in the methods.

@benedictpaten wanted UUIDs for sequences to facilitate merging across different API endpoints without having to rewrite or prefix IDs. If we are fine with having to manually construct truly global IDs (or just using accessions of some kind), I can get rid of the UUID thing.
For the sequence/reference/segment confusion, here's the simplest way I have found to put it so far:
A sequence is a component in a sequence graph, optionally joined at its ends to other sequences. Sequences are not directly retrievable through the API, but ranges of their bases can be downloaded.
A Segment is a pointer to a range on a sequence, possibly including the joins at the sequence's ends. It does not include base data. When the server has to refer to some or all of the bases in a sequence, it uses a Segment to indicate them. A Path through a sequence graph is a list of Segments, while a sequence graph itself can be described using a set of Segments, one for each sequence.
A Reference is an object that marks a sequence as part of a ReferenceSet's sequence graph. It contains a Segment referring to the entirety of the sequence it annotates.
This all kind of depends on the explanation of sequence graphs at the top of common.avdl, but I feel like maybe it should come first to give a higher-level overview. Thoughts?

OK, as a result of the discussion on the call this morning, I've introduced the concept of supported modes. API servers that support the "graph" mode will always populate the graph fields, and API endpoints that support the "classic" mode will always populate the non-graph-supporting fields that I made nullable (and also won't do confusing things like return GraphAlignments in the reads API).
If a server supports the "classic" mode, a client doesn't have to know anything about graphs in order to use it. If a server supports the "graph" mode, a client can just look at the new graph fields and not have to worry about doing its own up-conversion. A server can support both modes perfectly fine, although it won't be able to return things only expressible in graph terms.
This doesn't require any state on the server side; a server is permanently fixed in the modes it supports and the fields it fills in, regardless of what a client actually wants to use.

Re UUIDs - we've gone with hashes everywhere else for these sorts of requirements. I think we should change to ID here and add in a hash field of some sort later.

For metadata we make the format for id => UUID (recommended):
  /**
  The individual UUID. This is globally unique.
  The recommendation is to use an anonymous UUID type with extremely low collision probability.
  The typical implementation would be UUIDv4.
  This has to be provided by the implementation.
  */
  string id;

This is from the working doc https://github.com/ga4gh/metadata-team/blob/master/avro-playground/metadata_redo.avdl

I like the modes distinction @adamnovak --- I'm not sure about the exact mechanism for clients to discover the mode that a server is running in, but I think something like this is what we need. I'd like to clarify what I think is important about having these two modes, and why we need them.
There are a lot of people out there who have VCF data relative to a linear reference who would like to share their data. There are a lot of tools out there that ingest data in VCF. The v0.5 classic API is a direct translation of the concepts that these tools understand, and allow us to serve VCF data in a relatively straightforward manner. Importantly, we can convert from VCF to the classic API easily allowing us to make data available. We can also convert data from the classic API back to VCF in a one-to-one manner, allowing us to use existing tools on data coming from a GA4GH server. There will be VCF data for quite a long time, and it's critical to the success of the protocol that these workflows are supported naturally.
Ultimately, we hope that the field will move from a linear reference to a graph reference, but this will take a long time. We need to provide an evolutionary path for tools to follow: first they adopt the classic APIs, which translate fairly directly into the concepts that they work with today. Then, slowly, they start to adapt to the graph APIs and begin reaping the benefits (which we will demonstrate). Eventually, everyone (or at least a lot of people) will have moved over to the graph API, and we can then start to deprecate the classic API, eventually removing it altogether.
The main reason we don't want two different protocols is to avoid splitting our resources, and wasting time keeping them in sync. The classic and graph mode APIs  must be closely compatible for this strategy to work, and the best way to do this is by implementing both simultaneously. If we fork off two separate protocols, they will never again merge and we'll split our limited developer resources between working on one or the other.
There are unarguably downsides to this dual protocol approach, but I think they can be alleviated fairly easily. Firstly, server implementations are in no way required to implement graph mode, and are free to continue using classic mode for as long as they want. Secondly, clients should be encouraged to use classic mode by default, as this is by far the most likely thing that they would want to do. Also, graph mode is experimental, and will probably change considerably over time and so new users of the protocol should not be exposed to it unless this is explicitly what they want. A graph mode capable server running in classic mode should not return any of the new attributes in the JSON responses (since they will be null, it is the same thing to just leave the fields out).
The approach is a compromise, but it is hopefully one which allows us to both support users who want to work with existing datasets, and also to develop the graph based methods.

As long as our data can be converted between VCF and the graph model,
people will continue to be able to use tools structured around the linear
reference. The same goes for BAM and graph-based alignments. Obviously
these models are not completely congruent, so conversion from graphs ->
linear systems will lose data, but in the vast majority of cases it seems
trivial to convert back and forth between a linear and a graph way of
working.
I think that a gradual development to using the graph is unlikely, and
instead big leaps will be made where it is adopted. Most old tools will
remain useful as long as conversion back to the linear model is easy. New
tools will be written against a graph model.
On Thu, Feb 5, 2015 at 2:31 PM, Jerome Kelleher<EMAIL_ADDRESS>wrote:

I like the modes distinction @adamnovak https://github.com/adamnovak
--- I'm not sure about the exact mechanism for clients to discover the mode
that a server is running in, but I think something like this is what we
need. I'd like to clarify what I think is important about having these two
modes, and why we need them.
There are a lot of people out there who have VCF data relative to a linear
reference who would like to share their data. There are a lot of tools out
there that ingest data in VCF. The v0.5 classic API is a direct translation
of the concepts that these tools understand, and allow us to serve VCF data
in a relatively straightforward manner. Importantly, we can convert from
VCF to the classic API easily allowing us to make data available. We can
also convert data from the classic API back to VCF in a one-to-one manner,
allowing us to use existing tools on data coming from a GA4GH server. There
will be VCF data for quite a long time, and it's critical to the success of
the protocol that these workflows are supported naturally.
Ultimately, we hope that the field will move from a linear reference to a
graph reference, but this will take a long time. We need to provide an
evolutionary path for tools to follow: first they adopt the classic APIs,
which translate fairly directly into the concepts that they work with
today. Then, slowly, they start to adapt to the graph APIs and begin
reaping the benefits (which we will demonstrate). Eventually, everyone (or
at least a lot of people) will have moved over to the graph API, and we can
then start to deprecate the classic API, eventually removing it altogether.
The main reason we don't want two different protocols is to avoid
splitting our resources, and wasting time keeping them in sync. The classic
and graph mode APIs must be closely compatible for this strategy to
work, and the best way to do this is by implementing both simultaneously.
If we fork off two separate protocols, they will never again merge and
we'll split our limited developer resources between working on one or the
other.
There are unarguably downsides to this dual protocol approach, but I think
they can be alleviated fairly easily. Firstly, server implementations are
in no way required to implement graph mode, and are free to continue using
classic mode for as long as they want. Secondly, clients should be
encouraged to use classic mode by default, as this is by far the most
likely thing that they would want to do. Also, graph mode is experimental,
and will probably change considerably over time and so new users of the
protocol should not be exposed to it unless this is explicitly what they
want. A graph mode capable server running in classic mode should not return
any of the new attributes in the JSON responses (since they will be null,
it is the same thing to just leave the fields out).
The approach is a compromise, but it is hopefully one which allows us to
both support users who want to work with existing datasets, and also to
develop the graph based methods.
—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/schemas/pull/238#issuecomment-73054669.

@jeromekelleher The way I've done the modes now, it's perfectly fine for a server to support both the graph and classic modes, as long as they don't say things that can't be articulated in classic mode. I think that that would be the mode you want to run your servers in, because you have maximum compatibility with all clients.
I guess it makes sense not to send any graph fields if you don't actually advertise support for graph mode; however, I didn't write that in as a requirement, and I think clients should have to handle it. A classic-mode-only client doesn't have to interpret graph mode fields, but it does have to correctly ignore them if they are present. Otherwise it wouldn't work on a server that sends both modes.
While a client will probably want to support reading data in classic mode, I agree with @ekg and think new client development should be focused on graph mode. A client designed around graph mode can do its own trivial upconversion of classic mode replies, but the reverse is not true.
@mbaudis I think standardizing all the GA4GH APIs on recommending the use of UUIDs for record IDs is probably a good idea, but I'd like to do it in a seperate pull request, since it would apply to a bunch of API objects I haven't touched in this one.
Does anyone have any recommendations for things I should change? Or other reasons why they can't give this a +1?

@adamnovak My UUID comment was just a reminder to push this as a global default, not necessarily here; though objects with clear & limited context/scope may probably do better without the generation/storage overhead (?).
Don't feel entitled to +1 in though out of sheer personal incompetence ...

I'm +1 on this (obviously), but we need at least a couple of non-UCSC people to +1 it. I think Adam should squash down the commits to make it a bit easier to digest the changes.

I've squashed everything down to one commit for ease of evaluation. I'd appreciate it if people could take a look at this.

Several comments.

Are "classical" and "graph" the right names? This PR consists of two largely independent components: graph representation and allelic model. By independence, I mean we could in principle split this PR into the two with little interference. The graph mode is actually "graph+allelic", and the "classical" is "linear+genotypic". There could also be other combinations "linear+allelic" and "graph+genotypic" as well. In variants.avdl of this PR, we frequently say that some fields are mandatory in the graph mode, but more exactly, most of them are required by the allelic model, not by the graph representation. I think we need to rename the "graph mode" to something that is conceptually correct. I couldn't think of a clean name, though.

The Call object is overloaded. In the genotypic model, a call is a genotype call. In the allelic model, a call is an allele call with a very different set of new fields (the only overlapping field is apparently callSetId). The overloading obscures the meaning of Call. I would suggest completely separating allelic and genotypic calls by adding an AlleleCall object and moving allele-associated fields to the new object. AlleleCall is conceptually different from the old Call object.

Similarly the Variant object is overloaded to a lesser extent - some fields are allelic only and some are genotypic only. We might consider a similar treatment (see also point 4 below). On the other hand, Variant is a concept common to both allelic and genotypic models. Adding AlleleVariant seems inconsistent. I am not sure if there is a better solution.

If we decide to use one Variant object in both the genotypic and allelic models, we need to be careful about the updated time. In the genotypic model, the allele sequences are members of Variant, which would imply that update the allele sequences would change the updated time. In the allelic model, the ID of alleles, rather than the alleles themselves, are members of Variant. If we change an allele sequence without changing its ID, do we change the updated time? In addition, for the referenceName, start and a few other fields, the API doc only says "If the API server supports the classic mode, this field must not be null", but it does not specify what these fields mean in the "graph" (more exactly allelic) mode. Do they have to be null? If we create an AlleleVariant object, this won't be a problem.

Could someone write down code snippets to retrieve the genotype of some samples in a small region? I wrote some when the allelic model was on a separate branch. With both genotypic and allelic models mixed together, I am even less sure about what is the right code. This is critically important. If we creators of the APIs have difficulties in writing down the queries, endusers will have more troubles.

@lh3 raises excellent points. I have no issue with creating new types AlleleCall and AlleleVariant, except it does complicate things further up the stack. For example, SearchVariantsResponse contains a list variants, which has the type array<Variant>. This would then need to be union( array<Variant>, array<AlleleVariant>), so that we can return either type. (Avro's lack of inheritance is getting increasingly annoying.) We're then just pushing the overloading further up the stack. I'm not sure which option is better: have the overloading occurring at the query level, or at the object level.
In general, we seem to have two choices:

Overload some types so that we can to implement the graph+allelic model as well as the linear+genotype model using the same queries;
Make new types and queries exclusively for the graph+allelic model. This brings us back to the namespacing approach.

What do you think @lh3, which is the lesser of two evils?

Heng is right. The big distinction here, the one that will affect genetics
for decades, is "genotypic" versus "allelic". It would be a mistake to try
to get the world to convert to a graph model without explaining the deep
motivation for adding an "allelic" mode and eventually deprecating the
"genotypic" mode.
On Tue, Feb 10, 2015 at 3:52 PM, Heng Li<EMAIL_ADDRESS>wrote:

Several comments.

Are "classical" and "graph" the right names? This PR consists of two
largely independent components: graph representation and allelic model. By
independence, I mean we could in principle split this PR into the two with
little interference. The graph mode is actually "graph+allelic", and the
"classical" is "linear+genotypic". There could also be other combinations
"linear+allelic" and "graph+genotypic" as well. In variants.avdl of
this PR, we frequently say that some fields are mandatory in the graph
mode, but more exactly, most of them are required by the allelic model, not
by the graph representation. I think we need to rename the "graph mode" to
something that is conceptually correct. I couldn't think of a clean name,
though.
2.
The Call object is overloaded. In the genotypic model, a call is a
genotype call. In the allelic model, a call is an allele call with a very
different set of new fields (the only overlapping field is apparently
callSetId). The overloading obscures the meaning of Call. I would
suggest completely separating allelic and genotypic calls by adding an
AlleleCall object and moving allele-associated fields to the new
object. AlleleCall is conceptually different from the old Call object.
3.
Similarly the Variant object is overloaded to a lesser extent - some
fields are allelic only and some are genotypic only. We might consider a
similar treatment (see also point 4 below). On the other hand, Variant
is a concept common to both allelic and genotypic models. Adding
AlleleVariant seems inconsistent. I am not sure if there is a better
solution.
4.
If we decide to use one Variant object in both the genotypic and
allelic models, we need to be careful about the updated time. In the
genotypic model, the allele sequences are members of Variant, which
would imply that update the allele sequences would change the updated
time. In the allelic model, the ID of alleles, rather than the alleles
themselves, are members of Variant. If we change an allele sequence
without changing its ID, do we change the updated time? In addition,
for the referenceName, start and a few other fields, the API doc only
says "If the API server supports the classic mode, this field must not be
null", but it does not specify what these fields mean in the "graph" (more
exactly allelic) mode. Do they have to be null? If we create an
AlleleVariant object, this won't be a problem.
5.
Could someone write down code snippets to retrieve the genotype of
some samples in a small region? I wrote some when the allelic model was on
a separate branch. With both genotypic and allelic models mixed together, I
am even less sure about what is the right code. This is critically
important. If we creators of the APIs have difficulties in writing down the
queries, endusers will have more troubles.
—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/schemas/pull/238#issuecomment-73809927.

Well, not really "deprecating". Genotypic is here to stay. Maybe making it
more of a derived summary from the allelic information.
On Wed, Feb 11, 2015 at 8:17 AM, David Haussler<EMAIL_ADDRESS>wrote:

Heng is right. The big distinction here, the one that will affect genetics
for decades, is "genotypic" versus "allelic". It would be a mistake to try
to get the world to convert to a graph model without explaining the deep
motivation for adding an "allelic" mode and eventually deprecating the
"genotypic" mode.
On Tue, Feb 10, 2015 at 3:52 PM, Heng Li<EMAIL_ADDRESS>wrote:

Several comments.

Are "classical" and "graph" the right names? This PR consists of two
largely independent components: graph representation and allelic model. By
independence, I mean we could in principle split this PR into the two with
little interference. The graph mode is actually "graph+allelic", and the
"classical" is "linear+genotypic". There could also be other combinations
"linear+allelic" and "graph+genotypic" as well. In variants.avdl of
this PR, we frequently say that some fields are mandatory in the graph
mode, but more exactly, most of them are required by the allelic model, not
by the graph representation. I think we need to rename the "graph mode" to
something that is conceptually correct. I couldn't think of a clean name,
though.
2.
The Call object is overloaded. In the genotypic model, a call is a
genotype call. In the allelic model, a call is an allele call with a very
different set of new fields (the only overlapping field is apparently
callSetId). The overloading obscures the meaning of Call. I would
suggest completely separating allelic and genotypic calls by adding an
AlleleCall object and moving allele-associated fields to the new
object. AlleleCall is conceptually different from the old Call object.
3.
Similarly the Variant object is overloaded to a lesser extent - some
fields are allelic only and some are genotypic only. We might consider a
similar treatment (see also point 4 below). On the other hand, Variant
is a concept common to both allelic and genotypic models. Adding
AlleleVariant seems inconsistent. I am not sure if there is a better
solution.
4.
If we decide to use one Variant object in both the genotypic and
allelic models, we need to be careful about the updated time. In the
genotypic model, the allele sequences are members of Variant, which
would imply that update the allele sequences would change the updated
time. In the allelic model, the ID of alleles, rather than the alleles
themselves, are members of Variant. If we change an allele sequence
without changing its ID, do we change the updated time? In addition,
for the referenceName, start and a few other fields, the API doc only
says "If the API server supports the classic mode, this field must not be
null", but it does not specify what these fields mean in the "graph" (more
exactly allelic) mode. Do they have to be null? If we create an
AlleleVariant object, this won't be a problem.
5.
Could someone write down code snippets to retrieve the genotype of
some samples in a small region? I wrote some when the allelic model was on
a separate branch. With both genotypic and allelic models mixed together, I
am even less sure about what is the right code. This is critically
important. If we creators of the APIs have difficulties in writing down the
queries, endusers will have more troubles.
—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/schemas/pull/238#issuecomment-73809927.

Hi David, Heng,
Having been involved in API design before, it is hard to stress
how important it is to get the terminology and naming right now.
If the terminology is confusing, it will confuse people for the
next 20 years.
We also need to have complete, comprehensive documentation for
all of the APIs, including rationale, in of the source tree.
Documentation not in the source tree will be out-of-sync, lost,
or just plain wrong.
Mark
haussler<EMAIL_ADDRESS>writes:

Heng is right. The big distinction here, the one that will affect genetics
for decades, is "genotypic" versus "allelic". It would be a mistake to try
to get the world to convert to a graph model without explaining the deep
motivation for adding an "allelic" mode and eventually deprecating the
"genotypic" mode.
On Tue, Feb 10, 2015 at 3:52 PM, Heng Li<EMAIL_ADDRESS>wrote:

Several comments.

Are "classical" and "graph" the right names? This PR consists of two
largely independent components: graph representation and allelic model. By
independence, I mean we could in principle split this PR into the two with
little interference. The graph mode is actually "graph+allelic", and the
"classical" is "linear+genotypic". There could also be other combinations
"linear+allelic" and "graph+genotypic" as well. In variants.avdl of
this PR, we frequently say that some fields are mandatory in the graph
mode, but more exactly, most of them are required by the allelic model, not
by the graph representation. I think we need to rename the "graph mode" to
something that is conceptually correct. I couldn't think of a clean name,
though.
2.
The Call object is overloaded. In the genotypic model, a call is a
genotype call. In the allelic model, a call is an allele call with a very
different set of new fields (the only overlapping field is apparently
callSetId). The overloading obscures the meaning of Call. I would
suggest completely separating allelic and genotypic calls by adding an
AlleleCall object and moving allele-associated fields to the new
object. AlleleCall is conceptually different from the old Call object.
3.
Similarly the Variant object is overloaded to a lesser extent - some
fields are allelic only and some are genotypic only. We might consider a
similar treatment (see also point 4 below). On the other hand, Variant
is a concept common to both allelic and genotypic models. Adding
AlleleVariant seems inconsistent. I am not sure if there is a better
solution.
4.
If we decide to use one Variant object in both the genotypic and
allelic models, we need to be careful about the updated time. In the
genotypic model, the allele sequences are members of Variant, which
would imply that update the allele sequences would change the updated
time. In the allelic model, the ID of alleles, rather than the alleles
themselves, are members of Variant. If we change an allele sequence
without changing its ID, do we change the updated time? In addition,
for the referenceName, start and a few other fields, the API doc only
says "If the API server supports the classic mode, this field must not be
null", but it does not specify what these fields mean in the "graph" (more
exactly allelic) mode. Do they have to be null? If we create an
AlleleVariant object, this won't be a problem.
5.
Could someone write down code snippets to retrieve the genotype of
some samples in a small region? I wrote some when the allelic model was on
a separate branch. With both genotypic and allelic models mixed together, I
am even less sure about what is the right code. This is critically
important. If we creators of the APIs have difficulties in writing down the
queries, endusers will have more troubles.
—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/schemas/pull/238#issuecomment-73809927.

—
Reply to this email directly or view it on GitHub.*

@diekhans for comprehensive documentation inside the repository, I suggest using Pandoc. We use this with ADAM and it makes the process of attaching docs to a release seamless.

Re UUIDs - we've gone with hashes everywhere else for these sorts of requirements. I think we should change to ID here and add in a hash field of some sort later.

+1 @jeromekelleher

@lh3 raises excellent points. I have no issue with creating new types AlleleCall and AlleleVariant, except it does complicate things further up the stack. For example, SearchVariantsResponse contains a list variants, which has the type array. This would then need to be union( array, array), so that we can return either type. (Avro's lack of inheritance is getting increasingly annoying.) We're then just pushing the overloading further up the stack. I'm not sure which option is better: have the overloading occurring at the query level, or at the object level.

Wouldn't it make more sense to have SearchAllelicVariants and SearchGenotypicVariants? I think earlier we had said that a server that was going to serve both variant types would need to maintain some state (indicating what sort of variants it had). Here, we would make the request type explicit, and the server could just error if it can't serve either of Allelic or Genotypic variants.
I'd generally prefer to not overload types via unions.

Call shares a few fields between Calls that are associated with an Allele and Calls that aren't: both can use totalCopies, phaseset, callSetName, callSetId, and variantId (since a call on an Allele can also have an associated Variant).
If we split it up, we'll have to duplicate a substantial portion of the Variants API, and have some sort of constraint that the two views agree with each other.

Well, not really "deprecating". Genotypic is here to stay. Maybe making it
more of a derived summary from the allelic information.

+1; it seems like this is a necessary condition for the API. If people can't convert data stored in the allelic model to the genotypic model, people won't store data in the allelic model.

For mode names, I definitely don't want to call the modes "genotypic" and "allelic". If you're using linear sequences you can only make genotypic calls, but if you're using graphs you can make both genotypic and allelic calls, and will probably want to have both in the same CallSet. I think "classic" and "graph" (or maybe "linear" and "graph") is the right terminology.
So here's how a split API would probably want to work:
I think we need to keep the Variant type unified, because as I said you might want to make genotypic and allelic calls on what is really the same variant. You do end up with duplication of information between the backwards-compatible linear-reference fields and the new Allele ID references, but everything else is still shared, and we don't want to be calling it AllelicVariant or something forever into the future.
We would probably want to keep Call as the name of the genotypic call for backwards compatibility, and add a new AlleleCall. While a Call has to be associated with a Variant and gives a genotype, an AlleleCall is associated with an Allele and optionally a Variant, and gives a copy number.
We would then have one method searchCalls() to get Call objects (by CallSet, Variant, or both), and another method searchAlleleCalls() to get AlleleCall objects (by CallSet, Allele, and/or Variant).
These two methods don't quite map to the different modes, though. A server that serves classic/linear mode has to support searchCalls(), but a server that serves graph mode has to support both searchAlleleCalls() and searchCalls(), because we still want to provide people with a way to make genotype calls when they are defining Variants in terms of Alleles in the graph.
How would that look to people?

Thanks Heng, Jerome.
We debated splitting out the graph fields from both call and variant. Adam
has a nice UML diagram that he's working on that makes it easier to see the
relationships - @adamnovak, I think you should post this.  Jerome wanted
backwards compatibility - well we've got it, but the cost is some apparent
duplication.
I agree with Heng about creating code snippets. Adam - can you get Maciek
to do this as an exercise?
To David's point, I think it's very important to distinguish the concept of
genotypes (sites) vs. allelic and linear reference vs. graph reference.
These are separate ideas. What we have now allows us to express, as Heng
says, all four combinations of model: genotypes+linear-ref,
genotypes+graph-ref, allelic+graph-ref, and allelic+linear-ref (because
the linear-reference is a special case of the graph model - so you can use
the new segment object to describe an allele).
I think this will be cleaner in the future, because we can slowly deprecate
the linear reference stuff, then we'll end up with a single variant object,
which allows us to express genotypes on the graph and a single allele
object.
My strong opinion is not to split variant into variant and allele variant,
it does not fit the semantics.
I am ambivalent about splitting the call object into allele and genotype
calls.
On Wed, Feb 11, 2015 at 6:44 AM, Jerome Kelleher<EMAIL_ADDRESS>wrote:

@lh3 https://github.com/lh3 raises excellent points. I have no issue
with creating new types AlleleCall and AlleleVariant, except it does
complicate things further up the stack. For example,
SearchVariantsResponse contains a list variants, which has the type
array. This would then need to be union( array,
array), so that we can return either type. (Avro's lack of
inheritance is getting increasingly annoying.) We're then just pushing the
overloading further up the stack. I'm not sure which option is better: have
the overloading occurring at the query level, or at the object level.
In general, we seem to have two choices:

Overload some types so that we can to implement the graph+allelic
model as well as the linear+genotype model using the same queries;
Make new types and queries exclusively for the graph+allelic model.
This brings us back to the namespacing approach.

What do you think @lh3 https://github.com/lh3, which is the lesser of
two evils?
—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/schemas/pull/238#issuecomment-73891878.

I also think we should split Call. I actually more like to add GenotypeCall and gradually deprecate Call, but I wouldn't insist on this. As to Variant, are we regarding a variant in the VCF/classical mode exactly the same as a variant in the graph+allelic mode?

Might I propose @lh3 and @jeromekeller that we explore splitting these
objects as a subsequent pull request? For sake of getting things done, we
really need to get something accepted soon - we have a developer hired now
to build this into the reference server! I suspect that as we implement it
we will be proposing changes to improve it. As I say, I'm currently the
only +1 on this, and it would be great for others to feel that this is at
least a good-enough starting point on which we can iterate.
On Wed, Feb 11, 2015 at 9:39 AM, Benedict Paten<EMAIL_ADDRESS>wrote:

Thanks Heng, Jerome.
We debated splitting out the graph fields from both call and variant. Adam
has a nice UML diagram that he's working on that makes it easier to see the
relationships - @adamnovak, I think you should post this.  Jerome wanted
backwards compatibility - well we've got it, but the cost is some apparent
duplication.
I agree with Heng about creating code snippets. Adam - can you get Maciek
to do this as an exercise?
To David's point, I think it's very important to distinguish the concept
of genotypes (sites) vs. allelic and linear reference vs. graph reference.
These are separate ideas. What we have now allows us to express, as Heng
says, all four combinations of model: genotypes+linear-ref,
genotypes+graph-ref, allelic+graph-ref, and allelic+linear-ref (because
the linear-reference is a special case of the graph model - so you can use
the new segment object to describe an allele).
I think this will be cleaner in the future, because we can slowly
deprecate the linear reference stuff, then we'll end up with a single
variant object, which allows us to express genotypes on the graph and a
single allele object.
My strong opinion is not to split variant into variant and allele variant,
it does not fit the semantics.
I am ambivalent about splitting the call object into allele and genotype
calls.
On Wed, Feb 11, 2015 at 6:44 AM, Jerome Kelleher<EMAIL_ADDRESS>
wrote:

@lh3 https://github.com/lh3 raises excellent points. I have no issue
with creating new types AlleleCall and AlleleVariant, except it does
complicate things further up the stack. For example,
SearchVariantsResponse contains a list variants, which has the type
array. This would then need to be union( array,
array), so that we can return either type. (Avro's lack
of inheritance is getting increasingly annoying.) We're then just pushing
the overloading further up the stack. I'm not sure which option is better:
have the overloading occurring at the query level, or at the object level.
In general, we seem to have two choices:

Overload some types so that we can to implement the graph+allelic
model as well as the linear+genotype model using the same queries;
Make new types and queries exclusively for the graph+allelic
model. This brings us back to the namespacing approach.

What do you think @lh3 https://github.com/lh3, which is the lesser of
two evils?
—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/schemas/pull/238#issuecomment-73891878.

On Wed, Feb 11, 2015 at 9:57 AM, Heng Li<EMAIL_ADDRESS>wrote:

I also think we should split Call. I actually more like to add
GenotypeCall and gradually deprecate Call, but I wouldn't insist on this.
As to Variant, are we regarding a variant in the VCF/classical mode
exactly the same as a variant in the graph+allelic mode?

That was the intention. There is some weirdness. In the vcf/classic model a
site is a set of edits to a reference substring. In the graph model a
variant is a collection of alleles - they don't have to be homologous,
because we don't know how to define homologous in the graph world. I think
@richarddurbin has made the point repeatedly, but homology is difficult to
define and not transitive when talking about the relationship between
substrings (rather than individual bases). I'd welcome a proposal to
clarify this.

—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/schemas/pull/238#issuecomment-73929686.

OK, by popular demand I have split Call into Call and AlleleCall, and added a searchAlleleCalls() method.
This is simpler in that Calls will always have genotypes, and AlleleCalls will always have Allele copy number assertions (possibly associated with Variants). This lets the objects be simpler and removes a bunch of constraints about what needs to be set in what mode.
It's more complicated in that if you want all the information for a CallSet you need to use both searchCalls() to download any genotypes and searchAlleleCalls() to download Allele copy number assertions. I've added the constraint that the two views need to be consistent. I've also required that you serve Calls for every Variant you have AlleleCalls for if you support "classic" mode, and visa versa if you support "graph" mode, so you should be able to just query the kind of call that you want and get a more or less complete view of the CallSet.

Going back to last night's comments by Heng, I've tried to craft a simple
beginner's introduction to what we are doing for the benefit of those
outside our group. It is pasted below and attached in Word. Heng, Richard,
Adam others, please replace or edit as needed, pointing to diagrams and
examples (I agree with Adam these are essential). I think we need something
that gives a high-level intro and is pointed to from the schemas. -D
The allelic model of genetic variation
The field of genetics was born before we could read genomes, yet through
exceedingly clever experiments and careful observations, the pioneers of
genetics were able to form a very accurate model of the basic structure of
genetic information. We refer to this model as the genotypic model.  In the
genotypic model, (1) each individual in a diploid population has a set of
chromosomes that may be numbered 1, …, n,  (2) each individual carries
two copies of each of these n chromosomes, the sex chromosomes and
mitochondria being considered a special case, and (3) each chromosome copy
consists of a defined linear (or circular) sequence of sites, where each
site carries one of a finite set of possible alleles. In its most
fine-grained form, each site consists of a single basepair of DNA. While
this model has enormous conceptual and practical advantages, it is an
abstraction that is not completely accurate, and this has been a problem
for the field.
The more accurate model is simple: each individual has a genome, where a
genome is simply a set of molecules of double-stranded DNA. In a real
genome, pieces of DNA that represent alleles of particular sites in the
genotypic model occasionally appear in different numbers, different
locations, and different orientations, and this matters. Also, completely
novel DNA is observed. As we learn to read genomes with increasing
fidelity, the inadequacies of the genotypic model become more apparent.  We might contemplate simply replacing the
genotypic model with the direct observation of a complete genome. However,
it will never be practical to base all genetic analysis directly on the
reading of an entire genome. For one thing, a genome is too big and
complicated to be treated as a unit. Moreover, despite its shortcomings,
the genotypic model remains a very powerful and useful abstraction.
The allelic model of genetic variation is an abstraction that sits at a
level below the genotypic model, but above the model that merely represents
a genome as a set of molecules of double-stranded DNA. Instead of a single
linear coordinate system that is used to demarcate multi-allelic sites
along the chromosomes, in the allelic model the genome variation present in
the population is described by a network- or graph-like structure,
representing segments of DNA that appear in typical genomes in the
population, along with their common alternatives and common variations in
number, order and orientation [diagram].  We refer to this graph as a
(genome) reference structure. A chromosome is a path through this reference
structure, and a genome is a set of chromosomes.
Instead of sites, the elementary units of a reference structure are
positions. Each position consists of an orientation and a single base of
DNA. The orientation tells us whether that base is on the top or bottom
strand, and thus indicates on which side of it we expect to find the next
base when moving in the standard 5’ to 3’ direction. When a component of
the reference structure is linear, with no branching or “bubble”
alternatives, one can think of it in conventional terms as a series of
1-base sites defining the coordinate system plus the typical base content
of a reference chromosome, e.g. as in the “primary path” of the current
human genome reference of the International Nucleotide Sequence Database
Consortium, version GRCh38. Non-linear aspects of the reference structure,
e.g. “bubbles” that come off of the primary path, can be thought of as
alternate haplotypes, like the alternate haplotypes that are defined as an
adjunct to the primary paths of GRCh38. One difference, however, is that a
general reference structure allows cycles, so the path that defines a
particular individual’s chromosome may repeat a part of the reference
structure an arbitrary number of times.
In the allelic model, an allele is defined as a sequence of positions that
form a (sub)path in the graph structure, i.e. such that each position is
allowed by the edges of the graph structure to follow the previous
position. One can think of an allele roughly as the sequence of DNA spelled
out by a particular sequence of positions, but it is more than that. The
same sequence of DNA may be spelled out other places in the graph as well.
When we say that a genome has a particular allele, we are asserting that
the path for one of the DNA molecules in that genome passes through this
sequence of positions, contiguously, at some point along its extent, either
in one direction (strand) or the other.  This means that the individual’s
genome contains whatever biological feature, such as a particular form of
an exon, gene, etc., that is represented by this sequence of positions in
the reference structure. If we say the allele appears twice in the
individual’s genome then this asserts that the set of paths representing
that individual’s chromosomes, considered in aggregate, pass through this
particular sequence of positions twice. It is not asserted that these
allele traversals occur in two separate DNA molecules, or in any particular
orientations. Two alleles, be they the same or different, are not assumed
to be either phased or unphased by default. Phasing information must be
explicitly specified in addition to allelic information.
The allelic model does not have the classical genetics concepts of “site”
or “genotype at a site”. These concepts must be added on top of the allelic
model if needed.  In the allelic model, each position, and hence each
allele, has just one DNA sequence associated with it.   One might define an
“allelotype” as a set of alleles that are asserted to be present in an
individual’s genome, each with a specified copy number, zero being an
allowed copy number. This asserts that the double-stranded DNA molecules of
the individual’s genome follow a set of paths that traverse the sequences
of positions defined by these alleles the required number of times. These
traversals may occur in any combination of order, orientation and phasing.
Other DNA may also be included in the individual’s genome that is not
listed in the allelotype. This contrasts with a “genotype” in which it
asserted that the individual’s double-stranded DNA molecules include a
specific set of (classical) allelic variants in the default order and
orientation, with only the phasing (and possible additional DNA) left
unspecified. In this sense we claim that the classical genotypic model can
be built on top of the allelic model as a special case, by using additional
assumptions or assertions.
The allelic model is a richer foundation for genetics. Using something like
it becomes a requirement when one attempts to analyze and reason about
whole genomes. We hope that the new data schemas and application
programming interfaces we are defining for the allelic model will support
the further development of this model for both research and clinical use.
On Wed, Feb 11, 2015 at 11:34 AM, adamnovak<EMAIL_ADDRESS>wrote:

OK, by popular demand I have split Call into Call and AlleleCall, and
added a searchAlleleCalls() method.
This is simpler in that Calls will always have genotypes, and AlleleCalls
will always have Allele copy number assertions (possibly associated with
Variants). This lets the objects be simpler and removes a bunch of
constraints about what needs to be set in what mode.
It's more complicated in that if you want all the information for a
CallSet you need to use both searchCalls() to download any genotypes and
searchAlleleCalls() to download Allele copy number assertions. I've added
the constraint that the two views need to be consistent. I've also required
that you serve Calls for every Variant you have AlleleCalls for if you
support "classic" mode, and visa versa if you support "graph" mode, so you
should be able to just query the kind of call that you want and get a more
or less complete view of the CallSet.
—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/schemas/pull/238#issuecomment-73948312.

Speaking of the importance of images, I've done up a UML class diagram of all the data model records, so we can see my proposed changes (on the right) as well as how the whole API fits together.
http://hgwdev.sdsc.edu/~anovak/images/Global UML.png

@fnothaft , we don't need to use Avro IDL.  We can either change it - which many companies do internally - or use something like WebIDL which provides inheritance capabilities:
http://www.w3.org/TR/WebIDL/
If we keep working around the limitations of Avro, the schema will become cumbersome to support and expand upon.
Paul

I'm in favour of merging this now. It seems clear that the consensus is that we want something like this, but it's also clear that it will take some time to resolve the remaining issues. I would suggest that the most productive approach now would be to merge what we have and start filing issues and PRs against it to resolve the outstanding problems.
+1.

Richard astutely pointed out that there were some obnoxious aspects to the
previous summary of the allelic model. Here is a revised and a bit shorter
version. Further comments, edits very welcome. D
The allelic model of genetic variation
In the textbook genetic model, genetic information in a diploid population
is approximated as follows: (1) each individual has a set of chromosomes
that may be numbered 1, …, n,  (2) each individual carries two copies of
each of these n chromosomes, the sex chromosomes and mitochondria being
considered a special case, and (3) each chromosome copy consists of a
defined linear (or circular) sequence of sites, where each site carries one
of a finite set of possible alleles. We refer to this model as the
genotypic model.  In its most fine-grained form, each site consists of a
single basepair of DNA. While this model has enormous conceptual and
practical advantages, even prior to genome sequencing, geneticists realized
that it is not always sufficient, and proposed various generalizations. The
allelic model is such a generalization.
Genetic information is carried in a genome consisting of molecules of
double-stranded DNA. Inadequacies in the genotypic model arise because in a
real genome, pieces of DNA that represent alleles of particular sites
occasionally appear in different numbers, different locations, and
different orientations, and this can matter. While sufficient for many
purposes, the genotypic model doesn't handle these cases. As it becomes
more commonplace to read genomes with increasing fidelity, the inadequacies
of the genotypic model become more apparent.
The allelic model of genetic variation is an abstraction that sits at a
level below the genotypic model, but above the trivial model that merely
represents a genome as a set of molecules of double-stranded DNA. Instead
of the linear coordinate system that is used in the genotypic model to
demarcate multi-allelic sites along the chromosomes, in the allelic model
the genome variation present in the population is described by a network-
or graph-like structure, representing segments of DNA that appear in
typical genomes in the population, along with their common alternatives and
common variations in number, order and orientation [diagram].  We refer to
this graph as a (genome) reference structure. A chromosome is a path
through this reference structure, and a genome is a set of chromosomes.
Instead of sites, the elementary units of a reference structure are
positions. Each position consists of an orientation and a single base of
DNA. The orientation tells us whether that base is on the top or bottom
strand, and thus indicates on which side of it we expect to find the next
base when moving in the standard 5’ to 3’ direction. When a component of
the reference structure is linear, with no branching or “bubble”
alternatives, one can think of it in conventional terms as a series of
1-base sites defining the coordinate system plus the typical base content
of a reference chromosome, e.g. as in the “primary path” of the current
human genome reference of the International Nucleotide Sequence Database
Consortium, version GRCh38. Non-linear aspects of the reference structure,
e.g. “bubbles” that come off of the primary path, can be thought of as
alternate haplotypes, like the alternate haplotypes that are defined as an
adjunct to the primary paths of GRCh38. One difference, however, is that a
general reference structure allows cycles, so the path that defines a
particular individual’s chromosome may repeat a part of the reference
structure an arbitrary number of times.
In the allelic model, an allele is defined as a sequence of positions that
form a (sub)path in the graph structure, i.e. such that each position is
allowed by the edges of the graph structure to follow the previous
position. One can think of an allele roughly as the sequence of DNA spelled
out by a particular sequence of positions, but it is more than that. The
same sequence of DNA may be spelled out other places in the graph as well.
When we say that a genome has a particular allele, we are asserting that
the path for one of the DNA molecules of that genome passes through this
sequence of positions, contiguously, at some point along its extent, either
in one direction (strand) or the other.  This means that the individual’s
genome contains whatever biological feature, such as a particular form of
an exon, gene, etc., that is represented by this sequence of positions in
the reference structure. If we say the allele appears twice in the
individual’s genome then this asserts that the set of paths representing
that individual’s chromosomes, considered in aggregate, pass through this
particular sequence of positions twice. It is not asserted that these
allele traversals occur in two separate DNA molecules, or in any particular
orientations. Two alleles, be they the same or different, are not assumed
to be either phased or unphased by default. Phasing information must be
explicitly specified in addition to allelic information.
The allelic model is a generalization because it does not include the
classical genetics concepts of “site” or “genotype at a site”. These
concepts must be added on top of the allelic model in order to derive the
genotypic model.  In the allelic model, each position, and hence each
allele, has just one DNA sequence associated with it.   One might define an
“allelotype” as a set of alleles that are asserted to be present in an
individual’s genome, each with a specified copy number. Zero is an allowed
copy number. An allelotype asserts that the double-stranded DNA molecules
of the individual’s genome follow a set of paths that traverse the
sequences of positions defined by its alleles the required number of times.
These traversals may occur in any combination of order, orientation and
phasing. Other DNA may also be included in the individual’s genome that is
not listed in the allelotype. This contrasts with a “genotype” in which it
asserted that the individual’s double-stranded DNA molecules include a
specific set of (classical) allelic variants in the default order and
orientation, with only the phasing (and possible additional DNA) left
unspecified. Thus, the classical genotypic model can be built on top of the
allelic model as a special case, by using additional assumptions and
assertions.
Being more general, the allelic model is a broader foundation for genetics.
Using something like it often becomes a requirement when one attempts to
analyze and reason about whole genomes. We hope that the new data schemas
and application programming interfaces we are defining for the allelic
model will support the further development of this model for both research
and clinical use.
On Wed, Feb 11, 2015 at 1:58 PM, David Haussler<EMAIL_ADDRESS>wrote:

Going back to last night's comments by Heng, I've tried to craft a simple
beginner's introduction to what we are doing for the benefit of those
outside our group. It is pasted below and attached in Word. Heng, Richard,
Adam others, please replace or edit as needed, pointing to diagrams and
examples (I agree with Adam these are essential). I think we need something
that gives a high-level intro and is pointed to from the schemas. -D
The allelic model of genetic variation
The field of genetics was born before we could read genomes, yet through
exceedingly clever experiments and careful observations, the pioneers of
genetics were able to form a very accurate model of the basic structure of
genetic information. We refer to this model as the genotypic model.  In
the genotypic model, (1) each individual in a diploid population has a set
of chromosomes that may be numbered 1, …, n,  (2) each individual
carries two copies of each of these n chromosomes, the sex chromosomes
and mitochondria being considered a special case, and (3) each chromosome
copy consists of a defined linear (or circular) sequence of sites, where
each site carries one of a finite set of possible alleles. In its most
fine-grained form, each site consists of a single basepair of DNA. While
this model has enormous conceptual and practical advantages, it is an
abstraction that is not completely accurate, and this has been a problem
for the field.
The more accurate model is simple: each individual has a genome, where a
genome is simply a set of molecules of double-stranded DNA. In a real
genome, pieces of DNA that represent alleles of particular sites in the
genotypic model occasionally appear in different numbers, different
locations, and different orientations, and this matters. Also, completely
novel DNA is observed. As we learn to read genomes with increasing
fidelity, the inadequacies of the genotypic model become more apparent.  We might contemplate simply replacing the
genotypic model with the direct observation of a complete genome. However,
it will never be practical to base all genetic analysis directly on the
reading of an entire genome. For one thing, a genome is too big and
complicated to be treated as a unit. Moreover, despite its shortcomings,
the genotypic model remains a very powerful and useful abstraction.
The allelic model of genetic variation is an abstraction that sits at a
level below the genotypic model, but above the model that merely represents
a genome as a set of molecules of double-stranded DNA. Instead of a single
linear coordinate system that is used to demarcate multi-allelic sites
along the chromosomes, in the allelic model the genome variation present in
the population is described by a network- or graph-like structure,
representing segments of DNA that appear in typical genomes in the
population, along with their common alternatives and common variations in
number, order and orientation [diagram].  We refer to this graph as a
(genome) reference structure. A chromosome is a path through this reference
structure, and a genome is a set of chromosomes.
Instead of sites, the elementary units of a reference structure are
positions. Each position consists of an orientation and a single base of
DNA. The orientation tells us whether that base is on the top or bottom
strand, and thus indicates on which side of it we expect to find the next
base when moving in the standard 5’ to 3’ direction. When a component of
the reference structure is linear, with no branching or “bubble”
alternatives, one can think of it in conventional terms as a series of
1-base sites defining the coordinate system plus the typical base content
of a reference chromosome, e.g. as in the “primary path” of the current
human genome reference of the International Nucleotide Sequence Database
Consortium, version GRCh38. Non-linear aspects of the reference structure,
e.g. “bubbles” that come off of the primary path, can be thought of as
alternate haplotypes, like the alternate haplotypes that are defined as an
adjunct to the primary paths of GRCh38. One difference, however, is that a
general reference structure allows cycles, so the path that defines a
particular individual’s chromosome may repeat a part of the reference
structure an arbitrary number of times.
In the allelic model, an allele is defined as a sequence of positions that
form a (sub)path in the graph structure, i.e. such that each position is
allowed by the edges of the graph structure to follow the previous
position. One can think of an allele roughly as the sequence of DNA spelled
out by a particular sequence of positions, but it is more than that. The
same sequence of DNA may be spelled out other places in the graph as well.
When we say that a genome has a particular allele, we are asserting that
the path for one of the DNA molecules in that genome passes through this
sequence of positions, contiguously, at some point along its extent, either
in one direction (strand) or the other.  This means that the individual’s
genome contains whatever biological feature, such as a particular form of
an exon, gene, etc., that is represented by this sequence of positions in
the reference structure. If we say the allele appears twice in the
individual’s genome then this asserts that the set of paths representing
that individual’s chromosomes, considered in aggregate, pass through this
particular sequence of positions twice. It is not asserted that these
allele traversals occur in two separate DNA molecules, or in any particular
orientations. Two alleles, be they the same or different, are not assumed
to be either phased or unphased by default. Phasing information must be
explicitly specified in addition to allelic information.
The allelic model does not have the classical genetics concepts of “site”
or “genotype at a site”. These concepts must be added on top of the allelic
model if needed.  In the allelic model, each position, and hence each
allele, has just one DNA sequence associated with it.   One might define
an “allelotype” as a set of alleles that are asserted to be present in an
individual’s genome, each with a specified copy number, zero being an
allowed copy number. This asserts that the double-stranded DNA molecules of
the individual’s genome follow a set of paths that traverse the sequences
of positions defined by these alleles the required number of times. These
traversals may occur in any combination of order, orientation and phasing.
Other DNA may also be included in the individual’s genome that is not
listed in the allelotype. This contrasts with a “genotype” in which it
asserted that the individual’s double-stranded DNA molecules include a
specific set of (classical) allelic variants in the default order and
orientation, with only the phasing (and possible additional DNA) left
unspecified. In this sense we claim that the classical genotypic model can
be built on top of the allelic model as a special case, by using additional
assumptions or assertions.
The allelic model is a richer foundation for genetics. Using something
like it becomes a requirement when one attempts to analyze and reason about
whole genomes. We hope that the new data schemas and application
programming interfaces we are defining for the allelic model will support
the further development of this model for both research and clinical use.
On Wed, Feb 11, 2015 at 11:34 AM, adamnovak<EMAIL_ADDRESS>wrote:

OK, by popular demand I have split Call into Call and AlleleCall, and
added a searchAlleleCalls() method.
This is simpler in that Calls will always have genotypes, and AlleleCalls
will always have Allele copy number assertions (possibly associated with
Variants). This lets the objects be simpler and removes a bunch of
constraints about what needs to be set in what mode.
It's more complicated in that if you want all the information for a
CallSet you need to use both searchCalls() to download any genotypes and
searchAlleleCalls() to download Allele copy number assertions. I've
added the constraint that the two views need to be consistent. I've also
required that you serve Calls for every Variant you have AlleleCalls for
if you support "classic" mode, and visa versa if you support "graph" mode,
so you should be able to just query the kind of call that you want and get
a more or less complete view of the CallSet.
—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/schemas/pull/238#issuecomment-73948312.

+1, @adamnovak your presentation from today was fantastic

Can you squash the commits down please @adamnovak? Looks like we're ready to merge.

OK I have squashed everything down. I'm going to tag this as ready to merge.

I'm merging this.

This PR has been merged @ryan-williams, so the discussion thread has ended. Please open a PR if you'd like to make some updates, or open some issues corresponding to the individual comments.


[TS migration] Migrate 'SettingsProfileReport' page to TypeScript

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/25215
PROPOSAL: N/A
Tests

Open room chat
Go to room settings page
Navigate /notification-preferences, /room-name and /who-can-post screens
Verify that all screens works without errors

[x] Verify that no errors appear in the JS console

Offline tests

Same as in the Tests section.
QA Steps

Same as in the Tests section.

[x ] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
https://github.com/Expensify/App/assets/46921547/6aa84a67-33fd-4191-9f93-8a55f72b6675

Android: mWeb Chrome
https://github.com/Expensify/App/assets/46921547/7e3562c1-9cfb-4f37-a44e-223f7eba2f4c

iOS: Native
https://github.com/Expensify/App/assets/46921547/fd22193f-223d-433d-b225-9fc6727e9cf8

iOS: mWeb Safari
https://github.com/Expensify/App/assets/46921547/c1d35ec3-b2ed-4cbd-b4f0-17cf992338ba

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/46921547/8f9828d3-396b-4b0e-be73-ef0ee3e57fbc

MacOS: Desktop
https://github.com/Expensify/App/assets/46921547/a70e5e28-2cca-4298-8b15-e16a445ec9b8

@s77rt  What about this

Reviewer Checklist

[X] I have verified the author checklist is complete (all boxes are checked off).
[X] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[X] I verified the steps for local testing are in the Tests section
[X] I verified the steps for Staging and/or Production testing are in the QA steps section
[X] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[X] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[X] I checked that screenshots or videos are included for tests on all platforms
[X] I included screenshots or videos for tests on all platforms
[X] I verified tests pass on all platforms & I tested again on:

[X] Android: Native
[X] Android: mWeb Chrome
[X] iOS: Native
[X] iOS: mWeb Safari
[X] MacOS: Chrome / Safari
[X] MacOS: Desktop

[X] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[X] I verified proper code patterns were followed (see Reviewing the code)

[X] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[X] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[X] I verified that comments were added to code that is not self explanatory
[X] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[X] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[X] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[X] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[X] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[X] I verified the JSDocs style guidelines (in STYLE.md) were followed

[X] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[X] I verified that this PR follows the guidelines as stated in the Review Guidelines
[X] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[X] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[X] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[X] If a new component is created I verified that:

[X] A similar component doesn't exist in the codebase
[X] All props are defined accurately and each prop has a /** comment above it */
[X] The file is named correctly
[X] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[X] The only data being stored in the state is data necessary for rendering and nothing else
[X] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[X] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[X] All JSX used for rendering exists in the render method
[X] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[X] If any new file was added I verified that:

[X] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[X] If a new CSS style is added I verified that:

[X] A similar style doesn't already exist
[X] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[X] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[X] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[X] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[X] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[X] If the PR modifies the form input styles:

[X] I verified that all the inputs inside a form are aligned with each other.
[X] I added Design label so the design team can review the changes.

[X] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[X] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/16493223/397c9e59-5e1a-4ca3-b362-5df2fd5f0bd7

Android: mWeb Chrome

https://github.com/Expensify/App/assets/16493223/d0c4b38d-806a-4ab7-8cfd-8fce8d4cfd89

iOS: Native

https://github.com/Expensify/App/assets/16493223/45524e63-37a4-400e-ae88-fd1eab256637

iOS: mWeb Safari

https://github.com/Expensify/App/assets/16493223/7b94b50a-6568-4712-a5d9-3a6838998cc9

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/16493223/ecb163ff-d64e-48f5-b412-2aff4f14d7a3

MacOS: Desktop

https://github.com/Expensify/App/assets/16493223/dc7007ad-8b04-4d2d-8c22-eb609a7d2d52

cc @nkuoch

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Cherry-picked to staging by https://github.com/thienlnam in version: 1.4.36-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes.

🚀 Cherry-picked to staging by https://github.com/thienlnam in version: 1.4.36-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes.

🚀 Deployed to production by https://github.com/Julesssss in version: 1.4.37-7 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


Patch example

Hi, Is there a patch method example that fits your project's structure?

I am interested in having the method in the project if it's possible


Emit custom machine code

Something like the following:
fn fun() void {
    var local: u64 = undefined;
    @emit(.{
        .init = .{
            .rax = 4,
            .rcx = 5,
        },
        .bytes = .{1, 2, 3, 4},
        .clobbers = .{.rcx, .rdx},
        .post = {
            local = @fetch(.rax);
        },
    });
}

maybe breaking it down into 2/3 separate builtins would be a better idea? i.e. @register which would allow for getting/setting the register's value and the @emit which would let you emit custom code + mark clobbered registers? i feel like implementing a builtin with so many user values might be a bit of a hassle... also the first builtin i proposed would be nice for writing isr routines ;^) you could get all the registers easily without a redundant @emit expression
example usage of @register and @emit with my proposed changes, this example should perform a linux write syscall and retrieve the return value to a local variable:
@register(.rax) = 1;
@register(.rdi) = 0;
@register(.rsi) = @ptr_to_int("Hello world!".&);
@register(.rdx) = 12;
@emit(.{0x0f, 0x05}, .{.rax});
const result = @register(.rax);

Uh, what I don't like about that is that we don't have a way to know that the inputs depend on the register assignments and that the outputs depends on the @emit which means things could start to break with optimizations (the register assignments can be optimized out, reordered to after the asm or whatever).


Xterm.js does not wrap lines automatically

As illustrated below, if the user types a long string, it is wrapped in the same line which overwrites the beginning of the str:

It turns out that xterm.js is wrapping the lines automatically, but for some reason the two-character string  \r is inserted into every 80 characters of the standard output. This is possibly due to some residual settings which fools part of xterm.js thinking the terminal is 80 columns wide.
I added a hacky fix which simply removed all  \r substrings in the standard output.