gnupg: 2.2.12 -> 2.2.13

Motivation for this change
https://dev.gnupg.org/T4290
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Great, thanks guys! :)


FAQ.md: Add mention of hashedPassword

Closes #2451

Not sure if we want to put a warning that the password once hashed can't be recovered - should be obvious but may not be.

I think we're good. That's the point of hashing after all.

Will this work with Docker environment variable like PASSWORD but as HASHEDPASSWORD?

Nevermind, I've found it in the binary options:
--password             The password for password authentication (can only be passed in via $PASSWORD or the config file).
--hashed-password      The password hashed with SHA-256 for password authentication (can only be passed in via $HASHED_PASSWORD or the config file).                                 Takes precedence over 'password'.


generateChangeLog with only --diffType=data does not work as expected for any changeset format.

Environment Windows CLI
Liquibase Version: 4.4.3 #53
Liquibase Integration & Version: CLI
Liquibase Extension(s) & Version: NIL
Database Vendor & Version: SQL Server 2019
Operating System Type & Version: Windows 10 build 19043
Description
When using generateChangeLog command with --diffTypes=data alone, no data is extracted whether extracting to csv or sql formatted output. If --diffTypes=tables,data is specified, then dysfunctional empty CREATE TABLE syntax is created and the sql or csv output is created in the --dataOutputDirectory location.
Steps To Reproduce
@REM liquibase.properties defines login credentials for local SQL instance
SQLCMD -E -d tempdb -Q"SELECT name, system_type_id INTO myTypes FROM sys.types;"
SET URL=jdbc:sqlserver://localhost;databaseName=tempdb
liquibase.bat --overwriteOutputFile=true --url=%URL% --schemas=dbo --changeLogfile ./dbchglog_sys.xml --includeSchema=true --dataOutputDirectory=./data --diffTypes=data --liquibaseSchemaName=dbo generateChangeLog
TYPE dbchglog_sys.xml && DIR data
REM dbchglog_sys.xml has only the xsd definitions and no files output
liquibase.bat --overwriteOutputFile=true --url=%URL% --schemas=dbo --changeLogfile ./dbchglog_sys.xml --includeSchema=true --dataOutputDirectory=./data --diffTypes=tables,data --liquibaseSchemaName=dbo generateChangeLog
TYPE dbchglog-sys.xml && DIR data
REM dbchglog_sys.xml has two changesets - one the create table with no columns, and the other then loadData.
REM The csv file is in the data directoryt as expected.
Actual Behavior
Without specifying the tables diffType as well as data, no data is extracted and no loadData changeset is created. But when table is included it generates the loadData set as well as a invalid createTable change.
Expected/Desired Behavior
With diffType data I expect the loadData changesets to be created as well as the extract file to reload the inscope data.
With diffType tables, I do not expect an ill-formed createTable command to be generated.

Hi @sqlsleuth Thanks for submitting this issue.  We will add it to the list of issues that we are processing.

