404 Error - Status must be specified Google Api Client

I am trying to create a managed product using the google api client and this worked about few weeks ago. Of a sudden I can't get passed this error. I have touched nothing but I see this repo was updated some few days. Could this be the reason why.?
Environment details

OS: Mac OS 10.15.3 Catalina
PHP version: 7.3.9
Package name and version:   "google/apiclient": "^2.0",

Code example
 $client = new Google_Client();
                $client->setAuthConfig('credentials.json'));
                $client->addScope('https://www.googleapis.com/auth/androidpublisher');
                $service = new Google_Service_AndroidPublisher($client);

                $body = new \Google_Service_AndroidPublisher_InAppProduct();
                $body->setSku($sku);
                $body->setPackageName($packageName);

//                $1.00 USD = 1,000,000 Microns.
                $price = new \Google_Service_AndroidPublisher_Price();
                $price->setCurrency('NGN');
                $g_price = $request->price[$i];
                if ($request->price[$i] <= 299) {
                    $g_price = 300;
                }
                $conv = intval(currency($g_price, $from = "XAF", $to = "NGN", false));
                $price->priceMicros = $conv * 1000000;
                $body->setDefaultPrice($price);
                $body->defaultLanguage = "en_US";
                $body->setListings([
                    'en_US' => [
                        'title' => $title,
                        'description' => $description
                    ]
                ]);
                $purchase = $service->inappproducts->insert($packageName, $body, [
                    'autoConvertMissingPrices' => true,
                ]);
                $purchase->setStatus(true);

When I run the following code ... I get this error
{ "error": { "code": 400, "message": "Status must be specified.", "errors": [ { "message": "Status must be specified.", "domain": "global", "reason": "badRequest" } ], "status": "INVALID_ARGUMENT" } }

I am confused on what status is needed here?. I have checked back and forth and my service account has all the permissions for accessing the api. This worked about 3-4 weeks ago but now It throws this error. When I try to catch the exception.. I have the ** "message": "Status must be specified**

Okay I see it was not related to some auth as I though rather had to parse more parameters to the $body like status, purchaseType. Somehow they were made mandatory as of last week the params above worked just fine.


Update PSharpAsLanguage samples

After 578e140, we should update the samples in PSharpAsLanguage to use the VS build.
We should also confirm that we're finding the same bugs in the samples as before.

Closing this one since we recently updated the samples. If we do more work lets open another issue.


Failure anomalies smart alert miss from Application Insights -> Smart Detection rules

For some existing application insights instance, when nav to Smart Detection -> Settings, the Failure Anomalies is missing.
But if create a new app insight, it's there.
For details, you can refer to this issue on stack overflow.

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

ID: 914de10e-eaf5-d7b5-09be-c6d7b32408b2
Version Independent ID: 5d35c099-0f3c-667e-3a43-66f2cf513461
Content: Smart Detection in Azure Application Insights
Content Source: articles/application-insights/app-insights-proactive-diagnostics.md
Service: application-insights
GitHub Login: @mrbullwinkle
Microsoft Alias: mbullwin

@imeya Thank you for the feedback!  We are investigating this and will get back to you shortly.

@imeya Are you sending request/dependency telemetry to the existing application?  In the past we would activate Failure Anomalies when data was sent, however now we only activate Failure Anomalies when a new application is created.  If you are in a scenario where you have an old application where data was not sent until after the new rule went into effect, we can manually activate the applications (but we will need application information for the applications you want to activate).

Past:  Activated when data is sent
Current: Activated when new application is created, or by special request for older applications

Yes we are (lots of data). I'll contact you privately with app insights details which is about about 1 year old.

@Ofekw We are going to close this thread as resolved but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.


Season level stats

closes #93

I have triggered a 2023 rebuild from this branch. This will be the best test to see if everything works fine

We should add use-public-rspm: true to all setup-r calls, and maybe add nflverse r-universe as well?

Small nitpick: the corresponding nfl-data-py function param calls the "REG+POST" category "ALL". Thoughts on naming it to match?
Just a thought, I'm kind of ambivalent on it. I like that "REG+POST" is very concrete, whereas new users might find "ALL" ambiguous as to whether it includes pre-season.

Prefer reg+post myself for the same reasons although we could just embrace the nflverse telling people that the preseason doesn’t exist

Yeah I prefer "REG+POST" over "ALL" as it is very clear about what it is


Puddles and Vents YFight

Just put one above the other for drawdepth or move puddles iunno.

Fixed at some point. Vents draw above.


Set up SQlite usage without making use of ORM

Some people who would make use of SQLite might not need usage of any ORM, then we can add the functionality for such cases.

Not urgent. Can reopen in the future.


Alias System

Resolved with the created of the alias process. Updated the export, unset, printenv, and help processes.


Use mypy-protobuf for better grpc type stubs

This adds mypy type stub generation for better DX with grpc types.

Adds mypy-protobuf to poetry dev dependencies
Adds --mypy_out flag to grpc client generator

dev:

PR:

All Submissions:

[x] Contributions should target the dev branch. Did you create your branch from dev?
[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Recreated the type stubs with the dev branch of qdrant core

@joein anything against this? Otherwise I think it makes our life easier

Let's merge it before 1.11.2, but not right now

I added the mypy stubs in #758, now that this one is approved. To not repeat client generation, I will close this one in favor of the other one.


README has conflicting information about EKS/ECS

Describe the bug
It's a doc bug, could have happened to anyone: https://github.com/aws/secrets-store-csi-driver-provider-aws/blob/8d3e5030370790421828ad968f08b2d2c39b9331/README.md?plain=1#L11
To Reproduce
Steps to reproduce the behavior:

View the repository README

Do you also notice this bug when using a different secrets store provider (Vault/Azure/GCP...)? Yes/No No
Expected behavior: The README should contain accurate information
Additional context: Hey, if this is under the AWS Github org (is that a conflict of interest?) I'm assuming you know that there's no such thing as "EKS using ECS". I'm happy to PR in the change if someone wants to clear it up.
Does this work with ECS? ECS Fargate? Sounds like a "no" on EKS Fargate.. What about EKS with a combination of Fargate and EC2 nodes? What if I have EC2 nodes that are not part of a node group? What about EKS Anywhere? What about EC2 nodes using a home-baked AMI? What about self-hosted k8s on AWS? I realize that's a lot of questions- these are all questions I would expect to get asked at work when suggesting something like this.

Thanks for the report, onwsk8r. One of our engineers is taking a look.


Change how entity id is created

Entity ID is now based on entity name. This is a too strong binding that makes it difficult to change names. This also makes entity id a bit long in some cases.
Entity id should be based on meter manufacturer and measure id.
Existing sensor entity id should be migrated at startup using HA entity migration functionality.

https://github.com/toreamun/amshan-homeassistant/releases/tag/2022.2.1


Python and Anylogic Connection

Hello dear t-wolfeadam,
I am trying to connect Anylogic and Python. I know there is a Pipeline tool in Anylogic but I intend to get the non-stop generated output to Anylogic block in real time. I have searched for it and I encountered Python's socket library and Anylogic's REST API. I am confused about which one to use. By the way, I want to get the data from an IoT device as an input to Python.

Hi, so the Pypeline tool is this one :)
I'm not sure what you mean by "real-time" - simulation tools like AnyLogic are intended to run faster than real time, so typically any external endpoints are queried at the start of run to initialize the model and then it's executed under its own rules.
Also, Pypeline is probably exactly what you want. It uses Python's socket library for communication. For reference, AnyLogic's REST API is specifically for running models uploaded to the AnyLogic Cloud, so it's not what you want.
I made a very simple example model showing how it works, similar to the problem you described (though the provided examples are typically more useful). Please read the documentation if you need help installing it or for more information.
Model344.zip


Add some new relations

We want to add some new relations, these are all already in use by some wordnets.

Simple Aspect
Secondary Aspect
Feminine form
Masculine Form
Young Form
Diminutive
Augmentative
Gradable Antonym
Simple Antonym
Converse Antonym
Inter-register Synonym

Most of these are used by the Polish Wordnet Project, some by Czech and Bulgarian.

@ewa-rudnicka and @fcbond are still hashing out if some of the relations should be symmetric or appear in pairs.  Probably only the synonym and antonym relations should be symmetric.

Basic documentation added by b4dbc8c

A couple of comments on the implementation of these new relationships:

Could we lose the _of from property names like augmentative_of? This would fit the style better
simple_aspect_pi and secondary_aspect_pi are marked as not directly applicable. So what is the point of them??
ir_synonym is allowed between senses, but its parent relationship is not. This is a contradiction. I think that ir_synonym should not be allowed between senses
Similarly, simple_aspect_ip and secondary_aspect_ip are allowed between synsets, but not between its parent derivation. Again this is contradictory and we should probably not allow this.

A couple of comments on the implementation of these new relationships:

Could we lose the _of from property names like augmentative_of? This would fit the style better

I also prefer without _of, but I'm not sure we have a consistent style. Here are some existing relations with of:

state_of ⇔ be_in_state
subevent ⇔ is_subevent_of
manner_of ⇔ in_manner

Similarly, these by ones are inconsistent:

restricts ⇔ restricted_by
entails ⇔ is_entailed_by

Maybe we could use some relation naming guidelines.

simple_aspect_pi and secondary_aspect_pi are marked as not directly applicable. So what is the point of them??

"(not directly applicable)" is what is shown by the HTML templates when a relation is not marked as a synset-synset, sense-sense, or sense-synset relation (e.g., for constitutive). My guess is that someone forgot to mark these relations as such. Otherwise I'd agree that there's no point. I think for "constitutive", which is not defined in the DTD, it is only there to group related relations as a supertype. Maybe it should go?

ir_synonym is allowed between senses, but its parent relationship is not. This is a contradiction. I think that ir_synonym should not be allowed between senses

I see the logical argument, and also I think it's easier to start with a tight schema then loosen it later than vice versa. However, in the Japanese Wordnet we have words sharing a synset where some are interregister synonyms (e.g., 召し上がる, 召しあがる, 召上る (yes, three of them), 召される, 召す, 上がる, 食事, 食む, 食らう, 食う, 食べる, 食する, and 頂く all share a synset). These cannot be modeled with a synset-only relation. But maybe adapting the schema to the data we have is putting the cart before the horse and we should instead change the data (e.g., splitting those into different synsets)?

Similarly, simple_aspect_ip and secondary_aspect_ip are allowed between synsets, but not between its parent derivation. Again this is contradictory and we should probably not allow this.

Ditto my first sentence from (3) above. I don't have any opinion or counterexamples otherwise.
I have another related concern:

I find the _form relations (feminine_form, masculine_form, etc.) slightly odd. Why are we talking about "form" at the synset level? That seems like a word (or sense) thing. Why not just feminine, masculine, etc.?

A couple of comments on the implementation of these new relationships:

