How to deal with domain ontology grouping classes that are parents to CORE classes, e.g. PCO organismal entity

PCO includes 'organismal entity' A material entity that is one or more organisms, viruses or viroids.
should this be in core? cc @ramonawalls
If not, then note that pco would not conform to guidelines in that it would contain classes that do not have superclasses in core. perhaps we could have a getout clause - e.g. domain ontologies can still contain grouping classes if they are equivalent to an expression (e.g. a union) all of whose member classes are subclasses of core classes?

There should be a 'get out clause' for grouping terms. There were similar
concerns about 'chemical entity'. Ideally we should ask ontologies to label
such classes as 'grouping terms'?
On Wed, Jul 31, 2019 at 4:54 PM Chris Mungall<EMAIL_ADDRESS>wrote:

PCO includes 'organismal entity' A material entity that is one or more
organisms, viruses or viroids.
should this be in core? cc @ramonawalls https://github.com/ramonawalls
If not, then note that pco would not conform to guidelines in that it
would contain classes that do not have superclasses in core. perhaps we
could have a getout clause - e.g. domain ontologies can still contain
grouping classes if they are equivalent to an expression (e.g. a union) all
of whose member classes are subclasses of core classes?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=ADJX2IVI7YS5Q3VYUZTTCC3QCH3XVA5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HCVJ3HA,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADJX2IX7NZS3XEAZC6QBVS3QCH3XVANCNFSM4IIKPIBQ
.

--
Bjoern Peters
Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters

Seems reasonable, but lets think this through.
If PCO deems this to be a useful grouping, and being the domain experts in this area, does this warrant further discussion (in this specific case, and the general case).
Furthermore, let's say others want to have this grouping in their own ontology. We are back to a complicate MIREOT situation. In fact it's a bit harder than before: if I want OE in my ontology, then I need to:

import OBO CORE
MIREOT or extract the OE class from PCO
MIREOT or extract the two PCO subClassOf axioms, O is-a OE, PoO is-a OE

Note that 3 doesn't come for free with 2 due to the fact this is 'above' rather than 'below'.
I could instead MIREOT or extract the explicit subclasses from PCO, but this also gets awkward, and wouldn't work if we use a pco-base module and PCO uses core IDs for O and PoO.
All of this could be fixed with the right engineering, but it just seems a bad smell. I worry that putting classes 'above' core could have other side effects.
I don't know what the solution is. If we accept everyone's groupings, then CORE becomes very latticey and less minimalist.
it should be noted here also that mereological groupings are problematic for reasoning in ways class groupings are not.
I do think we want to limit above-CORE groupings as much as possible, although banning in domain ontologies would be too draconian. We could first start by obtaining a list of such groupings as an informative measure before making any recommendations

Uberon/CARO: anatomical entity (encompasses multiple scales, and both M/IM)
PCO: organismal entity
GO: cellular component
probably more...

My statement was based on the assumption (which I still think is true) that
specific domain ontologies would like to introduce groupings, but others
would rarely want to re-use these. And better yet: If grouping classes
above the core will essentially be 'union statements' then equivalence
between them can be easily asserted.
On Thu, Aug 1, 2019 at 8:42 PM Chris Mungall<EMAIL_ADDRESS>wrote:

Seems reasonable, but lets think this through.
If PCO deems this to be a useful grouping, and being the domain experts in
this area, does this warrant further discussion (in this specific case, and
the general case).
Furthermore, let's say others want to have this grouping in their own
ontology. We are back to a complicate MIREOT situation. In fact it's a bit
harder than before: if I want OE in my ontology, then I need to:

import OBO CORE
MIREOT or extract the OE class from PCO
MIREOT or extract the two PCO subClassOf axioms, O is-a OE, PoO
is-a OE

Note that 3 doesn't come for free with 2 due to the fact this is 'above'
rather than 'below'.
I could instead MIREOT or extract the explicit subclasses from PCO, but
this also gets awkward, and wouldn't work if we use a pco-base module and
PCO uses core IDs for O and PoO.
All of this could be fixed with the right engineering, but it just seems a
bad smell. I worry that putting classes 'above' core could have other side
effects.
I don't know what the solution is. If we accept everyone's groupings, then
CORE becomes very latticey and less minimalist.
it should be noted here also that mereological groupings are problematic
for reasoning in ways class groupings are not.
I do think we want to limit above-CORE groupings as much as possible,
although banning in domain ontologies would be too draconian. We could
first start by obtaining a list of such groupings as an informative measure
before making any recommendations

Uberon/CARO: anatomical entity (encompasses multiple scales, and
both M/IM)
PCO: organismal entity
GO: cellular component
probably more...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=ADJX2ISGTSJOJWMFBADMT7TQCN7H3A5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3MIFCA#issuecomment-517505672,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADJX2IVW3OGGGSGQ6JA2SN3QCN7H3ANCNFSM4IIKPIBQ
.

--
Bjoern Peters
Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters

Just a little history - the PCO grouping class was meant to align with the CARO upper union class - folks often need the union of the parent nodes in NCBI Taxon. I think in this context, it might make sense to have this grouping class in the CORE as a superclass of what we've decided for Organism? see #6
We don't want to end up with multiple ontologies creating this same class, especially since its been there all along.
We could also try to get NCBI to make a union parent class?

The name 'organismal entity' is confusing, but this isn't the same as the
caro class, this is the union of organism and population
On Sat, Aug 3, 2019 at 7:05 AM Melissa Haendel<EMAIL_ADDRESS>wrote:

Just a little history - the PCO grouping class was meant to align with the
CARO upper union class - folks often need the union of the parent nodes in
NCBI Taxon. I think in this context, it might make sense to have this
grouping class in the CORE as a superclass of what we've decided for
Organism? see #6
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/6
We don't want to end up with multiple ontologies creating this same class,
especially since its been there all along.
We could also try to get NCBI to make a union parent class?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=AAAMMOPSM7WXLBLGT4LZYHLQCWGDPA5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3PPBZI#issuecomment-517927141,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAMMOMQXLLDRIQZ4JJ2DJ3QCWGDPANCNFSM4IIKPIBQ
.

Thanks for clarifying Chris, that is what I understood. I think both that
label and the concept of having a union of organism and population is
confusing. For example, I can't think of many useful properties that are
shared between these two classes, and not by other material entities. If an
ontology wants this purely for grouping purposes, that is fine, but it
really doesn't help at all for the OBO-Core purposes of making it easy for
users to know where there classes should go, but would rather add to the
confusion. Given that Melissa misread this is a case in point for that. So
I really don't think we should worry about this or other grouping terms
(e.g. CHEBI chemical entity), which can be nice for some ontologies for
browsing, but are in my opinion an obstacle when we include them in the
Core.
On Sun, Aug 4, 2019 at 8:01 AM Chris Mungall<EMAIL_ADDRESS>wrote:

The name 'organismal entity' is confusing, but this isn't the same as the
caro class, this is the union of organism and population
On Sat, Aug 3, 2019 at 7:05 AM Melissa Haendel<EMAIL_ADDRESS>wrote:

Just a little history - the PCO grouping class was meant to align with
the
CARO upper union class - folks often need the union of the parent nodes
in
NCBI Taxon. I think in this context, it might make sense to have this
grouping class in the CORE as a superclass of what we've decided for
Organism? see #6
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/6
We don't want to end up with multiple ontologies creating this same
class,
especially since its been there all along.
We could also try to get NCBI to make a union parent class?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=AAAMMOPSM7WXLBLGT4LZYHLQCWGDPA5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3PPBZI#issuecomment-517927141
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAAMMOMQXLLDRIQZ4JJ2DJ3QCWGDPANCNFSM4IIKPIBQ
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=ADJX2IQOR2VZCM77N3XOKRDQC3VOLA5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QDPNI#issuecomment-518010805,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADJX2IU3F2KMQLHFCH67OXDQC3VOLANCNFSM4IIKPIBQ
.

--
Bjoern Peters
Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters

I think a good deciding principle could be that any class that we can only
define as the union of subclasses, while the subclasses can be reasonably
well defined individually should be very suspect to be added to the core.
On Sun, Aug 4, 2019 at 8:28 AM Bjoern Peters<EMAIL_ADDRESS>wrote:

