perform sanity check of ontology model

The topic of performing a sanity check of our ontology came up during our Ontology Meeting on 11/2.

Have we properly used "is a type of wasDerivedFrom" (and other properties from PROV-S)? Or do we need to create a different parent property to use?
If the above is modified, check impact to all the nodegroups.
While we're at it, scrub ontology for properties where it is indeed "... values of type" versus "... single value of type", and vice versa.

I think this kind of review is a good idea. Will get started on it Monday!

Review of RACK ontology completed, ready for discussion before submitting a pull request. After suggested edits, the ontology is still compatible with the standards sections, but some updates would be needed to the turnstile code. Let's discuss at the ontology meeting on 17 Nov.

Take a look at branch dwa/ontology-review for details. Best if we get interested folks on a conf call to walk through it

dwa/ontology-review branch has now been fully patched so that turnstile data has no remaining errors against the changes to rack data model reviewed today. Ready for final review.

@davearcher, is it that the ontology changes didn't cause any changes to Turnstile? Or could it be that modified Turnstile files have not been pushed in to your branch?

There were a couple of minor mods to Turnstile, and a couple of minor mods
to the data model as well. Unfortunately, I wasn't able to push those
changes. I upgraded my MacOS yesterday, and now must re-install the Xcode
dev tools in order to run git and do the commit/push. I'll push as soon as
my Xcode tools are in. Unfortunately, that's a process that takes about 12
hours with the bandwidth I have here at home :( ...sorry!
/d
On Thu, Nov 19, 2020 at 12:20 PM Kit Siu<EMAIL_ADDRESS>wrote:

@davearcher https://github.com/davearcher, is it that the ontology
changes didn't cause any changes to Turnstile? Or could it be that modified
Turnstile files have not been pushed in to your branch?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ge-high-assurance/RACK/issues/219#issuecomment-730614279,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACJXTPYXLBNW3HY4T4NQY6TSQV4Y7ANCNFSM4TKJZZWA
.

--
Dave Archer, PhD https://galois.com/team/david-archer/
Principal Scientist
Galois, Inc. https://www.galois.com - 421 SW 6th Avenue, Suite 300,
Portland, OR 97204
email<EMAIL_ADDRESS>SMS/phone +1(503)701-0235 (use Signal if possible)
https://www.mypronouns.org/he-him

Hi all - finally was able to push the last edits on ontology-review. Feel free to review.

@russell-d-e, can you please review the changes to Turnstile files in @davearcher's branch? Most of the changes to the ontology have to do with cardinality, but there are one or two changes to Turnstile that you should review. Also, @AbhaMoitra and I saw that at least one of the changes may impact your automation scripts.

Couple of notes / questions:

we need a cardinality restriction on agentName

do I remember correctly that when we went over the changes last week that Eric verified that SemTK does not handle "H:source of HAZARD must be one of {HAZARD, sw:SWCOMPONENT, sys:SYSTEM}." and that is why it is commented out. However, I see "sw:performedBy of CODE_GEN must be one of {Ag:PERSON, Ag:ORGANIZATION}." etc.

Why did we add unneeded "imports" to REQUIREMENTS.sadl, it makes the visualization less clear. Based on other changes in this file, you do need to now import HAZARD. Similar comment on other files.

Also

do we need to add cardinality restrictions on textConfidence etc. in GrammaTech.sadl?

My Notes/Question,:

it seems that some of the changes are over specifying, for example "governs" for requirements being restricted to SYSTEM, COMPONENT, TEST, FILE, REVIEW.  What about INTERFACE, it would be quite logical to define REQUIREMENTs for governing a INTERFACE.  This over all is the issue with restricting the ranges on these class. It does not provide much if any benefit however it does restrict the possibilities on how things can be used.
Changing mitigates to avoids, beyond that fact that you likely cannot avoid a hazard, mitigate is the common terminology that I have always heard in relation the Hazards why are we picking a new term.  Again it seems adding the HAZARD restriction is not necessary. In the future I could see someone wanting to capture something like FAILURE_CONDITION that you may what to have mitigating REQUIREMENTS for.
*Why is SystemComponent being changed to SYSTEM, this was defined as part of the turnstile planning?
Why did you not change ExecutiveThread, InputThread, and OutputThread to SYSTEM instead of  SWCOMPONENT?
I don't think it is correct to change file:statisfies to Rq:satisfies, the domain for the property is FILE, so it should be using the file version.  This might be a place were maybe we want to add a new fundamental relationship. Satisfies is a relationship that I could see having on many different classes.  By defining it as a new fundamental relationship we can avoid the need for a prefix at all.
For DATA_DICTIONARY_TERM, providedBy and consumedBy are identified as two separate relationships as they show directionality of the relationship, for example in the turnstile example there are requirements that produce some data dictionary terms and consume other data dictionary terms.  Directionality is something that can be very important if the data dictionary terms are being used do perform something like a data and control coupling analysis.
Why is Rv:governedBy changed to Rq:governedBy? governedBy is defined in the REVIEW.sadl?

@russell-d-e : In Dave's latest branch, it has "mitigates" and not "avoids". Were you looking at an earlier version of the branch?

Hi Dan,
On Wed, Nov 25, 2020 at 8:37 PM russell-d-e<EMAIL_ADDRESS>wrote:

My Notes/Question,:

it seems that some of the changes are over specifying, for example
"governs" for requirements being restricted to SYSTEM, COMPONENT, TEST,
FILE, REVIEW. What about INTERFACE, it would be quite logical to define
REQUIREMENTs for governing a INTERFACE. This over all is the issue with
restricting the ranges on these class. It does not provide much if any
benefit however it does restrict the possibilities on how things can be
used.

already removed, because SemTK doesn't support these restrictions. You may
not have the most recent version of this branch.

Changing mitigates to avoids, beyond that fact that you likely
cannot avoid a hazard, mitigate is the common terminology that I have
always heard in relation the Hazards why are we picking a new term. Again
it seems adding the HAZARD restriction is not necessary. In the future I
could see someone wanting to capture something like FAILURE_CONDITION that
you may what to have mitigating REQUIREMENTS for.

Not sure where you're seeing avoids in the current branch? You might want
to pull the branch again.

Note that mitigates is defined only for HAZARD. A separate relationship
would be needed in FAILURE_CONDITION for it to be mitigated by a
REQUIREMENT. I think that one of the problems with SADL is that it seems
allowable to attach a relationship defined anywhere to whatever entity
instance you choose - that's strictly disallowed in the E-R model. I think
it would be worth revisiting the restriction issue with some of the tenets
of E-R in mind?

*Why is SystemComponent being changed to SYSTEM, this was defined as
part of the turnstile planning?

I'm not sure what file you're referring to here. I think that might be an
error, since SystemComponent is a type of SYSTEM anyway.

Why did you not change ExecutiveThread, InputThread, and
OutputThread to SYSTEM instead of SWCOMPONENT?

I made only changes to Turnstile that allow it to compile successfully,
and where the semantics were clear to me. I'm not sure what kind of thing
the "thread" abstraction is, or how it's intended to be used in assurance
cases. Do we know what TA1's have in mind here?

I don't think it is correct to change file:statisfies to
Rq:satisfies, the domain for the property is FILE, so it should be using
the file version. This might be a place were maybe we want to add a new
fundamental relationship. Satisfies is a relationship that I could see
having on many different classes. By defining it as a new fundamental
relationship we can avoid the need for a prefix at all.

This situation is yet another instance of the restriction issue. I can see
that a FILE can SATISFIES a REQUIREMENT, so it should use the SATISFIES
property that is defined for attaching it to REQUIREMENT instances. Again,
I think that there's a major error in the modeling approach of being able
to use any relationship from anywhere in the model to connect any entity
instance types you might choose. By the way, file:satisfies has been
removed.

For DATA_DICTIONARY_TERM, providedBy and consumedBy are identified
as two separate relationships as they show directionality of the
relationship, for example in the turnstile example there are requirements
that produce some data dictionary terms and consume other data dictionary
terms. Directionality is something that can be very important if the data
dictionary terms are being used do perform something like a data and
control coupling analysis.

I don't think I changed these properties - only removed the statement that
they were types of wasDerivedFrom, which is incorrect. At least that was my
aim!

Why is Rv:governedBy changed to Rq:governedBy? governedBy is defined
in the REVIEW.sadl?

governedBy was removed from REVIEW.sadl - you may not have the correct
pull of the branch...

Hope this helps! Let me know if you have more questions!
/d

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ge-high-assurance/RACK/issues/219#issuecomment-734069093,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACJXTPZKM2P4DPD4X5VVJOTSRXLR7ANCNFSM4TKJZZWA
.

--
Dave Archer, PhD https://galois.com/team/david-archer/
Principal Scientist
Galois, Inc. https://www.galois.com - 421 SW 6th Avenue, Suite 300,
Portland, OR 97204
email<EMAIL_ADDRESS>SMS/phone +1(503)701-0235 (use Signal if possible)
https://www.mypronouns.org/he-him

On Wed, Nov 25, 2020 at 10:47 AM AbhaMoitra<EMAIL_ADDRESS>wrote:

Couple of notes / questions:

we need a cardinality restriction on agentName
fixed to max 1

do I remember correctly that when we went over the changes last week
that Eric verified that SemTK does not handle "H:source of HAZARD must be
one of {HAZARD, sw:SWCOMPONENT, sys:SYSTEM}." and that is why it is
commented out. However, I see "sw:performedBy of CODE_GEN must be one of
{Ag:PERSON, Ag:ORGANIZATION}." etc.
commented out now

Why did we add unneeded "imports" to REQUIREMENTS.sadl, it makes the
visualization less clear. Based on other changes in this file, you do need
to now import HAZARD. Similar comment on other files.
Aside from imports of PROV-S, I've checked all imports and removed all but
those that otherwise induce errors. The result is that
SOFTWARE imports FILE and AGENTS
REQUIREMENTS imports HAZARD
HAZARD now imports only SYSTEM
ANALYSIS now imports only DOCUMENT
REVIEW now imports only DOCUMENT
SYSTEM now imports only DOCUMENT

I'll push these changes shortly. Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ge-high-assurance/RACK/issues/219#issuecomment-733888444,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACJXTP3VJUT466FSM2SK6ATSRVGNRANCNFSM4TKJZZWA
.

--
Dave Archer, PhD https://galois.com/team/david-archer/
Principal Scientist
Galois, Inc. https://www.galois.com - 421 SW 6th Avenue, Suite 300,
Portland, OR 97204
email<EMAIL_ADDRESS>SMS/phone +1(503)701-0235 (use Signal if possible)
https://www.mypronouns.org/he-him

John is in the process of making the pre-release; so please wait on pushing the changes to master.

Dave,
Here are my remaining comments:
<EMAIL_ADDRESS>mitigates was changed to  have a range for the property of HAZARD, rather than entity. What is the virtue in having this range restricted? As I said before, if a new entity type of FAILURE_CONDITION is created I could see wanting to identify the requirements that are mitigating that failure condition.  This really is a comment that I would applies more generally. What are we gaining by having range restrictions in the base ontology that are more specific than ENTITY, ACTIVITY, or AGENT. While I could see some minor confusion that could stem from this openness when people first start using the tool, but eventually people while have to understand how to work with this as it will have to occur for ranges of some things. The tool in general is going to be much more useable in the long term the more flexibility that it has so anytime we are wanting to limit this flexibility we should have a clear and obvious reasons why.  In my mind this applies to things such as cardinality as well. For example:
<EMAIL_ADDRESS>The “givenText” on REQUIREMENT had a cardinality restriction add of at most 1 value, Why? I could see multiple “givenText” if you have more than one precondition.  This is maybe not the strongest case because I wonder if these should be part of a TA specific ontology on not the core ontology. Even something like author for a REVIEW.  I have participated in a many review where multiple people’s work where combined into a single review, why would we not support this? Things like dates, and statuses I absolutely agree can have cardinality restrictions, but just like the range we should be 100% confident that it is absolutely an error and I would argue it is better to error on the side of flexibility.
SystemComponent is being changed to SYSTEM in DevelopmentPlanData.sadl:
<EMAIL_ADDRESS>SystemComponent was defined in the Turnstile extension of the ontology this should remain as is. COMPONENT was changed to SWCOMPONENT:
<EMAIL_ADDRESS>This changes was not maintained for the<EMAIL_ADDRESS>But they were updated for the rules associated with this:
<EMAIL_ADDRESS>This should just be made consistent, otherwise extracting the data will miss some relationships.

I don't think it is correct to change file:statisfies to
Rq:satisfies, the domain for the property is FILE, so it should be using
the file version. This might be a place where maybe we want to add a new
fundamental relationship. Satisfies is a relationship that I could see
having on many different classes. By defining it as a new fundamental
relationship we can avoid the need for a prefix at all.

This situation is yet another instance of the restriction issue. I can see
that a FILE can SATISFIES a REQUIREMENT, so it should use the SATISFIES
property that is defined for attaching it to REQUIREMENT instances. Again,
I think that there's a major error in the modeling approach of being able
to use any relationship from anywhere in the model to connect any entity
instance types you might choose. By the way, file:satisfies has been
removed.

The issue with this is that in SADL and the underlying OWL, “File has satisfies Req” is not interchange able with “Req has satisfies Req” the Domain for the first is File while in the later it is Req.  If satisfies was removed from file this is likely not going to work as it will no longer show up in the nodes for SemTK and will likely cause an error on ingestion.  To only have the property on Requirements you would have to have two properties a satisfies and satisfiedBy  then you could write “Req has satisfiedBy File”.
The my final question for today is my the PROV primer describes derivation  as “ When one entity's existence, content, characteristics and so on are at least partly due to another entity, then we say that the former was derived from the latter.”  With this thing like “satisfies” would fall into that definition for derivation so why are we say that is not applicable.  One of the big benefits for using the PROV base is to be able to with a very simple query, answer the question, “if I change this entity, what are the downstream entities that would now be suspect”.  With these changes I am not sure we still be able to do those queries simply you would have to look at all the relationships and make a “uber-query” that looks at all the independent properties that are entity specific.
Since we are not going to try and squeeze this to the current release going forward maybe the best way to hash out these discussion is by having a pull request and putting comments as part of that.  That way we can really look at each of the changes in context and have a pointed discussion that that.
Dan
From: Dave Archer<EMAIL_ADDRESS>Sent: Monday, November 30, 2020 11:07 AM
To: ge-high-assurance/RACK<EMAIL_ADDRESS>Cc: Russell, Daniel (GE Aviation, US<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: EXT: Re: [ge-high-assurance/RACK] perform sanity check of ontology model (#219)
Hi Dan,
On Wed, Nov 25, 2020 at 8:37 PM russell-d-e <notifications<EMAIL_ADDRESS>wrote:

My Notes/Question,:

it seems that some of the changes are over specifying, for example
"governs" for requirements being restricted to SYSTEM, COMPONENT, TEST,
FILE, REVIEW. What about INTERFACE, it would be quite logical to define
REQUIREMENTs for governing a INTERFACE. This over all is the issue with
restricting the ranges on these class. It does not provide much if any
benefit however it does restrict the possibilities on how things can be
used.

already removed, because SemTK doesn't support these restrictions. You may
not have the most recent version of this branch.

Changing mitigates to avoids, beyond that fact that you likely
cannot avoid a hazard, mitigate is the common terminology that I have
always heard in relation the Hazards why are we picking a new term. Again
it seems adding the HAZARD restriction is not necessary. In the future I
could see someone wanting to capture something like FAILURE_CONDITION that
you may what to have mitigating REQUIREMENTS for.

Not sure where you're seeing avoids in the current branch? You might want
to pull the branch again.

Note that mitigates is defined only for HAZARD. A separate relationship
would be needed in FAILURE_CONDITION for it to be mitigated by a
REQUIREMENT. I think that one of the problems with SADL is that it seems
allowable to attach a relationship defined anywhere to whatever entity
instance you choose - that's strictly disallowed in the E-R model. I think
it would be worth revisiting the restriction issue with some of the tenets
of E-R in mind?

*Why is SystemComponent being changed to SYSTEM, this was defined as
part of the turnstile planning?

I'm not sure what file you're referring to here. I think that might be an
error, since SystemComponent is a type of SYSTEM anyway.

Why did you not change ExecutiveThread, InputThread, and
OutputThread to SYSTEM instead of SWCOMPONENT?

I made only changes to Turnstile that allow it to compile successfully,
and where the semantics were clear to me. I'm not sure what kind of thing
the "thread" abstraction is, or how it's intended to be used in assurance
cases. Do we know what TA1's have in mind here?

I don't think it is correct to change file:statisfies to
Rq:satisfies, the domain for the property is FILE, so it should be using
the file version. This might be a place were maybe we want to add a new
fundamental relationship. Satisfies is a relationship that I could see
having on many different classes. By defining it as a new fundamental
relationship we can avoid the need for a prefix at all.

This situation is yet another instance of the restriction issue. I can see
that a FILE can SATISFIES a REQUIREMENT, so it should use the SATISFIES
property that is defined for attaching it to REQUIREMENT instances. Again,
I think that there's a major error in the modeling approach of being able
to use any relationship from anywhere in the model to connect any entity
instance types you might choose. By the way, file:satisfies has been
removed.

For DATA_DICTIONARY_TERM, providedBy and consumedBy are identified
as two separate relationships as they show directionality of the
relationship, for example in the turnstile example there are requirements
that produce some data dictionary terms and consume other data dictionary
terms. Directionality is something that can be very important if the data
dictionary terms are being used do perform something like a data and
control coupling analysis.

I don't think I changed these properties - only removed the statement that
they were types of wasDerivedFrom, which is incorrect. At least that was my
aim!

Why is Rv:governedBy changed to Rq:governedBy? governedBy is defined
in the REVIEW.sadl?

governedBy was removed from REVIEW.sadl - you may not have the correct
pull of the branch...

Hope this helps! Let me know if you have more questions!
/d

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ge-high-assurance/RACK/issues/219#issuecomment-734069093,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACJXTPZKM2P4DPD4X5VVJOTSRXLR7ANCNFSM4TKJZZWA
.

--
Dave Archer, PhD https://galois.com/team/david-archer/
Principal Scientist
Galois, Inc. https://www.galois.com - 421 SW 6th Avenue, Suite 300,
Portland, OR 97204
email dwa<EMAIL_ADDRESS>SMS/phone +1(503)701-0235 (use Signal if possible)
https://www.mypronouns.org/he-him
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/ge-high-assurance/RACK/issues/219#issuecomment-735880140, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AO6MHPOFAHRT572ULSHXUWTSSO7JBANCNFSM4TKJZZWA.

Hi Dan,
On Tue, Dec 1, 2020 at 10:31 PM russell-d-e<EMAIL_ADDRESS>wrote:

Dave,
Here are my remaining comments:
<EMAIL_ADDRESS>mitigates was changed to have a range for the property of HAZARD, rather
than entity. What is the virtue in having this range restricted? As I said
before, if a new entity type of FAILURE_CONDITION is created I could see
wanting to identify the requirements that are mitigating that failure
condition. This really is a comment that I would applies more generally.
What are we gaining by having range restrictions in the base ontology that
are more specific than ENTITY, ACTIVITY, or AGENT. While I could see some
minor confusion that could stem from this openness when people first start
using the tool, but eventually people while have to understand how to work
with this as it will have to occur for ranges of some things. The tool in
general is going to be much more useable in the long term the more
flexibility that it has so anytime we are wanting to limit this flexibility
we should have a clear and obvious reasons why. In my mind this applies to
things such as cardinality as well. For example:
<EMAIL_ADDRESS>The “givenText” on REQUIREMENT had a cardinality restriction add of at
most 1 value, Why? I could see multiple “givenText” if you have more than
one precondition. This is maybe not the strongest case because I wonder if
these should be part of a TA specific ontology on not the core ontology.
Even something like author for a REVIEW. I have participated in a many
review where multiple people’s work where combined into a single review,
why would we not support this? Things like dates, and statuses I absolutely
agree can have cardinality restrictions, but just like the range we should
be 100% confident that it is absolutely an error and I would argue it is
better to error on the side of flexibility.

I think this discussion is at the heart of setting direction for RACK, and
I think it's a religious argument. I can keep saying that open-ended
relationships are too powerful and result in mistakes. On the other hand,
you can keep saying that flexibility is good because the users might want
it. What both of these positions come down to lack of alignment on
engineering risk: is there more risk in extending the model later? or is
there more risk in handing the users more ability to make mistakes? I'd
claim we'll never agree on an answer.
That said, GE gets to make the decision. So, if you'd like me to pull out
the cardinality restrictions and generalize the range for HAZARD, I'm happy
to do that.

SystemComponent is being changed to SYSTEM in DevelopmentPlanData.sadl:
<EMAIL_ADDRESS>SystemComponent was defined in the Turnstile extension of the ontology
this should remain as is. COMPONENT was changed to SWCOMPONENT:
<EMAIL_ADDRESS>This changes was not maintained for the
<EMAIL_ADDRESS>But they were updated for the rules associated with this:
<EMAIL_ADDRESS>This should just be made consistent, otherwise extracting the data will
miss some relationships.
These seem like small issues to resolve. We should be able to walk through
the turnstile code and address them.

I don't think it is correct to change file:statisfies to
Rq:satisfies, the domain for the property is FILE, so it should be using
the file version. This might be a place where maybe we want to add a new
fundamental relationship. Satisfies is a relationship that I could see
having on many different classes. By defining it as a new fundamental
relationship we can avoid the need for a prefix at all.

This situation is yet another instance of the restriction issue. I can
see
that a FILE can SATISFIES a REQUIREMENT, so it should use the SATISFIES
property that is defined for attaching it to REQUIREMENT instances. Again,
I think that there's a major error in the modeling approach of being able
to use any relationship from anywhere in the model to connect any entity
instance types you might choose. By the way, file:satisfies has been
removed.

The issue with this is that in SADL and the underlying OWL, “File has
satisfies Req” is not interchange able with “Req has satisfies Req” the
Domain for the first is File while in the later it is Req. If satisfies was
removed from file this is likely not going to work as it will no longer
show up in the nodes for SemTK and will likely cause an error on ingestion.
To only have the property on Requirements you would have to have two
properties a satisfies and satisfiedBy then you could write “Req has
satisfiedBy File”.
I've restored file:satisfies and pushed it.

The my final question for today is my the PROV primer describes derivation
as “ When one entity's existence, content, characteristics and so on are at
least partly due to another entity, then we say that the former was derived
from the latter.” With this thing like “satisfies” would fall into that
definition for derivation so why are we say that is not applicable. One of
the big benefits for using the PROV base is to be able to with a very
simple query, answer the question, “if I change this entity, what are the
downstream entities that would now be suspect”. With these changes I am not
sure we still be able to do those queries simply you would have to look at
all the relationships and make a “uber-query” that looks at all the
independent properties that are entity specific.

I think the query you want to write is, "Show me all artifacts created by
activities that used artifact X", which can be written in a concise way.
That seems more semantically accurate than tracing the query through the
generic wasDerivedFrom relationship. That leaves wasDerivedFrom available
for another kind of query such as "show me the version history of artifact
X". Does that make sense? If not, then as I said above, you get to make the
decision. We can certainly restore all of the "is a kind of" that were
commented out.

Since we are not going to try and squeeze this to the current release
going forward maybe the best way to hash out these discussion is by having
a pull request and putting comments as part of that. That way we can really
look at each of the changes in context and have a pointed discussion that
that.

I'm fine with the pull request approach, though my concern would be that
the comments above likely obviate most or all of the changes in the branch.
Should we just terminate the branch instead?
Thanks!
/d

Dan
From: Dave Archer<EMAIL_ADDRESS>Sent: Monday, November 30, 2020 11:07 AM
To: ge-high-assurance/RACK<EMAIL_ADDRESS>Cc: Russell, Daniel (GE Aviation, US<EMAIL_ADDRESS>Mention <
<EMAIL_ADDRESS>Subject: EXT: Re: [ge-high-assurance/RACK] perform sanity check of
ontology model (#219)
Hi Dan,
On Wed, Nov 25, 2020 at 8:37 PM russell-d-e<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:

My Notes/Question,:

it seems that some of the changes are over specifying, for example
"governs" for requirements being restricted to SYSTEM, COMPONENT, TEST,
FILE, REVIEW. What about INTERFACE, it would be quite logical to define
REQUIREMENTs for governing a INTERFACE. This over all is the issue with
restricting the ranges on these class. It does not provide much if any
benefit however it does restrict the possibilities on how things can be
used.

already removed, because SemTK doesn't support these restrictions. You
may
not have the most recent version of this branch.

Changing mitigates to avoids, beyond that fact that you likely
cannot avoid a hazard, mitigate is the common terminology that I have
always heard in relation the Hazards why are we picking a new term.
Again
it seems adding the HAZARD restriction is not necessary. In the future I
could see someone wanting to capture something like FAILURE_CONDITION
that
you may what to have mitigating REQUIREMENTS for.

Not sure where you're seeing avoids in the current branch? You might
want
to pull the branch again.

Note that mitigates is defined only for HAZARD. A separate relationship
would be needed in FAILURE_CONDITION for it to be mitigated by a
REQUIREMENT. I think that one of the problems with SADL is that it seems
allowable to attach a relationship defined anywhere to whatever entity
instance you choose - that's strictly disallowed in the E-R model. I think
it would be worth revisiting the restriction issue with some of the tenets
of E-R in mind?

*Why is SystemComponent being changed to SYSTEM, this was defined as
part of the turnstile planning?

I'm not sure what file you're referring to here. I think that might be
an
error, since SystemComponent is a type of SYSTEM anyway.

Why did you not change ExecutiveThread, InputThread, and
OutputThread to SYSTEM instead of SWCOMPONENT?

I made only changes to Turnstile that allow it to compile successfully,
and where the semantics were clear to me. I'm not sure what kind of thing
the "thread" abstraction is, or how it's intended to be used in assurance
cases. Do we know what TA1's have in mind here?

I don't think it is correct to change file:statisfies to
Rq:satisfies, the domain for the property is FILE, so it should be using
the file version. This might be a place were maybe we want to add a new
fundamental relationship. Satisfies is a relationship that I could see
having on many different classes. By defining it as a new fundamental
relationship we can avoid the need for a prefix at all.

This situation is yet another instance of the restriction issue. I can
see
that a FILE can SATISFIES a REQUIREMENT, so it should use the SATISFIES
property that is defined for attaching it to REQUIREMENT instances. Again,
I think that there's a major error in the modeling approach of being able
to use any relationship from anywhere in the model to connect any entity
instance types you might choose. By the way, file:satisfies has been
removed.

For DATA_DICTIONARY_TERM, providedBy and consumedBy are identified
as two separate relationships as they show directionality of the
relationship, for example in the turnstile example there are
requirements
that produce some data dictionary terms and consume other data
dictionary
terms. Directionality is something that can be very important if the
data
dictionary terms are being used do perform something like a data and
control coupling analysis.

I don't think I changed these properties - only removed the statement
that
they were types of wasDerivedFrom, which is incorrect. At least that was
my
aim!

Why is Rv:governedBy changed to Rq:governedBy? governedBy is defined
in the REVIEW.sadl?

governedBy was removed from REVIEW.sadl - you may not have the correct
pull of the branch...

Hope this helps! Let me know if you have more questions!
/d

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/ge-high-assurance/RACK/issues/219#issuecomment-734069093>,

or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/ACJXTPZKM2P4DPD4X5VVJOTSRXLR7ANCNFSM4TKJZZWA>

.

--
Dave Archer, PhD https://galois.com/team/david-archer/
Principal Scientist
Galois, Inc. https://www.galois.com - 421 SW 6th Avenue, Suite 300,
Portland, OR 97204
email dwa<EMAIL_ADDRESS>SMS/phone +1(503)701-0235 (use Signal if possible)
https://www.mypronouns.org/he-him
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<
https://github.com/ge-high-assurance/RACK/issues/219#issuecomment-735880140>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/AO6MHPOFAHRT572ULSHXUWTSSO7JBANCNFSM4TKJZZWA>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ge-high-assurance/RACK/issues/219#issuecomment-737023704,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACJXTP6SLOGPO2PZYRDJE33SSXNMBANCNFSM4TKJZZWA
.

--
Dave Archer, PhD https://galois.com/team/david-archer/
Principal Scientist
Galois, Inc. https://www.galois.com - 421 SW 6th Avenue, Suite 300,
Portland, OR 97204
email<EMAIL_ADDRESS>SMS/phone +1(503)701-0235 (use Signal if possible)
https://www.mypronouns.org/he-him

Shortening above discussions for clarity:

we have what I might call a "religious argument" about generality (of relationship ranges, as well as cardinalities). By religious argument, I mean that there's likely no objective criteria by which to choose one of the opposing views.

there's also a similar disagreement about sub-classing at least one of the PROV-S relationships: wasDerivedFrom.

In looking over the ontology-review branch, the vast majority of the changes I suggested fall into one of these areas, following the design principles outlined in the ModelingGuidelines.sadl file in the branch. If the team decides in favor of generality on one hand and allowing the various subclass uses of wasDerivedFrom, then we may want to terminate that branch, and make a new pass over master to capture just the handful of concrete errata addressed in the ontology-review branch.
So, I'd suggest that this issue is blocked pending an explicit decision on the 2 bulleted issues above


167 mui grid user table

Fixes #167
Describe your changes
Table implemented for user view
Checklist before requesting a review

[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have added thorough tests

Codecov Report

Merging #179 (ea79621) into dev (49778a6) will increase coverage by 13.73%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##              dev     #179       +/-   ##
===========================================
+ Coverage   46.21%   59.94%   +13.73%
===========================================
  Files          75       46       -29
  Lines        3287     2377      -910
  Branches      451      195      -256
===========================================
- Hits         1519     1425       -94
+ Misses       1733      919      -814
+ Partials       35       33        -2

Flag
Coverage Δ

backend
59.94% <ø> (ø)

dev
59.94% <ø> (?)

frontend
?

staging
?

unit
59.94% <ø> (+13.73%)
:arrow_up:

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

Impacted Files
Coverage Δ

frontend/src/components/AdminView.tsx

frontend/src/components/AdminViewPollDataGrid.tsx

frontend/src/components/PollEditView.tsx

frontend/src/components/Registration.tsx

frontend/src/components/Sidebar.tsx

frontend/src/components/ResultOption.tsx

frontend/src/components/AdminViewUser.tsx

frontend/src/components/PollCreation.tsx

frontend/src/services/pollService.ts

frontend/src/components/NavBar.tsx

... and 18 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


x/mobile: handle assets on iOS

What version of Go are you using (go version)?

$ go version
go version go1.12.7 darwin/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/wucanrui/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/wucanrui/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12.7/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12.7/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/0_/j6m36l9s0psg9xm5ggt2_b680000gp/T/go-build792194215=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
I am new to IOS.
I build an IOS framework file by using gomobile.

In xxx package, I use asset.Open() to get the asset but it failed with log (no such file or directory). And then when I check the 'bind_iosapp.go' in gomobile, I find that it does not handle the "assets" directory at all.
What did you expect to see?
I can use my asset file in xxx.framework by using golang.
What did you see instead?
I see this tip on godoc of gomobile.(On iOS an asset is a resource stored in the application bundle. Resources can be loaded using the same relative paths). How can I get the asset file? Should I use the asset.Open API? What the path I should put the asset file into IOS is?

For asking questions about learning the language, see one of our forums: https://golang.org/wiki/Questions We only use this issue tracker for tracking bugs. People in the forums can explain what is happening here.


Feature Request - 4k output

Any way to encode the output video in higher resolution? 4k would keep most of the original density in case details need to be pulled later - like a license plate in the distance etc.

Use the --scale 1280x960 flag in your config file.
This keeps each individual video at its original size which gives you a 3840x1920 output video (based on also using the --WIDESCREEN flag)

Have you tried using parameter --quality? For file size there is also --compression

Closing


Make pull request for adding primary content to feature/body

Make pull request for adding primary content to feature/body

Make pull request for adding primary content to feature/body


Is it possible to access the library created with TwinCAT?

Is it possible to access the library created with TwinCAT?
when a library *.library is created, can it be accessed?

I'm not sure what do you mean.
If you have a library and then add it to a PLC project, you can read/write data from the library GVLs, programs etc.

I'm not sure what do you mean.
If you have a library and then add it to a PLC project, you can read/write data from the library GVLs, programs etc.

Hello @jisotalo,
Let me explain better, I would like to carry out unit tests of a *.library,

I do not want to install the *.library in any project, can this be done?
Another option could be to just install it in a project and make a reference in the project but not use it, having to call its FB in the project. Would this other option be viable?
The last option to carry out unit tests of a *.library I have to use it in the TwinCAT project by calling its FB and then it is the only way to carry out unit tests of developed libraries,
I hope it is better understood.

Hi @runtimevic

I do not want to install the *.library in any project, can this be done?

No, because the library needs to be running in a PLC runtime

Another option could be to just install it in a project and make a reference in the project but not use it, having to call its FB in the project. Would this other option be viable?

That's totally possible, however the FBs need to be instantiated somewhere (for example GVL inside library)


Extension causes high cpu load

Issue Type: Performance
Extension Name: LiveServer
Extension Version: 5.5.1
OS Version: Windows_NT x64 10.0.14393
VSCode version: 1.31.1

:warning: Make sure to attach this file from your home-directory: C:\Users\Alex-Hawk\ritwickdey.LiveServer-unresponsive.cpuprofile.txt :warning:
Find more details here: https://github.com/Microsoft/vscode/wiki/Explain:-extension-causes-high-cpu-load

Hello. few questions!!,
When you're getting this issue? after load of vscode or after clicking to Go Live ?
Is this happen every-time ? or random ?
Please reply here https://github.com/ritwickdey/vscode-live-server/issues/278
Duplicate of https://github.com/ritwickdey/vscode-live-server/issues/278

[Note: This issue is closed by a javascript code (written by me).
https://gist.github.com/ritwickdey/36682dabe4a992c57e4562c935bfbbdd ]

Thank You.


Syscall 599: Relocation type 6 is not supported

This error happens on both Amplitude and Project Diva X.
Amplitude log: amplog.txt
Project Diva X: PDXlog.txt

@ultimaweapon So, with some very simple testing, seems like it's just another one that can be {continue;}'d
Also, how tf do you get the function names-
/// See reloc_non_plt on the PS4 kernel for a reference.

You don't see its effect immediately that means putting continue seems like to work but it may not.
For the function name, if it is the official name from Sony you can find from the string list that is a logging message. Some logging messages will have a function name in it.

Tom Clancy The Division also requires Relocation type 6 as well.

^ We Are Doomed seems to also use this Relocation type.

Verify if there are any different with the PS4 kernel.

...Nah :P
Because once again, idfk how to.

You seem to mention this Relocation type in module/module.rs, but never define it elsewhere, like rtld, or the Relocation Type number it uses.

The module/module.rs is an old version before I saw the PS4 kernel while the rtld is a new version based on the PS4. We will eventually remove module when the rtld is completed.

Still, seems this Reloc is kinda important as a good half of my games use it...

I'll be working on this soon because it is required after the syscall 608 is finished.

Actually syscall 608 already finished but I did not commit the last part because the crash is awaiting ahead.

Actually syscall 608 already finished but I did not commit the last part because the crash is awaiting ahead.

Soon, I'll finally be able to end my "Part # of Syscall 608, woo!" counter in the Discord server. Lol.

I mean it, haha.

Mighty No. 9 also uses this relocation type.
Current list:
Amplitude
Hatsune Miku: Project Diva X
Mighty No. 9
The Division 2
We are Doomed
About 2/3rd of my extracted games use this relocation type.

Thanks for testing. This one is depend on #300.

Thanks for testing. This one is depend on #300.

Oh, another thing, some of my games have the SDK version error you added, want me to make an issue listing them?

Yep, please create a dedicated issue for it.


Action: increase timeout for docker step

to 20 mins

This was done in https://github.com/pombase/fypo/commit/23a1413778b3a49053a7f7773305b43e5fc0fa85


WIP: Add password option

[ ] Add some tests

Codecov Report

Merging #2 into master will decrease coverage by 4.44%.
The diff coverage is 93.1%.

@@            Coverage Diff             @@
##           master       #2      +/-   ##
==========================================
- Coverage     100%   95.55%   -4.45%
==========================================
  Files           1        1
  Lines          21       45      +24
==========================================
+ Hits           21       43      +22
- Misses          0        1       +1
- Partials        0        1       +1

Impacted Files
Coverage Δ

handler.go
95.55% <93.1%> (-4.45%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 85f12c6...ef5b99d. Read the comment docs.


install page wrong for version 2.0 alpha

on page https://www.tensorflow.org/install/pip
change "tensorflow==2.0.0-alpha0" to "tensorflow==2.0.0-a0"    (two instances)
change "tensorflow-gpu==2.0.0-alpha0" to "tensorflow-gpu==2.0.0-a0"
change "tensorflow==2.0.0-alpha0-gpu" to "tensorflow-gpu==2.0.0-a0"
on page https://www.tensorflow.org/install/gpu
change "tensorflow==2.0.0-alpha0" to "tensorflow==2.0.0-a0"
i had to make these changes on my ubuntu-18-04 system to get it to install.

pip install tensorflow-gpu==2.0.0-alpha0 and
pip install tensorflow==2.0.0-alpha0 work as expected.
I was able to download the wheel and install it successfully.

you are right, they are both there.  I had tried "tensorflow==2.0.0-alpha0-gpu" and when that did not work just went looking around and came across the a0 aliases.
I do believe that that "tensorflow==2.0.0-alpha0-gpu" reference is actually wrong, but the others are correct.

Yes you are right about the tensorflow==2.0.0-alpha0-gpu we have to correct it. Thanks!

@zadeck It has been fixed now. Thanks!


Multisig account transfer view - mosaics not visible

Steps:

Create multisig.
Create mosaics for multisig and for cosigners.
Go to transfer view
Switch account to multisig

Result: Mosaics available for multisig are not visible
Video: https://www.loom.com/share/feb80de98cb24098b479977d359663f6

Fixed.


Support CodecID 12 for HEVC

Several existing implementations used CodecID of 12 to support HEVC before this project began, and there are also hardware implementations based on those concepts, so could this be added to Enhanced RTMP as well?

Hey Dave,

Gotcha, can you list some of the hardware and software implementations
let's us consider this
curious: switching to fourcc HEVC is straight forward and minimal work. Is that not possible?

thx

Here's some of the implementations that I'm aware of:

https://github.com/ossrs/srs/issues/465
https://github.com/ksvc/FFmpeg/wiki
https://github.com/shogo4405/HaishinKit.swift/issues/343
https://blog.wmspanel.com/2019/05/support-hevc-rtmp-nimble-streamer-larix.html

I agree that switching appears to be doable, but getting all of the existing implementations to do this can be a difficult and the even bigger challenge is then upgrading all of the existing installs
And then when you consider all of the existing content that has been generated over the years with CodecID of 12, it would be really nice to have that brought into the standard as valid. From my perspective, it could be introduced as "deprecated" or "not recommended", so future implementations and uses would be using fourcc but all of the existing usage would still work as is

i'm concerned that making "id 12 == HEVC" official is a negative incentive to transition to the fourCc way, no matter how much you say it's "deprecated" or "NOT RECOMMENDED", especially given the inertia of existing implementations.

there is no Protocol Police, and nobody is stopping anyone from using any codec ID any way they want (i'm currently using audio codec id 15 ("Device Specific") for Opus in my Javascript+WebCodecs implementation). the only reason to document video codec id 12 as HEVC would be to encourage interoperation and adoption in new implementations, but new implementations should be preferring the fourCc way.
IMO use of any "unassigned" or "reserved" code points should be considered ad hoc, uncoordinated, and nonstandard, and especially now that there's Enhanced RTMP, doing so should be considered "NOT RECOMMENDED".

Hey David,
I understand the suggestion and appreciate you bringing it up. After thinking about this some more, it feels like the best course of action is to leave this alone. Some of the thinking behind this is:

Introducing CodecID 12 for HEVC as part of the spec while at the same time deeming it as “deprecated” or “not recommended” feels at odds with each other and ultimately will not have any real effect.

While unlikely,  Introducing CodecID 12 for HEVC, could perhaps be incompatible with other unofficial implementations.

Leaving this alone will not break anything, and future implementations for HEVC will be compelled to adopt the FourCC approach as outlined in the enhanced RTMP specification.

Hope this helps. I will close this issue out for now. If a compelling argument comes up, we will reopen.
Thanks!

closing per previous reason (https://github.com/veovera/enhanced-rtmp/issues/24#issuecomment-1731658053)


resource autodetection

It would be nice to have resource auto-detection, similar to what exists in opentelemetry-js. The logic was largely ported from OpenCensus Node:
https://github.com/open-telemetry/opentelemetry-js/pull/899
There is little to no specification for it at this time, there is a related issue:
https://github.com/open-telemetry/opentelemetry-specification/issues/535

@robertlaurin can you please comment here so I can assign this one to you? 😄

Hey 👋, I'm going to work on this :)

I referenced the OpenTelemetry Collector's implementation of resource auto-discovery on today's SIG call. Turns out it's a little more Kubernetes-specific (and much more complicated) than I thought: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/master/processor/k8sprocessor. I'm not sure how much we can usefully extract from it.

Do we consider this fixed by #263 or do we want to leave this open to add resource detection for platforms other than GCP?

From last week's call, we decided to close this with #263 and open new issues for platforms other than GCP.


Create KMP.cpp

KMP string matching algo with time and space complexity and explanation with comment

add your name in contribute.txt

Hey This is Frontman Speaking
Check Your Hacktoberfest Profile, I think Your Contribution is accepted. ✨✨✨


[Preliminary] Build es5 components

intention to build components as es5 imports so we don't rely on the build system of the individual projects these components are used in
proxying react and react-dom to preact will always be needed.
status: this is in dev phase. not stable yet.

@faboweb can this be closed now?


Please make a colab notebook for this 😪

I tried making one. but it says
CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.
To initialize your shell, run
idk what to do

Hey I will, probably this or next weekend.  I'll add a jupyter notebook hopefully that'll help.

Hey I will, probably this or next weekend.  I'll add a jupyter notebook hopefully that'll help.


Add generic image

This image can be used as reference "generic" image
for any architectures supported by debian.
Boot on PC (x86 or x86_64) is supported thanks to grub,
extra tweaking might be needed to boot other architectures
on virtual machines.
For the record, this is inspired from recipes
I wrote for emilia pinball.
Change-Id: I709a456f196df337c3f368f03416defe6aadcb0b
Signed-off-by: Philippe Coval<EMAIL_ADDRESS>

Review welcome
cc: @sjoerdsimons

Review welcome
cc: @sjoerdsimons

I opened a PR for a generic EFI image: https://github.com/go-debos/debos-recipes/pull/21


[Migration] Handle currency conversion

Details
In HANA there are predefined table names which are associated with currency conversion - see https://help.sap.com/docs/HANA_CLOUD_DATABASE/460112ecd20e42c0a647979434b32412/fcb8efe0cf8b45d2bbb2a885ae74868c.html?version=2021_01_QRC&locale=en-US
In HANA on Neo you could omit the tables, but in HANA Cloud they must be explicitly stated
Target
Create currencyConversionTables element in the calculationview based on the existence of the following tables: TCURC, TCURF, TCURN, TCURR, TCURT, TCURV, TCURW, and TCURX
<currencyConversionTables rates="TCURR" configuration="TCURV" prefactors="TCURF" notations="TCURN" precisions="TCURX"/>

This issue is closed as the project is no longer maintained


usa-state-list is featured in a Vaadin blog

Hi biztek,
Recently, I wrote the article Dropdown components with ready-to-use data with your component featured in it. I believe your component is very useful and thus, I want to introduce it to people.
Feel free to drop a comment down below and have a nice day!
Regards,
Binh

@binhbbbb
Thanks @binhbbbb .
BTW: Vaadin used to be located in the same office as Biztek in San Jose, CA (before they moved to Sunnyvale). Great to see Vaadin doing amazing work.

The components need some work :(
but pls feel free to add the badges.


Create .version inside container

This PR adds /.version file inside container to mimic what kubevirt containers already do, and to help to understand which git tree / archive were used to build the image.

@booxter how would I use it? When something goes wrong, I just log into the Pod and check for the .version file or is there some smarter way how to use it?

Thanks a lot @booxter

I pushed a new image to Quay.io, it should include the version file


Support Yosemite+ traffic lights

Fixed an issue where the window traffic lights reverted to pre-Yosemite
style in El Capitan and higher (Reworked OS identification).

I think that's already part of #526.
I don't know why it hasn't been merged yet, though.


Recommend using GitHub private reporting

Recommend that people use GitHub private reporting. Yes, it's technically only in "beta", but it is easy to use by many, and that's a key advantage of it.

@SecurityCRob - Can the vulnerability disclosure WG discuss this PR (as well the soon-to-be-proposed PR on encrypted emails)? I think we need to make reporting maximally easy. Now that GitHub has added this feature (thank you GitHub!), let's be sure to tell people to use it.

For sure!  We can slot it for our next WG call.
Cheers,
CRob
Director of Security Communications
Intel Product Assurance and Security
From: David A. Wheeler @.>
Sent: Friday, March 24, 2023 3:23 PM
To: ossf/oss-vulnerability-guide @.>
Cc: Robinson, Christopher @.>; Mention @.>
Subject: Re: [ossf/oss-vulnerability-guide] Recommend using GitHub private reporting (PR #47)
@SecurityCRobhttps://github.com/SecurityCRob - Can the vulnerability disclosure WG discuss this PR (as well the soon-to-be-proposed PR on encrypted emails)? I think we need to make reporting maximally easy. Now that GitHub has added this feature (thank you GitHub!), let's be sure to tell people to use it.
—
Reply to this email directly, view it on GitHubhttps://github.com/ossf/oss-vulnerability-guide/pull/47#issuecomment-1483301841, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQRFDLBENOLZ3H6HWLYCZLDW5XYA3ANCNFSM6AAAAAAWG6IUHI.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>

This was approved, & I know of no complaints, so I'm merging this. Thank you everyone!


Add ability in CollectSQLProfile.ps1 to read instances from a file

If many instances are to be scanned, we have to put the CollectSQLProfile.ps1 script in a loop to avoid hitting the maximum character limit for a command line.

Feature added.


Fix error when using train_model without passing in callback_objects

The default for callback_objects in train_model is currently [None](https://github.com/icenet-ai/icenet/blob/main/icenet/model/train.py#L31), but this will raise an error as there's an attempt to concatenate a list with None.
Fix by making the default an empty list.

Fixed in @rchan26 so have unassigned while I evaluate what's left in 0.2.6 to fix 😉


Hide history button on models

Right now there isn't an option to not print that button on models if the feature is unused.
https://github.com/unfoldadmin/django-unfold/blob/6772bcf19735041e161c1d56395482604f8bedc7/src/unfold/templates/admin/change_form_object_tools.html#L6

Is it possible to disable this link in Django admin?

I am not sure but as this projects has custom parameters I think that is something easy to do.

As of today, there doesn't seem to be a native feature in Django Admin to hide the history button. However, with the latest unfold templates, you can easily rewrite templates/admin/change_form_object_tools.html to achieve that.

Yes it is possible but if history is not enabled in the model clicking that button will show that error so maybe this dashboard can improve that UX automatically checking if the history is enabled/exist and add the button.

Easy thing.
Add one attribute in your ModelAdmin class, like.
class ProductModelAdmin(ModelAdmin):
display_history_button = False
Overwrite templates/admin/change_form_object_tools.html as below.
from
{% trans 'History' as title %}
{% add_preserved_filters history_url as link %}
{% include "unfold/helpers/tab_action.html" with title=title link=link %}

to
{% if display_history_button %}
    {% trans 'History' as title %}
    {% add_preserved_filters history_url as link %}
    {% include "unfold/helpers/tab_action.html" with title=title link=link %}
{% endif %}

Also, modify changeform_view method, update
    extra_context.update(
        {
            "actions_submit_line": self.get_actions_submit_line(request),
            "actions_detail": actions,
        }
    )

to
    extra_context.update(
        {
            "actions_submit_line": self.get_actions_submit_line(request),
            "actions_detail": actions,
            "display_history_button: self.display_history_button,
        }
    )

If you wanna achieve object-level history button display on/off, add in BooleanField display_history_button in your model, and change the above codes to
    extra_context.update(
        {
            "actions_submit_line": self.get_actions_submit_line(request),
            "actions_detail": actions,
            "display_history_button: YourModel.objects.get(id=object_id).display_history_button,
        }
    )

These codes haven't been verified. Use them at your own risk. But I think they should work.


3D not working with 0.4.x

Hi, there is no example for angular2-highcharts that uses highcharts-3d. I have been trying quite a bit but without any luck. I am using it with Ionic 2, but at this point Ionic is not the reason.
Examples:
import { Highcharts } from 'angular2-highcharts';
import Highcharts3d from 'highcharts/highcharts-3d';
Highcharts3d(Highcharts);

leads to
11:32:28]  Module '"node_modules/angular2-highcharts/index"' has no exported
            member 'Highcharts'.
[11:32:28]  ngc failed

This
import Highcharts from 'highcharts/highcharts';
import Highcharts3d from 'highcharts/highcharts-3d';
Highcharts3d(Highcharts);

compiles but still shows 2D charts.
How do you achieve 3D charts with angular2-highcharts?

see https://github.com/gevgeny/angular2-highcharts#installation

Yes, I did read that, and tried it before without success, but I don't remember the error message.
Doesn't matter, because now, with this code
import * as Highcharts from 'highcharts';
import * as Highcharts3d from 'highcharts/highcharts-3d';

Highcharts3d(Highcharts);

and these versions:
   "angular2-highcharts": "0.4.1",
   "highcharts": "5.0.2",
   "@types/highcharts": "4.2.40"

it finally works! Thanks!

you don't need install highcharts at all.


Fix cmake setup for yocto

The current cmake setup of the pigpio project was incompatible with a yocto build for the raspberry pi. For some reason it had problems finding standard header files like <stdio.h>. However the builds succeeded on non Yocto builds which reinforced my suspicion that the CMake setup was the cause.
Nevertheless I modernized the CMake setup, which now also builds in a yocto environment :D. The new CMake conforms with the current CMake 3.0 standard. As such the following features are available.

Usage of CMAKE_INSTALL_PREFIX instead of the custom DEST_DIR
Usage of CMAKE_BUILD_TYPE to determine Release/Debug or RelWithDebInfo builds.
Usage of CMake versioning system
Create a CMake importable package configuration for all configurations.
Create a CMake installer via CPack (build the package target)
Usage of dependency handling via CMake target architecture (no more add_dependencies)
Finding of external dependencies via CMake (CMake will raise an error if -lpthread or -lrt are not present on the system)
Moved the option like option (BUILD_SHARED_LIBS) to an actual option (default is ON).
Removed the uninstall target (CMake tracks all install commands and provides an uninstall target, however this is not compatible with the custom python module setup.py)

I wrote these enhancements for our own raspberry pi yocto builds, which require pigpio. We used to use WiringPi, however that project got disbanded by the maintainer himself, which is sad. Nevertheless the pigpio project works equally amazing.

I have no knowledge or experience of using CMake so can not judge the merits of this request.
That said, I am happy to accept this as long as no one objects within a few days.

I would like to second this issue, I was hunting down this for a couple of hours today for my own yocto build until I solved it myself with a patch. It would be great if this was merged.

I'll try to include this in the next release sometime in March.

@GertRozing Do you have pigpio recipe which works with this PR? coud you share it? I would like to add pigpio to my yocto build. Thank you.

I have this recipe. It comes with it's own patch to prevent the issue here, but you can now of course just ditch that. It is also not very sophisticated, but it gets you going.
DESCRIPTION = "pigpio "
SECTION = "devtools"
LICENSE = "CLOSED"
LIC_FILES_CHKSUM = "file://UNLICENCE"

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI = "git://github.com/joan2937/pigpio.git;protocol=https;tag=${PV}\
    file://0001-Fix-CFLAGS-so-cross-compilation-in-YOCTO-works.patch\
    file://pigpiod.sh\
    "

S = "${WORKDIR}/git"

inherit pkgconfig cmake update-rc.d

RDEPENDS_${PN} = "python3"

FILES_${PN} += "${bindir}/pigpiod\
    ${libdir}/libpigpio.so\
    ${libdir}/libpigpiod_if.so\
    ${libdir}/libpigpiod_if2.so\
    ${libdir}/python3.7/site-packages/pigpio.py\
"

FILES_${PN}-dev = "${includedir}"

INITSCRIPT_NAME = "pigpiod"
INITSCRIPT_PARAMS = "start 01 5 3 2 . stop 99 0 1 6 ."

do_install() {
    install -d ${D}${bindir}
    install -d ${D}${libdir}
    install -d ${D}${libdir}/python3.7/site-packages

    install -m 0755 pigpiod ${D}${bindir}
    install -m 0755 libpigpio.so ${D}${libdir}
    install -m 0755 libpigpiod_if.so ${D}${libdir}
    install -m 0755 libpigpiod_if2.so ${D}${libdir}
    install -m 0644 ${S}/pigpio.py ${D}${libdir}/python3.7/site-packages

    install -d ${D}${sysconfdir}/init.d
    install -m 0755 ${WORKDIR}/pigpiod.sh ${D}${sysconfdir}/init.d/pigpiod
}

@dir-ableton  thanks, I will give it a try


fix(aws): remove duplicate bucket logging rule

We already have a bucket logging rule.
See https://github.com/aquasecurity/trivy/issues/4975

@simar7 The tests failed at the OPA install stage: sha256sum: checksum: no properly formatted SHA256 checksum lines found

These are the rules I moved into the rules/ dir recently https://github.com/aquasecurity/defsec/commit/91898b5a97b9f7952205e8c2544ebcc9b3602fae do we have any other rules that also exist in Go that overlap with these? If so, we should remove them (Go rules).

@simar7 OK, I'll return rego and remove the GO rule. By the way, the rego rule contained an invalid AVD ID.

Is it possible this duplication also generates a false positive when you do something like this?:
# tfsec:ignore:aws-s3-enable-bucket-logging
# tfsec:ignore:aws-s3-enable-versioning
resource "aws_s3_bucket" "this" {
  bucket        = var.name
}

Hi @davidbmleach
If this comment doesn't help you, could you describe in more detail what happened to you and what you expected to see?

@simar7 I updated the config for golangci-lint and added ignoring U1000 (unused variables) for variables in those files referenced from Rego. I noticed that now golangci-linter uses the following linters to check dead code: unused, struct check, deadcode and varcheck. All of them except unsuded are deprecated. How about updating the config?

@simar7 I updated the config for golangci-lint and added ignoring U1000 (unused variables) for variables in those files referenced from Rego. I noticed that now golangci-linter uses the following linters to check dead code: unused, struct check, deadcode and varcheck. All of them except unsuded are deprecated. How about updating the config?

Sounds good. Let's create a separate issue and track it there.


MM-36218,MM-36219: CRT thread read flashes

Summary
New messages that arrive while the thread is open are marked as read and
the indicators don't flash anymore.
Furthermore if a thread is manually marked as unread it should stay
unread even if new messages arrive while it's open.
Ticket Link
https://mattermost.atlassian.net/browse/MM-36218
https://mattermost.atlassian.net/browse/MM-36219
Release Note
NONE

@hmhealey @jgilliam17 please help with priority reviews if possible

Going to merge to get this in but @koox00 feel free to create follow-up PRs/tickets if you'd like to address Harrison's comments


Nested CMake fails to link.

Hi everyone! I am making a sort of game engine using glfw as the windowing system. The way that my setup work is the following.
I have a series of engine libraries which gets built with a top-level cmake file. As part of that CMake file, I add the subdirectory with the glfw CMake and build from source. No problem so far.
Then when I build the game, I add as subdirectory the top level of the engine library so everything gets built together. Now everything works fine except for glfw won't link, all the engine libraries get linked fine.
During the process glfw gets built no problem, it just seems like CMake doesn't seem to be able to recognize that it built glfw aswell. Now since everything else works fine, I am wondering if glfw does something weird that might confuse CMake? If I add glfw as subdir on the top level of the game it works and links fine with glfw too.
Here is how I add subdirectory in the engine:
set(GLFW_BUILD_TESTS OFF CACHE BOOL "Build shared libraries" FORCE)
set(GLFW_BUILD_EXAMPLES OFF CACHE BOOL "Build the GLFW example programs" FORCE)
set(GLFW_BUILD_DOC OFF CACHE BOOL "Build the GLFW documentation" FORCE)
set(GLFW_INSTALL OFF CACHE BOOL "Generate installation target" FORCE)
add_subdirectory(middleware/glfw)
add_subdirectory(src/core)
add_subdirectory(src/animation)
add_subdirectory(src/rendering)

Here is how I add the subdirectories for the game :
add_subdirectory(internal/WW_engine)
add_subdirectory(platfoorm)

The above configuration is the one that doesn't work, keep in mind that all the lib built from src/core, animation, rendering etc all build no problem.
Instead, if I move the subdirectory of glfw from the engine to the game works like a charm, same exact code.
set(GLFW_BUILD_TESTS OFF CACHE BOOL "Build shared libraries" FORCE)
set(GLFW_BUILD_EXAMPLES OFF CACHE BOOL "Build the GLFW example programs" FORCE)
set(GLFW_BUILD_DOC OFF CACHE BOOL "Build the GLFW documentation" FORCE)
set(GLFW_INSTALL OFF CACHE BOOL "Generate installation target" FORCE)
add_subdirectory(middleware/glfw)
add_subdirectory(internal/WW_engine)
add_subdirectory(platfoorm)

I tried not disabling anything from glfw build but still same issue. Can you think of anything that might cause the issues?
M.
PS: If any more info is needed let me know.

During the process glfw gets built no problem, it just seems like CMake doesn't seem to be able to recognize that it built glfw aswell.

What does this bit mean, exactly?

Hi, it means that, if I generate a visual studio solution for my project, glfw gets it s own solution and gets built as part of the project:

But then, when in the game's cmake I write:
add_executable(platfoorm ${SOURCE_FILES} ${INCLUDES_FILES})
target_link_libraries(platfoorm glfw engine WW_engine WW_engineAnim WW_engineRender  OpenGL32 ${TBB_IMPORTED_TARGETS})

For all my WW_* libraries cmake provides them with a relative path, meanwhile, glfw gets linked as just glfw3.lib almost like cmake cannot figure out that it built that library and to add the relative path to it aswell. here is what I would get in VS:

If I do hardcode the path where glfw3.lib gets built then it works fine, of course, won't work if I try to build it any other place. Hope it helps any question or clarification I am happy to provide.

Thank you, that was very clear!
I don't know if this bug is in CMake, in our CMake files or in yours. I'm finishing up the next release and can't look into this right now.

I'll be traveling next week when I'll come back I will clean up my projects and open source them so if you need to have a look or repro should be fairly straightforward to do so. Then we can see whats what.
M.


Bulb continues to show old color in HA app after switching to white mode

Describe the bug
I'm able to control the colour and temperature of this bulb no problems. If I've set an RBG colour, and then I change the temperature, the bulb switches to white as I would expect. However the colour of the bulb shown in the Home Assistant app doesn't update, and continutes to show the old colour. The reported colour does correctly update in both TuyaSmart, and when using TuyaLocal.
Expected behavior
The bulb entity colour shown in the Home Assistant app should change to white when the white temperature is adjusted while the bulb is in a color mode, to match the actual bulb.
Home Assistant Version

e.g. 2021.7.1

Device info
{
"active_time":<PHONE_NUMBER>,
"biz_type": 0,
"category": "dj",
"create_time":<PHONE_NUMBER>,
"icon": "smart/product_icon/dj.png",
"id": "aaaaaaaaaaa",
"ip": "xxxxxxxxxxxxxxxx",
"lat": "xxxxxxxxxx",
"local_key": "xxxxxxxxxxxxx",
"lon": "-xxxxxxxxxx",
"name": "Night Light",
"online": true,
"owner_id": "18344533",
"product_id": "8UhAGZyCrYqYAcEc",
"product_name": "RGBCW light",
"status": [
{
"code": "switch_led",
"value": true
},
{
"code": "work_mode",
"value": "colour"
},
{
"code": "bright_value",
"value": 136
},
{
"code": "temp_value",
"value": 109
},
{
"code": "colour_data",
"value": "{"h":360.0,"s":218.0,"v":133.1}"
},
{
"code": "scene_data",
"value": "{"h":37.5,"s":255.0,"v":189.0}"
},
{
"code": "flash_scene_1",
"value": "{"bright":255,"frequency":80,"hsv":[{"h":120.0,"s":255.0,"v":255.0}],"temperature":255}"
},
{
"code": "flash_scene_2",
"value": "{"bright":255,"frequency":128,"hsv":[{"h":0.0,"s":255.0,"v":255.0},{"h":120.0,"s":255.0,"v":255.0},{"h":240.0,"s":255.0,"v":255.0},{"h":0.0,"s":0.0,"v":0.0},{"h":0.0,"s":0.0,"v":0.0},{"h":0.0,"s":0.0,"v":0.0}],"temperature":255}"
},
{
"code": "flash_scene_3",
"value": "{"bright":255,"frequency":80,"hsv":[{"h":0.0,"s":255.0,"v":255.0}],"temperature":255}"
},
{
"code": "flash_scene_4",
"value": "{"bright":255,"frequency":5,"hsv":[{"h":0.0,"s":255.0,"v":255.0},{"h":120.0,"s":255.0,"v":255.0},{"h":60.0,"s":255.0,"v":255.0},{"h":300.0,"s":255.0,"v":255.0},{"h":240.0,"s":255.0,"v":255.0},{"h":0.0,"s":0.0,"v":0.0}],"temperature":255}"
}
],
"sub": false,
"time_zone": "+00:00",
"uid": "eu16044126174017IJNM",
"update_time":<PHONE_NUMBER>,
"uuid": "3458238010521ccc0827"
}
Device specifications
2021-07-26 10:09:42 DEBUG (SyncWorker_0) [tuya iot] Request: method = GET, url = https://openapi.tuyaeu.com/v1.0/devices/aaaaaaaaaaa/specifications, params = None, body = None, headers = {'client_id': 'xxxxxxxxxxxxxxx', 'sign': 'xxxxxxxxxxxxxxx', 'sign_method': 'HMAC-SHA256', 'access_token': 'xxxxxxxxxxxxxxx', 't': '1627290582093', 'lang': 'en'}
2021-07-26 10:09:42 DEBUG (SyncWorker_0) [tuya iot] Response: {
"result": {
"category": "dj",
"functions": [
{
"code": "switch_led",
"type": "Boolean",
"values": "{}"
},
{
"code": "bright_value",
"type": "Integer",
"values": "{"min":25,"scale":0,"unit":"","max":255,"step":1}"
},
{
"code": "work_mode",
"type": "Enum",
"values": "{"range":["white","colour"]}"
},
{
"code": "temp_value",
"type": "Integer",
"values": "{"min":0,"scale":0,"unit":"","max":255,"step":1}"
},
{
"code": "colour_data",
"type": "Json",
"values": "{"h":{"min":1,"scale":0,"unit":"","max":360,"step":1},"s":{"min":1,"scale":0,"unit":"","max":255,"step":1},"v":{"min":1,"scale":0,"unit":"","max":255,"step":1}}"
},
{
"code": "scene_data",
"type": "Json",
"values": "{"h":{"min":1,"scale":0,"unit":"","max":360,"step":1},"s":{"min":1,"scale":0,"unit":"","max":255,"step":1},"v":{"min":1,"scale":0,"unit":"","max":255,"step":1}}"
},
{
"code": "flash_scene_1",
"type": "Json",
"values": "{"h":{"min":1,"scale":0,"unit":"","max":360,"step":1},"s":{"min":1,"scale":0,"unit":"","max":255,"step":1},"v":{"min":1,"scale":0,"unit":"","max":255,"step":1}}"
},
{
"code": "flash_scene_2",
"type": "Json",
"values": "{"h":{"min":1,"scale":0,"unit":"","max":360,"step":1},"s":{"min":1,"scale":0,"unit":"","max":255,"step":1},"v":{"min":1,"scale":0,"unit":"","max":255,"step":1}}"
},
{
"code": "flash_scene_3",
"type": "Json",
"values": "{"h":{"min":1,"scale":0,"unit":"","max":360,"step":1},"s":{"min":1,"scale":0,"unit":"","max":255,"step":1},"v":{"min":1,"scale":0,"unit":"","max":255,"step":1}}"
},
{
"code": "flash_scene_4",
"type": "Json",
"values": "{"h":{"min":1,"scale":0,"unit":"","max":360,"step":1},"s":{"min":1,"scale":0,"unit":"","max":255,"step":1},"v":{"min":1,"scale":0,"unit":"","max":255,"step":1}}"
}
],
"status": [
{
"code": "switch_led",
"type": "Boolean",
"values": "{}"
},
{
"code": "work_mode",
"type": "Enum",
"values": "{"range":["white","colour"]}"
},
{
"code": "bright_value",
"type": "Integer",
"values": "{"min":25,"scale":0,"unit":"","max":255,"step":1}"
},
{
"code": "colour_data",
"type": "Json",
"values": "{"h":{"min":1,"scale":0,"unit":"","max":360,"step":1},"s":{"min":1,"scale":0,"unit":"","max":255,"step":1},"v":{"min":1,"scale":0,"unit":"","max":255,"step":1}}"
},
{
"code": "scene_data",
"type": "Json",
"values": "{"h":{"min":1,"scale":0,"unit":"","max":360,"step":1},"s":{"min":1,"scale":0,"unit":"","max":255,"step":1},"v":{"min":1,"scale":0,"unit":"","max":255,"step":1}}"
},
{
"code": "flash_scene_1",
"type": "Json",
"values": "{"h":{"min":1,"scale":0,"unit":"","max":360,"step":1},"s":{"min":1,"scale":0,"unit":"","max":255,"step":1},"v":{"min":1,"scale":0,"unit":"","max":255,"step":1}}"
},
{
"code": "flash_scene_2",
"type": "Json",
"values": "{"h":{"min":1,"scale":0,"unit":"","max":360,"step":1},"s":{"min":1,"scale":0,"unit":"","max":255,"step":1},"v":{"min":1,"scale":0,"unit":"","max":255,"step":1}}"
},
{
"code": "flash_scene_3",
"type": "Json",
"values": "{"h":{"min":1,"scale":0,"unit":"","max":360,"step":1},"s":{"min":1,"scale":0,"unit":"","max":255,"step":1},"v":{"min":1,"scale":0,"unit":"","max":255,"step":1}}"
},
{
"code": "flash_scene_4",
"type": "Json",
"values": "{"h":{"min":1,"scale":0,"unit":"","max":360,"step":1},"s":{"min":1,"scale":0,"unit":"","max":255,"step":1},"v":{"min":1,"scale":0,"unit":"","max":255,"step":1}}"
},
{
"code": "temp_value",
"type": "Integer",
"values": "{"min":0,"scale":0,"unit":"","max":255,"step":1}"
}
]
},
"success": true,
"t":<PHONE_NUMBER>157
}
Additional context
Add any other context or logs about the problem here.

I am having the same issue

i also have the same

I would like to expand on this a little bit. It seems that Home Assistant is not aware of the "white mode" of the bulbs.
Like you said, changing the colour is not a problem, but there is no white option as well.
That means, that I have to change to white manually via the app and Home Assitant - not knowhing what white is, reports the last known colour.

I would like to expand on this a little bit. It seems that Home Assistant is not aware of the "white mode" of the bulbs.
Like you said, changing the colour is not a problem, but there is no white option as well.
That means, that I have to change to white manually via the app and Home Assitant - not knowhing what white is, reports the last known colour.

i think this is related https://github.com/tuya/tuya-home-assistant/issues/131

I would like to expand on this a little bit. It seems that Home Assistant is not aware of the "white mode" of the bulbs.
Like you said, changing the colour is not a problem, but there is no white option as well.
That means, that I have to change to white manually via the app and Home Assitant - not knowhing what white is, reports the last known colour.

i think this is related #131

Yeah, seems that both of these are tightly connected.

Having the same issue.

I too am having the same issue, Also the effects dropdown is missing which I know my light supports.
interestingly in the HA Lovelace dashboard when the light is on in its White mode "had to set it from the Tuya App" the icon shows a grey instead of yellow when turned on

Setting supported features to 21 seems to rectify the issue. Though it would be better if it picked this up automatically

Setting supported features to 21 seems to rectify the issue. Though it would be better if it picked this up automatically

Can you explain how can one do that? I honestly just started using this integration and never changed supported features manually.

I am having the same issue, and I've also noticed that the color_mode stays as hs when switching to a white value.
With my lifx bulbs the mode becomes color_temp and the bulb shows the right white state!

Same issue here.  I have tried adding all kinds of supported features in customizations by following several guides, but nothing has worked yet.  My bulbs are Merkury and Smart Life app has ability to choose white but HA doesn't.  I just get rgb 255,255,255 but it doesn't use the white LEDs.

See issue #131 and several others.  No fix as far as I know, but trying to get more attention to these issues.

Plus 1
Get Outlook for Androidhttps://aka.ms/AAb9ysg

From: mikesellt @.>
Sent: Saturday, August 7, 2021 3:13:35 PM
To: tuya/tuya-home-assistant @.>
Cc: iotinkognito @.>; Comment @.>
Subject: Re: [tuya/tuya-home-assistant] Bulb continues to show old color in HA app after switching to white mode (#234)
See issue #131https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftuya%2Ftuya-home-assistant%2Fissues%2F131&data=04|01||aca610a7777f4ee427c408d95972e5b6|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637639172279723061|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=XFJH28HKUhzYKydLkvjAN%2BOm0GmKAkSpFR2g%2BYBGR70%3D&reserved=0 and several others. No fix as far as I know, but trying to get more attention to these issues.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftuya%2Ftuya-home-assistant%2Fissues%2F234%23issuecomment-894617433&data=04|01||aca610a7777f4ee427c408d95972e5b6|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637639172279733017|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=I9VFdwi7X%2Fdo%2BxLvLWrzjm5GlSXUa%2BERa9BGcWRh7Qg%3D&reserved=0, or unsubscribehttps://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FATTKFENAXEFUF7POK4QKRR3T3TMJ7ANCNFSM5A7X2AIQ&data=04|01||aca610a7777f4ee427c408d95972e5b6|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637639172279733017|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=LwWcgA6Ye1FM3%2FcD5l9Ha4br8KMfFAGqm8BiuvvMkuM%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01||aca610a7777f4ee427c408d95972e5b6|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637639172279742976|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=yzYDVZUTkNntnPQ6QxHlugNsFDrg4KbdSXTwMR3hpXs%3D&reserved=0 or Androidhttps://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26utm_campaign%3Dnotification-email&data=04|01||aca610a7777f4ee427c408d95972e5b6|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637639172279742976|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=THY8YDAtYh1lgw3xr1dSC1B19236lyEu83da2PYcbFA%3D&reserved=0.

I am having the same issue with a similar light. A Merkury BW904 Smart Bulb.  I am a sometimes hobby coder so I know enough to read the code and have an idea of what it is doing but I don't know enough right now about HA Dev to fix it myself.  I wanted to add my observations about what is/is not happening and, at least generally, what needs to be done I think.
To start with, in a nutshell, there are few types of lights that fall under category "dj" :

White - single temperature
White - adjustable temperature
Color only
Color with white - single temp
Color with white - adjustable temp

Referencing the code for lights on the Tuya_v2  github.
From what I see, each time the integration polls the API for the device it looks at the status responses and determines what options the device supports.  Currently, the integration only sends 3 of the things to HA:
(code lines 14-16)
    SUPPORT_BRIGHTNESS,
    SUPPORT_COLOR,
    SUPPORT_COLOR_TEMP

If your device does not have Color Temp in the status, you do not get color temp adjustment in the UI even if you try and change it in the customizations.
When you change the brightness, the code will look at the Work_Mode to see if it is color or white so it knows how to adjust the brightness but it will not change the work mode.
(Code lines 164 - 183)
If the color wheel on the UI is used to change the color while it is in white Work_Mode, it will change the Work_Mode to color.
(Code lines 185 - 210, Specifically lines 209-210)
The ONLY time the Work_Mode is changed to white  is if the Color_Temp is changed and it is not in white Work_Mode
(Code lines 212 - 233, Specifically lines 232 - 233)
As it stands right now, the easiest way that I see for them to fix this is to add the color temp option to the lights that have a work_mode status.  or at least make it so the color temp option is able to be set in the customizations.  The only potential issue I see is that the Work_Mode status does not necessarily mean it supports both color and white because it also supports other options (ref. Tuya Standard instruction set of lights (dj).
An additional issue I see creating upon us that will have an effect on this and maybe why they aren't pushing code changes heavily is, the way light features/color modes for lights are being handled in Home Assistant is changing some of them have been deprecated and will be removed with Home Assistant Core 2021.10 (Oct. I am assuming since we are on 2021.8.x now)
Please feel free to correct me where I am wrong or just add your input.
Cross posted  to #131, #234, and #308

Same here with both Mirrabella Genio bulbs and Connect Smart Home bulbs.


[Godot 4] Editing property in inspector triggers node rename

Godot version
4.0.beta6.official (7f8ecffa5)
System information
macOS 12.6, Apple M1 Max
Issue description
In the latest beta version of Godot 4, I've noticed that once you edit any text/number field in the inspector pane and press RETURN, it automatically goes to rename the node in the scene pane that the property belongs to. This usually results in accidentally renaming nodes with gibberish since it isn't immediately obvious that the text field has focus. Using keyboard shortcuts after changing properties in the inspector often leads to messing up the user's scene tree.
Steps to reproduce

Create a scene
Place any node in the scene
Find a property in the inspector and type in a new value
Press enter
The node in the scene pane will have its name highlighted and the caret placed in the text field

Minimal reproduction project
N/A

Could be a duplicate of #69160

Ah, yes it is a duplicate. Oops 😁

Confirmed duplicate of #69160


Custom method support

It's impossible to register a custom Method with safe/idempotent semantics or whether it permits/forbids a body since the demise of the global, mutable, despicable registry.
package com.example

package object cornercase {
  val BLORP: Method = ???
}

We can make Method.fromString("BLORP") === BLORP.  But we can't define that BLORP is safe, idempotent, or what type of body it takes.  We also can't make Method.fromString("BLORP") eq BLORP.  You can do both of these things in akka-http.
Does anybody out there actually BLORP?  If you do, can you figure out how to do this without global state?

My view: if you're important enough to be a flyweight with recognized properties, you're important enough to be in the IANA registry.
Anyone want to fight? :boxing_glove: :boxing_glove:

I think we should be against potentially unholy behavior . I really can't think of a single reason why I would ever not fight a decision in a workplace to do stuff with a custom method over HTTP.
Down with this idea.

It's really a corner/custom case, I would skip over it
Having said that this same issue comes up if you want to e.g. add a custom MediaType which maybe more common?

Yes, it's a more challenging question for MediaType.  Encoding considerations (7-bit vs. 8-bit vs. binary) and file extensions are interesting properties here that can't be expressed without a custom registry.  People can build their own logic for this, but we can't make mediaType.isBinary return true.
If we implement #73, we can shrug our shoulders and point at MimeDB and offer people a patch release.

Alright, I think #73 is a good ticket for further discussion of the media types.  There are interesting MiMa issues to work through if and when that comes into being.

The MimeDB PR went through. Can we close?

There is no longer a mutable registry.


cannot find 'localforage'

when i use the demo  in local test , 'localforage' has been defined,  but on the server , 'localforage' is not defined..
using   ,
the net work has returned to the localforage.js

module.exports = localforage_js;
//update localforage.js , add the following line,  the problem resolved
window.localforage = localforage_js

Are you trying to use localForage in node? localForage is a browser library only.

just in browser

Which demo page are you trying to use?

localForage-master \localForage-master\examples\index.html

I'm still not getting how you are trying to use localforage. Running index.html simply with a double click on the file works (logs appear in the console) on both Firefox and chrome.

Closing this for now.
Please take a look at #624 and the live example we added in README.
Feel free to re-open in any case.


Derivation of json schemas

Feature request:
I'd be interested in automatically generating a json schema (in the sense of https://json-schema.org) out of an OCaml type definition. A json schema is describing a subset of all jsons and can be seen as a json type or a validity criterion on a json structure. Say if I have an OCaml type ty = ... [@@deriving yojson], the json structures produced by ty_to_yojson, when applied to OCaml values of type ty, would be json structures abiding by the schema.
Ideally the schema would capture exactly the image of ty_to_yojson, but I expect the notion of json schema to be less expressive than OCaml's type system (e.g., I don't think json schemas have polymorphism and I think that in a json schema, all elements of JSON arrays must have the same type --which would be problematic for the encoding of OCaml's tuples as json arrays)...
...so for the moment what would be enough is producing a json schema that captures the image of ty_to_yojson for a simple class of OCaml types ty (no tuples, all constructors have "record-like / named arguments", etc), and perhaps producing a reasonable superset of that image when ty is outside that class.
I had hoped that the meta option of this deriver would do something along those lines, but it seems it does something much simpler.
Has anybody heard of a project doing what I'd like?

Json_schema in ocplib-json-typed has a representation of schemas (which are themselves jsons) but I see no deriver;
ATD offers its own notion of json type (from what I understand), whose expressivity may be well-suited to my use case, but the tool seems to offer a one way street towards OCaml code generation, while I need the reverse direction: producing json schemas from types in existing OCaml code;
ppx_yojson_conv seems to be the same kind of ppx deriver as ppx_deriving_yojson and, just like Milk, they both seem to offer value-level serialization/deserialization while I need type-level "serialization";
ppx_yojson does something different (though very useful).

My understanding is that ppx_yojson_conv is a more recent library that supersedes ppx_deriving_yojson, and is more actively maintained. Given that your feature requires new developments, I would go ask the ppx_yojson_conv developers.
(I will edit the README here to formalize this recommandation.)

My understanding is that ppx_yojson_conv is a more recent library that supersedes ppx_deriving_yojson, and is more actively maintained. Given that your feature requires new developments, I would go ask the ppx_yojson_conv developers.
(I will edit the README here to formalize this recommandation.)

Makes sense; I've posted my query here. Thanks!

Makes sense; I've posted my query here. Thanks!


Add WarpExchangeRegister class

WarpExchangeRegister works like WarpExchange semantically, but uses warp shuffles internally instead of shared memory. This pattern is useful in a number of situations:

Kernels that only need to exchange a small number of items. When exchanging 2, 4 or 8 items per thread, the number of warp shuffles is 1, 4 and 12, respectively, which is lower than a total of 4, 8 and 16 shared memory transactions, respectively.
Kernels that already have a high shared memory budget but still need to exchange data to maintain ILP.
Kernels running on GPUs that are shared memory starved, such as Turing or Pascal.

Inspired by

https://forums.developer.nvidia.com/t/transposing-register-held-matrices-with-warp-shuffles-need-help/38652/2
https://forums.developer.nvidia.com/t/implement-2d-matrix-transpose-using-warp-shuffle-without-local-memory/208418/11

@senior-zero

Register-based vs SMEM-based Transpose:

The register-based solution obviously has a slightly higher arithmetic intensity (due to all the SEL instructions), but also achieves a much better occupancy, due to only requiring 40(!) registers in order to transpose a 32x32 matrix in a single warp.

@senior-zero I've amended the code to your suggestions. I haven't documented the impl yet, but will do so soon. I haven't added tests, mainly because there's still one problem:
Let's assume we have an array in global memory of [0, ..., 63] where threads load data in a coalesced way into an array of size two, i.e. int arr[2] = {mem[lane], mem[32 + lane]} (assuming a threadblock of (32, 1, 1)). When setting the logical warp size to 2, I get for the WARP_EXCHANGE_SHMEM transpose
arr[2] == {0, 1} for lane % 2 == 0
arr[2] == {32, 33} for lane % 2 == 1

or
 arr[0]:    0   32    0   32    0   32    0   32    0   32    0   32    0   32    0   32    0   32    0   32    0   32    0   32    0   32    0   32    0   32    0   32
 arr[1]:    1   33    1   33    1   33    1   33    1   33    1   33    1   33    1   33    1   33    1   33    1   33    1   33    1   33    1   33    1   33    1   33

where columns represent lanes 0 to 31. It is apparent that the data from lanes in [2, 31] gets lost. Switching to WARP_EXCHANGE_SHUFFLE, I get after the transpose
 arr[0]:    0   32    2   34    4   36    6   38    8   40   10   42   12   44   14   46   16   48   18   50   20   52   22   54   24   56   26   58   28   60   30   62
 arr[1]:    1   33    3   35    5   37    7   39    9   41   11   43   13   45   15   47   17   49   19   51   21   53   23   55   25   57   27   59   29   61   31   63

Given how __shfl_xor_sync works, I don't see a solution to making them work identically without a broadcast into [LOGICAL_WARP_THREADS, 31] after the core transpose procedure. Any ideas?

I've amended the code to your suggestions.

@pb-dseifert Thank you, we are getting closer, but I'm afraid that the scheme I suggested is still not implemented. You've fused two implementations in WarpExchange. My suggestion was:

I'd like the same approach as in warp reduce implementation.

Could you extract shared memory implementation into warp/specializations/warp_exchange_shfl.cuh and the new shuffle implementation into warp/specializations/warp_exchange_shfl.cuh? Then the warp exchange would contain:
using InternalWarpExchange =
  cub::detail::conditional_t<
    WARP_EXCHANGE_ALGORITHM == WarpExchangeAlgorithm::WARP_EXCHANGE_SHMEM,
    WarpExchangeShfl<T, ITEMS_PER_THREAD, LOGICAL_WARP_THREADS>,
    WarpExchangeSmem<T, ITEMS_PER_THREAD, LOGICAL_WARP_THREADS>>;

I'm sorry for nit picking, but I'd also prefer WARP_EXCHANGE_SMEM.
Regarding your main question, is there any chance that you've passed a single temporary storage to all virtual warps? The contract is that each virtual warp gets it's own temporary storage. In the code below, I get the same output as WARP_EXCHANGE_SHUFFLE:
constexpr int items_per_thread = 2;
constexpr int warp_size = 32;
constexpr int virtual_warp_size = 2;
constexpr int n = items_per_thread * warp_size;
constexpr int virtual_warps = warp_size / virtual_warp_size;

__global__ void kernel(int *data) {
  using warp_exchange_t = cub::WarpExchange<int, items_per_thread, virtual_warp_size>;
  using temp_storage_t = warp_exchange_t::TempStorage;
  __shared__ temp_storage_t temp_storage[virtual_warps];
  const int warp_id = threadIdx.x / virtual_warp_size;

  int thread_data[items_per_thread];
  for (int i = 0; i < items_per_thread; ++i) {
    thread_data[i] = data[warp_size * i + threadIdx.x];
  }

  warp_exchange_t(temp_storage[warp_id]).StripedToBlocked(thread_data, thread_data);

  for (int i = 0; i < items_per_thread; ++i) {
    data[warp_size * i + threadIdx.x] = thread_data[i];
  }
}

int main() {
  thrust::device_vector<int> data(n);
  thrust::sequence(data.begin(), data.end());

  kernel<<<1, warp_size>>>(thrust::raw_pointer_cast(data.data()));
  cudaDeviceSynchronize();

  thrust::host_vector<int> result = data;
  for (int i = 0; i < items_per_thread; i++) {
    std::cout << "arr[" << i << "] = ";
    for (int thread = 0; thread < warp_size; thread++) {
      std::cout << result[warp_size * i + thread] << " ";
    }
    std::cout << std::endl;
  }
}

// arr[0] = 0 32 2 34 4 36 6 38 8 40 10 42 12 44 14 46 16 48 18 50 20 52 22 54 24 56 26 58 28 60 30 62
// arr[1] = 1 33 3 35 5 37 7 39 9 41 11 43 13 45 15 47 17 49 19 51 21 53 23 55 25 57 27 59 29 61 31 63

@senior-zero sorry, this took a little longer than anticipated.
Yes, I forgot to use multiple temporary storage arrays for the different logical warps. That made it work.
I've split the actual implementations into different files. I've also documented the recursive approach in the shuffle implementation. I hope this is more to your liking, I went with private inheritance, since it avoids most of the compositional boilerplate in WarpExchange.
I haven't extended the testsuite, since I'm still looking into how to exactly invoke it.

@senior-zero I've addressed all your comments, could you check again? Once you're happy here, I'll open a fresh PR in cccl

https://github.com/NVIDIA/cccl/pull/256


K8s v1.2 - Ingress includes targets from across namespaces that have matching selectors.

Rancher Version - v1.2.0-pre2
Set up - Have k8s env in v1.2
Steps to create the problem:
Create service/rc/pod in 1 namespace.
Create the same set of service/rc/pod (using the same yml file) in another namespace.
Ingresses that get created have services from different namespace being included as targets.

Tested with Server version - v1.1.4-rc1 and K8s template from https://github.com/rancher/qa-catalog.
This issue is not seen anymore.


Empty JSON being added to JSON editor

If the user clicks on a section which contains an own attribute in the fields like

healthChecks
lables
container

and afterwards opens the JSON editor those fields are present in the JSON but they are empty. At this point the user hasn't added any of these so it is slightly misleading and adds unnecessary noise to JSON.
The expected functionality is that the JSON only contains the default fields and the empty fields should be excluded.
Current State

Expected State

Isn't this a dupe of https://github.com/mesosphere/marathon/issues/3293 ? if so, please close. Thanks!


python39Packages.snowflake-sqlalchemy: 1.4.1 -> 1.4.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python39Packages.snowflake-sqlalchemy is: "Snowflake SQLAlchemy Dialect"
meta.homepage for python39Packages.snowflake-sqlalchemy is: "https://www.snowflake.net/"
meta.changelog for python39Packages.snowflake-sqlalchemy is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
Warning: a test defined in passthru.tests did not pass
found 1.4.2 with grep in /nix/store/qr23knfz6mqh2ishy5m7pklhzjrpvjh2-python3.9-snowflake-sqlalchemy-1.4.2
found 1.4.2 in filename of file in /nix/store/qr23knfz6mqh2ishy5m7pklhzjrpvjh2-python3.9-snowflake-sqlalchemy-1.4.2

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
python310Packages.snowflake-sqlalchemy
python39Packages.snowflake-sqlalchemy

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/qr23knfz6mqh2ishy5m7pklhzjrpvjh2-python3.9-snowflake-sqlalchemy-1.4.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python39Packages.snowflake-sqlalchemy https://github.com/r-ryantm/nixpkgs/archive/40b8cd6d3788a8558c5f9095984763a6f792c72d.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/qr23knfz6mqh2ishy5m7pklhzjrpvjh2-python3.9-snowflake-sqlalchemy-1.4.2
ls -la /nix/store/qr23knfz6mqh2ishy5m7pklhzjrpvjh2-python3.9-snowflake-sqlalchemy-1.4.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

python310Packages.snowflake-sqlalchemy
python39Packages.snowflake-sqlalchemy

Maintainer pings

Result of nixpkgs-review pr 193455 run on x86_64-linux 1

2 packages built:

python310Packages.snowflake-sqlalchemy
python39Packages.snowflake-sqlalchemy