Could we lose the _of from property names like augmentative_of? This would fit the style better

I also prefer without _of, but I'm not sure we have a consistent style. Here are some existing relations with of:

state_of ⇔ be_in_state
subevent ⇔ is_subevent_of
manner_of ⇔ in_manner

Similarly, these by ones are inconsistent:

restricts ⇔ restricted_by
entails ⇔ is_entailed_by

Maybe we could use some relation naming guidelines.

simple_aspect_pi and secondary_aspect_pi are marked as not directly applicable. So what is the point of them??

"(not directly applicable)" is what is shown by the HTML templates when a relation is not marked as a synset-synset, sense-sense, or sense-synset relation (e.g., for constitutive). My guess is that someone forgot to mark these relations as such. Otherwise I'd agree that there's no point. I think for "constitutive", which is not defined in the DTD, it is only there to group related relations as a supertype. Maybe it should go?

ir_synonym is allowed between senses, but its parent relationship is not. This is a contradiction. I think that ir_synonym should not be allowed between senses

I see the logical argument, and also I think it's easier to start with a tight schema then loosen it later than vice versa. However, in the Japanese Wordnet we have words sharing a synset where some are interregister synonyms (e.g., 召し上がる, 召しあがる, 召上る (yes, three of them), 召される, 召す, 上がる, 食事, 食む, 食らう, 食う, 食べる, 食する, and 頂く all share a synset). These cannot be modeled with a synset-only relation. But maybe adapting the schema to the data we have is putting the cart before the horse and we should instead change the data (e.g., splitting those into different synsets)?

Similarly, simple_aspect_ip and secondary_aspect_ip are allowed between synsets, but not between its parent derivation. Again this is contradictory and we should probably not allow this.

Ditto my first sentence from (3) above. I don't have any opinion or counterexamples otherwise.
I have another related concern:

I find the _form relations (feminine_form, masculine_form, etc.) slightly odd. Why are we talking about "form" at the synset level? That seems like a word (or sense) thing. Why not just feminine, masculine, etc.?

Yes, for 1 and 5 I also prefer shorter names.
On 3, I think that this is something that should be fixed in Japanese WordNet, Typically, register changes (e.g., 'bloke' vs 'man') are different synsets in wordnets.

Yes, for 1 and 5 I also prefer shorter names.
On 3, I think that this is something that should be fixed in Japanese WordNet, Typically, register changes (e.g., 'bloke' vs 'man') are different synsets in wordnets.

Hi,
CCing Ewa in case she is not watching the github.
On Tue, Jan 12, 2021 at 12:20 AM Michael Wayne Goodman <
<EMAIL_ADDRESS>wrote:

A couple of comments on the implementation of these new relationships:

Could we lose the _of from property names like augmentative_of?
This would fit the style better

I also prefer without _of, but I'm not sure we have a consistent style.
Here are some existing relations with of:

state_of ⇔ be_in_state
subevent ⇔ is_subevent_of
manner_of ⇔ in_manner

Similarly, these by ones are inconsistent:

restricts ⇔ restricted_by
entails ⇔ is_entailed_by

Maybe we could use some relation naming guidelines.

Actually I have been thinking that for the next round we should try to do a
consistent renaming (like Eurowordnet did).   Until then, I guess I am OK
with trying be consistent and going for shorter here (I am assuming we can
update the paper after the conference).

simple_aspect_pi and secondary_aspect_pi are marked as not directly
applicable. So what is the point of them??

"(not directly applicable)" is what is shown by the HTML templates when a
relation is not marked as a synset-synset, sense-sense, or sense-synset
relation (e.g., for constitutive). My guess is that someone forgot to
mark these relations as such. Otherwise I'd agree that there's no point. I
think for "constitutive", which is not defined in the DTD, it is only there
to group related relations as a supertype. Maybe it should go?

Michael is correct, it was a bug, I have fixed it.

ir_synonym is allowed between senses, but its parent relationship
is not. This is a contradiction. I think that ir_synonym should not be
allowed between senses

I see the logical argument, and also I think it's easier to start with a
tight schema then loosen it later than vice versa. However, in the Japanese
Wordnet we have words sharing a synset where some are interregister
synonyms (e.g., 召し上がる, 召しあがる, 召上る (yes, three of them), 召される, 召す, 上がる, 食事,
食む, 食らう, 食う, 食べる, 食する, and 頂く all share a synset). These cannot be modeled
with a synset-only relation. But maybe adapting the schema to the data we
have is putting the cart before the horse and we should instead change the
data (e.g., splitting those into different synsets)?

I agree for the Japanese wordnet, we should definitely split these.  I was
trying to also allow the schema to model the Polish Wordnet, which treats
these all as sense level relations, but as I think that for them synset is
not a basic relation, maybe we should not worry about it?   In which case I
agree that sense-level is not needed.  Ewa?

Similarly, simple_aspect_ip and secondary_aspect_ip are allowed
between synsets, but not between its parent derivation. Again this is
contradictory and we should probably not allow this.

Ditto my first sentence from (3) above. I don't have any opinion or
counterexamples otherwise.

Ewa?

I have another related concern:

I find the _form relations (feminine_form, masculine_form, etc.)
slightly odd. Why are we talking about "form" at the synset level? That
seems like a word (or sense) thing. Why not just feminine, masculine,
etc.?

In general, the link names are nominals, not adjectives, and I was trying
to be consistent, ...    I could be persuaded to lose the form for all of
these if everyone agrees.
--
Francis Bond http://www3.ntu.edu.sg/home/fcbond/
Division of Linguistics and Multilingual Studies
Nanyang Technological University

Hi,
CCing Ewa in case she is not watching the github.
On Tue, Jan 12, 2021 at 12:20 AM Michael Wayne Goodman <
<EMAIL_ADDRESS>wrote:

A couple of comments on the implementation of these new relationships:

Could we lose the _of from property names like augmentative_of?
This would fit the style better

I also prefer without _of, but I'm not sure we have a consistent style.
Here are some existing relations with of:

state_of ⇔ be_in_state
subevent ⇔ is_subevent_of
manner_of ⇔ in_manner

Similarly, these by ones are inconsistent:

restricts ⇔ restricted_by
entails ⇔ is_entailed_by

Maybe we could use some relation naming guidelines.

Actually I have been thinking that for the next round we should try to do a
consistent renaming (like Eurowordnet did).   Until then, I guess I am OK
with trying be consistent and going for shorter here (I am assuming we can
update the paper after the conference).

simple_aspect_pi and secondary_aspect_pi are marked as not directly
applicable. So what is the point of them??

"(not directly applicable)" is what is shown by the HTML templates when a
relation is not marked as a synset-synset, sense-sense, or sense-synset
relation (e.g., for constitutive). My guess is that someone forgot to
mark these relations as such. Otherwise I'd agree that there's no point. I
think for "constitutive", which is not defined in the DTD, it is only there
to group related relations as a supertype. Maybe it should go?

Michael is correct, it was a bug, I have fixed it.

ir_synonym is allowed between senses, but its parent relationship
is not. This is a contradiction. I think that ir_synonym should not be
allowed between senses

I see the logical argument, and also I think it's easier to start with a
tight schema then loosen it later than vice versa. However, in the Japanese
Wordnet we have words sharing a synset where some are interregister
synonyms (e.g., 召し上がる, 召しあがる, 召上る (yes, three of them), 召される, 召す, 上がる, 食事,
食む, 食らう, 食う, 食べる, 食する, and 頂く all share a synset). These cannot be modeled
with a synset-only relation. But maybe adapting the schema to the data we
have is putting the cart before the horse and we should instead change the
data (e.g., splitting those into different synsets)?

I agree for the Japanese wordnet, we should definitely split these.  I was
trying to also allow the schema to model the Polish Wordnet, which treats
these all as sense level relations, but as I think that for them synset is
not a basic relation, maybe we should not worry about it?   In which case I
agree that sense-level is not needed.  Ewa?

Similarly, simple_aspect_ip and secondary_aspect_ip are allowed
between synsets, but not between its parent derivation. Again this is
contradictory and we should probably not allow this.

Ditto my first sentence from (3) above. I don't have any opinion or
counterexamples otherwise.

Ewa?

I have another related concern:

I find the _form relations (feminine_form, masculine_form, etc.)
slightly odd. Why are we talking about "form" at the synset level? That
seems like a word (or sense) thing. Why not just feminine, masculine,
etc.?

In general, the link names are nominals, not adjectives, and I was trying
to be consistent, ...    I could be persuaded to lose the form for all of
these if everyone agrees.
--
Francis Bond http://www3.ntu.edu.sg/home/fcbond/
Division of Linguistics and Multilingual Studies
Nanyang Technological University

Hi,
I had a chat with Ewa:
On Tue, Jan 12, 2021 at 12:20 AM Michael Wayne Goodman <

<EMAIL_ADDRESS>wrote:

A couple of comments on the implementation of these new relationships:

Could we lose the _of from property names like augmentative_of?
This would fit the style better

I also prefer without _of, but I'm not sure we have a consistent style.
Here are some existing relations with of:

state_of ⇔ be_in_state
subevent ⇔ is_subevent_of
manner_of ⇔ in_manner

Similarly, these by ones are inconsistent:

restricts ⇔ restricted_by
entails ⇔ is_entailed_by

Maybe we could use some relation naming guidelines.

Actually I have been thinking that for the next round we should try to do
a consistent renaming (like Eurowordnet did).   Until then, I guess I am OK
with trying be consistent and going for shorter here (I am assuming we can
update the paper after the conference).

We are both ok with losing the '_of'

simple_aspect_pi and secondary_aspect_pi are marked as not
directly applicable. So what is the point of them??

"(not directly applicable)" is what is shown by the HTML templates when a
relation is not marked as a synset-synset, sense-sense, or sense-synset
relation (e.g., for constitutive). My guess is that someone forgot to
mark these relations as such. Otherwise I'd agree that there's no point. I
think for "constitutive", which is not defined in the DTD, it is only there
to group related relations as a supertype. Maybe it should go?

Michael is correct, it was a bug, I have fixed it.

I have also marked them both to be just for sense-sense level relations.

ir_synonym is allowed between senses, but its parent relationship
is not. This is a contradiction. I think that ir_synonym should not
be allowed between senses

I see the logical argument, and also I think it's easier to start with a
tight schema then loosen it later than vice versa. However, in the Japanese
Wordnet we have words sharing a synset where some are interregister
synonyms (e.g., 召し上がる, 召しあがる, 召上る (yes, three of them), 召される, 召す, 上がる, 食事,
食む, 食らう, 食う, 食べる, 食する, and 頂く all share a synset). These cannot be modeled
with a synset-only relation. But maybe adapting the schema to the data we
have is putting the cart before the horse and we should instead change the
data (e.g., splitting those into different synsets)?