Thanks for clarifying Chris, that is what I understood. I think both that
label and the concept of having a union of organism and population is
confusing. For example, I can't think of many useful properties that are
shared between these two classes, and not by other material entities. If an
ontology wants this purely for grouping purposes, that is fine, but it
really doesn't help at all for the OBO-Core purposes of making it easy for
users to know where there classes should go, but would rather add to the
confusion. Given that Melissa misread this is a case in point for that. So
I really don't think we should worry about this or other grouping terms
(e.g. CHEBI chemical entity), which can be nice for some ontologies for
browsing, but are in my opinion an obstacle when we include them in the
Core.
On Sun, Aug 4, 2019 at 8:01 AM Chris Mungall<EMAIL_ADDRESS>wrote:

The name 'organismal entity' is confusing, but this isn't the same as the
caro class, this is the union of organism and population
On Sat, Aug 3, 2019 at 7:05 AM Melissa Haendel<EMAIL_ADDRESS>wrote:

Just a little history - the PCO grouping class was meant to align with
the
CARO upper union class - folks often need the union of the parent nodes
in
NCBI Taxon. I think in this context, it might make sense to have this
grouping class in the CORE as a superclass of what we've decided for
Organism? see #6
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/6
We don't want to end up with multiple ontologies creating this same
class,
especially since its been there all along.
We could also try to get NCBI to make a union parent class?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=AAAMMOPSM7WXLBLGT4LZYHLQCWGDPA5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3PPBZI#issuecomment-517927141
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAAMMOMQXLLDRIQZ4JJ2DJ3QCWGDPANCNFSM4IIKPIBQ
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=ADJX2IQOR2VZCM77N3XOKRDQC3VOLA5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QDPNI#issuecomment-518010805,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADJX2IU3F2KMQLHFCH67OXDQC3VOLANCNFSM4IIKPIBQ
.

--
Bjoern Peters
Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters

--
Bjoern Peters
Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters

+1
On Sun, Aug 4, 2019 at 11:50 AM bpeters42<EMAIL_ADDRESS>wrote:

I think a good deciding principle could be that any class that we can only
define as the union of subclasses, while the subclasses can be reasonably
well defined individually should be very suspect to be added to the core.
On Sun, Aug 4, 2019 at 8:28 AM Bjoern Peters<EMAIL_ADDRESS>wrote:

Thanks for clarifying Chris, that is what I understood. I think both that
label and the concept of having a union of organism and population is
confusing. For example, I can't think of many useful properties that are
shared between these two classes, and not by other material entities. If
an
ontology wants this purely for grouping purposes, that is fine, but it
really doesn't help at all for the OBO-Core purposes of making it easy
for
users to know where there classes should go, but would rather add to the
confusion. Given that Melissa misread this is a case in point for that.
So
I really don't think we should worry about this or other grouping terms
(e.g. CHEBI chemical entity), which can be nice for some ontologies for
browsing, but are in my opinion an obstacle when we include them in the
Core.
On Sun, Aug 4, 2019 at 8:01 AM Chris Mungall<EMAIL_ADDRESS>wrote:

The name 'organismal entity' is confusing, but this isn't the same as
the
caro class, this is the union of organism and population
On Sat, Aug 3, 2019 at 7:05 AM Melissa Haendel <
<EMAIL_ADDRESS>wrote:

Just a little history - the PCO grouping class was meant to align with
the
CARO upper union class - folks often need the union of the parent
nodes
in
NCBI Taxon. I think in this context, it might make sense to have this
grouping class in the CORE as a superclass of what we've decided for
Organism? see #6
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/6
We don't want to end up with multiple ontologies creating this same
class,
especially since its been there all along.
We could also try to get NCBI to make a union parent class?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=AAAMMOPSM7WXLBLGT4LZYHLQCWGDPA5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3PPBZI#issuecomment-517927141

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAAMMOMQXLLDRIQZ4JJ2DJ3QCWGDPANCNFSM4IIKPIBQ

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=ADJX2IQOR2VZCM77N3XOKRDQC3VOLA5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QDPNI#issuecomment-518010805
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ADJX2IU3F2KMQLHFCH67OXDQC3VOLANCNFSM4IIKPIBQ

.

--
Bjoern Peters
Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters

--
Bjoern Peters
Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=AAJR55X47DHHQK222DQZLXTQC33DFA5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QELVI#issuecomment-518014421,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJR55R4BK2W3RISETQKNL3QC33DFANCNFSM4IIKPIBQ
.

Allow me to bang on about this a bit more as I think this is an interesting
specific case, and it's good to for discussing more general cases.
Agreed that the label is confusing.

I can't think of many useful properties that are shared between these two
classes,

I slightly disagree here. E.g looking at evolution of genomes on the
individual vs population level.
Also from a pragmatic ontology engineering point of view: there is a
general problem here with mereological sum classes. The limit case of 1
member is really awkward. Either you allow sums/sets of size one (which can
be conceptually weird, but makes a lot of mathematical sense), which in
this case would mean Os are subclasses of PoO; or you say minimum of size
2, introducing a mathematical disjunction and limiting the ability to talk
about sets that are inclusive of single individuals without introducing a
grouping class.
All solutions are sucky here (basically because we have set theory
operating at two levels), which is why I think it's a good idea to avoid
mereological sum classes. Populations of organisms are obviously an
exception here as it's such a crucial scientific concept (I use the C word
advisedly).
Anyway, the more general point here is that while I am partially
sympathetic to arguments for inclusion of this and other grouping classes,
I am extremely skeptical of the notion that this is only locally useful
to the needs of PCO or one particular ontology.
Also I can't emphasize enough as someone who has spent countless hours
debugging horrible import chains from poorly modularized ontologies with
cyclic imports and stale mireots and patchwork bridges, people
superclassing core creates a lot of engineering headaches.
On Sun, Aug 4, 2019 at 8:29 AM bpeters42<EMAIL_ADDRESS>wrote:

Thanks for clarifying Chris, that is what I understood. I think both that
label and the concept of having a union of organism and population is
confusing. For example, I can't think of many useful properties that are
shared between these two classes, and not by other material entities. If an
ontology wants this purely for grouping purposes, that is fine, but it
really doesn't help at all for the OBO-Core purposes of making it easy for
users to know where there classes should go, but would rather add to the
confusion. Given that Melissa misread this is a case in point for that. So
I really don't think we should worry about this or other grouping terms
(e.g. CHEBI chemical entity), which can be nice for some ontologies for
browsing, but are in my opinion an obstacle when we include them in the
Core.
On Sun, Aug 4, 2019 at 8:01 AM Chris Mungall<EMAIL_ADDRESS>wrote:

The name 'organismal entity' is confusing, but this isn't the same as the
caro class, this is the union of organism and population
On Sat, Aug 3, 2019 at 7:05 AM Melissa Haendel<EMAIL_ADDRESS>wrote:

Just a little history - the PCO grouping class was meant to align with
the
CARO upper union class - folks often need the union of the parent nodes
in
NCBI Taxon. I think in this context, it might make sense to have this
grouping class in the CORE as a superclass of what we've decided for
Organism? see #6
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/6
We don't want to end up with multiple ontologies creating this same
class,
especially since its been there all along.
We could also try to get NCBI to make a union parent class?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=AAAMMOPSM7WXLBLGT4LZYHLQCWGDPA5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3PPBZI#issuecomment-517927141

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAAMMOMQXLLDRIQZ4JJ2DJ3QCWGDPANCNFSM4IIKPIBQ

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=ADJX2IQOR2VZCM77N3XOKRDQC3VOLA5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QDPNI#issuecomment-518010805
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ADJX2IU3F2KMQLHFCH67OXDQC3VOLANCNFSM4IIKPIBQ
.

--
Bjoern Peters
Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=AAAMMOPGFYQYWQMYPZ4HZBLQC3YWBA5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QD7VY#issuecomment-518012887,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAMMONF7SCZ2WV5QLB44JLQC3YWBANCNFSM4IIKPIBQ
.

Responses inline
On Sun, Aug 4, 2019 at 12:05 PM Chris Mungall<EMAIL_ADDRESS>wrote:

Allow me to bang on about this a bit more as I think this is an interesting
specific case, and it's good to for discussing more general cases.
Agreed that the label is confusing.

I can't think of many useful properties that are shared between these two
classes,

I slightly disagree here. E.g looking at evolution of genomes on the
individual vs population level.

Can you be more specific? I thought this was a great example where there
should not be any shared properties, given that  evolution impacts a
population vs. an individual is dramatically different.

