Simplifying Service Invocation API surface

Background
We're making changes broadly across Dapr to rely on HTTP for service invocation: https://github.com/dapr/dapr/issues/2342
Currently the SDK relies on gRPC for service invocation, which means that in the common path HTTP responses have to be translated to gRPC responses. This translation layer has some technical challenges since the error handling model is gRPC is very simple compared to HTTP. It also means at the .NET SDK has to abstract over the different behaviors of protocols - treating semantics like HTTP methods as an optional feature, or causing the user to understand two different error handling models.
The changes in short:

Invoking an HTTP service: Dapr will pass through your request as-is and perform no translation other than rewriting the URL path
Invoking a gRPC service: Dapr will perform a set of translations similar to gRPC gateway. An incoming HTTP request will be mapped to a gRPC service call. The gRPC error code (if any) will be translated to an HTTP status code, and message body.

Since we're now committing to HTTP as the protocol for service invocation (for now), we've got a single error handling model to work with, and it makes more sense to expose .NET's HTTP types in our API.
Goals
This proposal intends to check a few boxes:

Keep the spirit of the existing invoke APIs: terse and simple, optimized for RPC scenarios
Provide something in the box that uses the vocabulary of service invocation
Reuse existing types where possible to support knowledge transfer

We're also merging support for using HttpClient in all of it's glory for Dapr service invocation - https://github.com/dapr/dotnet-sdk/pull/544. We don't need so support every possible scenario through these APIs - I expect HttpClient to be a good choice for many users.
We also have some non-goals:

Build a general purpose HttpClient wrapper library - this is for Dapr service invocation only
Abstract over HTTP as a protocol in the SDK

Proposal
We start by exposing a new set of "building-block" APIs:
public class DaprClient
{
        public abstract HttpRequestMessage CreateInvokeMethodRequest(string appId, string methodName);

        public abstract HttpRequestMessage CreateInvokeMethodRequest(HttpMethod httpMethod, string appId, string methodName);

        public abstract HttpRequestMessage CreateInvokeMethodRequest<TRequest>(string appId, string methodName, TRequest data);

        public abstract HttpRequestMessage CreateInvokeMethodRequest<TRequest>(HttpMethod httpMethod, string appId, string methodName, TRequest data);

        public abstract Task<HttpResponseMessage> InvokeMethodWithResponseAsync(HttpRequestMessage request, CancellationToken cancellationToken = default);

        public abstract Task InvokeMethodAsync(HttpRequestMessage request, CancellationToken cancellationToken = default);

        public abstract Task<TResponse> InvokeMethodAsync<TResponse>(HttpRequestMessage request, CancellationToken cancellationToken = default);
}

CreateInvokeMethodRequest: Creates a new HttpResponseMessage with a URL that follows the format of a Dapr service invocation request. request.Content will be set to a JsonContent if you call the generic variant.
InvokeMethodWithResponseAsync: Does the HTTP, and either returns a response message without checking the status code.
InvokeMethodAsync: Does the HTTP and returns void deserialized response depending on the method. These check the status code and throw for non-200, as is convention for the similar methods on HttpClient.
These APIs make it really easy to work with HttpRequestMessage/HttpResponseMessage for any sort of customization that needs to be done, without us expanding the Dapr API set. You'll likely also want to reach for these methods for cases where you do error handling without exceptions.
Examples:

Manipulating headers
Using protobof (set request.Content)
Send a request and write your own code for handling deserialization based on status code

:bulb: Note: on parameter ordering - I made the HttpMethod come first, and be optional for RPC-style cases. This largely follows existing APIs for HTTP (like HttpRequestMessage). If you think of the app id and "method" as comprising the URI, it's the same design.

Next we'll want to expose the JSON serializer options
public class DaprClient
{
        public abstract JsonSerializerOptions JsonSerializerOptions { get; }
}

The user provided these, and so we want to make them easy to access. This is useful because we perform serialization on the user's behalf in some cases, but not every conceivable case. In some error handling cases the user might need to deserialize manually using ReadFromJsonAsync - so we should make the options instance public.

Next we tweak the existing family of InvokeMethodAsync overloads to follow those conventions. HttpOptions goes away, as do InvocationRequest and InvocationResponse. We're going to use the built-in types.
public class DaprClient
{
     public Task<TResponse> InvokeMethodAsync<TRequest, TResponse>(
            string appId,
            string methodName,
            TRequest data,
            CancellationToken cancellationToken = default);

     public Task<TResponse> InvokeMethodAsync<TRequest, TResponse>(
            HttpMethod httpMethod,
            string appId,
            string methodName,
            TRequest data,
            CancellationToken cancellationToken = default);
}

These methods become non-abstract convenience methods that chain together calls to CreateInvokeMethodRequest and InvokeMethodAsync(HttpRequestMesage request, ...).
We've simplified these a bit, and they no longer directly support raw bytes or header manipulation - but that's find because users can use CreateInvokeMethodRequest directly.
Open Question: Do we want a hybrid one-liner that returns an HttpResponseMessage? (probably not)

@amolenk - I think you were interested in this

@amolenk - I think you were interested in this

@rynowak thanks
It’s not entirely clear to me how the new HTTP invocations work. Am I correct that HTTP to HTTP service invocations still use gRPC internally in the runtime?:
Caller (SDK) HTTP —> Dapr Sidecar Internal gRPC —> Dapr Sidecar HTTP —> Callee

I can also use the new HttpClient support to call a gRPC service, right?
Caller (HttpClient) HTTP —> Dapr Sidecar Internal gRPC —> Dapr Sidecar gRPC —> Callee

There’s a small typo in the proposal. For the **CreateInvokeMethodRequest you explain that it creates a new HttpResponseMessage. That should be a new HttpRequestMessage.
I assume the non-abstract convenience methods throw for non-200 codes?
I don’t think we need a convenience method that returns an HttpResponseMessage. I feel like that will muddy the waters somewhat. I like how the current proposal makes a distinction between just make a simple call and do any advanced stuff yourself.
Overall, I think this is a great improvement that will give a lot of flexibility without having to introduce new concepts to the user.

@rynowak thanks
It’s not entirely clear to me how the new HTTP invocations work. Am I correct that HTTP to HTTP service invocations still use gRPC internally in the runtime?:
Caller (SDK) HTTP —> Dapr Sidecar Internal gRPC —> Dapr Sidecar HTTP —> Callee

I can also use the new HttpClient support to call a gRPC service, right?
Caller (HttpClient) HTTP —> Dapr Sidecar Internal gRPC —> Dapr Sidecar gRPC —> Callee

There’s a small typo in the proposal. For the **CreateInvokeMethodRequest you explain that it creates a new HttpResponseMessage. That should be a new HttpRequestMessage.
I assume the non-abstract convenience methods throw for non-200 codes?
I don’t think we need a convenience method that returns an HttpResponseMessage. I feel like that will muddy the waters somewhat. I like how the current proposal makes a distinction between just make a simple call and do any advanced stuff yourself.
Overall, I think this is a great improvement that will give a lot of flexibility without having to introduce new concepts to the user.

@rynowak Thanks for your work on this.
I am using gRPC for all my collaborating services in a greenfield development.  I chose gRPC since 1) It has faster communications than http and 2) since it supports Protobuf.
It looks as if your changes only impact HTTP -- Is that so?  In other words, gRPC communications for Service Invocation will still be available so as to realize the 2 above listed benefits?  Thanks.

@rynowak Thanks for your work on this.
I am using gRPC for all my collaborating services in a greenfield development.  I chose gRPC since 1) It has faster communications than http and 2) since it supports Protobuf.
It looks as if your changes only impact HTTP -- Is that so?  In other words, gRPC communications for Service Invocation will still be available so as to realize the 2 above listed benefits?  Thanks.

I chose gRPC since 1) It has faster communications than http and 2) since it supports Protobuf.

How are you using gRPC? - through the InvokeMethodAsync APIs on DaprClient or are you using the gRPC client directly?
There are two changes that you should be aware of:
We're changing InvokeMethodAsync and similar functionality in other SDKs to use HTTP in its implementation. You can read more about the motivations for this change here. The main thing is that its not straightforward to wrap HTTP invocations in gRPC due to differences in the error handling model - the reverse works well. This is the same reason why it's pretty obtuse to write an abstraction in code that handles both protocols.
We're changing the InvokeMethodAsync family of methods to no longer perform Protobuf serialization. This is not out of a desire to remove Protobuf, but out of a desire to have absolute clarity about what serialization Dapr performs on your behalf. Having method calls that sometimes result in protobuf and sometimes result in JSON is suspect. You can read more about that change here. I'm happy to add InvokeMethodProtobuf<> versions to this proposal so that functionality is still easy to access.

So where does this leave you:
I suppose you have the option to use the generated grpc client if you want (namespace == Dapr.Client.Autogen.Grpc.v1). This gets you as close to the bare metal as you can go, but I can't say its especially nice to program against.
You could also use protobuf with DaprClient.InvokeMethodProtobufAsync to talk to your gRPC services - this will use an HTTP error handling model - ie, rather than gRPC status codes you'll get HTTP status codes.
You could adopt HTTP as a server-side programming model with Protobuf as the serialization format.
The north star here is still to enable the actual gRPC programming model with Dapr (generated clients and servers), but that won't be happening for v1.

I'm not sure that I believe the claims about performance differences between HTTP+JSON and gRPC in a vacuum. Protobuf is definitely a more compact (on the wire) format which is the source of many of these claims. However implementing Protobuf in a GC'ed language (esp. .NET) comes with some perf drawbacks that are unavoidable due to the nature of the format.
In general if there is a benefit for your use case with Dapr, it's actually related to the serialization format, and not the underlying protocol.  Many of the other benefits of gRPC (streaming) aren't supported yet with Dapr.

I chose gRPC since 1) It has faster communications than http and 2) since it supports Protobuf.

How are you using gRPC? - through the InvokeMethodAsync APIs on DaprClient or are you using the gRPC client directly?
There are two changes that you should be aware of:
We're changing InvokeMethodAsync and similar functionality in other SDKs to use HTTP in its implementation. You can read more about the motivations for this change here. The main thing is that its not straightforward to wrap HTTP invocations in gRPC due to differences in the error handling model - the reverse works well. This is the same reason why it's pretty obtuse to write an abstraction in code that handles both protocols.
We're changing the InvokeMethodAsync family of methods to no longer perform Protobuf serialization. This is not out of a desire to remove Protobuf, but out of a desire to have absolute clarity about what serialization Dapr performs on your behalf. Having method calls that sometimes result in protobuf and sometimes result in JSON is suspect. You can read more about that change here. I'm happy to add InvokeMethodProtobuf<> versions to this proposal so that functionality is still easy to access.