I agree for the Japanese wordnet, we should definitely split these.  I was
trying to also allow the schema to model the Polish Wordnet, which treats
these all as sense level relations, but as I think that for them synset is
not a basic relation, maybe we should not worry about it?   In which case I
agree that sense-level is not needed.  Ewa?

I have also changed these to sense-sense.

Similarly, simple_aspect_ip and secondary_aspect_ip are allowed
between synsets, but not between its parent derivation. Again this is
contradictory and we should probably not allow this.

Ditto my first sentence from (3) above. I don't have any opinion or
counterexamples otherwise.

Ewa?

I have another related concern:

I find the _form relations (feminine_form, masculine_form, etc.)
slightly odd. Why are we talking about "form" at the synset level? That
seems like a word (or sense) thing. Why not just feminine, masculine,
etc.?

In general, the link names are nominals, not adjectives, and I was trying
to be consistent, ...    I could be persuaded to lose the form for all of
these if everyone agrees.

I think diminutive and augmentative are also ok as just sense/sense.
For male/female/young, I would like to capture relations like 'King Queen',
'Kangaroo Joey' as well as 'Prince Princess' and 'Pig Piglet', So I would
like to leave it at    I guess if we thought it important we could have two
different sets of relations, but I would prefer to leave that for another
revision.
I have checked in the changes to the synset/sense level issues in
the documentation.
do we want the names to be:
young/has_young
male/has_male    (to emphasize the concept)
female/has_female    (to emphasize the concept)
diminuative/has_diminuative
augmentative/has_augmentative
If everyone agrees I will make this change too.
--
Francis Bond http://www3.ntu.edu.sg/home/fcbond/
Division of Linguistics and Multilingual Studies
Nanyang Technological University

Hi,
I had a chat with Ewa:
On Tue, Jan 12, 2021 at 12:20 AM Michael Wayne Goodman <

<EMAIL_ADDRESS>wrote:

A couple of comments on the implementation of these new relationships:

Could we lose the _of from property names like augmentative_of?
This would fit the style better

I also prefer without _of, but I'm not sure we have a consistent style.
Here are some existing relations with of:

state_of ⇔ be_in_state
subevent ⇔ is_subevent_of
manner_of ⇔ in_manner

Similarly, these by ones are inconsistent:

restricts ⇔ restricted_by
entails ⇔ is_entailed_by

Maybe we could use some relation naming guidelines.

Actually I have been thinking that for the next round we should try to do
a consistent renaming (like Eurowordnet did).   Until then, I guess I am OK
with trying be consistent and going for shorter here (I am assuming we can
update the paper after the conference).

We are both ok with losing the '_of'

simple_aspect_pi and secondary_aspect_pi are marked as not
directly applicable. So what is the point of them??

"(not directly applicable)" is what is shown by the HTML templates when a
relation is not marked as a synset-synset, sense-sense, or sense-synset
relation (e.g., for constitutive). My guess is that someone forgot to
mark these relations as such. Otherwise I'd agree that there's no point. I
think for "constitutive", which is not defined in the DTD, it is only there
to group related relations as a supertype. Maybe it should go?

Michael is correct, it was a bug, I have fixed it.

I have also marked them both to be just for sense-sense level relations.

ir_synonym is allowed between senses, but its parent relationship
is not. This is a contradiction. I think that ir_synonym should not
be allowed between senses

I see the logical argument, and also I think it's easier to start with a
tight schema then loosen it later than vice versa. However, in the Japanese
Wordnet we have words sharing a synset where some are interregister
synonyms (e.g., 召し上がる, 召しあがる, 召上る (yes, three of them), 召される, 召す, 上がる, 食事,
食む, 食らう, 食う, 食べる, 食する, and 頂く all share a synset). These cannot be modeled
with a synset-only relation. But maybe adapting the schema to the data we
have is putting the cart before the horse and we should instead change the
data (e.g., splitting those into different synsets)?

I agree for the Japanese wordnet, we should definitely split these.  I was
trying to also allow the schema to model the Polish Wordnet, which treats
these all as sense level relations, but as I think that for them synset is
not a basic relation, maybe we should not worry about it?   In which case I
agree that sense-level is not needed.  Ewa?

I have also changed these to sense-sense.

Similarly, simple_aspect_ip and secondary_aspect_ip are allowed
between synsets, but not between its parent derivation. Again this is
contradictory and we should probably not allow this.

Ditto my first sentence from (3) above. I don't have any opinion or
counterexamples otherwise.

Ewa?

I have another related concern:

I find the _form relations (feminine_form, masculine_form, etc.)
slightly odd. Why are we talking about "form" at the synset level? That
seems like a word (or sense) thing. Why not just feminine, masculine,
etc.?

In general, the link names are nominals, not adjectives, and I was trying
to be consistent, ...    I could be persuaded to lose the form for all of
these if everyone agrees.

I think diminutive and augmentative are also ok as just sense/sense.
For male/female/young, I would like to capture relations like 'King Queen',
'Kangaroo Joey' as well as 'Prince Princess' and 'Pig Piglet', So I would
like to leave it at    I guess if we thought it important we could have two
different sets of relations, but I would prefer to leave that for another
revision.
I have checked in the changes to the synset/sense level issues in
the documentation.
do we want the names to be:
young/has_young
male/has_male    (to emphasize the concept)
female/has_female    (to emphasize the concept)
diminuative/has_diminuative
augmentative/has_augmentative
If everyone agrees I will make this change too.
--
Francis Bond http://www3.ntu.edu.sg/home/fcbond/
Division of Linguistics and Multilingual Studies
Nanyang Technological University

Hi,
A couple of comments on the implementation of these new relationships:

Could we lose the _of from property names like augmentative_of?
This would fit the style better

I also prefer without _of, but I'm not sure we have a consistent style.
Here are some existing relations with of:

state_of ⇔ be_in_state
subevent ⇔ is_subevent_of
manner_of ⇔ in_manner

Similarly, these by ones are inconsistent:

restricts ⇔ restricted_by
entails ⇔ is_entailed_by

Maybe we could use some relation naming guidelines.

Actually I have been thinking that for the next round we should try to do
a consistent renaming (like Eurowordnet did).

I would also opt for consistent renaming and where possible shorter forms.
Until then, I guess I am OK with trying be consistent and going for shorter

here (I am assuming we can update the paper after the conference).

We are both ok with losing the '_of'

Yes.

simple_aspect_pi and secondary_aspect_pi are marked as not
directly applicable. So what is the point of them??

"(not directly applicable)" is what is shown by the HTML templates when
a relation is not marked as a synset-synset, sense-sense, or sense-synset
relation (e.g., for constitutive). My guess is that someone forgot to
mark these relations as such. Otherwise I'd agree that there's no point. I
think for "constitutive", which is not defined in the DTD, it is only there
to group related relations as a supertype. Maybe it should go?

Michael is correct, it was a bug, I have fixed it.

I have also marked them both to be just for sense-sense level relations.

Both aspectual relations are derivationally based and are sense-sense
relations in plWordNet and I would opt to keep them as such generally.
"Constitutive" groups relations that define synset membership in plWordNet,
such as hypo/hypernymy, mero/holonymy which are synset-synset and antonymy
which is sense-sense.

ir_synonym is allowed between senses, but its parent relationship
is not. This is a contradiction. I think that ir_synonym should not
be allowed between senses

I see the logical argument, and also I think it's easier to start with a
tight schema then loosen it later than vice versa. However, in the Japanese
Wordnet we have words sharing a synset where some are interregister
synonyms (e.g., 召し上がる, 召しあがる, 召上る (yes, three of them), 召される, 召す, 上がる, 食事,
食む, 食らう, 食う, 食べる, 食する, and 頂く all share a synset). These cannot be modeled
with a synset-only relation. But maybe adapting the schema to the data we
have is putting the cart before the horse and we should instead change the
data (e.g., splitting those into different synsets)?

I agree for the Japanese wordnet, we should definitely split these.  I
was trying to also allow the schema to model the Polish Wordnet, which
treats these all as sense level relations, but as I think that for them
synset is not a basic relation, maybe we should not worry about it?   In
which case I agree that sense-level is not needed.  Ewa?

I have also changed these to sense-sense.

Inter register synonymy is a synset-synset relation in plWordNet  and as I
understood me and Francis agreed to keep it as such for the general model,
too. It need not be derivationally based, as most other new relations that
we are adding now.

Similarly, simple_aspect_ip and secondary_aspect_ip are allowed
between synsets, but not between its parent derivation. Again this
is contradictory and we should probably not allow this.

Ditto my first sentence from (3) above. I don't have any opinion or
counterexamples otherwise.

Ewa?

As written above, both aspectual relations are sense-sense in plWordNet,
because they are derivationally based, so their parent is derivation, also
a sense-level one and I would keep to that in our format, too.

I have another related concern:

I find the _form relations (feminine_form, masculine_form, etc.)
slightly odd. Why are we talking about "form" at the synset level? That
seems like a word (or sense) thing. Why not just feminine, masculine,
etc.?

In general, the link names are nominals, not adjectives, and I was trying
to be consistent, ...    I could be persuaded to lose the form for all of
these if everyone agrees.

I think diminutive and augmentative are also ok as just sense/sense.

Yes, because again they are derivationally based (at least in Polish, but
in other Slavic languages, too).

For male/female/young, I would like to capture relations like 'King
Queen', 'Kangaroo Joey' as well as 'Prince Princess' and 'Pig Piglet', So I
would like to leave it at

I guess it was supposed to be at synset level, because they are not always
derivationally based and we want to note all instances of such relations.
I guess if we thought it important we could have two different sets of

relations, but I would prefer to leave that for another revision.
I have checked in the changes to the synset/sense level issues in
the documentation.
do we want the names to be:
young/has_young
male/has_male    (to emphasize the concept)
female/has_female    (to emphasize the concept)
diminuative/has_diminuative
augmentative/has_augmentative

I am ok with that, it should only be 'diminutive '.

If everyone agrees I will make this change too.

Best,
Ewa

--
Francis Bond http://www3.ntu.edu.sg/home/fcbond/
Division of Linguistics and Multilingual Studies
Nanyang Technological University

Hi,
A couple of comments on the implementation of these new relationships:

Could we lose the _of from property names like augmentative_of?
This would fit the style better

I also prefer without _of, but I'm not sure we have a consistent style.
Here are some existing relations with of:

state_of ⇔ be_in_state
subevent ⇔ is_subevent_of
manner_of ⇔ in_manner

Similarly, these by ones are inconsistent:

restricts ⇔ restricted_by
entails ⇔ is_entailed_by

Maybe we could use some relation naming guidelines.

Actually I have been thinking that for the next round we should try to do
a consistent renaming (like Eurowordnet did).

I would also opt for consistent renaming and where possible shorter forms.
Until then, I guess I am OK with trying be consistent and going for shorter

here (I am assuming we can update the paper after the conference).

We are both ok with losing the '_of'

Yes.

simple_aspect_pi and secondary_aspect_pi are marked as not
directly applicable. So what is the point of them??

"(not directly applicable)" is what is shown by the HTML templates when
a relation is not marked as a synset-synset, sense-sense, or sense-synset
relation (e.g., for constitutive). My guess is that someone forgot to
mark these relations as such. Otherwise I'd agree that there's no point. I
think for "constitutive", which is not defined in the DTD, it is only there
to group related relations as a supertype. Maybe it should go?

Michael is correct, it was a bug, I have fixed it.

I have also marked them both to be just for sense-sense level relations.

Both aspectual relations are derivationally based and are sense-sense
relations in plWordNet and I would opt to keep them as such generally.
"Constitutive" groups relations that define synset membership in plWordNet,
such as hypo/hypernymy, mero/holonymy which are synset-synset and antonymy
which is sense-sense.

ir_synonym is allowed between senses, but its parent relationship
is not. This is a contradiction. I think that ir_synonym should not
be allowed between senses

I see the logical argument, and also I think it's easier to start with a
tight schema then loosen it later than vice versa. However, in the Japanese
Wordnet we have words sharing a synset where some are interregister
synonyms (e.g., 召し上がる, 召しあがる, 召上る (yes, three of them), 召される, 召す, 上がる, 食事,
食む, 食らう, 食う, 食べる, 食する, and 頂く all share a synset). These cannot be modeled
with a synset-only relation. But maybe adapting the schema to the data we
have is putting the cart before the horse and we should instead change the
data (e.g., splitting those into different synsets)?

I agree for the Japanese wordnet, we should definitely split these.  I
was trying to also allow the schema to model the Polish Wordnet, which
treats these all as sense level relations, but as I think that for them
synset is not a basic relation, maybe we should not worry about it?   In
which case I agree that sense-level is not needed.  Ewa?

I have also changed these to sense-sense.

Inter register synonymy is a synset-synset relation in plWordNet  and as I
understood me and Francis agreed to keep it as such for the general model,
too. It need not be derivationally based, as most other new relations that
we are adding now.

Similarly, simple_aspect_ip and secondary_aspect_ip are allowed
between synsets, but not between its parent derivation. Again this
is contradictory and we should probably not allow this.

Ditto my first sentence from (3) above. I don't have any opinion or
counterexamples otherwise.

Ewa?

As written above, both aspectual relations are sense-sense in plWordNet,
because they are derivationally based, so their parent is derivation, also
a sense-level one and I would keep to that in our format, too.

I have another related concern:

I find the _form relations (feminine_form, masculine_form, etc.)
slightly odd. Why are we talking about "form" at the synset level? That
seems like a word (or sense) thing. Why not just feminine, masculine,
etc.?

In general, the link names are nominals, not adjectives, and I was trying
to be consistent, ...    I could be persuaded to lose the form for all of
these if everyone agrees.

I think diminutive and augmentative are also ok as just sense/sense.

Yes, because again they are derivationally based (at least in Polish, but
in other Slavic languages, too).

For male/female/young, I would like to capture relations like 'King
Queen', 'Kangaroo Joey' as well as 'Prince Princess' and 'Pig Piglet', So I
would like to leave it at

I guess it was supposed to be at synset level, because they are not always
derivationally based and we want to note all instances of such relations.
I guess if we thought it important we could have two different sets of

relations, but I would prefer to leave that for another revision.
I have checked in the changes to the synset/sense level issues in
the documentation.
do we want the names to be:
young/has_young
male/has_male    (to emphasize the concept)
female/has_female    (to emphasize the concept)
diminuative/has_diminuative
augmentative/has_augmentative

I am ok with that, it should only be 'diminutive '.

If everyone agrees I will make this change too.

Best,
Ewa

--
Francis Bond http://www3.ntu.edu.sg/home/fcbond/
Division of Linguistics and Multilingual Studies
Nanyang Technological University

Just confirming that ir_synonym is changed to synset-synset and not sense-sense as written above?
Also, I see that you've changed masculine to male and feminine to female. My qualm was with using the _form suffix, not with the masculine/feminine part. There are times that the grammatical gender does not match the natural gender (for example, from Wikipedia, cailín "girl" (Irish) is masculine), so male/female might be problematic. Which are we annotating?

Just confirming that ir_synonym is changed to synset-synset and not sense-sense as written above?
Also, I see that you've changed masculine to male and feminine to female. My qualm was with using the _form suffix, not with the masculine/feminine part. There are times that the grammatical gender does not match the natural gender (for example, from Wikipedia, cailín "girl" (Irish) is masculine), so male/female might be problematic. Which are we annotating?

Hi,
On Thu, Jan 14, 2021 at 3:39 PM Michael Wayne Goodman <
<EMAIL_ADDRESS>wrote:

Just confirming that ir_synonym is changed to synset-synset and not
sense-sense as written above?

Yes, sorry for the confusion.

Also, I see that you've changed masculine to male and feminine to female.
My qualm was with using the _form suffix, not with the masculine/feminine
part. There are times that the grammatical gender does not match the
natural gender (for example, from Wikipedia
https://en.wikipedia.org/wiki/Grammatical_gender#Grammatical_gender_need_not_match_natural_gender,
cailín "girl" (Irish) is masculine), so male/female might be
problematic. Which are we annotating?

We are annotating natural gender, which is why I suggested the change.
I guess if we wanted to have the sense-sense separate from synset-synset,
then the former would be masculine/feminine and the latter male/female, ....
--
Francis Bond http://www3.ntu.edu.sg/home/fcbond/
Division of Linguistics and Multilingual Studies
Nanyang Technological University

Hi,
On Thu, Jan 14, 2021 at 3:39 PM Michael Wayne Goodman <
<EMAIL_ADDRESS>wrote:

Just confirming that ir_synonym is changed to synset-synset and not
sense-sense as written above?

Yes, sorry for the confusion.

Also, I see that you've changed masculine to male and feminine to female.
My qualm was with using the _form suffix, not with the masculine/feminine
part. There are times that the grammatical gender does not match the
natural gender (for example, from Wikipedia
https://en.wikipedia.org/wiki/Grammatical_gender#Grammatical_gender_need_not_match_natural_gender,
cailín "girl" (Irish) is masculine), so male/female might be
problematic. Which are we annotating?

We are annotating natural gender, which is why I suggested the change.
I guess if we wanted to have the sense-sense separate from synset-synset,
then the former would be masculine/feminine and the latter male/female, ....
--
Francis Bond http://www3.ntu.edu.sg/home/fcbond/
Division of Linguistics and Multilingual Studies
Nanyang Technological University

I changed the names in the paper, and will update the PR on the weekend.
John can you submit the final version to Alexandre, or would you like me to
do it?
On Thu, Jan 14, 2021 at 3:46 PM Francis Bond<EMAIL_ADDRESS>wrote:

Hi,
On Thu, Jan 14, 2021 at 3:39 PM Michael Wayne Goodman <
<EMAIL_ADDRESS>wrote:

Just confirming that ir_synonym is changed to synset-synset and not
sense-sense as written above?

Yes, sorry for the confusion.

Also, I see that you've changed masculine to male and feminine to female.
My qualm was with using the _form suffix, not with the masculine/feminine
part. There are times that the grammatical gender does not match the
natural gender (for example, from Wikipedia
https://en.wikipedia.org/wiki/Grammatical_gender#Grammatical_gender_need_not_match_natural_gender,
cailín "girl" (Irish) is masculine), so male/female might be
problematic. Which are we annotating?

We are annotating natural gender, which is why I suggested the change.
I guess if we wanted to have the sense-sense separate from synset-synset,
then the former would be masculine/feminine and the latter male/female, ....
--
Francis Bond http://www3.ntu.edu.sg/home/fcbond/
Division of Linguistics and Multilingual Studies
Nanyang Technological University

--
Francis Bond http://www3.ntu.edu.sg/home/fcbond/
Division of Linguistics and Multilingual Studies
Nanyang Technological University

I changed the names in the paper, and will update the PR on the weekend.
John can you submit the final version to Alexandre, or would you like me to
do it?
On Thu, Jan 14, 2021 at 3:46 PM Francis Bond<EMAIL_ADDRESS>wrote:

Hi,
On Thu, Jan 14, 2021 at 3:39 PM Michael Wayne Goodman <
<EMAIL_ADDRESS>wrote:

Just confirming that ir_synonym is changed to synset-synset and not
sense-sense as written above?

Yes, sorry for the confusion.

Also, I see that you've changed masculine to male and feminine to female.
My qualm was with using the _form suffix, not with the masculine/feminine
part. There are times that the grammatical gender does not match the
natural gender (for example, from Wikipedia
https://en.wikipedia.org/wiki/Grammatical_gender#Grammatical_gender_need_not_match_natural_gender,
cailín "girl" (Irish) is masculine), so male/female might be
problematic. Which are we annotating?

We are annotating natural gender, which is why I suggested the change.
I guess if we wanted to have the sense-sense separate from synset-synset,
then the former would be masculine/feminine and the latter male/female, ....
--
Francis Bond http://www3.ntu.edu.sg/home/fcbond/
Division of Linguistics and Multilingual Studies
Nanyang Technological University

--
Francis Bond http://www3.ntu.edu.sg/home/fcbond/
Division of Linguistics and Multilingual Studies
Nanyang Technological University

Will do

Will do


Feature/linux dictionary move

@yaronweiss, please review the PR and merge to the master.

@MeniKadosh1, changes are implemented. Please check and then I will merge the code to master.

@MeniKadosh1, implemented the changes your sent for review. Please check and approve.