Also from a pragmatic ontology engineering point of view: there is a
general problem here with mereological sum classes. The limit case of 1
member is really awkward. Either you allow sums/sets of size one (which can
be conceptually weird, but makes a lot of mathematical sense), which in
this case would mean Os are subclasses of PoO; or you say minimum of size
2, introducing a mathematical disjunction and limiting the ability to talk
about sets that are inclusive of single individuals without introducing a
grouping class.
We are doing "2 or more vs.1" distinctions throughout, e.g. for the
distinction between a molecule and an atom. Given that we want to do a
single cross-granularity ontology, we have to draw borders somewhere, and I
thought these work better than anything else we have.

All solutions are sucky here (basically because we have set theory
operating at two levels), which is why I think it's a good idea to avoid
mereological sum classes. Populations of organisms are obviously an
exception here as it's such a crucial scientific concept (I use the C word
advisedly).
Anyway, the more general point here is that while I am partially
sympathetic to arguments for inclusion of this and other grouping classes,
I am extremely skeptical of the notion that this is only locally useful
to the needs of PCO or one particular ontology.
Either I don't understand the last paragraph, or maybe there is a typo /
word missing? did you mean 'arguments against inclusion'?

Also I can't emphasize enough as someone who has spent countless hours
debugging horrible import chains from poorly modularized ontologies with
cyclic imports and stale mireots and patchwork bridges, people
superclassing core creates a lot of engineering headaches.
On Sun, Aug 4, 2019 at 8:29 AM bpeters42<EMAIL_ADDRESS>wrote:

Thanks for clarifying Chris, that is what I understood. I think both that
label and the concept of having a union of organism and population is
confusing. For example, I can't think of many useful properties that are
shared between these two classes, and not by other material entities. If
an
ontology wants this purely for grouping purposes, that is fine, but it
really doesn't help at all for the OBO-Core purposes of making it easy
for
users to know where there classes should go, but would rather add to the
confusion. Given that Melissa misread this is a case in point for that.
So
I really don't think we should worry about this or other grouping terms
(e.g. CHEBI chemical entity), which can be nice for some ontologies for
browsing, but are in my opinion an obstacle when we include them in the
Core.
On Sun, Aug 4, 2019 at 8:01 AM Chris Mungall<EMAIL_ADDRESS>wrote:

The name 'organismal entity' is confusing, but this isn't the same as
the
caro class, this is the union of organism and population
On Sat, Aug 3, 2019 at 7:05 AM Melissa Haendel <
<EMAIL_ADDRESS>wrote:

Just a little history - the PCO grouping class was meant to align
with
the
CARO upper union class - folks often need the union of the parent
nodes
in
NCBI Taxon. I think in this context, it might make sense to have this
grouping class in the CORE as a superclass of what we've decided for
Organism? see #6
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/6
We don't want to end up with multiple ontologies creating this same
class,
especially since its been there all along.
We could also try to get NCBI to make a union parent class?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=AAAMMOPSM7WXLBLGT4LZYHLQCWGDPA5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3PPBZI#issuecomment-517927141

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/AAAMMOMQXLLDRIQZ4JJ2DJ3QCWGDPANCNFSM4IIKPIBQ

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<

https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=ADJX2IQOR2VZCM77N3XOKRDQC3VOLA5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QDPNI#issuecomment-518010805

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ADJX2IU3F2KMQLHFCH67OXDQC3VOLANCNFSM4IIKPIBQ

.

--
Bjoern Peters
Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=AAAMMOPGFYQYWQMYPZ4HZBLQC3YWBA5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QD7VY#issuecomment-518012887
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAAMMONF7SCZ2WV5QLB44JLQC3YWBANCNFSM4IIKPIBQ
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=ADJX2IWNBOBYFYNCTEH2BI3QC4R77A5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QHWUY#issuecomment-518028115,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADJX2ISFZIC6JDQQ6KPBU63QC4R77ANCNFSM4IIKPIBQ
.

--
Bjoern Peters
Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters

evolution of genomes of individuals vs populations: I don't have a
particularly strong argument here, there are of course differences, but
it's useful to treat both as genome-bearers.
N>1 vs 1: agreed that this is analogous to atom vs molecule. But we have
(or did have) a grouping here. So we have the benefits of lumping and
splitting here.

Anyway, the more general point here is that while I am partially

sympathetic to arguments for inclusion of this and other grouping
classes,
I am extremely skeptical of the notion that this is only locally useful
to the needs of PCO or one particular ontology.
Either I don't understand the last paragraph, or maybe there is a typo /
word missing? did you mean 'arguments against inclusion'?

No typo, but maybe I wasn't clear. Basically I don't find it satisfying to
say "you can keep the grouping class in PCO, but we won't have it in core".
Either it has some general utility in which case there is a strong argument
for having it in core, or its overall utility is minimal in which case
there is a strong argument for removing from PCO. If we trust an ontology
in a domain then we should trust its abstractions, and we should have as
few competing super-abstractions within OBO as possible.
I'm not arguing from any kind of absolutist position here, and maybe the
first step in any case is just to list the supercore classes in various
trusted ontologies and work from there.

I certainly can agree with the last point to: "just to list the supercore
classes in various trusted ontologies and work from there." Rather than
working in the abstract. I would also want to argue that this has much
lower priority than finishing defining the classes that were identified as
important for cross-ontology work.
On Sun, Aug 4, 2019 at 4:09 PM Chris Mungall<EMAIL_ADDRESS>wrote:

evolution of genomes of individuals vs populations: I don't have a
particularly strong argument here, there are of course differences, but
it's useful to treat both as genome-bearers.
N>1 vs 1: agreed that this is analogous to atom vs molecule. But we have
(or did have) a grouping here. So we have the benefits of lumping and
splitting here.

Anyway, the more general point here is that while I am partially

sympathetic to arguments for inclusion of this and other grouping
classes,
I am extremely skeptical of the notion that this is only locally
useful
to the needs of PCO or one particular ontology.
Either I don't understand the last paragraph, or maybe there is a typo
/
word missing? did you mean 'arguments against inclusion'?

No typo, but maybe I wasn't clear. Basically I don't find it satisfying to
say "you can keep the grouping class in PCO, but we won't have it in core".
Either it has some general utility in which case there is a strong argument
for having it in core, or its overall utility is minimal in which case
there is a strong argument for removing from PCO. If we trust an ontology
in a domain then we should trust its abstractions, and we should have as
few competing super-abstractions within OBO as possible.
I'm not arguing from any kind of absolutist position here, and maybe the
first step in any case is just to list the supercore classes in various
trusted ontologies and work from there.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/OBOFoundry/Experimental-OBO-Core/issues/37?email_source=notifications&email_token=ADJX2IWQRVHJNMEINQSAPG3QC5OSBA5CNFSM4IIKPIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QLQII#issuecomment-518043681,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADJX2IS32PWEEOOMQVPVDALQC5OSBANCNFSM4IIKPIBQ
.

--
Bjoern Peters
Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters

@ukemi also notes that this holds for GO cellular component

Sorry to be late to the game here. Perhaps some clarification of the history and use of this term will be helpful.

Organismal entity (OE) is just a union class in PCO. You will see this in the editors file (https://raw.githubusercontent.com/PopulationAndCommunityOntology/pco/master/src/ontology/pco-edit.owl). Of course, when we run the reasoner for release, it asserts the subclass axioms. I guess this is the case for most grouping classes in OBO ontologies. Does this provide a potential solution? Could PCO just import organism and collection of organisms from CORE and create the union class? I'm not sure how much that solves.

OE is not the union of organism, virus, or viroid and population of organisms, but rather the union of organism, virus, or viroid and collection of organisms. I want us to get in the habit of not referring to general collections as populations, because they aren't, either in the statistical or biological sense.

OE was first created as a parent class for household, which might be one person or multiple people. There are many use cases that need to refer to single organism or multiple organisms, and it is really convenient for us to keep this union class. Sure, we could just include the union statement in every definition, but who wants to do that.

Darwin Core has a class "Organism" which is defined as "A particular organism or defined group of organisms considered to be taxonomically homogeneous." As mush as I dislike the DwC class, it has a purpose. BCO needs to deal with the DwC class, and OE makes the perfect parent class for it.

Regarding the discussion about sets and whether they can have only one element, I don't have a philosophical position on it. I just need to be able to talk about three types of entities: those that are one organism, those that are collections of two or more organisms, and those that can be either.

I don't have a strong opinion on whether or not OE should go into the core, as long as we can keep it in PCO and continue to use it BCO.


There is a bug for PagedList

I am sure it's bug for get item start and end.
here is your code:
ItemStart = PageIndex * PageSize + 1;  ItemEnd = Math.Min(PageIndex * PageSize + PageSize, TotalItemCount);
If I just have 10 items, pageindex:1, pagesize:10,
Item-Start should be 1 not 11.

With 10 items and PageSize 10, PageIndex should be 0.


Bombardment (Game on Java)

Hey guys i made a game on Java a while back please check and merge if it fits your criteria thank you :)