So where does this leave you:
I suppose you have the option to use the generated grpc client if you want (namespace == Dapr.Client.Autogen.Grpc.v1). This gets you as close to the bare metal as you can go, but I can't say its especially nice to program against.
You could also use protobuf with DaprClient.InvokeMethodProtobufAsync to talk to your gRPC services - this will use an HTTP error handling model - ie, rather than gRPC status codes you'll get HTTP status codes.
You could adopt HTTP as a server-side programming model with Protobuf as the serialization format.
The north star here is still to enable the actual gRPC programming model with Dapr (generated clients and servers), but that won't be happening for v1.

I'm not sure that I believe the claims about performance differences between HTTP+JSON and gRPC in a vacuum. Protobuf is definitely a more compact (on the wire) format which is the source of many of these claims. However implementing Protobuf in a GC'ed language (esp. .NET) comes with some perf drawbacks that are unavoidable due to the nature of the format.
In general if there is a benefit for your use case with Dapr, it's actually related to the serialization format, and not the underlying protocol.  Many of the other benefits of gRPC (streaming) aren't supported yet with Dapr.

Hi Ryan,
Thanks for the detailed info. Rather than getting in the details of the
links you kindly provided, I'll instead provide you with some background
and a brief sketch of my high level requirements and why I am using Dapr in
the first place.  Then perhaps you can tell me if your changes will throw a
monkey wrench into what I am doing with Service Invocation.
I come from designing and writing services in WCF between 2011 and 2016,
using an RPC approach along with a lot of Messaging (queues) as well.  Both
RPC and Messaging used chunky DTOs (often containing an object hierarchy,
rather than just a single, flat class).  I have found using a straight RPC
approach (without having to worry about the HTTP verbs and the various http
headers) to be very highly productive for programming teams.  Specifically,
an RPC approach allows one to express the behavior of each service
operation clearly and concisely as some desired domain oriented behavior,
plus to send chunky Data Transfer Objects (again directly aimed at domain
oriented things) and to receive responses as chunky DTOs as well.
Note, I am being driven by business productivity goals, and not technology.
In my several decades of software development, the above is the most highly
productive (doing much more with less time and effort and money) way of
implementing services that I have seen. WCF excelled at it, but is no
longer an option.  Azure Service Fabric excels at it also, but is very
limited on the hosts it can run on. And recently I have been able to use
this highly productive RPC plus Messaging style with Azure Functions and
Durable Functions, but they too have fairly strict run-time-environment
limitations as well.
It is my hope that ASP.NET gRPC coupled with Dapr will support the RPC
style outlined above, plus messaging as well, AND allow me to develop
systems of collaborating services that can run literally ANYWHERE -- On
edge devices like IoT Edge or Azure Stack Edge, on VMs, on-prem, in the
cloud, within container orchestrators like K8s, etc.  Use the same code,
the same DTOs, and change some config files, builds, deployments, etc and
it runs!  That is what I am after.  All these possible hosts should be able
to use the same RPC plus Messaging programming model for the sake of
increasing productivity and thus decreasing the cost to the owner of the
software.
Again, in a sentence -- My goal is to be able to use ASP.NET gRPC and Dapr
(for messaging, service invocation, bindings, plus more) to be able to
develop RPC and Messaging based services in a highly cost effective way
that can run almost ANYWHERE without having to do code changes to get
them to run in other places.  Why? This maximizes the business value that I
can produce.  Plus having a staff that does not have to have a wide breadth
of technical skills, but rather is very highly focused on deep expertise in
a few key programming technologies.  Again, this maximizes the business
value I create for customers.
Increasing productivity and maximizing the business value for customers are
the main drivers for me using Dapr.  My intention is to use ASP.NET gRPC or
Dapr Messaging (pub/sub or queue bindings) to communicate with the single
outside-facing-service in a small collection of collaborating services
(called a subsystem).  Then my plan is to use RPC style Service Invocation
to communicate between the "outside facing service" and some or even all of
the several other services within a subsystem.
If I cannot have a clean RPC style Service Invocation for this purpose it
throws a monkey wrench into the works.  I definitely do NOT want to have to
have developers needing to be competent in both RPC and HTTP programming
(get, post, etc, http headers...).   I found the Service Invocation in RC 2
to be acceptable and it does a good job of preventing devs from having to
deal with HTTP verbs and headers in the code they write.
If I can have RPC style programming for Service Invocation, both with the
request and the response, but have to live without protobuf and use chunky
DTOs implemented in JSON for a year or two, then I can live with that.
Although I'd much rather have protobuf since it's binary format conserves
network bandwidth (which is much more difficult to scale out than compute
is).  And on the smaller Edge devices network bandwidth may be even way
more scarce than compute.
So now you know what I want and need, and I hope that you can accomodate my
needs (I'd argue that my needs are also shared by many organizations in the
.NET world right now, or soon will be when we start developing more, and
more, and more software in our quest to counteract climate change).  I also
understand the reasons why you are making the changes you are making.
Please let me know if your changes will upset my planned use of Service
Invocation.
Thanks again for your work,
George
On Wed, Jan 20, 2021 at 4:26 PM Ryan Nowak<EMAIL_ADDRESS>wrote:

I chose gRPC since 1) It has faster communications than http and 2) since
it supports Protobuf.
How are you using gRPC? - through the InvokeMethodAsync APIs on DaprClient
or are you using the gRPC client directly?
There are two changes that you should be aware of:
We're changing InvokeMethodAsync and similar functionality in other SDKs
to use HTTP in its implementation. You can read more about the motivations
for this change here https://github.com/dapr/dapr/issues/2342. The main
thing is that its not straightforward to wrap HTTP invocations in gRPC due
to differences in the error handling model - the reverse works well. This
is the same reason why it's pretty obtuse to write an abstraction in code
that handles both protocols.
We're changing the InvokeMethodAsync family of methods to no longer
perform Protobuf serialization. This is not out of a desire to remove
Protobuf, but out of a desire to have absolute clarity about what
serialization Dapr performs on your behalf. Having method calls that
sometimes result in protobuf and sometimes result in JSON is suspect. You
can read more about that change here
https://github.com/dapr/dotnet-sdk/issues/442. I'm happy to add
InvokeMethodProtobuf<> versions to this proposal so that functionality is
still easy to access.
So where does this leave you:
I suppose you have the option to use the generated grpc client if you want
(namespace == Dapr.Client.Autogen.Grpc.v1). This gets you as close to the
bare metal as you can go, but I can't say its especially nice to program
against.
You could also use protobuf with DaprClient.InvokeMethodProtobufAsync to
talk to your gRPC services - this will use an HTTP error handling model -
ie, rather than gRPC status codes you'll get HTTP status codes.
You could adopt HTTP as a server-side programming model with Protobuf as
the serialization format.
The north star here is still to enable the actual gRPC programming model
with Dapr (generated clients and servers), but that won't be happening for
v1.
I'm not sure that I believe the claims about performance differences
between HTTP+JSON and gRPC in a vacuum. Protobuf is definitely a more
compact (on the wire) format which is the source of many of these claims.
However implementing Protobuf in a GC'ed language (esp. .NET) comes with
some perf drawbacks that are unavoidable due to the nature of the format.
In general if there is a benefit for your use case with Dapr, it's
actually related to the serialization format, and not the underlying
protocol. Many of the other benefits of gRPC (streaming) aren't supported
yet with Dapr.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dapr/dotnet-sdk/issues/549#issuecomment-763958626,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRXHHOINK664UNGXUJ4LJ3S25C7RANCNFSM4WGP5SVA
.

Hi Ryan,
Thanks for the detailed info. Rather than getting in the details of the
links you kindly provided, I'll instead provide you with some background
and a brief sketch of my high level requirements and why I am using Dapr in
the first place.  Then perhaps you can tell me if your changes will throw a
monkey wrench into what I am doing with Service Invocation.
I come from designing and writing services in WCF between 2011 and 2016,
using an RPC approach along with a lot of Messaging (queues) as well.  Both
RPC and Messaging used chunky DTOs (often containing an object hierarchy,
rather than just a single, flat class).  I have found using a straight RPC
approach (without having to worry about the HTTP verbs and the various http
headers) to be very highly productive for programming teams.  Specifically,
an RPC approach allows one to express the behavior of each service
operation clearly and concisely as some desired domain oriented behavior,
plus to send chunky Data Transfer Objects (again directly aimed at domain
oriented things) and to receive responses as chunky DTOs as well.
Note, I am being driven by business productivity goals, and not technology.
In my several decades of software development, the above is the most highly
productive (doing much more with less time and effort and money) way of
implementing services that I have seen. WCF excelled at it, but is no
longer an option.  Azure Service Fabric excels at it also, but is very
limited on the hosts it can run on. And recently I have been able to use
this highly productive RPC plus Messaging style with Azure Functions and
Durable Functions, but they too have fairly strict run-time-environment
limitations as well.
It is my hope that ASP.NET gRPC coupled with Dapr will support the RPC
style outlined above, plus messaging as well, AND allow me to develop
systems of collaborating services that can run literally ANYWHERE -- On
edge devices like IoT Edge or Azure Stack Edge, on VMs, on-prem, in the
cloud, within container orchestrators like K8s, etc.  Use the same code,
the same DTOs, and change some config files, builds, deployments, etc and
it runs!  That is what I am after.  All these possible hosts should be able
to use the same RPC plus Messaging programming model for the sake of
increasing productivity and thus decreasing the cost to the owner of the
software.
Again, in a sentence -- My goal is to be able to use ASP.NET gRPC and Dapr
(for messaging, service invocation, bindings, plus more) to be able to
develop RPC and Messaging based services in a highly cost effective way
that can run almost ANYWHERE without having to do code changes to get
them to run in other places.  Why? This maximizes the business value that I
can produce.  Plus having a staff that does not have to have a wide breadth
of technical skills, but rather is very highly focused on deep expertise in
a few key programming technologies.  Again, this maximizes the business
value I create for customers.
Increasing productivity and maximizing the business value for customers are
the main drivers for me using Dapr.  My intention is to use ASP.NET gRPC or
Dapr Messaging (pub/sub or queue bindings) to communicate with the single
outside-facing-service in a small collection of collaborating services
(called a subsystem).  Then my plan is to use RPC style Service Invocation
to communicate between the "outside facing service" and some or even all of
the several other services within a subsystem.
If I cannot have a clean RPC style Service Invocation for this purpose it
throws a monkey wrench into the works.  I definitely do NOT want to have to
have developers needing to be competent in both RPC and HTTP programming
(get, post, etc, http headers...).   I found the Service Invocation in RC 2
to be acceptable and it does a good job of preventing devs from having to
deal with HTTP verbs and headers in the code they write.
If I can have RPC style programming for Service Invocation, both with the
request and the response, but have to live without protobuf and use chunky
DTOs implemented in JSON for a year or two, then I can live with that.
Although I'd much rather have protobuf since it's binary format conserves
network bandwidth (which is much more difficult to scale out than compute
is).  And on the smaller Edge devices network bandwidth may be even way
more scarce than compute.
So now you know what I want and need, and I hope that you can accomodate my
needs (I'd argue that my needs are also shared by many organizations in the
.NET world right now, or soon will be when we start developing more, and
more, and more software in our quest to counteract climate change).  I also
understand the reasons why you are making the changes you are making.
Please let me know if your changes will upset my planned use of Service
Invocation.
Thanks again for your work,
George
On Wed, Jan 20, 2021 at 4:26 PM Ryan Nowak<EMAIL_ADDRESS>wrote:

