How do I capture known antigen/epitope reactivity to AIRR objects (Rearrangement/Cell)

Moving discussion of linking AIRR objects of known epitope/antigen reactivity/specificity to this issue and out of #776

Discussion starts here:
https://github.com/airr-community/airr-standards/pull/776#issuecomment-2027483756

From the call:
Make a PR for the below, throw data at it, pray.
Reactivity:

Set cell_id to nullable:true and remove from required.
Add reactivity_ref (eg, to IEDB).
Expand reactivity_method and reactivity_readout for additional computational/experimental approaches (eg, activation assay, ML model).

Rearrangement:

Add reactivity_id.

PR with initial attempt created in #784
Need to look at reactivity_method and reactivity_readout controlled vocabulary terms.
For reactivity_method I added two, annotated for a reactivity record that is annotated from an external source (e.g. IEDB) and inferred for something that is inferred using a computational method (e.g. tcrmatch).
For reactivity_readout I could really only think of adding a confidence readout that for inference would capture the confidence of the inference and for annotated would suggest the "level of annotation" somehow.

This might be silly, but...
By "level of annotation" I mean capturing how complete the match is between the entity in the ADC and the entity in the external repository (e.g. IEDB). It is kind of a quality score that describes how exact the match is between the two repositories.
In IEDB we can have receptors with full v domain for both chains (a Receptor in the ADC definition) all the way down to I believe a single CDR3 from one chains (I would need to confirm that).
In the ADC we can have a similar range of completeness for Cells (e.g. Both chains fully annotated through to a Cell with a single rearrangement with not necessarily all of junction_aa, v_call, d_call, j_call populated for that rearrangement)
When annotating a Rearrangement with a Reactivity record that maps to an external resource, how important is it that we capture that completeness. This can be computed by checking the external record (IEDB) and the Cell/Rearrangements, but when we assign the Reactivity we know the level of completeness, so should we not annotate it?

From the meeting:

Create a new field to delineate whether this is observed or inferred.
reactivity_method: enum either "observed" or "inferred"

Drop the old fields:

reactivty_method, reactivity_readout, reactivity_value, and reactivity_unit

Create an example for this for an "observed" rearrangement that was observed in IEDB for discussion.

Here is an example of using Reactivity to associate a Cell with observed reactivity in an AIRR-seq study:
https://github.com/airr-community/airr-standards/issues/704#issuecomment-1891063546

Example of annotated Rearrangement with Reactivity:
curl -d '{"filters": {"op": "=", "content": { "field": "sequence_id", "value":"636f50e6c90058221e522b92" }},"fields":["v_call", "j_call", "junction_aa"]}' https://t1d-1.ireceptor.org/airr/v1/rearrangement

    "junction_aa": "CASSLQSSYNSPLHF",
    "v_call": "TRBV11-2*01",
    "j_call": "TRBJ1-6*02"

This is the beta chain of a known receptor in IEDB: https://www.iedb.org/receptor/182992 which is specific to this epitope: https://www.iedb.org/epitope/1616345
My equivalence criteria for annotations case is that the CDR3, V and J calls need to be an exact match
I want to annotate this so I create a Reactivity object as follows:
reactivity_id : XXXXXXX # ID for this object
cell_id: null # Not associated with a cell
ligand_type - peptide
antigen_type - peptide
antigen_source_species: Homo Sapiens
antigen: {Insulin, UniProt:P01308}
peptide_sequence_aa: QKRGIVEQCCTSICS
peptide_sequence_start: 87
peptide_sequence_end: 101
reactivity_method: observed
reactivity_ref: [IEDB:182992]

I then set for this Rearrangement Rearrangement.reactivty_id = XXXXXXX
If I have another Rearrangement that matches I can also set its Rearrangement.reactivty_id = XXXXXXX
The only problem I see is that there is no way for me to differentiate this Reactivity from one that is actually observed in this study directly.
I would still lean to having reactivity_method to have a third enum "annotated" which would be used in this case. Annotated implies observed, but not observed directly in this study. That is I am annotating a Rearrangement with an observed reactivity but the observation was from an external source.

FYI, in the T1D repository, there are 21 Rearrangements (out of >100 Million Rearrangements) that match on this CDR3/V/J
If I was to fully annotate this repository for that reactivity record, I would have 21 Rearrangements that would have XXXXXXX in their reactitivty_id field.
I should also note that there are 347 such Rearrangements in the ADC (out of 5 Billion Rearrangements) that could ultimately be annotated in this manner (if the repositories chose to do this).
If you flip this around, what we have done is taken one Receptor from IEDB and annotated all of the Rearrangements (347 of them) in the ADC that match on the CDR3/V/J exact match criteria.
There are 180297 Receptors from Homo Sapiens in IEDB. For sake of argument, lets say that on average we get a similar match to the above (350 Rearrangements/Receptor). We would then have 63 Million annotated Rearrangements across all of the Repertoires in the ADC annotated with some sort of antigen/epitope specificity. That is ~1% of the 5 Billion Rearrangements in the ADC annotated with some sort of disease specificity. How interesting would that be???
Who knows what the real frequency per IEDB Receptor might be, but it would be interesting to find out!

One other quick observation, the alpha chain for the IEDB Receptor is TRAV9-2/CALRTDRGSTLGRLYF/TRAJ18. There are 26 of these in the ADC, so ultimately we would have 347 + 26 Rearrangements in the ADC point to [IEDB:182992] if the repositories in the ADC were to completely annotate the ADC for IEDB Receptor IEDB:182992

For completeness, here is an example of a Reactivity object created from an observation in an actual AIRR-seq study. This is detected with a dextramer barcode and the Cell in the ADC does not match any Receptors in IEDB for this Epitope.
reactivity_id: YYYYYYY
cell_id: CCCCCCC
ligand_type:	MHC:peptide
antigen_type:	peptide
antigen:  {"id:: "NCBI:YP_009725307.1, "label": "RNA-dependent RNA polymerase (nsp12)"}
antigen_source_species	{ "id": "NCBITAXON:2697049", "label" : "Severe acute respiratory syndrome coronavirus 2"
peptide: DTDFVNEFY
peptide_start:	738
peptide_end:	746
mhc_class:	MHC-I
mhc_gene_1:	id: MRO:0000046, label: HLA-A
mhc_allele_1:	HLA-A*01:01
reactivity_method: observed

This is what we would have stored previously, but with the suggestion that we don't store these things any more, we lose this information.
reactivity_method	dextramer barcoding
reactivity_readout	barcode count
reactivity_value	23
reactivity_unit	absolute count

This seems important to me, are we sure we want to drop this?

@javh @bussec any comment on the above - or should I go ahead and make the changes from the last meeting. I still hestitate to remove the reactivity_method, reactivity_readout, reactivity_value, reactivity_unit because of the use case above...

My suggestion is to consider reactivity_method having: observed, annotated, inferred as possible string, and if observed one can/should fill out reactivity_method, reactivity_readout, reactivity_value, reactivity_unit and if annotated or inferred they should be left blank...
We would need to figure out names for the two fields that are reactivity_method in this case.
Thoughts?

I still hestitate to remove the reactivity_method, reactivity_readout, reactivity_value, reactivity_unit because of the use case above...

IIRC, our logic from the last call was there were certainly valid use cases for this information, but that we didn't want to hassle with enumerating them all because there's quite a few experimental approaches we'd need to accommodate if we went down that road. So we're trading schema completeness for tractability.

My suggestion is to consider reactivity_method having: observed, annotated, inferred as possible string [...]

I think reacivity_method = annotated has semantic problems. Umm, can you accomplish what you want with reactivity_ref? If there's an IEDB (or other ref) in that field, then that implies "annotated".
Could reactivity_ref link to a repertoire_id? Is that something we do?

I think reactivity_method = annotated has semantic problems. Umm, can you accomplish what you want with reactivity_ref? If there's an IEDB (or other ref) in that field, then that implies "annotated".

Based on discussion at the meeting today, I think we are leaning to have observed and inferred, with the use case of referencing a reactivity from an external resource like IEDB being considered an inferred reactivity and by having reactvity_ref: IEDB_RECEPTOR:182992 stating that source of the inference is from an IEDB entity. I think this would make sense to me. The Reactivity being captured in this case is an inference based on data fron an external repository (IEDB) with the inference being determined by matching the ADC entity (Cell or Rearrangement) to the entity in IEDB to some level of matching criteria.
Just like if using an inference algorithm that works on some closeness criteria of the CDR3 to predict reactivity, we are using an algorithm with some matching criteria to a Receptor in IEDB to predict reactivity based on the Receptor/Reactivity data in IEDB.
I think this works.

Could reactivity_ref link to a repertoire_id? Is that something we do?

Haven't thought of that to date, but...
Since we are documenting inference of a Cell or Rearrangement reactivity by linking it to data in an external repository, this could be any repository (IEDB, VDJdb, MCPAS, etc). If the only place that this Reactivity is documented is in a repository in the ADC, I suppose it would not be out of the question. We are then linking to an internally observed reactivity. I am not sure exactly what object to link to. I am not sure it would be the repertoire_id. It would almost be another Reactivity wouldn't it?
I think this is a pretty extreme edge case?
I suppose that my hope would be that any Receptor/Reactivity evidence found in a study in the ADC would be curated into a repository like IEDB, where other evidence for that Receptor/Reactivity would reside. There is a level of curation process and methodology around that, where evidence is gathered through multiple studies and assays to provide evidence that supports that Receptor/Reactivity.
When storing an inferred reactivity in the ADC, by using such an external resource such as IEDB, we get stronger evidence to support the inference. With that said, since the ADC is storing Reactivity, your use case should not be considered out of the question I suppose.

I would almost suggest that the flow might go the other way. If a study stored in the ADC detects a Reactivity to a Cell or Rearrangement that is directly observed through that study (e.g. the tetramer bar code example above) then this is a primary observation of the phenomenon. I could see how IEDB could use the ADC to look for observed reactivity and use that to help them find data to curate into IEDB. All of the metadata for the study would be in the ADC, so presumably this would make it easy(ier) for them to curate that data in IEDB. @rvita @bpeters42 would that make sense?
Once it is curated in IEDB, then any inferred reactivity of a Cell or Rearrangement in the ADC would include the "self-evidence" but would also include any other evidence for that reactivity that is stored in IEDB. IEDB in this case would not be interested in inferred Reactivity in the ADC but they would be interested in observed Reactivity in the ADC.

IIRC, our logic from the last call was there were certainly valid use cases for this information, but that we didn't want to hassle with enumerating them all because there's quite a few experimental approaches we'd need to accommodate if we went down that road. So we're trading schema completeness for tractability.

Small steps I suppose.  8-)
We have in the past used a string to keep such fields flexible, with documentation on recommended or possible examples to guide users in the right direction. That way we don't need to be complete, but do enable the ability to capture the data. One possibility... 8-)
If we don't have something like this, when we load these data we will probably just do this ourselves by storing the data in custom internal iReceptor fields. We don't want to not load this data when we are loading everything else, and then try and load it piecemeal after we come up with a mechanism to do it properly 8-) Easier for us to store these fields in our best guess and then map/convert them later if necessary...
So look for the fields `ir_reactivity_method, ir_reactivity_measure, ir_reactivity_value, ir_reactivity_unit' in our repositories 8-)

If I understand correctly, you are asking if the ADC had published epitope
specific experimental data that was not yet in the IEDB, we (the IEDB)
could use the ADC to identify and curate it? If so, yes, as long as the
data is connected to its PMID.
---------- Forwarded message ---------
From: Brian Corrie @.>
Date: Mon, May 6, 2024 at 4:41 PM
Subject: Re: [airr-community/airr-standards] How do I capture known
antigen/epitope reactivity to AIRR objects (Rearrangement/Cell) (Issue #781)
To: airr-community/airr-standards @.>
Cc: rvita @.>, Mention @.>
I would almost suggest that the flow might go the other way. If a study
stored in the ADC detects a Reactivity to a Cell or Rearrangement that is
directly observed through that study (e.g. the tetramer bar code example
above) then this is a primary observation of the phenomenon. I could see
how IEDB could use the ADC to look for observed reactivity and use that to
help them find data to curate into IEDB. All of the metadata for the study
would be in the ADC, so presumably this would make it easy(ier) for them to
curate that data in IEDB. @rvita https://github.com/rvita @bpeters42
https://github.com/bpeters42 would that make sense?
Once it is curated in IEDB, then any inferred reactivity of a Cell or
Rearrangement in the ADC would include the "self-evidence" but would also
include any other evidence for that reactivity that is stored in IEDB. IEDB
in this case would not be interested in inferred Reactivity in the ADC but
they would be interested in observed Reactivity in the ADC.
—
Reply to this email directly, view it on GitHub
https://github.com/airr-community/airr-standards/issues/781#issuecomment-2097101326,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADKDY42QQYV2MGAMGVCFCETZBAIKXAVCNFSM6AAAAABFQROPL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJXGEYDCMZSGY
.
You are receiving this because you were mentioned.Message ID:
@.***>
--
Randi Vita, M.D.
Lead Ontology and Quality Manager
Immune Epitope Database and Analysis Project
La Jolla Institute for Allergy & Immunology
9420 Athena Circle
La Jolla, Ca 92037
@.***
www.immuneepitope.org
858-752-6912

This is what we would have stored previously, but with the suggestion that we don't store these things any more, we lose this information.
reactivity_method	dextramer barcoding
reactivity_readout	barcode count
reactivity_value	23
reactivity_unit	absolute count

This seems important to me, are we sure we want to drop this?

I think the crux of what remains is what we do with these fields. The discussion above seems to imply that our meetings came to the conclusion that these should be removed from the Reactivity object - but as I say in one of my comments above this seems really important. The main reason why we want to remove it is that it became "complicated" to capture this information in the context of linking a Rearrangement to Reactivity. In our earlier discussions around Cell and Reactivity (https://github.com/airr-community/airr-standards/issues/704#issuecomment-1891063546) we agreed that these fields would work well and that this was important.
So it seems wrong to me to remove the fields we decided we needed for Cell->Reactivity interactions because we are adding Rearrangement->Reactivity interactions. If this is the case, then I would suggest that we need a different way to link Rearrangements to Reactivity rather than dumb down our Reactivity object.

This pull request is currently adding a minor field to Rearrangement but removing important functionality from Reactivity - which was not what was intended for this pull issue and the related pull request. If we can't come up with another solution, I would rather drop reactivity_id from Rearrangement rather than remove the above fields from Reactivity.


feature/cplp-1251 company user assigned role db audit

https://jira.catena-x.net/browse/CPLP-1251

This PR will be closed since the changes are provided in PR


Rebuild the processing syntax highlighter using java as a base

@b-g @ybakos Give this version a try. I did a screenshot compare of some of my pde files and in each case the highlighting was improved and no highlighting was lost from what I can tell. Hopefully you find the same results!
Here's what I did for reference:

started with java as a base
took out java's "enum" and "package" (not supported by processing)
added C++'s function call highlighting
put back in processing's keyword highlighting

Here's a comparison to the screenshots I took in #20:

(and for completeness here's it compared again to the current processing highlighting)

Awesome! However, two issues I see are:

We should keep enum and package.
Unwanted italicization of data types.

I see now - maybe the italics in the screenshot are just part of your particular config. (In mine, datatypes are not italicized.)

Kyle, actually I redact everything I said and I do like your approach. Every other way just doesn't make sense. Thank you soooo much for working on this. There are some minor issues, which I will post here and also add line-by-line comments to the source.

@kylefleming I've now spent significant time with this. Thanks again. I have one humble request and one potential flaw to point out. Screenshot below illustrates.

Let's ensure that enum Foo behaves like class and interface.
Dark color themes (eg. Amy, others) tend to incorrectly highlight parens and/or braces. May be a bug in the relevant regex.... or perhaps the color themes themselves, but I'm mentioning it here. Screenshot illustrates.

I'm personally no longer concerned with the way package is/isn't handled; the default actually seems aesthetically pleasing across many different color themes.

@kylefleming
(sorry to be so chatty)
You can ignore my comments regarding the inconsistent parenthesis highlighting. This is really an issue of the particular color theme.
I guess the only issues to discuss are:

Adding enum to the same / similar rule as class and interface.
The impact of changing source.pde to source.processing.

/cc @b-g

@ybakos I'll answer your questions in order:

enum/package highlighting: if you try to declare an enum or declare your file belongs to a package, in both cases you get a compiler error. The reason I can see to keep it is if we wanted someone to be able to select the processing highlighter for a pure java file. On the whole, it doesn't hurt to add them back in, so either way is fine with me. I notice in your screenshots you have these declared listed. Do those files compile?
italicized data types: From what I can tell, for data types of a variable declaration, java uses the style identifier storage.type and c/c++ uses variable.other. Given that the color scheme can style each identifier however it wants, your theme probably styles the 2 identifiers exactly the same while the one I'm using (Monokai on sublime text 2) probably italicizes one of them. We can change it to match what was there before if we want, for this issue too I think either way is fine.
Just for reference, I also want to mention that I changed the base of the processor to start at "class-body" instead of "code". class-body includes code so it will be backwards compatible, but this is representative of how processing works, since all of the code in the pde's are essential embedded in a global PApplet class. The styler now reflects this and lets you do things like declare methods on the top level (like setup()) which isn't possible in java.
I agree we should take out java only classes. But also those classes are styled for me the same way as a normal class, so I'm not sure that they're even doing anything right now. I think it will need more investigation. In general though, I agree only processing specific classes/constants should be highlighted differently.
Inconsistent paren highlighting: That's an artifact of the copying the function call highlighting from C, where it styles the first parenthesis as punctuation.definition.parameters. It's easy to take out and probably should be taken out, or we should highlight the end one too. The easier route is to take it out though.
changing source.pde to source.processing: From what I could tell, other languages all declare that as the name of the language not the file extension. I changed it to keep consistency. It doesn't make a difference in the grand scheme of things, though. If we change it to source.processing, we should also change the build scripts and anything else that depends on it. Otherwise, changing it back is fine too.
Another change to note: I changed the postfix of the style identifiers from .java-processing to .processing. This again is for consistency with other languages. (and side note I see I forgot to change the C ones.) There may be side of effects of this change, but I'm not away of any.

Thanks @kylefleming . I think in this PR we should keep it focused to the issue at hand and ignore my comments about the Java classes, etc.
I think it's wise to:

include the enum stuff (again, ignore what I said about package).
Perhaps make the source.processing change in other locations.

Care to create another PR with those two changes, and close this one? (@b-g will probably chime in soon).

@ybakos Thanks for the code review. I added a new commit to this pull request with these changes:

I switched back to source.pde. I figure that the config files of people's machines are probably already using source.pde for things like "always open this file as" and stuff like that. Better not to break it.
I put enum and package stuff back in. Since the processing language file declares it can open java files, it's probably best to make sure it styles them the same as the java highlighter would.
I removed the part where it styles the first parenthesis of a function call differently. Good catch.

Merged!
@kylefleming
Many thanks for taking care of it! Finally working syntax highlighting!
I added you to https://github.com/b-g/processing-sublime#acknowledgements
@ybakos
Thanks for feedback, code review and spotting!

@kylefleming Awesome, man. Thank you!

I'm glad it all worked out, happy to have contributed!


fix: update apiversion for ingress. fixes #75

This change updates the maximum apiVersion for ingress if the Kubernetes cluster Atlantis is running on supports it.

Also, this updates the method for checking capabilities since .Capabilities.KubeVersion.GitVersion is deprecated. See: https://github.com/helm/helm/blob/7d13cd5ca1f1eee080c180be6c3201e3a81ff6e9/pkg/chartutil/capabilities.go#L80

Hi, thanks for this patch!
It's a nice first step but the chart might still fail on a stable API because of changes in supported fields.
The chart is using spec.rules[0].http.paths[0].backend.serviceName and spec.rules[0].http.paths[0].backend.servicePort with became spec.rules[0].http.paths[0].backend.service.name and spec.rules[0].http.paths[0].backend.service.port.number or .name
Also spec.rules[0].http.paths[0].pathType became a required value and is not provided yet. This one might be heavier to change, as path values are advised to use a * wildcard and I don't know if one of the possible filePaths support it now.
Do you think this patch could also address these parts so the linked issue is actually fixed?

Yes. Totally forgot about the spec change. I'll work on it and reply soon.

FWIW, I've set this up to generate based off of what's available in the cluster. @tszym you made a note that "path values are advised to use a * wildcard" and I couldn't find that in the reference for paths but did see it for hostnames.

Oh right, I meant the readme of this chart currently describes ingress paths with

Path to use in the Ingress. Should be set to /* if using gce-ingress in Google Cloud.

I don't know if that is still possible with the stable API as I did not find it either in the reference.

Do you know if that would be appropriate to reference an ingress class, or provide a way to do it, in the ingress resource?

Oh right, I meant the readme of this chart currently describes ingress paths with

Path to use in the Ingress. Should be set to /* if using gce-ingress in Google Cloud.

I don't know if that is still possible with the stable API as I did not find it either in the reference.

The documentation here makes me think that the readme of the chart is still applicable

Do you know if that would be appropriate to reference an ingress class, or provide a way to do it, in the ingress resource?

Were you thinking of this? https://kubernetes.io/docs/concepts/services-networking/ingress/#deprecated-annotation
I could see creating the option to define it, but to leave it nil for now. Thoughts?

I was thinking about adding an optional ingressClassName field if that's ok to you. This should be enough, I don't feel like the IngressClass resource should be part of the chart but as I understand the stable API, the field on the ingress should be useful.

Check it out when you have time and let me know.

Looks good to me! Maybe need to add the field to the table in the readme, or it's automatic idk.


fix: allow importing 'false' values

Currently fields are rejected based on #blank?. false.blank? equals true, so false values are discarded.
https://github.com/stephskardal/rails_admin_import/blob/5a536c3de0039bf89581cf393cd44e64882b8baa/lib/rails_admin_import/importer.rb#L208-L210

Thanks for the fix! Released as 3.0.3


raftstore: check merge entries' length to avoid slice out of range

What have you changed? (mandatory)
In merge process, target region will send entries to fall-behind source region. It is possible to propose a CompactLog command after proposing PrepareMerge.  Note that, the entries involved in CommitMerge would not take the CompactLog record.
So during the merge process, if the source region catches up with the logs by raft append msgs, self.raft_group.raft.raft_log.committed - log_idx would be larger than entries.len() which leads to entries[self.raft_group.raft.raft_log.committed - log_idx..] out of slice range.
So check the len before cutting up the slice.
What are the type of changes? (mandatory)

Bugfix (a change which fixes an issue)

How has this PR been tested? (mandatory)
unit-test
Does this PR affect documentation (docs) or release note? (mandatory)
No
Does this PR affect tidb-ansible update? (mandatory)
No
Refer to a related PR or issue link (optional)
https://github.com/pingcap/tidb/issues/11744

PTAL @BusyJay @overvenus @hicqu

/release

/release

/run-all-tests

I remove the key fix in src/raftstore/store/peer.rs, the test can still pass.

@BusyJay Here is what the result shows when I comment the key fix, and it can be reproduced everytime on idc. Maybe should enlarge the wait time to trigger compact?
running 1 test
thread 'raftstore-3-0::test_node_merge_catch_up_logs_no_need' panicked at 'slice index starts at 3 but ends at 2', src/libcore/slice/mod.rs:2561:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
thread 'apply-0::test_node_merge_catch_up_logs_no_need' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', src/libcore/result.rs:1051:5
thread 'cases::test_merge::test_node_merge_catch_up_logs_no_need' panicked at 'called `Result::unwrap()` on an `Err` value: Any', src/libcore/result.rs:1051:5
test cases::test_merge::test_node_merge_catch_up_logs_no_need ... FAILED

@BusyJay I try it on my poor laptop, and it also can be reproduced steadily. How you test it?


Dependency conflict for ipython 7.16.3

On doing pip install -e . inside the conda environment, pip complains about ipython requiring pexpect:
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
ipython 7.16.3 requires pexpect; sys_platform != "win32", which is not installed.

I'm on Ubuntu, which is definitely not "win32", so perhaps that's behind this?

Are you running the pip install on a new python virtual environment?

There is generally an issue with the dependencies. I will try to fix them. The Tensorflow version got outdated maybe this resulted in an error.

Are you running the pip install on a new python virtual environment?

Not sure if I understand "new" but I created a conda environment just for this repo and am not re-using an environment from another project

There is no ipython requirement in the setup.py file. That's why I suspect maybe it's not a clean conda environment. Can you please do conda list and share the output?
Also, could you try in another fresh conda environment branch_hotfix/fix-python-requirements_ if it's working?

Sorry for the delay.
Here's the output of conda list in the same environment that gives the error described in this issue, and there's no ipython:
# Name                    Version                   Build  Channel
_libgcc_mutex             0.1                        main
_openmp_mutex             5.1                       1_gnu
absl-py                   1.1.0                    pypi_0    pypi
astor                     0.8.1                    pypi_0    pypi
atari-py                  0.2.6                    pypi_0    pypi
bcrypt                    3.2.2                    pypi_0    pypi
ca-certificates           2022.4.26            h06a4308_0
cached-property           1.5.2                    pypi_0    pypi
certifi                   2021.5.30        py36h06a4308_0
cloudpickle               1.6.0                    pypi_0    pypi
cryptography              37.0.2                   pypi_0    pypi
gast                      0.5.3                    pypi_0    pypi
google-pasta              0.2.0                    pypi_0    pypi
gripperenv                0.0.1                     dev_0    <develop>
grpcio                    1.46.3                   pypi_0    pypi
gym                       0.19.0                   pypi_0    pypi
h5py                      2.10.0                   pypi_0    pypi
iniconfig                 1.1.1                    pypi_0    pypi
keras                     2.2.4                    pypi_0    pypi
keras-applications        1.0.8                    pypi_0    pypi
keras-preprocessing       1.1.2                    pypi_0    pypi
ld_impl_linux-64          2.38                 h1181459_1
libffi                    3.3                  he6710b0_2
libgcc-ng                 11.2.0               h1234567_1
libgomp                   11.2.0               h1234567_1
libstdcxx-ng              11.2.0               h1234567_1
llvmlite                  0.36.0                   pypi_0    pypi
markdown                  3.3.7                    pypi_0    pypi
ncurses                   6.3                  h7f8727e_2
numba                     0.53.1                   pypi_0    pypi
numpy                     1.18.0                   pypi_0    pypi
openssl                   1.1.1o               h7f8727e_0
paramiko                  2.11.0                   pypi_0    pypi
pip                       21.2.2           py36h06a4308_0
pluggy                    1.0.0                    pypi_0    pypi
protobuf                  3.19.4                   pypi_0    pypi
py                        1.11.0                   pypi_0    pypi
pybullet                  2.6.4                    pypi_0    pypi
pydot                     1.4.2                    pypi_0    pypi
pyglet                    1.5.26                   pypi_0    pypi
pynacl                    1.5.0                    pypi_0    pypi
pytest                    7.0.1                    pypi_0    pypi
python                    3.6.13               h12debd9_1
pytz                      2022.1                   pypi_0    pypi
readline                  8.1.2                h7f8727e_1
seaborn                   0.11.2                   pypi_0    pypi
setuptools                58.0.4           py36h06a4308_0
six                       1.16.0                   pypi_0    pypi
sqlite                    3.38.3               hc218d9a_0
stable-baselines          2.10.2                   pypi_0    pypi
tensorboard               1.14.0                   pypi_0    pypi
tensorflow                1.14.0                   pypi_0    pypi
tensorflow-estimator      1.14.0                   pypi_0    pypi
termcolor                 1.1.0                    pypi_0    pypi
tk                        8.6.12               h1ccaba5_0
tomli                     1.2.3                    pypi_0    pypi
werkzeug                  2.0.3                    pypi_0    pypi
wheel                     0.37.1             pyhd3eb1b0_0
wrapt                     1.14.1                   pypi_0    pypi
xz                        5.2.5                h7f8727e_1
zlib                      1.2.12               h7f8727e_2

However, pip list does have ipython (apparently conda may not recognize packages installed by pip), here's the output of pip list | grep ipython:
ipython                       7.16.3    <---- this matches the version number in the error log
ipython-genutils              0.2.0

Idk how relevant this is, but on doing pip list | grep ipython outside the virtual environment:
ipython                            5.5.0  <---- not 7.16.3
ipython-genutils                   0.2.0

So I don't think ipython 5.5.0 is playing any role here.
And regarding

could you try in another fresh conda environment branch  hotfix/fix-python-requirements if it's working?

I see you've merged that branch -- again, sorry for responding late -- so I pulled master and created a new environment and still see the issue.

If this problem cannot be reproduced by you, I don't think there's much you can do here. I'm okay with closing this issue, and if anyone else who tries out your work runs into a similar problem and has new information to add, this ticket could be re-opened.


Is it possible to setup Amplify to use MTLS protected API Gateways?

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting questions.
[X] I have removed any sensitive information from my code snippets and submission.

App Id
new_app
AWS Region
us-west-1
Amplify Hosting feature
Access control
Question
I've got an API Gatweway configured to connect using MTLS using this documentation: https://aws.amazon.com/blogs/compute/introducing-mutual-tls-authentication-for-amazon-api-gateway/
As a human, I can make an API call using my client cert and private key.
As an Amplify site, my client cert needs to be in the API's configured truststore and I need to use my private key to make the API call.
How do I get access to the Amplify/Route53 auto configured certs PEM file and its key? It does not show up in ACM for me and it doesnt appear to be availble through the amplify console. Alternatively, can the cert and key be leveraged through the SDK somehow?
Thanks!

Bueller? :D

Hi @ogg130 👋🏽 thanks for raising this question. Amplify Hosting is a managed service and we manage all of the certificates internally. We do not provide access to any keys or PEM files associated with certificates at this time. We apologize for this inconvenience.


[Slack] Add Search Messages command

Description
Add a new command to search through your Slack's workspace messages.
Also rename Search to Open Channel for consistency.
Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

@jfkisafk You can already have a look if you want 🙂

@jfkisafk could you check this after the latest update 🙂

I will take a look at this today.


Fix an incorrectly formatted URL in the v1.10 release note

I also have a separate PR (https://github.com/kubernetes/kubernetes/pull/62294) in the kubernetes repo to fix the change log upstream. This change is to fix the already imported release note on the live website.

/approve
/lgtm


WebSockets/Channels support

This isn't as much of a feature request as it is an attempt to start of a conversation about the possibility of adding WebSocket support (through Channels or otherwise). This would probably have to be done through AWS IoT (MQTT over WebSockets).
Here is a proof-of-concept using this with AWS Lambda:
http://stesie.github.io/2016/04/aws-iot-pubsub
I also found this, but I'm not sure if it helps us any:
https://github.com/edigiacomo/asgi-mqtt

I don't see a way to get plain Websocket support, only MQTT-over-websockets.  And you don't really need Lambda for that.

I think having a websocket solution that can work within the context of this framework would be valuable, however I do see your point in that it doesn't have to be directly coupled with Zappa. Maybe this would be better suited as a separate library?

Bumping this as websockets are now a part of api-gateway!
https://aws.amazon.com/blogs/compute/announcing-websocket-apis-in-amazon-api-gateway/

Bumping this as websockets are now a part of api-gateway!
https://aws.amazon.com/blogs/compute/announcing-websocket-apis-in-amazon-api-gateway/

Hi guys!  Any ideas, how implement this to zappa?

For this to work, there would need to be a Django/Flask Websocket extension that worked like AWS API Gateway, it has a specific way of dealing the connection, working as a middleware

In terms of syntax/abstraction, I think a great way to implement this would be by extending zappa-async to handle the web socket logic.

I am not certain if this would be the solution here, but I've created an adapter library for ASGI on AWS Lambda & API Gateway called here with an open issue about WebSocket support here. I haven't had much time to dig into the WebSocket support specifically, but I'm very interested in finding the solution.
If there is an interest in supporting ASGI in Zappa I would be happy to assist where I can, in which case I think to approach from HTTP support first and then tackling WebSockets after would be the way to go.

Is there any update on this topic?

I added it in my Zappa branch https://github.com/delijati/Zappa. Here i played a bit around with it https://github.com/delijati/benchmark :)

I added it in my Zappa branch https://github.com/delijati/Zappa. Here i played a bit around with it https://github.com/delijati/benchmark :)

Nice work! Have you played around with any ASGI frameworks (eg. https://bocadilloproject.github.io/) with your fork of Zappa?

or quart?  Now that this is possible, I'm definitely :+1: on it!

the benchmark uses quart ;) i really would like to know why the WSGI seams faster

Any update on this? Seems to be bummer for people working on ASGI frameworks.

Yes, I'm like what I'm seeing in fastapi, what's the status here, any clear direction  or work that needs to be done?

Any update on this? Im trying to implement websockets with zappa and AWS Lambda

Has anyone tried out the api gateway support for websockets? What doesn't work? https://aws.amazon.com/blogs/compute/announcing-websocket-apis-in-amazon-api-gateway/

Is there already a way to get this working somehow? Also interested in proof of concepts, suggestions, workarounds, e.g. any info at all.

@acidjunk
I was working on an ASGI protocol implementation to support WebSockets on a branch in a different project, though it may be applicable here if ASGI support is introduced. I was able to create a successful deployment in an example application (based on a previous commit in that branch). The implementation follows the backing-service approach demonstrated in broadcaster to persist the connection identifiers.
I included detailed docstrings/comments in the protocol class to explain how the flow works. There is also more information on the old doc page and in this issue.
Essentially the way it works:

A $connect event is received, and the adapter stores the connection id in the backing service and returns successfully to complete the handshake.

Any $message events fetch the connection id from the backing-service and runs a new ASGI protocol+application instance until the connection becomes stale or the application decides to close it.

A $disconnect event should remove the connection id from the backing-service.

I'm tracking future progress on any of my future efforts here, but for the moment I am bored of this problem and haven't been motivated to push forward. If you decide to take a shot at this and have any specific questions, feel free to comment on that issue.
Hope any of this helps! :)

API Gateway Websocket integration should be pretty straight forward:

API Gateway handles the persistency, so the Lambda handler/Zappa can remain stateless
API Gateway triggers events, which can invoke Lambda function responses
pushing messages to a socket can be done via boto (e.g. boto3.client('apigatewaymanagementapi').post_to_connection(ConnectionId=connection_id, Data=...))

In other words, incoming events can be handled like any other HTTP request or scheduled event, and outgoing data is a simple HTTP request as well.
Currently this is best implemented by setting up an HTTP Proxy integration in the Websocket API Gateway, triggering the Lambda handler via HTTP. What Zappa could do here would be to augment the LambdaHandler class to accept API Gateway Websocket events directly as well; currently those simply don't fit any of the existing patterns and just fall through, doing nothing. Then a Lambda function integration could be done, which is probably a bit more performant. Integrating some templates for making that API Gateway setup a simple configuration option would be nice too.

Guys, Any update on this?

Bump

Hi @mister-rao and @pfcodes,
Can you please ask for this feature on currently active repo here https://github.com/zappa/Zappa/issues/949 ?


Add more validations in voting contract init methods

Describe the bug
Some validations are not present in init function of the voting contract. Parameters like voting_period_secs, target_approval_rate_bps and total_voters should never be zero.

Completed with https://github.com/eigerco/nebula/pull/92


Roylly new arrow orientation

Checklist for this pull request

[x] I have read the guidelines for contributing.
[x] I have updated README.md, describing the new feature I'm adding (if applicable).
[x] I have checked that my code additions did fail neither code linting checks nor unit/UI test.

Description
I have finished the arrow orientation support left and right development, but don't make big change for the layout engine, just add new case for layout.
Thanks!

Thanks for taking the time to rework your PR! I haven't forgotten you, I'll take a look before the end of the coming week.

Thanks for your work, it's much cleaner now, which make my job easier. I really appreciate it!
I see two issues remaining:

You need to install Swiftlint and make sure the code pass linting. I don't have a strict style guide, but passing the linting phase with neither warnings nor errors is required.

You went for manual positioning, which means that left/right settings override the automated positioning. Nothing wrong with that, I'm happy with it. However, I don't think we should be forced to provide a maxWidth to prevent coach marks from being out of bounds. The second coach mark in the provided example is partially out of bounds on an iPhone SE, while it should only expand as far as the screen bounds (if maxWidth is not provided).

Thanks for being patient and reworking your PR. We're getting there!

I have fixed the two issues you pointed out . thanks!  And i am learning swift, thanks for your help.

Looks good to me!

And i am learning swift, thanks for your help.

You're welcome ;)

Nearly a year old. Has this not been merged in? I'm only seeing "top, bottom"

@bryan1anderson Yeah, sorry about that. This was merged into a temporary branch. There's still a bit of cleanup before I can make it play well with master and it's low priority for me.


Can't slide all the way to the end when variableWidth:true and infinite:false

Can't slide all the way to the end when variableWidth:true and infinite:false. Gets stuck on first visible slide on the left.

====================================================================
[  paste your jsfiddle link here  ]
http://jsfiddle.net/fmo50w7n/1577/
====================================================================
Steps to reproduce the problem

Try and get to slide 6. It is not possible

====================================================================
What is the expected behaviour?
You should be able to step or slide right to the end
====================================================================
What is observed behaviour?
Controls disable and can't slide passed the first visible slide on the left
====================================================================
More Details

Which browsers/versions does it happen on? Chrome, FF, Safari
Which jQuery/Slick version are you using? 1.8.1
Did this work before? Not sure

I guess this is happening because I've got "slidesToShow = 4". When I change it to a value of 1 it works as expected. I still think it would be nice though if it kept progressing through the slides until the last one was fully visible.

Have the same issue

Same issue. It is definitely a bug


Fixing Cmedlet

changing NewRgsTimeRange to the correct cmdlet New-CSRgsTimeRange
fixed on line 53,54,55

@kenwith Can you please verify this pull request so that I can merge it and close the vso item for it? Thank you.


need help

how do i export my old game and put everything togethor on unity ? ;)

You can use my AssetRipper fork.


update responses

add private auth
add right JSON response. Format from docs:

{
  "channels": [
    {
      "channel": "$chan1",
      "token": "<SUBSCRIPTION JWT TOKEN>"
    },
    {
      "channel": "$chan2",
      "token": "<SUBSCRIPTION JWT TOKEN>"
    }
  ]
}

Laravel PrivateChannel to Centrifugo format
Change Laravel PrivateChannel prefix (private-) to Centrifugo format ($). Now can use

public function broadcastOn()
    {
        return new PrivateChannel('some.channel');
    }

Thanks for the pull request, I will check and do the merge with the master


Rename clone to prototype

The Maintenance uses also the entry concept from the MORYX-Platform but instead of prototype the name clone was chosen. Same names will help to understand the implementation of the entry concept.

Closed by #37


Android studio flutter plugin snippet auto-complete for InheritedWidget still uses deprecated inheritFromWidgetOfExactType method

Currently the default snippet for InheritedWidget (inh+<tab>) is still using inheritFromWidgetOfExactType.
According to API documents inheritFromWidgetOfExactType is deprecated and should be replaced by dependOnInheritedWidgetOfExactType.

Hi @CareF
but this is already marked as deprecated. Or do you mean it shouldn't be at all in the auto-complete?

Hi @CareF
but this is already marked as deprecated. Or do you mean it shouldn't be at all in the auto-complete?

@VladyslavBondarenko Sorry for any confusion but I mean when I use the snippet (inh + ), the code piece created is using the duplicate inheritFromWidgetOfExactType method.

@CareF oh, I didn't pay attention to (inh+<tab>), it's clear

/cc @devoncarew

Thanks for the heads up!


Add commit-message command

@reker- latest published as 1.3.0. As an aside, the _command method is a legacy approach that currently fails on windows machines so I made a note in the README. Also, I added a fallback for node envs that don't have spawnSync (e.g. node 0.10.x).
Thanks for your help!

@kurttheviking It was a rather sleazy shortcut.
I will write up a solution that actually parses .git/logs/HEAD to make it more accessible / backward compatible.

@reker- sounds good; no rush -- any time & help is very much appreciated; i'm sure you're busy with many other things


[0.17.x] [KOGITO-3643] Setup 0.17.0-rc1 version

https://issues.redhat.com/browse/KOGITO-3643
to avoid conflicts with master branch in nightly, until the next release.
Many thanks for submiting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:

[x] You have read the contributors' guide
[x] Pull Request title is properly formatted: [KOGITO-XYZ] Subject
[x] Pull Request contains link to the JIRA issue
[x] Pull Request contains description of the issue
[x] Pull Request does not include fixes for issues other than the main ticket
[ ] Your feature/bug fix has a unit test that verifies it
[x] You've tested the new feature/bug fix in an actual OpenShift cluster

BDD tests should be executed, if needed once https://github.com/kiegroup/kogito-images/pull/263 has been merged and nightly images pushed to quay

Why we need this?

to avoid conflicts with master branch in nightly, until the next release.

I don't have the time to go through it now, but would we need an actual release or you guys are creating this just a workaround?

this is 0.17.x branch. this is just a temp setup before the release.

there is no release done yet

@radtriste is this one ready?

yep it is ;)


Missing Settings

[Enter feedback here]
Hi
You've listed the options for Workspace Key and Workspace ID and several items related to the proxy. However what are the key word to turn the proxy option on?
Thanking you in advance

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 00a00a3e-a0df-7ee5-4733-7231bd7a024f
Version Independent ID: 94361683-e1e7-7e55-6993-86d3c2486a14
Content: Connect Windows computers to Azure Monitor - Azure Monitor
Content Source: articles/azure-monitor/platform/agent-windows.md
Service: azure-monitor
Sub-service: logs
GitHub Login: @bwren
Microsoft Alias: bwren

@megatc101 Thanks for your comment. We are actively investigating and will get back to you shortly.

Hello
I have an update for you.
Selecting the PROXY_URL command line option automatically enables the "Use
Proxy Server" option.  However this only works for a new installation of
the Microsoft Monitoring Agent.  I'm attempting to upgrade the agent and at
the same time amend the configuration options so that the server sends
event log data to OMS, via an OMS Gateway.  When attempting to do this via
SCCM the agent is upgraded but none of the OMS configuration options are
applied.
This is probably not your remit, but it would be good to get this fix as we
potentially have a lot of servers that we want to use with OMS.
Regards
On Thu, 18 Jun 2020 at 05:16, SwathiDhanwada-MSFT<EMAIL_ADDRESS>wrote:

@megatc101 https://github.com/megatc101 Thanks for your comment. We are
actively investigating and will get back to you shortly.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/57312#issuecomment-645761422,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AENIXBKHUJ3SBRORFJHRBETRXGIJFANCNFSM4OBCZ5KA
.

@megatc101 Thanks for the information. I am not sure whether you have checked this document which articulates the information about updating the agent and also configuring the proxy settings.
To set configuration settings for multiple servers, I would suggest you to take advantage of Azure Automation DSC. For more information, kindly refer this documentation.
Hope this helps!!

@megatc101 We will close the issue for now. If there are further questions , please revert and we will be glad to assist you.


Revert "feat: Add CRD charts as a dependency"

Reverts aws/karpenter#3260
We'll have to reopen this when the image repository is public

Hi @spring1843 , would you consider applying again this PR ? I would find it useful for installation with argoCD. Currently we mays forget to manually apply the new CRDs, leading to bugs.

This may help: https://gallery.ecr.aws/karpenter/karpenter-crd


raw crashes micro - v2.0.13

Description of the problem or steps to reproduce
open a new micro instance
launch commandbar
type raw and hit enter
after roughly one second, micro crashes with the below message
╭ octoshrimpy in ~/projects/
└❱ m
Micro encountered an error: runtime.errorString runtime error: invalid memory address or nil pointer dereference
runtime/panic.go:261 (0x55a999a7a898)
runtime/panic.go:260 (0x55a999a7a866)
github.com/zyedidia/micro/v2/internal/action/rawpane.go:37 (0x55a999ee4737)
github.com/zyedidia/micro/v2/internal/action/tab.go:269 (0x55a999ee5e9e)
github.com/zyedidia/micro/v2/internal/action/tab.go:139 (0x55a999ee5448)
github.com/zyedidia/micro/v2/cmd/micro/micro.go:476 (0x55a999f1d1e5)
github.com/zyedidia/micro/v2/cmd/micro/micro.go:394 (0x55a999f1ca8c)
runtime/internal/atomic/types.go:194 (0x55a999a66172)
runtime/asm_amd64.s:1650 (0x55a999a976e1)

If you can reproduce this error, please report it at https://github.com/zyedidia/micro/issues

Specifications
╭ octoshrimpy in ~/projects/
└❱ m --version
Version: 2.0.13
Commit hash: 68d88b57
Compiled on October 22, 2023

OS: endeavourOS (arch), inside and outside tmux
Terminal: alacritty, kitty, konsole, xterm, wezterm (all have same result)

#2991 is related, however I have a single tab, and my buffer is empty

It is very likely that it's the same issue as #2991, just triggered in a different way. So you may try compiling micro with the PR #2992 and see if it fixes the problem.
FWIW, I've just compiled v2.0.13 but couldn't reproduce the crash the way you described (i.e. just run the raw command). I'm not very surprised, an issue like #2991 may occur in various unexpected cases, and also may be highly dependent on the user environment, configuration etc.

Closed with #2992.
In case it is still reproducible afterwards we can simply re-open it. :)


Update?

Still working on this?

Hi milezzz,
Yes, I'm still working on it (on my local)
and it'll complete on this Monday (Mon 8 august 2016)

Sweet, I hope I can be first to test it for you =)

Thank you :)
but just let you know, it just layout by this week

Sounds good, I'll be waiting. Probably some of us can help with some of the features you are after.

Hi milezzz,
Apologize me for my under-estimation.
There are many components more than I thought,
anyway I will keep working on it until it's done.
11.33 PM - Mon 8/8/2016

Yeah I hear you...many things to consider.  I have been playing some others but they're on different platforms.
Q:  Were you planning on offering medium style front-end submissions? This might be the biggest challenge.

Hi milezzz, glad to see you around.
Yes, you are right.
I create this repository cause my passion and challenging myself.
So, normally I working on this repository when I have free time (but I will make it done indeed).
Last, did you have any plan about this repository
(study / using this project / using some part / or something else) ?
If you are here for some reason, so I can invest more time into it :star:
and maybe I  can provide rough estimate for you.
*note - yea, that repo is super GREAT!

Hi @milezzz, how do you do ?
It might be late already.
I just finish version 1.0.3 of this theme in a few days ago, may be you would like to check it out.
FYI

wordpress.org might take ~5 months before first review
repository to show theme layout: https://github.com/jojoee/mediumm-template
review ticket: https://themes.trac.wordpress.org/ticket/41990.


Include SuperH4 support

Is your feature request related to a problem? Please describe.
Support for the SH-4 is mentioned in the documentation @ Assembler as having Platinum quality, but I can't seem to find any way to import SuperH4 binaries.
Describe the solution you'd like
Support for SuperH4:BE:32:default and SuperH4:LE:32:default included in Ghidra

It can easily be added be yourself or someone who knows the ISA, unfortunately I'vent played around with SuperH since 2006 and even back then I didn't know much about it.
But you can look at how another RISC architecture is implemented and go from there. Personally I'd suggest using PPC as the basis.

Any news on this? Clearly there is some support for SH-4 considering that it is listed as 'platinum' quality. This could be really useful for me.

Planned for release in 9.1.

Just to clarify, the current PR is SH-1, SH-2, SH-2A, and SH-2E as is.  The goal is likely to get the core SuperH in and then additional PRs for SH-3/SH-4/SH-4A/DSP/etc... or was that getting added on your side?

It will be added into the ghidra repo in the next week or so.  After that, there may need to be a merging of the two.  The SH4 wasn't ready to me merged at the time of initial release.  I hadn't realized there was as much overlap in the SH1/2/3/4 encoding and instructions until a cursory review of the sh1/2.

Planned for release in 9.1.

Do you have any idea when 9.1 will be out?
Thanks!

A 9.1 beta build is planned soon.  Most features have been merged into main.  The SH4 will be merged in within the next few days.

I guess you are referring to PR https://github.com/NationalSecurityAgency/ghidra/issues/37, @emteere (doesn't seem to include SH4 refs though)? Or are there any other (internal?) branches to be aware of? I also happen to be very interested on SH4 right now.

Will you folks push a compiled release out with this support enabled? https://ghidra-sre.org is still back on 9.0.4

@ArcadeHustle Just compile it yourself with this: https://github.com/dukebarman/ghidra-builder

Thanks!


graph/simple: add node indegree outdegree functions for graph implementations

What are you trying to do?

using indegree := g.Indegree(id) instand of g.To(id).Len()
using outdegree := g.Outdegree(id) instand of g.From(id).Len()
for g.To or g.From copy node data, it's slow .
What did you try?

g.To(id).Len()
or
g.From(id).Len()
How does Gonum not allow you to achieve your goal?
It's slow for big data.
g.To or g.From copy node data,but I don't use this data.
What version of Go and Gonum are you using?

go version go1.14.1 linux/amd64
gonum.org/v1/gonum v0.7.0
Is this feature absent from the current master?
no
Are you able to help contribute the feature?

yes
func (g *DirectedGraph) Indegree(id int64) int {
	return len(g.to[id])
}

func (g *DirectedGraph) Outdegree(id int64) int {
	return len(g.from[id])
}

I don't think we will add this. The implementation of g.From().Len() and g.To().Len() is not fixed, and while it's true that currently these operations allocate for each no in the set, this is not necessarily true (an implementation change that is planned is to optimise this).
The graph implementations are starting points that satisfy the graph interfaces. You are welcome to copy the code and add this method, but making use of the method it not likely to be something that the gonum graph routines will do.
Can you give an example where this impacts on your work?

Please see #1347.

I don't think we will add this. The implementation of g.From().Len() and g.To().Len() is not fixed, and while it's true that currently these operations allocate for each no in the set, this is not necessarily true (an implementation change that is planned is to optimise this).
The graph implementations are starting points that satisfy the graph interfaces. You are welcome to copy the code and add this method, but making use of the method it not likely to be something that the gonum graph routines will do.
Can you give an example where this impacts on your work?

Hi ,
Thank you very much.
I'm trying to rewrite the stanford'snap code to go. It's in c++ and python except go.
I'm trying to follow this example  https://github.com/snap-stanford/snap/tree/master/examples/cascadegen
when debuging my code, I find it's more slow than the c++'s snap cascadegen.
I 'm trying to find out the reason.
In this line,
https://github.com/snap-stanford/snap/blob/master/snap-core/casc.cpp#L155
My go version code using gonum's graph , is slower than snap's version.
so, I'm here to request a faster Indegree function.

OK. So in the first instance, I would jut copy the code we have and use that with your modifications. This is a perfectly reasonable approach and part of the design intention with the simple/multi graph implementations. In the longer term, I'll get to issue I just filed (and later the unsafe version that will be a little faster).

OK. So in the first instance, I would jut copy the code we have and use that with your modifications. This is a perfectly reasonable approach and part of the design intention with the simple/multi graph implementations. In the longer term, I'll get to issue I just filed (and later the unsafe version that will be a little faster).

OK, Thank you very much.

I have implemented the lazy iterators. This is in https://github.com/gonum/gonum/tree/graph/lazy-nodes if you want to try it.

@kortschak  I will try it now. Thank you,Sir.

Thanks


cl generation script

About the PR

Media

:cl: DEATHB4DEFEAT

add: Added fun!
tweak: Tweaked fun!
fix: Fixed fun!
remove: Removed fun!

Works, need to get it to run on merge though. This will be harder to test.


Memfixes

Fixes for issues flagged by Dr.Memory and the MSVC static analysis tool, along with a few misc code hygiene improvements

Thx :)


Capture API calls not working?

Trying this in sandbox with some dummy test accounts setup in sandbox. Setting capture_now: true in 'authorize_on_billing_agreement' does not seem to actually charge the card. I get an email confirming that the payment method was successfully setup. But dont actually see anything charged. No transactions show up in the sandbox 'Manage transactions' view either. Also tried making a separate call to capture, but still dont see anything charged or anything show up in transactions page in the Sandbox view.  Is there something I am missing here?
thanks for your help!

Found the issue. Have it working in Sandbox.
thanks!


Update xml-config-file.md

@dstrome  - Will likely need some assistance in the proper formatting of the XML table.  We added the following XML values to the reference XML and to the table.
   &
AutoExitMeetingEnabled  &  ZoomMeetingsEnabled
Thanks!

@JohanFreelancer9 Copy editing is needed for this PR. Thanks.

@dstrome PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


b1

PR
Author
Editor
Reviewers
Assignment
Approval
Merge

#3
@pazner
@pazner
@jandrej
11/25/21
12/16/21
⌛due 12/24/21

This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch.

Merged in next for testing...

Re-merged in next for testing...


Yup Lazy schema is not accepted as revolver parameter

Describe the bug
When passing yup.Lazy object as a parameter to yupResolver it gives us error that we are not passing expected type as a parameter.
To Reproduce
Please check code sandbox, it's a type error not runtime one.
Codesandbox link (Required)
https://codesandbox.io/s/weathered-snowflake-wj71vi?file=/src/logic.ts
Expected behavior
Passing yup.Lazy should not generate any type issues.
Screenshots

I'm also facing this issue, is there any update or workaround?

I'm also running in to this. In my case, I have a schema that is concatinated with another one under certain condition. I use 'lazy' to wrap this conditional logic. When I pass the lazy schema into the resolver, conditional validation works as intendent but Typescript is complaining like @Mrowa96 mentioned.
Codesandbox example
https://codesandbox.io/p/sandbox/yupresolver-lazy-inference-nrmgz6

Released in 3.3.0


STORM-3720 get correct results for BlobStoreFile getModTime()

What is the purpose of the change
If we call getModTime() multiple times before and after a blobstore file changes, we will get an incorrect timestamp.
How was the change tested
Built storm.  Ran HdfsBlobStoreImplTest.

I did not see any issue given how we are using it.  But if the code changed, it seems like we could get unexpected results from calling this multiple times.


Allow per-mode implementations for commands

Resolves: #215
How to Test
An example command for Comment.nvim comment toggling:
require('legendary').command({
  ':Comment',
  {
    n = 'gcc',
    v = 'gc',
  },
  description = 'Toggle comment',
})

Testing for Regressions
I have tested the following:

[x] Triggering keymaps from legendary.nvim in all modes (normal, insert, visual)
[x] Creating keymaps via legendary.nvim, then triggering via the keymap in all modes (normal, insert, visual)
[x] Triggering commands from legendary.nvim in all modes (normal, insert, visual)
[x] Creating commands via legendary.nvim, then running the command manually from the command line
[x] augroup/autocmds created through legendary.nvim work correctly

@olimorris I think I saw some stuff in your dotfiles that can be simplified using this new syntax.

This is really nice! Have migrated a mapping already.
One behavioural thing I've noticed is that I opt to put most new functionality into a command as opposed to a mapping. This is because the ease at which I can open up Legendary and find the command is so great. Interested if you're the same?


fix: keep scroll level

Now scroll level is in the router state even on comment click
Resolves #1827

What does this pull request aim to achieve? 💯
Please be concise and link any related issue(s):

[x] I have checked that no one else is working on similar changes.
[x] I have read the latest README and understand the development workflow.
[x] The name of this branch is: feature/<branch_name>, or hotfix/<branch_name> if this is a hotfix, where <branch_name> briefly describes the issue(s) resolved and is prefixed with the issue number(s) (e.g. 1127-1130-update-git-branching-model). The branch is created in a cloned version of this repo, not a forked repo.
[x] This branch is rebased/merged with the latest staging (or the latest production if it is a hotfix).
[x] There are no merge conflicts.
[x] There are no console warnings and errors.
[x] On the right hand side of this PR, I have linked the appropriate issue(s) under "Issues" and added a project progress under "Projects".
[x] The title describes the issue(s) being addressed using format: <issue_numbers> - <brief_issue_description> (e.g. #1127/#1130 - Update Git Branching Model)

@joshmorel , @Zaydme , @rabbi08 ,
can I have your comments & approvements? so we can close this PR. 😀

One final thing before merging this, Can we add a condition in the loadPosts function here.
try {
      const {
        data: { data: posts, meta },
      } = await axios.get(endpoint);
...

to not fetch posts at all if postsInState exsists, so this one unnecessary request is not made.

@OzkanAbdullahoglu @Zaydme
Can I build URL or should I need to test on #1709?

There is no build URL, but I tested locally and it works as expected. Even when you go to post page by clicking on comment.

Oh then I can't test that... I don't have laptop to test on local as of now.

One final thing before merging this, Can we add a condition in the loadPosts function here.
try {
      const {
        data: { data: posts, meta },
      } = await axios.get(endpoint);
...

to not fetch posts at all if postsInState exsists, so this one unnecessary request is not made.

Good point, I am looking  into this.

@Zaydme as we discussed I will open a different PR to prevent initial fetch in case we have postsInState. I just did a small logical revision.
@rabbi08 will you able to perform a test for this PR?

@Zaydme as we discussed I will open a different PR to prevent initial fetch in case we have postsInState. I just did a small logical revision.
@rabbi08 will you able to perform a test for this PR?

@OzkanAbdullahoglu
Yes plz, I can. Kindly share build URL.

@rabbi08 can you test locally? This doesn't have a build URL.

@rabbi08 can you test locally? This doesn't have a build URL.

I need time for that :)

@rabbi08 can you test locally? This doesn't have a build URL.

I need time for that :)

That's fine. ok , let me try on local.

@OzkanAbdullahoglu @Zaydme
I have limited time on desktop and I messed with my docker, its not working. So, please go ahead and merge into STG. we can verify there. Thanks.


Solved issue #101

Wrong answer in Learn Spelling Template because of the fact that Autocomplete option in most devices adds spaces to the end of the word.. Thus resulting in wrong answer since Apple(Space) is not equal to Apple.
Thats all the matter of removing leading spaces in EditText of Template of Learn Spellings Template!!

Don't add app.iml, and other project files that are generally ignored by present gitignore configuration. Please update it and resolve merge conflict.

Fixed and closed via 1f8047643546703f62e7e9485b0431f422cd27bc


Dont add line clamp, if column id is not defined

Changes
Added validation if column id is present before checking for Cell property. If column has no id, we cannot know about the Cell property. As a result, not adding line clamp styling.
Updated the column id check to use instance.columns instead of props.column. This ensures that columns always have ids (react-table generates a backup id if the user-specified column object does not have one).
This fixes an issue where a column with a Cell but without an id wasn't being detected properly.
Testing
Added unit test;
TODO: validate in storybook, failing local build for now.
Docs
N/A

🚀 This is released in 3.14.2, thanks for the PR!


Added robotiq gazebo simulation

Includes:
Full interface to the programmer in simulation which is the same as the real interface to the robot.
launch script to visualize it
It compiles with catkin
Works on ROS Hydro and ROS Groovy
Works in gazebo 1.9
Works in RViz
Allows the user to send commands to open and close gripper in simulation with full underactuation and coupling. This was extrapolated from the drcsim package and made standalone. I'm using it here on the https://github.com/g/grizzly_ur10 project. It does not have a MoveIt interface yet (e.g a trajectory client), but that should be easy to build on from this or use alongside an arm with MoveIt

To use:
clone that branch and use groovy-devel
catkin_make it
roslaunch robotiq_s_model_articulated_gazebo robotiq_gripper_empty_world.launch
Gripper should spawn.
To pinch the gripper :
rostopic pub --once right_hand/command robotiq_s_model_articulated_msgs/SModelRobotOutput {1,1,1,0,0,0,255,255,0,155,0,0,255,0,0,0,0,0}
Should be pinched in simulation.

Hi @TheDash, thanks for this. I've added some in-line comments for this PR.
The (re-)licensing thing is something we need to figure out I think. @shaun-edwards?
Also: could you please squash your commit history a bit? There's only so many 'sigh', 'fixed things' and 'stuff' commits we can allow in this repository ;).

O, one more thing: I understand this was used in the drcsim, which has the concept of left and right hands (them being attached to Atlas and all). Do we perhaps want to remove that from this package (and the Gazebo plugins)? And make it work with any prefix?

We could do that. The purpose of this was to demonstrate that it now works,
so I'm happy with what's here. I'll have a read through the code review and
see what I can fix up.
On Jan 18, 2015 6:38 AM, "G.A. vd. Hoorn"<EMAIL_ADDRESS>wrote:

O, one more thing: I understand this was used in the drcsim, which has the
concept of left and right hands (them being attached to Atlas and all). Do
we perhaps want to remove that from this package (and the Gazebo plugins)?
And make it work with any prefix?
—
Reply to this email directly or view it on GitHub
https://github.com/ros-industrial/robotiq/pull/17#issuecomment-70400565.

I hadn't paid attention to any licensing, whatever's there is the default
from catkin-create-pkg.
On Jan 18, 2015 6:36 AM, "G.A. vd. Hoorn"<EMAIL_ADDRESS>wrote:

Hi @TheDash https://github.com/TheDash, thanks for this. I've added
some in-line comments for this PR.
The (re-)licensing thing is something we need to figure out I think.
@shaun-edwards https://github.com/shaun-edwards?
Also: could you please squash your commit history a bit? There's only so
many 'sigh', 'fixed things' and 'stuff' commits we can allow in this
repository ;).
—
Reply to this email directly or view it on GitHub
https://github.com/ros-industrial/robotiq/pull/17#issuecomment-70400528.

Do you know how to properly do a squash/renaming of commits? Every time I do it it adds a stack of N commits based on what was edited but the old history still remains

@TheDash wrote:

Do you know how to properly do a squash/renaming of commits? Every time I do it it adds a stack of N commits based on what was edited but the old history still remains

I'm not sure I understand what you're saying, but regarding squashing: there are many ways, but I guess if you haven't done it before using git rebase -i HEAD~N (where N is the number of commits to squash) is the most understandable. See the manual on git-rebase - INTERACTIVE MODE. Just make sure you replace the pick in front of the commits you want to squash with squash (or s). The rest should be obvious.
You can always first try it out in a different branch if you'd like.

I used git rebase -i HEAD~35, and before that my commit count was at 61, afterwards, it went up to 95, and just repeated the 61 through 35 commits ontop of the 61, to make the 95 through 61 the same as 61 through 35.
As well, tried Googling around to fix that, but found no advice on the matter. I attempted using "reword" instead of "squash" to fixup the misnamed commits, alas, it ran into the same matter of stacking 35 commits ontop rather than modifying the existing commits

Lots of discussion ;)  @TheDash, we are implementing our own two arm/hand robot.  Perhaps we should talk (offline).

Sure, send me an email<EMAIL_ADDRESS>

@TheDash: I've recently sent you an email on your gmail address. Does that still reach you?

Hm, did not receive it<EMAIL_ADDRESS>or<EMAIL_ADDRESS>On Thu, Jan 22, 2015 at 9:09 AM, G.A. vd. Hoorn<EMAIL_ADDRESS>wrote:

@TheDash https://github.com/TheDash: I've recently sent you an email on
your gmail address. Does that still reach you?
—
Reply to this email directly or view it on GitHub
https://github.com/ros-industrial/robotiq/pull/17#issuecomment-71024967.

--
Devon Ash
View Devon Ash's profile

@gavanderhoorn wrote:

[..] sent you an email on your gmail address [..]

:)

Okie doke. I squashed everything into 2 logical commits. 1 that encapsulates the additions specified in this PR. Secondly, the clean-up work necessary for this PR.
Hope this is all!

Not everything has been addressed, but most of that is out-of-scope for this PR, and issues have been logged. So +1 from me for these changes.
@TheDash: thanks for fixing things. And for the contribution obviously.

O, just to be clear: I have only performed a 'static review'. I have not had a chance to check out these packages on my Hydro/Indigo systems.

Ok, I have tested this on a Hydro system only. if you could check Indigo
that would be great.
On Thu, Jan 22, 2015 at 12:06 PM, G.A. vd. Hoorn<EMAIL_ADDRESS>wrote:

O, just to be clear: I have only performed a 'static review'. I have not
had a chance to check out these packages on my Hydro/Indigo systems.
—
Reply to this email directly or view it on GitHub
https://github.com/ros-industrial/robotiq/pull/17#issuecomment-71056417.

--
Devon Ash
View Devon Ash's profile

Is there anything else holding up the merge?

@TheDash: I haven't done any runtime testing, but apart from that, I think this can be merged. Any outstanding issues can be addressed in future PRs.
Btw: I can't merge this. @shaun-edwards?

Ping?

Ping ping? @shaun-edwards

Not to pass the buck...but @nicolaslauzier can you verify the model name is what you want?  We changed another package name to account for robotiq's model naming.  +1 from me.  @nicolaslauzier feel free to merge as well.

Thanks @nicolaslauzier and @gavanderhoorn et al. It was a pleasure working with you.

@TheDash My pleasure! By the way, do not hesitate to contact us if you come up with new contributions or projects that would need to be advertised. Our blog writers are always looking for new stuff to discuss, even if it's not related to our grippers.

Excellent :-) I will take you up on that offer in the future @nicolaslauzier
On Wed, Feb 4, 2015 at 4:22 PM, nicolaslauzier<EMAIL_ADDRESS>wrote:

@TheDash https://github.com/TheDash My pleasure! By the way, do not
hesitate to contact us if you come up with new contributions or projects
that would need to be advertised. Our blog writers are always looking for
new stuff to discuss, even if it's not related to our grippers.
—
Reply to this email directly or view it on GitHub
https://github.com/ros-industrial/robotiq/pull/17#issuecomment-72942152.

--
Devon Ash
View Devon Ash's profile


login page added, delete fix, optimized the code

Hello @Shobhit-pandey , thank you for your contribution. I tried testing the changes you made. It was missing a login template for auth_views.login . I have added the login.html inside templates/registration and its working fine now. I will merge your Pull Request.

Sorry, I forget to add login.html in git.
On Tue, May 5, 2020 at 12:38 PM Shubham Kumar<EMAIL_ADDRESS>wrote:

Hello @Shobhit-pandey https://github.com/Shobhit-pandey , thank you for
your contribution. I tried testing the changes you made. It was missing a
login template for auth_views.login . I have added the login.html inside
templates/registration and its working fine now. I will merge your Pull
Request.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/shubhamkumar27/WIFI_based_RFID_attendance-system_using_NodeMcu_and_Django/pull/1#issuecomment-623890423,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFDEA3RKLJJSG6U354J56FDRP63OXANCNFSM4MY56B3A
.

For reference, here is my login.html code.
Login  {% csrf_token %} {{ form.as_p }} Login
On Tue, May 5, 2020 at 8:45 PM Shobhit Pandey<EMAIL_ADDRESS>wrote:

Sorry, I forget to add login.html in git.
On Tue, May 5, 2020 at 12:38 PM Shubham Kumar<EMAIL_ADDRESS>wrote:

Hello @Shobhit-pandey https://github.com/Shobhit-pandey , thank you
for your contribution. I tried testing the changes you made. It was missing
a login template for auth_views.login . I have added the login.html inside
templates/registration and its working fine now. I will merge your Pull
Request.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/shubhamkumar27/WIFI_based_RFID_attendance-system_using_NodeMcu_and_Django/pull/1#issuecomment-623890423,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFDEA3RKLJJSG6U354J56FDRP63OXANCNFSM4MY56B3A
.


Artifactory Ansible installation fails on service config creation

Is this a request for help?:
No

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT
Which installer:
Ansible; collection 1.1.2 (latest)
Which product and version:
Artifactory  7.12.5
Verified (and reproduced the same way) also on 7.10.2 which is listed as certified in README.md
OS: Ubuntu 18.04
What happened:
Ansible fails at jfrog.installers.artifactory : create artifactory service task:
... REDACTED FOR BREVITY...

TASK [jfrog.installers.postgres : install postgres configuration] **************
[WARNING]: Using world-readable permissions for temporary files Ansible needs
to create when becoming an unprivileged user. This may be insecure. For
information on securing this, see
https://docs.ansible.com/ansible/user_guide/become.html#risks-of-becoming-an-
unprivileged-user
changed: [artifactory.ourdomain.io] => (item=pg_hba.conf)
changed: [artifactory.ourdomain.io] => (item=postgresql.conf)

TASK [jfrog.installers.postgres : enable postgres service] *********************
ok: [artifactory.ourdomain.io]

TASK [jfrog.installers.postgres : Hold until Postgresql is up and running] *****
ok: [artifactory.ourdomain.io]

TASK [jfrog.installers.postgres : Create users] ********************************
[WARNING]: Using world-readable permissions for temporary files Ansible needs
to create when becoming an unprivileged user. This may be insecure. For
information on securing this, see
https://docs.ansible.com/ansible/user_guide/become.html#risks-of-becoming-an-
unprivileged-user
changed: [artifactory.ourdomain.io] => (item=None)
changed: [artifactory.ourdomain.io]

TASK [jfrog.installers.postgres : Create a database] ***************************

TASK [jfrog.installers.postgres : Grant privs on db] ***************************

TASK [jfrog.installers.postgres : restart postgres] ****************************
changed: [artifactory.ourdomain.io]

TASK [jfrog.installers.postgres : debug] ***************************************
ok: [artifactory.ourdomain.io] => {
    "msg": "Restarted postgres service<EMAIL_ADDRESS>}

TASK [include_role : jfrog.installers.artifactory] *****************************

TASK [jfrog.installers.artifactory : Check to see if artifactory has a service and stop it] ***
fatal: [artifactory.ourdomain.io]: FAILED! => {"changed": false, "msg": "Could not find the requested service artifactory: host"}

TASK [jfrog.installers.artifactory : Check to see if artifactory has a service and stop it] ***
fatal: [artifactory.ourdomain.io]: FAILED! => {"changed": false, "msg": "Could not find the requested service artifactory: host"}

TASK [jfrog.installers.artifactory : perform installation] *********************
included: /Users/waldekm/git/auto/galaxy-roles/ansible_collections/jfrog/installers/roles/artifactory/tasks/install.yml for artifactory.ourdomain.io

TASK [jfrog.installers.artifactory : debug] ************************************
ok: [artifactory.ourdomain.io] => {
    "msg": "Performing installation of Artifactory..."
}

TASK [install nginx] ***********************************************************

TASK [jfrog.installers.artifactory_nginx : debug] ******************************
ok: [artifactory.ourdomain.io] => {
    "msg": "Attempting nginx installation without dependencies for potential offline mode."
 DONE\nCreating Group artifactory...already exists... DONE\nModifying environment file /opt/jfrog/artifactory/app/bin/artifactory.default... DONE\n\u001b[33m** INFO: Please create/edit system.yaml file in /opt/jfrog/artifactory/var/etc to set the correct environment\u001b[0m\n\u001b[33m         Templates with information can be found in the same directory\u001b[0m\nInitializing artifactory.service service with systemctl... DONE\nRemoving old custom drivers : /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_*\nCopying /opt/jfrog/artifactory/var/bootstrap/artifactory/tomcat/lib/postgresql-42.2.18.jar to /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_postgresql-42.2.18.jar\nCopying /opt/jfrog/artifactory/var/bootstrap/artifactory/tomcat/lib/README.md to /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_README.md\n\nSetting file permissions...\nChecking permissions on /opt/jfrog/artifactory/var\n/opt/jfrog/artifactory/var is already owned by artifactory:artifactory.\n\u001b[38;5;197m[ERROR\u001b[0m\u001b[38;5;197m] \u001b[0mFailed to set create shared.user with artifactory in /opt/jfrog/artifactory/var/etc/system.yaml, \\ncommand used : /opt/jfrog/artifactory/app/bin/../third-party/yq/yq w -i \"/opt/jfrog/artifactory/var/etc/system.yaml\" \"shared.user\" \"artifactory\"", "stdout_lines": ["", "Installing artifactory as a Unix service that will run as user artifactory and group artifactory", "Installing artifactory with home /opt/jfrog/artifactory/app", "Creating user artifactory...already exists... DONE", "Creating Group artifactory...already exists... DONE", "Modifying environment file /opt/jfrog/artifactory/app/bin/artifactory.default... DONE", "\u001b[33m** INFO: Please create/edit system.yaml file in /opt/jfrog/artifactory/var/etc to set the correct environment\u001b[0m", "\u001b[33m         Templates with information can be found in the same directory\u001b[0m", "Initializing artifactory.service service with systemctl... DONE", "Removing old custom drivers : /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_*", "Copying /opt/jfrog/artifactory/var/bootstrap/artifactory/tomcat/lib/postgresql-42.2.18.jar to /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_postgresql-42.2.18.jar", "Copying /opt/jfrog/artifactory/var/bootstrap/artifactory/tomcat/lib/README.md to /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_README.md", "", "Setting file permissions...", "Checking permissions on /opt/jfrog/artifactory/var", "/opt/jfrog/artifactory/var is already owned by artifactory:artifactory.", "\u001b[38;5;197m[ERROR\u001b[0m\u001b[38;5;197m] \u001b[0mFailed to set create shared.user with artifactory in /opt/jfrog/artifactory/var/etc/system.yaml, \\ncommand used : /opt/jfrog/artifactory/app/bin/../third-party/yq/yq w -i \"/opt/jfrog/artifactory/var/etc/system.yaml\" \"shared.user\" \"artifactory\""]}

PLAY RECAP *********************************************************************
artifactory.ourdomain.io : ok=50   changed=31   unreachable=0    failed=2    skipped=51   rescued=1    ignored=0

What you expected to happen:
Ansible succesfully installing the unit file and moving on with installation.
How to reproduce it (as minimally and precisely as possible):
Standard playbook based on
https://github.com/jfrog/JFrog-Cloud-Installers/blob/master/Ansible/examples/playbook-rt.yml
Ran against a Ubuntu 18.04.5 LTS VM.
- name: Install and configure Artifactory
  hosts: artifactory_test
  become: true
  tasks:
    - include_role:
        name: jfrog.installers.postgres
    - include_role:
        name: jfrog.installers.artifactory

Additional group vars (in artifactory_test.yml)

# postgres role:
db_users:
  - db_user: "artifactory"
    db_password: "mypassword"

# artifactory role:
server_name: "{{ ansible_fqdn }}"
artifactory_version: 7.10.2

artifactory_is_primary: true
db_download_url: "https://jdbc.postgresql.org/download/postgresql-42.2.18.jar"
db_type: "postgresql"
db_driver: "org.postgresql.Driver"
db_url: "jdbc:postgresql://localhost:5432/artifactory"
db_user: "artifactory"
db_password: "mypassword"

Anything else we need to know:
I did some investigation and looking at this task:
https://github.com/jfrog/JFrog-Cloud-Installers/blob/9929016ae7abbd292206435df7abf771d32812b2/Ansible/ansible_collections/jfrog/installers/roles/artifactory/tasks/install.yml#L200
has shown me it's running /opt/jfrog/artifactory/app/bin/installService.sh script.
I executed it manually and the output is as follows:
root@artifactory:/opt/jfrog/artifactory/app/bin# ./installService.sh

Installing artifactory as a Unix service that will run as user artifactory and group artifactory
Installing artifactory with home /opt/jfrog/artifactory/app
Creating user artifactory...already exists... DONE
Creating Group artifactory...already exists... DONE
Modifying environment file /opt/jfrog/artifactory/app/bin/artifactory.default... DONE
** INFO: Please create/edit system.yaml file in /opt/jfrog/artifactory/var/etc to set the correct environment
         Templates with information can be found in the same directory
Stopping the artifactory service...
Initializing artifactory.service service with systemctl... DONE
Removing old custom drivers : /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_postgresql-42.2.18.jar /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_README.md
Copying /opt/jfrog/artifactory/var/bootstrap/artifactory/tomcat/lib/postgresql-42.2.18.jar to /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_postgresql-42.2.18.jar
Copying /opt/jfrog/artifactory/var/bootstrap/artifactory/tomcat/lib/README.md to /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_README.md

Setting file permissions...
Checking permissions on /opt/jfrog/artifactory/var
/opt/jfrog/artifactory/var is already owned by artifactory:artifactory.
[ERROR] Failed to set create shared.user with artifactory in /opt/jfrog/artifactory/var/etc/system.yaml, \ncommand used : /opt/jfrog/artifactory/app/bin/../third-party/yq/yq w -i "/opt/jfrog/artifactory/var/etc/system.yaml" "shared.user" "artifactory"
root@artifactory:/opt/jfrog/artifactory/app/bin#

Content of this file afterwards is:
root@artifactory:/opt/jfrog/artifactory/app/bin# ls -al /opt/jfrog/artifactory/var/etc/system.yaml
-rw-r--r-- 1 root root 1314 Jan  7 11:25 /opt/jfrog/artifactory/var/etc/system.yaml
root@artifactory:/opt/jfrog/artifactory/app/bin# cat /opt/jfrog/artifactory/var/etc/system.yaml
## @formatter:off
## JFROG ARTIFACTORY SYSTEM CONFIGURATION FILE
## HOW TO USE: comment-out any field and keep the correct yaml indentation by deleting only the leading '#' character.
configVersion: 1

## NOTE: JFROG_HOME is a place holder for the JFrog root directory containing the deployed product, the home directory for all JFrog products.
## Replace JFROG_HOME with the real path! For example, in RPM install, JFROG_HOME=/opt/jfrog

## NOTE: Sensitive information such as passwords and join key are encrypted on first read.
## NOTE: The provided commented key and value is the default.

## SHARED CONFIGURATIONS
## A shared section for keys across all services in this config
shared:

  ## Node Settings
  node:
    ## A unique id to identify this node.
    ## Default: auto generated at startup.
    id: c679d8c16d38498c9598c8e8c84ba759

    ## Sets this node as primary in HA installation
    primary: True

    ## Sets this node as part of HA installation
    haEnabled: True

  ## Database Configuration
  database:
    ## One of: mysql, oracle, mssql, postgresql, mariadb
    ## Default: Embedded derby

    ## Example for mysql/postgresql
    type: "postgresql"
driver: "org.postgresql.Driver"
     url: "jdbc:postgresql://localhost:5432/artifactory"
     username: "artifactory"
password: "mypassword"

Note the invalid indentation of the lines driver and password in the Yaml file.

One more observation:
Running Yamllint over the system.yaml file gives me the following findings:
root@artifactory:~# yamllint /opt/jfrog/artifactory/var/etc/system.yaml
/opt/jfrog/artifactory/var/etc/system.yaml
  3:81      error    line too long (118 > 80 characters)  (line-length)
  4:1       warning  missing document start "---"  (document-start)
  6:81      error    line too long (142 > 80 characters)  (line-length)
  7:81      error    line too long (92 > 80 characters)  (line-length)
  9:81      error    line too long (90 > 80 characters)  (line-length)
  23:14     warning  truthy value is not quoted  (truthy)
  26:16     warning  truthy value is not quoted  (truthy)
  36:6      error    syntax error: expected <block end>, but found '<block mapping start>'
  38:23     error    no new line character at the end of file  (new-line-at-end-of-file)

One more observation:
Running Yamllint over the system.yaml file gives me the following findings:
root@artifactory:~# yamllint /opt/jfrog/artifactory/var/etc/system.yaml
/opt/jfrog/artifactory/var/etc/system.yaml
  3:81      error    line too long (118 > 80 characters)  (line-length)
  4:1       warning  missing document start "---"  (document-start)
  6:81      error    line too long (142 > 80 characters)  (line-length)
  7:81      error    line too long (92 > 80 characters)  (line-length)
  9:81      error    line too long (90 > 80 characters)  (line-length)
  23:14     warning  truthy value is not quoted  (truthy)
  26:16     warning  truthy value is not quoted  (truthy)
  36:6      error    syntax error: expected <block end>, but found '<block mapping start>'
  38:23     error    no new line character at the end of file  (new-line-at-end-of-file)

Confirmation: error is indeed caused by malformed system.yaml content
Fixing indentation let me proceed:
root@artifactory:/opt/jfrog/artifactory/app/bin# ./installService.sh

Installing artifactory as a Unix service that will run as user artifactory and group artifactory
Installing artifactory with home /opt/jfrog/artifactory/app
Creating user artifactory...already exists... DONE
Creating Group artifactory...already exists... DONE
Modifying environment file /opt/jfrog/artifactory/app/bin/artifactory.default... DONE
** INFO: Please create/edit system.yaml file in /opt/jfrog/artifactory/var/etc to set the correct environment
         Templates with information can be found in the same directory
Stopping the artifactory service...
Initializing artifactory.service service with systemctl... DONE
Removing old custom drivers : /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_postgresql-42.2.18.jar /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_README.md
Copying /opt/jfrog/artifactory/var/bootstrap/artifactory/tomcat/lib/postgresql-42.2.18.jar to /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_postgresql-42.2.18.jar
Copying /opt/jfrog/artifactory/var/bootstrap/artifactory/tomcat/lib/README.md to /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_README.md

Setting file permissions...
Checking permissions on /opt/jfrog/artifactory/var
/opt/jfrog/artifactory/var is already owned by artifactory:artifactory.

************ SUCCESS ****************
Installation of Artifactory completed

Start Artifactory with:
> systemctl start artifactory.service

Check Artifactory status with:
> systemctl status artifactory.service

Logs can be found under /opt/jfrog/artifactory/var/log
System configuration templates can be found under /opt/jfrog/artifactory/var/etc
Copy any configuration you want to modify from the template to /opt/jfrog/artifactory/var/etc/system.yaml

I believe the bug might be hiding here - the Jinja2 indentation markers might be a bit off:
https://github.com/jfrog/JFrog-Cloud-Installers/blob/9929016ae7abbd292206435df7abf771d32812b2/Ansible/ansible_collections/jfrog/installers/roles/artifactory/templates/system.yaml.j2#L35

Confirmation: error is indeed caused by malformed system.yaml content
Fixing indentation let me proceed:
root@artifactory:/opt/jfrog/artifactory/app/bin# ./installService.sh

Installing artifactory as a Unix service that will run as user artifactory and group artifactory
Installing artifactory with home /opt/jfrog/artifactory/app
Creating user artifactory...already exists... DONE
Creating Group artifactory...already exists... DONE
Modifying environment file /opt/jfrog/artifactory/app/bin/artifactory.default... DONE
** INFO: Please create/edit system.yaml file in /opt/jfrog/artifactory/var/etc to set the correct environment
         Templates with information can be found in the same directory
Stopping the artifactory service...
Initializing artifactory.service service with systemctl... DONE
Removing old custom drivers : /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_postgresql-42.2.18.jar /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_README.md
Copying /opt/jfrog/artifactory/var/bootstrap/artifactory/tomcat/lib/postgresql-42.2.18.jar to /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_postgresql-42.2.18.jar
Copying /opt/jfrog/artifactory/var/bootstrap/artifactory/tomcat/lib/README.md to /opt/jfrog/artifactory/app/artifactory/tomcat/lib/jf_README.md

Setting file permissions...
Checking permissions on /opt/jfrog/artifactory/var
/opt/jfrog/artifactory/var is already owned by artifactory:artifactory.

************ SUCCESS ****************
Installation of Artifactory completed

Start Artifactory with:
> systemctl start artifactory.service

Check Artifactory status with:
> systemctl status artifactory.service

Logs can be found under /opt/jfrog/artifactory/var/log
System configuration templates can be found under /opt/jfrog/artifactory/var/etc
Copy any configuration you want to modify from the template to /opt/jfrog/artifactory/var/etc/system.yaml

I believe the bug might be hiding here - the Jinja2 indentation markers might be a bit off:
https://github.com/jfrog/JFrog-Cloud-Installers/blob/9929016ae7abbd292206435df7abf771d32812b2/Ansible/ansible_collections/jfrog/installers/roles/artifactory/templates/system.yaml.j2#L35

I managed to work around it by overriding artifactory_system_yaml_template: artifactory_system.yaml.j2 and using a fixed template as follows:
$ diff  galaxy-roles/ansible_collections/jfrog/installers/roles/artifactory/templates/system.yaml.j2 playbooks/templates/artifactory_system.yaml.j2
3a4
>
35c36
< {%+ if db_type == 'derby' -%}
---
> {%+ if db_type == 'derby' %}
39,44c40,45
< {%+ else -%}
<      driver: "{{ db_driver }}"
<      url: "{{ db_url }}"
<      username: "{{ db_user }}"
< {%+ endif -%}
<     password: "{{ db_password }}"
\ No newline at end of file
---
> {%+ else %}
>     driver: "{{ db_driver }}"
>     url: "{{ db_url }}"
>     username: "{{ db_user }}"
> {%+ endif %}
>     password: "{{ db_password }}"

Caveat: I've not tested it with derby db :)

I managed to work around it by overriding artifactory_system_yaml_template: artifactory_system.yaml.j2 and using a fixed template as follows:
$ diff  galaxy-roles/ansible_collections/jfrog/installers/roles/artifactory/templates/system.yaml.j2 playbooks/templates/artifactory_system.yaml.j2
3a4
>
35c36
< {%+ if db_type == 'derby' -%}
---
> {%+ if db_type == 'derby' %}
39,44c40,45
< {%+ else -%}
<      driver: "{{ db_driver }}"
<      url: "{{ db_url }}"
<      username: "{{ db_user }}"
< {%+ endif -%}
<     password: "{{ db_password }}"
\ No newline at end of file
---
> {%+ else %}
>     driver: "{{ db_driver }}"
>     url: "{{ db_url }}"
>     username: "{{ db_user }}"
> {%+ endif %}
>     password: "{{ db_password }}"

Caveat: I've not tested it with derby db :)

@weakcamel  we plan to support  by default external postgresql only (not derby) . So derby code in systemyaml will be removed in upcoming releases

@weakcamel  we plan to support  by default external postgresql only (not derby) . So derby code in systemyaml will be removed in upcoming releases


URLs being read as comments

Anything after https:// is being treated as a comment an not as a url, by this I mean that the content of url is being formatted as a comment.

Hi, is it fixed?


Re-add example-bots.json

Fix local dev currently broken due to example-bot.json reference in examples/medplum-chart-demo/src/pages/UploadDataPage.tsx

HI @Bjornkjohnson , thanks for flagging this!
I've just opened up this pr with some guidance on how to fix. This example-bots.json file is actually dynamically generated by the build:bots script, so running this first should solve the problem