I have checked your code and merged it . It would be a really good practice to make a README file for your game . It helps new users and contributors understand what your game is about . Try to make one . Thank you :)

Thank you.I will surely add a readme file.


Receive payjoin

Request + receive payjoin v2. This basic functionality requires no changes to mutiny-web because it only changes the presented bip21 uri to include a &pj= endpoint. This change does NOT yet include v2 sending, but was tested using the payjoin-cli in the the payjoin v2 pdk implementation
In order to become a production feature some changes must be considered:
Fetch Oblivious HTTP Configuration
This implementation hard codes the payjoin relay's ohttp gateway's configuration (ciphersuite and keys). This information ought to be fetched by mutiny and served over https. If a mutiny client asks for this information directly without proxy then their IP address would be revealed to the payjoin relay, which OHTTP otherwise protects.  It could also be configured by the Mutiny client but that adds complexity and assumes the client takes steps to protect their IP address in an independent fetch.
Display &ohttp= gateway configuration in bip21 uri
By including the ohttp gateway configuration in the bip21 uri, the sender can immediately connect to the payjoin server without fetching the configuration and potentially leaking their IP. This parameter should be included in waila.
It could also be hacked into the pj endpoint as a query parameter, but is information for the sender wallet, not to be passed as query to payjoin relay, and is better suited to a bip21 parameter.
Run Oblivious HTTP Relay
Mutiny should run a basic HTTP proxy to relay OHTTP requests from client to payjoin relay. If this relay were run by the same party as the payjoin relay, then that party would have enough information to correlate specific payjoin peer pairs with IP addresses. This same server could be trusted to fetch ohttp configurations on behalf of mutiny clients. The worst Mutiny could do by failing to return proper ohttp configurations would be deny service, NOT disrupt privacy (Assuming the payjoin relay is available over https as a known entity run separately from the Mutiny OHTTP relay).
If this requirement is too costly, another service may be willing to operate an independent OHTTP relay for the sake of Mutiny clients.
Link a proper payjoin crate release
The payjoin dependency tested here varies slightly from that in the payjoin v2 implementation. That payjoin dependency even depends on a WIP ohttp crate. These all must be published on crates.io for a production release.

I'm curious what ohttp adoption is looking like

Oblivious HTTP is still a draft, but is implemented in Chrome, Firefox, Cloudflare and Apple operating systems. It is used for Oblivious DNS over HTTP with a relay deployed by Fastly.

and what information is gained by running one? I guess the assumption would be that the ohttp proxy and the service are not the same people and not colluding? What, if any, information gained by the payjoin server or ohttp proxy? Trying to think through what it makes sense to host or have others host that we link to in app.

OHTTP relies on 2 distinct servers. The OHTTP Relay Resource sees the client IP and the OHTTP Gateway Resource target IP, behind which the target resource may be accessed. The OHTTP Relay sees an encrypted ohttp-req message. It does NOT see the contents of the message.
The OHTTP Gateway sees that the request came from the OHTTP Relay IP, and may decrypt the contents of the request: a second layer of e2ee between sender and receiver and the pubkey associated with that session (a pseudonymous subdirectory identifier for the session)
The threat model in the BIP assumes they do not collude. If they do collude, they may correlate the subdirectory with sender and receiver IP addresses to discover only that 2 IP addresses may have communicated with one another at the Payjoin relay subdirectory at a given time.

Would users be able to select their own ohttp proxy and their own payjoin servers? Ideally we don't have to host or hard code it in order for it to work, though potentially willing to if it makes sense.

I would suggest users don't select their own proxy for the initial rollout for three reasons.

Dependency compatibility: OHTTP's specified Hybrid Pub Key Encryption HMAC-based Extract-and-Expand Key Derivation Function does not support the secp256k1 curve. I've specified a change which uses secp256k1 so that bitcoin software does not need any external crypto in order to use payjoin v2. Secp256k1, sha256, and chacha20poly1305 are all already part of the bitcoin stack and secure for the purposes of such a protocol. There is a formal process to get secp256k1 into the spec Key Encapsulation Mechanisms via IANA and potentially the browsers/operating systems. However, the spec does not prevent us from building working software today.
UX: Any external relay would need to support secp256k1 or potentially be incompatible with a payjoin peer. Any draft spec external  OHTTP Relay will not support secp256k1 at time of writing. A Payjoin Relay relied on an OHTTP Gateway configuration using only curves other than secp256k1, which is guaranteed to be available in bitcoin software, some payjoin-enabled wallets may not be able to communicate with them.
Privacy: Mutiny clients already reveal their IP address to Mutiny and don't need to reveal it to another service. There is also an anonymity set benefit of having as many users using the same OHTTP relay as possible.

By running an OHTTP relay, could anyone use that to connect to any other OHTTP gateway? I'm guessing the relay would see what IP is connecting to what gateway, but could there be multiple services behind any given gateway?

By running an OHTTP relay, could anyone use that to connect to any other OHTTP gateway?

In section 8.2: "The relay will only forward for Oblivious Gateway Resources that it has explicitly configured and allowed."

I'm guessing the relay would see what IP is connecting to what gateway, but could there be multiple services behind any given gateway?

Yes, and specific path, query, methods, request body, headers are all encrypted from the ohttp relay's view

Okay thank you, this is very helpful. Just trying to understand the operational side of OHTTP and whether we should stand one up. Regardless of who runs what, I like the approach and the code is clean and makes sense. Appreciate the work there!

FYI standing up a relay is as simple as adding a couple blocks to nginx if you're already running it somewhere
http {
    # HTTP Server Block
    server {
        listen 80;
        server_name your-server-name.com;

        location /ohttp-relay {
            # Forward requests to the OHTTP Gateway
            proxy_pass https://ohttp-gateway.example.com;

            # Clear the X-Real-IP header
            proxy_set_header X-Real-IP "";
            # Make default proxy_pass behavior explicit for good measure

            access_log /path/to/http-access.log;
            error_log /path/to/http-error.log;
        }
    }

    # HTTPS Server Block
    server {
        listen 443 ssl;
        server_name your-server-name.com;

        ssl_certificate /path/to/your/certificate.crt;
        ssl_certificate_key /path/to/your/private.key;

        location /ohttp-relay {
            # Forward requests to the OHTTP Gateway
            proxy_pass https://ohttp-gateway.example.com;

            # Clear the X-Real-IP header
            proxy_set_header X-Real-IP "";
            # Make default proxy_pass behavior explicit for good measure

            access_log /path/to/https-access.log;
            error_log /path/to/https-error.log;
        }
    }
}

This should now be receiving v2 payjoins, however the persistence and asynchronous completion is still a bit janky in this form factor. It does not seem like resume_payjoins is properly resuming sessions on startup.
We've also got to consider how to display pending payjoin in activity. It seems like that UI list is only considering broadcasted transactions and pending lightning payments at the moment. This introduces a new tx pending state where a PSBT has been signed and posted to a payjoin directory but not yet responded to (from a sender) or responded to but not yet broadcast by the sender (for a receiver).
I think v2 payjoin receivers who sign should show transactions pending, since only 1 step remains before the transaction is broadcast, and they've effectively been probed and revealed their utxo. v2 Senders perhaps should not treat a single signature as pending, since they both need to have receiver sign and check the result, at least until BDK allows us to lock UTXOs. Still, a sender in this state could have their original psbt broadcast by a receiver. I'll have to look into how you're handling pending lightning payments to become inspired with a solution regarding pending payjoins.

I think it's valid to consider it as pending in the UI. I think we just do a filter on ActivityItems before returning it. We may have to save these in our DB for it to reflect state accurately.

