text:
Does DateRanegPicker receive a classname ?

Hi, Thanks for the great lib.!
I was trying to overwrite some the themes using the provided instructions in the documentation, yet it seem to be missing the part where the component takes the theme itself, so, Here's my code:
theme.js
import ThemedStyleSheet from 'react-with-styles/lib/ThemedStyleSheet';
import aphroditeInterface from 'react-with-styles-interface-aphrodite';
import DefaultTheme from 'react-dates/lib/theme/DefaultTheme';

import { css, withStyles } from 'react-with-styles';

const myTheme = {
  reactDates: {
    ...DefaultTheme.reactDates,
    color: {
      ...DefaultTheme.reactDates.color,
      highlighted: {
        backgroundColor: '#369',
        backgroundColor_active: '#369',
        backgroundColor_hover: '#369',
        color: '#369',
        color_active: '#369',
        color_hover: '#369',
      },
    },
  },
};

ThemedStyleSheet.registerInterface(aphroditeInterface);
ThemedStyleSheet.registerTheme(myTheme);

export { css, withStyles, ThemedStyleSheet };

index.js
import 'react-dates/initialize';
import React from 'react';
import { DateRangePicker} from 'react-dates';
import { css, withStyles } from './theme.js';

class ReactDatesComponent extends React.Component {

  componentWillMount() {
    this.setState({
      startDate: null,
      endDate: null,
      focusedInput: null,
    })
  }

  render() {
    return (
      <DateRangePicker
        {...css(this.props.styles.reactDates)}
        startDate={this.state.startDate} // momentPropTypes.momentObj or null,
        endDate={this.state.endDate} // momentPropTypes.momentObj or null,
        onDatesChange={({ startDate, endDate }) => this.setState({ startDate, endDate })} // PropTypes.func.isRequired,
        focusedInput={this.state.focusedInput} // PropTypes.oneOf([START_DATE, END_DATE]) or null,
        onFocusChange={focusedInput => this.setState({ focusedInput })} // PropTypes.func.isRequired,
      />
    );
  }
}

export default withStyles(({ reactDates }) => ({ reactDates }))(ReactDatesComponent)

I improvised here based on react-with-styles docs, yet I get this error:
warning.js:33 Warning: Failed prop type: withStyles(DateRangePicker): unknown props found: className

so, What do you think is wrong here ?

Sorry my bad, Apparently it was working yet the warning was just that i provided reactDates as is, something like:
export default withStyles(({ reactDates }) => ({
  DateRangePicker: reactDates,
}))(ReactDatesComponent)

should fix it, and then maybe we add more clear styles ( just for testing ) in our theme object like :
      selected: {
        backgroundColor: '#369',
        backgroundColor_active: '#369',
        backgroundColor_hover: '#369',
        borderColor: '#369',
        borderColor_active: '#369',
        borderColor_hover: '#369',
        color: '#369',
        color_active: '#369',
        color_hover: '#369',
      },

again , I am new to this so if anyone'd like to introduce a better practice to this please go on :)
closing this now 👍

HI @yasserhennawi, I know you closed this but just for future clarification, once you render the theme, you don't have to wrap ReactDatesComponent in withStyles (ie you don't need withStyles(({ reactDates }) => ({ reactDates }))(ReactDatesComponent) at all). It should just work! You would only wrap your component if you wanted to apply your own different styles which you can read more about in the react-with-styles repo - https://github.com/airbnb/react-with-styles

authors: majapw yasserhennawi

repo: airbnb/react-dates


text:
Add Receptor fixes

Fixes #704

From the call:

Bidirectional links between antigen and receptor may not be necessary.

From the call: @bcorrie and @bussec are in general ok with this PR, @bussec will make some final clarification in the description of Cell.reactivity_measurement. Will put this up for a final discussion in January, then merge.

From the call:

Need to review, but seems mostly fine, except we don't think we need reactivity_measurements in Cell. There wouldn't be a prohibition on it, but it would not be the preferred schema path.

From the call:

Sorry I missed the call, looks like my calendar entry ended end of 2023. I am still traveling, returning home tomorrow.

Need to review, but seems mostly fine, except we don't think we need reactivity_measurements defined in Cell. There wouldn't be a prohibition on it, but it would not be the preferred schema path.

reactivity_measurements in both Cell and Receptor are arrays of IDs that refer to ReceptorReactivity objects (essentially the RecceptorReactivity.receptor_reactivity_id of the object). So reactivity_measurements are not defined in the Cell object per se.
My understanding of Cell having a receptor_reactivity is that this would capture when a specific experiment measured a reactivity for an epitope for a specific Cell (e.g. in a 10X experiment). See https://github.com/airr-community/airr-standards/issues/704#issuecomment-1641133894
Is that the general understanding? Would this not be the preferred thing to do in such an experiment?