I chose gRPC since 1) It has faster communications than http and 2) since
it supports Protobuf.
How are you using gRPC? - through the InvokeMethodAsync APIs on DaprClient
or are you using the gRPC client directly?
There are two changes that you should be aware of:
We're changing InvokeMethodAsync and similar functionality in other SDKs
to use HTTP in its implementation. You can read more about the motivations
for this change here https://github.com/dapr/dapr/issues/2342. The main
thing is that its not straightforward to wrap HTTP invocations in gRPC due
to differences in the error handling model - the reverse works well. This
is the same reason why it's pretty obtuse to write an abstraction in code
that handles both protocols.
We're changing the InvokeMethodAsync family of methods to no longer
perform Protobuf serialization. This is not out of a desire to remove
Protobuf, but out of a desire to have absolute clarity about what
serialization Dapr performs on your behalf. Having method calls that
sometimes result in protobuf and sometimes result in JSON is suspect. You
can read more about that change here
https://github.com/dapr/dotnet-sdk/issues/442. I'm happy to add
InvokeMethodProtobuf<> versions to this proposal so that functionality is
still easy to access.
So where does this leave you:
I suppose you have the option to use the generated grpc client if you want
(namespace == Dapr.Client.Autogen.Grpc.v1). This gets you as close to the
bare metal as you can go, but I can't say its especially nice to program
against.
You could also use protobuf with DaprClient.InvokeMethodProtobufAsync to
talk to your gRPC services - this will use an HTTP error handling model -
ie, rather than gRPC status codes you'll get HTTP status codes.
You could adopt HTTP as a server-side programming model with Protobuf as
the serialization format.
The north star here is still to enable the actual gRPC programming model
with Dapr (generated clients and servers), but that won't be happening for
v1.
I'm not sure that I believe the claims about performance differences
between HTTP+JSON and gRPC in a vacuum. Protobuf is definitely a more
compact (on the wire) format which is the source of many of these claims.
However implementing Protobuf in a GC'ed language (esp. .NET) comes with
some perf drawbacks that are unavoidable due to the nature of the format.
In general if there is a benefit for your use case with Dapr, it's
actually related to the serialization format, and not the underlying
protocol. Many of the other benefits of gRPC (streaming) aren't supported
yet with Dapr.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dapr/dotnet-sdk/issues/549#issuecomment-763958626,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRXHHOINK664UNGXUJ4LJ3S25C7RANCNFSM4WGP5SVA
.

Thanks for the additional thoughts - I think the best thing to do here is to augment the proposal above with a family of InvokeMethodGrpcAsync methods that use Protobuf and gRPC's semantics. That will give you the same experience you have today, the only difference will be that its a different method name.

Thanks for the additional thoughts - I think the best thing to do here is to augment the proposal above with a family of InvokeMethodGrpcAsync methods that use Protobuf and gRPC's semantics. That will give you the same experience you have today, the only difference will be that its a different method name.

Thanks for the quick response.  That sounds like a good plan.  It keeps
Protobuf and gRPC "in the game"  and perhaps even well positioned for the
long run when ASP.NET implementation of gRPC and Protobuf is more mature.
Plus also allows people interested in Dapr to "see what the future may look
like"!
Building new software on top of new software is always highly changeable so
I appreciate you adding the InvokeMethodGrpcAsync family of methods!
Thanks.
On Thu, Jan 21, 2021 at 1:09 PM Ryan Nowak<EMAIL_ADDRESS>wrote:

Thanks for the additional thoughts - I think the best thing to do here is
to augment the proposal above with a family of InvokeMethodGrpcAsync
methods that use Protobuf and gRPC's semantics. That will give you the same
experience you have today, the only difference will be that its a different
method name.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dapr/dotnet-sdk/issues/549#issuecomment-764837664,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRXHHOIIGC2V2UPC7DK7YDS3BUV3ANCNFSM4WGP5SVA
.

Thanks for the quick response.  That sounds like a good plan.  It keeps
Protobuf and gRPC "in the game"  and perhaps even well positioned for the
long run when ASP.NET implementation of gRPC and Protobuf is more mature.
Plus also allows people interested in Dapr to "see what the future may look
like"!
Building new software on top of new software is always highly changeable so
I appreciate you adding the InvokeMethodGrpcAsync family of methods!
Thanks.
On Thu, Jan 21, 2021 at 1:09 PM Ryan Nowak<EMAIL_ADDRESS>wrote:

Thanks for the additional thoughts - I think the best thing to do here is
to augment the proposal above with a family of InvokeMethodGrpcAsync
methods that use Protobuf and gRPC's semantics. That will give you the same
experience you have today, the only difference will be that its a different
method name.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dapr/dotnet-sdk/issues/549#issuecomment-764837664,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRXHHOIIGC2V2UPC7DK7YDS3BUV3ANCNFSM4WGP5SVA
.


cannot embed wetty in iframe.

This issue is still not fixed for me. Version 2.3.0
wetty.service
[Unit]
Description=WeTTY
After=network-online.target

[Service]
Type=simple
ExecStart=/bin/bash -c "wetty --host <IP_ADDRESS> -p 3000 --title 'Linux'  --allow-iframe"
Restart=always
RestartSec=2
TimeoutStopSec=5
SyslogIdentifier=wetty

[Install]
WantedBy=multi-user.target

curl -I output:
HTTP/1.1 200 OK
Server: nginx/1.14.1
Date: Thu, 10 Feb 2022 07:36:40 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 1123
Connection: keep-alive
Content-Security-Policy: default-src 'self';script-src 'self' 'unsafe-inline' 'unsafe-eval';style-src 'self' 'unsafe-inline';font-src 'self' data:;connect-src 'self' ws://live.ashutoshpatole.me
X-DNS-Prefetch-Control: off
Expect-CT: max-age=0
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Download-Options: noopen
X-Content-Type-Options: nosniff
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: no-referrer-when-downgrade
X-XSS-Protection: 0
ETag: W/"463-sU/26veHuUBEvMiP/7q1LeC8l5E"
Vary: Accept-Encoding

Adding x-frame-option to nginx results in duplicates x-frame-option headers.
# For more information on configuration, see:
#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    #  include http_headers.conf;
    access_log  /var/log/nginx/access.log  main;
    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 2048;
    # add_header X-Frame-Options "ALLOW-FROM https://server.com";
    include             /etc/nginx/mime.types;
nginx.conf# For more information on configuration, see:
#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log  /var/log/nginx/access.log  main;
    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 2048;
    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;

    server {
        server_name  live.ashutoshpatole.me;
        root         /usr/share/nginx/html;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        location / {
        }

        # Necessary for Let's Encrypt Domain Name ownership validation
        location ~ /.well-known {
          allow all;
        }

        location /wetty {
            proxy_pass http://<IP_ADDRESS>:3000/wetty;
            #
            proxy_pass_request_headers on;
            #
            proxy_pass_request_headers on;
            #
            proxy_set_header Host $host;
            #
            proxy_http_version 1.1;
            #
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-Protocol $scheme;
            proxy_set_header X-Forwarded-Host $http_host;
            proxy_set_header X-NginX-Proxy true;
            #
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $http_connection;
            proxy_read_timeout 43200000;
            proxy_set_header X-Forwarded-Ssl on;
            #
            proxy_redirect off;
            proxy_buffering off;
           # add_header X-Frame-Options "ALLOW-FROM https://myserver.com";
        }
        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
   location = /50x.html {
        }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

}

Am I missing something else? @butlerx
Originally posted by @AshutoshPatole in https://github.com/butlerx/wetty/issues/368#issuecomment-1034585656

Yarn installation. The --allow-iframe flag is not working.
Trying to get Wetty to work inside of Organizr.
Tried resolutions described in https://github.com/butlerx/wetty/issues/380 and that did not work.


Implement Transfer Activity

Transfer Activity is an abstraction layer designed to help users move data from point A to point B. It is designed to simplify the user experience.

In light, of large branch divergence this branch is going to be made stale and will be kept for reference. This branch needs to be split into 3 to 4 different components.

URI separators

Any plugin that has a plugin specific uri separator needs to be implemented according to documentation.

Activity Converter Abstraction layer

All activities should be converted to a plugin activity internally before being passed to the actual plugins, this avoids the need for each plugin to know about every kind of activity, they will only need to understand the plugin activity.

A plugin and transfer activity needs to be added that is user facing.

All of the components need to be shown to work together,

This requires some detailed plumbing i.e. ensuring UUIDs are being appropriately passed around.


fix(types): Update polkadot-js deps to get the latest types

I also fixed up the test with crowdloan.contribute. Changed the sr25519 signature from 8 bytes to 64 bytes.

Can you ELI5 what the problem was with the test?

@dvdplm So it all starts with this PR
In this case specifically sr25519 is expected to have a 64 byte input. Previously polkadot-js would take the input and pad the missing bytes with 0's. Now it is enforced to input the correct length.
In this case we had a 8 byte input, and I changed it to 64.


Blacklist & Lockout QoL

Blacklist Update
Blacklist now works in Inbox (direct messages) as it does in chat, by hiding blocked users in pre-existing multi-chats.
Note: This may lead to "ghost" notifications should someone on your BL post in the group DM.
Account Lockout Change
Account lockouts will now function differently than they did in the past.
Failing to login from new location 3 or more times will result in a 5 minute cooldown period before you can login again (this will stack to 8 - 10 minutes with two additional fails in a 10 minute period).
Failing to login from a previous location (last two recorded) will result in a 3 minute cooldown period before you can login again.
Head Moderators and User Admins can still manually unlock accounts to bypass this cooldown period.

This is ready for final review. Blocking comment resolved, will have final solution with character PR.


chore: Set up Renovate config for Konflux-provided bot

Description
Used these sources of documentation and as examples:

https://redhat-appstudio.github.io/docs.appstudio.io/Documentation/main/concepts/RenovateBot/
https://github.com/redhat-appstudio/build-definitions/blob/main/renovate.json
https://github.com/redhat-appstudio/build-service/blob/1268e589644feccfed33af1a44beb04f43b5a1b2/controllers/git_tekton_resources_renovater.go#L141
https://docs.renovatebot.com/configuration-options/
https://docs.renovatebot.com/modules/manager/tekton/

Related Slack thread:

https://redhat-internal.slack.com/archives/C04PZ7H0VA8/p1707240910969019

Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
Here I tell how I validated my change
TODO(replace-me)
Use this space to explain how you validated that your change functions exactly how you expect it.
Feel free to attach JSON snippets, curl commands, screenshots, etc. Apply a simple benchmark: would the information you
provided convince any reviewer or any external reader that you did enough to validate your change.
It is acceptable to assume trust and keep this section light, e.g. as a bullet-point list.
It is acceptable to skip testing in cases when CI is sufficient, or it's a markdown or code comment change only.
It is also acceptable to skip testing for changes that are too taxing to test before merging. In such case you are
responsible for the change after it gets merged which includes reverting, fixing, etc. Make sure you validate the change
ASAP after it gets merged or explain in PR when the validation will be performed.
Explain here why you skipped testing in case you did so.
Have you created automated tests for your change? Explain here which validation activities you did manually and why so.
Reminder for reviewers
In addition to reviewing code here, reviewers must also review testing and request further testing in case the
performed one does not seem sufficient. As a reviewer, you must not approve the change until you understand the
performed testing and you are satisfied with it.

Closing in favor of https://issues.redhat.com/browse/ROX-22359, see details there.


flexvolume driver daemonset didn't work in worker node

experts,
I was testing ccm in kubernetes v1.18.5 , and when I deployed flexvolume driver as below guide, I found that there are no any log ouputs for oci-flexvolume-driver-worker-xxx pod,  and I also tried to bind an volume of an pod to an exist bv from oci, it also failed.
by the way, oci-flexvolume-driver-master-xxx pod looks fine.

cloud controller manager is deployed in advanced, also up and running, and I tried loadbalancer, it looks good.
ccm version: i used latest, and also tried 0.9.0 version
.....
oci-cloud-controller-manager-xbmpc                1/1     Running   0          4h37m
oci-flexvolume-driver-master-lqgpj                1/1     Running   0          40m
oci-flexvolume-driver-worker-8smgk                1/1     Running   0          39m
oci-flexvolume-driver-worker-n2bgb                1/1     Running   0          39m
tiller-deploy-5cb7ddc974-dtklp                    1/1     Running   2          20d
output of oci-flexvolume-driver-master-lqqpj-------
2021-04-23T08:24:48.093Z	INFO	metadata/instance_metadata.go:87	Metadata endpoint /opc/v2/instance/ returned response successfully
2021-04-23T08:24:48.093Z	WARN	config/config.go:177	cloud-provider config: "auth.useInstancePrincipals" is DEPRECATED and will be removed in a later release. Please set "useInstancePrincipals".
2021-04-23T08:24:48.094Z	INFO	metadata/instance_metadata.go:87	Metadata endpoint /opc/v2/instance/ returned response successfully
2021-04-23T08:24:48.097Z	INFO	client/utils.go:94	OCI using read rate limit configuration: QPS=20, bucket=5	{"pid": 13336, "version": "", "build": "", "command": "init"}
2021-04-23T08:24:48.097Z	INFO	client/utils.go:98	OCI using write rate limit configuration: QPS=20, bucket=5	{"pid": 13336, "version": "", "build": "", "command": "init"}
2021-04-23T08:24:48.512Z	INFO	metadata/instance_metadata.go:87	Metadata endpoint /opc/v2/instance/ returned response successfully
...
output of  oci-flexvolume-driver-worker-8smgk  nothing output.....
kubectl  -n kube-system logs -f oci-flexvolume-driver-worker-8smgk
"nothing here"

shyamradhakrishnan, thanks for reminding this, I would like to try CSI, and will keep u posted if this is works later on.

@shyamradhakrishnan
I tried CSI for my setup, and it looks good, pvc can bonded when pod is created, but still met an errors, which the pod can't be up and running, in "oci-csi-controller-driver" container log, can see below errors which mentioned "provider id", I was a little confused about this provider id
and "smartfren-cne-worker-01" is one of the k8s worker node.
2021-04-23T10:49:00.584Z	ERROR	driver/utils.go:40	ProvideID is missing.	{"node": "smartfren-cne-worker-01"}
2021-04-23T10:49:00.584Z	ERROR	driver/controller.go:204	Failed to lookup node	{"volumeID": "ocid1.volume.oc1.iad.abuwcljtgupxpd5z6ntkub3h4ttcwong73237ajmax3lpk4xhdspvjb6umgq", "error": "missing provider id for node smartfren-cne-worker-01", "nodeId": "smartfren-cne-worker-01"}
2021-04-23T10:49:00.586Z	ERROR	driver/driver.go:150	Failed to process gRPC request.	{"error": "rpc error: code = InvalidArgument desc = failed to get ProviderID by nodeName. error : missing provider id for node smartfren-cne-worker-01", "method": "/csi.v1.Controller/ControllerPublishVolume", "request": "{"node_id":"smartfren-cne-worker-01","volume_capability":{"AccessType":{"Mount":{"fs_type":"ext4"}},"access_mode":{"mode":1}},"volume_context":{"storage.kubernetes.io/csiProvisionerIdentity":"1619173925402-8081-blockvolume.csi.oraclecloud.com"},"volume_id":"ocid1.volume.oc1.iad.abuwcljtgupxpd5z6ntkub3h4ttcwong73237ajmax3lpk4xhdspvjb6umgq"}"}
2021-04-23T10:51:08.593Z	ERROR	driver/utils.go:40	ProvideID is missing.	{"node": "smartfren-cne-worker-01"}
2021-04-23T10:51:08.593Z	ERROR	driver/controller.go:204	Failed to lookup node	{"volumeID": "ocid1.volume.oc1.iad.abuwcljtgupxpd5z6ntkub3h4ttcwong73237ajmax3lpk4xhdspvjb6umgq", "error": "missing provider id for node smartfren-cne-worker-01", "nodeId": "smartfren-cne-worker-01"}
2021-04-23T10:51:08.595Z	ERROR	driver/driver.go:150	Failed to process gRPC request.	{"error": "rpc error: code = InvalidArgument desc = failed to get ProviderID by nodeName. error : missing provider id for node smartfren-cne-worker-01", "method": "/csi.v1.Controller/ControllerPublishVolume", "request": "{"node_id":"smartfren-cne-worker-01","volume_capability":{"AccessType":{"Mount":{"fs_type":"ext4"}},"access_mode":{"mode":1}},"volume_context":{"storage.kubernetes.io/csiProvisionerIdentity":"1619173925402-8081-blockvolume.csi.oraclecloud.com"},"volume_id":"ocid1.volume.oc1.iad.abuwcljtgupxpd5z6ntkub3h4ttcwong73237ajmax3lpk4xhdspvjb6umgq"}"}
2021-04-23T10:52:05.085Z	ERROR	driver/utils.go:40	ProvideID is missing.	{"node": "smartfren-cne-worker-01"}
2021-04-23T10:52:05.085Z	ERROR	driver/controller.go:204	Failed to lookup node	{"volumeID": "ocid1.volume.oc1.iad.abuwcljtgupxpd5z6ntkub3h4ttcwong73237ajmax3lpk4xhdspvjb6umgq", "error": "missing provider id for node smartfren-cne-worker-01", "nodeId": "smartfren-cne-worker-01"}
2021-04-23T10:52:05.088Z	ERROR	driver/driver.go:150	Failed to process gRPC request.	{"error": "rpc error: code = InvalidArgument desc = failed to get ProviderID by nodeName. error : missing provider id for node smartfren-cne-worker-01", "method": "/csi.v1.Controller/ControllerPublishVolume", "request": "{"node_id":"smartfren-cne-worker-01","volume_capability":{"AccessType":{"Mount":{"fs_type":"ext4"}},"access_mode":{"mode":1}},"volume_context":{"storage.kubernetes.io/csiProvisionerIdentity":"1619173925402-8081-blockvolume.csi.oraclecloud.com"},"volume_id":"ocid1.volume.oc1.iad.abuwcljtgupxpd5z6ntkub3h4ttcwong73237ajmax3lpk4xhdspvjb6umgq"}"}

Looks like CCM was not initialised properly in your setup, see Preparing your cluster section at https://github.com/oracle/oci-cloud-controller-manager

Looks like CCM has not been initilalized properly in your setup, please execute steps 1 and 3 in the preparing your cluster section namely
Setting the --cloud-provider=external flag on the kubelet on all nodes in your cluster.
Setting the --cloud-provider=external flag on the kube-controller-manager in your Kubernetes control plane.
You can ignore step 2 first, see if it works without that.

@shyamradhakrishnan
thanks, I patched "provider id" manually as below, and now pod looks fine
kubectl patch node worker01 -p '{"spec":{"providerID":"ocid1.instance.oc1.me-jeddah-1.XXXXXXXXXXX"}}'
NAME   READY   STATUS    RESTARTS   AGE
app1   1/1     Running   0          2m33s
appreciate it your help.


Update index.md

Compare with rich diff

@Rick-Anderson Should I close my original PR?

Or should I just merge your changes into my PR?

@halter73  let me clean this up and then merge with your PR.

@halter73 I see. Can you suggest new wording? You can always create a PR of this PR and I'll merge your changes into these changes then you can merge my PR into your original PR. Do that all via browser/GitHub GUI.
I think it's good info to say that it doesn't replace @using, and you'll frequently need both directives.

I suggested some new wording. Thanks!

@halter73  Should I close this PR and suggest the word changes in your PR or do you want to merge/tweak your PR?

@Rick-Anderson That sounds good to me. I already updated my PR to match your new wording.


No (documented) way to perform env var interpolation in container group yml file

az feedback auto-generates most of the information requested below, as of CLI version 2.0.62

Describe the bug
when specifying a yml file in the az container create the format $VAR ${VAR} and ${env:VAR} are all passed as literals
To Reproduce
create a container group from a yml file and attempt to include a value from your env.
Expected behavior
the value should be interpolated into the yml file when submitted to azure
Environment summary
▶ az --version
azure-cli                         2.30.0
core                              2.30.0
telemetry                          1.0.6
Python location '/opt/az/bin/python3'
Extensions directory '/home/josh/.azure/cliextensions'
Python (Linux) 3.6.10 (default, Oct 29 2021, 10:11:58)
[GCC 7.5.0]
Additional context

route to service team


Wifi and Bluetooth

Anyone have the WiFI and Bluetooth drivers working on T-HEAD c910 ice hardware with Android ?

https://beaglev-ahead.beagleboard.io/docs/latest/boards/beaglev/ahead/index.html


Confirm requirements.txt is accurate

I had to install these packages after installing the latest fontbakery in order for its scripts to run...
sudo pip install pyasn1 ;
sudo pip install characteristic ;
sudo pip install cryptography ;
sudo pip install zope.interface ;