Still an issue for liquibase 4.16.1, what @sqlsleuth  meant with invalid createTable changeset is that the createTable changeset does not include other information other than the table name, example:
    <changeSet author="FBurguer (generated)" id="1663766410077-1">
        <createTable tableName="test"/>
    </changeSet>
    <changeSet author="FBurguer (generated)" id="1663766410077-2">
        <loadData commentLineStartsWith="#" encoding="UTF-8" file="output.csv/test.csv" quotchar=""" separator="," tableName="test">
            <column header="id" name="id" type="NUMERIC"/>
            <column header="name" name="name" type="STRING"/>
        </loadData>
    </changeSet>

The csv is created correctly but the createTable changeset is incorrect.


Cannot have an odd latent_size (working with 2, 4, etc. , but not 3 or 5), shape problem

Hello, here is a code that just builds a rnvp flow with a gaussian base, and run forward on a random set of points (no training).
It works fine with latent_size=2 or latent_size=4, but not if you put latent_size=3 or latent_size=5.
Could you help me find the problem?
#%% # Import required packages
import torch
import normflows as nf
import numpy as np

#%% Real NVP model, with Gaussian base distribution
latent_size=5

# Define 2D Gaussian base distribution
base = nf.distributions.base.DiagGaussian(latent_size)

# Define list of flows
num_layers = 8
flows = []
for i in range(num_layers):
    # Neural network with two hidden layers having 64 units each
    # Last layer is initialized by zeros making training more stable
    param_map = nf.nets.MLP([latent_size//2, 64, 64, latent_size], init_zeros=True)
    # Add flow layer
    flows.append(nf.flows.AffineCouplingBlock(param_map))
    # Swap dimensions
    flows.append(nf.flows.Permute(latent_size, mode='swap'))

# Construct flow model
model = nf.NormalizingFlow(base, flows)
model = model.to('cpu')

# %%
X=np.random.rand(10,latent_size)
X_tensor = torch.tensor(X, dtype=torch.float32)
z = model.forward(X_tensor)

The error happens in the last line, and in fact, trying to run just the first flow of the loop in forward will do the same:
model.flows[0](X_tensor)
With latent_size=3, I have:
RuntimeError: mat1 and mat2 shapes cannot be multiplied (10x2 and 1x64)
With latent_size=5, I have:
RuntimeError: mat1 and mat2 shapes cannot be multiplied (10x3 and 2x64)
For this last one, if I print model.flows[0], I have the architecture herebelow, so I feel like the problem is between the Split that has to separate the variables in two sets, and the first Linear 2x64, and has to do in the code with the integer division latent_size//2.
Is the problem that when it is an odd number, we cannot split in two set of variables of the same number? How can I deal with that?
AffineCouplingBlock(
  (flows): ModuleList(
    (0): Split()
    (1): AffineCoupling(
      (param_map): MLP(
        (net): Sequential(
          (0): Linear(in_features=2, out_features=64, bias=True)
          (1): LeakyReLU(negative_slope=0.0)
          (2): Linear(in_features=64, out_features=64, bias=True)
          (3): LeakyReLU(negative_slope=0.0)
          (4): Linear(in_features=64, out_features=5, bias=True)
        )
      )
    )
    (2): Merge()
  )
)

I just realized this might be a theoretical constraint

https://en.wikipedia.org/wiki/Flow-based_generative_model
Maybe it would be be good to have an error message disclosing this?
Now I am wondering if there would be a workaround on this, like adding a dummy variable that it e.g. a uniform distribution (or other if better), or if this would not be a good idea for some reason

Hi @noetits,
It is possible to use real NVP with an odd number of dimensions. In this case, the variable is split into two parts of size (latent_size // 2 +1 , latent_size // 2). Since the first part goes into the parameter map, which computes the parameters for the second part, we need to change the following:
param_map = nf.nets.MLP([(latent_size + 1) // 2, 64, 64, latent_size // 2 * 2], init_zeros=True)

This should work for both even and odd dimensions.
Note that this depends on the kind of Split you use. Also, if you do not use a scale, as in NICE, you need to drop the factor of 2 in the output units, since there will be only one parameter per dimension, i.e. the shift.
Best regards,
Vincent


typed times erased when @date is parsed

hi,
Issue, sometimes a @date is parsed but the time is erased after enter
I use the plugin in language NL.
Example issue:
I type:  meeting planned @morgen om 11.30 uur
I hit enter
result is that it now says:
meeting planned [[25-05-2023]]
Comment: the " om 11.30 uur" has been erased automatically.
To avoid this issue, I type the date, then hit enter and then go back to add the hours.

Fixed in v4.0.4


when watch a reactive data, the old value is equal new value. if watch a ref, it's right.

Version
3.0.0-beta.15
Reproduction link
https://codesandbox.io/s/cool-lovelace-kw6hp?file=/src/App.vue
Steps to reproduce
import { reactive, watch } from 'vue'
export default {
mounted() {
},
setup() {
const msg1 = reactive({
val: 1
});
watch(msg1, (val, oldVal) => {
console.log(val === oldVal); // true?
console.log(new val: ${val.val}, old val: ${oldVal.val});
});
const changeMsg1 = () => {
msg1.val  = 1;
};
    return {
        msg1,
        changeMsg1
    };
}

};
What is expected?
"val == oldVal" is false
"val.val === oldVal.val" is false
What is actually happening?
"val === oldVal" is true
"val.val === oldVal.val" is true

this app is use vue-cli3 create，then use "vue add vue-next" change version vue2 to vue3。

This is consistent with the behavior of Vue2, because the old and new values have the same reference.

^

@huangfengya
watch(
  () => msg1.val,
  (val, oldVal) => {
    msg1.isOldEqualNew = val.val === oldVal.val
    console.log(val === oldVal) // true?
    console.log(`new val: ${val}, old val: ${oldVal}`)
  }
)

no workaround for this?


gRPC-Web requests hang over QUIC

Title: gRPC-Web requests hang over QUIC
Description:
gRPC-Web requests hang over QUIC:

It appears to be due to an empty HEADERS frame being sent by Envoy at the end of the stream instead terminating it:

The bug appears to be that trailers are encoded into a QUIC frame even when they are empty, which is the case with the gRPC-Web filters which clears and converts trailers into a body chunk.
Repro steps:

Configure a gRPC Web endpoint behind Envoy (https://grpc.io/docs/platforms/web/basics/#configure-the-envoy-proxy)
Expose it over QUIC to downstream clients (https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/http/http3#http-3-downstream)
Send gRPC Web requests from a browser, observe that they hang.

I have a tentative fix in https://github.com/envoyproxy/envoy/pull/33228 to fix the handling of empty trailers to terminate the stream instead of sending an empty HEADERS frame.
An alternative would be to skip the call to encodeTrailers when headers are empty. That would require broader changes to Envoy and may break the design of filters if we expect empty trailers processed by a first filter to be handled by a subsequent ones. This change is more narrowly scoped but it would be good for a maintainer to confirm that this is the right fix.

cc @RyanTheOptimist @danzh2010

Hi Quentin, thanks for reporting the issue and proposing the fix! Could you elaborate more about why an empty trailer in response could cause the stream hanging but an empty body with FIN over HTTP/3 won't? Supposedly there is some gRPC contract that HTTP/3 is violating and causing the hang? How does HTTP/2 codec handle this situation?

Interesting. It looks like the HTTP/2 codec also skips the encoding of empty trailers, and instead sends empty data. How odd. Well, if this is the Envoy way of doing this, then it probably makes sense for both the H2 and H3 codecs to behave similarly. But we'd likely need a runtime flag to guard this new (hopefully correct) behavior.
https://github.com/envoyproxy/envoy/blob/main/source/common/http/http2/codec_impl.cc#L630-L640

@danzh2010 raises a good question that I don't think I understand the answer to. It sounds like if the client talks directly to a gRPC-web server, then the empty trailers do not cause a hang. But when the client talks to a Envoy and Envoy talks to the server, then the request hangs. Do we understand what the difference here is? To confirm, is the client sending empty trailers? Or is the gRPC-Web filter creating them even when the client does not?

Thank you both for looking into this.

It sounds like if the client talks directly to a gRPC-web server, then the empty trailers do not cause a hang.

From https://github.com/grpc/grpc-web, gRPC Web isn't meant to be directly exposed by a web server, so you won't usually find a gRPC-web server that a client can talk to directly. Instead, gRPC Web clients connect to a regular gRPC server with a proxy doing the translation, and Envoy is the default implementation of this.
gRPC-web clients connect to gRPC services via a special proxy; by default,
gRPC-web uses [Envoy](https://www.envoyproxy.io/).

gRPC uses trailers to communicate the status of the RPC, but gRPC Web doesn't as trailers aren't exposed by web browsers (https://stackoverflow.com/questions/46373013/access-to-http-2-trailers-in-a-browser). So Envoy and the grpc_web filter is responsible for translating the trailers into a body chunk.
When using QUIC, this is happening correctly but Envoy appends an empty HEADERS frame which seems to block Chrome from considering the stream complete. Do you know if the later is expected? It is possible that this is a Chrome issue if a HEADERS frame at the end of a stream is expected to be handled gracefully (from the screenshot above, the HEADERS frame does have FIN=true). But in the meantime removing the HEADERS frame when empty should fix the issue.
Should I go ahead and add the runtime flag to my pull request, or do you prefer to take this over?

Envoy and the grpc_web filter is responsible for translating the trailers into a body chunk.
When using QUIC, this is happening correctly but Envoy appends an empty HEADERS frame which seems to block Chrome from considering the stream complete. Do you know if the later is expected?

Did grpc_web filter fail to translate an empty trailer but passed it down somehow? Or did it translate a non-empty trailer into body and appended an empty one?

Thank you both for looking into this.

It sounds like if the client talks directly to a gRPC-web server, then the empty trailers do not cause a hang.

From https://github.com/grpc/grpc-web, gRPC Web isn't meant to be directly exposed by a web server, so you won't usually find a gRPC-web server that a client can talk to directly. Instead, gRPC Web clients connect to a regular gRPC server with a proxy doing the translation, and Envoy is the default implementation of this.
gRPC-web clients connect to gRPC services via a special proxy; by default,
gRPC-web uses [Envoy](https://www.envoyproxy.io/).

gRPC uses trailers to communicate the status of the RPC, but gRPC Web doesn't as trailers aren't exposed by web browsers (https://stackoverflow.com/questions/46373013/access-to-http-2-trailers-in-a-browser). So Envoy and the grpc_web filter is responsible for translating the trailers into a body chunk.
When using QUIC, this is happening correctly but Envoy appends an empty HEADERS frame which seems to block Chrome from considering the stream complete. Do you know if the later is expected? It is possible that this is a Chrome issue if a HEADERS frame at the end of a stream is expected to be handled gracefully (from the screenshot above, the HEADERS frame does have FIN=true). But in the meantime removing the HEADERS frame when empty should fix the issue.

Yes, this does sound a like a Chrome bug to me, yes. At the QUIC layer, the stream is closed because a QUIC STREAM frame was received with the fin bit set. There's nothing "wrong" at the HTTP/3 layer, as far as I know, with an empty HEADERS frame. But it makes me wonder if Chrome is somehow treating empty headers as incomplete headers? Have you worked with Chrome team on this at all?

Should I go ahead and add the runtime flag to my pull request, or do you prefer to take this over?

If you could add a flag, that'd be great. I think I'd like to understand the problem a bit more clearly before we land anything, but adding a flag is a good idea.

Thanks for the offline discussion this morning. The server sends non-empty trailers to Envoy, and then the gRPC filters mutate the trailers (by removing the status field) which leaves the trailers empty at the end of the filter chain. It's a bit odd that Envoy chooses to call EncodeTrailers at that point, but it's not crazy :) So let's go ahead and move forward with your PR, subject to runtime-flag protection.
In addition, the Chrome behavior of having a request hang when empty HTTP/3 trailers are received is clearly a bug.
I filed https://issues.chromium.org/issues/332587381, and fixed the issue with this commit https://chromium-review.googlesource.com/c/chromium/src/+/5421968 Chrome Canary should pick this up in the next day or so if you would like to confirm.


Add right click option on canvas to delete all unused blocks

Instead of just deleting all blocks, maybe you could have a command to delete all the blocks that aren't connected to an event or on start. It's easy for blocks to disappear between other blocks, and this could help with performance cause you could be removing tons of blocks that are never seen by the user.

Interesting idea. We don't plan to implement this.


[M1] Update Usage section of README

To be done after all the other tasks are completed for M1 and before #26

Successfully done and merged PR


Change the module path of bls12_381-sign-go

Resolves #1182

Codecov Report

Merging #1203 (20f2a8a) into master (828364b) will decrease coverage by 0.62%.
The diff coverage is 54.98%.

@@            Coverage Diff             @@
##           master    #1203      +/-   ##
==========================================
- Coverage   50.51%   49.88%   -0.63%
==========================================
  Files         145      150       +5
  Lines        7544     9068    +1524
==========================================
+ Hits         3811     4524     +713
- Misses       3066     3878     +812
+ Partials      667      666       -1

Impacted Files
Coverage Δ

pkg/config/consts.go
0.00% <ø> (ø)

pkg/config/genesis/config.go
0.00% <0.00%> (ø)

pkg/core/candidate/validator.go
64.00% <ø> (+6.85%)
:arrow_up:

pkg/core/chain/legacy.go
0.00% <0.00%> (-28.58%)
:arrow_down:

pkg/core/chain/mock.go
9.09% <ø> (+0.75%)
:arrow_up:

...kg/core/consensus/blockgenerator/candidate/mock.go
0.00% <0.00%> (ø)

pkg/core/consensus/comms.go
0.00% <0.00%> (ø)

pkg/core/consensus/fixtures.go
0.00% <0.00%> (ø)

pkg/core/consensus/header/header.go
24.50% <0.00%> (+2.41%)
:arrow_up:

pkg/core/consensus/publisher.go
0.00% <0.00%> (ø)

... and 177 more

Continue to review full report at Codecov.

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


test: exclude TestPHPOverrides on Colima

The Issue
Colima is always difficult to get through a run. Lately we're seeing TestPHPOverrides fail a lot, and it seems no reason to work any harder on it.
How This PR Solves The Issue
Don't test it on Colima.
HOWEVER: Run local tests with colima on TestPHPOverrides and see if it can be reproduced.

I manually tested TestPHPOverrides on macOS (with the t.Skip removed) and it tested fine (Colima)


zsa-openapi consumes request, make it impossible to use it later

I suggest making a clone before doing for example an await request.json().  This makes it impossible for later use the request param received in the routes handlers, for example to verify a hmac, because when I try to make a request.clone().text(), it has already been consumed.

Thanks for the PR 🫡


Query for presentation event log

This PR adds a new option to the VerifierAPI that would allow the Verifier to obtain a list of events, the event log, for a presentation.

[x] Introduce a sealed hierarchy PresentationEvent, to represent notable events
[x] Allow the use cases, to publish such events
[x] Add a new option to VerifierAPI to allow the retrieval of the event log
[x] Add an in memory repo to store such events
[ ] Add to OpenAPI the new endpoint
[x] Consider adding unhappy path events
[x] Introduce a timer to remove those events from the repo

Closes #178

@dzarras I think that it is ready. Please check the OpenAPI addition

@babisRoutis Besides the two points above, the PR is ready for merging.


Update etender data

This change is

Reviewed 2 of 2 files at r1, 1 of 1 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


eni: agent failed to restart after patching wrong value in ciliumnode

Bug report
General Information

Cilium version 1.6.2
Orchestration system version in use k8s 1.13.2

How to reproduce the issue
1. start cilium-agent in ipam:eni mode, ciliumnode resource is created automatically
2. set random subnet-tags for this node
kubectl patch ciliumnodes.cilium.io nodename --type='json' -p='[{"op": "replace", "path": "/spec/eni/subnet-tags", "value":[{"key":"testkey","value":"testvalue"}]}]'

The subnet-tags shown in describe ciliumnode:
Spec:
...
  Eni:
...
    Subnet - Tags:
      Key:     testkey
      Value:   testvalue
...

3. restart cilium-agent, cilium-agent exited with the following logs:
level=info msg="Updating CRD (CustomResourceDefinition)..." name=v2.CiliumIdentity subsys=k8s
level=info msg="CRD (CustomResourceDefinition) is installed and up-to-date" name=v2.CiliumIdentity subsys=k8s
level=info msg="k8s mode: Allowing localhost to reach local endpoints" subsys=daemon
level=info msg="Initializing node addressing" subsys=daemon
level=info msg="Restored IPv4 internal node IP: xx.xx.xx.xx" subsys=node
level=info msg="Initializing CRD-based IPAM" subsys=ipam
level=info msg="Subscribed to CiliumNode custom resource" name=nodename subsys=ipam
level=fatal msg="Unable to create CiliumNode resource" error="ciliumnodes.cilium.io \"nodename\" already exists" subsys=nodediscovery

@jaffcheng I think the way you're updating the cn custom resource does not match the type of the SubnetTags field in the eni spec (https://github.com/cilium/cilium/blob/master/pkg/k8s/apis/cilium.io/v2/types.go#L806-L810). You can see that it is a map[string]string. With your kubectl you're making the subnets-tags field in the CiliumNode to be an array.

Thanks for pointing that out @ungureanuvladvictor , I just realized that and after patching the wrong value, cilium-agent prints right error logs immediately, which I missed because I have restarted cilium-agent:
level=error msg=k8sError error="github.com/cilium/cilium/pkg/ipam/crd.go:148: Failed to list *v2.CiliumNode: v2.CiliumNodeList.Items: []v2.CiliumNode: v2.CiliumNode.Spec: v2.NodeSpec.ENI: v2.ENISpec.SubnetTags: ReadMapCB: expect { or n, but found [, error found in #10 byte of ...|et-tags\":[{\"key\":\"se|..., ...

After a restart, agent log only shows:
level=fatal msg="Unable to create CiliumNode resource" error="ciliumnodes.cilium.io \"nodename\" already exists" subsys=nodediscovery

I think it would be easier to debug if cilium-agent prints the CRD validation error on restart.

I agree with your point @jaffcheng but I suspect we can sidestep this problem entierly by having the k8s apiserver apply validation to the ciliumnodes.cilium.io. Without a lot of experience in this area I've found https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#specifying-a-structural-schema and I suspect Cilium is already doing this for CNPs.
@aanm any hints in this area?

@ungureanuvladvictor yep, PR #9655 seems to be in the right track.


API Limits

Hello! I'm getting an error 429 ("Rate exceeded.") when using the pi-delivery API. I would like to know this limit so I can adjust my requests. Thank you!

The API is a demo and it's not intended to be used to scan a lot of digits. The limits are adjusted based on overall workload of the service and not a fixed value. A typical use case would send probably a few requests per minute, and if you need more digits, consider downloading directly from the Cloud Storage bucket: https://storage.googleapis.com/pi100t/index.html


Add Twitter oracle v1

Every 100 blocks, process tweets with user invites and create new users, enabling daily CREDITS, and setting invite data.
Check if the user is friends with the invited user.
This could be a CosmWasm contract. Maybe each vendor could have their own user verification oracle contract that confirms to the same interface. This way we can add future verifications for other vendors / social networks.
The contract would obviously have to talk to the native user module on-chain. And there needs to be a registry of vendor_id <-> contract_address somewhere. Then new vendor verifications can be added by uploading new contracts and adding a new one to the registry.

See:
https://github.com/Uniswap/sybil-list
https://github.com/irisnet/irismod/tree/master/modules/oracle


Immediate compatiblity feedback for external loaders

External loaders are streaming their data via stdout as expected, but we're waiting for their exit status code in order to decide whether they are compatible... which nullifies the whole point of streaming the data in the first place!
This PR now detects as soon as a child process starts streaming data in, and considers that as a sure sign of compatibility.
0.12:
https://github.com/rerun-io/rerun/assets/2910679/872d7bc3-f907-4dd4-9cbe-c4c85510ffc1
Now:
https://github.com/rerun-io/rerun/assets/2910679/4266c194-1eb0-4c34-a79a-c2f4286688ba
Checklist

[x] I have read and agree to Contributor Guide and the Code of Conduct
[x] I've included a screenshot or gif (if applicable)
[x] I have tested the web demo (if applicable):

Using newly built examples: app.rerun.io
Using examples from latest main build: app.rerun.io
Using full set of examples from nightly build: app.rerun.io

[x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG

PR Build Summary
Docs preview
Examples preview
Recent benchmark results
Wasm size tracking

Nice! This is pretty motivating for doing a patch release


Add AdsSymbol class

Expanded the AdsSymbol class to stand on its own. Also updated the AdvancedHandler tester class.
Fixes #166 and related to #168

Pull Request Test Coverage Report for Build 503

90 of 122 (73.77%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-2.2%) to 91.533%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pyads/ads.py
14
15
93.33%

pyads/constants.py
9
16
56.25%

pyads/symbol.py
66
90
73.33%

Totals

Change from base Build 502:
-2.2%

Covered Lines:
1027

Relevant Lines:
1122

💛  - Coveralls

Pull Request Test Coverage Report for Build 503

90 of 122 (73.77%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-2.2%) to 91.533%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pyads/ads.py
14
15
93.33%

pyads/constants.py
9
16
56.25%

pyads/symbol.py
66
90
73.33%

Totals

Change from base Build 502:
-2.2%

Covered Lines:
1027

Relevant Lines:
1122

💛  - Coveralls

Yeah, the buffering idea sounds good.
One danger would be a user expecting that symbol.value is identical to symbol.read(), so we have to make very clear the buffering

so we have to make very clear the first is a buffered value.

If you like you can add a hint to the docstring of value. Also it should be mentioned in the documentation. Anyway I think we should create a separate Quickstart chapter for this new feature.

Nice feature - this symbol class will definitely be my preferred method of using pyads 👍
A quick summary of some thoughts from up here in the peanut gallery:

Consider adding context manager support to AdsSymbol (mirroring that of Connection), such that a manual .close() is not necessary
AdsSymbol.__del__ may not be throwing errors for you now, but from experience with other projects, I can say it's a common source of errors when the interpreter is exiting and has already cleaned up objects your __del__ method relies on. You might consider using weakref.finalize instead.
Moving the regular expression-based "type determination from string" utilities out of the AdsSymbol class would make testing easier and the functions themselves reusable. Also, re.compile is advisable when possible.
enable_auto_update(True/False) is a bit awkward in name - might set_auto_update be better?

Apologies if any of this has already been discussed above - I haven't followed this as closely as I'd like to have.

Nice feature - this symbol class will definitely be my preferred method of using pyads 👍
A quick summary of some thoughts from up here in the peanut gallery:

Consider adding context manager support to AdsSymbol (mirroring that of Connection), such that a manual .close() is not necessary
AdsSymbol.__del__ may not be throwing errors for you now, but from experience with other projects, I can say it's a common source of errors when the interpreter is exiting and has already cleaned up objects your __del__ method relies on. You might consider using weakref.finalize instead.
Moving the regular expression-based "type determination from string" utilities out of the AdsSymbol class would make testing easier and the functions themselves reusable. Also, re.compile is advisable when possible.
enable_auto_update(True/False) is a bit awkward in name - might set_auto_update be better?

Apologies if any of this has already been discussed above - I haven't followed this as closely as I'd like to have.

Consider adding context manager support to AdsSymbol (mirroring that of Connection), such that a manual .close() is not necessary

How would the context usage look like? The symbol don't really open or close themselves.
I was about to say 'Connection doesn't required .close()', but I know notice it doesn't have its own destructor. Should it?

AdsSymbol.__del__ may not be throwing errors for you now, but from experience with other projects, I can say it's a common source of errors when the interpreter is exiting and has already cleaned up objects your __del__ method relies on. You might consider using weakref.finalize instead.

Yeah, I see your point. Is there a downside to using a weakref?
And would a Symbol keep a weakref to the Connection, or the other way around?

Moving the regular expression-based "type determination from string" utilities out of the AdsSymbol class would make testing easier and the functions themselves reusable. Also, re.compile is advisable when possible.

I think I made the method static before. Would that work?

enable_auto_update(True/False) is a bit awkward in name - might set_auto_update be better?

Agreed, changed it.

Consider adding context manager support to AdsSymbol (mirroring that of Connection), such that a manual .close() is not necessary

How would the context usage look like? The symbol don't really open or close themselves.
I was about to say 'Connection doesn't required .close()', but I know notice it doesn't have its own destructor. Should it?

AdsSymbol.__del__ may not be throwing errors for you now, but from experience with other projects, I can say it's a common source of errors when the interpreter is exiting and has already cleaned up objects your __del__ method relies on. You might consider using weakref.finalize instead.

Yeah, I see your point. Is there a downside to using a weakref?
And would a Symbol keep a weakref to the Connection, or the other way around?

Moving the regular expression-based "type determination from string" utilities out of the AdsSymbol class would make testing easier and the functions themselves reusable. Also, re.compile is advisable when possible.

I think I made the method static before. Would that work?

enable_auto_update(True/False) is a bit awkward in name - might set_auto_update be better?

Agreed, changed it.

How would the context usage look like? The symbol don't really open or close themselves.

True - I mistakenly was thinking of the __del__ as an equivalent to close() and didn't express that very well. That said, do you think a general cleanup() method would be appropriate? In that case, the context manager would from a very high level be "create symbol; clean up notifications (and anything else) when the context block is done".

I think I made the method [for "type determination from string"] static before. Would that work?
Making it static would be an improvement to not require an instantiated symbol, for sure. I might argue that its functionality is independent of the AdsSymbol and should remain a separate utility function, but it could just be a matter of preference at that point. 😄

Is there a downside to using a weakref? And would a Symbol keep a weakref to the Connection, or the other way around?

Since pyads is Python 3.6+, I don't think there would be a downside. Removing __del__ may even help with eventual PyPy support. For what it's worth, I haven't found a better solution at least.
Keep in mind the important note from the weakref.finalize docs (below atexit). It's a bit confusing at first, but to get around that, you'd rather be looking to make a weakref finalizer of AdsSymbol that uses the pertinent cleanup information. As the docs note, making it a non-bound method of the form def _symbol_cleanup(plc, handles_list): with a stashed finalizer instance like self._finalizer = weakref.finalize(self, _symbol_cleanup, self.plc, self._handles_list) might work, I think.

How would the context usage look like? The symbol don't really open or close themselves.

True - I mistakenly was thinking of the __del__ as an equivalent to close() and didn't express that very well. That said, do you think a general cleanup() method would be appropriate? In that case, the context manager would from a very high level be "create symbol; clean up notifications (and anything else) when the context block is done".

I think I made the method [for "type determination from string"] static before. Would that work?
Making it static would be an improvement to not require an instantiated symbol, for sure. I might argue that its functionality is independent of the AdsSymbol and should remain a separate utility function, but it could just be a matter of preference at that point. 😄

Is there a downside to using a weakref? And would a Symbol keep a weakref to the Connection, or the other way around?

Since pyads is Python 3.6+, I don't think there would be a downside. Removing __del__ may even help with eventual PyPy support. For what it's worth, I haven't found a better solution at least.
Keep in mind the important note from the weakref.finalize docs (below atexit). It's a bit confusing at first, but to get around that, you'd rather be looking to make a weakref finalizer of AdsSymbol that uses the pertinent cleanup information. As the docs note, making it a non-bound method of the form def _symbol_cleanup(plc, handles_list): with a stashed finalizer instance like self._finalizer = weakref.finalize(self, _symbol_cleanup, self.plc, self._handles_list) might work, I think.

Forgive me for being a bit slow in all this, but I don't see how weakref.finalize would solve our dependencies problem.
My interpretation: weakref.finalize is an alternative to __del__ methods. So if we add a cleanup method to the symbols, the user can still close or delete the Connection object before the symbols are cleaned up.

Forgive me for being a bit slow in all this, but I don't see how weakref.finalize would solve our dependencies problem.
My interpretation: weakref.finalize is an alternative to __del__ methods. So if we add a cleanup method to the symbols, the user can still close or delete the Connection object before the symbols are cleaned up.

Thanks for adding auto_update to AdsSymbol. Subsequently it will also be needed in the get_symbol function :scream:

Thanks for adding auto_update to AdsSymbol. Subsequently it will also be needed in the get_symbol function :scream:

Thanks for adding auto_update to AdsSymbol. Subsequently it will also be needed in the get_symbol function 😱

There will come a day that remember to do everything. But it is not this day.
Updated it

Thanks for adding auto_update to AdsSymbol. Subsequently it will also be needed in the get_symbol function 😱

There will come a day that remember to do everything. But it is not this day.
Updated it

I merged this PR and released a new version 3.3.1 of pyads.

I merged this PR and released a new version 3.3.1 of pyads.


chameneos.mlish fails tests

chameneos is randomly failing tests. I don't know exactly what chameneos does but maybe we should do something about it?

Yes, it's an intermittent failure due to random inputs. I thought I had made the test deterministic but I must have missed a case. Feel free to fix it if can figure out a way.
chameneos is a standard benchmark in the language shootout benchmarks: http://benchmarksgame.alioth.debian.org/
I believe the original paper is here: http://ieeexplore.ieee.org/document/1227495/

That (sleep 0) on line 79 looks highly suspicious. The problem, though, is that the tests seem to more or less check whether the scheduler is (precisely) fair.
PR #30 fixes this by not relying on the scheduler.
TL;DR: Although we could modify the benchmark to ensure that the creatures are scheduled in the right order, I think it's better to simply test against the sum of all meetings (knowing that there were 100 couple-meetings, there should be 200 meetings recorded by individual creatures), instead of checking that every creature got 66 or 67 meetings (which happens when they are run in the order A B C A B C …).
Explanation of what I think was happening follows below.

The place thread, which runs swap, gets two messages (with a callback channel on each) from the ch-meet channel, and replies to the callback by swapping the messages. The creatures send messages to ch-meet, and count how many other creatures they have met, and how many times they have met a creature with the same name (which could happen because the names are random).
The tests below check that each creature met an other one exactly 66 or 67 times, for 100 runs. This will occur if the messages are sent to ch-meet by the creatures A B C A B C A B C … in that order.
However, between the (channel-put ch1 …) (channel-put ch2 …) on lines 57–58 and the subsequent iteration which runs (channel-get ch-meet) (channel-get ch-meet) on lines 53 and 55, in principle any creature could grab the channel and send a message first (if the replies were just sent to A and B, I suspect it's possible that C was not being scheduled, and that A and B grab the channel again; it is also possible if C had already grabbed the channel in the meantime that B will come first, instead of A).
The results on the benchmarks game page for the Racket implementation show that the scheduling is not 100% fair (the creatures have 3999997, 4000011 and 3999992 meetings).

Fixed by #30


Add/dad jokes

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
I've added a dad jokes extension that you can use whenever you're bored and want to refresh your mind with a new dad joke
Fixes:  #392

Type of change

[ x] New feature (non-breaking change which adds functionality)

Checklist:

[ x] I have made this from my own
[x ] I have taken help from some online resources
[ x] My code follows the style guidelines of this project
[x ] I have performed a self-review of my own code
[x ] I have commented my code, particularly in hard-to-understand areas

ATTACH SCREEN-SHOTS / DEPLOYMENT LINK
https://github.com/Sulagna-Dutta-Roy/GGExtensions/assets/115486960/f39f1072-69c2-484f-a32a-69b4ad2b1bdd

yes i have made two PRs so thats why its showing two branch Dad jokes and weight calculator(from another issue)

@Sulagna-Dutta-Roy ??


OracleContainer extends JdbcDatabaseContainer without generic type

It means I need explicit cast when using methods from super type, eg:
@ClassRule
public static OracleContainer db = (OracleContainer) new OracleContainer("foo")
        .withLogConsumer(new Slf4jLogConsumer(LoggerFactory.getLogger("db container logger")));

Following screams compilation errors, because #withLogConsumer returns GenericContainer:
@ClassRule
public static OracleContainer db = new OracleContainer("foo")
        .withLogConsumer(new Slf4jLogConsumer(LoggerFactory.getLogger("db container logger")));

Hi @SoftwareTipi,
Have you tried public static OracleContainer db = new OracleContainer<>("foo") as a workaround?

Hi OracleContainer does not have generic type on itself so diamond syntax won't apply to this.
And still this would be workaround.

@SoftwareTipi Yes, you are right. Are you interested in providing a PR?

@kiview already submitted: #1425


Remove the guideline around CIDR notation

As found in https://github.com/Azure/azure-sdk-for-js/issues/13391, we don't really support the CIDR notation for NO_PROXY. Removing it from the guidelines.

cc @jeremymeng

Thanks @bterlson!


Added reference to required cssmin library

I couldn't find it mentioned anywhere (the location of the PHP cssmin library required). I found an incorrect one with a very close API but it wasn't compatible.

Fixed in 2dcbb8b


Question with respect to training the mediator

Hi, @XiaohangZhan , thanks for your implementation.
You said in the paper, The mediator is trained on D_{l}, but actually you explained in the previous section that the input to the mediator is the relationships, the affinity and the local structures on the graphs derived from the unlabeled dataset. How do you get this on D_{l} for training the mediator, did you repeat the process again for the labeled data?
Thanks,

Yes, in training the mediator, we need to extract those inputs of D_l as well.

Thanks for your clarification


Move all core directives to separate file

Right now, all core module directives are hardcoded in the config_parser src file. This is a problem, since it means we have to search through a massive file to find something miniscule within core.
We should migrate all that we can into a separate and dedicated file.
Note that we absolutely cannot move certain methods, such as LoadModule. However, if we are willing to copy some code from it to initialize the core module, we can mover everything.

There may be one extra thing keeping this away from happening, and that is that if we need to add to the module loading system later on, we would have two places to make the changes, which is not good. Therefore, if we do this, I don't think LoadModule should leave the parser file. It will still be a part of the core module, but this will allow us to avoid code fragmentation.

There may be one extra thing keeping this away from happening, and that is that if we need to add to the module loading system later on, we would have two places to make the changes, which is not good. Therefore, if we do this, I don't think LoadModule should leave the parser file. It will still be a part of the core module, but this will allow us to avoid code fragmentation.

Alright, new job for this thread.
Come up with a list of core directives that cannot move into a dedicated file, along with a good reason for why.

Alright, new job for this thread.
Come up with a list of core directives that cannot move into a dedicated file, along with a good reason for why.

LoadModule: No way to load modules without this directive or copying code, which can result in memory fragmentation.

The definition of this directive may be able to move, but the definition of the code it runs should stay inside the parser code.

LoadModule: No way to load modules without this directive or copying code, which can result in memory fragmentation.

The definition of this directive may be able to move, but the definition of the code it runs should stay inside the parser code.


404 for GET on https://registry.npmjs.org/cordova-plugin-telerik-imagepicker

cordova plugin add cordova-plugin-telerik-imagepicker --variable "PHOTO_LIBRARY_USAGE_DESCRIPTION=your usage message" --save
✖ Running command - failed!
[ERROR] Cordova encountered an error.
You may get more insight by running the Cordova command above directly.
[ERROR] An error occurred while running cordova plugin add cordova-plugin-telerik-imagepicker --variable
"PHOTO_LIBRARY_... (exit code 1):
    Error: Registry returned 404 for GET on https://registry.npmjs.org/cordova-plugin-telerik-imagepicker

Same here :cry:

Me too :(

Yep i'm having the same issue...........

Should be ok now.


Better support for oneOf

One thing that's been lackluster is the support for messages that contain protobuf oneOf groups. It should be possible to map this into OpenAPI using a combination of "required" [field name] and "not" "anyOf" [other field names in the oneOf group].

This has been completed!


added missing figure, fixed links to figures

Hi Johannes @jo-mueller ,
this fixes image links in your sphinx blog entry and adds a missing figure. Would you mind reading over it and checking that every figure is in the right place?
Feel free to merge if you think everything is ok.
Thanks!
Best,
Robert

I also made some minor changes to a display of code that appears to be messed up on the blog page.


Test replacing the background image in megamenu by a gradient

we have one gradient example in the footer wave


Crash on Typing event

Steps to reproduce:

Go to a channel
Start typing - a "user is typing" message is displayed
Post typed string (press return) - crash happens

I couldn't select the error message to copy it, so here's a screenshot:

The typed string is still posted.
Crash only happens on some servers, not all.

It seems that this happens when no overrides (mutes and such) were configured on the server, it is just a matter of checking for the returned value of this data.get

Submitted PR #35


E2E integration AVM circuits with Simulator

Task list to be expanded as we think of them:

[x] #4881
[ ] Support passing of execution context from TS AVM simulator

Done


Network State Migrations (version 10,12,13)

@ec2 will add issues for each state migration that we need to implement

#962 - Network version 10
#1039 - Network version 12
#1112 - Network version 13

We have decided not to support these network versions due to the FVM release. We will only be supporting from NV15 onwards.


Gh-2972: Codecov can generate inconsistent coverage reports

Compared to before this avoids making multiple uploads to codecov and allows the codecov upload to be reattempted with rerunning any tests.
Related Issue

Resolve #2971

Branch name is wrong. This needs to be reopened as the branch cannot be renamed in-situ.


Support for IntelliJ-style http-client.env.json environment files

httpyac supports the .http files used by the IntelliJ HTTP Client, however, it does not support the IntelliJ way of defining environments. Being able to use a http-client.env.json file for environments would be great for cross IDE compatibility.
Example http-client.env.json file
{
  "dev": {
    "host": "https://myhost.dev"
  },
  "qa": {
    "host": "https://myhost.qa"
  },
  "prod": {
    "host": "https://myhost.prod"
  }
}

The example file above should be parsed into three distinct environments named dev, qa and prod.
Is this a feature you also would like to support? If you need support on development, I'll gladly offer some 👍

thanks for using my extension.
In which folder is the file located (root, same as http file, vscode setting?). The documentation of intellij is not really helpful (Docs). Do you have a example of a private env.json?
Thanks for your help, my license for Idea has expired.

I tested in Webstorm instead of IntelliJ, but it should behave the same way as the base of the IDE should be quite similar.
The http-client.env.json file will be picked up from anywhere in the project folder structure. You can also have multiple files in different folders.
There is an error message when duplicate environment names are found between multiple files.
The private files will be excluded from version control by default and will append its properties to environments defined in non-private files.
http-client.env.json
{
  "dev": {
    "host": "https://myhost.dev"
  }
}

http-client.private.env.json
{
  "dev": {
    "auth": "****"
  }
}

In the .http file, you can access variables from both private and non-private files:
myExampleRequest.http
POST {{host}}/foo
Authentication: {{auth}}
Content-Type: application/json

{
  "foo": "bar"
}

http-client.env.json/ http-client.private.env.json should be loaded now. These are searched either in the root or in a configurable folder (default is empty). could you please test it and report problems. thanks

maybe you should enable httpyac.intellijVariableProviderEnabled if your env.json files is next to the *.http file. See readme

Thanks a lot for the fast implementation! 😮 👍
I created a small test project and unfortunately, the variables in the environment do not seem to be picked up:

When selecting the environment, dev is available in the dropdown menu, but inside the .http file editor none of the variables can be resolved.

Trying to send the request results in an error:

Are there any debug logs with further information that might help you?

httpyac register a output panel. In every call the variables are logged.
But why is the host variable
set to https://<IP_ADDRESS> or <IP_ADDRESS>:443. Do you use other settings, like
vscode setting httpyac.environmentVariables? I would expect a
ReferenceError, if variable is  not defined, but it is a timeout. Or is a
proxy configured?
Daniel Kneip<EMAIL_ADDRESS>schrieb am Di., 2. Feb. 2021, 19:03:

Thanks a lot for the fast implementation! 😮 👍
I created a small test project and unfortunately, the variables in the
environment do not seem to be picked up:
[image: image]
https://user-images.githubusercontent.com/13169906/106642631-e5c85080-6588-11eb-8be2-f90c9a03baa0.png
When selecting the environment, dev is available in the dropdown menu,
but inside the .http file editor none of the variables can be resolved.
[image: image]
https://user-images.githubusercontent.com/13169906/106642840-26c06500-6589-11eb-864d-d833166fcf73.png
Trying to send the request results in an error:
[image: image]
https://user-images.githubusercontent.com/13169906/106642795-19a37600-6589-11eb-8067-1dd1f08cbe6c.png
Are there any debug logs with further information that might help you?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/AnWeber/vscode-httpyac/issues/9#issuecomment-771848248,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADGP64ZZ6IPWJN7B544E4I3S5A46JANCNFSM4W4LXH5Q
.

You did use the CodeLens "Send Request" to initiate the call. This is the code lens of vscode-restclient.

You need to use Code Lens "send"

I would recommend using only either vscode-restclient or my extension, not both. Because both extensions do more or less the same. I created my own extension, because my pull request got not integrated in vscode-restclient. So I created my own extension. In vscode-restclient is a feature request implementing intellij support, but I would not expect any progress.

Oh boy, sorry, I totally forgot that I also hab REST Client installed.
Uninstalled it and tried again, now env resolution works just fine! 😃

However, actually sending the request produces an error:
[ERROR - 10:16:27] POST {{host}}/foo
Content-Type: application/json
Authorization: {{auth}}

{
    "foo": "bar"
}
[object Object]
TypeError [ERR_INVALID_URL]: Invalid URL: POST%20https://google.com/foo%0AContent-Type:%20application/json%0AAuthorization:%20BASIC%20****%0A%0A%7B%0A%20%20%20%20%22foo%22:%20%22bar%22%0A%7D
[ERROR - 10:16:27] requestCommandsController.send
TypeError [ERR_INVALID_URL]: Invalid URL: POST%20https://google.com/foo%0AContent-Type:%20application/json%0AAuthorization:%20BASIC%20****%0A%0A%7B%0A%20%20%20%20%22foo%22:%20%22bar%22%0A%7D

Looks like the URL gets appended with the headers? Is there a problem with my request syntax that I'm just missing?

there is an error in parsing your http file.

if you are using another line carriage as the default of your operating system, this error happens.

Man, what a nasty thing ^^ It's working fine now 👍
Variables from the http-client.env.json and http-client.private.env.json get picked up.
I also tested with some real requests we are currently using from Webstorm / IntelliJ, this works flawless too!
So looks good to me, besides the line feed problem 😃
Is this something you would also address? In our case, most of the guys are using LF as they develop on unix-based machines, so the Windows guys also use LF instead of the native CRLF.

if you use the same line carriage as your os all is fine. but if you switch like LF on win or CRLF on linux you got the trouble. I already fixed it in my dev environment. I will release a fix later. I have to cook for my kids now.

Thanks a lot Andreas! 🙇♂

I pushed the fix to vsce. Would be nice if you could test it again.

I just tested and it now works on both LF and CRLF on Windows 😃
Thanks for the quick responses everytime!

You're welcome. Thanks for using my fun coding project😃


Is this plugin maintained?

I notice the last release is almost a year ago, predated the actual release of tox 4.0, and the only commits to this repository since January appear to be automated or semi-automated dependency bumps.
I also notice that the plugin does not appear to work at the moment -- this GitHub Actions config and this tox config yielded a CI run that appears to have tried to run every environment on every Python version, rather than only the specified environments for each Python version.

Do you have a repro? PR to fix it is welcomed.

The linked config files and GH Actions output in the initial comment show my attempt to use this plugin, and the result. I don't have a more minimal reproduction than that at the moment.

That's because this repo was created against the alpha release of tox and supports only v4 from get go.

I understand that part. But it seems like there's been no real activity in the repository for a long time, no new releases that might indicate compatibility with the 4.0 tox release, and some out-of-date things in the documentation (like the README saying to run tox4, when the actual 4.0 release of tox does not have a tox4 command-line entry point -- only plain tox).

That's because I've been busier with tox 4 core issues than this extension. If someone would fill in a PR I'd take a look though. I'm only one person doing it in their free time so 🤷

@ubernostrum By now you should know how open-source works. If my hint was not enough, let me be more explicit: if you want something to happen you better start doing it yourself (contributing) or pay someone to do it for you.

@ssbarnea I'm not sure why the simple question -- whether or not this plugin is maintained -- warrants such a response. But don't worry, you won't have to deal with any further interactions from me.


Fix broken homepage & repo links

Thanks!
Since this PR was created before I had added the license files, if you could just comment that you acknowledge them, I can go ahead and merge this.

I acknowledge that I have read and accept the license of this project and accept to have my (miniscule) present and any future contributions be licensed under MIT or Apache as the author of this repo has decided.


[Unsplash] ...The redirect uri included is not valid.

I'm a dummy, disregard.

I have this problem too. Can't seem to fix it. @iodrift what made you a dummy here? haha. I'm probably doing the same thing

Follow the instructions given in the Readme file of the extension.


feat(Lineage): Add support for lineage reporting

@Doe-Ed if the tests pass u can merge and release,
than u would just need to add in airflow the env var USE_LINEAGE
u can see how we did in atlas
https://github.com/YotpoLtd/yotpo-airflow/blob/a8770c23febef2ab4980f30db743a87e4136242c/dags/operators/spark_on_nomad_operator.py#L203


CannotObserveExternalResource on newly-created SecurityGroup

What happened?
When trying to create a SecurityGroup resource with the following contents:
apiVersion: ec2.aws.crossplane.io/v1beta1
kind: SecurityGroup
metadata:
  annotations:
    crossplane.io/external-name: eks-dev-rds
  name: crossplane-rds
spec:
  deletionPolicy: Delete
  forProvider:
    description: Crossplane RDS Security Group for eks-dev
    groupName: eks-dev-rds
    ingress:
    - fromPort: 5432
      ipProtocol: tcp
      ipRanges:
      - cidrIp: <IP_ADDRESS>/16
      toPort: 5432
    region: us-west-2
    vpcId: vpc-XXXX
  writeConnectionSecretToRef:
    name: crossplane-rds-sg
    namespace: crossplane-system

... after describing the resource I see the following:
Warning  CannotObserveExternalResource  5s (x4 over 10s)  managed/securitygroup.ec2.aws.crossplane.io  failed to describe SecurityGroup: api error InvalidGroupId.Malformed: Invalid id: "eks-dev-rds" (expecting "sg-...")

This seems to indicate that Crossplane is attempting to reference the group by its name rather than its Id. I've seen other similar tickets ( such as #1316), but none that seem to occur in such a simple usage of the resource. Please let me know if there's any additional info I could provide that could be of use :)
P.S. I should also mention that it doesn't seem like the Security Group is actually created on the AWS side.
How can we reproduce it?
In theory, simply applying the above resource, replacing vpcId with something appropriate should suffice.
What environment did it happen in?

Component
Version

Crossplane AWS Provider
0.31

Crossplane (Helm Chart)
1.9.0

EKS
1.22

I've already verified that crossplane has appropriate permissions to provision RDS DBInstance resources (it has full *:* on all AWS resources) so I know it's not a general permissions issue.

Ah just noticed something interesting. It looks like SecurityGroup resources don't like when you set both groupName and the crossplane.io/external-name annotation. Removing the annotation allowed the group to be created without issue.
I guess the question now is whether this is intended behavior.

aws generated the id for securitygroup - thats why you get the issue with crossplane.io/external-name ...


TextDocument extensionAPI documentation gives error

I'm not sure why this page is failing, it told me to report the issue here.

VSCode Version: N/A
OS Version: macOS, Chrome 58

Steps to Reproduce:

Go to https://code.visualstudio.com/docs/extensionAPI/TextDocument
Error Message "Sorry! We seem to be having technical issues"

@skyllo
The correct URL is https://code.visualstudio.com/docs/extensionAPI/vscode-api#TextDocument.
Where did you find this link reference?

Thanks! The document link on this method.


BINDTO should work without an explicit port 0

See https://github.com/amphp/artax/issues/100

This is implemented in #29.


Common namespace for enums

Looking at the various components I believe there will be some commonality with the enums.
For instance Persona and OrgChart will share enums like presence and style.
What does everyone think about putting them (or all enums for consistency) in either the core namespace or one dedicated for these datatypes?

Could OrgChart reuse the Persona directive making it unnecessary to duplicate the enums?

I've wondered the same thing like with the IconEnum that's in uif-icon. If uif-org-chart can depend on uif-persona for rendering and code reuse, then I say it stays with Persona. However if not and it's truly something that can be reused, I would put them in the root of the officeuifabric.core module.
FWIW, I've got a personal task to create enums in the officeuifabric.core for all color, animation & font size options. They would simply be used for developers to get strong naming of CSS classes. I think the color & animation ones are really the useful ones... font size won't get user much from code.

Where does this stand @johnmeilleur ... reuse within existing directive or move to core?

Since they are really about the persona I agree as suggested we leave them in with the persona directive and other directives (e.g. orgchart) can reference as necessary.

LGTM


feat(cdk-scrollable): add methods to normalize scrolling in RTL

Technically a major change due to tightening the ElementRef to ElementRef<HTMLElement>

PTAL, comments addressed


git-blame-ignore-revs: fix typo

Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Oh no, this is not a typo. It says:

To not have to set the option in every repository it is needed in,
save the following script in your path with the name "git-bblame"

So git-bblame is the name of the script.


runtime: "go test -short -cpu=1,2,4" command takes too long

Build fails sometime http://build.golang.org/log/0f5d58c2d0ba874ec4e387ad5a6cc9c6972b6aa0
##### GOMAXPROCS=2 runtime -cpu=1,2,4
panic: test timed out after 10m0s

goroutine 208730 [running]:
testing.startAlarm.func1()
	C:/workdir/go/src/testing/testing.go:717 +0x139
created by time.goFunc
	C:/workdir/go/src/time/sleep.go:129 +0x41
FAIL	runtime	600.049s
2015/12/16 20:45:49 Failed: exit status 1

Alex

I think @aclements is on this.

Possible dup of #13642.

Also maybe "go test -short -cpu=1,2,4" DOES take too long. Maybe we should create a CL (with some failure in it), that runs "go test -short -cpu=1,2,4 -v" instead of "go test -short -cpu=1,2,4" to see if some runtime test is too long.
Alex

Sometimes is does take a long time. Just using the failure logs we already have, here are the last 50 (successful) times that are over 120s. The worst amd64 time is only 145s, though, which suggests the 10 minute timeout is a freeze.

Build
runtime -cpu=1,2,4 time

2015-11-16T22:07:41-4d39bb6/linux-ppc64le-canonical
128.058s

2015-11-17T02:20:02-095710b/linux-arm-arm5
417.964s

2015-11-17T02:20:12-2cfde41/linux-arm-arm5
416.192s

2015-11-17T02:20:21-a897684/linux-arm-arm5
417.765s

2015-11-17T02:20:29-6a18122/linux-arm-arm5
411.677s

2015-11-17T02:20:49-36fe6f2/linux-arm-arm5
410.979s

2015-11-17T02:24:49-a8e839b/linux-arm-arm5
408.966s

2015-11-17T02:25:04-e493309/linux-arm-arm5
414.993s

2015-11-17T02:25:11-a10b270/linux-arm-arm5
415.182s

2015-11-18T19:00:45-6bf794a/plan9-386-ducolombier
147.368s

2015-11-20T19:53:41-2a6c773/linux-arm-arm5
418.586s

2015-11-20T19:55:27-7ab4cba/linux-arm-arm5
411.762s

2015-11-20T19:55:36-08ea825/linux-arm-arm5
416.970s

2015-11-23T01:13:04-29a22ab/linux-arm-arm5
423.353s

2015-11-23T01:13:14-0c64370/linux-arm-arm5
410.002s

2015-11-23T01:13:20-aca4fa5/linux-arm-arm5
416.488s

2015-11-23T02:01:20-61e1cae/linux-arm-arm5
413.792s

2015-11-23T02:01:28-2246923/freebsd-amd64-gce101
145.331s

2015-11-23T02:01:28-2246923/linux-arm-arm5
411.732s

2015-11-23T03:10:30-2876020/linux-arm-arm5
411.326s

2015-11-23T04:38:50-bebbc62/linux-arm-arm5
412.200s

2015-11-23T15:16:54-3facf7e/linux-arm-arm5
403.954s

2015-11-24T01:33:14-9f9b95b/linux-arm-arm5
417.509s

2015-11-24T02:18:46-6b26788/linux-arm-arm5
414.911s

2015-11-24T04:33:05-8ad1dc4/linux-arm-arm5
428.638s

2015-11-25T00:46:57-3583a44/linux-ppc64le-canonical
134.865s

2015-12-03T00:18:53-377a8a8/linux-arm-arm5
410.395s

2015-12-03T00:31:00-3cca924/linux-arm-arm5
410.955s

2015-12-03T00:44:15-40cbf58/linux-arm-arm5
421.949s

2015-12-04T01:00:32-5ff82f8/linux-arm-arm5
426.318s

2015-12-05T04:55:02-f25f6ea/freebsd-amd64-gce101
133.447s

2015-12-05T04:55:02-f25f6ea/linux-arm
276.154s

2015-12-05T04:55:02-f25f6ea/linux-arm-arm5
370.523s

2015-12-05T04:55:02-f25f6ea/linux-mips64le-cherry
468.997s

2015-12-05T04:55:02-f25f6ea/linux-ppc64le-canonical
122.623s

2015-12-05T05:46:48-336c998/linux-arm
282.040s

2015-12-05T05:46:48-336c998/linux-mips64le-cherry
528.227s

2015-12-05T05:46:48-336c998/linux-ppc64le-canonical
131.049s

2015-12-05T06:19:47-d2ca451/freebsd-amd64-gce101
126.806s

2015-12-05T06:19:47-d2ca451/linux-arm
268.973s

2015-12-05T06:19:47-d2ca451/linux-arm-arm5
371.975s

2015-12-05T06:19:47-d2ca451/linux-mips64le-cherry
528.252s

2015-12-05T06:19:47-d2ca451/linux-mips64-minux
839.060s

2015-12-05T06:26:17-5b1a8a5/linux-arm
275.702s

2015-12-05T06:26:17-5b1a8a5/linux-arm-arm5
374.833s

2015-12-05T06:26:17-5b1a8a5/linux-mips64le-cherry
528.136s

2015-12-05T06:26:17-5b1a8a5/linux-mips64-minux
834.156s

2015-12-05T06:26:17-5b1a8a5/linux-ppc64le-canonical
132.242s

2015-12-07T22:07:12-e89d3b4/linux-arm-arm5
414.790s

2015-12-16T05:42:40-86f1944/openbsd-386-gce56
123.219s

That is fine, @aclements. I will let you deal with this.
Alex

Let's assume dup of #13642. If you want to try to reproduce with GOTRACEBACK=crash and get full output, that might be helpful. Post it there. Thanks.

I've seen this recently too and reported #13632. And I think I saw it on a builder today -- so I think there is a problem here.

Some recent samples from try bots:
net/http: document ResponseWriter and Handler more; add test

Patch Set 1:

This change failed on windows-386-gce:
See https://storage.googleapis.com/go-build-log/ec63595c/windows-386-gce_8a484fbf.log

net: fix the build even harder

Patch Set 1:

This change failed on linux-amd64-race:
See https://storage.googleapis.com/go-build-log/f0e334d2/linux-amd64-race_7bc08295.log

Another crash, but with more stack trace:
cmd/dist: skip all nolibgcc tests on windows
Patch Set 1: TryBot-Result-1
1 of 15 TryBots failed:
Failed on windows-amd64-gce: https://storage.googleapis.com/go-build-log/6f64c8df/windows-amd64-gce_7c21e23b.log
Alex

I was hoping this would be fixed by 8d5ff2e, which fixed a bug in the StackOverflow test, but it's still happening.

I don't see original crash anymore. But there is new failure happening http://build.golang.org/log/9097c870bd4716e62c87a18648e0bd9da7061abc
panic: test timed out after 6m0s

goroutine 103795 [running]:
testing.startAlarm.func1()
	C:/workdir/go/src/testing/testing.go:719 +0x152
created by time.goFunc
	C:/workdir/go/src/time/sleep.go:129 +0x41

goroutine 1 [chan receive, 5 minutes]:
testing.RunTests(0x6f4fb0, 0x7d4300, 0xb3, 0xb3, 0x7bbf01)
	C:/workdir/go/src/testing/testing.go:577 +0x8c0
testing.(*M).Run(0xc082081ef8, 0x6f5638)
	C:/workdir/go/src/testing/testing.go:509 +0x88
runtime_test.TestMain(0xc082081ef8)
	C:/workdir/go/src/runtime/crash_test.go:24 +0x2f
main.main()
	runtime/_test/_testmain.go:956 +0x11b

goroutine 102753 [chan receive, 5 minutes]:
testing.(*T).Parallel(0xc08204ea20)
	C:/workdir/go/src/testing/testing.go:435 +0xc4
runtime_test.TestStackGrowth(0xc08204ea20)
	C:/workdir/go/src/runtime/stack_test.go:74 +0x2c
testing.tRunner(0xc08204ea20, 0x7d5008)
	C:/workdir/go/src/testing/testing.go:467 +0x9f
created by testing.RunTests
	C:/workdir/go/src/testing/testing.go:576 +0x880

goroutine 102755 [chan receive, 5 minutes]:
testing.(*T).Parallel(0xc08204eab0)
	C:/workdir/go/src/testing/testing.go:435 +0xc4
runtime_test.TestStackGrowthCallback(0xc08204eab0)
	C:/workdir/go/src/runtime/stack_test.go:157 +0x2c
testing.tRunner(0xc08204eab0, 0x7d5020)
	C:/workdir/go/src/testing/testing.go:467 +0x9f
created by testing.RunTests
	C:/workdir/go/src/testing/testing.go:576 +0x880

goroutine 102754 [chan receive, 5 minutes]:
testing.RunTests.func1(0xc0820282a0, 0xc08204ea20)
	C:/workdir/go/src/testing/testing.go:580 +0x4e
created by testing.RunTests
	C:/workdir/go/src/testing/testing.go:581 +0x921

goroutine 103793 [runnable, locked to thread]:
syscall.Syscall(0x76e75e28, 0x2, 0x464045, 0x6f6118, 0x0, 0x4110f9, 0x10, 0x660240)
	C:/workdir/go/src/runtime/syscall_windows.go:128 +0x5c
syscall.(*Proc).Call(0xc0820ea080, 0xc0820e1e80, 0x2, 0x2, 0xc0820e1e98, 0x2, 0x0, 0x0)
	C:/workdir/go/src/syscall/dll_windows.go:132 +0x391
runtime_test.nestedCall(0xc08204e1b0, 0x6f6118)
	C:/workdir/go/src/runtime/syscall_windows_test.go:166 +0x144
runtime_test.TestCallbackPanic(0xc08204e1b0)
	C:/workdir/go/src/runtime/syscall_windows_test.go:221 +0x14e
runtime_test.TestCallbackPanicLoop(0xc08204e1b0)
	C:/workdir/go/src/runtime/syscall_windows_test.go:228 +0x37
testing.tRunner(0xc08204e1b0, 0x7d52c0)
	C:/workdir/go/src/testing/testing.go:467 +0x9f
created by testing.RunTests
	C:/workdir/go/src/testing/testing.go:576 +0x880

goroutine 102756 [chan receive, 5 minutes]:
testing.RunTests.func1(0xc0820282a0, 0xc08204eab0)
	C:/workdir/go/src/testing/testing.go:580 +0x4e
created by testing.RunTests
	C:/workdir/go/src/testing/testing.go:581 +0x921
FAIL	runtime	360.077s
2016/01/04 19:34:39 Failed: exit status 1

that looks similar.
Alex

I could be wrong, but my current hunch is that the runtime test is a red herring. I think t.Parallel() may be broken. There are only three places where we use it in the standard library: runtime, net, and net/http. Looking through recent failures, these are the packages we see timing out, and they time out with the tests marked t.Parallel() waiting on the channel that tells them to go.

2016-01-13T14:02:22-ceeb52d/linux-arm64-linaro: TestStackCache is stuck (non-Parallel test). Lots of runnable goroutines at the beginning of runtime_test.growing. Maybe something wrong with stack growth? TestFutexsleep is done, but two goroutines spawned from it are still running (presumably in the futex sleep). TestStackGrowth and TestStackGrowthCallback are waiting for the parallel phase.
2016-01-13T14:02:22-ceeb52d/linux-arm64-canonical: RunTests is in fmtDuration -> fmt.Sprinf -> prologue of fmt.(*pp).doPrintf in state runnable. Maybe also stuck growing the stack? TestFutexsleep, TestStackGrowth and TestStackGrowthCallback are identical to failure 1.
2016-01-13T04:49:19-4ffba76/linux-amd64-nocgo: Regular runtime test. Otherwise identical to failure 2.
2016-01-12T17:31:01-505fa7b/linux-ppc64le-canonical: Regular runtime test. RunTests is in fmtDuration in "GC assist wait".

There's also a recent timeout not in the runtime test. It might be unrelated:
2016-01-12T02:00:48-352e287/linux-amd64-race: Timeout in net/http. No obvious culprit; everybody is waiting on everyone else.

The leftover Futexsleep goroutines are unrelated and should be fixed by https://go-review.googlesource.com/18617.

I cannot reproduce failures we see on windows builders here on my computers. I run selected runtime tests in a loop. If you have suggestions on how to break things here, I might help more. Maybe tiny sleep here or there?
Alex

I wish I did. I spent all day trying to reproduce this on a linux-amd64-nocgo gomote and somehow haven't succeeded. It shows up frequently enough on the dashboard for this builder that I'm rather perplexed.

I ran a go test -short std loop all night on a linux-amd64-nocgo gomote and still no luck reproducing. I'm going to try lifting the loop level to create and tear down the VM itself. Maybe this has something to do with where the VM lands.
VM=$(gomote create linux-amd64-nocgo)
gomote push $VM
gomote run $VM 'go/src/make.bash'
gomote run $VM /bin/sh -c 'PATH=$PWD/go/bin:$PATH; cd go/src; while true; do GOTRACEBACK=crash go test -short std; done'

I've now run over 200 cycles of create VM/go test std/destroy VM and still haven't reproduced this.

2016-01-12T02:00:48-352e287/linux-amd64-sid: Lots of runnable goroutines in the prologue of runtime_test.growing
2016-01-12T17:31:01-505fa7b/linux-ppc64le-canonical: GC assist wait in testing.fmtDuration:256 +0x108 (call to runtime.convT2E with a nil x, so it allocates)
2016-01-13T04:49:19-4ffba76/linux-amd64-nocgo: Runnable in fmt.(*pp).doPrintf prologue
2016-01-13T14:02:22-ceeb52d/linux-arm64-canonical: Runnable in fmt.(*pp).doPrintf prologue
2016-01-13T14:02:22-ceeb52d/linux-arm64-linaro: Lots of runnable in runtime_test.growing prologue
2016-01-13T18:22:21-b2cf5e7/dragonfly-amd64: Runnable in runtime_test.growStackIter progloue and runtime_test.TestStackGrowth.func3:111 +0x287 (call to runtime.selectgo, which can allocate sudogs)
2016-01-13T18:39:15-9094e3a/linux-amd64-sid: Runnable in regexp.(*Regexp).doExecute prologue
2016-01-13T19:06:28-dd6753a/windows-amd64-gce: Runnable in syscall.loadlibrary:98 +0x66 (call to runtime.cgocall)
2016-01-13T19:06:40-4a0eee2/linux-amd64-nocgo: Lots of runnable in runtime_test.growing prologue
2016-01-13T19:06:40-4a0eee2/linux-ppc64le-canonical: Runnable in testing.fmtDuration:256 +0x108 (call to runtime.convT2E with a nil x, so it allocates)
2016-01-13T19:06:40-4a0eee2/windows-386-gce: Runnable in syscall.Syscall:128 +0x4a (call to runtime.cgocall)
2016-01-13T19:10:31-00c0a3a/linux-amd64: Lots of runnable in runtime_test.growing prologue
2016-01-13T23:07:40-8c9ef9d/windows-amd64-gce: Runnable in syscall.Syscall:128 +0x5c (call to runtime.cgocall)
2016-01-14T02:04:50-5f23bc8/windows-amd64-gce: Runnable in syscall.Syscall:128 +0x5c (call to runtime.cgocall)
2016-01-14T02:05:31-535741a/windows-386-gce: Runnable in syscall.Syscall:128 +0x4a (call to runtime.cgocall)
2016-01-14T03:08:30-353ee32/windows-amd64-gce: Runnable in syscall.getprocaddress:113 +0x66 (call to runtime.cgocall)
2016-01-14T03:16:20-b73d8fb/linux-amd64-noopt: Lots of runnable in runtime_test.growing prologue
2016-01-14T04:01:47-f36ee8c/linux-amd64-noopt: Runnable in fmt.glob.func1:128 +0x2f (call to runtime.newobject).
2016-01-14T15:23:41-38ca046/linux-arm64-linaro: GC assist wait in fmt.glob.func1:128 +0x2c (call to runtime.newobject)
I'm not sure what's happening on Windows, but on the other platforms every single timeout has a goroutine in state "running" that's in a context where it could be allocating, or it clearly is trying to allocate and is blocked in an assist.

I'm not sure what's happening on Windows, ...

Do not forget that all windows failures we see are around Windows callbacks. There is a lot of unsafe (and asm) code there. I wouldn't be surprised if some recent runtime changes affected that.
Alex

I looked at Windows a little more closely and those failures are also in a context that might be allocating (because of the defer statement in cgocall).
Hopefully we'll have much more information once a few more failures show up on the dashboard with 1556c31 applied.

I managed to reproduce this by repeatedly running the trybots on https://go-review.googlesource.com/#/c/18646/ and https://go-review.googlesource.com/#/c/18680/. These show runtime frames. Unfortunately, for reasons I don't understand, this didn't traceback at "crash" level, so some tracebacks are still hidden.
Some interesting cases:
https://storage.googleapis.com/go-build-log/390e0725/windows-amd64-gce_4122b0f2.log: Shows a cgocall mallocing and assisting and getting stuck in the assist. Interestingly, the goroutine is shown as "runnable", not "GC assist wait", which indicates we woke the goroutine but it never actually ran again. My best guess is that there's an issue with us putting that goroutine on the global run queue and never pulling it off the global run queue. However, the background sweeper is also runnable and in Gosched, which indicates a few things: GC is definitely over, at least some scheduling happened after GC started the world again, and there's almost certainly a G on a local run queue. However, it also looks like the system has been wedged for at least five minutes, which is more than enough time for the background sweeper to finish, suggesting that the scheduler lost track of both the background sweeper
and the assist. The scheduler isn't completely wedged, though, because it ran the timeout goroutine.
https://storage.googleapis.com/go-build-log/763ec68b/windows-amd64-gce_7689e79d.log:  A runtime test timeout, but probably unrelated to the GC problem since GC appears to be completely idle and there are no assists running.
https://storage.googleapis.com/go-build-log/7647f2db/windows-amd64-gce_e5e4abda.log: Same.
https://storage.googleapis.com/go-build-log/7d903bfa/linux-amd64_d3fa644c.log: User goroutine is stuck in the GC assist wait park. There's a running background mark worker, which, unfortunately, didn't show a traceback. The stuck mark worker is presumably why the system isn't making progress.
I've started the same cycle on https://go-review.googlesource.com/18681 but with the traceback level set more aggressively to crash. I'll probably add some scheduler debugging to it.

Got a reproduction with GOTRACEBACK=crash (but unfortunately not the scheduler debug dump I added because it was killed by the infrastructure, not from within): https://storage.googleapis.com/go-build-log/f7c7c056/darwin-amd64-10_10_795d2e74.log
Goroutine 53 is parked in a GC assist wait and has been for at least 3 minutes. Goroutines 67 and 74 are actively running mark workers. 74 is on M 8 trying to stop the world but is stuck in the loop waiting for other Ms to voluntarily stop. 67 is presumably the one preventing it. Unfortunately, 67 doesn't obviously appear in any of the other thread tracebacks, which is confusing because all of the other threads are clearly at points where they would have switched their Gs out of _Grunning.

Another failure on the dashboard, now with "system" level tracebacks for runtime failures: 2016-01-16T02:40:00-b05f18e/linux-ppc64-minux
None of the goroutines are in assists and the background mark workers are idle. Other than the alarm goroutine, only two goroutines are runnable: the background sweeper is in Gosched and the main test thread is in the prologue of fmt.Sprintf. These are both weird. Based on the other goroutines, there almost certainly hasn't been GC activity for 19 minutes, so the background sweeper has had oodles of time to finish. fmt.Sprintf could have stopped either because it needed to grow its stack or because of a preemption. I don't think it needed to grow its stack because the calling frame was already past the first doubling boundary (the stack size in the caller is 0xc820037f80 - 0xc820037910 = 1648 bytes and the first boundary should be 2048 - 720 + 128 = 1456) and it's nowhere near the next boundary (4096-720+128=3504). That means it got preempted, which calls gopreempt_m, which puts it in to _Grunnable (consistent with the traceback) and puts it on the global queue.
Since both goroutines are on the global run queue, this again points at some issue with scheduling things from the global queue.

In nearly every case, one of the goroutines that is runnable or in "GC assist wait" is also "locked to thread". This happens in Linux on the main testing thread because of the init function in runtime_linux_test.go. It happens on Windows in the test that we see freezing (I'm not sure why; I assume because of the callback). It also happened in the Darwin failure because the wedged test, TestTraceStressStartStop, calls LockOSThread.

Finally a timeout with a snapshot of the scheduler state: https://storage.googleapis.com/go-build-log/8ecdfe49/windows-amd64-gce_e20c47a0.log. GC is not running and has not run for over five minutes. Both P run queues are empty (one is idle, the other is running the alarm goroutine). The two runnable goroutines (background sweeper and a cgocall) are on the global run queue and must have been stuck there for several minutes. The stuck cgocall is "locked to thread".

The same runtime -cpu=1,2,4 test also occasionally hang on the ppc64 builder.
For example,
http://build.golang.org/log/8db41f218ad62ec3ba3b8117b521fda2984b0340

So, @aclements, how can that happen? :-)
A few thoughts, perhaps none of them useful.

It looks to me like there are two different p's both with gcMarkWorkerMode == gcMarkWorkerFractionalMode. That seems wrong: I thought there would be only one worker dedicated to being a fraction at any given time.

It looks like the "we lost a race" here would explain having two fractional workers:
decIfPositive := func(ptr *int64) bool {
	if *ptr > 0 {
		if atomic.Xaddint64(ptr, -1) >= 0 {
			return true
		}
		// We lost a race
		atomic.Xaddint64(ptr, +1)
	}
	return false
}

I don't see any actual harm caused by having two fractional workers in the code. Eventually one will die and not be replaced (until the next race). But still it seems scary and could be avoided with a Cas if we understood how it explained real damage.

gcphase is 0. Why are there any fractional workers in that case? The GC that kicked off the fractional workers must have finished to get to gcphase 0. How did it finish with the fractional workers still thinking they should run?

I see assignments that set p.gcMarkWorkerMode but nothing that clears it. Also gcMarkWorkerDedicatedMode == 0, which is a little odd for distinguishing "not a worker" from "a worker". But maybe code only looks at that field if it knows it is a worker, in which case the two p's with fractional mode could both be stale, with neither actually being a worker.

All cgocalls lock the goroutine to the thread for the duration of the call, in case of cgo callbacks. When a goroutine is locked to a thread, that thread bails out of func schedule very early. It does not even reach the code thinking about being a GC worker. It's possible that the thread ran a GC worker earlier, before being locked, but that worker is preempted if we're doing the cgo call. And then the worker is attached to the p, which will be released elsewhere while the cgo call is blocked. And the GC finished.

The stack trace doesn't show us where the cgo call goroutine is blocked. It will show the entersyscall information until gp.syscallsp is cleared after the goroutine is cleared to run. But I don't see any way it can block during entersyscall, so it must be blocked in exitsyscall.

System stacks would be nice. Since this seems to happen mainly on Windows, I wonder if we can adapt os1_windows.go's profileloop1/profilem into something that will give us the same thread stacks we now can get on Unix.

For 1, 2, and 3, you're right that it wouldn't be intentional for multiple fractional workers to be running at the same time, but we never clear gcMarkWorkerMode, so these are just stale values, gcMarkWorkerMode is a one time communication from the scheduler at wakeup of what type of worker a worker should be. We didn't even have to lose the decIfPositive race. One fractional worker could have parked before we started the other one.
4 is interesting. I strongly suspect locked goroutines are part of this. I hadn't thought about how that skips specifically the worker scheduling code. OTOH, in https://storage.googleapis.com/go-build-log/8ecdfe49/windows-amd64-gce_e20c47a0.log the workers are parked in their usual spot and GC isn't active, so it shouldn't have scheduled any workers anyway.

The locking of goroutines concern threads, not p's, so the fact that it skips the worker scheduling code shouldn't really matter. The locked thread (m) will park itself and some other m will get to run. Not that this helps.

I finally managed to reproduce this outside of the build system! Last night I got 3 failures out of 187 runs on the windows-386-gce builder using the following script
#!/bin/zsh

VM=$(gomote create windows-386-gce)
if [[ -z $VM ]]; then
    echo "VM creation failed"
    exit 0
fi
STATUS=0
pushlog=$(mktemp)
if ! gomote push $VM >& $pushlog; then
    echo "Push failed:"
    cat $pushlog
    STATUS=1
elif ! gomote run $VM go/src/all.bat; then
    echo "Run failed"
    STATUS=1
fi
rm $pushlog
gomote destroy $VM
exit $STATUS

run as parallel -j 10 ./test1 :::: <(seq 200) with the following modification to all.bat to run only the parallel runtime test:
diff --git a/src/run.bat b/src/run.bat
index 01a66bc..2f4ab00 100644
--- a/src/run.bat
+++ b/src/run.bat
@@ -37,7 +37,7 @@ call env.bat
 del env.bat
 echo.

-go tool dist test
+go tool dist test runtime:cpu124
 if errorlevel 1 goto fail
 echo.

Next steps are to narrow this down a bit and to see if the same approach works on a Linux builder where it's easier to debug things.

Reproduced in 2 out of 230 iterations across 13 windows-386-gce VMs with a loop around go tool dist test:
for /l %%x in (1, 1, 50) do (
    go tool dist test runtime:cpu124
)

Reproduced once out of 135 linux-amd64-noopt VMs with the equivalent Linux change to https://github.com/golang/go/issues/13645#issuecomment-176230977

Reproduced 2 out of 147 iterations across 6 linux-amd64-noopt VMs with the equivalent of https://github.com/golang/go/issues/13645#issuecomment-176285999

I was able to collect some core dumps from this. I took the core dumps without allowing the freezetheworld and various other things that happen in the panic handler and, interestingly, the story they tell is rather different from the time out tracebacks.
Here's a representative example:
G state:
       1 waiting (GC assist wait), m 0 (locked to thread)
         started at runtime.main
         created by runtime.rt0_go
       2 waiting (force gc (idle))
         started at runtime.forcegchelper
         created by runtime.init.4
      17 syscall, m 1 (locked to thread)
         started at 0x0
         created by 0x0
      18 waiting (GC sweep wait)
         started at runtime.bgsweep
         created by runtime.gcenable
      19 waiting (finalizer wait)
         started at runtime.runfinq
         created by runtime.createfing
      20 syscall, m 11
         started at runtime.timerproc
         created by runtime.addtimerLocked
     112 waiting (GC worker (idle))
         started at runtime.gcBgMarkWorker
         created by runtime.gcBgMarkStartWorkers
  207479 waiting (GC worker (idle))
         started at runtime.gcBgMarkWorker
         created by runtime.gcBgMarkStartWorkers
  207598 waiting (chan receive)
         started at testing.tRunner
         created by testing.RunTests
  207599 waiting (chan receive)
         started at testing.RunTests.func1
         created by testing.RunTests
  207600 waiting (chan receive)
         started at testing.tRunner
         created by testing.RunTests
  207601 waiting (chan receive)
         started at testing.RunTests.func1
         created by testing.RunTests

M state:
       0 PID 28287, g 1, blocked, locked to thread
       1 PID 0, g 17, locked to thread
       2 PID 28290, blocked
       3 PID 28291, blocked
       4 PID 28292, blocked
       5 PID 28293, blocked
       6 PID 28294, blocked
       7 PID 28295, blocked
       8 PID 28296, epollwait
       9 PID 28297, blocked
      10 PID 28298, blocked
      11 PID 29459, g 20, blocked
      12 PID 29460, blocked
      13 PID 29461, blocked
      14 PID 29462, blocked

P state:
       0 idle, mark worker g 112
         runq: <empty>
       1 idle, mark worker g 207479
         runq: <empty>

global runq: <empty>

All of the Gs are waiting and all of the Ms are blocked. Notably, the main G is blocked in an assist and no workers are running and everything else is waiting, so nothing schedules a new worker and no worker satisfies the assist.
GC is in mark 2. work.full is empty, but only 2 of 4 mark root jobs have completed, so there is still GC work to be done. In this situation, since there are only two Ps, it's possible that no fractional worker would be scheduled, but I would expect idle workers to keep things going. The lack of idle workers indicates that we somehow failed to satisfy the idle worker start condition on all of the Ps simultaneously just before they all blocked. My best guess is that the workers were detached, but I haven't been able to come up with a sequence that would cause this, and as of the core file all Ps have workers.
A few things worth trying to see if they amplify the chance of this happening: Add delay between detaching and gcMarkDone to encourage the workers to simultaneously detach. Disable fractional and dedicated workers to force everything through idle workers.
For debugging, it may help for the Ps to record some of the state of the world before they go idle, like why they didn't start an idle worker.

The following patch exacerbates the problem with locked Gs by locking all Gs. In theory this should work, but it causes the runtime test to regularly freeze in much the same way as seen in these test failures. (It also causes TestMainGoroutineID to fail for uninteresting reasons.)
diff --git a/src/runtime/proc.go b/src/runtime/proc.go
index 2bc3c92..cfb1172 100644
--- a/src/runtime/proc.go
+++ b/src/runtime/proc.go
@@ -2647,6 +2652,8 @@ func newproc(siz int32, fn *funcval) {
        })
 }

+var lockOSThreadFunc uintptr
+
 // Create a new g running fn with narg bytes of arguments starting
 // at argp and returning nret bytes of results.  callerpc is the
 // address of the go statement that created this.  The new g is put
@@ -2703,6 +2710,10 @@ func newproc1(fn *funcval, argp *uint8, narg int32, nret int32, callerpc uintptr
        newg.sched.pc = funcPC(goexit) + sys.PCQuantum // +PCQuantum so that previous instruction is in same function
        newg.sched.g = guintptr(unsafe.Pointer(newg))
        gostartcallfn(&newg.sched, fn)
+       if lockOSThreadFunc == 0 {
+               lockOSThreadFunc = funcPC(LockOSThread)
+       }
+       gostartcallfn(&newg.sched, (*funcval)(unsafe.Pointer(&lockOSThreadFunc)))
        newg.gopc = callerpc
        newg.startpc = fn.fn
        if isSystemGoroutine(newg) {

I've been stressing https://go-review.googlesource.com/19107 for over two hours across 10 VMs and so far none of the 1,242 runs has failed.


Install fails on Apache 2.9.4 due to a Key issue

Issue Type

Bug Report / Support Request

Your Environment

Windows (10 Pro 10.0.16299)

Full console output

https://gist.github.com/chumkui/88f3b62c79ac00920078ac65da03f0b2
Summary

Did a rebuild today and it failed when installing Apache 2.4 - it has previously been working fine.  I have not seen this error before.

OK - I managed to get around this by manually installing the key first - I ssh'd into the machine and ran:
sudo apt-key adv --recv-key --keyserver keyserver.ubuntu.com 14AA40EC0831756756D7F66C4F4EA0AAE5267A6C
The key installs fine, but does not using the DVM installer:
sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 14AA40EC0831756756D7F66C4F4EA0AAE5267A6C
Not an area of expertise for me, but I am at least up and running again. As far as I am aware there are no firewall issues.

I haven't seen this issue elsewhere and can't reproduce it locally, so I'm wondering if it might've also been a temporary issue with the upstream packages.
Since you have a workaround (manually adding the key), I think that should suffice if this happens again; if you have it happen again (same error(s)), please post another issue and we'll take a deeper look.


[JENKINS-38832] Add support for credential tracking.

https://issues.jenkins-ci.org/browse/JENKINS-38832

Possible null pointer dereference in hudson.plugins.sshslaves.SSHLauncher.launch(SlaveComputer, TaskListener) due to return value of called method [hudson.plugins.sshslaves.SSHLauncher, hudson.plugins.sshslaves.SSHLauncher] Method invoked at SSHLauncher.java:[line 745]Known null at SSHLauncher.java:[line 744] NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE
Nullcheck of node at line 745 of value previously dereferenced in hudson.plugins.sshslaves.SSHLauncher.launch(SlaveComputer, TaskListener) [hudson.plugins.sshslaves.SSHLauncher, hudson.plugins.sshslaves.SSHLauncher] At SSHLauncher.java:[line 745]Redundant null check at SSHLauncher.java:[line 746] RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE

@iwarapter pong

@oleg-nenashev Sorry i forgot to push the change after @jglick's comment

👍  on bumping the core dep to align with credential's core dep

Any update on this guys?

@iwarapter there is a merge conflict. It would be great if you could fix it (though a plugin maintainer can do it as well)

@oleg-nenashev this is updated now.

Yes, I've seen the update. Now it needs an action from a maintainer. CC @olivergondza and @jglick

Fixed the merge conflict

Now it's ready to go


Huobi ETH/BTC limitOrder failed

Huobi.pro api renewaled.
ETH/BTC, BCC/BTC, LTC/BTC currency is not available.

We need more information than that. What's the exact issue?

Huobi has been removed from XChange


Implement focused and pending groups

This resolves #19, resolves #21 and bring a lot of changes internally.
Example groups can now be tagged and its children will automatically inherit
those tags. before, after and around hooks now gets called for every
example group as well.

Current coverage is 88.56%

Merging #27 into master will increase coverage by +0.31% as of b45d970

@@            master     #27   diff @@
======================================
  Files           23      24     +1
  Stmts          383     411    +28
  Branches        63      73    +10
  Methods          0       0
======================================
+ Hit            338     364    +26
- Partial         18      24     +6
+ Missed          27      23     -4

Review entire Coverage Diff as of b45d970

Powered by Codecov. Updated on successful CI builds.


Invalid argument supplied for foreach()

New install of Community Store (<IP_ADDRESS>) on concrete<IP_ADDRESS> and get this error when attempting to add a product....
Invalid argument supplied for foreach()

Sorry about this one, I'd recently reworked the way product categoires are handled and hasn't tested it well enough. Should be fixed with https://github.com/concrete5-community-store/community_store/issues/131

Thanks!


Avoid generating email/domain_word with non-ascii

In ja and other locales using non-ascii characters,
generating emails and domains from the faker name
results in non-ascii emails and domains.
Such email and domains are invalid, because they contain non-ascii
characters.
Faker::Config.locale = :ja
Faker::Internet.email #=><EMAIL_ADDRESS>
So, if first_name and last_name is non-ascii characters,
we use fist_name and last_name in locale :en.

Fixed in 7f01954


Push up the Default bound on HashEngine in order to better support keyed hash functions

Backstory for this patch is in #3084, and this might be enough to close that issue, but I think some follow up work might be required.
I took @Kixunil's advice and pushed up the Default bound on HashEngine all the way to the default methods themselves on the GeneralHash trait. I initially placed the bound just on the assocated type Engine of GeneralHash, which is a tad cleaner and keeps the bound from "leaking" downstream into things like Hmac and Hkdf implementations. However, that restricts GeneralHash implementations to just unkeyed hash functions and I believe there will be value in having Poly1305 and SipHash24 still leverage the interface. I struggled a bit on the best spots to put these bounds (even found the syntax a little jarring at times, I found RFC2289 helpful if others do too).
Refactored the existing keyed hash function, SipHash24, to no longer have Default functions with zero-value keys. I kept the test coverage though by just hardcoding the zero-value keys over in the tests.
Refactoring the hash_type macro for keyed hashes was getting a little hairy, so backed off and just wrote the bare minimum for SipHash24 inline. Once Poly1305 lands there will be two keyed hash functions and I think it will make more sense to then generalize over them.

@tcharding let me know if this is inline with the vision for general hash, happy to iterate on it.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>9
Details

45 of 61 (73.77%)  changed or added relevant lines in 4 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.03%) to 83.188%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

hashes/src/lib.rs
10
11
90.91%

hashes/src/siphash24.rs
17
32
53.13%

Files with Coverage Reduction
New Missed Lines
%

hashes/src/siphash24.rs
1
92.2%

Totals

Change from base Build<PHONE_NUMBER>8:
-0.03%

Covered Lines:
19693

Relevant Lines:
23673

💛  - Coveralls

concept ACK 67485804d056a3ed30b97ecba430bc65ddc73cf5
At first some of the new Default bounds looked unnecessary but after looking more closely I think they're necessary.
As an interesting side effect of this you can no longer construct a "HMAC-unkeyed-siphash" which is probably a good thing :).

At first some of the new Default bounds looked unnecessary but after looking more closely I think they're necessary.
As an interesting side effect of this you can no longer construct a "HMAC-unkeyed-siphash" which is probably a good thing :).

Yea, it felt a little weird at first, but glad it checks out. I think once there are two keyed hash functions it will lead to a little more cleanup.

Looks good but I'd prefer to either not reformat the code or put reformatting as a separate commit.

My bad, didn't notice that I fell off the nightly toolchain. Reverted the formats.


Bracket Matching Does Not Work For Inner Languages

Playground Code:
// The Monaco Editor can be easily created, given an
// empty container and an options literal.
// Two members of the literal are "value" and "language".
// The editor takes the full size of its container.

monaco.editor.create(document.getElementById('container'), {
	value: "```js\n()\n```",
	language: 'markdown'
});

Notice how brackets are not matched:

I believe this is caused by this commit @alexdima (it works with the nightly release before):
https://github.com/microsoft/vscode/commit/cc527241

come on ！I need this feature urgently ！

Once https://github.com/microsoft/vscode/pull/175331 lands in main, we can adopt onLanguageEncountered for loading up configuration files.


[JENKINS-31831] Make referer URL pattern more permissive

Needed for https://github.com/jenkinsci/workflow-cps-plugin/pull/12.
@reviewbybees

:bee:

:bee: