closeIdleConnectionsAfterEachResponse closes the response before consuming is possible

Im using the following configuration to reproduce the issue:
RestAssured.config = RestAssured.config().connectionConfig(new ConnectionConfig().closeIdleConnectionsAfterEachResponse());
RequestSpecification request = given().relaxedHTTPSValidation()
.contentType(Constants.XML_CONTENT_TYPE)
.auth().basic("usr",
"pass");
request .contentType("application/json");
request.accept("application/json");
request.body(...);
request.when().post(restURL).then().extract().response().asString();
The asString() call throws exception:
java.net.SocketException: Socket is closed
at sun.security.ssl.SSLSocketImpl.checkEOF(SSLSocketImpl.java:1520)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:95)
at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160)
at org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84)
at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273)
at org.apache.http.impl.conn.LoggingSessionInputBuffer.readLine(LoggingSessionInputBuffer.java:116)
at org.apache.http.impl.io.ChunkedInputStream.getChunkSize(ChunkedInputStream.java:240)
at org.apache.http.impl.io.ChunkedInputStream.nextChunk(ChunkedInputStream.java:206)
at org.apache.http.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:169)
at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:238)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158)
at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:117)
at org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:137)
at org.apache.http.conn.EofSensorInputStream$read.call(Unknown Source)
at com.jayway.restassured.internal.RestAssuredResponseOptionsGroovyImpl.convertStreamToByteArray(RestAssuredResponseOptionsGroovyImpl.groovy:430)
at sun.reflect.GeneratedMethodAccessor158.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite$StaticMetaMethodSiteNoUnwrapNoCoerce.invoke(StaticMetaMethodSite.java:151)
at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.callStatic(StaticMetaMethodSite.java:102)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:206)
at com.jayway.restassured.internal.RestAssuredResponseOptionsGroovyImpl.charsetToString(RestAssuredResponseOptionsGroovyImpl.groovy:482)
at com.jayway.restassured.internal.RestAssuredResponseOptionsGroovyImpl$charsetToString$3.callCurrent(Unknown Source)
at com.jayway.restassured.internal.RestAssuredResponseOptionsGroovyImpl.asString(RestAssuredResponseOptionsGroovyImpl.groovy:170)
at com.jayway.restassured.internal.RestAssuredResponseOptionsGroovyImpl.asString(RestAssuredResponseOptionsGroovyImpl.groovy:166)
at com.jayway.restassured.internal.RestAssuredResponseOptionsImpl.asString(RestAssuredResponseOptionsImpl.java:194)
This happens only with json. application/xml is deserialized correctly.
Seems like the socket is closed prematurely.
Please investigate

Hmm sounds very strange, never seen anything like it. It's extremely hard for me to know what's going on unless I can reproduce it. I don't suppose you can give me any guidance on how I can do that?

Hi,
I made a dummy project https://github.com/DarinVenkov/rest-assured-dummy with a simple service deployed on a fresh Apache Tomcat 8.0.30 and a client with JUnit tests to try to reproduce the use case.
The project is bare bones and doesn't give the exact same stack trace but it is giving an org.apache.http.ConnectionClosedException exception after trying to get the response body when using the closeIdleConnectionsAfterEachResponse configuration. And I'm getting it both with xml and json. There are also tests without the configuration and they don't fail.
How can we consume the response bodies after the connections have been closed. It's necessary for the connections to close and the response to be consumable even after that. If there is another way to accomplish that or if there isn't please look into the issue.

Thanks a lot for taking the time to create this project, I'll try to look into it. I only have 15 minutes now until spouse and kid gets home so I'm not sure I'll make it today :)

How do I actually run the service? I can't do mvn jetty:run? I'm not using Eclipse (I'm an intellij user)

I added the Maven jetty plugin and then it worked.

Hmm so when I change the URL to be http://localhost:8080/rest/dummy/person (which is the URL that works when I start it with Jetty) only ClosedConnectionsTestJson fails. But it fails with:
org.apache.http.MalformedChunkCodingException: CRLF expected at end of chunk

	at org.apache.http.impl.io.ChunkedInputStream.getChunkSize(ChunkedInputStream.java:255)
	at org.apache.http.impl.io.ChunkedInputStream.nextChunk(ChunkedInputStream.java:227)
	at org.apache.http.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:186)
	at org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:137)
	at org.apache.http.conn.EofSensorInputStream$read.call(Unknown Source)
	at com.jayway.restassured.internal.RestAssuredResponseOptionsGroovyImpl.convertStreamToByteArray(RestAssuredResponseOptionsGroovyImpl.groovy:430)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
	at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite$StaticMetaMethodSiteNoUnwrapNoCoerce.invoke(StaticMetaMethodSite.java:151)
	at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.callStatic(StaticMetaMethodSite.java:102)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:56)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:194)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:206)

If I remove  request.config(RestAssured.config().connectionConfig(new ConnectionConfig().closeIdleConnectionsAfterEachResponse())); then it also works. Why would you like to configure RA to closeIdleConnectionsAfterEachResponse?

Also if I change to request.config(RestAssured.config().connectionConfig(new ConnectionConfig().closeIdleConnectionsAfterEachResponseAfter(10, TimeUnit.MILLISECONDS))); it works. It seems like the server is returning chunked content and it's not safe to use closeIdleConnectionsAfterEachResponse  when using chunked content (see javadoc). Perhaps the javadocs should be improved though.. The documentation also says this:

However if you're downloading (especially large amounts of) chunked data you must not close connections after each response.

I'm going to close the issue for now. We can continue the discussion if you like and tell me if you think I should reopen the issue.

@johanhaleby I think you underestimated the severity of that issue. I take full responsibility for not explaining the problem better :)
This bug is REAL and very critical.
You see, a real world continuous integration environment often would contain several hundred or even thousands of test cases. These test cases will usually run in a complicated VM/docker infrastructure, on build machines coordinated by Jenkins.
Such complex infrastructures are actually very common in the enterprise world.
And in order for such infrastructure to operate smoothly and stable, it MUST NOT have any resource leaks. And this is exactly why I opened this issue - rest-assured is introducing socket leackages into our environment.
The problem is that after each test case:
(request.when().post(restURL).then().extract().response()....)
... a new socket is being open. This socket is then never closed, unless one explicitly specifies the closeIdleConnectionsAfterEachResponse() configuration. You can see that for yourself - just open TCPView or any other TCP sniffer and invoke several hundred requests using rest-assured. You will notice hundreds of sockets being opened all at once and then never closed.
So we decided to use the closeIdleConnectionsAfterEachResponse() config in order to properly clean up the connection state after each test.
We identified three problems with that:
1] If you set this option globally:
RestAssured.config = config().connectionConfig(new ConnectionConfig().closeIdleConnectionsAfterEachResponse());
... it doesn't even work. The sockets are not getting closed after each response, even though the configuration is there. Again, you can see this for yourself using TCPView.
2] If you set this option "per configuration" like that:
request.config(RestAssured.config().connectionConfig(new ConnectionConfig().closeIdleConnectionsAfterEachResponse()))
... it does close the sockets, but if the accept header contains "application/json" then the sockets are being closed prematurely, before the last chunk of information arrives.
3] The closeIdleConnectionsAfterEachResponseAfter(...) method does not work at all.
The time out is not even used for anything and the sockets again get closed prematurely.
So we end up in a situation where either all sockets will never get closed, or they will all get closed prematurely. As I said, in my opinion this makes the rest-assured api unusable. At least for us this is a blocker.
So please have a look into this.

Hi, I'm the lead maintainer of the integration test platform @mdzhigarov talked about. I took a look at where the connections should probably be closed and why they aren't. Here's my theory:
RequestSpecificationImpl is using HttpEntity.consumeContent, which is deprecated and doesn't provide a default implementation, in the finally block of doRequest. I think since the responses we are getting should contain InputStreamEntities which are relying on the default implementation.
For testing if I'm right, I'll replace the call to getEntity with a different stream consumptions. I'll submit a PR once I've got a working solution.

Sorry for not getting back on this earlier, I've been so busy :(
@oxygen0211 If you can find a way to get this working it would be great. Really appreciate your effort in tracking this down.

@johanhaleby sure, no problem. We have a big interest in getting this up and running for testing rest services for our products.
If my theory is right, it should just be switching to EntityUtils for consuming the entity. I'm just dealing with some hickups in the groovy parts of the maven build at the moment before being able to verify this.

If you're using intellij you should just be able to open the pom.xml and the project should build. If you're using Eclipse I have no clue :)

I'm using eclipse, I guess that makes it a bit complicated, but in the meantime, tests are running, so we'll see if my fix (and what I could build) is sufficient :-)

With PR #639, I couldn't reproduce our problems anymore

I've merged the pull request and published a new snapshot. Please try it out by depending on version 2.8.1-SNAPSHOT after having added the following maven repo:
<repositories>
        <repository>
            <id>sonatype</id>
            <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
            <snapshots />
        </repository>
</repositories>

Thanks for your help

Sorry for letting you wait, but I didn't come to test the SNAPSHOT earlier. Looks good so far, couldn't reproduce the problem. Is there a plan when the 2.8.1 release will be available?

Probably in a few weeks. There are some other issues I'd like to sort out first.

It should be safe to use the snapshot though.