This is now based on the payjoin-0.13.0 release, persists receive payjoin sessions, and adds pending transactions to the wallet using insert_tx and cancel_tx before they hit mempool. Though tracked payjoins are not explicitly marked as such. Their PSBTs are just put in the ActivityItem::Onchain list.  One way to explicitly mark them as payjoin would be to manually construct payjoin TransactionDetails, add an is_payjoin field or similar, store them in MutinyStorage, and pull from that list in get_activity() if this solution seems incomplete.  This solution should work with the existing add_onchain_labels since it attaches labels to addresses.
For now, the way the receiver here gets payjoin directory's ohttp-keys does reveal IP address to the directory but that will be solved with the next deployment of ohttp-relay @teemie1
This would require the addition of &ohttp= bip21 param parsing, ideally in bitcoin-waila, for ui support.

While I've left a few TODOs that are in progress, this change is ready for deeper review

Sorry for the delay on this.
I want to be transparent, that we're pretty unsure about what we want to do with the on chain wallet long term. We're really not optimizing for on chain related activities and it has just caused various friction. Ideally long term we get to move towards something like splicing and can do splice outs for on chain payments, but until then, we've talked about removing the on chain wallet and defaulting to on chain going into a fedimint.
I've seen the discussions here which are great to see but would imagine it might be complex.


Rename NamedTupleLiteral#[] to NamedTupleLiteral#[]?

I have a macro-land array of NamedTupleLiteral, each representing a field of data to parse for a binary protocol (this is my usecase).
Here is an example:
MACRO_VAR__X_fields = [] of _

macro fixture_fields
  {% MACRO_VAR__X_fields << {type: :pad_bytes, by_n: 5} %}
  {% MACRO_VAR__X_fields << {type: :card16, name: "data_len", save: false} %}
  {% MACRO_VAR__X_fields << {type: :string, name: "important_data", save: true} %}
end

fixture_fields

Now I need to get all the fields that needs to be saved:
{% elems_to_save = MACRO_VAR__X_fields.select { |e| e.keys.includes?(:save.id) && e[:save] } %}