This is my current set of installed pip packages as listed out by the command
pip freeze:
apt-xapian-index==0.45
BeautifulSoup==3.2.1
beautifulsoup4==4.2.1
bzr==2.7.0.dev1
bzr-fastimport===0.13.0.final.0
cffi==1.3.1
characteristic==14.3.0
chardet==2.0.1
colorama==0.2.5
configobj==4.7.2
cryptography==1.1.1
cssselect==0.9.1
cu2qu==1.0
decorator==3.4.0
defcon==0.1
defusedxml==0.4.1
dnspython==1.11.1
docutils==0.11
duplicity==0.6.23
ecdsa==0.10
Electrum==2.4.4
enum34==1.0.4
fastimport==0.9.2
feaTools==0.1
flake8==2.1.0
fontaine==1.3.10
fontbakery==0.0.13
FontCrunch==0.1
fonttools==3.0
futures==3.0.3
gitdb==0.6.4
GitPython==0.3.2rc1
html5lib==0.999
httplib2==0.8
idna==2.0
ipaddress==1.0.15
ipython==1.2.1
Jinja2==2.8
keyring==3.5
launchpadlib==1.10.2
lazr.restfulclient==0.13.3
lazr.uri==1.0.3
libxml2dom==0.5
livestreamer==1.12.2
lockfile==0.8
lxml==3.5.0
Mako==0.9.1
Markdown==2.6.4
MarkupSafe==0.23
matplotlib==1.3.1
mccabe==0.2.1
mercurial==2.8.2
mock==1.0.1
numpy==1.8.2
oauth==1.0.1
paramiko==1.10.1
pbkdf2==1.3
pep8==1.4.6
pexpect==3.1
Pillow==2.3.0
pingo==0.2.0
plyfile==0.4
protobuf==2.5.0
pyasn1==0.1.9
pyasn1-modules==0.0.8
pycparser==2.14
pycrypto==2.6.1
pycups==1.9.66
pycurl==7.19.3
pyflakes==0.8.1
pygame===1.9.1release
Pygments==1.6
pygobject==3.12.0
pygpgme==0.3
PyICU==1.9.2
PyMata==2.10
pyOpenSSL==0.15.1
pyparsing==2.0.1
pyserial==2.7
pysmbc==<IP_ADDRESS>
python-apt===<IP_ADDRESS>-7.0trisquel1
python-dateutil==1.5
python-debian===0.1.21-nmu2ubuntu2
python-magic==0.4.10
python-xlib==0.14
pytz==2012rc0
pyxdg==0.25
PyYAML==3.11
qrcode==4.0.1
queuelib==1.4.2
reportlab==3.0
requests==2.8.1
robofab==1.2
roman==2.0.0
Scrapy==1.0.3
SecretStorage==2.0.0
service-identity==14.0.0
simplegeneric==0.8.1
simplejson==3.3.1
singledispatch==<IP_ADDRESS>
six==1.5.2
slowaes==0.1a1
smmap==0.9.0
Sphinx==1.2.2
tabulate==0.7.5
Twisted==15.4.0
ufo2fdk==0.1
ufo2ft==0.1
ufoLib==1.2
ufonormalizer==0.1
Unidecode==0.4.18
urlgrabber==3.9.1
urllib3==1.7.1
urwid==1.3.1
w3lib==1.13.0
wadllib==1.3.2
wheel==0.24.0
xdot==0.5
zope.interface==4.0.5

There's plenty of unecessary packages (for fontbakery) installed on my system.
@davelab6 maybe you could output the list of packages from your system and we can perform an intersection of both lists ? :-)
To verify the precise set of dependencies required by fontbakery I have setup a virtualenv so that I could install packages individually from scratch, but fontbakery complains about not finding the python-fontforge package.
Trying to install it with pip results in:
pip install fontforge
Collecting fontforge
/home/felipe/devel/github_felipesanches/fontbakery/TesteVENV/local/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
  Could not find a version that satisfies the requirement fontforge (from versions: )
No matching distribution found for fontforge

Outside of the virtual environment I can run fontbakery's python setup install without issues (because it uses the fontforge-python package installed with apt-get)

Please verify with a clean install, using a virtual machine

If we look at the travis config file, we'll notice that these are the pip packages that are installed in the Travis CI virtual machine:

pip install pyicu
pip install git+https://github.com/behdad/fontTools.git
pip install git+https://github.com/googlefonts/fontcrunch.git
pip install git+https://github.com/googlefonts/fontbakery.git

And, additionally, the GCC 4.8 compiler is installed, as well as the following deb packages:

sudo add-apt-repository -y ppa:ubuntu-toolchain-r/test
sudo add-apt-repository --yes ppa:fontforge/fontforge
sudo apt-get update -qq
sudo apt-get install python-fontforge ttfautohint swig libicu-dev
sudo apt-get install -qq g++-4.8

Well, I had to install those packages after installing the latest fontbakery in order for its scripts to run, so there is a problem somewhere.

pip install pyicu
pip install git+https://github.com/behdad/fontTools.git
pip install git+https://github.com/googlefonts/fontcrunch.git
pip install git+https://github.com/googlefonts/fontbakery.git

These should all be in requirements.txt, right?

yes. all of these should be in fontbakery's requirements.txt:

pip install pyicu
pip install git+https://github.com/behdad/fontTools.git
pip install git+https://github.com/googlefonts/fontcrunch.git

except the last one, obviously:

pip install git+https://github.com/googlefonts/fontbakery.git

I presume that the other packages that you installed manually but that are not listed in the travis setup are the ones that may already come pre-bundled in the Travis VM environment. We clearly  should add those to requirements.txt as well.

I'll open a pull request with our current understanding of what's needed in a requirements.txt file for fontbakery and then we can validate and/or improve it as needed.

@girish-dalvi was able to install okay so I think we are now good here.


Creating own dataset

Good night.
I want to create my own dataset with my own labels. is it possible for this repository?
Thanks

Thanks!
But isn't necessary to train a model with youtube 8M?

Short answer - yes.
Two models have been used here.
vggish - as feature extractor.
youtube8m - as classifier.
So if you want to use different labels you need to extract features using vggish and then train youtube 8m model with these features.

Hi,
I still have some questions about creating own data set.
The training script provided by youtube8m is using .tfrecord extension. Do you know how to generate this format for audio?
Also, how do I add my custom labels using the youtube8m training model? Many thanks.


fix: making dependency requirements more relaxed

Codecov Report

Merging #22 (f3284cc) into main (5671fc0) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head f3284cc differs from pull request most recent head 82d1025. Consider uploading reports for the commit 82d1025 to get more accurate results

@@           Coverage Diff           @@
##             main      #22   +/-   ##
=======================================
  Coverage   99.10%   99.10%
=======================================
  Files          28       28
  Lines        1557     1557
=======================================
  Hits         1543     1543
  Misses         14       14

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Update material to use RHDPS

We are reworking the labs to be installed as an Ansible Playbook with local Eclipse Che and Workshopper for guides. This will be possible to install on either RHPDS workshops, on customers own OpenShift Cluster, or Minishift.

This works now with new doc materials specific for ocp/che style workshop; also the new repo for the infra stuff is here now: https://github.com/jbossdemocentral/vertx-kubernetes-workshop-infra


add pagination and search in user

pagination with ci template and search by name(nama on table)

acc merge


Adding More comments for .mendelrc in full example

@anuragdamle @stephanwlee @irae

👍

@irae Updated comments as per your suggestion.


samples: subsys: shell: shell_module: Add support for mec15xxevb_assy6853 board

The shell didn't work on the "mec15xxevb_assy6853" board.
I identified two problems:

The board goes to a deep sleep state after a short moment. In this mode the UARTs are powered down and do no longer work.
The "shell_module" sample requires the shell UART to be enabled/defined, which was not the case for the "mec15xxevb_assy6853" board.

With these fixes the "shell_module" sample is working well on my "mec15xxevb_assy6853" board.

In my opinion, the problem is with the board configuration not with the example. Adding an overlay file is fine but to be honest I do not like the solution in the main.c file.

Ok, then I need to find a way to prevent the board going into deep sleep state somewhere in the board configuration. Any hints?

@carlescufi  do you know who can help with the microchip boards?

@carlescufi do you know who can help with the Microchip boards?

@jvasanth1 @MaureenHelm can you help here?

In my opinion, the problem is with the board configuration not with the example. Adding an overlay file is fine but to be honest I do not like the solution in the main.c file.

But wouldn't it be a more real-world scenario if we keep the board config as it is and simulate some "real work" while the shell is running? When I would use the shell in my application I would not want to disable deep sleep but would expect that I can use the shell while there is some other work done.

@ambranaam please remove the merge commits by rebasing.

Done.

But wouldn't it be a more real-world scenario if we keep the board config as it is and simulate some "real work" while the shell is running? When I would use the shell in my application I would not want to disable deep sleep but would expect that I can use the shell while there is some other work done.

But wouldn't you lose bytes in that case? In real world scenario your app may sleep 1ms, 1min or 1 day. Shell assumes that uart RX is always on.

But wouldn't you lose bytes in that case? In real world scenario your app may sleep 1ms, 1min or 1 day. Shell assumes that uart RX is always on.

I am not (yet) an Microchip MEC expert, but I would say that the deep sleep is entered only if system is in sleep state (which I assume has UARTs enabled and working) for a while (how long is that?).

But wouldn't you lose bytes in that case? In real world scenario your app may sleep 1ms, 1min or 1 day. Shell assumes that uart RX is always on.

I am not (yet) an Microchip MEC expert, but I would say that the deep sleep is entered only if system is in sleep state (which I assume has UARTs enabled and working) for a while (how long is that?). In a real-world scenario (e.g. used as an Embedded Controller on a x86 mainboard) I would assume that the deep sleep mode is entered only when the system is in a sleep state, and then I would say that it is OK to have the shell not running. But yes, maybe it's a good idea to disable the deep sleep completely when we want to use the shell, as we only want to use the shell as a debug helper. So, let's wait for an Microchip MEC expert who tells us how to disable the deep sleep by some Kconfig option.

we can remove CONFIG_PM from board level KConfig, this way application can enable if required

@jvasanth1 please take a look

@jvasanth1 please take a look

@jvasanth1 ping

@ambranaam have you try the proposed change given on Dec 21, 2022?


nodai_shark_studio_20231009_984.exe does not work

when I try to run the nodai_shark_studio_20231009_984.exe  , I get following error.
G:\nodai_shark_studio>nodai_shark_studio_20231009_984.exe
[26036] Failed to extract PIL_imaging.cp311-win_amd64.pyd: decompression resulted in return code -1!
G:\nodai_shark_studio>

Redownload imho, looks like damaged file

Yes, that specific release is broken. Thanks for the heads up, I'll mark it as such.


Religious-regional cultures not working

It seems as the converter doesn't care about the various lines in the culture mapping file that teaches it to, e.g. make the Muslim Serbians Bosnjaks or remembering that British people in Canada are "Anglo Canadian".
I don't know if it may be tied with order as in #507, but in doubt, I post it here, as it is an annoying bug and may cause cultural-core problems.

This issue is related to #47

They look connected, but really are separate from a programming perspective.


Requires Babel "^7.0.0-0", but was loaded with "6.26.3".