Thanks for the info. Using snapshots in production is prohibited by our company policy to make sure we won't suddenly get changed behavior due to an updated snapshot, so I'm thinking more of building an internal version including the change until you have released it officially.
Anyways, thanks for your help and the fast handling of the issue. I consider this as fixed (at least until I'm proven wrong :-)).

Little update on this one:
Although at first it looked like the problem was solved by my PR, we are still experiencing hanging connections with a growing base of tests. My guess is that there are similar places in the code to what I fixed that are not working smoothely with the refactorings introduced to httpclient a while ago.
Unfortunately, these problems are blockers for using rest-assured in our test env. We had to find another solution, so from our side, there is no urgency to fix this. However, I would love to see these problems solved since rest-assured provides much value for API developers and I think that it would find use in other places of our company if reliable enough.

Ok that's bad news :( Unfortunately it'll be extremely hard for me to track this down since I don't have a setup like yours. If this is to be solved anytime soon I will need your help of tracking it down.

@johanhaleby
This is actually quite easy to reproduce. We already provided for you a dummy project:
https://github.com/DarinVenkov/rest-assured-dummy
I just updated the project a bit - it now includes jetty so you'll be able to start the service in a few seconds. The junit tests in the client are also updated.
What you need to do:

run mvn jetty:run in the service project in order to start the service
run mvn test in the client project

You will notice two junit tests in the client project - one is using content-type application/xml, the other - application/json.
The latter is failing with:
org.apache.http.MalformedChunkCodingException: CRLF expected at end of chunk
at org.apache.http.impl.io.ChunkedInputStream.getChunkSize(ChunkedInputStream.java:255)
at org.apache.http.impl.io.ChunkedInputStream.nextChunk(ChunkedInputStream.java:227)
at org.apache.http.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:186)
at org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:137)
at org.apache.http.conn.EofSensorInputStream$read.call(Unknown Source)
...

IMHO this is a bug which needs addressing.
We need the closeIdleConnectionsAfterEachResponse option because we make a lot of consecutive requests with small response bodies. If we omit this option, suddenly hundreds of inet sockets are being opened in a small window of time. These sockets then are never closed (they stay in CLOSE_WAIT state. See: http://blogs.technet.com/b/janelewis/archive/2010/03/09/explaining-close-wait.aspx for more info)
Setting closeIdleConnectionsAfterEachResponseAfter(1000, TimeUnit.MILLISECONDS)) in the configuration doesn't solve the issue either.

@mdzhigarov you can reuse the http clients, not need close them.
System.setProperty("http.maxConnections","100");
config = config().httpClient(httpClientConfig().reuseHttpClientInstance().httpClientFactory(
    () -> new SystemDefaultHttpClient()
));

I made a fork with close() method added to Response object as a possible workaround.
close() method calls connectionManager.shutdown() under the hood.
https://github.com/gpor89/rest-assured

@johanhaleby Can this issue be reopened this still seems to be an ongoing problem.
These are my global settings
    RestAssured.baseURI = "http://" + System.getProperty("API_HOST");
    RestAssured.port = Integer.parseInt(System.getProperty("API_PORT", "8080"));
    RestAssured.config = RestAssured.config()
        .connectionConfig(connectionConfig().closeIdleConnectionsAfterEachResponse())
        .httpClient(httpClientConfig().reuseHttpClientInstance());

I make two POST's in the same test one after the other, their ordering is not important I have switched them around and still get the same error. I also tried putting Thread.sleep(1000) between them but no change.
    // Create Extension
    given()
        .contentType(ContentType.JSON)
        .accept(ContentType.JSON)
        .body(ext)
        .when()
        .post("/extension");

    // Create Customer
    String customerId = given()
        .contentType(ContentType.JSON)
        .accept(ContentType.JSON)
        .body(cust)
        .when()
        .post("/")
        .then()
        .statusCode(201)
        .extract()
        .header("Location");

I have the wire logging turned on and i can verify that the data is created on the server for both requests. It looks like the connection is closed but not released.
    00:19:35.298 [Test worker] DEBUG org.apache.http.impl.client.DefaultHttpClient - Connection can be kept alive indefinitely
    00:19:35.313 [Test worker] DEBUG io.restassured.internal.RequestSpecificationImpl$RestAssuredHttpBuilder - Parsing response as: application/json
    00:19:35.313 [Test worker] DEBUG io.restassured.internal.RequestSpecificationImpl$RestAssuredHttpBuilder - Parsed data to instance of: class org.apache.http.conn.EofSensorInputStream
    00:19:35.338 [Test worker] DEBUG org.apache.http.impl.conn.DefaultClientConnection - Connection <IP_ADDRESS>:54724<-><IP_ADDRESS>:9080 closed
    00:19:36.359 [Test worker] DEBUG org.apache.http.impl.conn.BasicClientConnectionManager - Get connection for route {}->http://localhost:9080

Here is the top of stacktrace but it doesn't line up with master
    java.lang.IllegalStateException: Invalid use of BasicClientConnManager: connection still allocated.
    Make sure to release the connection before allocating another one.
        at org.apache.http.util.Asserts.check(Asserts.java:34)
        at org.apache.http.impl.conn.BasicClientConnectionManager.getConnection(BasicClientConnectionManager.java:166)
        at org.apache.http.impl.conn.BasicClientConnectionManager$1.getConnection(BasicClientConnectionManager.java:148)
        at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:424)
        at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:884)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
        at org.apache.http.client.HttpClient$execute$0.call(Unknown Source)
        at io.restassured.internal.RequestSpecificationImpl$RestAssuredHttpBuilder.doRequest(RequestSpecificationImpl.groovy:2035)

I'm having trouble with the build, getting the itests to pass. This is the error i'm getting from the itests on master
Failed tests:   using_statically_configured_proxy_defined_using_string_uri_without_port(io.restassured.itest.java.ProxyITest):

I have also run into this issue because our tests opens so many connections that we started running out of ports on our workstations. I solved it by adding a way to explicitly close the connection as previously shown by @gpor89 . So my suggestion for a (temporary) solution would be to simply add a close() method to the Response.

but why we need to close the connection, the connection can be reused for subsequent requests. The right fix is to close the stream after stream read is done

RestAssured.reset(); solved for me ...

Hi everyone!
Just a little hint on the issue:
After so many days of trying, we found out, that a problem is with void endpoints, no matter what is your http and connection config related to closing idle connections. If you call endpoints with void return type, the connections won't be closed, the buffer will slowly become full, and the following exception will be thrown: java.net.SocketException: No buffer space available (maximum connections reached?): connect
(The default buffer size is 8192, which can be changed by creating a new org.apache.http.config.ConnectionConfig instance with given buffer size and setting it in RestAssured config. However, it is not a solution.)
In our case, we modified the API endpoint to return the id of the inserted object instead of void, so the problem is gone. We use reuseHttpClientInstance() config in order not to have growing number of TIME_WAIT connections, which would also cause the above exception to be thrown.
I hope this observation will help to solve the problem in RestAssured soon, or at least will help you to do a workaround.


Games Page

Edit - 5/12/2022: Updated issue to remove ability for users to edit their games.
Create a Games page for logged in users providing them with the following:

[x] ability to add a new game to this user's list of games
[x] list of any games found in database exclusively added by this user where each game item has:

[x] cover art image displayed
[x] name of game displayed
[x] user's total play count
[x] user's total win count (or win percentage)
[x] ability to view more details for this game:

[x] present game statistics in the style of the Overall Stats page
[ ] ability to edit details for this game via:

[ ] updating name or cover art image
[x] incrementing scores

[x] ability to delete this game

Implemented game list to display win ratios and play count stats for each of the user's games. Also implemented ability to view the specific stats for an individual game.


Add option to configure custom resolver

resolves #84
Utilizes the service manager to provide an implementation for either basic and/or digest authentication methods, overriding the default ApacheResolver and FileResolver.

closed with merge https://github.com/zfcampus/zf-mvc-auth/commit/0b56922a9a00b17facea4316d3d504dc1d0bdda2


Ability to move scaled down image

Is your feature request related to a problem? Please describe.
PhotoView allows to scale down image and its very useful. But unfortunately scaled down image can be only rotated. It is not possible to move it to change its position. Current implementation supports move only on zoomed image.
Describe the solution you'd like
Support an ability to move scaled down image.

I would also want to have this please.

Yes I'm also into this. 👍

Yes I'm also into this. 👍

I am also looking for this...

Hi Folks, looks like our problem was solved back to July 2021 :) When a new property enablePanAlways: true was added in the release 0.12.0!
Now we can rotate and move the image even when it is downscaled 👍
Closing this feature request as implemented. Well done!


Documentation broken script links to gitbook from enterprise environments

Documentation is broken inside enterprises which block gitbook.com
For example
https://docs.pinot.apache.org/basics/getting-started/running-pinot-locally
All tabs are broken I.e. clicking download the release tab doesn't update to display the tab.
May may sense to host the scripts and images on the same domain as the documentation.

We were not able to do that unfortunately.. ASF did not allow it.

Docs seem to work better these days.  Closing.


⚠ Bofrost.fr has degraded performance

In 0fb6669, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1466 ms

Resolved: Bofrost.fr performance has improved in b47f766 after 15 minutes.


pull request for e2e test at 01/05/2017 02:45:12

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Batch 1 of Grant Cmdlets Updates

Adding Teams Updates for recently modernized:
Grant-CsApplicationAccessPolicy
Grant-CsBroadcastMeetingPolicy
Grant-CsCallingLineIdentity
Grant-CsClientPolicy
Grant-CsCloudMeetingPolicy
Grant-CsExternalAccessPolicy
Grant-CsExternalUserCommunicationPolicy
Grant-CsGraphPolicy
Batch 1 of 4

Docs Build status updates of commit a0bdf5b:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

skype/skype-ps/skype/Grant-CsApplicationAccessPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsBroadcastMeetingPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsCallingLineIdentity.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsClientPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsCloudMeetingPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsExternalAccessPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsExternalUserCommunicationPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsGraphPolicy.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

@tseward

@tiburd Please merge this PR. Thanks

Docs Build status updates of commit 0161c83:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

skype/skype-ps/skype/Grant-CsApplicationAccessPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsBroadcastMeetingPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsCallingLineIdentity.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsClientPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsCloudMeetingPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsExternalAccessPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsExternalUserCommunicationPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsGraphPolicy.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

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

File
Status
Preview URL
Details

skype/skype-ps/skype/Grant-CsApplicationAccessPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsBroadcastMeetingPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsCallingLineIdentity.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsClientPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsCloudMeetingPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsExternalAccessPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsExternalUserCommunicationPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Grant-CsGraphPolicy.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