Ravi – Please confirm the testing looks good too.
Thanks,
Yaron.
From: Ravi Kethe<EMAIL_ADDRESS>Sent: Thursday, October 18, 2018 10:22 AM
To: Ginger-Automation/Ginger<EMAIL_ADDRESS>Cc: Yaron Weiss<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Ginger-Automation/Ginger] Feature/linux dictionary move (#207)
@ravikirankethe commented on this pull request.
Meni, I have merged with Master and resolved conflict. Let me know if this can be pushed to the master now.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Ginger-Automation/Ginger/pull/207#pullrequestreview-166152715, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AfO-Mg1ALSrFYUXSAjchMDwEt5B13Lhtks5umJx_gaJpZM4XaUme.
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer https://www.amdocs.com/about/email-disclaimer


adding fix for vm log capture

Adding the following fixes:

Try to fix vm capture log through output
Prometheus - fix enable variable
Disable OCP installation on Sunday and add just nightly run instead

Yep.


Update rktnetes to 1151.0.0 and fix Docker 1.12 issue

Resolves several docker2aci bugs in rkt 1.11.0 https://github.com/coreos/rkt/pull/3026
Install to disk (rktnetes-install) is not yet working https://github.com/coreos/bugs/issues/1541
Docker v1.12 dockerd fails if given the daemon argument (doesn't break rktnetes, but fix is desirable)
Applies https://github.com/coreos/coreos-kubernetes/pull/642

cc: @pbx0 @euank

Verified this works as before and the docker.service no longer fails.
kubectl --kubeconfig=examples/assets/tls/kubeconfig get pods --all-namespaces
NAMESPACE     NAME                                        READY     STATUS    RESTARTS   AGE
kube-system   heapster-v1.1.0-3647315203-w00td            2/2       Running   0          16m
kube-system   kube-apiserver-node1.example.com            1/1       Running   0          16m
kube-system   kube-controller-manager-node1.example.com   1/1       Running   0          16m
kube-system   kube-dns-v15-kmnr9                          3/3       Running   0          16m
kube-system   kube-proxy-node1.example.com                1/1       Running   0          16m
kube-system   kube-proxy-node2.example.com                1/1       Running   0          15m
kube-system   kube-proxy-node3.example.com                1/1       Running   0          15m
kube-system   kube-scheduler-node1.example.com            1/1       Running   0          16m
kube-system   kubernetes-dashboard-v1.1.0-v5keo           1/1       Running   0          16m

Now able to deploy test containers from Quay (going through docker2aci). This wasn't working with rkt 1.11.0, but now do :)
NAMESPACE     NAME                                        READY     STATUS    RESTARTS   AGE
default       hellogo-56039949-rkhld                      1/1       Running   0          1m


Handle multiple link_libs calls for the same target

Linking additional targets by calling target_link_libraries multiple times (potential gated via if in case of optional features) is recommended practice for modern CMake. Currently this case not handled well, we only add a keyword.

To really properly support this it might be necessary to read  User/CMakePresets file and infer variables used in if gated calls...


Add magentic - Seamlessly integrate LLMs as Python functions

Please add magentic alongside LangChain and LiteChain. This is a python package with a new approach to integrating LLMs based on using Python functions with type annotations. I am the author.
https://github.com/jackmpcollins/magentic

Thanks for this!


Autocorrect(autoreplacement) by dictionary

Description of the new feature / enhancement
Add the autocorrect tab by matching dictionary.
Scenario when this would be used?
Reduction of input time for frequent commands, ip addresses, use in correspondence
Supporting information
No response

Can you elaborate on this?
Where do you want to have this autocorrect?
Windows already have a built-in spellcheck that works on most applications.

/needinfo

Unfortunately, this does not work in all applications, for example, wsl, powershell, many IDEs and many others. Of course, you can use other solutions or write your own, but it's much nicer to see it in powertoys.

/dup https://github.com/microsoft/PowerToys/issues/5074


Itseez/demo

This is good.  I find this very useful. 😃
However you should change the readme.md in the project root if the example image has been moved to demo.
Right now I can see it is a dead reference.

I made the links in the readme relative to the root of the readme so that they work with any branch.


Steps to replicate quantitative results shown in Table 1 of the paper

Thank you for this work. Would you be able to give the steps to replicate the quantitative results (of GeneFace) shown in Table 1 of the paper?

Hello, for FID, we use this repo, for SyncScore, see this repo, for Error-related metrics, you can see the tensorboard.

Thank you for your response. Would you be able to give me the names of the videos that you have used for training and inference, both in-domain and out-of-domain? In the link that you have provided for other target person videos, there are 8 videos. In the paper (Section 4, Dataset Preparation), it is mentioned that 5 videos have been utilized for experiments. Which of the 8 videos are the mentioned 5 videos? Which video and audio files did you use for out-of-domain testing? Thank you for your time.


Cluster deployment question : about configuration.sh

Hello!
When I carry out the step 4 "Project Deployment", I have a question with the setting of the file configuration.sh.
My situation: three virtual machines，their ips: ***16, ***17, ***18 (Replaced with 16 17 18)
And 16 is host ; 17 is guest ; 18 is arbiter.
　　　　　   And each machine contains all the modules.
The following is my specific settings in one machine.
#!/bin/bash
user=app
dir=/data/projects/fate
mysqldir=/data/projects/common/mysql/mysql-8.0
javadir=/data/projects/common/jdk/jdk1.8
venvdir=/data/projects/fate/venv
redisip=(16 17 18)
redispass=fate1234
partylist=(9999 10000 10001)
JDBC0=(16 fate0 fate Fate123#$)
JDBC1=(17 fate1 fate Fate123#$)
JDBC2=(18 fate2 fate Fate123#$)
iplist=(16 17)
fedlist0=(16)
fedlist1=(17)
fedlist2=(18)
meta0=(16)
meta1=(17)
meta2=(18)
proxy0=(16)
proxy1=(17)
proxy2=(18)
roll0=(16)
roll1=(17)
roll2=(18)
egglist0=(16)
egglist1=(17)
egglist2=(18)
tmlist0=(16)
tmlist1=(17)
tmlist2=(18)
serving0=(16)
serving1=(17)
serving2=(18)
exchangeip=18
Is there a mistake in my configuration?
Is the configuration of the three machines the same?
Thank you for your answer！

At present, the deployment supports single-party deployment and simultaneous deployment of two-party parties. Currently, the simultaneous deployment of the three parties is not supported. You can deploy both parties first, and then add one party.

Thank you for your reply！
I will try to deploy both parties simultaneously, and is the configuration of the two machines the same?
Do they have the same file "configuration.sh"?

These are the modified settings. Is it correct?
#!/bin/bash
user=app
dir=/data/projects/fate
mysqldir=/data/projects/common/mysql/mysql-8.0
javadir=/data/projects/common/jdk/jdk1.8
venvdir=/data/projects/fate/venv
redisip=(16 17)
redispass=fate1234
partylist=(9999 10000)
JDBC0=(16 fate0 fate Fate123#$)
JDBC1=(17 fate1 fate Fate123#$)
iplist=(16 17)
fedlist0=(16)
fedlist1=(17)
meta0=(16)
meta1=(17)
proxy0=(16)
proxy1=(17)
roll0=(16)
roll1=(17)
egglist0=(16)
egglist1=(17)
tmlist0=(16)
tmlist1=(17)
serving0=(16)
serving1=(17)
exchangeip=


CSS-grid not supported.

See: https://github.com/sass/sass/issues/2233
Summary: With the release of FF52 and GC57, CSS-grid layout is now supported. With this new feature, construct like  grid-template-columns: repeat(5, 1fr) are present.
The CSS function 'repeat' is not really supported by SASS.
Solution: The last version of SASS (3.5) addresses the issue.

sass 3.5 is already supported by this gem https://github.com/rails/sass-rails/blob/v5.0.6/sass-rails.gemspec#L17, so why it is not supported?

It works perfectly well in development mode.
It fails only in production environment with rake asset:precompile (aka heroku deploy).

If it works in development and not in production with the same set of gems I recommend you to report the issue to your production environment since it seems to be related with it.
sass-rails supports sass 3.5 and if it is fixed in sass 3.5 so you should be able to get it installed. If the issue is not fixed in sass 3.5, you should report the issue in the sass repository since sass-rails is just a wrapper around sass.

I have the error locally when I run:
RAILS_ENV=production bundle exec rake assets:precompile
So, the problem starts here (locally) when I test my local environment in production mode.

Can you please provide a sample application that reproduces the error?

@rafaelfranca, I'm having a similar error using @supports.
Just try:
.header {
  backdrop-filter: saturate(180%) blur(20px);
  background-color: rgba(#fff, 0.975);

  @supports (backdrop-filter: blur()) {
    background-color: rgba(#fff, 0.8);
  }
}

It works on development mode, but not in production.

sass-rails doesn't defines the sass behavior, the gem responsible for this is sass, if it is working in development and not production either it is a problem in sass or the production envrionment.

Sass added support https://github.com/sass/sass/issues/2233


Fix string out-of-bounds access

Running the tests with the program compiled with custom flags discovered an out of bounds access:
<mock-chroot> sh-5.2# ./base64.t
1..2
ok - base64 encoding
/usr/include/c++/14/string_view:283: constexpr const std::basic_string_view<_CharT, _Traits>::value_type& std::basic_string_view<_CharT, _Traits>::back() const [with _CharT = char8_t; _Traits = std::char_traits<char8_t>; const_reference = const char8_t&]: Assertion 'this->_M_len > 0' failed.
Aborted (core dumped)

Have you considered adding GitHub Actions to run tests with sanitized binary or with valgrind?

Thank you for finding this out.
Given the low number of pull requests, I use to run make check manually before merging something. If you know a good set of flags, I could add them to the CMakeLists.txt so that every development build uses them, or possibly introduce a new build type for tests to systematically use sanitized binaries.


Grab SdkGenny via Vcpkg

Use a Vcpkg registry to grab SdkGenny instead of copying it directly into this project.

Closed because using FetchPackage was a lot simpler.


BBFindVAD: Exception

ZIRAK-PC.txt
Hi,
I'm running Windows 10.0.10586.0.103 and it seems like I have been encountering "BBFindVAD: Exception" whenever I try to change the memory protection access for Explorer.exe.
This occurs in the "BBProtectMemory" function where it executes:
status = BBGetVadType( pProcess, pProtect->base, &vadType );
Would it be possible that the offsets changed for this version of Windows 10?
Thanks!

Not sure what the issue was, but I managed to get it to resolved somehow. Closing out ticket!


Added instructions for tree-sitter-swift in Web Assembly

Added instructions for using wasm based tree-sitter-swift.

Fantastic, thank you!!


potential regression in benchmarks.py

I'm trying to run the benchmarks for openjournals/joss-reviews#7134, but I'm getting:
Traceback (most recent call last):
  File "./misc/benchmark.py", line 143, in <module>
    H1, T1 = bench_bodge(L, W)
  File "./misc/benchmark.py", line 120, in bench_bodge
    H = system(format="csr")
TypeError: 'Hamiltonian' object is not callable

Any ideas?

Hi, thanks for checking the benchmarks.
I changed the Hamiltonian class a bit before submitting to JOSS, including that I renamed Hamiltonian.__call__(format=...) (which implemented the magic system(format=...) syntax above) to Hamiltonian.matrix(format=...) to make the conversion more explicit. I think the only change needed is to change system(...) to system.matrix(...) in the benchmark code, but I'll have a quick look now to see if I've overlooked anything else :)

I pushed a quick fix to the main branch now, with the update mentioned above the benchmark script is working again for me :).
Remember also to do a pip install kwant if you haven't already, to fetch the library that I'm benchmarking against as well. I added a quick note of this to the top of the benchmark script now.

I guess the benchmark script is fixed now, so I'll close this issue as resolved. But please feel free to reopen it if you have any more problems, and I'd be happy to help.


Problem help

Excuse me, I am a student related to quality evaluation. I have the honor to read your paper on quality evaluation. It seems that the code you provided lacks some sub functions, such as crop_ Saliency_ Percentage and concatenate_ Data and predict. Is it convenient to provide it? Thank you very much!

Hello, sir. It's my honor to read your paper. I want to try your method in my research direction, but I have a few questions. I hope you can answer them. First of all, how to determine the maximum disparity distance? Different data sets are different, so is it determined through multiple experiments? Secondly, there is a little distortion after fusion. Will this affect the experimental results? Or how to avoid such distortion? Thank you very much for your reading
| |
陈平安
|
|
@.***
|
---- Replied Message ----
| From | Oussama @.> |
| Date | 6/16/2022 21:05 |
| To | @.> |
| Cc | @.> ,
@.> |
| Subject | Re: [o-messai/3D-NR-SIQA] Problem help (Issue #1) |
Sorry for the missing functions ! It should work now. Please let me know if you face any other problems.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

Hi, thank you for your good questions,
1- We have fixed the disparity manually for all datasets to be 25 (if I remember correctly). It depends on the image resolution, you may increase the max. disparity for higher resolution to get better estimation, but we have conducted some tests and found that fixing it for all datasets is not bad.
2- The distortions after fusion is more likely caused by the disparity map, and it actually does not effect much the results since we process the whole cyclopean image and the other distortion will be dominant (i,e., jpeg, WN, etc.), but even if it effects the results it should be in a good way: the distortion in stereo=>cause bad depth information=> cause bad fusion=> bad quality.
I hope the arrows below resumes my answer:
Distorted stereo image=>bad disparity map => bad depth information perceived by the viewer (using stereo glasses)  => bad fusion added little new distortion (but not dominant)=> bad cyclopean view inside his brain=> bad quality, discomfort and maybe headache.
Anyway if you want to avoid the added little distortion, you need to fine tuning the parameters of the process (like disp. max).

OK, thank you for your answers.
| |
陈平安
|
|
@.***
|
---- Replied Message ----
| From | Oussama @.> |
| Date | 10/20/2022 16:44 |
| To | @.> |
| Cc | @.> ,
@.> |
| Subject | Re: [o-messai/3D-NR-SIQA] Problem help (Issue #1) |
Hi, thank you for your good questions,
1- We have fixed the disparity manually for all datasets to be 25 (if I remember correctly). It depends on the image resolution, you may increase the max. disparity for higher resolution to get better estimation, but we have conducted some tests and found that fixing it for all datasets is not bad.
2- The distortions after fusion is more likely caused by the disparity map, and it actually does not effect much the results since we process the whole cyclopean image and the other distortion will be dominant (i,e., jpeg, WN, etc.), but even if it effects the results it should be in a good way: the distortion in stereo=>cause bad depth information=> cause bad fusion=> bad quality.
I hope the arrows below resumes my answer:
Distorted stereo image=>bad disparity map => bad depth information perceived by the viewer (using stereo glasses) => bad fusion added little new distortion (but not dominant)=> bad cyclopean view inside his brain=> bad quality, discomfort and maybe headache.
Anyway if you want to avoid the added little distortion, you need to fine tuning the parameters of the process (like disp. max).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


PolkaKey

Grant Application Checklist

[x] The application-template.md has been copied, renamed ( "project_name.md") and updated.
[x] A BTC address for the payment of the milestones is provided inside the application.
[x] The software of the project will be released under the Apache license version 2.0 as specified in the terms and conditions.
[x] The total funding amount of the project is below 30k at the time of submission.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Hi. Thanks for the application. I just added your desktop wallet sakura to our tech stack document, see https://github.com/w3f/General-Grants-Program/blob/master/grants/polkadot_stack.md#iphone-explorer-and-wallets. In general, multiple wallet providers are currently already working on potentially more secure and more user-friendly solutions (e.g. https://www.parity.io/signer/ or https://github.com/w3f/General-Grants-Program/blob/master/grants/accepted_grant_applications.md). However, given the low total costs of your project, maybe it might be useful as a nice Electron tutorial for our ecosystem. Would you be willing to add a Chinese + English tutorial to your application?

Hi. Thanks for adding sakura to the tech stack document, but this is still an work-in-progress project, and I can only do this work in my spare time, so there are no exact milestones for this project.

申请提案后可将提案链接同步到Pr

Hi. Sorry for the late reply. Regarding sakura, it's not an issue that it's still work in progress. The intention behind the document is also to give other people an overview of existing projects so that they could pick it up and leverage it for their own projects. What I meant with the tutorial was to create one for a simple electron app for substrate/polkadot (similar for example to the following https://substrate.dev/docs/en/tutorials/substrate-front-end/). Basically use this project/PolkaKey also to help other developers to get get started with electron plus our tech stack.

What I meant with the tutorial was to create one for a simple electron app for substrate/polkadot (similar for example to the following https://substrate.dev/docs/en/tutorials/substrate-front-end/). Basically use this project/PolkaKey also to help other developers to get get started with electron plus our tech stack.

Hi, that's a great idea, and I'd love to do it. But I may need another two weeks to add a Chinese + English tutorial, because I'm very busy recently. I updated the milestone. Please let me know if there are questions.

Hi. Thanks for adding the tutorial. I have one last request, could you specify the milestone section a little bit better. For example add information on how you're going to test the code (e.g. unit tests, which testing framework, etc.), which function are you implementing (e.g. generate a polkadot address via electron), what is the content of the tutorial, where do you plan to publish it, etc..  We will use this milestone section to test your delivery, so it's basically similar to the requirements of regular contracts and therefore should be specified a little bit more detailed.

Hi. Sorry for the late reply. I added more detail on the milestone. If possible, i hope to publish the tutorial on Polkaworld and Substrate Dev Hub.

Thank you so much! @Noc2 @gavofyork @keorn

Hi @HiZhaoYun, any plans on finishing this grant? Otherwise we would just remove milestone 3 from the proposal.


Wrong run.csx template

The code template in the step "Add image captions with Computer Vision" contains an old url for the Cognitive API.  The file is this one: https://github.com/Azure-Samples/functions-first-serverless-web-application/blob/master/csharp/ResizeImage/run-module5.csx
The docs generate an url like this:
https://westcentralus.api.cognitive.microsoft.com/analyze?visualFeatures=Description&language=en
But it should be this:
https://westcentralus.api.cognitive.microsoft.com/vision/v1.0/analyze?visualFeatures=Description&language=en

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

ID: b1acd3de-471c-d954-af1a-62f7fc440370
Version Independent ID: 84549c67-6733-e861-6ec9-aab9f248a406
Content: Build a serverless web app in Azure
Content Source: AzureInteractive/tutorial-static-website-serverless-api-with-database.yml
Service: multiple
GitHub Login: @ggailey777
Microsoft Alias: glenga

@BobcatProgrammer Thank you very much for your thorough detail. I will have the content owner review and make an update as appropriate.

Thanks for reporting. We are in the process of updating this article, and I will make sure we get this updated as well. This is now being tracked internally (1347023).

Just to circle back on this issue. We have superseded this interactive tutorial with a new Microsoft Learn module that features a serverless web app. The new module supports Azure Functions v2.x. If you are interested in the image resize scenario, see this Event Grid tutorial.


If I guess correctly within 5 seconds I get 100 points

68bcc4ba3db05582590193ccbaddb14681cf70b2

68bcc4ba3db05582590193ccbaddb14681cf70b2

05f41deb8284ba8c072517ac35536871bd0c598f

Deployment failed, since one Test was not modified. But meanwhile Test is modified and everything is ok again.


fix: trade input validation fix for Balancer routed trades

Description
This is a follow to https://github.com/balancer-labs/frontend-v2/pull/1065
The problem was that Gnosis didn't really need this check since its "loading" state is more like "refreshing". For Balancer routed trades - this is a good solution.
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Other

How should this be tested?
Please provide instructions so we can test. Please also list any relevant details for your test configuration.

[ ] Try to input quickly before the pools are loaded (Balancer trades) - it won't let you since the input is disabled.
[ ] Gnosis / Wrapped trades should be working as normal (without losing their focus)

Checklist:

[x] I have performed a self-review of my own code
[x] I have commented my code where relevant, particularly in hard-to-understand areas
[x] My changes generate no new console warnings
[x] The base of this PR is master if hotfix, develop if not

I totally agree with you - this needs a proper solution.
But for now, this might be a good quick win since the current behaviour is indeed worse.


Fix conversion of zip-directory entries

The first return value of ZIPPY:ATTRIBUTES is a plist.

Thanks!


Made changes to constant

Made changes from 2020 to importing year variable

Yes, I did as you've asked .. let me know if that is fine

What about now..?
Sorry, I'm a beginner to open source , that's why had to make a lot of changes😅 and thanks for the opportunity :)

I learnt a lot along the way, thanks a lot for that too!


RDCC 418-v2 Update user status

JIRA link (if applicable)
RDCC-418
Change description
Update user status
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[X] No

Functional test cases have been added for status change and also regression tests for add/delete roles working fine.Build id green. Please approve this pull request.

Functional test cases (within PR-171) have been added for status change and also regression tests for add/delete roles working fine.Build id green


Align ref picker with built-in git extension ref picker

@joyceerhl I don't see HEAD, i do see main (default).
Like this from desktop:

Originally posted by @karthiknadig in https://github.com/microsoft/vscode-remote-repositories-github/issues/206#issuecomment-1171514182

Builtin git extension:

RemoteHub:


Aquatic creatures on land

In the Pathfinding Framework it is possible to define movement types which are not allowed to traverse tiles which are fine to walk over in vanilla, such as for example aquatic creatures not being allowed on land.
Forbidding these creatures from ever being in disallowed tiles would require a huge number of Harmony patching that would impact performance, so instead the mod follows a different approach. Aquatic creatures are allowed in land, but with huge path costs. This will make them avoid land tiles naturally in pathfinding, but it is not enough to prevent them from trying to reach food on land, for example.
Solving this issue requires multiple patches and features:

#11
Sleeping: JobGiver_GetRest
Wandering.
Going for a walk: JoyGiver_GoForWalk
Watching the sunset.

Should be resolved with the overall bugfixing and feature implementation work. When any further bugs are found, they will get a specific issue entry.


Client HTTP requests to OSS Index API  should be done in parallel where possible

Right now client requests are serialized which leads to long wait time for getting results for projects with many dependencies. A parallel implementation of querying the API can make things significantly faster and perhaps remove the need for a cache.

Actually, the cache is required due to there being rate limiting on the new API. By caching we ensure that each package is only queried once per day, which means any particular user is less likely to hit the cache.
The rate limiting uses a "leaky bucket" algorithm. Depending on whether you are a registered user or not, the rate limit has a different starting number of requests (16 for non-registered, 64 for registered). Each request can be for 128 total packages. Requests replenish at a rate of one per minute.
So regardless of whether we add parallelization, we definitely don't want to get rid of the caching.


overload(capslock, esc) : it's not a valid layer

Hello. I've been tweking my config and after two days of some reading (very nice docs btw) I have finally move my xmodmap keys config to keyd.
Now that I have more liberty in this program I'm experimenting with escing in other key rather than the actual esc key, my config:
[ids]

*

[main]

# Don't hold that shift
shift = oneshot(shift)

# meta as esc?
meta = overload(esc, meta)

# remap the escape key to capslock if held
esc = overload(capslock, esc)

# CapsLock to delete (very fast)
capslock = backspace

# Left alt to altgr
leftalt = layer(altgr)

# Right alt (altgr) to control for pinky safety
rightalt = layer(control)

[altgr]

# vim keys in altgr (deadkeys) mode
h = left
j = down
k = up
l = right

which gives me:
ERROR /etc/keyd/default.conf:11: "esc" is not a valid layer
ERROR /etc/keyd/default.conf:14: "capslock" is not a valid layer

I've tried with:
[capslock]

capslock = capslock

[esc]

esc = esc

at the end (making a layer?) but when I hold esc does not enables capslock. I'm sure I missed something but I don't seem to find it.

The first argument of overload must be a layer. So instead of
meta = overload(esc, meta)

You want
meta = overload(meta, esc)

since meta is a layer.
However
overload(capslock, esc)

Is not valid since neither capslock nor esc are valid layers. Overload is intended to be used in the case where a given key acts as both some kind of modifier (i.e layer toggle) and a normal key. If the above was valid, then the only way to access capslock would be to hold capslock and press another key, which makes little sense.
You might want to try something like this instead:
capslock = overload(capslock, esc)

[capslock:C]

1 = capslock

Which will allow you to access capslock with C-1 and otherwise treat capslock as a control key when held.

meta = overload(meta, esc)
Oh I thought overload args was (tap, hold), thanks.

Overload is intended to be used in the case where a given key acts as both some kind of modifier (i.e layer toggle) and a normal key. If the above was valid, then the only way to access capslock would be to hold capslock and press another key, which makes little sense.

I C. excuse the little experience I have about this, I'm still getting my head around this..
My intended use case is to have the esc key act as esc, but when held act as capslock. would that be possible?

My intended use case is to have the esc key act as esc, but when held act as capslock. would that be possible?

It depends on what you mean by 'held'. In this context 'held' means 'depressed while another key is struck'.
E.G
capslock down
a down
a up
capslock down

as opposed to
capslock down
capslock down
a down
a up

In this context it makes little sense to have the first case generate capslock and the second case generate escape.
If by held you simply mean 'depressed for a certain period of time' then this is unsupported.  I would submit that this is probably a bad idea anyway since you don't want time to be the only thing which distinguishes escape from capslock in the course of normal typing (see also #81 and #34).

you don't want time to be the only thing which distinguishes escape from capslock in the course of normal typing

Well, some keys are not useful when typying or might be used much less. I think this is a very large topic, but in general you could name the function keys, volume up/down and the like (play/next song/airplane mode/etc. Not sure how to name those).
Anyway, in that context i'm sure it will be useful to have an X not that useful key to act as an Y  useful key.

If by held you simply mean 'depressed for a certain period of time' then this is unsupported.

May I ask why? is it that complicated?
I think overload() is: waiting for X ms + another key stroke. So another func like overheld() could only look at time. Just a suggestion, I haven't touch keyd source (yet..).

Well, some keys are not useful when typying or might be used much less.

Agreed. This is the purpose of layers.

Anyway, in that context i'm sure it will be useful to have an X not that useful key to act as an Y useful key.

This is the purpose of overload (which avoids the time based ambiguity, is faster and gives you more flexibility).

May I ask why? is it that complicated?

The complexity lies in the problem domain, not in the implementation. To summarize:
<x down> <x up> = a
<x down> <300 ms> <x up> = b
Has several problems which make it undesirable in practice

It introduces visual latency.

It impedes normal typing flow unless the timeout is sufficiently high.

If the timeout is sufficiently high it is less efficient than just using a normal layer (which allows you to define multiple keys).

The pitafalls of using time to distinguish between keys has already been discussed at length in the referenced threads (and elsewhere). I would advise you to read through them.

I think overload() is: waiting for X ms + another key stroke.

Overload is purely sequence based unless you add a timeout, in which case it will exclusively use time. This behaviour makes sense in the case of layers, it doesn't make sense in the case of individual keys. That is, having a key's entire up/down lifecycle purely depend on time is an inherently bad idea with little benefit. Having said that, you are welcome to make a case for it in one of the aforementioned threads.

Okay I think to summarize, the problems are basically too slow or inefficient. Which I think really doesn't matter since the usecase I said it's on a 'non-typing' (or atleast not that constant) state.

you are welcome to make a case for it in one of the aforementioned threads.

I don't see other usecase rather than the one I mention.
If several other users encounter this, then maybe this topic does deserves a separate issue?

Anyway thank you very much for your feedback and, again, excuse my confusion on this key mapping journey.
One more suggestion, maybe add this example? meta = overload(meta, esc)

Thanks for the feedback.

Which I think really doesn't matter since the usecase I said it's on a 'non-typing' (or atleast not that constant) state.

This assumes that both keys are used infrequently. If at least one of them is then it still presents a problem as outlined in the referenced post.
Even if neither key is used very frequently, I would argue:
<key1 down> <key2 down> <key2 up> <key1> is superior to <key1 down> <300 ms> <key1 up> in almost every real world use case.

If several other users encounter this, then maybe this topic does deserves a separate issue?

Agreed. I am open to reconsidering the feature if there is real world demand (i.e If a non trivial number of people use the set up and don't eventually grow to despise it). I have learned from personal experience that many things which seem appealing in theory don't work in practice.

One more suggestion, maybe add this example? meta = overload(meta, esc)

Done.


Image strectch

Fix image in your pendapat tentang mereka section
from this

to this, and add css object-fit and object-position in your image

Please Close this issue, its already fixed

Please fix change css property not object-cover: top but object-position: top


Ticket/1.6.x/10112 pid

Added fact pid.

ssvarma - I just saw that this one is deeply related to #108 which was rejected due to concerns about the pid of the process that delivers the pid fact and the pid of the process that applies the catalog may not be in sync. Do you have any further question or use cases for this fact or why did you reopened the request?

@ssvarma - this is wrong, and bad, for all the reasons the previous submission was wrong and bad.  Please don't submit essentially unaltered, broken code without understanding why previous code was rejected.


Errors in the documentation

Lots of typos in the documentation. ("copy and pase") as well as logical errors (tells users to place command-line input "to the left of the flag" instead of to the right, constantly using the outdated prettycopy.prettycopy import instead of the current prettycopy import.)

Quite frankly, I should remove the documentation from the README as well. Better to just point users to the autodocumentated ReadTheDocs page.


feat: publish public key, #357

This PR

adds appsMeta to the user's public profile for apps that requested publish_data permission
fixes #357

Replaces #359

For @hstove to review

Thanks @friedger !


xsane fails to start with segmentation fault

Describe the bug
xsane fails to start with error loading libusb.
xsane: error while loading libusb-1.0.so.0 from libusb-0.1.so.4: libusb-1.0.so.0: cannot open shared object file: No such file or directory
zsh: segmentation fault  xsane

To Reproduce
With xsane installed as a system package, run xsane.
Expected behavior
xsane should load and allow scanning.
Metadata

system: "x86_64-linux"
host os: Linux 5.5.13, NixOS, 20.09pre218613.ae6bdcc5358 (Nightingale)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3.3
channels(root): "nixos-20.09pre218613.ae6bdcc5358, nix1709-17.09.3269.14f9ee66e63, nix1803-18.03.133402.cb0e20d6db9, nix1809-18.09.2574.a7e559a5504, nix1903-19.03.173553.6420e2649fa, unstable"
channels(swflint): "nixos-20.09pre215024.e97dfe73bba"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

I cannot reproduce on 20.03 by building and running xsane from your git commit.
However, SANE is impure even on NixOS. Sane backends are loaded from LD_LIBRARY_PATH so it is possible that one of the backends pulls one version of libusb and xsane the other. Since when I tested I still have the LD_LIBRARY_PATH of 20.03 it behaves differently.


Cache results of validated justifications to short-circuit future message verification

Each unique vote value in the protocol only needs to be justified once. After receiving a message with justified value V from one participant, a node need not check the justification received with other messages carrying the same V. This is a huge optimisation, probably necessary for feasible protocol execution at scale.

We might have to do this sooner than later.

From F3 standup discussions: this isn't quite so simple.

We can't re-broadcast messages with invalid justifications, even if we've seen a valid justification.
We can't easily replace the message's justification given that pubsub messages are signed (and identified by the original sender/nonce).
We can disable pubsub signatures and identify messages by their GPBFT payload, but, unfortunately, we use message IDs to deduplicate messages before validating them. That means, if we receive a message with payload X and mark it as invalid (e.g., has an invalid justification) then receive the same payload X with a correct justification, pubsub will drop it before validation because we're identifying inbound messages by payload value.

The solution to all this is to give pubsub two different ways of identifying messages:

For pre-validation deduplication, identify messages by hash, always.
Only use the user-configurable message ID after validation (to determine if we should rebroadcast the message, to identify messages in gossip, etc.).

However, we'd additionally need the ability to mutate pubsub messages: replace the possibly invalid justification (the one we didn't bother checking) with the known valid justification (from our cache).

Closing now that both #557 and #560  are merged. Please feel free to reopen if there is more here to do.


Installation instructions for Apple Silicon

Hi :wave:,
I'm reviewing the PyView JOSS paper.
I'm having trouble installing PyView on my machine which I assume is partially due to Apple Silicon M1 chip. It fails very early (e.g. Python 3.7 is not available for M1 on conda forge).
Could you add instructions for installing the package on newer macs, or better yet, an environment file?
Thanks!

Hi!
Thanks for the question -
I am trying to install conda right now, since yesterday I have an M2 mac, and it does not work yet. Maybe in a few days I will be able to help you. Mac has really changed many things, Anaconda is impossible to install, conda seems to work from the comand line:
https://repo.anaconda.com/archive/Anaconda3-2022.10-MacOSX-arm64.sh https://repo.anaconda.com/archive/Anaconda3-2022.10-MacOSX-arm64.sh
There is an environment file that can be used in conda, and works well with my previous mac. I did not yet have the time to test it with the M2 mac - sorry about that. I will try to do that asap, but I am travelling at the moment and cannot promise how fast I’ll be.
I’m copying Ajayrama Kumaraswamy: he is the computer scientist in our team (I am the biologist), but he does not run a mac, so he might be helpful or might not.
Best
Giovanni

Prof. Dr. Giovanni Galizia
Direktor Zukunftskolleg
Lehrstuhl Neurobiologie
Permanent Fellow Wissenschaftskolleg zu Berlin
@.***
http://neuro.uni.kn

On 16. Nov 2022, at 19:02, Adam Tyson @.***> wrote:
Hi 👋,
I'm reviewing the PyView JOSS paper https://github.com/openjournals/joss-reviews/issues/4936.
I'm having trouble installing PyView on my machine which I assume is partially due to Apple Silicon M1 chip. It fails very early (e.g. Python 3.7 is not available for M1 on conda forge).
Could you add instructions for installing the package on newer macs, or better yet, an environment file?
Thanks!
—
Reply to this email directly, view it on GitHub https://github.com/galizia-lab/pyview/issues/18, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACRMY4VRQXBS3R2VULRXNGDWIUOU7ANCNFSM6AAAAAASCQK3VQ.
You are receiving this because you are subscribed to this thread.

Thanks @galizia. Let me know if I can be of any help. We have quite a bit of Python/PyQt5 software that was troublesome to get working on macOS with Apple Silicone, but it is possible.

Hi again!
I have now replicated the python=3.7 problem, python=3.8 seems to work, could you try that?
(I cannot check that yet, because I am having problems installing ffmpeg right now - as soon as I solved that, I will tell you. Therefore, if you prefer to wait until I have done that, no problem)
(Python=3.10 will need a few adjustments, since scipy has changed quite a bit).
Thanks,
Giovanni

Prof. Dr. Giovanni Galizia
Direktor Zukunftskolleg
Lehrstuhl Neurobiologie
Permanent Fellow Wissenschaftskolleg zu Berlin
@.***
http://neuro.uni.kn

On 16. Nov 2022, at 19:02, Adam Tyson @.***> wrote:
Hi 👋,
I'm reviewing the PyView JOSS paper https://github.com/openjournals/joss-reviews/issues/4936.
I'm having trouble installing PyView on my machine which I assume is partially due to Apple Silicon M1 chip. It fails very early (e.g. Python 3.7 is not available for M1 on conda forge).
Could you add instructions for installing the package on newer macs, or better yet, an environment file?
Thanks!
—
Reply to this email directly, view it on GitHub https://github.com/galizia-lab/pyview/issues/18, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACRMY4VRQXBS3R2VULRXNGDWIUOU7ANCNFSM6AAAAAASCQK3VQ.
You are receiving this because you are subscribed to this thread.

Hi there!
Thanks for your patience!
We have now upgraded the code to python 3.10. You will find a new conda_env_development_py310.yml file to create a conda environment. On my silicon M2 it works fine!
Please let me know if you need any more information.
Best,
Giovanni

Prof. Dr. Giovanni Galizia
Direktor Zukunftskolleg
Lehrstuhl Neurobiologie
Permanent Fellow Wissenschaftskolleg zu Berlin
@.***
http://neuro.uni.kn

On 16. Nov 2022, at 19:02, Adam Tyson @.***> wrote:
Hi 👋,
I'm reviewing the PyView JOSS paper https://github.com/openjournals/joss-reviews/issues/4936.
I'm having trouble installing PyView on my machine which I assume is partially due to Apple Silicon M1 chip. It fails very early (e.g. Python 3.7 is not available for M1 on conda forge).
Could you add instructions for installing the package on newer macs, or better yet, an environment file?
Thanks!
—
Reply to this email directly, view it on GitHub https://github.com/galizia-lab/pyview/issues/18, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACRMY4VRQXBS3R2VULRXNGDWIUOU7ANCNFSM6AAAAAASCQK3VQ.
You are receiving this because you are subscribed to this thread.

Hi @adamltyson :wave:
Thanks for raising the issue. I have made a new release (v1.2) incorporating all the changes mentioned above by @galizia . Please try installing this version. We are available if you have questions or issues.
Thanks!


Const class cannot remove fields in hot reload

Currently if you remove a field from a const class and try to hot reload you get:
Hot reload received invalid response: {type: ReloadReport, success: false, notices: [{type: ReasonForCancelling, class: {type: @Class, fixedId: true, id:
classes/3988, name: ItemGeometry}, message: Const class cannot remove fields: Library:'package:plexiglass/rendering/items/common.dart' Class: ItemGeometry}]}

The ugliness of the message is https://github.com/flutter/flutter/issues/64027, but more importantly, we shouldn't fail for removing a const class field. If we must, we should just rename the field something that cannot be expressed in Dart, and pretend...

@rmacnak-google @mkustermann

https://github.com/dart-lang/sdk/issues/40442


Fix reactions popup.

Automated message from Dropbox CLA bot
@showell, it looks like you've already signed the Dropbox CLA. Thanks!

Merged, after tweaking the list based on what I see people using most often across the various Zulip realms I'm in.  Thanks @showell!


fix param aliases

add precise_float_parser to Dataset params at language wrappers level and raise error in case of new value in config for constructed Dataset
move linear_tree param to Dataset section (open to discussion about another way how indicate the fact that linear_tree config value is used at Dataset creation step)

@btrotta What do you think about moving linear_tree param into Dataset Parameters section?

@btrotta What do you think about moving linear_tree param into Dataset Parameters section?

@StrikerRUS this seems fine to me, since choosing linear_tree changes the how the dataset is constructed and stored.


[Fallback Support]Notation uses OCI image manifest to store the signature in the repository.

What is the areas you would like to add the new feature to?
Notation CLI
Is your feature request related to a problem?
OCI artifact manifest was introduced in OCI image spec 1.1.0. It takes time for registries to be compliant to the 1.1.0 spec. There could be cases that registries decide not uplifted to 1.1.0 spec. For these registries not compliant to 1.1.0 spec, it will fail if notation CLI uses OCI artifact manifest to push the signatures.
What solution do you propose?
This feature is to request notation to support using OCI image manifest to store the signature in the registry that doesn't support OCI artifact manifest.

Update signature spec to support additional format OCI image manifest
Define and align the process that under which condition notation uses OCI image manifest
Define the align the content for config property required by OCI image manifest

What alternatives have you considered?
No other alternative.
Notation can claim that only OCI artifact manifest is supported to store the signatures, but this will cause notation not broadly adopted.
Any additional context?
No response

Illustration:
@toddysm @priteshbandi Based on our last discussion, does the following picture help to explain the situation?

This fallback is not defined in OCI spec. The only fallback defined in OCI spec is based on referrers API. Do we want to devise fallback based on failure to push artifact manifest? If yes, why?

You are right. This fallback is not defined in OCI spec. OCI artifact manifest is introduced in OCI image spec v1.1.  Not all the registries are OCI image spec v1.1 compatible. If notation pushes signatures using OCI artifact manifest, the push fails. So the question is really about "Does Notation support sign container images/artifacts in registries not OCI image v1.1 compatible?".

OCI Artifact manifest fallback is defined here: Backwards Compatibility
However, it's not clearly defined the referrers API is required to be implemented when a registry supports OCI Artifact Manifest
ORAS Artifact manifest described it as coupled, where the artifact manifest and referrers API were both implemented: API Discovery
However, @shizhMSFT pointed out that the /referrers API won't yet exist if the user is pushing to a new repository.
Question: what if we checked the root of the registry for the existence of the /referrers API? For registries like ACR and ECR that have a unique domain names for each registry, it would be the root of the domain. myregistry.azurecr.io/v2/referrers/<digest> while ghcr and docker hub would use the org namespace: docker.io/v2/myregistry/referrers/<digest>

Add the link for related discussion at OCI: https://github.com/opencontainers/distribution-spec/issues/365

Notation fallback mechanism SFD on HackMD
Note that this is not going to work on ECR until it allows unknown fields (subject specifically for fallback) to pass through. In image-spec/considerations, it's suggested that:

Implementations that are reading/processing manifests or image indexes MUST NOT generate an error if they encounter an unknown property. Instead they MUST ignore unknown properties.

But I'm not sure if (being under considerations) this is part of the spec?
In any case, I'm looking at what changes need to be made in ECR in advance of 1/30/2023 that would allow this field, and thus make possible for notary to utilize the fallback mechanism if the move to oci-v1.1 is delayed.

Notation fallback mechanism SFD on HackMD

I've briefly reviewed the HackMD doc. The described behavior is similar to ORAS except the tag scheme (the fallback method of the Referrers API).
Major differences: oras-go always attempts to put the new referrers index first and then delete the old one while the HackMD doc suggests deleting the old index first and then put the new one. The oras-go implementation is more fault tolerant as it won't cause data / metadata loss if PUT the new index fails due to network issues or client / server errors. If we delete the old index first and then put the new one, we may lose all metadata if the final PUT fails.

Notation fallback mechanism SFD on HackMD

@nima Question on the flow of "Attempt artifact manifest upload via oci-v1.1 spec", why do we need to check and upload oras config blob?

Hi Yi, sorry for the delay, in response to your question in #444:

@nima Question on the flow of “Attempt artifact manifest upload via oci-v1.1 spec”, why do we need to check and upload oras config blob?

My understanding is that when we revert to a fallback (to use an image manifest, instead of an artifact manifest), then we need to construct an image manifest in its stead. And since an image spec mandates the manifest contain a config entry, we need to supply it one — even though we have no intention of ever using it.  At that point, we need for it to reference some arbitrary config blob, and that config blob appears to be {} whose digest is sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a.
It's quite possible that I've missed something—in either your question or in my understanding in general—because I think you know all that I've explained better than I do.  Let me know what I may have missed here, and I'll update the SFD.

Hi @shizhMSFT, thank you for the review; that is indeed very important, I will update the SFD to reflect this for completeness.

Hi @yizha1, sorry for the delay, in response to your question in #444:

@nima Question on the flow of “Attempt artifact manifest upload via oci-v1.1 spec”, why do we need to check and upload oras config blob?

My understanding is that when we revert to a fallback (to use an image manifest, instead of an artifact manifest), then we need to construct an image manifest in its stead. And since an image spec mandates the manifest contain a config entry, we need to supply it one — even though we have no intention of ever using it. At that point, we need for it to reference some arbitrary config blob, and that config blob appears to be {} whose digest is sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a.
It's quite possible that I've missed something—in either your question or in my understanding in general—because I think you know all that I've explained better than I do. Let me know what I may have missed here, and I'll update the SFD.

Thanks Nima. Your understanding is correct. The spec PR also described this https://github.com/notaryproject/notaryproject/pull/217.  My question is about the wording oras config blob. The configure descriptor is defined in OCI image spec. It is more accurate to call it OCI image configure blob, oras just provides an implementation for it.

Oh! I'm so sorry I misunderstood that—I will update that immediately, and thank you for pointing it out.

Closed as released in rc.2