🐛 Bug Report
I get the following message when trying to run tests.  None of the solutions in the documentation or other issues work.
    Requires Babel "^7.0.0-0", but was loaded with "6.26.3". If you are sure you have a compatible version of @babel/core, it is likely that something in your build process is loading the wrong version. Inspect the stack trace of this error to look for the first entry that doesn't mention "@babel/core" or "babel-core" to see what is calling Babel.

      at throwVersionError (node_modules/@babel/plugin-proposal-class-properties/node_modules/@babel/helper-plugin-utils/lib/index.js:65:11)
      at Object.assertVersion (node_modules/@babel/plugin-proposal-class-properties/node_modules/@babel/helper-plugin-utils/lib/index.js:13:11)
      at _default (node_modules/@babel/plugin-proposal-class-properties/lib/index.js:81:7)
      at node_modules/@babel/plugin-proposal-class-properties/node_modules/@babel/helper-plugin-utils/lib/index.js:19:12
          at Array.map (<anonymous>)

To Reproduce
Relevant package.json dependencies/config
{
   "devDependencies": {
        "@babel/core": "^7.0.0",
        "@babel/plugin-proposal-class-properties": "^7.0.0",
        "@babel/plugin-proposal-decorators": "^7.0.0",
        "@babel/plugin-proposal-object-rest-spread": "^7.0.0",
        "@babel/plugin-syntax-dynamic-import": "^7.0.0",
        "@babel/preset-env": "^7.0.0",
        "@babel/preset-react": "^7.0.0",
        "@babel/register": "^7.0.0",
        "babel-core": "^7.0.0-bridge.0",
        "babel-jest": "^23.4.2",
        "babel-loader": "^8.0.0",
        "jest": "^23.5.0",
        "jest-environment-jsdom": "^23.4.0",
        "jest-junit": "^3.6.0",
        "jest-transform-graphql": "^2.1.0",
        "regenerator-runtime": "^0.12.1"
    },
   "jest": {
        "coveragePathIgnorePatterns": [
            "node_modules",
            "/*.graphql"
        ],
        "transform": {
            "\\.(gql|graphql)$": "jest-transform-graphql",
            "^.+\\.js$": "babel-jest"
        },
        "setupFiles": [
            "<rootDir>/src/jestSetup.js"
        ],
        "snapshotSerializers": [
            "enzyme-to-json/serializer"
        ],
        "testResultsProcessor": "jest-junit"
    }
}

.babelrc
{
    "presets": ["@babel/preset-react"],
    "plugins": [
        "@babel/plugin-proposal-class-properties",
        "@babel/plugin-proposal-object-rest-spread",
        "@babel/plugin-syntax-dynamic-import",
        ["@babel/plugin-proposal-decorators", { "legacy": true }]
    ],
    "env": {
        "test": {
            "presets": ["@babel/preset-env", "@babel/preset-react"]
        }
    }
}

jestSetup.js
import 'regenerator-runtime';
import Enzyme from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';

Enzyme.configure({ adapter: new Adapter() });

Expected behavior
Jest runs correctly
Link to repl or repo (highly encouraged)
Please provide either a repl.it demo or a minimal repository on GitHub.
Issues without a reproduction link are likely to stall.
Run npx envinfo --preset jest
Throws the follwing error
(node:792) UnhandledPromiseRejectionWarning: TypeError: Cannot read property '1' of null

Strange.  I got the exact same error due to me removing babel-core when I updated to Babel 7.  I re-added it alongside @babel/core and that fixed it:
  "devDependencies": {
    "@babel/core": "^7.0.0",
    "babel-core": "7.0.0-bridge.0",
  ...
}

Are you using package-lock.json?  Maybe try deleting it and also remove node_modules, then reinstall?

I think this should work, your config looks correct...
Mind setting up a repo showing the error?