feat: Add Graph Connector sample app

Demo:

Architecture:

Close this PR. Will create a new one targeting GA branch


[red-knot] Update source root path for benchmark

Summary
I guess the existing path is correct but we currently don't have the ability to detect packages considering the below TODO:
https://github.com/astral-sh/ruff/blob/3eac2cae847770e28f87bef4e01faab71f95b201/crates/red_knot_workspace/src/workspace/metadata.rs#L33-L34
This means that the benchmark code considers /src as the package while /src/tomllib is the actual package. This means it's unable to resolve relative imports.
If this is correct, I can validate and update the expected diagnostics in the benchmark code.

Closing this as it's an expected behavior.


Fails to compile with ROCm 6.0

Hi!
Either something has recently changed here or ROCm broke something, but exllamav2 breaks on ROCm 6.0 for me:
log.txt
Thanks!

Same errors with ROCm 5.6:
log.txt

This is very odd. The prebuilt wheels compiled fine for ROCm 5.6?

Yes. I only have 5.6 in Docker right now though, so there may actually be other environmental factors.

how to check if it is using ROCm or not ? Please help

how to check if it is using ROCm or not ? Please help

Create a question in the discussions and don't hijack other issues, thanks

So I've been tinkering a bit with an AMD GPU now, and I can confirm the prebuilt wheel doesn't work with Torch 2.2. The basic requirements for building from source are:

Install the ROCm HIP SDK package (rocm-hip-sdk in Arch, I think the same name in Ubuntu)
Install the ROCm version of Torch: pip3 install torch --index-url https://download.pytorch.org/whl/rocm5.7
git clone the repo
pip install . in the exllamav2 directory

I'll bump the Torch requirement to 2.2.x for the next release, as soon as I've had a little time to try it out.

@hemangjoshi37a Huh?

I'll bump the Torch requirement to 2.2.x for the next release, as soon as I've had a little time to try it out.

this

Well it's not changing the requirement that's the issue, that takes ten seconds. It's testing that everything actually works with Torch 2.2 first, since there are obviously some breaking changes in at least the C++ extension features.

So I've been tinkering a bit with an AMD GPU now, and I can confirm the prebuilt wheel doesn't work with Torch 2.2. The basic requirements for building from source are:
* Install the ROCm HIP SDK package (`rocm-hip-sdk` in Arch, I think the same name in Ubuntu)

* Install the ROCm version of Torch: `pip3 install torch --index-url https://download.pytorch.org/whl/rocm5.7`

* `git clone` the repo

* `pip install .` in the exllamav2 directory

I'll bump the Torch requirement to 2.2.x for the next release, as soon as I've had a little time to try it out.

Doing so on my Fedora resulted in CUDA_HOME environment variable is not set.
Have you done something specific related to HIP to makes it compile @turboderp ?

I literally only did those four steps, on a brand new install of Manjaro. Is it possible you have a CUDA version of Torch installed? Perhaps you could try in a fresh venv?

In fact I went a little bit further (and no I got the 2.2.2+rocm5.7 torch version).
But I got inspired by your Github CI.
So I have exposed the following env vars:
USE_ROCM=1
ROCM_VERSION=5.7
ROCM_PATH=/usr/bin

Tho I am not sure about the last one cause the HIP package provided by Fedora differs a little bit compared to the one provided by Arch, but I can see a hipcc there so..
But now I'm facing the following issue: hip/hip_runtime_api.h: No such file or directory
I did search it with find / -iname *hip_runtime_api.h* 2>/dev/null
And I have this result:
/var/mnt/data/Projects/Misc/AI/tools/exllamav2/.venv/lib/python3.11/site-packages/triton/third_party/hip/include/hip/nvcc_detail/nvidia_hip_runtime_api.h
/var/mnt/data/Projects/Misc/AI/tools/exllamav2/.venv/lib/python3.11/site-packages/triton/third_party/hip/include/hip/hip_runtime_api.h
/var/mnt/data/Projects/Misc/AI/tools/exllamav2/.venv/lib/python3.11/site-packages/triton/third_party/hip/include/thrust/system/hip/detail/guarded_hip_runtime_api.h

So to me it should be ok..


Reference a true release of interact.js in bower.json (fixes #2)

@jamesdixon There is a bug with the cursor on click. And it's only fixed in the unstable branch.
Please see this https://github.com/taye/interact.js/issues/364

@marzubov thanks for sharing -- I'll close this PR.


Install Error

I tried using:
https://github.com/VanishsVault/apsjournal/releases/latest/download/module.json
I got the following:
Error: Unable to load valid module manifest data from "https://github.com/VanishsVault/apsjournal/releases/latest/download/module.json"
The requested manifest at "https://github.com/VanishsVault/apsjournal/releases/latest/download/module.json" did not provide module manifest data.
at Module.installPackage (file:///home/hcfoundryuser/foundryv10/resources/app/dist/packages/views.mjs:1:1620)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async SetupView.handlePost (file:///home/hcfoundryuser/foundryv10/resources/app/dist/server/views/setup.mjs:1:1980)

Yeah, in order to use the module, you'll have to download the package and install it manually. I don't have this setup for proper distribution yet, Sorry.

ok no worries I will do that

I have it installed an so far so good.  I tried a few of the layouts and it looks good, and the HTML looks right.

@HippyCraig Here is the correct repo. ;)


Panic during plan

Not sure if this could be user error? This is on v0.3.22 v0.3.23 and we've recently updated from v0.2.0. I've moved back to v0.3.10 and don't see the same error there. I've confirmed the error on all versions from v0.3.18-0.3.23.
Lock provider has been created successfully
Using GitHub.
GitHub context parsed successfully
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x14e25e8]

goroutine 1 [running]:
github.com/diggerhq/digger/cli/pkg/digger.UpdateStatusComment({0xc000590c00?, 0xe, 0x35ff0a0?}, 0x0?, {0x25947d0, 0xc000809830}, 0xffffffffffffffff?)
	/home/runner/work/digger/digger/cli/pkg/digger/digger.go:169 +0xe8
main.gitHubCI({0x25876c8, 0xc00007a0a0}, {0x2586cd8, 0xc000b10990}, {0x2586d08, 0xc000b18cf0}, {0x2574440?, 0xc000b22000})
	/home/runner/work/digger/digger/cli/cmd/digger/main.go:128 +0xcd1
main.glob..func2(0xc0000aa200?, {0x1f47aa6?, 0x4?, 0x1f47aaa?})
	/home/runner/work/digger/digger/cli/cmd/digger/default.go:23 +0x205
github.com/spf13/cobra.(*Command).execute(0x35d1980, {0x3639ca0, 0x0, 0x0})
	/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:987 +0xaa3
github.com/spf13/cobra.(*Command).ExecuteC(0x35d2220)
	/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1115 +0x3ff
github.com/spf13/cobra.(*Command).Execute(...)
	/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1039
main.main()
	/home/runner/work/digger/digger/cli/cmd/digger/main.go:815 +0xf4
Error: Process completed with exit code 2.

Hey @macbutch thanks for reporting! This error is related to the thread #1112 if you could try to run digger on v0.3.24 or v0.3.25 we will should be able to see a clearer error message of what is causing this instead of the nil exception 🙏