This works (https://carc.in/#/r/3o3w).
But with NamedTupleLiteral#[]?, this could be rewritten as:
{% elems_to_save = MACRO_VAR__X_fields.select { |e| e[:save]? } %}
# or even
{% elems_to_save = MACRO_VAR__X_fields.select &.[:save]? %}

Which feels way better, and simpler to understand.
It is currently missing, and I think it should be added! :smiley:
I can send a PR if you agree

Actually, I just realized that NamedTupleLiteral#[] is NamedTupleLiteral#[]?, so:
{% nt = {a: 1}; puts nt[:non_existant] %} # => nil

I think the documentation should be changed, or the macro method renamed to what it really is [] => []?.

Documentation should be fixed, but it makes no sense to rename to #[]? without having #[].

@jhass is right: methods are nilable by default in macros, unlike runtime methods that raise by default and may have a nilable alternative.
Close?

Close.


Strings with \ " are not escaped properly.

An example of some test code:
type StructWithEscapes struct {
	String   string `json:"str"`
	StringArray []string `json:"str-array"`
}

func Test_StructWithEscapes(t *testing.T) {
	es := StructWithEscapes{
		String: "one\\two\\,three\"",
		StringArray: []string{"one\\two", "three\\,four"},
	}

	wantJSON := `{"str":"one\\two\\,three\"","str-array":["one\\two","three\\,four"]}`

	var enc = NewStructEncoder(StructWithEscapes{})
	buf := NewBufferFromPool()
	enc.Marshal(&es, buf)
	resultJSON := buf.String()

	// Ensure JSON is valid.
	if !json.Valid([]byte(resultJSON)) {
		t.Errorf("Not valid JSON:" + resultJSON)
	}

	// Compare result
	if resultJSON != wantJSON {
		t.Errorf("Test_StructWithScapes Failed: want JSON:" + wantJSON + " got JSON:" + resultJSON)
	}
}

Strings with \ or " will produce incorrect JSON strings. Is there a way ptrStringToBuf or any higher level function can escape these properly?

Hi
Thank you for supplying the test for this.
#20 resolves this through via the addition of a new ,escape option for struct fields and jingo.EscapeString for use with slice encoders.

Hi
Thank you for supplying the test for this.
#20 resolves this through via the addition of a new ,escape option for struct fields and jingo.EscapeString for use with slice encoders.


Errors created without stack

What version of Ajv are you using? Does the issue happen if you use the latest version?
6.10.0 and yes.
It seems that Ajv creates subclasses of Error in an unusual way that leaves them without a stack. May I ask why a simple extend of the Error class was not used instead? It seems like there is a much better way of doing this that leaves the expected members intact.
This peculiarity adversely affected the Serverless Framework. I have opened an issue on their side to get them to check that the stack member exists before attempting to split() it, but this should still be remediated here, too, if possible.
https://github.com/epoberezkin/ajv/blob/ab841b462ec4baff37d2a7319cef13820b53d963/lib/compile/error_classes.js#L5-L15
Then further down:
https://github.com/epoberezkin/ajv/blob/ab841b462ec4baff37d2a7319cef13820b53d963/lib/compile/error_classes.js#L30-L34

This is the only backward compatible way to create a subclass - ES5 does not have another class extension mechanism (and the new ES6 syntax produces exactly the same result internally - "extends" links prototypes in the same way as the code you reference).
I've never seen the issues with stack traces in node or browser - it may be that your environment has the issue that it does not work with Error subclasses, regardless how they are created.
I suggest updating the code with ES6 syntax and checking if the issue remains - I expect it will.

I too noticed the absence of stack traces but only in ES6 environments. The code is transpiled using babel and I do see stack traces in IE11 (which I think counts as ES5) but not in Firefox or Chrome.

@silverwind thanks for confirming. It would definitely help if the issue remains if you move the code to ES6 (class syntax). I expect that the issue would remain for the reasons above - same internal structures used for class syntax. But it’s definitely worth checking if you need it addressed.

v7 uses ES6 classes


[Bug report] gravitino poms say to expect gradle modules but they are not published

Version
main branch
Describe what's wrong
Spotted in 0.7.0 (RC) and in 0.6.1.
https://repository.apache.org/content/groups/staging/org/apache/gravitino/meta/0.6.1-incubating/meta-0.6.1-incubating.pom
Says:
<!--  This module was also published with a richer model, Gradle metadata,   -->
<!--  which should be used instead. Do not delete the following line which   -->
<!--  is to indicate to Gradle or any Gradle module metadata file consumer   -->
<!--  that they should prefer consuming it instead.  -->
<!--  do_not_remove: published-with-gradle-metadata  -->

But the .module file is not published. This willl surely confuse Gradle builds that see this comment in the pom but then can't find the module file published alongside it.
https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html
Error message and/or stacktrace
n/a
How to reproduce
Gradle build
Additional context
No response

Let me fix this issue.


Authors aren't displayed anymore

I guess the culprit is here, but I don't know why :
https://github.com/quarkiverse/quarkus-roq/blob/main/theme/default/src/main/resources/templates/theme-layouts/roq-default/post.html#L46
I know the following does works :
{#let pageAuthor in page.data.author}
{#let author=(cdi:authors.get(pageAuthor))}
....

@jtama PR please?

Will do that.


Remove linear pool logic and types

double check with gareth for recovery exit ui

need a way to remove all pools from the DB that are connected to linear pools

#383


Backport/backport 2259 to 2.2

Adds feedback mechanism to 2.2
Checklist

[x ] By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and subject to the Developers Certificate of Origin.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

This PR has been replaced by the manual PR#2288


Update included EIPs list

Agreed to on https://github.com/ethereum/pm/issues/786

Codecov Report
Patch and project coverage have no change.

Comparison is base (c90ccbe) 74.06% compared to head (aa812f8) 74.06%.

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #792   +/-   ##
=======================================
  Coverage   74.06%   74.06%
=======================================
  Files         570      570
  Lines       31557    31557
=======================================
  Hits        23372    23372
  Misses       8185     8185

Flag
Coverage Δ

unittests
74.06% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


docs(README.md): add codecov.io badge

[skip ci]
Adds this codecov.io badge to the README:

Current coverage is 45.46% (diff: 100%)

Merging #100 into master will not change coverage

@@             master       #100   diff @@
==========================================
  Files            11         11
  Lines           618        618
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits            281        281
  Misses          290        290
  Partials         47         47

Powered by Codecov. Last update 2a368a7...25f5b32


Android ignores unicode soft hyphen (u00AD)

Description:
On android soft-hyphen unicode u00AD is ignored, neither the word break nor the hyphen are displayed correctly. Using u200B is a workaround for getting better word wrapping results but is still missing the hyphen.
React Native version:
System:
    OS: macOS 10.15.3
    CPU: (8) x64 Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
    Memory: 108.98 MB / 16.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 13.10.1 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.13.7 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  SDKs:
    iOS SDK:
      Platforms: iOS 13.2, DriverKit 19.0, macOS 10.15, tvOS 13.2, watchOS 6.1
    Android SDK:
      API Levels: 28, 29
      Build Tools: 28.0.3, 29.0.0, 29.0.1
      System Images: android-28 | Google Play Intel x86 Atom, android-29 | Intel x86 Atom_64
  IDEs:
    Android Studio: 3.6 AI-192.7<IP_ADDRESS>41897
    Xcode: 11.3.1/11C504 - /usr/bin/xcodebuild
  npmPackages:
    react: 16.12.0 => 16.12.0
    react-native: 0.61.5 => 0.61.5
  npmGlobalPackages:
    react-native-cli: 2.0.1

Steps To Reproduce
Render the following on android vs. iOS
const testString = 'sup\u00ADer\u00ADfrag\u00ADilis\u00ADtice\u00ADxpial\u00ADidocious'

return (
  <View>
    <Text style={{ width: 100 }}>
      {testString}
    </Text>
  </View>
);

Expected Results
Screenshot from iOS

Actual Result
Screenshot from Android

This makes it very hard / practically impossible to get proper when-needed hyphenation on Android. iOS works perfectly and is easy to make buttons that properly wrap the text only when needed.

What would the 'very hard' way be to get the hyphenation working on Android with this version of React Native? I'm experiencing the same bug...

Good question, you would need to build some kind of regex/matcher that checks for u200B followed by a new line and append "-" if it matches. Don't know if that is possible but it would be my first guess for a workaround.

seems to me that this is the default android behaviour https://stackoverflow.com/questions/4454911/hyphenation-in-android

That was my thought as well, however, I don't know of any method to check where the new line starts/old line breaks...

hyphenedText += line.text.substr(0, line.text.length - 1) + "- ";

With this solution I have some weird effects because the changed text (additional "- ") is triggering the onTextLayout again, which is performing changes again because the text has to change again ... in an endless loop 🔁

I'm checking for that as well.
if (line.text.substr(line.text.length - 2) === "- ") {
 alreadyHyphenated = true;
}

and I don't change the text again if alreadyHyphenated === true

It also sometimes brings the hyphenated word to the next line because the added dash pushes it over the edge. I'll have to think of a solution for that as well...

Yes, that's what I'm experiencing right now too. Almost all dashes are within the words because the new lines breaks are different after adding the dashes.

as we can read in this medium article it is possible on android thanks to setHyphenationFrequency
so I solved this in native code like this in ReactTextView.java:

I'll write a pull request to add a prop <Text androidHyphenationFrequency="normal" />

this functionality will be available with 0.64 https://github.com/react-native-community/releases/blob/20a632d3a61153f813c020ef2c6bca6910958a10/CHANGELOG.md Thanks :pray:

Can someone confirm here that this is working in react-native 0.64? because it is not working for me (tested with device > v23) cc @fabriziobertoglio1987

it doesn't work for me either.

@fabriziobertoglio1987 It does not work for me either.
 const testString = 'sup\u00ADer\u00ADfrag\u00ADilis\u00ADtice\u00ADxpial\u00ADidocious';

  return (
    <Text style={{ fontSize: 32, color: 'white' }} android_hyphenationFrequency={'normal'}>
      {testString}
    </Text>
  );

The word is breaking superfragilisticexpiaid ocious and without hyphen. Is there something wrong with my code?

https://developer.android.com/reference/android/widget/TextView#setHyphenationFrequency(int)

setHyphenationFrequency
Sets the frequency of automatic hyphenation to use when determining word breaks.

it doesn't work for me either.
@fabriziobertoglio1987 do you have some code examples?


git url change

super minor fix that kinda does nothing because the original url redirects anyway. just looks better imo

Thank you! 🙏


METRON-100 GeoIP errors out silently in vagrant

When we transitioned from passing the value to the adapters to passing a CacheKey object, we never adjusted the SQL statements.  Also, this error may cause downstream issues whereby messages error out because enrichments are short circuited if one fails and the source.type never gets properly set.
The JIRA is wrong, this bug is actually present in every environment and prevents GeoIP enrichment from working.

+1!
Thanks

Good catch.  Looks great. +1

Tested with the latest code changes, ..Good Fix


Insufficient information on mock failure when argument is object

Consider the following test, which is the simplest example to show a problem with the error information:
   it(`With an object as a parameter, but the wrong one, we get insufficient information back from TypeMoq`, () => {
        let mock = TypeMoq.Mock.ofType(B, TypeMoq.MockBehavior.Strict);
        mock.setup(g => g.g({a:22})).returns(() => -222);
        expect(mock.object.g({a:11})).eql(222);
    });

The message is:
MockException - no setup expression found for ('B.g([object Object])'
This works fine with simple values, of course.
There is an easy fix in this particular case. But when there are complex objects involved as arguments, it would be great to have displayed the full details of the objects concerned, both expected and actual. In my real case, I'm dealing with multiple arguments, all of which are complex objects and/or arrays.

I am seeing this too.
Moq (C#) has been awesome at providing very detailed clues about what didn't work when verifying expectations. For example, in this code (that fails because of an incorrect expectation):
                this.addressResolver.Setup(pm => pm.ResolveStreetAddress(It.IsAny<String>()))
                    .Returns((Position)null);

                this.manager.CreateCar("adescription", "alicenseplate", "amake", "amodel", 2010));

                this.addressResolver.Verify(pm => pm.ResolveStreetAddress("avalidhomelocation"));

yields this kind of error detail, when the test fails due to failed expectation.
Moq.MockException:
Expected invocation on the mock at least once, but was never performed: pm => pm.ResolveStreetAddress("avalidhomelocation")

Configured setups:
pm => pm.ResolveStreetAddress(It.IsAny<String>()), Times.Once

Performed invocations:
IAddressResolver.ResolveStreetAddress("aninvalidhomelocation")
<stacktrace following>

Can TypeMoq provide a similar output that lists: at least the expected value and the actual values that were returned like Moq does? Does not have to be exactly the same, but at least give enough clues as to where to focus the developer?

@rickmugridge Indeed [object Object] is not very informative. I've pushed a commit with some changes to display object args as json.
@jezzsantos Good idea. I've added to the failed verification message the list of the expected calls and their expected call counts (available only for the setups marked as verifiable) and the list of the actual calls.
Please install the development version and let me know how it goes.

Many thanks @florinn ! I have been using the dev version for the last few days and the new display is excellent.

Thanks, Rick. I've just published a new version (1.5.0) that includes these changes.


Move models to Models directory and refactor Imports

This PR marks the first step of #41.
Also remove unused imports

Found the culprit. The permissions are linked to the model name including the namespace. Since that changed, the admin lost its privileges.
I guess we need to create a migration to change these values from App\User to App\Models\User.


Integrating Observable Inputs

Hi,
Really excited to see progress being made on making observable plot available in python!
What is the feasibility of integrating Observable Inputs with this to make the following example possible?
https://observablehq.com/@observablehq/plot-density-weighted?intent=fork
Many thanks,
Harry

Hi,
In fact integrating Observable Inputs would mean integrating the Observable runtime and stdlib, which is not the scope of pyobsplot (I understand that the name Observable Plot can make the distinction a bit confusing).
pyobsplot only allows to use Plot in notebooks, not the entire Observable ecosystem. For your information I co-developed an R package that does the latter, but I don't know if there is an equivalent for Python.

Hi Julien,
Thank you for the information - not to worry!


Correcting formatting

Proposed changes
I have corrected some indentations, list numbering and formatting in bash code references because the contents of the documentation were being rendered in the wrong way making it difficult to read the documentation.
Occurrences:

Thanks so much @wallaceroque this is great!


Find untranslated strings?

Check to make sure strings are translated wherever we expect them to be. This includes all the places where the site renders text in the UI, for example:

menus
buttons
table headers
form labels.

It will not translate user-provided text, for example the names of programs, sites, indicators, etc.
Non-date numbers will not be localized or translated. For example

This issue is superseded by a number of other tickets that have since been implemented and closed.


3.11.16 Is broken

The latest deploy commit deleted all the dist files and as such the published npm package is broken.
As a result:
This dependency was not found:

vuesax in ./resources/js/themeConfig.js, ./resources/js/src/main.js

Please unpublish this version until it is solved or force a republish with the correct files

I'm having the same problem, please fix that :(

Same problem here, this version doesnt generate the dist folder with the css styles :(

Same issue, reverted to 3.11.15 for now

Ditto.

Same problem.

https://github.com/lusaxweb/vuesax/tree/2d85cddbc90d32bd356c996e8df88606f209a75f


[1.12.0-rc2] docker node reject?

If there is docker node accept, how do you reject a node from joining?
I expected to see something like docker node reject

@BenHall: You can use docker node rm to remove pending nodes from the list without accepting them.
I'll go ahead and close this, but please follow if this doesn't work as expected.

perhaps this can be improved in the docs? /cc @sfsmithcha


As @paulthomson has pointed out, there are undefined values caused by using derivative functions improperly so I slightly modified shaders and the following are the images produced by the latest shaders:

binarysearch_bw

mergesort_mosaic

quicksort_palette

@jiradeto Now that #665 is fixed, can you rebase?  Hopefully CI will pass for your new shaders.


Disconnect during handshake

This is my first attempt at using anything with graphql. Just trying to get a simple example running. I followed the setup instructions provided, including the creation of the "hello world" subscription and an exact copy of the routing.py file.
When I try to connect to the websocket server from my web browser, my server displays the following:
INFO 2020-06-08 17:10:53,544 runserver<PHONE_NUMBER>70039136000 WebSocket HANDSHAKING /graphql/ [<IP_ADDRESS>:41850] WebSocket DISCONNECT /graphql/ [<IP_ADDRESS>:41850] INFO 2020-06-08 17:10:57,761 runserver<PHONE_NUMBER>70039136000 WebSocket DISCONNECT /graphql/ [<IP_ADDRESS>:41850]
and the browser displays
WebSocket connection to 'ws://localhost:8000/graphql/' failed: Error during WebSocket handshake: net::ERR_CONNECTION_RESET
I can't seem to complete the handshake, and don't receive any error to help debug

Hi @addudley!
I wonder if the GraphQL client setup in your browser is causing some issues here - can you share any more details about how that is set up so that I can help you debug it? Also, are you running your Django app using ./manage.py runserver locally?
Could you also try testing the "hello world" subscription you created using something like GraphQL Playground to see whether it's an issue at the subscription layer?

Thanks for the fast response, @jaydenwindle !
The good news is, you put me on the right track to figuring out that it isn't completely broken. I installed GraphQL Playground and was able to successfully subscribe to "hello"!
I had been trying to connect to the websockets using both a websocket client and using ws = new WebSocket('ws://localhost:8000/graphql/') (with the same results). If you have any insights into why these may not be working, great, but if not no worries!
To answer your question, yes I am using ./manage.py runserver.
Now on to figuring out exactly how the demo "hello world" subscription works and the syntax required, and the many other questions that have sprung into my head while figuring this one out!

Ok awesome! Glad it worked in Playground.
My guess is that it's an issue with your client-side GraphQL setup. What kind of stack are you using on the front end? Have you tried setting up subscriptions using something like Apollo Client?
Feel free to ping me in our gitter channel and I'll help out with your additional questions however I can!

Pass 'graphql-ws' on the subprotocol parameter on the client side worked for me.
ws = new WebSocket('ws://localhost:8000/graphql/', 'graphql-ws')


InvalidEventNumber error in ByteStreamWriter

Problem description
My benchmark writer app panics with the following error from ByteStreamWriter.
[2020-10-26T18:54:21Z INFO  pravega_benchmark_rust] Benchmark configuration: BenchmarkWrite { controller: "nautilus-pravega-controller.nautilus-pravega.svc.cluster.local:9090", scope: "examples", stream: "pbr-10-100000MB-pod0", event_size: 10000000, num_events: 10000, events_per_flush: 100 }
[2020-10-26T18:54:21Z INFO  pravega_benchmark_rust] Stream pbr-10-100000MB-pod0 created.
[2020-10-26T18:54:21Z INFO  pravega_client_rust::byte_stream] SegmentReactor; event_stream_writer=28536362b022783074a59c14a6d560bd
[2020-10-26T18:54:21Z INFO  pravega_client_rust::reactor::segment_writer] setup connection; segment_writer=7d0adc804b78a818503e9ef18b0f067d segment=examples/pbr-10-100000MB-pod0/0.#epoch.0
[2020-10-26T18:54:21Z INFO  pravega_client_rust::reactor::segment_writer] setting up connection for segment writer
[2020-10-26T18:54:21Z INFO  pravega_benchmark_rust] Writing 10000 events of 10000000 bytes.
[2020-10-26T18:54:21Z INFO  pravega_client_rust::reactor::segment_writer] connection listener; connection=0f46599c-8063-4db9-8bb3-50d7b6539a67
[2020-10-26T18:54:21Z INFO  pravega_client_rust::reactor::segment_writer] finished setting up connection
[2020-10-26T18:54:22Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:54:39Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:54:54Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:55:09Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:55:24Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:55:39Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:55:54Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:56:09Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:56:24Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:56:38Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:56:53Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:57:08Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:57:22Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:57:37Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:57:51Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:58:06Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:58:20Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:58:21Z WARN  pravega_client_rust::reactor::segment_writer] connection failed to read data back from segmentstore due to Read { part: "header", source: ReadData { endpoint: PravegaNodeUri("<IP_ADDRESS>:12345"), source: Custom { kind: UnexpectedEof, error: "early eof" }, backtrace: Backtrace(()) }, backtrace: Backtrace(()) }, closing the listener task
[2020-10-26T18:58:21Z WARN  pravega_client_rust::reactor::reactors] writer WriterId(166209894736374678223617517123839919741) failed to flush data to segment ScopedSegment { scope: Scope { name: "examples" }, stream: Stream { name: "pbr-10-100000MB-pod0" }, segment: Segment { number: 0, tx_id: None } } due to SegmentWriting { source: Write { source: SendData { endpoint: PravegaNodeUri("<IP_ADDRESS>:12345"), source: Os { code: 32, kind: BrokenPipe, message: "Broken pipe" }, backtrace: Backtrace(()) }, backtrace: Backtrace(()) } }, reconnecting
[2020-10-26T18:58:21Z INFO  pravega_client_rust::reactor::segment_writer] setup connection; segment_writer=7d0adc804b78a818503e9ef18b0f067d segment=examples/pbr-10-100000MB-pod0/0.#epoch.0
[2020-10-26T18:58:21Z INFO  pravega_client_rust::reactor::segment_writer] setting up connection for segment writer
[2020-10-26T18:58:21Z INFO  pravega_rust_client_auth] token expiry time<PHONE_NUMBER> is in the refresh threshold<PHONE_NUMBER>, need to refresh token
[2020-10-26T18:58:21Z INFO  pravega_client_rust::reactor::segment_writer] connection listener; connection=f45f8db6-79a4-4c3a-8c35-ebf618b32c25
[2020-10-26T18:58:21Z INFO  pravega_client_rust::reactor::segment_writer] finished setting up connection
[2020-10-26T18:58:21Z INFO  pravega_client_rust::reactor::segment_writer] setup connection; segment_writer=7d0adc804b78a818503e9ef18b0f067d segment=examples/pbr-10-100000MB-pod0/0.#epoch.0
[2020-10-26T18:58:21Z INFO  pravega_client_rust::reactor::segment_writer] setting up connection for segment writer
[2020-10-26T18:58:21Z INFO  pravega_client_rust::reactor::segment_writer] connection listener; connection=562cdd1c-d122-4d16-9def-026f40c4005f
[2020-10-26T18:58:21Z INFO  pravega_client_rust::reactor::segment_writer] finished setting up connection
[2020-10-26T18:58:35Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:58:50Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:59:05Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:59:20Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:59:35Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T18:59:50Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:00:04Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:00:19Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:00:34Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:00:49Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:01:03Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:01:18Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:01:32Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:01:46Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:02:01Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:02:16Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:02:21Z WARN  pravega_client_rust::reactor::segment_writer] connection failed to read data back from segmentstore due to Read { part: "header", source: ReadData { endpoint: PravegaNodeUri("<IP_ADDRESS>:12345"), source: Custom { kind: UnexpectedEof, error: "early eof" }, backtrace: Backtrace(()) }, backtrace: Backtrace(()) }, closing the listener task
[2020-10-26T19:02:21Z INFO  pravega_client_rust::reactor::segment_writer] setup connection; segment_writer=7d0adc804b78a818503e9ef18b0f067d segment=examples/pbr-10-100000MB-pod0/0.#epoch.0
[2020-10-26T19:02:21Z INFO  pravega_client_rust::reactor::segment_writer] setting up connection for segment writer
[2020-10-26T19:02:21Z WARN  pravega_client_rust::reactor::segment_writer] connection failed to read data back from segmentstore due to Read { part: "header", source: ReadData { endpoint: PravegaNodeUri("<IP_ADDRESS>:12345"), source: Custom { kind: UnexpectedEof, error: "early eof" }, backtrace: Backtrace(()) }, backtrace: Backtrace(()) }, closing the listener task
[2020-10-26T19:02:21Z INFO  pravega_rust_client_auth] token expiry time<PHONE_NUMBER> is in the refresh threshold<PHONE_NUMBER>, need to refresh token
[2020-10-26T19:02:21Z INFO  pravega_client_rust::reactor::segment_writer] connection listener; connection=bf418d35-58cc-405f-b6c1-3bbc3affe572
[2020-10-26T19:02:21Z INFO  pravega_client_rust::reactor::segment_writer] finished setting up connection
[2020-10-26T19:02:21Z INFO  pravega_client_rust::reactor::segment_writer] setup connection; segment_writer=7d0adc804b78a818503e9ef18b0f067d segment=examples/pbr-10-100000MB-pod0/0.#epoch.0
[2020-10-26T19:02:21Z INFO  pravega_client_rust::reactor::segment_writer] setting up connection for segment writer
[2020-10-26T19:02:21Z INFO  pravega_client_rust::reactor::segment_writer] connection listener; connection=1cfc5965-b81a-4c25-a9e5-96a1b12fe158
[2020-10-26T19:02:21Z INFO  pravega_client_rust::reactor::segment_writer] finished setting up connection
[2020-10-26T19:02:30Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:02:45Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:03:00Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:03:15Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:03:29Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:03:43Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:03:58Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:04:12Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:04:26Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:04:41Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:04:56Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:05:11Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:05:25Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:05:40Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:05:54Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:06:09Z INFO  pravega_benchmark_rust] Flushing 100 events
[2020-10-26T19:06:21Z WARN  pravega_client_rust::reactor::segment_writer] connection failed to read data back from segmentstore due to Read { part: "header", source: ReadData { endpoint: PravegaNodeUri("<IP_ADDRESS>:12345"), source: Custom { kind: UnexpectedEof, error: "early eof" }, backtrace: Backtrace(()) }, backtrace: Backtrace(()) }, closing the listener task
[2020-10-26T19:06:21Z INFO  pravega_client_rust::reactor::segment_writer] setup connection; segment_writer=7d0adc804b78a818503e9ef18b0f067d segment=examples/pbr-10-100000MB-pod0/0.#epoch.0
[2020-10-26T19:06:21Z INFO  pravega_client_rust::reactor::segment_writer] setting up connection for segment writer
[2020-10-26T19:06:21Z INFO  pravega_rust_client_auth] token expiry time<PHONE_NUMBER> is in the refresh threshold<PHONE_NUMBER>, need to refresh token
[2020-10-26T19:06:21Z INFO  pravega_client_rust::reactor::segment_writer] connection listener; connection=8388eae8-f6f8-48ad-a590-c41a8543e2d0
[2020-10-26T19:06:21Z INFO  pravega_client_rust::reactor::segment_writer] finished setting up connection
[2020-10-26T19:06:21Z WARN  pravega_client_rust::reactor::segment_writer] connection failed to read data back from segmentstore due to Read { part: "header", source: ReadData { endpoint: PravegaNodeUri("<IP_ADDRESS>:12345"), source: Custom { kind: UnexpectedEof, error: "early eof" }, backtrace: Backtrace(()) }, backtrace: Backtrace(()) }, closing the listener task
[2020-10-26T19:06:21Z INFO  pravega_client_rust::reactor::segment_writer] setup connection; segment_writer=7d0adc804b78a818503e9ef18b0f067d segment=examples/pbr-10-100000MB-pod0/0.#epoch.0
[2020-10-26T19:06:21Z INFO  pravega_client_rust::reactor::segment_writer] setting up connection for segment writer
[2020-10-26T19:06:21Z INFO  pravega_client_rust::reactor::segment_writer] connection listener; connection=ed23823d-5969-4bc1-b80c-e8fdc88c4280
[2020-10-26T19:06:21Z INFO  pravega_client_rust::reactor::segment_writer] finished setting up connection
[2020-10-26T19:06:21Z WARN  pravega_client_rust::reactor::segment_writer] connection failed to read data back from segmentstore due to Read { part: "header", source: ReadData { endpoint: PravegaNodeUri("<IP_ADDRESS>:12345"), source: Custom { kind: UnexpectedEof, error: "early eof" }, backtrace: Backtrace(()) }, backtrace: Backtrace(()) }, closing the listener task
[2020-10-26T19:06:21Z ERROR pravega_client_rust::reactor::reactors] receive unexpected reply InvalidEventNumber(InvalidEventNumberCommand { writer_id:<PHONE_NUMBER>36374678223617517123839919741, event_number: 9768, server_stack_trace: "" }), closing segment reactor
[2020-10-26T19:06:21Z ERROR pravega_client_rust::reactor::segment_writer] connection read data from segmentstore but failed to send reply back to reactor due to SendError(ServerReply(ServerReply { segment: ScopedSegment { scope: Scope { name: "examples" }, stream: Stream { name: "pbr-10-100000MB-pod0" }, segment: Segment { number: 0, tx_id: None } }, reply: InvalidEventNumber(InvalidEventNumberCommand { writer_id:<PHONE_NUMBER>36374678223617517123839919741, event_number: 9770, server_stack_trace: "" }) }))
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: "oneshot error RecvError(())" }', src/bin/pravega-benchmark-rust.rs:140:36
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Problem location
Unknown.
Suggestions for an improvement
Unknown.

It has been fixed by the merged PR referenced above.


Tool: Open "Contact us" mailto link in new tab

Open "Contact us" mailto link in new tab. Currently opens in the same tab. It will just make going back to the forms page easier, especially if you have to refer back to that to write your issue.

@fazil-ey I have deployed it on DEV. It works well on mac os. It needs to check on windows os but on PCOD does not allow me to change the detail mail app to the browser like what you showed yesterday on call.
Could you please confirm on your end on DEV, to open "Contact Us" in the new tab?

Tested on Windows by Meghan & works as expected


Make CRUDHandler generic (#6129)

Pull request opened by the merge tool on behalf of #6129

Merged into branches iso6 in c7b37ca7a5feedc80c0b73114c7796fd6e40948c


threads

Icon Request

Icon name: Threads
Use case: https://www.threads.net/

https://remixicon.com/icon/threads-fill


Add_pct doesn't work with Pandas > 1.0.0

"Passing list-likes to .loc or [] with any missing labels is no longer supported.
The following labels were missing: Index(['Gm10116', 'Lilrb4', 'Chi3l3', 'AI607873',
'AF251705'], dtype='object', name='index'). See https://pandas.pydata.org/pandas-docs/stable/
user_guide/indexing.html#deprecate-loc-reindex-listlike"

        if gene_label == "index":
            tab["pct.%s" %ident] = data_temp.reindex([tab.index.values]).values
        else:
            tab["pct.%s" %ident] = data_temp.reindex([tab.loc[:, gene_label]]).values

Works with reindexing


Add processing toggle permission to component stereotypes

Related problem
Currently all components are automatically processed when it passes any ComponentProcessor's preconditions. However, it may not always be desired that a component is processed. This may be to circumvent specific modifications, for testing purposes, or other specific use-cases.
Requested feature
Add a toggle permission to the component stereotype: #processComponent which defaults to true. If the component indicates it does not wish to be processed, the processing queue should skip the component.

Perhaps this could be achieved by adding a @DisableComponent annotation to the component?

Perhaps this could be achieved by adding a @DisableComponent annotation to the component?

That would likely lead to ambiguity as the component will still be registered to the active component locator, while the name DisableComponent suggests the component is globally disabled.
Likewise, #permitProxying is also a stereotype attribute, so adding a separate annotation for component processing would be inconsistent