@jorgegonzalez same here in the project I'm working on
Since I've updated to babel 8 (@babel/core), all tests are breaking.
 FAIL  test/spec/utils.test.js
  ● Test suite failed to run

    Jest encountered an unexpected token

    This usually means that you are trying to import a file which Jest cannot parse, e.g. it's not plain JavaScript.

    By default, if Jest sees a Babel config, it will use that to transform your files, ignoring "node_modules".

    Here's what you can do:
     • To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.
     • If you need a custom transformation specify a "transform" option in your config.
     • If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.

    You'll find more details and examples of these config options in the docs:
    https://jestjs.io/docs/en/configuration.html

    Details:

    /home/herinson/.../test/jest.setup.js:1
    ({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,global,jest){import { configure } from 'enzyme';
                                                                                ^

    SyntaxError: Unexpected token {

      at ScriptTransformer._transformAndBuildScript (node_modules/jest-runtime/build/script_transformer.js:403:17)

And if I run npm ls babel-core, it shows that jest-runtime depends on babel-core
[herinson@arch ] (develop) $ npm ls babel-core
└─┬<EMAIL_ADDRESS>  └─┬<EMAIL_ADDRESS>    ├─┬<EMAIL_ADDRESS>    │ └─┬<EMAIL_ADDRESS>    │   └─┬<EMAIL_ADDRESS>    │     └──<EMAIL_ADDRESS>deduped
    └─┬<EMAIL_ADDRESS>      └──<EMAIL_ADDRESS>deduped

I was able to get rid of this error by copying node_modules/babel-core into node_modules/jest-config/node_modules overriding the installed babel-core that jest-config installs as its dependency. If you are hitting this error, can you check node_modules/jest-config/node_modules/babel-core and see what version it installed? Compare this with your node_modules/babel-core directory. If your project's babel-core is at 7.0.0, it should look much different from the one in the jest-config directory.
I did a simple test a minute ago to see if updating jest-config's dep version fixes the issue, and it looks like it does:
cp -r node_modules/babel-core node_modules/jest-config/node_modules
This will copy your 7.0.0 version into the jest-config's dependencies. Run your tests again. This worked for me locally, but I am curious if this works for anyone else. If it does, then my PR #6926 may be a proper resolution for this?

@matthamil  That did it!  Thanks!

@matteofigus that won't work for babel 8 as all babel modules for this version are installed at node_modules/@babel

My personal temporary solution is adding a postinstall npm script: rimraf node_modules/jest-runtime/node_modules/babel-core node_modules/jest-config/node_modules/babel-core

A solution for Yarn is to add a resolutions field to package.json like so:
"resolutions": {
  "babel-core": "7.0.0-bridge.0"
}

And then run yarn to update the dependency resolutions

@herodrigues good point, I updated the PR to reflect the namespaced @babel/core: https://github.com/facebook/jest/pull/6926/files#diff-42f440414578ffb55a0c454ba79a0d5b

This will be a good solution
sudo npm install<EMAIL_ADDRESS>--save-dev

Run your tests again. This worked for me locally

Thanks for all the help and guidance so far. I am struggling to migrate Jest to babel@7 on a side project of mine too. I've tried things described here but am stuck. I created a PR with as a repro case. I am not sure if I am doing something simple or essential wrong.

What's the status on this issue? This is preventing me from updating my project to babel 7. A solution that only works for yarn users isn't a solution.

@g-plane's solution worked for me..
npm install<EMAIL_ADDRESS>--save-dev

and add a postinstall npm script with rimraf node_modules/jest-runtime/node_modules/babel-core node_modules/jest-config/node_modules/babel-core

The rimraf hack is fugly. I'm teaching a React / Redux / Jest class next week and having this postinstall script in my demo app's package.json makes me want to take a shower.
Please, please Jest team, fix this ASAP!

They've just released a new minor version, but jest still depends on<EMAIL_ADDRESS>$ npm ls babel-core
└─┬<EMAIL_ADDRESS>  └─┬<EMAIL_ADDRESS>    └─┬<EMAIL_ADDRESS>      └──<EMAIL_ADDRESS>
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>|| ^7.0.0-0 but
none is installed. You must install peer dependencies yourself.

What's infuriating is all these docs mentioning 7.0.0-0 which is a
version that DOES NOT EXIST. It does resolve to 7.0.0.bridge-0, but not
in Jest's context due to their local use of 6 in runtime and config.
On Mon, Sep 10, 2018, at 18:09, Herinson Rodrigues wrote:

They've just released a new minor version (23.6.0), but jest still
depends on<EMAIL_ADDRESS>

$ npm ls babel-core └─┬<EMAIL_ADDRESS>└─┬<EMAIL_ADDRESS>└─┬ jest-
<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>|| ^7.0.0-
0 but none is installed. You must install peer dependencies yourself.

— You are receiving this because you commented. Reply to this email
directly, view it on GitHub[1], or mute the thread[2].
--
Christophe Porteneuve
<EMAIL_ADDRESS>

Links:

https://github.com/facebook/jest/issues/6913#issuecomment-419968618
https://github.com/notifications/unsubscribe-auth/AAAOqPcSn3gMoXWyNTYGFECR1-JiG4z5ks5uZo7FgaJpZM4WRvbY

It looks like this is the PR they're working on to implement this:
#6949
Hopefully they can get it done quickly.

Again, Jest works perfectly fine with Babel 7. It things are loaded incorrectly it's an issue with configuration.
I've opened up a PR adding an example to Jest's code base using babel 7: #6983

Thank you, @SimenB. Your example helped me to get Jest up and running.
For others wondering, I needed to add @babel/plugin-transform-modules-commonjs plugin to my babel.config.js. After that an error on import vanished. My babel.config.js:
'use strict'

module.exports = {
  presets: ['@babel/preset-env', '@babel/preset-react', '@babel/preset-flow'],
  plugins: [
    '@babel/plugin-transform-modules-commonjs',
    '@babel/plugin-proposal-export-default-from',
    '@babel/plugin-proposal-export-namespace-from',
    '@babel/plugin-proposal-class-properties',
    '@babel/plugin-proposal-object-rest-spread',
  ],
  env: {
    production: {
      presets: [
        [
          '@babel/preset-env',
          {
            modules: false,
          },
        ],
        '@babel/preset-react',
        '@babel/preset-flow',
      ],
    },
  },
}

@SimenB I have already installed the bridge package for Babel 7, that does not fix the error unless I use yarn and I set up a resolves  section in my package.json. Running npm ls babel-core outputs exactly what @herodrigues listed above.

@DBosley  yeah, it still depends on<EMAIL_ADDRESS>The problem is that I didn't have it worked for me after installing<EMAIL_ADDRESS>installed.
After installing it, it should work as expected.

It doesn't matter that babel-core comes from jest-runtime, it will still work, and load the correct version.
Make sure to use babel.config.js if you're still having issues

I will also add that this has been a little more difficult than "just install babel-core@bridge". In my case, I had to delete node_modules and package-lock.json and do a full rebuild to get the dependency tree correct.

Small improvements like the above in the form of e.g. "You may have to delete your lockfile to get the correct dependency tree" is welcome as pull requests!
I would think that a npm dedupe would have fixed it as well, FWIW

Are you telling me that on a fresh project, if we install Babel 7 and babel-core@7-bridge, then install Jest, we don't get Babel version conflicts? How is that even possible considering that, for instance, jest-runtime currently has a clear dependency on babel-core@6, and therefore will have it installed locally and prioritized over the higher-up @7-bridge?
So far the only workaround I've seen that works is to manually strip the locally-installed babel-cores@6 in jest-config and jest-runtime, so they pick up the project-level v7…

(At any rate, on any existing project, deleting package-lock may not be an option, and we do get the versioning conflict, so… seems to me fixing jest-runtime and jest-config's dependencies (to something like ">= 6" would be the better way)

I'll have to give it a whirl. On an existing project, the upgrade (as
per npx babel-upgrade) was faulty.
On Tue, Sep 18, 2018, at 13:24, Simen Bekkhus wrote:

Are you telling me that on a fresh project, if we install Babel 7 and
babel-core@7-bridge, then install Jest, we don't get Babel version
conflicts?> Almost, you also need to install babel-jest. Then yes, you will not
get conflicts> — You are receiving this because you commented. Reply to this email
directly, view it on GitHub[1], or mute the thread[2].
--
Christophe Porteneuve
<EMAIL_ADDRESS>

Links:

https://github.com/facebook/jest/issues/6913#issuecomment-422355740
https://github.com/notifications/unsubscribe-auth/AAAOqMpdulOqlJE2O4pZudRSePJaT2oNks5ucNfZgaJpZM4WRvbY

Starting on a fresh project using<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>can confirm that it works as expected. No runtime version conflict whatsoever.
Experience on upgrading existing project though, involves fighting with remove-readd dependencies and lockfiles.

I'm a bot confused how we're supposed to fix this when the problem is jest itself requiring old versions of babel-core? My project is using @babel/core v8.
`--<EMAIL_ADDRESS>  `--<EMAIL_ADDRESS>    +--<EMAIL_ADDRESS>    | `--<EMAIL_ADDRESS>    |   `--<EMAIL_ADDRESS>    |     `--<EMAIL_ADDRESS>deduped
    `--<EMAIL_ADDRESS>      `--<EMAIL_ADDRESS>deduped

As you can see here jest has a dependency on v6: https://github.com/facebook/jest/blob/master/package.json#L6
In the meant time I didn't really get how we're supposed to fix this?

It doesn't match that jest internally requireseits own version, we require thw version you define when transpiling your code

@SimenB better lock this issue. People will keep coming here to complain about it even though they don't check their project configuration.

@herodrigues good call!
If people have (babel) issues with Babel 7 whilst:

using jest@23 or older
uses babel-core@bridge and @babel/core@7
have both jest and babel-jest in package.json
do not use create-react-app

feel free to open a new issue. If you fit any of the requirements above, without fulfilling all of them, also fell free to open up a new issue!


Added note that this cmdlet will not apply to Teams

Added note that this cmdlet will not apply to Teams

Docs Build status updates of commit 7df28e2:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

skype/skype-ps/skype/Get-CsUserPstnSettings.md
:white_check_mark:Succeeded
View (skype-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

@JohanFreelancer9

@tseward @dariomws

@tseward @dariomws please review

@dariomws Please review

@tiburd Please merge this PR. Thanks

Docs Build status updates of commit 0f37cf6:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

skype/skype-ps/skype/Get-CsUserPstnSettings.md
:white_check_mark:Succeeded
View (skype-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Hiding the title bar

Is is possible to completely hide the title bar to have just the webpage as the application?

Ok. So I assume it's not possible in not-fullscreen mode. Like Spotify do.
On Thu, 22 Nov 2018, 15:24 Chris Knott<EMAIL_ADDRESS>wrote:

It's possible in Kiosk mode (full screen). Add the flag --kiosk to
chromeFlags
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ChrisKnott/Eel/issues/82#issuecomment-441045759, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACTIpQm1yDe24X8YhRO0QtfoBXWYWeDWks5uxrOtgaJpZM4YvY0J
.

Not unless it is a feature of Electron and you use that as the browser

what i am add the menu bar in eel window


Fix: Pattern for OaM Records allows not enough digits

(Issue created on behave of Vanitha Valluripalli)
Please find the below mentioned observation here:

specification OamLog
service /core-model-1-4:control-construct/profile-collection/profile={uuid}/oam-record-profile-1-0:oam-record-profile-pac/oam-record-profile-capability
parameter uuid
pattern '^ol-0-0-1-oam-record-p-\d{4}$', which allows only 4 digit uuid, which conflicts with maximum number of allowed entries being 1000000 according to LOADfile.

Proposed Solution:
Change the pattern so that it allows 7 digit uuid that is from '^ol-0-0-1-oam-record-p-\d{4}$' to '^ol-0-0-1-oam-record-p-\d{7}$'

OaM records are no longer stored in the LOADfile, but in a separate database.
oam-record-profile has been discontinued.
Issue got obsolete.


Live Share integration

When a guest joins a session, and the host is in a CodeSwing workspace, we should automatically open the swing. Additionally, we should synchronize layout changes and swing runs, so that all participants share the same swing state.

The initial version of this has been shipped!


Changes in production

Hi,
If I understood correctly, new attributes for objects in a graphql.schema do not change ancient saved objects, but what happens if we make errors by removing attributes ?
Is there a warning message to prevent deleting old objects ?

@rudyhadoux Managing data migration is out of scope for the CLI, so beside deploying the new API, the CLI will not operate on any existing data, not add or delete. It is the same problem area like data backfill. That is something that needs to be done manually. The CLI is not checking if there is existing data or not. In a cloud environment it is really likely that the account who does the deployment - executing the CLI - does not even have access to the production data, so there is no way to check it.
I hope this answers your question, if you have something new, please feel free to reopen the issue.

Thanks for answer but it would be great to add this (really important) feature.

@rudyhadoux could you give an example schema and workflow on how you think such functionality might look from a developer experience?

It can simply be a list of names of deleted or changed objects.
Even without details.
In case of :

addition of attributes.
removal of attributes.
removal of objects.

Is there a way to clone an AWS Amplify back-end to test any changes ?


Added Quick Heal and Quick Speed hotkeys

Added quick heal and quick speed hotkeys. Shouldn't be too cheaty since it doesn't actually right click the item for you, just changes active hotbar slot.

Please, request review from me whenever you think this is ready for one.

wait a minute

there we go


cardano-api 1.36.0

This PR updates the cardano-api version used in the wallet to 1.36.0 to make use of the new BundledProtocolParameters.

I've just done a comparison of master with this branch, running the following command 10 times:
cabal run cardano-wallet:test:unit -- --match "balanceTransaction" --seed $i

We see a small but significant (around 10%) reduction in the required total CPU time (in seconds):

seed
master
yura/bundled-protocol-parameters

1
559.1
492.2

2
542.4
492.4

3
543.8
491.9

4
547.2
498.3

5
542.6
486.5

6
557.3
496.7

7
578.5
517.0

8
560.7
513.1

9
537.5
494.4

10
555.5
505.2

mean
552.5
498.7

stdev
12.2
9.9

Locally, I get the following error (100% reproducible):
$ cabal run cardano-wallet:test:unit -- --match "/Cardano.Wallet.Shelley.Transaction/estimateSignedTxSize/equals the binary size of signed txs/"

Cardano.Wallet.Shelley.Transaction
  estimateSignedTxSize
    equals the binary size of signed txs [✘] (94ms)

Failures:

  test/unit/Cardano/Wallet/Shelley/TransactionSpec.hs:4485:17:
  1) Cardano.Wallet.Shelley.Transaction.estimateSignedTxSize equals the binary size of signed txs
       Falsifiable (after 1 test):

       "84a6008182582062d3756241f3f19483e2f710e00e83c80e84329bff08753df3a628beea3454ec18370d800182825839010c36ef7fff0869d7e75cd70f0f369bb770d66efd50625c2c1a5e84f3cd2a80021c790f232cddd9216631f285a0d745361d402305a61abc071a000f422a82583901d6c89cba59e000ab67171115d99a2f845c38b7616838d168af37288fcd2a80021c790f232cddd9216631f285a0d745361d402305a61abc071b000000174865a61e021a0001ffb803198fae0e81581c98947dd5fc0ec3fa16043bdbf5577fa383bb89deab60d9d9f80a214ca10082825820debdc92010207d6b51bfd2bab3d03610742d71cbf3867a7c8a7fce360c134a0e5840919835b47a543b72fae3a64cf75145cf0aa44e31cc0e089c9b2fea93d0acae9e2d69c28d4808904be4129c7a16ff3563843a8851a56701eb45947b1329bd540b8258204cff849a17fcbd9e40425e2c2ef96544333c91306e5f869e9d66fc0db91ffa0c584043c3dd8e9596ba3698633e7d6fcc20c4b0081211a1351ec192296abbb40411692fc75504d7a50f02f2439313dc5f16aa982aab8cea6e32e0c6e64a1b82609306f5f6"
       expected: TxSize 856
        but got: TxSize 428

  To rerun use: --match "/Cardano.Wallet.Shelley.Transaction/estimateSignedTxSize/equals the binary size of signed txs/"

Randomized with seed 353322201

Finished in 0.0956 seconds, used 0.2510 seconds of CPU time
1 example, 1 failure

Slow spec items:
  test/unit/Cardano/Wallet/Shelley/TransactionSpec.hs:4473:5: /Cardano.Wallet.Shelley.Transaction/estimateSignedTxSize/equals the binary size of signed txs/ (94ms)

bors merge


update dependencies

@3imed-jaberi work still progress, they are some fix in unit test

Node 8 and 9 aren't maintained: https://nodejs.org/en/about/releases/


[Implementation] Dashboard Screen

Implement Dashboard screen of app as per Figma design.

pull request #16 added for this issue.


⚠ File access has degraded performance

In 5f2bea7, File access (https://fyle.uk/file/fish) experienced degraded performance:

HTTP code: 200
Response time: 3506 ms

Resolved: File access performance has improved in 1abb108 after 8 minutes.


[doc] mention automatic file extension in output/build/script

learned about this here, and it's super useful for multi-platform multi-output recipes!

Thanks!


context menu does not offer paste in Firefox-on-Windows

The right-click context menu does not offer 'paste' as an option when using Firefox 50.0, FirefoxPortable 50.0.2, and FirefoxPortable 50.1.0 on Windows 8.1.  Pasting works when the paste option is selected from the Firefox menu.
Details

Browser and browser version:  Firefox 50.0 and FirefoxPortable 50.0.2 and 50.1.0
OS version:  Win 8.1
xterm.js version:  github as of 2016-12-16

Not affected:

Firefox Nightly, Google Chrome, and Safari on OS X (El Capitan)
Firefox 50.1.0 on Linux
Google Chrome on Win 8.1
Internet Explorer 11 on Win 8.1 has a paste option, but it doesn't work. (Different problem)

Steps to reproduce

Open an xterm.js Terminal in Firefox on Windows
Select some text with the mouse
Right click and select 'Copy'
Right click again to bring up context menu; observe that there is no "Paste" option.

Thanks for reporting this @risacher. Will take a look and post updates here.
Does this happen in the demo or in your consumer application? If the case is the latter there are a few chances it happens because one of the terminal's ancestors are using CSS transforms.

Same issue on Windows 10.
Any news about this?
And not only the context menu, I just don't have any clue about how to paste in Firefox on Windows... :(

@Oliboy50 I will try to get on top of this as soon as possible.
Are you aware if the host application of xterm.js that you are using, is using CSS transforms on xterm.js or any of it's parent elements?

@parisk you can poke at a live version of my app at https://risacher.org/ttyx/ , the code for which is https://github.com/risacher/ttyx.  You shouldn't be able to log in, but you can test the terminal paste function without logging into the server.
In my case the only css that's loaded is xterm.css from xterm.js itself and https://risacher.org/ttyx/style.css, which is derived from chjj's tty.js style.css.
I dunno about the demo app;  I'll try to check that.

I just confirmed that the same thing happens in the demo app.

@Oliboy50 I can paste in Firefox-on-Windows by selecting "paste" in the dropdown menu, which opens when I click on a symbol in the upper right of the browser window that looks like three horizontal bars.
Admittedly, I struggled for many months before I noticed that cut-copy-paste were in that menu, and it still seems strange to me that paste might work from there when it doesn't appear in the context menu.

@parisk Yes, can't show copy or paste context menus if CSS transforms is using on xterm.js or any parent elements. Thx!

@parisk but I still do not understand why CSS transforms will lead to such a problem, could you explain it? Thanks very much!

@ansiz CSS transforms are messing with absolute positioning of elements, which is used to provide the clipboard menu.


How to determine if robot has reached a particular position.

Hey, after enabling the p-controller, is there a way I can check whether the current motion the robot is performing complete or not? I would like to perform certain operations after every time the robot finishes moving its joints to a particular position.
Maybe like a trigger when the particular target position is reached?

Currently there is no such trigger. The best option would probably be to check the q values coming in from the p-controller and threshold the difference between two sequential joint values.

I was trying out something like this -
public IEnumerator CheckForMotion()
    {

        var first = last_q;
        yield return new WaitForSeconds(0.3f);
        var second = last_q;
        Debug.Log(first.SequenceEqual(second));

    }

But last_q is not returned by the p-controller it is in the RobotBase file itself. How can I get the Q values from the controller?

Well, the fact that first.SequenceEqual(...) prints true makes sense. The controller is always moving and updating. At some point the updates become  tiny, but a p-controller theoretically never reaches the target value.
Do the following: here the RobotBase receives the controller's updates. Take these joint values coming in here and check the newest one for the previous one.
double[] prev_joint_values = new double[] {0,0..., 0}
 private void ControlledJointsChanged(object sender, JointsChangedEventArgs e)
    {
        if (!EnablePController) return;

        if (e.DidConverge)
            SetQ(e.joint_values);

        if(prev_joint_values.EqualsWithTolerance(e.joint_values, 0.01))
        {
         // stopped moving.
        }
        prev_joint_values = e.joint_values;
    }

For EqualsWithTolerance you can use something like this

Hey, I tried using this IsTolerant function -
bool IsTolerant(double[] array1, double[] array2, float tol)
    {

        for (int i = 0; i < array1.Length; i++)
        {

            double dif = Math.Abs(array1[i] - array2[i]);
            if (dif > tol)
            {
                return false;
            }

        }

        return true;
    }

And in the controlled joints function, I did this-
    private void ControlledJointsChanged(object sender, JointsChangedEventArgs e)
    {
        if (!EnablePController) return;

        if (e.DidConverge)
            SetQ(e.joint_values);
        if (IsTolerant(prev_joint_values, e.joint_values, 0.0001f))
        {
            Debug.Log("Not Moving");
        }
        else
        {
            Debug.Log("Moving");
        }
        prev_joint_values = e.joint_values;
    }

The console always prints Not Moving, and on printing out the difference, I found that both prev joint values and e.joint_values are always the same. So it never prints that the robot is moving.

Well, they can't be the same because then the robot wouldn't move. The Unity Console (as far as I remember) usually does not print the full number by default but truncates the output. So maybe check it in the debugger.  There has to be a difference because as I said otherwise the robot would not move. Its only a matter of finding the correct tolerance values. I'd suggest making a public varaible out of your tolerance and then running the game and changing the value of tolerance until it prints correctly.
Instead of using the joint values you could also use the end-effectors position to check if it still moves.


Update a small mistake

Contents altered

Contents altered

@smaranjitghose Sir, There is missing the closing } at the end of the directory. Please check it.

@smaranjitghose Sir, There is missing the closing } at the end of the directory. Please check it.

This one?

This one?

This one?

The one I changed. In line 37.

This one?

The one I changed. In line 37.


Allow disabling "g" prefix for commit hash in version number

I've had multiple folks (including myself) be confused about the g in front of the commit sha of a version number like 16.0.40-preview+ge6c3a1f9e4.
You don't immediately realize without knowing this convention that the g isn't part of the sha and wonder why you can't find the commit. Is there a reason for the prefix or could there be an option to turn it off?

It stands for git, and provides a more deterministic way to ascertain that what follows is the commit ID. I don't remember where it came from (I didn't invent the convention).
I've heard this feedback several times though, and I sympathize with the inconvenience of not being able to just double-click to select the "word" and paste it somewhere else without having to trim off the leading g.
I'm not sure anyone even likes the leading g (as folks don't tend to reinforce behavior that they like), so while an option to remove it seems perfectly reasonable, it's worth considering simply removing it entirely, or at least making the option default to removal.
I'm planning some breaking changes for a 3.0 version, and changing this behavior (or at least the default) would be well-placed for the 3.0 version, I think. And perhaps we can add the option in 2.3, but change its default in 3.0.

So... now I know why the g prefix is there. Without it, if the commit id happens to start with a number, nuget produces warnings:
This works great (when the commit starts with a letter):
Successfully created package '/root/bin/Debug/root.42.42.4-f92b4f1cbd.nupkg'.

But when the commit starts with a number:
Successfully created package '/root/bin/Debug/root.42.42.3-7d637a3dc6.nupkg'.
/usr/share/dotnet/sdk/2.1.403/Sdks/NuGet.Build.Tasks.Pack/build/NuGet.Build.Tasks.Pack.targets(199,5): warning NU5105: The package version '42.42.3-7d637a3dc6' uses SemVer 2.0.0 or components of SemVer 1.0.0 that are not supported on legacy clients. Change the package version to a SemVer 1.0.0 string. If the version contains a release label it must start with a letter. This message can be ignored if the package is not intended for older clients. [/root/root.csproj]

So, that stinks.
I could still make it an option, or make the g appear in only certain contexts and not others, but I'm worried it will be confusing/frustrating if the g appears in some places but not others since folks will have an even harder time predicting and understanding when/where it appears.

I think the approach to fix this should be that we remove the g whenever the version.json file has opted into semver 2 for nuget packages. Or in other words, we use the g only for nuget package versions, and only when using semver 1 rules (which is the default).

@AArnott how about we replace the g with git-? That should make it clearer that the following is a git commit sha, e.g. root.42.42.4-git-f92b4f1cbd.nupkg

I would prefer a g prefix, when enabled, since it’s a “standard” convention after all. For semver 2, it would be nice to drop the prefix, but then I’m now used to seeing it everywhere, e.g. msbuild output, so I guess ultimately it should be configurable?

Is this stil disableable?
I tried setting these but still get the g prefix.
  "gitCommitIdPrefix": "",
  "nugetPackageVersion": {
    "semVer": "2"
  },

No @nosalan, the option to remove this was reverted. See earlier discussion for the problems that removing the prefix introduces.


is there anyway to share some ssh public key from multiple git repository ?

As I know, cloud config server support one default git repo and repos with pattern as below:
spring:
  cloud:
    config:
      server:
        git:
          uri: git@github.com:spring-cloud-samples/config-repo
          repos:
            simple: git@github.com:simple/config-repo
            special:
              pattern: special*/dev*,*special*/dev*
              uri: git@github.com:special/config-repo

So there is one question here, if all above git url is ssh authorized, is there any way to share the same ssh public key as the deploy key ? I did some investigation about this limitation:

For now by default, config server only take default ssh key name like id_rsa and id_rsa.pub.
Github do not allow share ssh public key between different repos, or you may get This key is in use already.

Any idea about this issue ?

If github doesn't allow it, I'm not sure what we can do.

or can we try each sshkey under ~/.ssh/ instead of default id_rsa one ?

It is not going to make a difference if GitHub doesnt support it

how about there are 2 sshkey under ~/.ssh/, one for repo A and the other for repo B. When  clone from these repos, will try each key for authentication ?

I suppose you could set the keys via properties
http://cloud.spring.io/spring-cloud-static/Greenwich.SR1/single/spring-cloud.html#_git_ssh_configuration_using_properties

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.


As a Data/Web manager I want to provide a well documented application programming interface (API - to access the data programmatically) ..so that I enable users to access the open/shareable data programmatically without requireing additional staff resource

original id#76
Direct access to the data without using a GUI.
Needs a matching end-user perspective user-story to create the demand for this!
Computer to computer access (computer geeks!)
Conflicts with tracking users, if latter agreed #13

Would an R package help to facilitate the access to the WebAPI?

https://cetaceans.ices.dk/webservices


feat: apply helmet middleware

AsIs
With our current implementations, Express middlewares under Nest is only disabling X-Powered-By headers. (Ref)
For considering security perspectives, helmet middleware covers not only this but another header values for production deployment, where we need to be more secure.
ToDo

[x] research how to add helmet with TypeScript to Express as Nest backend
[x] implement helmet and remove app.disable()

(Optional) Acceptance criteria
Confirm HTTP headers will be changed for security.
(Optional) Additional contexts
Issue(s): https://github.com/hwakabh/hwakabh.github.io/issues/190 (Basic implementation to Express with JavaScript)

research how to add helmet with TypeScript to Express as Nest backend

When we use npm packages, which have originally been developed without TypeScript, basically we need to install @types (DefinitelyTyped) as well as the packages to use. (Ref)


Cyclic Item Sorter lost colours in GUI

Minecraft version & Mod Version:
Minecraft: 1.12.2, Cyclic: 1.15.2
Single player or Server:
Server
Describe problem (what you were doing / what happened):
Cyclic Item sorter used to have each row in the GUI colour coded to match the output side - now there is no colour in the GUI at all, so no way of knowing which row relates to which side of the sorter.
Crash log (if any):
(If this is a suggestion and not a bug report, delete all this and just write your suggestion!)

Thanks for the report! This has been fixed in previous version  https://github.com/PrinceOfAmber/Cyclic/issues/809