Thanks, @motatoes. Here's the output with v0.3.25:
Error while fetching user teams for CI service: failed to list github teams: GET https://api.github.com/orgs/identiv/teams: 403 Resource not accessible by integration []
WARNING: teams failed to be fetched, passing an empty list instead for access policy checks
DEBUG: passing the following input policy: map[action:digger plan approvals:[] organisation:identiv planPolicyViolations:[] project:**snip** teams:[] user:macbutch] ||| text:
package digger
default allow = true
allow = (count(input.planPolicyViolations) == 0)
Lock identiv/**snip**
Lock result: false
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x14e1f55]
goroutine 1 [running]:
github.com/diggerhq/digger/cli/pkg/digger.RunJobs({0xc000bcca90, 0x1, 0x2?}, {0x2594950, 0xc000624120}, {0x25746e0, 0xc000624120}, {0x2587848, 0xc00007c530}, {0x257fe68, ...}, ...)
	/home/runner/work/digger/digger/cli/pkg/digger/digger.go:118 +0xab5
main.gitHubCI({0x2587848, 0xc00007c530}, {0x2586e58, 0xc000b53230}, {0x2586e88, 0xc000b5ebd0}, {0x25745c0?, 0xc000607320})
	/home/runner/work/digger/digger/cli/cmd/digger/main.go:327 +0x2419
main.glob..func2(0xc0000c1400?, {0x1f47b06?, 0x4?, 0x1f47b0a?})
	/home/runner/work/digger/digger/cli/cmd/digger/default.go:23 +0x205
github.com/spf13/cobra.(*Command).execute(0x35d2980, {0x363aca0, 0x0, 0x0})
	/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:987 +0xaa3
github.com/spf13/cobra.(*Command).ExecuteC(0x35d3220)
	/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1115 +0x3ff
github.com/spf13/cobra.(*Command).Execute(...)
	/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1039
main.main()
	/home/runner/work/digger/digger/cli/cmd/digger/main.go:819 +0xf4

I've redacted the projected name. Let me know if you need it, I'll share some other way.

Thanks Mark for this report, that's interesting, I am investigating this now

reproduced and verified that its happening when plan is occuring for an already locked project. Working on the fix to handle it

This issue should be repaired in v0.3.26 please reopen if still experiencing! @macbutch


pipelines/go: gobump: add new skip-initial-tidy

cc @smoser i guess you wanted this the other day?


Proposal: what to do with tableKey, namespace, name

I talk about tables because I think what works for them will work for systems, tables are more prevalent in the config, and systems have no sync to worry about. But u can see them both in the examples.
The examples are slightly contrived to show what happens when key and name differ
Current state
mudConfig tables have

Record key which represents the library name. It's used for most client stuff
namespace and name, which are used for on-chain tableId
tableId which is composed of namespace+name. It's used for all on-chain stuff

namespace is currently global (but https://github.com/latticexyz/mud/pull/971 aims to change it)
Record key and name are sometimes used interchangeably (like in store-cache), but they can currently be different, which can lead to problems.
export default mudConfig({
  namespace: "",
  tables: {
    CounterTableN: {
      schema: "uint32",
    },
    // Until namespace overrides, CounterTableNamespaced must be manually deployed in PostDeploy
  },
  systems: {
    IncrementSystem: {
      name: "Increment",
      openAccess: true,
    },
  },
  excludeSystems: [
    // Until namespace overrides, this system must be manually deployed in PostDeploy
    "IncrementNamespacedSystem",
  ],
});

Solution 1
Keep table key and name separate and make the separation stronger

Explicitly name table key as tableKey, and table name as name
Never use them interchangeably, because they can differ
Most client things would use tableKey, but some (like subscriptions) would still have name around, since sync works with the whole world and not just what's in the config
Per-table namespace overrides just work (since namespace+name has to be unique, not namespace+tableKey, you won't get ambiguity even with an existing world)
All on-chain things use name as before

export default mudConfig({
  namespace: "",
  tables: {
    CounterTableN: "uint32",
    CounterTableNamespaced: {
      // name can't actually be specified for tables, but it will be effectively different from tableKey because <=16 length limit
      // name: "CounterTableN"
      namespace: "namespace",
      schema: "uint32",
    }
  },
  systems: {
    IncrementSystem: {
      name: "Increment",
      openAccess: true,
    },
    IncrementNamespacedSystem: {
      namespace: "namespace",
      name: "Increment",
      openAccess: true,
    }
  },
});

Solution 2
Unify table key and name

Remove name from table config
name and tableKey can not differ, so have zod check that tableKey.length <= 16
Everything uses name, which is also tableKey
Per-table namespace overrides must be made to work , see 2.1 and 2.2
All on-chain things use name as before

Sub-solution 2.1
Keep only 1 root namespace

No per-table namespace overrides, you must make a separate config for a separate namespace
We have to allow multiple mud.config in one package (this is a separate issue, which would particularly affect cli and client)

// first config (there're 2)
export default mudConfig({
  namespace: "",
  tables: {
    CounterTableN: "uint32",
  },
  systems: {
    Increment: {
      openAccess: true,
    },
  },
});

// second config (there're 2)
export default mudConfig({
  namespace: "namespace",
  tables: {
    CounterTableN: "uint32",
  },
  systems: {
    Increment: {
      openAccess: true,
    }
  },
});

Sub-solution 2.2
Make tables config option grouped by namespace

Rather than per-table namespace, we get per-namespace table
This does not depend on having multiple mud.config in one package

export default mudConfig({
  tables: {
    "": {
      CounterTableN: "uint32",
    },
    "namespace": {
      CounterTableN: "uint32",
    }
  },
  systems: {
    "": {
      Increment: {
        openAccess: true,
      },
    },
    "namespace": {
      Increment: {
        openAccess: true,
      },
    },
  },
});

1 seems like the simplest option that mostly preserves the status quo
2.1 strongly depends on a separate issue that's probably bigger than this one, so hard to say
2.2 I kinda like this, but for both 2.1 and 2.2 being restricted to short file names feels bad
I currently prefer 1 but may have missed something and curious about your opinions

One thought i'd like to throw in the pot: eventually we should have something that allows devs to "download" a mud config of an existing world (ie mud config --worldAddress 0x1234 -> generates a mud.config.ts with all the tables and systems of that world). This would improve the dev ex for extending existing worlds, because now our client libs can have strong types based on the config of the existing world.
With this in mind we'll have to find a way to support non-unique names for tables and systems. With option 1 we'd have to somehow generate a unique name for the table key, probably something like concatenating namespace and name. What I don't like about this approach is that it's harder to explain what the difference between key and name is, and what each are used for.
My personal favorite is approach 2.2, or slight variation (let's call it 2.3, see below), because it maps the concept of namespaces and names well to the datastructure being used (namespaces have to be unique, names have to be unique within a namespace).
Approach 2.3:
export default mudConfig({
  namespaces: {
    "": {
      tables: {
        CounterTableN: "uint32",
      },
      systems: {
        Increment: {
          openAccess: true
        }
      }
    },
    "namespace": {
      tables: {
        CounterTableN: "uint32"
      },
      systems: {
        Increment: {
          openAccess: true
        }
      }
    }
  }
});

Potentially we could also allow a top level "tables" / "systems" key for the root namespace, and only nest in the namespaces key for non-root namespaces, but not sure about that yet.
One nice side effect of approach 2.3 is it's possible to use the table schema shortcuts also for namespaced tables.

Very into the idea of 2.3, with:

explicit parity of table key + table name (including 16 char enforcement of both name + namespace)
namespace-grouped tables/systems (helps with code organization/visualization)

Good points, especially about the downloading - didn't think of that.
btw fun fact about 2.2 is I started writing it like 2.3, but then changed midway because of my status quo bias here.
I agree with 2.3, and since we seem to have consensus already I can make a PR some time soon, wanna deal with a few other things 1st though

Update: new config has type support for multiple namespaces, but not enabled yet because of codegen limitations (tables can have the same name in different namespaces, which would lead to file name conflicts). Codegen support is being added in #2840

done in https://github.com/latticexyz/mud/pull/2968


Updated pagination part in the Quick Example doc

Hi!
I was trying the sample code in the Quick Example documentation, and the sample code throws the following error:
raise validation_error
pydantic.error_wrappers.ValidationError: 1 validation error for NinjaResponseSchema
response -> results
  field required (type=value_error.missing)

Looking further into the documentation, it seems that the pagination.paginate decorator no longer works well with List[UserSchema], so I modified it to pagination.PaginatedResponseSchema[UserSchema] and the decorator to pagination.paginate(pagination.PageNumberPaginationExtra, page_size=50) and it worked.
I have updated the docs accordingly, I hope you find this helpful.

Thanks @marcjermainepontiveros-sun. I will have do more refactor on that example later.


Error while running "pip install awscli"

When running the command: pip install awscli, I see the following errors, which did not appear before while running docker container:
$ pip install awscli
Collecting awscli
  Downloading https://files.pythonhosted.org/packages/b5/dd/84d32d2275ea16daf09d561858dd0e615c56c9e8afb2e9b42d02bc45e417/awscli-1.15.51-py2.py3-none-any.whl (1.3MB)
Collecting PyYAML<=3.12,>=3.10 (from awscli)
  Downloading https://files.pythonhosted.org/packages/4a/85/db5a2df477072b2902b0eb892feb37d88ac635d36245a72a6a69b23b383a/PyYAML-3.12.tar.gz (253kB)
Collecting s3transfer<0.2.0,>=0.1.12 (from awscli)
  Downloading https://files.pythonhosted.org/packages/d7/14/2a0004d487464d120c9fb85313a75cd3d71a7506955be458eebfe19a6b1d/s3transfer-0.1.13-py2.py3-none-any.whl (59kB)
Collecting colorama<=0.3.9,>=0.2.5 (from awscli)
  Downloading https://files.pythonhosted.org/packages/db/c8/7dcf9dbcb22429512708fe3a547f8b6101c0d02137acbd892505aee57adf/colorama-0.3.9-py2.py3-none-any.whl
Collecting docutils>=0.10 (from awscli)
  Downloading https://files.pythonhosted.org/packages/36/fa/08e9e6e0e3cbd1d362c3bbee8d01d0aedb2155c4ac112b19ef3cae8eed8d/docutils-0.14-py3-none-any.whl (543kB)
Collecting botocore==1.10.50 (from awscli)
  Downloading https://files.pythonhosted.org/packages/d5/9f/2e701a365b5ff0e8b664d6c393f3c61c20e52bb5148bbc2e27d737b890db/botocore-1.10.50-py2.py3-none-any.whl (4.4MB)
Collecting rsa<=3.5.0,>=3.1.2 (from awscli)
  Downloading https://files.pythonhosted.org/packages/e1/ae/baedc9cb175552e95f3395c43055a6a5e125ae4d48a1d7a924baca83e92e/rsa-3.4.2-py2.py3-none-any.whl (46kB)
Collecting python-dateutil<3.0.0,>=2.1; python_version >= "2.7" (from botocore==1.10.50->awscli)
  Downloading https://files.pythonhosted.org/packages/cf/f5/af2b09c957ace60dcfac112b669c45c8c97e32f94aa8b56da4c6d1682825/python_dateutil-2.7.3-py2.py3-none-any.whl (211kB)
Collecting jmespath<1.0.0,>=0.7.1 (from botocore==1.10.50->awscli)
  Downloading https://files.pythonhosted.org/packages/b7/31/05c8d001f7f87f0f07289a5fc0fc3832e9a57f2dbd4d3b0fee70e0d51365/jmespath-0.9.3-py2.py3-none-any.whl
Collecting pyasn1>=0.1.3 (from rsa<=3.5.0,>=3.1.2->awscli)
  Downloading https://files.pythonhosted.org/packages/a0/70/2c27740f08e477499ce19eefe05dbcae6f19fdc49e9e82ce4768be0643b9/pyasn1-0.4.3-py2.py3-none-any.whl (72kB)
Collecting six>=1.5 (from python-dateutil<3.0.0,>=2.1; python_version >= "2.7"->botocore==1.10.50->awscli)
  Downloading https://files.pythonhosted.org/packages/67/4b/141a581104b1f6397bfa78ac9d43d8ad29a7ca43ea90a2d863fe3056e86a/six-1.11.0-py2.py3-none-any.whl
Building wheels for collected packages: PyYAML
  Running setup.py bdist_wheel for PyYAML: started
  Running setup.py bdist_wheel for PyYAML: finished with status 'error'
  Complete output from command /usr/local/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-x88x8998/PyYAML/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d /tmp/pip-wheel-5djwbscu --python-tag cp37:
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build/lib.linux-x86_64-3.7
  creating build/lib.linux-x86_64-3.7/yaml
  copying lib3/yaml/constructor.py -> build/lib.linux-x86_64-3.7/yaml
  copying lib3/yaml/events.py -> build/lib.linux-x86_64-3.7/yaml
  copying lib3/yaml/representer.py -> build/lib.linux-x86_64-3.7/yaml
  copying lib3/yaml/dumper.py -> build/lib.linux-x86_64-3.7/yaml
  copying lib3/yaml/cyaml.py -> build/lib.linux-x86_64-3.7/yaml
  copying lib3/yaml/loader.py -> build/lib.linux-x86_64-3.7/yaml
  copying lib3/yaml/emitter.py -> build/lib.linux-x86_64-3.7/yaml
  copying lib3/yaml/__init__.py -> build/lib.linux-x86_64-3.7/yaml
  copying lib3/yaml/reader.py -> build/lib.linux-x86_64-3.7/yaml
  copying lib3/yaml/parser.py -> build/lib.linux-x86_64-3.7/yaml
  copying lib3/yaml/serializer.py -> build/lib.linux-x86_64-3.7/yaml
  copying lib3/yaml/resolver.py -> build/lib.linux-x86_64-3.7/yaml
  copying lib3/yaml/nodes.py -> build/lib.linux-x86_64-3.7/yaml
  copying lib3/yaml/scanner.py -> build/lib.linux-x86_64-3.7/yaml
  copying lib3/yaml/composer.py -> build/lib.linux-x86_64-3.7/yaml
  copying lib3/yaml/error.py -> build/lib.linux-x86_64-3.7/yaml
  copying lib3/yaml/tokens.py -> build/lib.linux-x86_64-3.7/yaml
  running build_ext
  creating build/temp.linux-x86_64-3.7
  checking if libyaml is compilable
  gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/usr/local/include/python3.7m -c build/temp.linux-x86_64-3.7/check_libyaml.c -o build/temp.linux-x86_64-3.7/check_libyaml.o
  checking if libyaml is linkable
  gcc -pthread build/temp.linux-x86_64-3.7/check_libyaml.o -L/usr/local/lib -lyaml -o build/temp.linux-x86_64-3.7/check_libyaml
  building '_yaml' extension
  creating build/temp.linux-x86_64-3.7/ext
  gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/usr/local/include/python3.7m -c ext/_yaml.c -o build/temp.linux-x86_64-3.7/ext/_yaml.o
  In file included from ext/_yaml.c:271:0:
  ext/_yaml.h:10:0: warning: "PyString_CheckExact" redefined
   #define PyString_CheckExact PyBytes_CheckExact

  ext/_yaml.c:139:0: note: this is the location of the previous definition
     #define PyString_CheckExact          PyUnicode_CheckExact

  ext/_yaml.c: In function ‘__pyx_pf_5_yaml_get_version_string’:
  ext/_yaml.c:1410:17: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
     __pyx_v_value = yaml_get_version_string();
                   ^
  ext/_yaml.c: In function ‘__pyx_pf_5_yaml_7CParser___init__’:
  ext/_yaml.c:2577:52: warning: passing argument 2 of ‘yaml_parser_set_input’ from incompatible pointer type [-Wincompatible-pointer-types]
       yaml_parser_set_input((&__pyx_v_self->parser), __pyx_f_5_yaml_input_handler, ((void *)__pyx_v_self));
                                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:1367:1: note: expected ‘int (*)(void *, unsigned char *, size_t,  size_t *) {aka int (*)(void *, unsigned char *, long unsigned int,  long unsigned int *)}’ but argument is of type ‘int (*)(void *, char *, size_t,  size_t *) {aka int (*)(void *, char *, long unsigned int,  long unsigned int *)}’
   yaml_parser_set_input(yaml_parser_t *parser,
   ^~~~~~~~~~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:79:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/bytesobject.h:87:31: warning: pointer targets in passing argument 2 of ‘yaml_parser_set_input_string’ differ in signedness [-Wpointer-sign]
   #define PyBytes_AS_STRING(op) (assert(PyBytes_Check(op)), \
                                 ^
  ext/_yaml.h:11:29: note: in expansion of macro ‘PyBytes_AS_STRING’
   #define PyString_AS_STRING  PyBytes_AS_STRING
                               ^~~~~~~~~~~~~~~~~
  ext/_yaml.c:2818:59: note: in expansion of macro ‘PyString_AS_STRING’
       yaml_parser_set_input_string((&__pyx_v_self->parser), PyString_AS_STRING(__pyx_v_stream), PyString_GET_SIZE(__pyx_v_stream));
                                                             ^~~~~~~~~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:1341:1: note: expected ‘const unsigned char *’ but argument is of type ‘char *’
   yaml_parser_set_input_string(yaml_parser_t *parser,
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c: In function ‘__pyx_f_5_yaml_7CParser__token_to_object’:
  ext/_yaml.c:4572:38: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
       __pyx_t_2 = PyUnicode_FromString(__pyx_v_token->data.tag_directive.handle); if (unlikely(!__pyx_t_2)) __PYX_ERR(0, 417, __pyx_L1_error)
                                        ^~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:4584:38: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
       __pyx_t_2 = PyUnicode_FromString(__pyx_v_token->data.tag_directive.prefix); if (unlikely(!__pyx_t_2)) __PYX_ERR(0, 418, __pyx_L1_error)
                                        ^~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:5444:38: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
       __pyx_t_2 = PyUnicode_FromString(__pyx_v_token->data.alias.value); if (unlikely(!__pyx_t_2)) __PYX_ERR(0, 448, __pyx_L1_error)
                                        ^~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:5518:38: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
       __pyx_t_2 = PyUnicode_FromString(__pyx_v_token->data.anchor.value); if (unlikely(!__pyx_t_2)) __PYX_ERR(0, 451, __pyx_L1_error)
                                        ^~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:5592:38: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
       __pyx_t_2 = PyUnicode_FromString(__pyx_v_token->data.tag.handle); if (unlikely(!__pyx_t_2)) __PYX_ERR(0, 454, __pyx_L1_error)
                                        ^~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:5604:38: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
       __pyx_t_2 = PyUnicode_FromString(__pyx_v_token->data.tag.suffix); if (unlikely(!__pyx_t_2)) __PYX_ERR(0, 455, __pyx_L1_error)
                                        ^~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:5716:38: warning: pointer targets in passing argument 1 of ‘PyUnicode_DecodeUTF8’ differ in signedness [-Wpointer-sign]
       __pyx_t_2 = PyUnicode_DecodeUTF8(__pyx_v_token->data.scalar.value, __pyx_v_token->data.scalar.length, ((char *)"strict")); if (unlikely(!__pyx_t_2)) __PYX_ERR(0, 460, __pyx_L1_error)
                                        ^~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:1298:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_DecodeUTF8(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c: In function ‘__pyx_f_5_yaml_7CParser__event_to_object’:
  ext/_yaml.c:7424:42: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
           __pyx_t_4 = PyUnicode_FromString(__pyx_v_tag_directive->handle); if (unlikely(!__pyx_t_4)) __PYX_ERR(0, 574, __pyx_L1_error)
                                            ^~~~~~~~~~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:7436:42: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
           __pyx_t_4 = PyUnicode_FromString(__pyx_v_tag_directive->prefix); if (unlikely(!__pyx_t_4)) __PYX_ERR(0, 575, __pyx_L1_error)
                                            ^~~~~~~~~~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:7655:38: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
       __pyx_t_4 = PyUnicode_FromString(__pyx_v_event->data.alias.anchor); if (unlikely(!__pyx_t_4)) __PYX_ERR(0, 586, __pyx_L1_error)
                                        ^~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:7749:40: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
         __pyx_t_4 = PyUnicode_FromString(__pyx_v_event->data.scalar.anchor); if (unlikely(!__pyx_t_4)) __PYX_ERR(0, 591, __pyx_L1_error)
                                          ^~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:7790:40: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
         __pyx_t_4 = PyUnicode_FromString(__pyx_v_event->data.scalar.tag); if (unlikely(!__pyx_t_4)) __PYX_ERR(0, 594, __pyx_L1_error)
                                          ^~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:7811:38: warning: pointer targets in passing argument 1 of ‘PyUnicode_DecodeUTF8’ differ in signedness [-Wpointer-sign]
       __pyx_t_4 = PyUnicode_DecodeUTF8(__pyx_v_event->data.scalar.value, __pyx_v_event->data.scalar.length, ((char *)"strict")); if (unlikely(!__pyx_t_4)) __PYX_ERR(0, 595, __pyx_L1_error)
                                        ^~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:1298:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_DecodeUTF8(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:8179:40: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
         __pyx_t_4 = PyUnicode_FromString(__pyx_v_event->data.sequence_start.anchor); if (unlikely(!__pyx_t_4)) __PYX_ERR(0, 620, __pyx_L1_error)
                                          ^~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:8220:40: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
         __pyx_t_4 = PyUnicode_FromString(__pyx_v_event->data.sequence_start.tag); if (unlikely(!__pyx_t_4)) __PYX_ERR(0, 623, __pyx_L1_error)
                                          ^~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:8449:40: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
         __pyx_t_4 = PyUnicode_FromString(__pyx_v_event->data.mapping_start.anchor); if (unlikely(!__pyx_t_4)) __PYX_ERR(0, 637, __pyx_L1_error)
                                          ^~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:8490:40: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
         __pyx_t_4 = PyUnicode_FromString(__pyx_v_event->data.mapping_start.tag); if (unlikely(!__pyx_t_4)) __PYX_ERR(0, 640, __pyx_L1_error)
                                          ^~~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c: In function ‘__pyx_f_5_yaml_7CParser__compose_node’:
  ext/_yaml.c:10094:38: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
       __pyx_t_3 = PyUnicode_FromString(__pyx_v_self->parsed_event.data.alias.anchor); if (unlikely(!__pyx_t_3)) __PYX_ERR(0, 734, __pyx_L1_error)
                                        ^~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:10378:38: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
       __pyx_t_6 = PyUnicode_FromString(__pyx_v_self->parsed_event.data.scalar.anchor); if (unlikely(!__pyx_t_6)) __PYX_ERR(0, 750, __pyx_L1_error)
                                        ^~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:10434:38: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
       __pyx_t_6 = PyUnicode_FromString(__pyx_v_self->parsed_event.data.sequence_start.anchor); if (unlikely(!__pyx_t_6)) __PYX_ERR(0, 753, __pyx_L1_error)
                                        ^~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:10490:38: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
       __pyx_t_6 = PyUnicode_FromString(__pyx_v_self->parsed_event.data.mapping_start.anchor); if (unlikely(!__pyx_t_6)) __PYX_ERR(0, 756, __pyx_L1_error)
                                        ^~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c: In function ‘__pyx_f_5_yaml_7CParser__compose_scalar_node’:
  ext/_yaml.c:11109:36: warning: pointer targets in passing argument 1 of ‘PyUnicode_DecodeUTF8’ differ in signedness [-Wpointer-sign]
     __pyx_t_2 = PyUnicode_DecodeUTF8(__pyx_v_self->parsed_event.data.scalar.value, __pyx_v_self->parsed_event.data.scalar.length, ((char *)"strict")); if (unlikely(!__pyx_t_2)) __PYX_ERR(0, 791, __pyx_L1_error)
                                      ^~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:1298:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_DecodeUTF8(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:11310:38: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
       __pyx_t_2 = PyUnicode_FromString(__pyx_v_self->parsed_event.data.scalar.tag); if (unlikely(!__pyx_t_2)) __PYX_ERR(0, 804, __pyx_L1_error)
                                        ^~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c: In function ‘__pyx_f_5_yaml_7CParser__compose_sequence_node’:
  ext/_yaml.c:11841:38: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
       __pyx_t_3 = PyUnicode_FromString(__pyx_v_self->parsed_event.data.sequence_start.tag); if (unlikely(!__pyx_t_3)) __PYX_ERR(0, 837, __pyx_L1_error)
                                        ^~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c: In function ‘__pyx_f_5_yaml_7CParser__compose_mapping_node’:
  ext/_yaml.c:12435:38: warning: pointer targets in passing argument 1 of ‘PyUnicode_FromString’ differ in signedness [-Wpointer-sign]
       __pyx_t_3 = PyUnicode_FromString(__pyx_v_self->parsed_event.data.mapping_start.tag); if (unlikely(!__pyx_t_3)) __PYX_ERR(0, 876, __pyx_L1_error)
                                        ^~~~~~~~~~~~
  In file included from /usr/local/include/python3.7m/Python.h:80:0,
                   from ext/_yaml.c:4:
  /usr/local/include/python3.7m/unicodeobject.h:702:23: note: expected ‘const char *’ but argument is of type ‘yaml_char_t * {aka unsigned char *}’
   PyAPI_FUNC(PyObject*) PyUnicode_FromString(
                         ^~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c: In function ‘__pyx_f_5_yaml_input_handler’:
  ext/_yaml.c:13141:87: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
     __pyx_t_3 = (((__pyx_v_parser->stream_cache_len - __pyx_v_parser->stream_cache_pos) < __pyx_v_size) != 0);
                                                                                ^
  ext/_yaml.c: In function ‘__pyx_pf_5_yaml_8CEmitter___init__’:
  ext/_yaml.c:13630:53: warning: passing argument 2 of ‘yaml_emitter_set_output’ from incompatible pointer type [-Wincompatible-pointer-types]
     yaml_emitter_set_output((&__pyx_v_self->emitter), __pyx_f_5_yaml_output_handler, ((void *)__pyx_v_self));
                                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:1829:1: note: expected ‘int (*)(void *, unsigned char *, size_t) {aka int (*)(void *, unsigned char *, long unsigned int)}’ but argument is of type ‘int (*)(void *, char *, size_t) {aka int (*)(void *, char *, long unsigned int)}’
   yaml_emitter_set_output(yaml_emitter_t *emitter,
   ^~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c: In function ‘__pyx_f_5_yaml_8CEmitter__object_to_event’:
  ext/_yaml.c:15002:44: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
           __pyx_v_tag_directives_end->handle = PyString_AS_STRING(__pyx_v_handle);
                                              ^
  ext/_yaml.c:15117:44: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
           __pyx_v_tag_directives_end->prefix = PyString_AS_STRING(__pyx_v_prefix);
                                              ^
  ext/_yaml.c:15454:62: warning: pointer targets in passing argument 2 of ‘yaml_alias_event_initialize’ differ in signedness [-Wpointer-sign]
       __pyx_t_2 = ((yaml_alias_event_initialize(__pyx_v_event, __pyx_v_anchor) == 0) != 0);
                                                                ^~~~~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:553:1: note: expected ‘yaml_char_t * {aka unsigned char *}’ but argument is of type ‘char *’
   yaml_alias_event_initialize(yaml_event_t *event, yaml_char_t *anchor);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:16169:63: warning: pointer targets in passing argument 2 of ‘yaml_scalar_event_initialize’ differ in signedness [-Wpointer-sign]
       __pyx_t_2 = ((yaml_scalar_event_initialize(__pyx_v_event, __pyx_v_anchor, __pyx_v_tag, __pyx_v_value, __pyx_v_length, __pyx_v_plain_implicit, __pyx_v_quoted_implicit, __pyx_v_scalar_style) == 0) != 0);
                                                                 ^~~~~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:578:1: note: expected ‘yaml_char_t * {aka unsigned char *}’ but argument is of type ‘char *’
   yaml_scalar_event_initialize(yaml_event_t *event,
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:16169:79: warning: pointer targets in passing argument 3 of ‘yaml_scalar_event_initialize’ differ in signedness [-Wpointer-sign]
       __pyx_t_2 = ((yaml_scalar_event_initialize(__pyx_v_event, __pyx_v_anchor, __pyx_v_tag, __pyx_v_value, __pyx_v_length, __pyx_v_plain_implicit, __pyx_v_quoted_implicit, __pyx_v_scalar_style) == 0) != 0);
                                                                                ^~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:578:1: note: expected ‘yaml_char_t * {aka unsigned char *}’ but argument is of type ‘char *’
   yaml_scalar_event_initialize(yaml_event_t *event,
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:16169:92: warning: pointer targets in passing argument 4 of ‘yaml_scalar_event_initialize’ differ in signedness [-Wpointer-sign]
       __pyx_t_2 = ((yaml_scalar_event_initialize(__pyx_v_event, __pyx_v_anchor, __pyx_v_tag, __pyx_v_value, __pyx_v_length, __pyx_v_plain_implicit, __pyx_v_quoted_implicit, __pyx_v_scalar_style) == 0) != 0);
                                                                                ^~~~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:578:1: note: expected ‘yaml_char_t * {aka unsigned char *}’ but argument is of type ‘char *’
   yaml_scalar_event_initialize(yaml_event_t *event,
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:16603:71: warning: pointer targets in passing argument 2 of ‘yaml_sequence_start_event_initialize’ differ in signedness [-Wpointer-sign]
       __pyx_t_3 = ((yaml_sequence_start_event_initialize(__pyx_v_event, __pyx_v_anchor, __pyx_v_tag, __pyx_v_implicit, __pyx_v_sequence_style) == 0) != 0);
                                                                         ^~~~~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:601:1: note: expected ‘yaml_char_t * {aka unsigned char *}’ but argument is of type ‘char *’
   yaml_sequence_start_event_initialize(yaml_event_t *event,
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:16603:87: warning: pointer targets in passing argument 3 of ‘yaml_sequence_start_event_initialize’ differ in signedness [-Wpointer-sign]
       __pyx_t_3 = ((yaml_sequence_start_event_initialize(__pyx_v_event, __pyx_v_anchor, __pyx_v_tag, __pyx_v_implicit, __pyx_v_sequence_style) == 0) != 0);
                                                                                ^~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:601:1: note: expected ‘yaml_char_t * {aka unsigned char *}’ but argument is of type ‘char *’
   yaml_sequence_start_event_initialize(yaml_event_t *event,
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:17037:70: warning: pointer targets in passing argument 2 of ‘yaml_mapping_start_event_initialize’ differ in signedness [-Wpointer-sign]
       __pyx_t_2 = ((yaml_mapping_start_event_initialize(__pyx_v_event, __pyx_v_anchor, __pyx_v_tag, __pyx_v_implicit, __pyx_v_mapping_style) == 0) != 0);
                                                                        ^~~~~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:633:1: note: expected ‘yaml_char_t * {aka unsigned char *}’ but argument is of type ‘char *’
   yaml_mapping_start_event_initialize(yaml_event_t *event,
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:17037:86: warning: pointer targets in passing argument 3 of ‘yaml_mapping_start_event_initialize’ differ in signedness [-Wpointer-sign]
       __pyx_t_2 = ((yaml_mapping_start_event_initialize(__pyx_v_event, __pyx_v_anchor, __pyx_v_tag, __pyx_v_implicit, __pyx_v_mapping_style) == 0) != 0);
                                                                                ^~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:633:1: note: expected ‘yaml_char_t * {aka unsigned char *}’ but argument is of type ‘char *’
   yaml_mapping_start_event_initialize(yaml_event_t *event,
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c: In function ‘__pyx_pf_5_yaml_8CEmitter_12serialize’:
  ext/_yaml.c:18516:42: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
         __pyx_v_tag_directives_end->handle = PyString_AS_STRING(__pyx_v_handle);
                                            ^
  ext/_yaml.c:18631:42: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
         __pyx_v_tag_directives_end->prefix = PyString_AS_STRING(__pyx_v_prefix);
                                            ^
  ext/_yaml.c: In function ‘__pyx_f_5_yaml_8CEmitter__serialize_node’:
  ext/_yaml.c:19491:65: warning: pointer targets in passing argument 2 of ‘yaml_alias_event_initialize’ differ in signedness [-Wpointer-sign]
       __pyx_t_2 = ((yaml_alias_event_initialize((&__pyx_v_event), __pyx_v_anchor) == 0) != 0);
                                                                   ^~~~~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:553:1: note: expected ‘yaml_char_t * {aka unsigned char *}’ but argument is of type ‘char *’
   yaml_alias_event_initialize(yaml_event_t *event, yaml_char_t *anchor);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:20240:68: warning: pointer targets in passing argument 2 of ‘yaml_scalar_event_initialize’ differ in signedness [-Wpointer-sign]
         __pyx_t_2 = ((yaml_scalar_event_initialize((&__pyx_v_event), __pyx_v_anchor, __pyx_v_tag, __pyx_v_value, __pyx_v_length, __pyx_v_plain_implicit, __pyx_v_quoted_implicit, __pyx_v_scalar_style) == 0) != 0);
                                                                      ^~~~~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:578:1: note: expected ‘yaml_char_t * {aka unsigned char *}’ but argument is of type ‘char *’
   yaml_scalar_event_initialize(yaml_event_t *event,
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:20240:84: warning: pointer targets in passing argument 3 of ‘yaml_scalar_event_initialize’ differ in signedness [-Wpointer-sign]
         __pyx_t_2 = ((yaml_scalar_event_initialize((&__pyx_v_event), __pyx_v_anchor, __pyx_v_tag, __pyx_v_value, __pyx_v_length, __pyx_v_plain_implicit, __pyx_v_quoted_implicit, __pyx_v_scalar_style) == 0) != 0);
                                                                                ^~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:578:1: note: expected ‘yaml_char_t * {aka unsigned char *}’ but argument is of type ‘char *’
   yaml_scalar_event_initialize(yaml_event_t *event,
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:20240:97: warning: pointer targets in passing argument 4 of ‘yaml_scalar_event_initialize’ differ in signedness [-Wpointer-sign]
         __pyx_t_2 = ((yaml_scalar_event_initialize((&__pyx_v_event), __pyx_v_anchor, __pyx_v_tag, __pyx_v_value, __pyx_v_length, __pyx_v_plain_implicit, __pyx_v_quoted_implicit, __pyx_v_scalar_style) == 0) != 0);
                                                                                ^~~~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:578:1: note: expected ‘yaml_char_t * {aka unsigned char *}’ but argument is of type ‘char *’
   yaml_scalar_event_initialize(yaml_event_t *event,
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:20605:76: warning: pointer targets in passing argument 2 of ‘yaml_sequence_start_event_initialize’ differ in signedness [-Wpointer-sign]
         __pyx_t_2 = ((yaml_sequence_start_event_initialize((&__pyx_v_event), __pyx_v_anchor, __pyx_v_tag, __pyx_v_implicit, __pyx_v_sequence_style) == 0) != 0);
                                                                              ^~~~~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:601:1: note: expected ‘yaml_char_t * {aka unsigned char *}’ but argument is of type ‘char *’
   yaml_sequence_start_event_initialize(yaml_event_t *event,
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:20605:92: warning: pointer targets in passing argument 3 of ‘yaml_sequence_start_event_initialize’ differ in signedness [-Wpointer-sign]
         __pyx_t_2 = ((yaml_sequence_start_event_initialize((&__pyx_v_event), __pyx_v_anchor, __pyx_v_tag, __pyx_v_implicit, __pyx_v_sequence_style) == 0) != 0);
                                                                                ^~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:601:1: note: expected ‘yaml_char_t * {aka unsigned char *}’ but argument is of type ‘char *’
   yaml_sequence_start_event_initialize(yaml_event_t *event,
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:21113:75: warning: pointer targets in passing argument 2 of ‘yaml_mapping_start_event_initialize’ differ in signedness [-Wpointer-sign]
         __pyx_t_2 = ((yaml_mapping_start_event_initialize((&__pyx_v_event), __pyx_v_anchor, __pyx_v_tag, __pyx_v_implicit, __pyx_v_mapping_style) == 0) != 0);
                                                                             ^~~~~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:633:1: note: expected ‘yaml_char_t * {aka unsigned char *}’ but argument is of type ‘char *’
   yaml_mapping_start_event_initialize(yaml_event_t *event,
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c:21113:91: warning: pointer targets in passing argument 3 of ‘yaml_mapping_start_event_initialize’ differ in signedness [-Wpointer-sign]
         __pyx_t_2 = ((yaml_mapping_start_event_initialize((&__pyx_v_event), __pyx_v_anchor, __pyx_v_tag, __pyx_v_implicit, __pyx_v_mapping_style) == 0) != 0);
                                                                                ^~~~~~~~~~~
  In file included from ext/_yaml.h:2:0,
                   from ext/_yaml.c:271:
  /usr/include/yaml.h:633:1: note: expected ‘yaml_char_t * {aka unsigned char *}’ but argument is of type ‘char *’
   yaml_mapping_start_event_initialize(yaml_event_t *event,
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ext/_yaml.c: In function ‘__Pyx__ExceptionSave’:
  ext/_yaml.c:24143:19: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘exc_type’; did you mean ‘curexc_type’?
       *type = tstate->exc_type;
                     ^~
  ext/_yaml.c:24144:20: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘exc_value’; did you mean ‘curexc_value’?
       *value = tstate->exc_value;
                      ^~
  ext/_yaml.c:24145:17: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘exc_traceback’; did you mean ‘curexc_traceback’?
       *tb = tstate->exc_traceback;
                   ^~
  ext/_yaml.c: In function ‘__Pyx__ExceptionReset’:
  ext/_yaml.c:24152:22: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘exc_type’; did you mean ‘curexc_type’?
       tmp_type = tstate->exc_type;
                        ^~
  ext/_yaml.c:24153:23: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘exc_value’; did you mean ‘curexc_value’?
       tmp_value = tstate->exc_value;
                         ^~
  ext/_yaml.c:24154:20: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘exc_traceback’; did you mean ‘curexc_traceback’?
       tmp_tb = tstate->exc_traceback;
                      ^~
  ext/_yaml.c:24155:11: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘exc_type’; did you mean ‘curexc_type’?
       tstate->exc_type = type;
             ^~
  ext/_yaml.c:24156:11: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘exc_value’; did you mean ‘curexc_value’?
       tstate->exc_value = value;
             ^~
  ext/_yaml.c:24157:11: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘exc_traceback’; did you mean ‘curexc_traceback’?
       tstate->exc_traceback = tb;
             ^~
  ext/_yaml.c: In function ‘__Pyx__GetException’:
  ext/_yaml.c:24212:22: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘exc_type’; did you mean ‘curexc_type’?
       tmp_type = tstate->exc_type;
                        ^~
  ext/_yaml.c:24213:23: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘exc_value’; did you mean ‘curexc_value’?
       tmp_value = tstate->exc_value;
                         ^~
  ext/_yaml.c:24214:20: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘exc_traceback’; did you mean ‘curexc_traceback’?
       tmp_tb = tstate->exc_traceback;
                      ^~
  ext/_yaml.c:24215:11: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘exc_type’; did you mean ‘curexc_type’?
       tstate->exc_type = local_type;
             ^~
  ext/_yaml.c:24216:11: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘exc_value’; did you mean ‘curexc_value’?
       tstate->exc_value = local_value;
             ^~
  ext/_yaml.c:24217:11: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘exc_traceback’; did you mean ‘curexc_traceback’?
       tstate->exc_traceback = local_tb;
             ^~
  error: command 'gcc' failed with exit status 1

This is an issue with PyYAML, see here: https://github.com/yaml/pyyaml/issues/126

Thank you


Introduce sync.Map wrapper with generics support

sync.Map provides a map-like API that is safe for concurrent use by
multiple goroutines without additional locking or coordination. Its
main drawback, though, is that predates generics support in Go, which
means that all methods operate on keys/values of any type. Hence, it
is not type safe, and requires annoying type conversions.
This PR introduces a thin generic wrapper around it, allowing
consumers to specify the exact type of keys and values. Code comments
from the standard library are copied (and slightly adapted where
necessary) for users' convenience.
Additionally, it converts current usages over to it, and extends the
lock-check.sh linting script to additionally flag usages of sync.Map.

/test

Cilium Cluster Mesh upgrade failure looks caused by https://github.com/cilium/cilium/issues/29078. Rerunning

Great idea! I am wondering if we need the MapCmpValues struct in addition to the Map struct here. What was the reasoning behind the split? From my understanding, if the CompareAnd{Swap,Delete} methods were attached to the Map struct instead, I don't think there would be any difference to users, since the corresponding sync.Map methods can already support taking a value with type any.

Yeah, I agree that the MapCmpValues struct looks a bit weird, and I don't like its name (but I couldn't come up with anything really better -- MapWithComparableValues could be an alternative but looks long, and ComparableMap sounds misleading -- I'm open to suggestions).
Overall the reasoning behind the split is that the CompareAnd{Swap,Delete} methods require also the values to be comparable (in addition to keys being comparable), and it seemed reasonable to enforce that through the generics constraints. Indeed, while the original sync.Map supports taking a value with type any also for these functions, it would then panic if values are not comparable. OTOH requiring values to be always comparable for all methods looks a no go, as it would limit the usability of the abstraction, preventing for instance to store references to functions.
WDYT?
Another alternative could be simply dropping the MapCmpValues struct (and the associated CompareAnd{Swap,Delete}) methods for the moment, as we are not using them anyway in any part of the code.

Great idea! I am wondering if we need the MapCmpValues struct in addition to the Map struct here. What was the reasoning behind the split? From my understanding, if the CompareAnd{Swap,Delete} methods were attached to the Map struct instead, I don't think there would be any difference to users, since the corresponding sync.Map methods can already support taking a value with type any.

Yeah, I agree that the MapCmpValues struct looks a bit weird, and I don't like its name (but I couldn't come up with anything really better -- MapWithComparableValues could be an alternative but looks long, and ComparableMap sounds misleading -- I'm open to suggestions).
Overall the reasoning behind the split is that the CompareAnd{Swap,Delete} methods require also the values to be comparable (in addition to keys being comparable), and it seemed reasonable to enforce that through the generics constraints. Indeed, while the original sync.Map supports taking a value with type any also for these functions, it would then panic if values are not comparable. OTOH requiring values to be always comparable for all methods looks a no go, as it would limit the usability of the abstraction, preventing for instance to store references to functions.
Another alternative could be simply dropping the MapCmpValues struct (and the associated CompareAnd{Swap,Delete}) methods for the moment, as we are not using them anyway in any part of the code.
WDYT?

Ah I didn't realize that it would panic :facepalm:. I'm on the same page now.
IMO, keeping the extra struct is probably a good idea. We could remove it for now, since no code uses it, but then we may have to reimplement it in the future anyways. Not a dealbreaker thoughl

IMO, keeping the extra struct is probably a good idea. We could remove it for now, since no code uses it, but then we may have to reimplement it in the future anyways. Not a dealbreaker thoughl

Yeah, I agree. Let's keep it there for the moment, we can always drop it afterwards.


iOS:  After viewing All Stories, going to Saved Stories on iPad will get stuck in "syncing" loop

iOS 9.1, iPad Air 2.  This one doesn't always happen, and I wasn't able to reproduce it at the time I submit this, but I have seen it with the latest beta.
These are the rough steps:

Launch NewsBlur
Go to All Stories
Read your stories, until the queue is empty (I wonder if you need to go through enough stories that it has to load another batch from the server?)
Go back to the main page
Go to Saved Stories.  Often the "Syncing" popover thing will appear, fading in and out, like it's stuck in a loop.  The only way to get to Saved Stories is to kill the app and relaunch.

I'll post a screenshot next time I see it, and see if I can get more reproducible steps.  Thanks.

Thanks for posting this1

I can't reproduce this, though not too surprising if sporadic or dependent on some data state.

I'll see if I can get better steps.  Next time it gets in the loop I'll see if I can plug it into my Mac and record a short video of what I'm seeing.  I'm not sure it'll be super helpful, since it won't tell you how it got into that state, but maybe you'll see something I don't.

Turns out "syncing" was the right word -- it's actually "Finding Story...".  Here's a screenshot of where I managed to break the app in the "All Stories" view.  This is a bit different than normal, since I don't usually see the "Finding text" bit in the right pane.  In this both also stayed on solidly, and didn't fade in and out.

I'll continue looking for better steps and a more accurate repro case.

I still can't reproduce this one.  Does it still occur?  Any more clues?

I haven't seen this issue in a while now.  I think it magically got fixed in a prior update, and I just forget about it as everything was working as expected now.
Sorry for the trouble.  I'll try to check back on bug reports if I haven't repro'ed them in some time.  Thanks

No problem; I'm glad it seems to be fixed.  I'll close this now, but if it does occur again, please let us know.  We appreciate your help reporting issues.


dxLookup example

Hi team,
Could you provide example how to use dxLookup. If possible a code similar to attached.
In the attached code I could not work "search" and dxLookup text always shows "[obect object]"
app.component.html: --------------------------
<dx-lookup [dataSource]="heroes" [displayExpr]="name">

    {{item.name}}

app.component.ts code: -----------------------
import { Component } from '@angular/core';
import { DxLookup, DxLookupValueAccessor, DxTemplate } from "devextreme-angular2"
declare var DevExpress: any;
declare var $: any;
export class Hero {
id: number;
name: string;
}
const HEROES: Hero[] = [
{ id: 11, name: 'Mr. Nice' },
{ id: 12, name: 'Narco' },
{ id: 13, name: 'Bombasto' },
{ id: 14, name: 'Celeritas' },
{ id: 15, name: 'Magneta' },
{ id: 16, name: 'RubberMan' },
{ id: 17, name: 'Dynama' },
{ id: 18, name: 'Dr IQ' },
{ id: 19, name: 'Magma' },
{ id: 20, name: 'Tornado' }
];
@Component({
moduleId: module.id,
selector: 'app-root',
templateUrl: 'app.component.html',
directives: [ DxTemplate, DxLookup, DxLookupValueAccessor]
})
export class AppComponent {
public listHeroes: Hero[] = HEROES;
public heroes: any;
private getSource() {
console.log('geting DataSource');
this.heroes = new DevExpress.data.DataSource({
  store: this.listHeroes,
  key: "id",
  searchExpr: "name",
  searchOperation: "contains"
})

}
ngOnInit(): void {
this.getSource();

}
}

Thks!

Ooooops:
The correct code:
app.component.html: --------------------------
`<dx-lookup [dataSource]="heroes" [displayExpr]="name">

    {{item.name}}

`

Hello,

"displayExpr" property expected a string value, but a square brackets told Angular to evaluate the template expression. Use the following html to fix the issue:
<dx-lookup
    [dataSource]="heroes"
    displayExpr="name"
></dx-lookup>

Thank Aden, so obvious after resolved.


Added ability to set proxy server for gem installations; typo fix; ad…

…ded IDEA files to .gitignore
CHECK LIST
Thank you for taking the time to work on a PR.
To ensure your PR is dealt with swiftly please check the following:

[x] You have searched the repository for any relevant issues or PRs.
[x] Your submissions are formatted according to the ansible-lint guidelines.
[x] You have provided a summary describing the change, including rationale and design decisions
[x] You have added additional spec tests to cover new feature or modification as needed

SUMMARY

TESTS/SPECS

Approved.


Create RandomEvent helper function

Here is how we currently calculate random damage (from GiantCrab.cpp):
int GiantCrab::ReturnRiskAttackDamage() {
    int selector = Common::RandomInt(0, 5);
    switch(selector) {
    case 0:
    case 1:
    case 2:
    case 3:
        return 0;
        break;
    case 4:
    case 5:
        return 20;
        break;
    default:
        return 0;
        break;
    }
}

This basically means:

4/6 chance of doing 0 damage
2/6 chance of doing 20 damage

We'd like to create a helper method to avoid doing this. This is what I had in mind:
We'd have to create a function with the signature:
typename<class T>
T RandomEvent(int denominator, vector<int> numerators, vector<T> outcomes)

where it must be that sum(numerators) == denominator and numerators.size() == outcomes.size(). The function takes in generic outcomes, so that even things like functions could be decided randomly.
With this helper function, the GiantCrab function could be rewritten as:
int GiantCrab::ReturnRiskAttackDamage() {
    // 4/6 chance of doing 0 damage
    // 2/6 chance of doing 20 damage

    int denominator = 6;
    vector<int> numerators{4, 2};
    vector<int> outcomes{0, 20};
    return RandomEvent<int>(denominator, numerators, outcomes);
}

This helper function should be placed in the Common class. If you have another design in mind, or know any existing STL libraries that can do this, let me know - we can probably do better than this :stuck_out_tongue:

I'd like to work on this.
I'm sure that there might be better ways to do this depending from case to case but it sounds like a good solution for a generalised situation.


Run all integration tests in one place

Codecov supports uploading multiple files into one flag.
Since there is no conflict between multi-cluster and antrea integration
tests, we can merge them into one category to simplify CI.
Signed-off-by: Lan Luo<EMAIL_ADDRESS>

Codecov Report

Merging #3966 (ffa32ec) into main (79b6480) will increase coverage by 3.34%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #3966      +/-   ##
==========================================
+ Coverage   64.39%   67.73%   +3.34%
==========================================
  Files         294      297       +3
  Lines       43627    43721      +94
==========================================
+ Hits        28095    29616    +1521
+ Misses      13258    11803    -1455
- Partials     2274     2302      +28

Flag
Coverage Δ

*Carryforward flag

integration-tests
35.22% <ø> (?)

Carriedforward from daa82e1

kind-e2e-tests
50.79% <ø> (ø)

Carriedforward from daa82e1

mc-integration-tests
46.61% <ø> (?)

Carriedforward from daa82e1

unit-tests
44.37% <ø> (-0.02%)
:arrow_down:

*This pull request uses carry forward flags. Click here to find out more.

Impacted Files
Coverage Δ

pkg/agent/cniserver/ipam/antrea_ipam.go
51.08% <0.00%> (-1.74%)
:arrow_down:

pkg/ipam/poolallocator/allocator.go
53.49% <0.00%> (-0.97%)
:arrow_down:

...icluster/controllers/multicluster/common/helper.go
58.00% <0.00%> (ø)

pkg/agent/cniserver/ipam/testing/utils.go
92.85% <0.00%> (ø)

pkg/agent/cniserver/testing/utils.go
100.00% <0.00%> (ø)

pkg/agent/util/net.go
52.81% <0.00%> (+0.86%)
:arrow_up:

pkg/apiserver/storage/ram/store.go
80.19% <0.00%> (+1.48%)
:arrow_up:

pkg/agent/util/iptables/iptables.go
45.07% <0.00%> (+1.55%)
:arrow_up:

pkg/agent/openflow/network_policy.go
81.17% <0.00%> (+1.64%)
:arrow_up:

pkg/agent/openflow/framework.go
100.00% <0.00%> (+2.40%)
:arrow_up:

... and 31 more

/test-integration

What does "one flag" in "Codecov supports uploading multiple files into one flag" mean?
Do you mean even without any change, "test-integration" already runs multi-cluster integration tests (I did not see you made any change for that)? If so, probably we should change the title to "Remove separate multi-cluster integration test from CI".

/test-multicluster-e2e

/skip-all
The change impacts only integration tests.