We were thinking the normal usage would be Cell -> Receptor -> ReceptorReactivity. If you wanted to jump over Receptor and put a reactivity_measurements array into Cell you could, in the same way that you can add sample_id to Rearrangement (semantics are clear even though there's no sample_id defined in Rearrangement), but it wouldn't be the model.

Hey gang,
I wanted to toss thoughts from a B cell perspective. The above discussion seems very focused on T cells so I'm trying to figure out if we need another Object to cover Antibody specificity or make a more general.
Random thoughts:

ReceptorReactivity is more of a T cell concept since I think of "reactivity" as a (T) cell's response when it's receptor binds something. For antibodies the concept of reactivity is not on-point since there is no cell.
The above and that BCRs (on B cells) can also interact with antigen (like T cells), begs the question is if we should have the distinction between antibodies and BCRs on B cells? We sequence B cells but often test binding/affinity on antibodies. Maybe that distinction should be encapsulated in the description of how the BCR/antibody specificity was measured?
peptide_aa_string is something that don't have much applicability in B cell world.

-krish

I agree that reactivity doesn’t make sense for Abs. I haven’t kept up with all the discussion on this, but doesn’t ReceptorSpecificity make more sense and cover BCR, TCR, and Ab (even though Abs aren’t receptors)?

I think that name change covers my name issue. The only thing I could see falling outside that is if we had protein sequence from protein sequencing of antibodies, like Georgiou does. In IRAD we've thought about going after that data type because there is a lot of it in the patent Genbank. But, as far as I know, all our tool chains are very focused on nucleotide sequences, so that's an issue.

@krishnaroskin @lgcowell The Receptor object was developed with both AB/BCR and TCR in mind. In general, it can exist independent of a Cell, i.e., you can use it to annotate reactivities of antibodies that were not observed in cells derived from a Subject, e.g., a recombinantly expressed antibody in which somatic hypermutations were added or removed. However, as @javh described, we assume that the typical way how it would be used is in the context of single-cell experiment.

ReceptorReactivity is more of a T cell concept since I think of "reactivity" as a (T) cell's response when it's receptor binds something. For antibodies the concept of reactivity is not on-point since there is no cell.

This is basically a question about the semantics of the term "reactity". For me, reactivity implies that the receptor or antibody can interact with a given target in a way that can be experimentally detected. Using this definition, activiation of the cell that bears a given receptor/antibody is a sufficient, but not a necessary criterion. The reason why we use reactivity instead of specificity is that the later one - similar to its use in statistics - is relative to something else. Polyreactive antibodies for example are exactly that: They bind everything from polystyrol to shoe laces (i.e. they are "reactive") but they are not specific for any of these things.

The above and that BCRs (on B cells) can also interact with antigen (like T cells), begs the question is if we should have the distinction between antibodies and BCRs on B cells? We sequence B cells but often test binding/affinity on antibodies. Maybe that distinction should be encapsulated in the description of how the BCR/antibody specificity was measured?

In general this is the idea behind the Receptor/ReceptorReactivity split: A given receptor shoud always have the same intristic reactity (otherwise there would be no chance of reproducible results), but different assays will measure it by different means. For example, take an experiment where a fluorescently-labeled protein is used as bait to select for target-specific B cells during sorting. The sorted cells are then subjected to single-cell sequencing and the sequence information of the IGH/IGK transcripts is then used to produce a recombinant antibody that can be tested in vitro (e.g. ELISA). In this case a single Receptor record would have one or more ReceptorReactivity record that describe the results obtained using the recombinant antibody and one that describes the binding in the initial fluorescent bait assay. The latter ReactivityRecord could be directly referrenced from a Cell record (@bcorrie's use-case), while the prior ones would not. The reactivity_method and reactivity_readout properties can be used to provide further information on the experimental approach.

peptide_aa_string is something that don't have much applicability in B cell world.

Fully agree, therefore the schema does not require you to provide this property.

We were thinking the normal usage would be Cell -> Receptor -> ReceptorReactivity. If you wanted to jump over Receptor and put a reactivity_measurements array into Cell you could, in the same way that you can add sample_id to Rearrangement (semantics are clear even though there's no sample_id defined in Rearrangement), but it wouldn't be the model.

Is this implying that Cell.receptor_reactivity should be removed from the object schema? If so I think that is a problem. When receptor_reactivity is measured in an experiment, that reactivity is associated with a specific Cell. If we go Cell -> Receptor -> ReceptorReactivity we lose the information that that specific receptor_reactivity is associate with that Cell and that the receptor_reactivity was measured in a specific experiment.
Remember that since Receptor is a "global object" (there is only one Receptor with a specific paired VDJ/CDR3) it is quite likely for a specific Receptor to have more than one measured receptor_reactivity. This is even likely to happen in a single experiment if I am not mistaken, but it would certainly happen across multiple experiments. Multiple Cells will be assigned the same Receptor and have different measured receptor_reactivity. In the above model a single Receptor will have multiple receptor_reactivity measurements, but it won't be possible to tell which receptor_reactivity measurement came from which Cell. This would be even worse if the receptor_reactivity measures came from different experiments. In this case we lose information about which Study a receptor_reactivity measure came from.
Bottom line is I believe we need to be able to capture a link between Cell and a specific receptor_reactivity directly in the model.

Hmm, in thinking about this a bit more, the AIRR Standard is primarily about capturing how an experiment is done, no? So a direct link from the Cell to the ReceptorReactivity that was measured in the experiment is actually the critical path. It is what is actually measured in the experiment.
Mapping Cells to Receptors is a processing step that may or may not be done in an experiment.

Hmm, in thinking about this a bit more, the AIRR Standard is primarily about capturing how an experiment is done, no?

I agree with this sentiment, which makes me wonder how to get the set of receptor reactivities that were done in a single experiment?
{"digression rant": true}
The underlying issue that I feel we continually run into with these discussions is how to represent relations. How do we resolve the tension between an efficient data structure and our semantic model of the biology (with the ADC often as a third wrinkle). This is where JSON schema fails us because it doesn't have an explicit representation for relations (unlike say SQL DDL), instead it is implicit semantics (like ids and arrays) without any syntactic enforcement.
I tend to always advocate for the efficient data structure. That means in 1-to-n relations, I advocate that the "link" always goes on the "n" side where a single field can be used to point to the "1" object. Versus if you put the relation on the "1" side then you need an array holding "n" objects/ids.
Given this, having reactivity_measurements in Receptor is "wrong" (inefficient), even though semantically it sounds just fine: "a receptor has a set of reactivities". Instead ReceptorReactivity should have a receptor_id field that points to its one and only Receptor. With the current model, every time there is a reactivity measurement then the "global Receptor object" needs to updated with a new object added to the array. Who does that? How do we even know when to do that? Sounds messy to me. As an extreme analogy, imagine instead of Rearrangement pointing to its V allele, the V allele in the germline set had an array of rearrangements.
So I understand the current discussion is around Cell. A Cell can have multiple Receptors, so it's an n-to-n relation with ReceptorReactivity. However if you consider a Cell/Receptor combo, then nominally its a 1-to-n relation. Using the "efficiency" logic, the ReceptorReactivity should have a cell_id that points to the Cell. If the ReceptorReactivity does not involve a cell then that field is null. With ReceptorReactivity having both receptor_id and cell_id then I believe you can represent the true n-to-n relation by having multiple ReceptorReactivity objects with various combos of receptor_id and cell_id values.
Finally, coming back to where I started, maybe we should consider adding some formalism, like some JSON-LD attributes, that more explicitly defines the relations in the schema. Not really sure if that helps though, though maybe it helps to document the arity of the relation. Looking at some of the new draft objects, I feel we've introduced a number of "data inefficient" relations.
{"digression rant": false}

Using the "efficiency" logic, the ReceptorReactivity should have a cell_id that points to the Cell. If the ReceptorReactivity does not involve a cell then that field is null. With ReceptorReactivity having both receptor_id and cell_id then I believe you can represent the true n-to-n relation by having multiple ReceptorReactivity objects with various combos of receptor_id and cell_id values.

I don't object to this implementation if we feel that is a better way to go. As long as we maintain the ability to have a link between ReceptorReactivity to both Cell and Receptor if desired I think we are fine. Both can be null if the experiment does not have such links.
The array stems from the original Receptor model where their was an Array of reactivity objects embeded in the Receptor object. This was changed to have a separate ReceptorReactivity object an array of ReceptorReactivity IDs instead and the same was added to Cell.
I am OK to change ReceptorReactivity to have a cell_id and receptor_id to make these links. We can then remove the arrays receptor_reactivity from Cell and Receptor.

With the current model, every time there is a reactivity measurement then the "global Receptor object" needs to updated with a new object added to the array. Who does that? How do we even know when to do that? Sounds messy to me.

This is a really good reason to change our model as @schristley suggests...

I just pushed a set of changes to the schema that should address some of the points raised.
Some explanations on these changes and thoughts on the recent discussion regarding the relations between the objects, with a focus on experimental aspects:
From my point of view, there are two distinct types of reactivity information that we are trying to annotate:

Reactivity of recombinant receptors: In this case the receptor is reconstructed based on the sequences from an scAIRR-seq experiment and recombinantly expressed, e.g., as an soluble antibody or a T cell line expressing it as TCR. In such a setup we look at one defined receptor at a time, so we can simplify the Cell:Receptor:Reactivity relation as N:1:N, i.e., multiple cells can have the same receptor and a given receptor can have multiple reactivity measurements. Following our discussion on the representation of 1:N relations, this means that both Cell and ReceptorReactivity should reference to Receptor (Note: The fact that a cell can have multiple receptors would IMO not change in this decision, as the number of receptors per cell is usually 1 or 2 (and rarely large than 3), while cells per receptor can easily go into the range of hundreds. However, it means that Cell needs to contain an array of receptor IDs (as it does)). Importantly, in such an experiment there is no direct relation between the cell observed in the scAIRR-seq experiment and the reactivity measurement, so there is no reason to have a direct reference between the respective records here. This leads to the situation that the origin of a ReceptorReactivity is lost, which is something that - as @bcorrie critizied - we need to avoid. However, I don't see any obvious entry point below the level of the study, which is why my edits contain the addition of a study_id property to ReceptorReactivity. This also addresses the problem of receptors that are tested within a study, but are not observed in the scAIRR-seq data (e.g., antibodies in which some or all hypermutations are reverted).

Reactivity of individual cells: In this case cells are incubated with a bait (e.g., a protein or carbohydrate for B cells or an MHC:peptide multimere for T cells) that is labeled, e.g., with a fluorescent or DNA barcode tag. The presence of the tag on the cells (measured, e.g., as fluorescence or as barcode counts in the sequencing data to stick with the previous examples) is then interpreted as reactivity that can be attributed to the Ig/TCR expressed by the cell. We therefore had the idea to use ReceptorReactivity to capture this information, which then gave rise to the notion that there should be a direct reference between Cell and ReceptorReactivity as otherwise it would be impossible to attribute a given ReceptorReactivity to a Cell (given the N:1:N relation described above). After careful consideration, I have decided against adding a cell_id property to ReceptorReactivity and I would like us to reconsider the original decision to use ReceptorReactivity for this type of information, as I think that the ways these experiments are usually conducted do not allow for a proper attribution of reactivity information to an individual receptor:

If multiple receptors are expressed, binding cannot be directly attributed to any of them
Binding experiments are primarily used to select high-binding cells, not to measure reactivity. Therefore often the level of receptor surface expression in not measured, but would be necessary for normalization
Combining the previous two points, multiple receptor might be expressed at different levels but it is very challenging with the methods described above to normalize for this
Finally, the exact amount of background binding of the bait by an individual cell is unknown as it is difficult to control for it

Therefore, while not impossible, most experiments will provide data that should not be considered to be receptor reactivity data, but rather cell reactivity data.

The most obvious solution would IMO be to leave Receptor and ReceptorReactivity as it is now, and add a separate CellReactivity object, but I am open to other suggestions.

@bussec as a non-expert, your argument makes sense to me.
Am I correct in stating that:

If we "reused" ReceptorReactivity to represent your case 2 above, we could simply add a cell_id and it would work. But in this case we are "confusing" or "conflating" the two types of reactivity when you are suggesting we probably shouldn't.
If we created a new CellReactivity it would have similar fields to ReceptorReactivity but would not be related at all to the Receptor. It would have a cell_id to link it to the Cell, but would not have a link to a Receptor. We would then remove the array of receptor_reactivity in Cell also.

If I am not mistaken you have not made that change yet, correct?
For the record, we are trying to curate a study that has CellReactivity using MHC:peptide multimers. That is where issue #704 "Receptor object issues when used in real life..." came from. There is no Receptor inference done in this study and the reactivity is to the Cell. So to capture this study accurately from the experimental perspective we would have Cell and CellReactivity but no Receptor and ReceptorReactivity.
If the study actually inferred that Cell C was actually an instance of Receptor R, we would then create a Receptor object and link it to the Cell.
So I think you rationale of adding CellReactivity and having two different types of "Reactivity" make sense to me.

@bcorrie Yes, your two points are correct. I think that a separate CellReactivity record is the cleaner solution, although it will be very similar to the ReceptorReactivity record. In haven't made these changes yet, be we would need to clean up some of the experimental keywords in addition.

Thank you for the detailed description @bussec

Reactivity of recombinant receptors:

A somewhat naive question. This overlaps (same, different?) with the annotation that IEDB is doing?

Reactivity of individual cells: In this case cells ...

Hi @bpeters42 , this is an interesting case that Christian brings up. Is this something that IEDB is currently annotating in some way? While the reactivity is not tied to a one specific receptor, it is limited to a small possible set.
@bussec Are you aware of any publications that have reported this type of data?

See my use case here about how one might annotate a Cell with two paired chain Rearrangements with Receptor information that is linked to IEDB: https://github.com/airr-community/airr-standards/issues/704#issuecomment-1891063546

@bussec Are you aware of any publications that have reported this type of data?

We are working on curating this paper: https://doi.org/10.1038/s41590-022-01184-4 which uses MHC/peptide dextramer tags to determine cells that have specificity to specific MHC/peptide complexes.
We have loaded the Rearrangement and Cell data for this study already (https://gateway.ireceptor.org/samples?query_id=93707) and are working on the Cell/CellReactivity linking currently. We also have similar specificity data for some of our T1D studies that we are working on.
In fact, it is the curation of this study that caused me to create #704 "Receptor object issues when used in real life...".

@bussec I have added a start of CellReactivity. Has a cell_id rather than study_id, and I removed receptor_hash as I don't think it applies??? I also removed receptor_reactivity from Cell.

@bussec Are you aware of any publications that have reported this type of data?

Lots of this going on in the B cell world:
https://pubmed.ncbi.nlm.nih.gov/34848871/
https://pubmed.ncbi.nlm.nih.gov/37935199/
https://pubmed.ncbi.nlm.nih.gov/36708513/
https://pubmed.ncbi.nlm.nih.gov/37440409/
...though many of those don't do more than an SRA deposit, in terms of reporting.

I'm a bit confused here.  If there's reactivity data without any associated AIRR-seq data, then isn't this out of scope for the AIRR schema?
The COVID-19 paper with the oligo tagged MHC:peptide assay is measuring both the TCR and the reactivity of the TCR simultaneously (via the 10x protocol). Wouldn't this be a case for Receptor:ReceptorReactivity?

2. Reactivity of individual cells: In this case cells are incubated with a bait (e.g., a protein or carbohydrate for B cells or an MHC:peptide multimere for T cells) that is labeled, e.g., with a fluorescent or DNA barcode tag. The presence of the tag on the cells (measured, e.g., as fluorescence or as barcode counts in the sequencing data to stick with the previous examples) is then interpreted as reactivity that can be attributed to the Ig/TCR expressed by the cell. We therefore had the idea to use ReceptorReactivity to capture this information,

@bussec @bcorrie isn't this already covered by CellExpression though? In particular, we have "antigen_bait_binding_by_fluorescence_intensity" and "antigen_bait_binding_by_dna_barcode_count" as recommended values for CellExpression.property_type.
I could see how it might make sense to separate this into a new CellReactivity object, since antigens are not "expressed," but (a) we should make the boundaries/use cases clear and (b) the above should be added to CellReactivity.reactivity_method along with corresponding changes to readout.

I'm a bit confused here. If there's reactivity data without any associated AIRR-seq data, then isn't this out of scope for the AIRR schema?
The COVID-19 paper with the oligo tagged MHC:peptide assay is measuring both the TCR and the reactivity of the TCR simultaneously (via the 10x protocol). The purpose of these assays is to determine the reactivity of individual TCRs. Wouldn't this be a case for Receptor -> ReceptorReactivity?

I guess that "measuring both the TCR and the reactivity of the TCR simultaneously" is not quite true since (a) you can have a reactivity measurement for a cell from which a TCR was not captured (and vice versa) and (b) an allelic inclusion (or cell doublet) would result in a single reactivity measurement but >1 possible receptor.

@bussec Are you aware of any publications that have reported this type of data?

We are working on curating this paper: https://doi.org/10.1038/s41590-022-01184-4 which uses MHC/peptide dextramer tags to determine cells that have specificity to specific MHC/peptide complexes.

This study is curated in IEDB.  It has 891 receptors, 44 assays, 18 epitopes and 5 antigens. What is AIRR trying to curate that isn't already in IEDB?

I guess that "measuring both the TCR and the reactivity of the TCR simultaneously" is not quite true since (a) you can have a reactivity measurement for a cell from which a TCR was not captured (and vice versa) and (b) an allelic inclusion (or cell doublet) would result in a single reactivity measurement but >1 possible receptor.

@scharch good point. Hrm. Is the main challenge here that the global Receptor object is too ambitious? Hard to update, will require inferences that aren't simple, etc? In which case, I think the proposed CellReactivity would end up being the default route people take because of convenience.

I suppose that this would mean that if we wanted to be complete in the curation of this study, we would need to create 891 Receptors and link the Cells we have loaded (https://gateway.ireceptor.org/samples/cell?query_id=93707) to each of the related Receptor object, which in turn would have a link to the related IEDB object. I suspect there is an N to 1 relationship between Cell and Receptor and it is likely that all Cells will have a Receptor as we are only curating the epitope specific Cells from the study.

So for this study's reactivity data it seems like the minimal would be:

Create a CellReactivity object for each measured reactivity between a Cell and an epitope target. This is linked back to the Cell through the cell_id field. These are the actual measured experimental results.

In this way:

One can find reactivity data in the ADC that is experimentally measured at the Cell level by looking at CellReactivity
One can find reactivity data in the ADC at the Receptor level with a more complex query. You would need to do something like "give me the set of Cells C that are linked to Receptor R and then give me all the CellReactivity for all the Cells in set C"
One can find reactivity data in the ADC at the Receptor level by looking a ReceptorReactivity.
One can find reactivity data from external sources at the Receptor level through querying IEDB about known reactivity from Receptors in the ADC

This is non-trivial, but at least "semantically" distinct???
In the AKC world, this is all going to be trivial, right 8-)

One can find reactivity data in the ADC at the Receptor level with a more complex query. You would need to do something like "give me the set of Cells C that are linked to Receptor R and then give me all the CellReactivity for all the Cells in set C"

I wonder if CellReactivity should have a receptor_id so that a Cell->Epitope reaction can be associated with both a Cell and a Receptor, which would avoid the above issue... It can be null if no Receptor is created, but if  there is a Cell->Receptor association, should we maintain this in the CellReactivity? Possibly not, as this makes internal consistency challenging.

I have added repertoire_id and data_processing_id to CellReactivity similar to how we have it with CellExpression. I think we need to link the reactivity back to the Repertoire, no?

@scharch good point. Hrm. Is the main challenge here that the global Receptor object is too ambitious? Hard to update, will require inferences that aren't simple, etc? In which case, I think the proposed CellReactivity would end up being the default route people take because of convenience.

It seems to me that the experiments are measuring CellReactivity. Isn't the fact that there is ReceptorReactivity inferred in some sense? If we define a Receptor in this case aren't we inferring that the reactivity is between the Receptor and the epitope.

@bussec Are you aware of any publications that have reported this type of data?

We are working on curating this paper: https://doi.org/10.1038/s41590-022-01184-4 which uses MHC/peptide dextramer tags to determine cells that have specificity to specific MHC/peptide complexes.

This study is curated in IEDB. It has 891 receptors, 44 assays, 18 epitopes and 5 antigens. What is AIRR trying to curate that isn't already in IEDB?

The AIRR-seq, Cell, and GEX data from the study.
This seems like a perfect use case for linking the ADC and IEDB since the study is currently curated in both. Currently the AIRR-seq/Cell/Gex data is in the ADC and the Epitope specificity data is in IEDB. There is currently no way to determine that there is related data in both repositories except through searching for the publication in each platform. In fact I didn't know it was curated in IEDB. Isn't that the crux of the problem 8-)

Yes, though I meant specifically about reactivity. My concern was duplication of curation between the two resources about receptors and reactivity, especially if there isn't coordination, then you get two separate curations, leading to confusion for users. The link that you want between the two resources doesn't happen automatically, so yeah that's the crux of the problem but ADC doing it's own curation that duplicates IEDB doesn't sound like a good idea.

I suppose that this would mean that if we wanted to be complete in the curation of this study, we would need to create 891 Receptors and link the Cells we have loaded (https://gateway.ireceptor.org/samples/cell?query_id=93707) to each of the related Receptor object, which in turn would have a link to the related IEDB object.

Or you can just point the AIRR Study to the IEDB Study and then you know there is information in both. Or have the AIRR Rearrangements point to the IEDB records. Or have AIRR Cells point to IEDB records. Or what you said... There are many options, it all depends upon what your goals are based upon some driving use cases.

In the AKC world, this is all going to be trivial, right 8-)

If not trivial then at least easier and more consistent. Part of my confusion with this whole thread is understanding where the boundaries are. Many things seem to be exactly what the AKC data harmonization effort is doing. If AIRR is trying to create standards for the integration effort and data harmonization that AKC is doing, then it feels a bit like the cart before the horse.

@schristley  said:

Or you can just point the AIRR Study to the IEDB Study and then you know there is information in both. Or have the AIRR Rearrangements point to the IEDB records. Or have AIRR Cells point to IEDB records. Or what you said... There are many options, it all depends upon what your goals are based upon some driving use cases.

We (the iReceptor team) chose the Minervina et al. study because it provides a good scientific use case that tested all of the new AIRR Standard constructs - Subject HLA, Rearrangement, Cell, CellExpression, Receptor, and ReceptorReactivity that were available after the release of AIRR v1.4/iReceptor v4.0. Thus in a way it was chosen to help us both poke holes in the AIRR model as well as to understand the boundaries between the ADC and other resources better.
In order to poke holes in the AIRR model we wanted to curate the study as completely as possible. So we want to curate all of the HLA, Rearrangement, Cell, CellExpression, Receptor, and CellReactivity data that was produced in the study in the appropriate ADC constructs. Although we have done all of the others, we have only recently been trying to curate the Minervina Receptor, ReceptorReactivity, or CellReactivity data - and that is what started this whole discussion 8-)
@schristley also said:

If not trivial then at least easier and more consistent. Part of my confusion with this whole thread is understanding where the boundaries are. Many things seem to be exactly what the AKC data harmonization effort is doing. If AIRR is trying to create standards for the integration effort and data harmonization that AKC is doing, then it feels a bit like the cart before the horse.

For me the AIRR Receptor and Reactivity objects are designed to enable data harmonization and integration, not necessarily perform that integration. That is why Receptor has receptor_refs which point to external sources of information (such as IEDB) that might have information about that object that doesn't exist in the ADC. There is no intent to duplicate data needlessly.
The reason there is overlap in terms of Reactivity data between the ADC and IEDB in this case is that the data from the Minervina study has been reused for both purposes. This is a good thing, and to me these uses are complementary but different. The links between Cell, CellExpression, and CellReactivity are all part of the Minverina immune response study, and are only found in the ADC, so I do believe that the CellReactivity (linked back to the actual Cell) from the study should be captured in the ADC.
This study also provide evidences for specificity of known Receptors in IEDB, so the data has also been curated and captured there.
Our challenge, like usual, is to figure out how to link the two so that the user doesn't get confused... 8-)

Minor tweak in CellReactivity and ReceptorReactivity - shouldn't reactivity_unit be a Unit Ontology (UO) field?

Minor tweak in CellReactivity and ReceptorReactivity - shouldn't reactivity_unit be a Unit Ontology (UO) field?

Answering this myself. I don't think it can because there is a need to have a Reactivity as a true/false - which I can't find in UO. But I am also not sure how to represent the boolean this cell binds to this antigen/epitope/peptide?
Do we really know the fields reactivity_readout and reactivity_method to have these as enums? Should they be strings with a recommended limited vocabulary instead?

From the call:

Keep lean version of Receptor.
Remove ReceptorReactivity.

Done

Receptor.reactivity_measurements to reactivity_ref.

This was already removed. There is now only a Receptor.receptor_ref
It seems to me like receptor_ref is a better name for this field. At least when it points to an IEDB record, it is pointing to a IEDB.Receptor object which likely records many documented reactivity records for that Receptor.

Can we rename CellReactivity to Reactivity.

This seems more appropriately named CellReactivity to me, since it is actually linked to the Cell. I don't think this is particularly critical since there is a cell_id field that makes the implicit link to Cell clear.
But it seems to me that since we have CellExpression as an object it seems like CellReactivity is more consistent.

Note to self: Changes in the docs are still pending, will wait for #628 to  complete.

But it seems to me that since we have CellExpression as an object it seems like CellReactivity is more consistent.

No objection from me.

It seems to me like receptor_ref is a better name for this field. At least when it points to an IEDB record, it is pointing to a IEDB. Receptor object which likely records many documented reactivity records for that Receptor. I think the intent here is we are pointing to external definitions of the Receptor that provide more info like "receptor reactivity".

I don't think that was the goal. I thought we were replacing the functionality of the reactivity object itself. @bussec?

I don't think that was the goal. I thought we were replacing the functionality of the reactivity object itself. @bussec, am I mistaken?

The Receptor object now points to a bunch of external entities that contain information about that Receptor, noted with CURIEs. Those entities (e.g. IEDB_RECEPTOR:10) contain information about receptor reactivity, but they currently are not pointing to different reactivity records, you are correct.
        receptor_ref:
            type: array
            description: Array of receptor identifiers defined for the Receptor object
            title: Receptor cross-references
            items:
                type: string
            example: ["IEDB_RECEPTOR:10"]
            x-airr:
                nullable: true
                adc-query-support: true

I think we could link to individual external reactivity records, but that would be moving more towards replicating information that is in those other repositories. The above IEDB Receptor (https://www.iedb.org/receptor/10) has three assays that show positive results:
https://www.iedb.org/assay/1650226
https://www.iedb.org/assay/1650227
https://www.iedb.org/assay/1755178
So we could have:
        receptor_ref:
            type: array
            description: Array of receptor identifiers defined for the Receptor object
            title: Receptor cross-references
            items:
                type: string
            example: ["IEDB_ASSAY":"1650226","IEDB_ASSAY":"1650227","IEDB_ASSAY:"1755178"]
            x-airr:
                nullable: true
                adc-query-support: true

But as I say, you can get that from IEDB by linking to a single record, and you are now replicating all of the links to specific assay data that is curated in IEDB. Some Receptors would have MANY assays, so that would be painful to manage.
It makes more sense to me to be linking to the external object at the same conceptual level (e.g. Receptor).

It seems to me like receptor_ref is a better name for this field. At least when it points to an IEDB record, it is pointing to a IEDB. Receptor object which likely records many documented reactivity records for that Receptor. I think the intent here is we are pointing to external definitions of the Receptor that provide more info like "receptor reactivity".

I don't think that was the goal. I thought we were replacing the functionality of the reactivity object itself. @bussec, am I mistaken?

The way I interpreted our discussions in the last call was to replace the (AIRR-C-defined) ReceptorReactivity object with links to objects defined and hosted by other repositories. This is different from removing reactivity information completely from the Receptor object. IMO there is value for users to be able to directly assess how much (or how little) information there is about a given receptor, without having to do lookups with other repos.

@bcorrie @javh I had another look at this and did some minor fixes with regard to enums of experimental properties in CellReactivity. Otherwise:

I would be ok with removing the reactivity_ref property from the Receptor object and only retain the links to an "receptor-like" object in an external database. While I would still prefer to have the reactivity information in there, I also think that @bcorrie's concerns with regard to logical structure and update frequency of reactivity information are valid.
In which scenario do we need CellReactivity.repertoire_id and CellReactivity.data_processing_id, given that this information is already present in the Cell object?
If we agree on dropping reactivity information altogether, the Docs need some more work-up to reflect the changes regarding *Reactivity objects.
The original ReceptorReactivity object was designed with a low-throughput experimental setup in mind than what will get from experiments that would use a CellReactivity record (i.e., 10,000-1,000,000 cells stained with the same set of baits). Irrespective of normalization in the backend database of a repo, do we need to split CellReactivity into a "reagent" and a "measurement" object? Or will file compression save us?

As the last point is not directly connected to the original topic of this PR, I would like to suggest that we make the changes for 1-3 and merge and then have a new issue for 4.

I would be ok with removing the reactivity_ref property from the Receptor object and only retain the links to an "receptor-like" object in an external database. While I would still prefer to have the reactivity information in there, I also think that @bcorrie's concerns with regard to logical structure and update frequency of reactivity information are valid.

This is currently the situation, I had not yet added reactivty_ref into the Receptor object, so there is currently only a receptor_ref. So this is "done" unless we decide otherwise.

2. In which scenario do we need CellReactivity.repertoire_id and CellReactivity.data_processing_id, given that this information is already present in the Cell object?

Currently, unless I am mistaken (gasp), all observed objects are connected to their respective Repertoire and the relative _id fields.
Although the use case might not be obvious, making it possible for the data consumer to find all CellReactivity information related to a Repertoire without having to find all Cells and the search CellReactivity for a large number of Cells seems like a good idea to me. It future proofs us from things that we might not think would be common.
In fact, now that I think about it from an ADC perspective, one use case would be I want to download all of the Cells, CellExpression, and CellReactivity data from a specific Sample. I would do this by processing the related repertoire_id fields from that Sample and query the appropriate end point once.

As the last point is not directly connected to the original topic of this PR, I would like to suggest that we make the changes for 1-3 and merge and then have a new issue for 4.

Good idea, since I don't understand 4 8-)

@bussec I think this is back in your court. I am OK with the way it is, I think we should have repertoire_id and data_processing_id in the CellReactivity object.

3. If we agree on dropping reactivity information altogether, the Docs need some more work-up to reflect the changes regarding *Reactivity objects.

Would you prefer to update the Reactivity docs in this PR or update the docs in the general Docs PR (which is yet to be created).

@bcorrie I now updated the docs, we should be good to go.

Nice... @javh I added you as reviewer - @bussec and I are happy with this, any objections to merge?

Minor comment:
The language of cell_reactivity_id wasn't quite consistent with other _id fields which are currently recommended to be globally unique, but not required to be so.  I push a change for that.
More bigger comment (I missed this earlier, sorry):
I'm confused about the directionality of the records here. Cell has no reference to CellExpression or CellReactivity. And there are "back references" to Repertoire, DataProcessing, and Cell inside CellExpression and CellReactivity.
Shouldn't it be the opposite? Shouldn't CellExpression and CellReactivity be members of Cell?

More bigger comment (I missed this earlier, sorry): I'm confused about the directionality of the records here. Cell has no reference to CellExpression or CellReactivity. And there are "back references" to Repertoire, DataProcessing, and Cell inside CellExpression and CellReactivity.
Shouldn't it be the opposite? Shouldn't CellExpression and CellReactivity be members of Cell? I'm missing something here.

@javh see the discussion starting here for more info around this: https://github.com/airr-community/airr-standards/pull/705#issuecomment-1951531948

@bcorrie I read those, but I'm still confused. How do you retrieve the expression and reactivity data for a single cell?

@bcorrie I read those, but I'm still confused. How do you retrieve the expression and reactivity data for a single cell?

ADC wise:
# Get a cell ID from the first Cell in the repository
curl -d '{"size":1}' https://covid19-1.ireceptor.org/airr/v1/cell | grep \"cell_id\"
    "cell_id": "641e1abd42e3dd9c961f2d8b",

# Get all of that Cell's expression data
curl -d '{"filters":{"op":"=","content":{"field":"cell_id","value":"641e1abd42e3dd9c961f2d8b"}}}' https://covid19-1.ireceptor.org/airr/v1/expression

Rearrangements for a different cell:
curl -d '{"filters":{"op":"=","content":{"field":"cell_id","value":"641e1adb4e75a9e20c57407e"}},"fields":["v_call","junction_aa","cell_id"]}' https://covid19-1.ireceptor.org/airr/v1/rearrangement | egrep "junction|v_call|cell_id"
    "cell_id": "641e1adb4e75a9e20c57407e",
    "v_call": "TRAV9-2",
    "junction_aa": "CAPKPGNAGGTSYGKLTF"
    "cell_id": "641e1adb4e75a9e20c57407e",
    "v_call": "TRBV7-9",
    "junction_aa": "CASSFRGTGELFF"

Reactivity would be the same, except there is no Reactivity data in the ADC yet...

This is essentially exactly what the iReceptor Gateway displays on the Cell page:

Minor comment:
The language of cell_reactivity_id wasn't quite consistent with other _id fields which are currently recommended to be globally unique, but not required to be so. I push a change for that.

I note that this is true for CellExpression, Receptor, and Cell as well, I have made similar changes...

Okay, thanks @bcorrie.  Essentially what you have here is searching all expression data for cells instead of the model where you search all cells for expression data. Which, might be the better approach, but seems contradictory with what I thought the intent behind the Cell object was - to be a container for observations about individual cells.
In this model, CellExpression and CellReactivity are akin to Rearrangement in that they are top-level-ish tables/matrices of observations keyed by cell_id.  This makes a lot of sense to me and is consistent with how these observations are stored as files.
But, then the Cell object serves no purpose because the only part of it doing any work is cell_id which is used as a key to link expression, reactivity, and V(D)J sequence (rearrangement) observations.  In which case, we can drop Cell altogether and move the fields in it elsewhere (eg, virtual_pairing -> Receptor, expression_study_method -> CellExpression, etc).
What this looks like to me is two competing logical structures. Cell contains CellExpression vs CellExpression contains Cell (represented by cell_id).  I think we need to either pick one or decide we're going to support two competing representations and design/document them accordingly.
If I were to have an opinion today, I like the model where expression, reactivity, and rearrangement are the primary observation objects. But, I dunno. It's a big change.
Does this make any sense?

@javh I agree with you on the general points, although I would rather lean towards having Cell as a container. I will try to have a look at the discussions we had on this topic before (i.e. at the point where we decided to implement it in the current fashion) before the next call.
However, I would like to note that this is becoming a discussion about revisiting the overall structure of the Cell object, while the original question of this PR - the structure of Receptor and related objects - has IMO been solved. While I agree that Receptor will likely be affected again by the forthcoming changes we are now starting to discuss, I would like to opt for merging this PR and create a new issues around the structure of Cell.

In this model, CellExpression and CellReactivity are akin to Rearrangement in that they are top-level-ish tables/matrices of observations keyed by cell_id. This makes a lot of sense to me and is consistent with how these observations are stored as files.
But, then the Cell object serves no purpose because the only part of it doing any work is cell_id which is used as a key to link expression, reactivity, and V(D)J sequence (rearrangement) observations. In which case, we can drop Cell altogether and move the fields in it elsewhere (eg, virtual_pairing -> Receptor, expression_study_method -> CellExpression, etc).

That isn't how I think of it... I agree Rearrangement, CellExpression, and CellReactivity are the base level observations. But I think Cell is also observed, no? And it is an important concept that I think we want to track as an entity. I would think of the aggregation aspect of it more along the lines of Clone. Yes, I suppose we could live without it, but it certainly seems important as a class of object to me.
Currently the Cell object doesn't have a significant number of attributes currently, but if we don't have Cell we have no way of capturing either observed or computed attributes of that object. I would imagine that the Rearrangement, CellExpression, and CellReactivity are not the only things that are important about a Cell? I think providing a solution to things like #317 and #477 need a Cell object, no?

What this looks like to me is two competing logical structures. Cell contains CellExpression vs CellExpression contains Cell (represented by cell_id).

I don't see these as two logical structures at all... Cell and CellExpression are two fundamental objects, and there is a relationship between them. The relationship is captured through cell_id and it is 1:N from Cell to CellExpression.
We can choose to store that relationship by having links to N CellExpression objects in every Cell or a single link to a Cell in every CellExpression object. We are choosing to store the relationship in CellExpression. I should note that this is the way we normally choose to store 1:N relationships when the N is large.

source: gharchive/pull-request

authors: bcorrie bussec javh krishnaroskin scharch schristley

repo: airr-community/airr-standards

license_type: permissive

license_source: github-api


text:
ci: saving invidual log files

Kafka logs no longer printed to stdout
ci: The log files from pytest and kafka are saved in artifacts for inspection
fixed a bug in rapu, 500 internal errors did not set the response content type
removed duplicated code from the Makefile (relying exclusively on pre-commit)
conftest automatically downloading Kafka to the runtime directory
ground work to run test suite with different kafka versions

I had this PR split into multiple ones:
https://github.com/aiven/karapace/pull/357
https://github.com/aiven/karapace/pull/359
https://github.com/aiven/karapace/pull/360
https://github.com/aiven/karapace/pull/356
https://github.com/aiven/karapace/pull/358
Just for the sake of clarify, since some of the comments I have added here are no longer relevant. I'm closing this and reopening to get a clean slate.

repo: aiven/karapace


text:
Cant compile through Maven

I'm having trouble compiling the project through maven using: mvn clean package war:war jetty:run
I have also tried using war:exploded and get the same result
Here is what im getting:
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.650 s
[INFO] Finished at: 2018-07-21T20:04:38+00:00
[INFO] Final Memory: 6M/15M
[INFO] ------------------------------------------------------------------------
[ERROR] Could not find goal 'runmvn' in plugin org.eclipse.jetty:jetty-maven-plugin:9.3.0.v20150612 among available goals run-forked, run-war, start, effective-web-xml, run, stop, run-exploded, deploy-war, help -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoNotFoundException
root@ubuntu-s-1vcpu-1gb-sfo2-01:~/PretendYoureXyzzy# mvn clean package war:war jetty:run
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building pyx 0.7.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[WARNING] The POM for com.fasterxml.jackson.core:jackson-core:jar:2.9.2-SNAPSHOT is missing, no dependency information available
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ pyx ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-files-exist) @ pyx ---
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireFilesExist failed with message:
Some required files are missing:
/root/PretendYoureXyzzy/build.properties
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.748 s
[INFO] Finished at: 2018-07-21T20:04:57+00:00
[INFO] Final Memory: 11M/26M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:1.3.1:enforce (enforce-files-exist) on project pyx: Some Enforcer rules have failed. Look above for specific messages explaining why the rule failed. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

You need to append -Dmaven.buildNumber.doCheck=false -Dmaven.buildNumber.doUpdate=false like so mvn clean package war:exploded jetty:run -Dmaven.buildNumber.doCheck=false -Dmaven.buildNumber.doUpdate=false.

that fixed it

source: gharchive/issue

authors: RecursionError devgianlu

repo: ajanata/PretendYoureXyzzy


text:
Uncaught TypeError: Arguments to CompositeDisposable.add must have a .dispose() method

Showing up in Atom 1.11.1 with source-preview 0.5.0
TypeError: Arguments to CompositeDisposable.add must have a .dispose() method     at assertDisposable (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/event-kit/lib/composite-disposable.js:70:13)     at CompositeDisposable.module.exports.CompositeDisposable.add (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/event-kit/lib/composite-disposable.js:43:11)     at new CompositeDisposable (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/event-kit/lib/composite-disposable.js:19:14)     at /Applications/Atom.app/Contents/Resources/app.asar/src/workspace.js:265:29     at Function.module.exports.Emitter.simpleDispatch (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/event-kit/lib/emitter.js:25:14)     at Emitter.module.exports.Emitter.emit (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/event-kit/lib/emitter.js:129:28)     at PaneContainer.module.exports.PaneContainer.addedPaneItem (/Applications/Atom.app/Contents/Resources/app.asar/src/pane-container.js:388:27)     at /Applications/Atom.app/Contents/Resources/app.asar/src/pane-container.js:366:19     at /Applications/Atom.app/Contents/Resources/app.asar/src/pane-container.js:97:16     at Function.module.exports.Emitter.simpleDispatch (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/event-kit/lib/emitter.js:25:14)     at Emitter.module.exports.Emitter.emit (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/event-kit/lib/emitter.js:129:28)     at PaneContainer.module.exports.PaneContainer.didAddPane (/Applications/Atom.app/Contents/Resources/app.asar/src/pane-container.js:306:27)     at Pane.module.exports.Pane.setContainer (/Applications/Atom.app/Contents/Resources/app.asar/src/pane.js:131:26)     at PaneAxis.module.exports.PaneAxis.addChild (/Applications/Atom.app/Contents/Resources/app.asar/src/pane-axis.js:144:13)     at PaneAxis.module.exports.PaneAxis.insertChildAfter (/Applications/Atom.app/Contents/Resources/app.asar/src/pane-axis.js:216:19)     at Pane.module.exports.Pane.split (/Applications/Atom.app/Contents/Resources/app.asar/src/pane.js:923:23)     at Pane.module.exports.Pane.splitRight (/Applications/Atom.app/Contents/Resources/app.asar/src/pane.js:884:19)     at PreviewView.module.exports.PreviewView.show (/Users/anshu/.atom/packages/source-preview/lib/preview-view.coffee:111:23)     at Object.module.exports.toggle (/Users/anshu/.atom/packages/source-preview/lib/main.coffee:33:13)     at atom-text-editor.subscriptions.add.atom.commands.add.source-preview:toggle (/Users/anshu/.atom/packages/source-preview/lib/main.coffee:13:47)     at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (/Applications/Atom.app/Contents/Resources/app.asar/src/command-registry.js:260:29)     at /Applications/Atom.app/Contents/Resources/app.asar/src/command-registry.js:3:61     at KeymapManager.module.exports.KeymapManager.dispatchCommandEvent (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/atom-keymap/lib/keymap-manager.js:580:16)     at KeymapManager.module.exports.KeymapManager.handleKeyboardEvent (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/atom-keymap/lib/keymap-manager.js:388:22)     at WindowEventHandler.module.exports.WindowEventHandler.handleDocumentKeyEvent (/Applications/Atom.app/Contents/Resources/app.asar/src/window-event-handler.js:114:36)     at HTMLDocument.<anonymous> (/Applications/Atom.app/Contents/Resources/app.asar/src/window-event-handler.js:3:61)

Same issue.
[Enter steps to reproduce below:]

Create a Node project with the following package.json:

{
  "name": "js-lesson-build-tools",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "build:watch": "webpack --watch",
    "build": "webpack",
    "start": "node ./dist/main.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "babel-core": "^6.17.0",
    "babel-eslint": "^7.0.0",
    "babel-loader": "^6.2.5",
    "babel-polyfill": "^6.16.0",
    "babel-preset-latest": "^6.16.0",
    "babel-preset-stage-0": "^6.16.0",
    "standard": "^8.4.0",
    "webpack": "^1.13.2"
  },
  "babel": {
    "presets": ["latest", "stage-0"]
  },
  "standard": {
    "parser": "babel-eslint"
  }
}

Create a .js file with arbitrary es6 code (language support provided by the language-babel package
Use the command palette to trigger Source Preview: Toggle command
Receive error 🎉

Atom Version: 1.11.1
Electron Version: 0.37.8
System: Microsoft Windows 10 Pro Insider Preview
Thrown From: source-preview package, v0.5.0
Stack Trace
Uncaught TypeError: Arguments to CompositeDisposable.add must have a .dispose() method
At C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\node_modules\event-kit\lib\composite-disposable.js:70

TypeError: Arguments to CompositeDisposable.add must have a .dispose() method
    at assertDisposable (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\node_modules\event-kit\lib\composite-disposable.js:70:13)
    at CompositeDisposable.module.exports.CompositeDisposable.add (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\node_modules\event-kit\lib\composite-disposable.js:43:11)
    at new CompositeDisposable (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\node_modules\event-kit\lib\composite-disposable.js:19:14)
    at C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\src\workspace.js:265:29
    at Function.module.exports.Emitter.simpleDispatch (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\node_modules\event-kit\lib\emitter.js:25:14)
    at Emitter.module.exports.Emitter.emit (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\node_modules\event-kit\lib\emitter.js:129:28)
    at PaneContainer.module.exports.PaneContainer.addedPaneItem (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\src\pane-container.js:388:27)
    at C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\src\pane-container.js:366:19
    at C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\src\pane-container.js:97:16
    at Function.module.exports.Emitter.simpleDispatch (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\node_modules\event-kit\lib\emitter.js:25:14)
    at Emitter.module.exports.Emitter.emit (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\node_modules\event-kit\lib\emitter.js:129:28)
    at PaneContainer.module.exports.PaneContainer.didAddPane (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\src\pane-container.js:306:27)
    at Pane.module.exports.Pane.setContainer (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\src\pane.js:131:26)
    at PaneAxis.module.exports.PaneAxis.addChild (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\src\pane-axis.js:144:13)
    at PaneAxis.module.exports.PaneAxis.insertChildAfter (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\src\pane-axis.js:216:19)
    at Pane.module.exports.Pane.split (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\src\pane.js:923:23)
    at Pane.module.exports.Pane.splitRight (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\src\pane.js:884:19)
    at PreviewView.module.exports.PreviewView.show (file:///C:/Users/peter/.atom/packages/source-preview/lib/preview-view.coffee:111:23)
    at Object.module.exports.toggle (file:///C:/Users/peter/.atom/packages/source-preview/lib/main.coffee:33:13)
    at atom-text-editor.subscriptions.add.atom.commands.add.source-preview:toggle (file:///C:/Users/peter/.atom/packages/source-preview/lib/main.coffee:13:47)
    at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\src\command-registry.js:260:29)
    at C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\src\command-registry.js:3:61
    at CommandPaletteView.module.exports.CommandPaletteView.confirmed (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\node_modules\command-palette\lib\command-palette-view.js:183:32)
    at CommandPaletteView.module.exports.SelectListView.confirmSelection (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\node_modules\atom-space-pen-views\lib\select-list-view.js:338:21)
    at space-pen-div.atom.commands.add.core:confirm (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\node_modules\atom-space-pen-views\lib\select-list-view.js:109:19)
    at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\src\command-registry.js:260:29)
    at C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\src\command-registry.js:3:61
    at KeymapManager.module.exports.KeymapManager.dispatchCommandEvent (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\node_modules\atom-keymap\lib\keymap-manager.js:580:16)
    at KeymapManager.module.exports.KeymapManager.handleKeyboardEvent (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\node_modules\atom-keymap\lib\keymap-manager.js:388:22)
    at WindowEventHandler.module.exports.WindowEventHandler.handleDocumentKeyEvent (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\src\window-event-handler.js:114:36)
    at HTMLDocument.<anonymous> (C:\Users\peter\AppData\Local\atom\app-1.11.1\resources\app.asar\src\window-event-handler.js:3:61)

Commands
     -0:47.4.0 core:undo (atom-text-editor.editor.is-focused)
     -0:45.3.0 core:move-down (atom-text-editor.editor.is-focused.autocomplete-active)
     -0:45 autocomplete-plus:confirm (atom-text-editor.editor.is-focused.autocomplete-active)
     -0:44.4.0 autocomplete-plus:activate (atom-text-editor.editor.is-focused)
     -0:43.8.0 snippets:next-tab-stop (atom-text-editor.editor.is-focused)
     -0:43.8.0 snippets:expand (atom-text-editor.editor.is-focused)
     -0:43.8.0 editor:indent (atom-text-editor.editor.is-focused)
 15x -0:43 editor:select-to-beginning-of-word (atom-text-editor.editor.is-focused)
  2x -0:40.5.0 core:backspace (atom-text-editor.editor.is-focused)
 11x -0:34.1.0 blur (atom-text-editor.editor.is-focused)
     -0:04.4.0 core:save (atom-text-editor.editor.is-focused)
     -0:03.1.0 command-palette:toggle (atom-text-editor.editor.is-focused)
     -0:02.9.0 blur (atom-text-editor.editor.is-focused)
     -0:01.8.0 core:confirm (atom-text-editor.editor.mini.is-focused)
     -0:01.8.0 blur (atom-text-editor.editor.mini.is-focused)
     -0:01.8.0 source-preview:toggle (atom-text-editor.editor)

Config
{
  "core": {
    "autoHideMenuBar": true,
    "disabledPackages": [
      "linter-js-standard-engine",
      "source-preview-babel"
    ],
    "telemetryConsent": "limited",
    "themes": [
      "atom-material-ui",
      "atom-material-syntax-light"
    ]
  }
}

Installed Packages
# User
adventurous-syntax, v0.2.0 (inactive)
aesthetic-ui, v2.0.0 (inactive)
atom-material-syntax, v0.4.6 (inactive)
atom-material-syntax-light, v0.4.5 (active)
atom-material-ui, v1.3.6 (active)
batman-syntax, v1.0.1 (inactive)
docker, v0.7.0 (inactive)
elm-format, v2.1.0 (active)
emmet, v2.4.3 (active)
file-icons, v1.7.22 (active)
firewatch-syntax, v1.0.1 (inactive)
flat-light-syntax, v0.7.0 (inactive)
fonts, v1.6.0 (active)
git-hide, v0.1.2 (active)
git-time-machine, v1.5.3 (inactive)
github-atom-light-syntax, v0.2.0 (inactive)
gitignore-snippets, v0.2.5 (inactive)
goto, v1.7.1 (inactive)
gruvbox-plus-syntax, v1.2.5 (inactive)
language-babel, v2.44.1 (active)
language-batch, v0.3.3 (active)
language-docker, v1.1.7 (active)
language-elm, v1.5.0 (active)
language-gitignore, v0.3.0 (active)
linter, v1.11.18 (active)
linter-docker, v0.1.2 (active)
linter-elm-make, v0.17.7 (active)
linter-js-standard, v3.4.1 (active)
linter-js-standard-engine, v0.0.6 (inactive)
merge-conflicts, v1.4.4 (active)
minimap, v4.25.0 (active)
minimap-bookmarks, v0.4.2 (active)
minimap-find-and-replace, v4.5.1 (active)
minimap-git-diff, v4.3.1 (active)
minimap-linter, v1.6.0 (active)
minimap-pigments, v0.2.1 (active)
minimap-selection, v4.4.0 (active)
monokai-soda, v0.5.0 (inactive)
pigments, v0.37.0 (active)
redmond-syntax, v1.0.2 (inactive)
script, v3.10.1 (inactive)
source-preview, v0.5.0 (active)
source-preview-babel, v0.2.1 (inactive)
standardjs-snippets, v2.4.0 (active)
tomorrow-night-eighties-syntax, v0.17.0 (inactive)
atom-dark-syntax, v0.27.0 (inactive)
atom-dark-ui, v0.52.0 (inactive)
atom-light-syntax, v0.28.0 (inactive)
atom-light-ui, v0.44.0 (inactive)
base16-tomorrow-dark-theme, v1.2.0 (inactive)
base16-tomorrow-light-theme, v1.2.0 (inactive)
one-dark-ui, v1.6.0 (inactive)
one-light-ui, v1.6.0 (inactive)
one-dark-syntax, v1.3.0 (inactive)
one-light-syntax, v1.3.0 (inactive)
solarized-dark-syntax, v1.0.2 (inactive)
solarized-light-syntax, v1.0.2 (inactive)
about, v1.7.0 (active)
archive-view, v0.61.1 (active)
autocomplete-atom-api, v0.10.0 (active)
autocomplete-css, v0.11.2 (active)
autocomplete-html, v0.7.2 (active)
autocomplete-plus, v2.31.1 (active)
autocomplete-snippets, v1.11.0 (active)
autoflow, v0.27.0 (inactive)
autosave, v0.23.1 (active)
background-tips, v0.26.1 (active)
bookmarks, v0.42.0 (active)
bracket-matcher, v0.82.1 (active)
command-palette, v0.38.0 (active)
deprecation-cop, v0.54.1 (active)
dev-live-reload, v0.47.0 (active)
encoding-selector, v0.22.0 (active)
exception-reporting, v0.40.0 (active)
find-and-replace, v0.201.1 (active)
fuzzy-finder, v1.4.0 (active)
git-diff, v1.1.0 (active)
go-to-line, v0.31.0 (inactive)
grammar-selector, v0.48.2 (active)
image-view, v0.59.0 (active)
incompatible-packages, v0.26.1 (active)
keybinding-resolver, v0.35.0 (active)
line-ending-selector, v0.5.0 (active)
link, v0.31.1 (inactive)
markdown-preview, v0.158.0 (active)
metrics, v1.0.0 (active)
notifications, v0.65.1 (active)
open-on-github, v1.2.0 (inactive)
package-generator, v1.0.0 (inactive)
settings-view, v0.242.2 (active)
snippets, v1.0.2 (active)
spell-check, v0.68.2 (active)
status-bar, v1.4.1 (active)
styleguide, v0.47.0 (active)
symbols-view, v0.113.1 (inactive)
tabs, v0.101.0 (active)
timecop, v0.33.2 (active)
tree-view, v0.209.3 (active)
update-package-dependencies, v0.10.0 (active)
welcome, v0.35.1 (active)
whitespace, v0.33.0 (active)
wrap-guide, v0.38.2 (active)
language-c, v0.52.1 (active)
language-clojure, v0.21.0 (active)
language-coffee-script, v0.47.2 (active)
language-csharp, v0.12.1 (active)
language-css, v0.37.1 (active)
language-gfm, v0.88.0 (active)
language-git, v0.15.0 (active)
language-go, v0.42.1 (active)
language-html, v0.45.1 (active)
language-hyperlink, v0.16.0 (active)
language-java, v0.23.0 (active)
language-javascript, v0.119.0 (active)
language-json, v0.18.2 (active)
language-less, v0.29.5 (active)
language-make, v0.22.2 (active)
language-mustache, v0.13.0 (active)
language-objective-c, v0.15.1 (active)
language-perl, v0.35.0 (active)
language-php, v0.37.2 (active)
language-property-list, v0.8.0 (active)
language-python, v0.45.0 (active)
language-ruby, v0.69.0 (active)
language-ruby-on-rails, v0.25.0 (active)
language-sass, v0.56.0 (active)
language-shellscript, v0.22.4 (active)
language-source, v0.9.0 (active)
language-sql, v0.23.0 (active)
language-text, v0.7.1 (active)
language-todo, v0.28.0 (active)
language-toml, v0.18.0 (active)
language-xml, v0.34.9 (active)
language-yaml, v0.26.0 (active)

# Dev
No dev packages

I just ran into this too 😞

Varying the atom release but leaving the packages installed the same, I found that:

Atom 1.10.2 WORKS (behaviour mentioned is not reproduced)
Atom 1.11.0 FAILS (behaviour mentioned is reproduced)
Atom 1.11.1 FAILS
Atom 1.12.0-beta2 WORKS

Fortunately for me I am willing to switch to the Atom-beta channel temporarily as a workaround.   Perhaps whatever fix is applied will make its way eventually to the stable channel?    I don't know the specifics of whatever side-effect was introduced in Atom.  I suggest keeping this bug open until it is resolved in stable.

authors: d4nshields danielbayley eskhool resisttheurge

license: mit

license_source: bigquery


text:
add jquery to dependencies

because new version of slick requires jquery in peerDependencies.
https://github.com/kenwheeler/slick/releases/tag/1.8.0

I'm not really fully up-to-date on how things work here, so please pardon me if I'm talking nonsense. However, if I understand correctly based on #240, the JS part of slick-carousel is not used and thus there is no real need for jquery. I just noticed the warning about missing peer dependency as well, but not sure what would be the best way to resolve this. Having jquery in the deps feels a bit wrong though if it's only for suppressing the warning and it is not being really used by the component.

@harriha sure, it's jQuery not used by react-slick, but until react-slick will depends on slick-carousel every project should add jquery to dependencies or only react-slick to prevent warnings.

moved slick-carousel to peerDependency

authors: DimaRGB akiran harriha

repo: akiran/react-slick

license: MIT


text:
Parameterization

量子アニーリング系の研究で、

多数の構造を出力する
ダメな構造も出力してOK（エネルギー正は困るけど）

という需要ができつつあるので、それをするために2つのconst変数を外から指定できるようにしました。

確認・ご指摘ありがとうございます。ご指摘の点修正しました。
また、変数名をPOSES_PER_LIG に合わせて、NUM_POSES_PER_LIG_BEFORE_OPT ではなく POSES_PER_LIG_BEFORE_OPT としました。

repo: akiyamalab/restretto


text:
[Feature Request] git add -i (patch)

Is there any plan to implement interactive add? with that I can add hunks interactively

Related to / duplicate of #246

The Stage Hunk command provides this. It could use some polishing I think but that is the interactive add command.

authors: Nandiin akonwi superdump

repo: akonwi/git-plus


text:
add new metric for Oban Job, total time inserted

Change description
New metric for the Oban plugin, the total time the job spent in the DB before being attempted.
What problem does this solve?
Issue number: n/a
We wanted to track how long a job took from insertion to attempt.  Normally queued time would tell you this but we snooze jobs and the queue time gets reset when you reinsert the job.
Example usage
Additional details and screenshots
Checklist

[x] I have added unit tests to cover my changes.
[x] I have added documentation to cover my changes.
[x] My changes have passed unit tests and have been tested E2E in an example project.

It is missing the grafana dashboard changes currently.


text:
Valheim Plus

the mod does not start with the server, I am using LGSM

Hmm, yeah might be a limitation of current V+ & LGSM. I switched to AMP early in because if it’s ease of use.
Try this for LGSM and let me know how it goes:

Edit start_server_bepinex.sh and replace the arguments of Valheim executable with $@ so the last line looks like this :
exec ./valheim_server.x86_64 $@

Add executable="./start_server_bepinex.sh" to your your vhserver.cfg

authors: NiceATC akridge


text:
triagle patter finished

This is the triangle pattern in is own brach

Code is there

Hey I already update the fork, and I can't find the any file on the Patterns Folder,
that prints the pattern requested.
The first time that make a pull request for this piece of code,
I forgot to change the branch and I uploaded the the calculator.py again. :crying_cat_face:

repo: akshitagit/Python


text:
Use tab to open drawer

I currently have a basic setup with 4 tabs.
The last tab is "More", which i want to use as a menu.  Clicking the tab should slide a menu in, which is then used to push more pages.
Im just not sure how to lay this out to have it functioning correctly.  Can anyone offer some help?

I did not test it, but I would do is use Actions.refresh somewhat like this:
<Scene key="tab1_1" component={TabView} onRight={()=> Actions.refresh({key:"drawer", open: true})} />
Scene definition is taken from https://github.com/aksonov/react-native-router-flux/blob/master/docs/DETAILED_EXAMPLE.md
Property key in onRight must reflect Scene key of your drawer, it sets open value to true, which should open the drawer if you have drawer properly set. Drawer example is here and I can verify, that it works fine: https://github.com/aksonov/react-native-router-flux/blob/master/docs/OTHER_INFO.md

Thanks mate got it figured.

repo: aksonov/react-native-router-flux


text:
"[App] has stopped" when try to open drawer after uploading to play store, works fine locally

Version
Tell us which versions you are using:

react-native-router-flux "^4.1.0-beta.8",
"react": "16.9.0",
"react-native": "0.61.4",

I have no idea what is going on here, RNRF works fine locally, even with a --variant=release build but after uploading it to the play store and downloading it through the internal testing track I see that the app crashes when I try to open the drawer for my navigation.
I don't know how to debug this since I cannot replicate it without downloading from the app store. Any information about this specific problem or how to start debugging a problem like this where I am effectively blind would be appreciated.
My router with identifying information replaced can be found below. I am able to access the login page, account creation page, and then log in to see the initial page, as well as use the navigation options on that initial page. The problem only appears when I tap the hamburger icon or swipe from the right to see the drawer content.
`

<Scene type="reset" key="login" type={ActionConst.REPLACE} transitionConfig={() => ({ screenInterpolator: StackViewStyleInterpolator.forHorizontal })}>

<Drawer
type="reset"
hideNavBar
key="drawer"
drawer={true}
contentComponent={DrawerContent}
drawerImage={MenuIcon}
drawerWidth={Dimensions.get('window').width}
drawerPosition={'right'}
>
		<Scene key='tabbar' transitionConfig={() => ({ screenInterpolator: StackViewStyleInterpolator.forHorizontal })} >
			<Scene key="replaced" type={ActionConst.REPLACE} component={replaced} title="" titleStyle={styles.centerText} initial />
			<Scene key='replaced' component={replaced} title='replaced' titleStyle={styles.centerText} back={true} backTitle="Back" backButtonImage={newBackIcon} backButtonTextStyle={{ color: colors.white, paddingTop: 3 }} navigationBarTitleImage={{ uri: this.props.icons[constants.ICON_FEELINGS] }} navigationBarTitleImageStyle={styles.navigationBarTitleImageStyle2} />

			<Scene key="replaced" component={replaced} title="" titleStyle={styles.centerText} navigationBarTitleImage={{ uri: this.props.icons[constants.replaced] }} back={true} backTitle="Back" backButtonImage={newBackIcon} backButtonTextStyle={{ color: colors.white, paddingTop: 3 }} navigationBarTitleImageStyle={styles.navigationBarTitleImageStyle2} />

			<Scene key="replaced" component={replaced} title="replaced" titleStyle={styles.centerText} navigationBarTitleImage={{ uri: this.props.icons[constants.replaced] }} back={true} backTitle="Back" backButtonImage={newBackIcon} backButtonTextStyle={{ color: colors.white, paddingTop: 3 }} navigationBarTitleImageStyle={styles.navigationBarTitleImageStyle2} />

			<Scene key="replaced" component={Disclaimer} back={true} backTitle="Back" backButtonImage={newBackIcon} backButtonTextStyle={{ color: colors.white, paddingTop: 3 }} navigationBarTitleImage={{ uri: this.props.icons[constants.replaced] }} navigationBarTitleImageStyle={styles.navigationBarTitleImageStyle2} />

			<Scene key="replaced" component={replaced} title="replaced" titleStyle={styles.centerText} back={true} backTitle="Back" backButtonImage={newBackIcon} backButtonTextStyle={{ color: colors.white, paddingTop: 3 }} navigationBarTitleImage={{ uri: this.props.icons[constants.replaced] }} navigationBarTitleImageStyle={styles.navigationBarTitleImageStyle2} />
			<Scene key="replaced" component={replaced} title="replaced" titleStyle={styles.centerText} back={true} backTitle="Back" backButtonImage={newBackIcon} backButtonTextStyle={{ color: colors.white, paddingTop: 3 }} navigationBarTitleImage={{ uri: this.props.icons[constants.replaced] }} navigationBarTitleImageStyle={styles.navigationBarTitleImageStyle2} />

			<Scene key="replaced" component={replaced} title="replaced" titleStyle={styles.centerText} back={true} backTitle="Back" backButtonImage={newBackIcon} backButtonTextStyle={{ color: colors.white, paddingTop: 3 }} navigationBarTitleImage={{ uri: this.props.icons[constants.replaced] }} navigationBarTitleImageStyle={styles.navigationBarTitleImageStyle2} />
			<Scene key="replaced" component={replaced} title="replaced" titleStyle={styles.centerText} back={true} backTitle="Save" backButtonImage={newBackIcon} backButtonTextStyle={{ color: colors.white, paddingTop: 3 }} navigationBarTitleImage={{ uri: this.props.icons[constants.replaced] }} navigationBarTitleImageStyle={styles.navigationBarTitleImageStyle2} />
			<Scene key="replaced" component={replaced} title={"replaced"} titleStyle={styles.centerText} back={true} backTitle="Back" backButtonImage={newBackIcon} backButtonTextStyle={{ color: colors.white, paddingTop: 3 }} navigationBarTitleImage={{ uri: this.props.icons[constants.replaced] }} navigationBarTitleImageStyle={styles.navigationBarTitleImageStyle2} />
		</Scene>

	</Drawer>
	<Scene key="createAccount" component={CreateAccount} back={true} backTitle="Back" backButtonImage={newBackIcon} backButtonTextStyle={{ color: colors.white, paddingTop: 3 }} />
</Scene>

`

I made a build without proguard and tested that, there was no difference when clicking the hamburger menu icon, it crashed immediately. I think there was a slight difference when pulling the menu from the right, it crashed in a fraction of a second but I could see the menu briefly and it looked like it should.

I was switching to react-navigation since I couldn't find a fix for this, and had to make a build to check something else, and switched back to this since the other navigation was only partially complete. It worked this time. Seems like it was a missing dependency then since I had installed them as part of starting react-navigation. I do not believe the v3 to v4 upgrade guide I was following mentioned that which was responsible for the error. Not sure why it wouldn't fail due to this locally though.


text:
refactor(framework): apply conventional code style

Please read and mark the following check list before creating a pull request:

[x] I read and followed the CONTRIBUTING.md guide.
[x] I read and followed the New Feature Checklist guide.

Short description of what this resolves:

applies conventional code style to ui module components
applies typescript usage to theme module components

@malashkevich ?

Used this pr to integrate components with token-group mappings

repo: akveo/react-native-ui-kitten


text:
空调风速映射不正确

Device model / 设备型号
qdhkl.aircondition.b23
Component version / 插件版本
0.7.7
HA core version / HA版本
2023.4.6
Integrated mode / 集成方式
Automatic (自动模式)
The problem / 问题详情
No response
Entity attributes / 实体属性
空调的风速映射，和米家APP还有控制器实际风速都不一样
低速 = 高速
中速 = 中速
高速 = 低速
Home Assistant Logs / 系统日志
无

![IMG_9308]
fan_level 4对应的应该是low，miot-spec网页上的是对的。但是插件映射出来不对，fan_mode变成high了

该设备有两个版本的规格，插件会优先使用released状态的最新版本。已在最新的提交中为该设备强制使用debug状态的规格，请升级至master分支后重试。

该设备有两个版本的规格，插件会优先使用released状态的最新版本。已在最新的提交中为该设备强制使用debug状态的规格，请升级至master分支后重试。

能否增加一个local_delay_update的参数，这款设备和其他设备不一样，它需要等待空调回应状态，自身的状态才会更新。现在本地模式连接这个设备，打开空调以后，会马上用lan模式获取状态，但是这个时候空调的状态还是关闭的，估计要过2秒左右才会更新状态

authors: HateBaozi al-one

repo: al-one/hass-xiaomi-miot


text:
#30 Fix XHTML Issue - Backend Option changed from html to xhtml5

Changed Backend-Option to XHTML5 (to be compatible with Confluence API). Add @Ignore to tests breaking on my machine.

pull request build failure due to gpg key issues, investigating ...

Builds of pull requests from forks fail due to security restrictions with secret variables (see https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions). Please rebase your pull request branch onto the current master in order to get commit ba4f702c which fixes this issue. Thank you for your patience!

See https://github.com/alainsahli/confluence-publisher/issues/62 for an explanation of the failed build. Once https://github.com/alainsahli/confluence-publisher/issues/62 has been fixed, please rebase your pull request branch onto the master and push the changes. Thank you for your patience!

Issue #62 is now fixed, please rebase your pull request branch onto the master of the confluence publisher repo and push the changes. Thank you!

Coverage increased (+3.5%) to 90.16% when pulling 31321a53f6f03f2a3c2bb69fa83b75f65e27241a on klaus31:bugfix/issue-30 into 442f07b7f392a816fc032bb20d9852b61a8a1315 on alainsahli:master.

Trying to merge your pull request, I realized that your commits are on the pull request twice:

Maybe something went wrong while rebasing your changes onto the master? Anyway, may I kindly ask you to create a new branch from an up-to-date master, apply your commits again and create a new pull request (or update the existing one)? Then I can merge that one cleanly into our master.
Alternatively, if you prefer, I can also cherry-pick your changes onto a feature branch in our repo and merge from there (you will not loose any credits). Thank you!

Hi @klaus31, thanks for your contribution. We are going to release 0.2.0 today so I applied your changes in PR #77.

authors: alainsahli coveralls cstettler klaus31

repo: alainsahli/confluence-publisher


text:
Rewrite previous issues so they are up to date

Summary
@jiraslama and @katoss did lots of work together on design features and user testing/community recommendations which are currently preserved in old issues. These also include feedback from the AutSPACEs community. We should rewrite the issues to reference the current platform and workflow while making sure to credit/keep a record of their work.

I've linked them all up in #369 👍

authors: GeorgiaHCA gedankenstuecke

repo: alan-turing-institute/AutSPACEs


text:
[epic] Collect simulation data

A wide variety of simulations will help to test the package.

[x]  tsunami simulations
[x] cardiovascular simulations
[ ] engineering simulations
[ ] ice sheet simulations
[ ] infrastructure
[ ] other interesting simulations

Few notes on the cardiovascular simulation data after talking to Marina:
Easy datasets (fewer parameters, usually LHS sampled):

atrial_cell_model / ionic
circadapt
passive_mechanics
tiossue_elecrophysiology

Difficult datasets (many parameters, non-linear, non-smooth, non-LHS):

atrial_cell_model (other than ionic)
four chamber datasets (very difficult)

yes, thanks for adding this @kallewesterling and @zackxconti for providing the data!

Also adding this repo for high dimensional datasets.

@mastoffel This is where we're waiting for a dataset from BAS? We might want to add that as an issue here to make sure it's on the roadmap.

@mastoffel This is where we're waiting for a dataset from BAS? We might want to add that as an issue here to make sure it's on the roadmap.

Yes, still waiting for the BAS dataset.

Could you tell me something more about what the "infrastructure" dataset would be above?
As for "other interesting simulations", I think this might be something we can add to #71 as part of how folks can contribute to the package?

Could you tell me something more about what the "infrastructure" dataset would be above?

I'm not sure tbh, this should be something from the DT-TRIC infrastructure side, but I haven't found any good datasets here, but will talk to Keith again at some point.

What would a "good dataset" mean? I will poke around as well!

What would a "good dataset" mean? I will poke around as well!

Simulation input/output for a simulation that's interesting or useful to emulate. Basically a potential use case for autoemulate. Optimally, these will have simple scalar inputs and outputs, rather than a mesh or something more complicated.

authors: kallewesterling mastoffel

repo: alan-turing-institute/autoemulate


text:
[DOC] SlidingWindowSplitter

Describe the issue linked to the documentation
Additional docstring here would be great to better understand how to configure this:

class SlidingWindowSplitter(BaseWindowSplitter):
    """Sliding window splitter
    Parameters
    ----------
    fh : int, list or np.array
        Forecasting horizon
    window_length : int
    step_length : int
    initial_window : int
    start_with_window : bool, optional (default=True)
    """

This is related to #477

Closed by #555

authors: aiwalter mloning

repo: alan-turing-institute/sktime


text:
refactors HCrystallBall Forecaster

Reference : https://github.com/alan-turing-institute/sktime/issues/955
We need to slowly re-factor all forecasters to be compliant with the new interface (see PR #912). i.e., no overrides of fit etc and descendant classes only implementing core logic, while the BaseForecaster implements check etc logic.
Currently this is running due to various downwards compatibility workarounds, which should be removed once all forecasters are ready (in "no-override" state)
The forecasters that still need a downstream refactor are:

[x] HCrystalBallForecaster

Hello @mloning @fkiraly @aiwalter . I would like to request for review. For some reason, I cannot do that on the reviewer menu. Did I raise the pull request wrongly?

Hello @fkiraly , I cannot see the option to merge this. Would you be able to merge it?

I cannot see the option to merge this. Would you be able to merge it?

Yes, I guess this relates to earlier discussion with @mloning - you need push access to the repo to merge it.
https://docs.github.com/en/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request
So I guess the modification of GitHub flow is that repo collaborators have to merge if the PRer is not a collaborator.
FYI, @mloning - you were right.

authors: fkiraly thayeylolu


text:
Scripts according VM CPU/Memory Hot-Plug Features

Hello,
the vCheck framework is an awesome tool to those who do not have vCOps or just get an overview about the things that do not comply 'standards or recommendations'. Sometimes it is executed by people, who do not really dive-in deep in the scripts and in environments with hundreds or thousands of VMs...
According KB 2040375, I think CPU/Memory Hot-Plug should ony be enabled, if You really need it.
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2040375
By default CPU Hot-Plug and Memory Hot-Add are disabled. If CPU Hot-Plug is enabled, vNUMA is disabled, which might have other impacts.
Therefore I think vCheck reports should only list those VMs, that have either CPU Hot Plug or Memory Hot Add enabled.
Right now, there are 2 scripts that address this. Maybe it is the best to provide only 1 script like mine
(I list only VMs that do not have either CPU nor Memory Hot Add enabled) - You can improve this by defining the desired CPU/Hot Plug state ($true / $false)
103 VMs with CPU and or Memory Hot Add Configuration.txt

Good suggestion - and good pickup on the duplicate plugins.
Will try to push a commit this week.

Removed duplicate plugin and updated 201 to allow defining what value you want each setting.

authors: Sneddo rebneth

repo: alanrenouf/vCheck-vSphere


text:
push方法耦合有点高？很多人并不愿意使用这类的非原生方法名的库。

因为push pop方法实在太多，跳转和返回如果一个个替换该多麻烦，而且不想用这个库的时候一个个改还是问题。
所以楼主的方法如果能替换系统的就好一些了。

我一开始就是hook 原生 push 和 present的方法，实现调用原生方法就可以直接调用动画，但是实际使用的时候发现了两个问题：1、如果头文件加在pch文件中，所有的原生push、present都变成我的库的效果，2、需要多一行代码来选择动画类型，耦合度也一样。
后面思考了很久参照SDWebImage这种加前缀的调用方法区分开来。
如果你工程中的调整都用到同一个动画，可以用Method Sizzing 交换原生的跳转方法。

authors: alanwangmodify jinxiansen

repo: alanwangmodify/WXSTransition


text:
🛑 TEDSIG 2020 is down

In c909db4, TEDSIG 2020 (https://tedsig.alaoweb.org/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: TEDSIG 2020 is back up in 8972122 after 9 minutes.

repo: alaoweb/status


text:
Please provide an example for augmentation and classification with pytorch

📚 Documentation
README.md links to this: https://github.com/albu/albumentations/blob/master/notebooks/example.ipynb – with a title of "classification". But there is no classification inside.

You may try to look at this repo: https://github.com/catalyst-team/classification/blob/master/src/transforms.py#L186

I am looking for some best practices for augmentation for classification, shall I go with the hard_transform you pointed to? It the readme of albumentations is says that you won several kaggle competitions using the library, what are the typical augmentations you use?

it 100% depends on task, you just have to run augmentations and see what happens with image

Are you taking bets on that? I bet that there are some best practices that are task-independent. But whatever.

authors: albu dreamflasher ternaus

repo: albu/albumentations


text:
PS-478-2 : create initial attributes after asset creation WIP DO NOT MERGE

create initial attributes after asset creation
add attributeDefinition.initializers (see Newspaper.yaml for syntax)
todo before merge : remove debug ; implement FR, EN ... (?)

closed in favor of clean https://github.com/alchemy-fr/phrasea/pull/336

repo: alchemy-fr/phrasea


text:
feat: add events to use react native signer

Pull Request Checklist

[ ] Did you add new tests and confirm existing tests pass? (yarn test)
[ ] Did you update relevant docs? (docs are found in the site folder, and guidelines for updating/adding docs can be found in the contribution guide)
[ ] Do your commits follow the Conventional Commits standard?
[ ] Does your PR title also follow the Conventional Commits standard?
[ ] If you have a breaking change, is it correctly reflected in your commit message? (e.g. feat!: breaking change)
[ ] Did you run lint (yarn lint:check) and fix any issues? (yarn lint:write)
[ ] Did you follow the contribution guidelines?

PR-Codex overview
This PR introduces documentation for using the React Native Signer package, including setup instructions, user authentication methods, and deep linking for user sessions.
Detailed summary

Added a new section in the sidebar for "Using the Signer".
Created a new .mdx file titled Using the React Native Signer.
Provided instructions on creating a Signer instance.
Explained user authentication via email and deep linking.
Included code examples for authentication methods.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#1182  👈 (View in Graphite)
#1181
#1180
moldy/rn-base

This stack of pull requests is managed by Graphite. Learn more about stacking.

@moldy530 Created a new PR to add the Getting started section to the Bare and Expo documentation here

Closing this in favor of: https://github.com/alchemyplatform/aa-sdk/pull/1181

repo: alchemyplatform/aa-sdk


text:
Compression is likely not working.

I've been playing around with the compression algorithms in hdf5 and observed that the Blosc compression algorithms basically do nothing. I suspect this is a bug on your end (though also possible on my end)
Here's my evaluation, hope it helps =]

See #273 for a potential duplicate

Great, I'll not worry about it for now then and hope a fix turns up in time. Thanks for the help!

You are very welcome to make a PR exposing blosc_sys::blosc_set_blocksize as hdf5::filters::blosc_set_blocksize and another adding features blosc-lz4 which enables `blosc-sys/lz4 etc.!

authors: CiaranWelsh mulimoen


text:
Add boolean control

Feature request: Add a boolean control

Resolved with new Toggle controls.

repo: aldernero/sketchy


text:
🛑 BOS Fahrzeug Info is down

In 142eea2, BOS Fahrzeug Info (https://bos-fahrzeuge.info/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: BOS Fahrzeug Info is back up in cfbdd73 after 29 minutes.


text:
🛑 Searx is down

In 555c26d, Searx (https://sx.alefvanoon.xyz) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Searx is back up in cdf406f.

repo: alefvanoon/Status


text:
TS2503: Cannot find namespace 'adal'

The example doesn't appear to work.
node_modules/angular2-adal/services/adal.service.d.ts(13,25): error TS2503: Cannot find namespace 'adal'.
Edit:
I fixed it by adding "adal": "github:DefinitelyTyped/DefinitelyTyped/adal-angular/adal.d.ts#53347571e6f44ed9a961b569bb81893fde4789c1" to typings.json

This issue still exists if you run the solution with Visual Studio 2015