Support copy single step as Cypress script

Chrome 109 launches a new "Copy a single step as script" feature.
How to test

In a recording, right click on a step, select copy as [your extension] script option.

Action required

Your extension needs to implement the stringifyStep API for this feature to work.
You can test this feature with the latest Chrome Canary

This is great! Thanks for the heads up

I have put up a PR here https://github.com/cypress-io/cypress-chrome-recorder/pull/41 (will look into signing the CLA later this week)


"Plate to plate" operation cuts are not recognized by Grasshopper components and "Deconstruct Cut" flattens data

I'm using <IP_ADDRESS>3 and 0.1.6.
I have three connections here that are fed into the Grasshopper components at the same time.
On the left is N3 with a "cut by work plane" and "End plate" operation.
Middle is N4 with a "Plate to plate" operation.
On the right is N5 with a "Plate to plate" operation.

This one is the "Plate to plate" operation.

In Grasshopper we see that only the "End plate" operation cut exists. "Plate to plate" operation cuts are missing. "Plate to plate" operation should create two cuts. One for each member.

These connections are going through the following pathway:

Reference Connection
Extract IOM Container
Modify Open Model
Deconstruct Open Model

Connections/SAF/script are attached.
Second issue is that there is some error with the "Deconstruct Cut" component although it does give me the "CM3 is cut by plate EP2" which is actually correct for connection N3. It also appears to force flatten data which means plate cut data trees are not properly generated which means it cannot be used for bulk connection geometry generation for Tekla.
PP - Connections.zip

Hi @tbyrk,
You are correct. I am transferring this to the development team. I will get back to you.
Cheers
Nathan

@tbyrk, Can you please now try with the latest release? (24.0.2) We have added some additional cut outputs. It is getting flattened incidentally by a grasshopper. The component runs until it hits the null reference error.

Before I get to the stiffening members I stumbled upon this. There is no "Location" output now. How to get the point coordinates from the Goo object "Ref Point"?

I'm still having issues with the "Deconstruct Connected Member" cut planes data tree structure. I have three connections in the input. All other components understand that it means three branches of data but cut planes output gives each member a separate branch (two members per connection = six branches in this case).
For example for anything else the script understands that all connection 1 elements should be moved by (6000,0,7000), connection 2 elements by (0,0,5000) and connection 3 elements by (12000,0,5000). But since the cut plane output has a separate branch for each member then the connection 2 ID=1 element (third in the list) gets moved by connection 3 coordinates instead of connection 2 coordinates.

Hi @tbyrk, I have updated a new version that allows casting the point ref to a Rhino point. Regarding the cuts. This is more of an issue on the IOM data structure rather than a grasshopper issue. We will hopefully improve the way we are storing plane cuts in IOM - I don't want to go away from IOM for the time being. The problem is that a connected member can have multiple cuts (list) which causes appending of branches for each member.   See attached and a script below. Regarding the planes for the member cuts. Plate View outputs the front and back planes already I added this to the script aswell.
(PP - Script_nl.zip)

Closing issue.


How to handle mergeInFieldsFromFragmentSpreads with imperative store api

I was investigating updating to the most recent version of apollo codegen to add support for query operation ids. The new version has a cool - but maybe problematic feature -- fragments get spread onto their containing type:
consider:
query HeroAndFriendsWithFragments($episode: Episode) {
  hero(episode: $episode) {
    ... HeroWithFriendsFragment
  }
}

fragment HeroWithFriendsFragment on Character {
  id
  name
  friends {
    ... HumanWithIdFragment
  }
}

The new IR file:
	{
			"filePath": "/Users/ben_schwab/airapps/apollo-android/apollo-integration/src/main/graphql/com/apollographql/apollo/integration/normalizer/HeroAndFriendsWithFragments.graphql",
			"operationName": "HeroAndFriendsWithFragments",
			"operationType": "query",
			"rootType": "Query",
			"variables": [
				{
					"name": "episode",
					"type": "Episode"
				}
			],
			"source": "query HeroAndFriendsWithFragments($episode: Episode) {\n  hero(episode: $episode) {\n    __typename\n    ...HeroWithFriendsFragment\n  }\n}",
			"fields": [
				{
					"responseName": "hero",
					"fieldName": "hero",
					"type": "Character",
					"args": [
						{
							"name": "episode",
							"value": {
								"kind": "Variable",
								"variableName": "episode"
							}
						}
					],
					"isDeprecated": false,
					"deprecationReason": null,
					"fields": [
						{
							"responseName": "__typename",
							"fieldName": "__typename",
							"type": "String!"
						},
						{
							"responseName": "id",
							"fieldName": "id",
							"type": "ID!",
							"description": "The ID of the character",
							"isDeprecated": false,
							"deprecationReason": null
						},
						{
							"responseName": "name",
							"fieldName": "name",
							"type": "String!",
							"description": "The name of the character",
							"isDeprecated": false,
							"deprecationReason": null
						},
						{
							"responseName": "friends",
							"fieldName": "friends",
							"type": "[Character]",
							"description": "The friends of the character, or an empty list if they have none",
							"isDeprecated": false,
							"deprecationReason": null,
							"fields": [
								{
									"responseName": "__typename",
									"fieldName": "__typename",
									"type": "String!"
								}
							],
							"fragmentSpreads": [
								"HumanWithIdFragment"
							],
							"inlineFragments": [
								{
									"typeCondition": "Human",
									"possibleTypes": [
										"Human"
									],
									"fields": [
										{
											"responseName": "__typename",
											"fieldName": "__typename",
											"type": "String!"
										},
										{
											"responseName": "id",
											"fieldName": "id",
											"type": "ID!",
											"description": "The ID of the human",
											"isDeprecated": false,
											"deprecationReason": null
										},
										{
											"responseName": "name",
											"fieldName": "name",
											"type": "String!",
											"description": "What this human calls themselves",
											"isDeprecated": false,
											"deprecationReason": null
										}
									],
									"fragmentSpreads": [
										"HumanWithIdFragment"
									]
								}
							]
						}
					],
					"fragmentSpreads": [
						"HeroWithFriendsFragment"
					],
					"inlineFragments": []
				}
			],
			"fragmentsReferenced": [
				"HumanWithIdFragment",
				"HeroWithFriendsFragment"
			],
			"sourceWithFragments": "query HeroAndFriendsWithFragments($episode: Episode) {\n  hero(episode: $episode) {\n    __typename\n    ...HeroWithFriendsFragment\n  }\n}\nfragment HeroWithFriendsFragment on Character {\n  __typename\n  id\n  name\n  friends {\n    __typename\n    ...HumanWithIdFragment\n  }\n}\nfragment HumanWithIdFragment on Human {\n  __typename\n  id\n  name\n}",
			"operationId": "61146c8cea6a6ef45dfc7e4fcbbfd9a67a0c04703042ed4203e280c3d37ad81a"
		},

Note that friends, id, name get merged onto Hero. This presents the problem that Object types (like friends) are declared twice - once in the parent, and once in the fragment. These are legitimate different types because the parent class might be the merge result of multiple fragments.
In the imperative store api if a user is adding a friend, she will need to add the user to both friends declaration (hero object, and fragment object)... where the friend is of different types. What happens if only change is supplied to the parent friend declaration, and not the fragment? Or vice versa.
Actually, how does the imperative store API handle the current case where two fragments actually reference the same piece of source data? As this seems like the same problem.

@sav007 Sorry, this is a bit of a word dump. But came across a question about the imperative store api when looking to update apollo codegen. Let me know if this doesn't make sense.

First that weird, why fields from fragment been merged to operation, is it some new changes in code gen? And why? And it seems that the query is not correspond to IR, in IR there is inline fragment but in query that you provided there is no any inline fragment:
"inlineFragments": [
								{
									"typeCondition": "Human",
									"possibleTypes": [
										"Human"
									],
									"fields": [
										{
											"responseName": "__typename",
											"fieldName": "__typename",
											"type": "String!"
										},
										{
											"responseName": "id",
											"fieldName": "id",
											"type": "ID!",
											"description": "The ID of the human",
											"isDeprecated": false,
											"deprecationReason": null
										},
										{
											"responseName": "name",
											"fieldName": "name",
											"type": "String!",
											"description": "What this human calls themselves",
											"isDeprecated": false,
											"deprecationReason": null
										}
									],
									"fragmentSpreads": [
										"HumanWithIdFragment"
									]

Actually, how does the imperative store API handle the current case where two fragments actually reference the same piece of source data? As this seems like the same problem.

I believe there is no any issues here, as we are talking about normalized cache. Response data field will be merged and reading fragment from store is just instructions what fields we need to read and how.

Conclusion seems to be we need mergeInFieldsFromFragmentSpreads to be a flag for the time being until we can solve fully, either through making fragments interfaces or improving our fragment parsing / code gen process in some other way.
The concern is that the merged in fields (esp. for objects) are a different type than in the fragment. This may be confusing from a user perspective, additionally, this can introduce significant overhead on the normalization process as the merged fragments and fragments themselves will generate normalized records that will either be merged if the objects have an appropriate id, or worse, be duplicated if using the path as id.


Images hosted on Docker Hub are no longer updated. Please use quay.io image

https://hub.docker.com/r/jupyter/minimal-notebook
Images hosted on Docker Hub are no longer updated. Please, use quay.io image
#FROM jupyter/minimal-notebook
FROM quay.io/jupyter/minimal-notebook:latest

Thanks, good to now, I also found that in the readme now:

Since 2023-10-20 our images are only pushed to Quay.io registry. Older images are available on Docker Hub, but they will no longer be updated.

I will create a PR for this


[User story] status

placeholder for now, I'll add more details in the next days

@code-ready/crc-team what are the both statuses representing? We have CRC Status and OCP Status. Can crc be started, while ocp is starting?

CRC status is about the VM state (roughly equivalent to virsh -c qemu:///system domstate crc on linux).
OCP status is determined by looking at cluster operators state (oc get co).
If you watch crc status while crc start is in progress in another terminal, you should be able to see crc status: started together with openshift: starting (and a wide range of variations of statutes, even if Guillaume improved this).


Migrate from FMP to JKube

Migrate from Fabric8 Maven Plugin to JKube Openshift Maven Plugin

any news on this one?


Limit search results and add metrics

Closes #10.

This change is

Reviewed 5 of 7 files at r1, 3 of 3 files at r2.
Review status: all files reviewed, 1 unresolved discussion (waiting on @mithrandi)

setup.py, line 26 at r2 (raw file):

        'toolz',
        'py2casefold',
        'prometheus_client',

Don't you also need to update requirements.txt?

Comments from Reviewable

Reviewed 1 of 7 files at r1, 1 of 1 files at r3.
Review status: all files reviewed, 1 unresolved discussion (waiting on @jonathanj)

setup.py, line 26 at r2 (raw file):
Previously, jonathanj (Jonathan Jacobs) wrote…
Don't you also need to update requirements.txt?

Done.

Comments from Reviewable

Reviewed 1 of 1 files at r3, 1 of 1 files at r4.
Review status: :shipit: complete! all files reviewed, all discussions resolved

Comments from Reviewable

bors r+

Comments from Reviewable


Implemented secret handling

As promised in #11, this PR adds support for secret files.
Many container orchestrators provide a way to inject secret configuration values into application securely by mounting read-only files into their file system; the application is expected to read those files upon starting up.
These changes modify configuration loading to:

Try and read a configuration value from an environment variable FOO, if defined
Try and read a file path from an environment variable FOO_PATH, if defined
Try and read the file path from the variable, if it exists

If all three variants fail, and no default value is passed, a KeyError is raised. This should provide solid configuration handling and allow to specify all values as environment variables or secret files, with the environment always taking precedence - so existing installations are not affected.

Thank you for your valuable contribution. We truly appreciate your efforts, and we will make sure to merge your PR as soon as possible.

@wacken89 nice! Could you also do a new released soon? That would be great. Thank you for merging!

Sure, I'm going to do it. I just need to update the readme on how to use files

@wacken89 Just added a new PR with the Readme update :)


Added Llama Bedrock client

Description
Added Llama Bedrock client
Related Issue

Type of Change

[ ] 📚 Examples / docs / tutorials / dependencies update
[ ] 🔧 Bug fix (non-breaking change which fixes an issue)
[x] 🥂 Improvement (non-breaking change which improves an existing feature)
[ ] 🚀 New feature (non-breaking change which adds functionality)
[ ] 💥 Breaking change (fix or feature that would cause existing functionality to change)
[ ] 🔐 Security fix

Checklist

[ ] I've read the CODE_OF_CONDUCT.md document.
[ ] I've read the CONTRIBUTING.md guide.
[ ] I've written tests for all new methods and classes that I created.
[ ] I've written the docstring in Google format for all the methods and classes that I used.
[ ] I've updated the pdm.lock running pdm update-lock (only applicable when pyproject.toml has been
modified)

Also, it would be better to have a common class called BedrockLLMClient.
It seems that both LLamaBedrockClient and ClaudeBedrockClient are reusing several pieces of code


[BYOC] Support control flow in annotate_target

This PR adds changes to annotate_target to handle control flow(if-else nodes) and let nodes correctly.
Context: The Neo team was trying to compile TF MobileNet SSD model and since the model is dynamic we noticed that the if-else and let nodes are not getting correctly compiled. Therefore this PR addresses those fixes.

Hi @codeislife99, thanks for the PR.
Would you mind providing a bit more context on what this change is and why is it needed? Also, generally speaking, it would be good to have some test cases added when changes are introduced. That would help a lot, when reviewing your PR.

Hey Ritwik, nice to see you here :-)
Would you love to provide some context of this change? Also CC @comaniac @zhiics.

@leandron @junrushao1994 The PR is now ready for review. Please take a look.
@comaniac @zhiics

@leandron @junrushao1994 The description is updated. PTAL.

@comaniac I addressed your comments. PTAL again.

Thanks @codeislife99


The My Avatar at http://ddbullfrog.github.io/iCard-Resume/ is broken

Hi,
The My Avatar at http://ddbullfrog.github.io/iCard-Resume/ is broken.
Can you please check it ?

fixed


Css links on non-production builds

What problem does this feature solve?
Production and non-production builds do not produce the same styling elements.  Css links are created on production builds while inline styles are created on non-production builds.  Although this is ideal for most use cases, it can cause problems.  In our case we have a theming engine that is breaking because it is specifically looking for these css links.  In the vue cli 2.x we could fairly easily overwrite the default behavior and serve css links in non-production builds, but I've found it difficult, to say the least, to accomplish this in the the 3.0 version.
What does the proposed API look like?
An additional config entry in the css options should do the trick for this, something like enableHotReload which is defaults to true.  Then line 25 of the css config would need to be altered to account for the new config entry.

CSS extraction is disabled in development mode because it breaks HMR.

@Akryum, can you please clarify if enabling css extraction would break all hmr or just for css changes?

What theming engine is it? Why does it need to crawl CSS links? Sounds like a big hack to me.

Ouch!  The theming engine is home grown and was the best our team could do based on the styles provided by our vendor and direction from management.  We felt that having the theme engine perform the same in both production and non-production builds were better than having hmr for css.  I can put together a small sample project if you think that will help my case.

Looks like it wasn't such a bad idea after all, fixed in rc-11 686ec2591a4e686e2aadf36ecf666167b7607333.  Thanks!


Verifiable encryption of elliptic curve secrets

Implement functions and tests for verifiable encryption of a scalar secret on the secp256k1 curve.

Many thanks for PR, @tetratorus! It seems ok to me, however there is one problem. In the last months we have rewritten pretty much every primitive and scheme except the one for verifiable encryption. We plan to do it, but not sure if in the near future. It badly needs refactoring, however we have no need for this primitive at the moment.
If there is an application where you would like to use verifiable encryption, we can perhaps do this sooner than initially planned. Bottom line - I would merge the test you provided, but would wait with elliptic curve group until we refactor the primitive (it would not require copying the whole file then).

I would then suggest you modify PR to include only the extension of a test and fix related to keys. I will then merge it. Also, can you please delete one PR? It seems like there are two pretty much the same PRs.


documentation page

Hi,
I see the full documentation is condensed in the README file. Would it be of interest to have a dedicated documentation page for the project? Hosted, for example, on ReadTheDocs.

I don't think that is worth the effort on my part. I'm sure there would be some administration involved.


Add Criterion CI that compares PRs to master

Closes https://github.com/paritytech/wasmi/issues/322.

Codecov Report

Merging #324 (89f1b5e) into master (0793ada) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #324   +/-   ##
=======================================
  Coverage   79.96%   79.96%
=======================================
  Files          69       69
  Lines        9312     9312
=======================================
  Hits         7446     7446
  Misses       1866     1866

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 0793ada...89f1b5e. Read the comment docs.

Closed due to this: https://github.com/paritytech/wasmi/issues/322#issuecomment-1010098122


Optimize websocket

The current version of the websocket pushes frequently, and the front-end cannot tell if the data is updated or not, and the page is re-rendered every time it is pushed.
Can longhorn refer to the way Rancher websocket is implemented. Returning an empty object when there is no data change

Depends on #791

@smallteeths Is this still a valid issue after several WS improvements in the previous releases?

@smallteeths Is this still a valid issue after several WS improvements in the previous releases?

I will close this issue, Ws has been optimized.


Jakarta Security 3.0 - OpenIdAuthenticationMechanismDefinition implementation

Opening as a draft PR for now as it's still WIP
Doesn't work/WIP:

Token expiration checks (@AutoApplySession is used right now on the auth mechanism, I've mainly done this for testing purposes and will likely drop it)
redirectToOriginalResource=true, isn't implemented yet
Large parts of the code aren't covered by unit/integration tests

What does work:

Authentication against Keycloak (Both in a real app and in examples/openid-security tests) and https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server (used in security TCK)
Passes TCK app-openid and app-openid2, app-openid3 tests redirectToOriginalResource which is not implemented yet:

[INFO] Reactor Summary for Jakarta Security TCK - main 3.0.1:
[INFO]
[INFO] Jakarta Security TCK - main ........................ SUCCESS [  2.672 s]
[INFO] common ............................................. SUCCESS [  0.699 s]
[INFO] app-openid ......................................... SUCCESS [  6.441 s]
[INFO] app-openid2 ........................................ SUCCESS [ 16.031 s]
[INFO] app-openid3 ........................................ FAILURE [  6.057 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------

I've been working on this on and off for a couple of weeks now, with this PR getting quite big by now. So I'd highly appreciate if someone can take a look and give some feedback 🙂

redirectToOriginalResource=true works now and all openid modules of the TCK are passing:
[INFO] Reactor Summary for Jakarta Security TCK - main 3.0.1:
[INFO]
[INFO] Jakarta Security TCK - main ........................ SUCCESS [  2.725 s]
[INFO] common ............................................. SUCCESS [  0.748 s]
[INFO] app-openid ......................................... SUCCESS [  6.556 s]
[INFO] app-openid2 ........................................ SUCCESS [ 15.742 s]
[INFO] app-openid3 ........................................ SUCCESS [ 14.100 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  39.986 s
[INFO] Finished at: 2024-06-02T17:24:15+02:00
[INFO] ------------------------------------------------------------------------

Thanks @rzo1 for triggering a full build: https://ci-builds.apache.org/job/Tomee/view/tomee-10.x/job/pull-request-manual/106/
All tests are passing :slightly_smiling_face:

looks really good from a short review and tests are running; +1
great work!

what really needs a closer look and maybe needs to be discussed:

JWT Validation is using jose.4.j, this introduces a new dependency in all tomee flavours (wasn't in webprofile before). Maybe it needs to be added in some notice file?
Spec mentions a special variable that can be used in the annotation: ${baseURL}, I implemented this with producing an @Named String
I built a basic delegate in OpenIdAuthenticationMechanismDefinitionDelegate that automatically resolves the configuration from the openid provider
SavedRequest (originally from @LoginToContinue) has been rewritten so I can serialize it for use in cookies
Spec is ambiguous on how to handle subjectTypeSupported, idTokenSigningAlgorithmsSupported and responseTypeSupported (See CompositeOpenIdProviderMetadata). A user can override these, but it's not obvious if that has been done or not. I handled these the same way soteria does, but it's probably worth a spec issue in the future?
Requests to openid provider are done using JAX-RS Client, maybe we want to use something else in TomEE? Really the only reason I chose this was because it's convenient

(See https://lists.apache.org/thread/sghf41f1z75gpnhpf236o1lrj1sl4vr8 for whole thread on mailing list)

Thanks @jungm


Certificate-based authentication docs

Items to resolve:

The section about logging in with a client cert: "There is a lot of foot shooting potential with these settings"
SSL client cert setup via TLS mutual auth was broken to its own doc here: https://docs.mattermost.com/deployment/ssl-client-certificate.html
Document config settings

PR description updated

Added config settings into the document,


Can't sign in

I go through the process of signing in. I verify the login and I just end up back at the sign in and I'm not signed in. I'm running Android 12.

Same here

Same here

I have a a similar issue. I can login, but face the Vanced microG Settings again.
If I try to add the account again, I receive the message that the account is already registered on the device.
Youtube Vanced on the other hand won't load anything anymore (black screen), after I failed to sign in.
Reinstalls or reboots change nothing.
BUT, if you read the messages from Vanced Manager, when installing microG/Youtube Vanced, you'll notice:

Install Youtube Vanced 15.43.32
Open Youtube Vanced and log in
Update Youtube Vanced

It clearly states, this is currently a known bug and they provide a workaround.


trustbundle: return error when replacing td in principal fails

This avoids an empty string to be added into the new principal list replaced
when the principal is not presented in a valid SPIFFE ID format.
Signed-off-by: Kailun Qin<EMAIL_ADDRESS>[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[x] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Pull Request Attributes
Please check any characteristics that apply to this pull request.
[x] Does not have any user-facing changes. This may include CLI changes, API changes, behavior changes, performance improvements, etc.

@kailun-qin: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-ipv6-k8s-tests_istio
67541fe34848b78d86d5eecc4c81d63554bae1e8
link
/test integ-ipv6-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@kailun-qin: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-ipv6-k8s-tests_istio
67541fe34848b78d86d5eecc4c81d63554bae1e8
link
/test integ-ipv6-k8s-tests_istio

unit-tests_istio
67541fe34848b78d86d5eecc4c81d63554bae1e8
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Add key_code value as part of dom_sender map

Hello we are using awesome develop with a new project
This is not a bug, but a feature.
We think it could be quite useful for keyboard events to add the key_code within the dom_sender
sometimes, you don't want to process every key pressed.
For instance, want to load an autocomplete pop-up with values for a web-service, but no with every key pressed, because it takes too much CPU.
We don't see how could it be done now.
Thanx

By default, events send some information back to the server, as described in docs here - https://hexdocs.pm/drab/Drab.Commander.html#content - so you can have the value, text, html etc of the sender DOM object. Maybe it is a good idea to add the event object here, so you could read its properties. I'll think about it.
The simple example is here https://tg.pl/drab#broadcast - but it launch the event on every key press. From the performance perspective, it would be nice to have some kind of "throttle" event, which is launched on the JS side when user stop pressing the keys with some delay, like 0.5 second. I will add it to the TODO

Thank you  @grych

Added in v0.2.6

added event object with specified properties to the dom_sender
added debounce function as an option to the event handler


Unable to cast object of type 'TaskToAsyncOperationAdapter' to type 'IAsyncOperation'

Describe the bug
I'm authoring an in-process WinRT server, and it has the following method:
public struct Data
{
    public int X;
}

class Foo
{
    public IAsyncOperation<Data> GetDataAsync()
    {
        return AsyncInfo.Run(async () =>
        {
            await Task.Delay(1000);
            return new Data { X = 42 };
        });
    }
}

To Reproduce
Create a client that call into the server method:
var foo = new Foo();
await foo.GetDataAsync();

You will get:
Unhandled exception. System.InvalidCastException: Unable to cast object of type 'System.Threading.Tasks.TaskToAsyncOperationAdapter`1[WinRTServer.Data]' to type 'Windows.Foundation.IAsyncOperation`1[WinRTServer.Data]'.
   at WinRT.MarshalInspectable`1.FromAbi(IntPtr ptr)
   at WinRT.MarshalInterface`1.FromAbi(IntPtr ptr)
   at ABI.WinRTServer.IFooClassMethods.GetDataAsync(IObjectReference _obj)
   at WinRTServer.Foo.GetDataAsync()

Note that the WinRTServer.Data in TaskToAsyncOperationAdapter<WinRTServer.Data> comes from the server, while the one in IAsyncOperation<WinRTServer.Data> comes from the client.
This issue doesn't reproduce if you are using an out-of-process WinRT server. It only reproduces for in-process WinRT server.
A simple repro can be found here (checkout the repro branch): https://github.com/hez2010/WinRTServer/tree/repro
Expected behavior
No exception being thrown.
Version Info
CsWinRT 2.0.7

I also tested the following code:
In a WinRT component:
class Foo
{
    public IAsyncAction BarAsync()
    {
        ...
    }
}

In consumer:
var foo = new Foo();
await foo.BarAsync();

And I got the exception again:
Unhandled exception. System.InvalidCastException: Unable to cast object of type 'System.Threading.Tasks.TaskToAsyncActionAdapter' to type 'Windows.Foundation.IAsyncAction'.
   at WinRT.MarshalInspectable`1.FromAbi(IntPtr ptr)
   at WinRT.MarshalInterface`1.FromAbi(IntPtr ptr)
   at ABI.WinRTServer.IFooClassMethods.BarAsync(IObjectReference _obj)
   at WinRTServer.Foo.BarAsync()

Seems that the async usage in in-proc WinRT component is completely broken?

Looking at the repro, there are a couple issues probably happening here:

We have the projected Data type and the authored Data type.  When the call tries to convert from one to the other, it runs into a cast exception.
There are 2 instances of the Windows SDK projection loaded.  One from the authored component and the other via hosting support.  They are loaded in different assembly load context probably causing the invalid cast exception in the 2nd scenario.

Part of this issue arises probably because both use the same global instance of ComWrappers while using different projections of the same type.  I wonder if it is possible to address this by making one use a different instance.  Will need to look more into that.
What would you say the scenario here is where we have a C# client activate a C# component via the projection support while loading the same component inproc rather than instantiate from the managed DLL itself?

I wonder if it is possible to address this by making one use a different instance.

I think this should work as the out-of-proc model (the main branch of the repro) works without any issue.


MQTT in node auto-detect mode should include trying to parse JSON

Current Behavior
Currently the MQTT in node when in default automatic mode will only return strings or buffers (if payload is not utf8). In order to parse JSON that mode has to be manually selected.
See discussion https://discourse.nodered.org/t/improvement-of-mqtt-in-nodes/55445
Expected Behavior
Proposed behaviour rather than expected - I would propose that the automatic mode should be "fully automatic" and try to parse the incoming payload to the highest possible capability - ie JSON if possible. Then fail back to string  - then back to buffer as today. Obviously the existing fixed modes can still be selected manually.
This would be more in line with what I would interpret as automatic - and doing our best to help users by default. We do get a lot of Q&A on the forum where the answer is - "turn on json parsing for your mqtt node input" - and this change would reduce that.
However it is a breaking change in behaviour - but one that I think is worth doing as we move to 3.0. Yes you could add yet another checkbox to the options but I don't feel adding more options is the right answer when the existing behaviour can be improved in line with user expectations.
I'm happy to implement if accepted.
Steps To Reproduce
No response
Example flow
paste your flow here

Environment

Node-RED version:
Node.js version:
npm version:
Platform/OS:
Browser:

Having considered this, I have concerns about making this change in behaviour to the auto mode.
To be clear - I agree that in a perfect world, auto mode would try to JSON parse. The question is whether the impact of making this change can be justified - even with a major version change (ie 3.0).
I would suggest that JSON over MQTT is a very common pattern implemented as an MQTT node wired to a JSON node - both with their default configurations. And that pattern will be broken by this change.
If we were discussing a relatively uncommon edge case, then it would be easier to justify the breakage for the greater good. But we're talking about changing the default behaviour of the MQTT node that will have a large impact in terms of the number of flows that need fixing to continue working.
I think we need to find a way to introduce this behaviour that doesn't break existing flows.

I propose we add auto-detect (JSON, string or buffer) option - and make that the default for newly added nodes. Existing nodes will continue with just the string/buffer auto-detect option.
Would could then also add a deprecation warning to the auto-detect string/buffer option - (in both UI and maybe logged on node deploy) - that encourages users to migrate to the new option. This gives them time to migrate and minimise the impact when we eventually remove the old option in 4.0.

@knolleary I think this is a reasonable approach
I will begin work on this tomorrow assuming @dceejay has no objections.

No objections

@dceejay @knolleary Updated PR and added a comment here: https://github.com/node-red/node-red/pull/3530#issuecomment-1105730063

Shipped in 3.0


Add Buluc Chabtan

Some ideas

Dismembering a living enemy raises DF

For this to work I gotta make it so repeated damage to a body part (not including "body") will dismember it

Causing enemy's to bleed raises DF
Running away from a fight lowers DF
Ability to sacrifice yourself, causing massive AOE damage. The higher your DF is, the higher chance he resurrects you afterwards (it's never a guarantee tho)
Ability to let him control you, buffing all your stats and doing all the attacking for you for X turns but with 0 regard for your health (this sounds hard to do so probably won't do it lol)


Missing some thread listing related REST types

I'm looking for the type information for the following rest routes and it seems they are not present:

GET /channels/{channel.id}/threads/archived/public
GET /channels/{channel.id}/threads/archived/public
GET /channels/{channel.id}/users/@me/threads/archived/private

GET /channels/{channel.id}/threads/archived/public

Seems like we are missing an interface export for this

GET /channels/{channel.id}/threads/archived/public

Seems like we are also missing an interface export for this

GET /channels/{channel.id}/users/@me/threads/archived/private

Type is RESTGetAPIChannelUsersThreadsArchivedResult

Feel free to open a PR for the missing ones if you want!

I think [GET /channels/{channel.id}/threads/archived/public](https://discord.com/developers/docs/resources/channel#list-public-archived-threads) and [GET /channels/{channel.id}/threads/archived/public](https://discord.com/developers/docs/resources/channel#list-private-archived-threads) are also RESTGetAPIChannelUsersThreadsArchivedResult - the docs for all three say they only have threads, members, and has_more.


Automatic application of Arcane Weapon/Soul Empower prevents application to off-hand weapon

Heya.  While this is not strictly a bug, I noticed that Forceblade Sorcerer's and Soulblade Warlock's (and possibly Arcane Fighter Wizard's) Arcane Weapon abilities automatically apply to the main-hand weapon now.  While handy, this prevents dual wielders from utilizing the feature if they multiclass to have two of the features (i.e. Forceblade Sorc + Soulblade Warlock).
I also noticed, with automatic application;  If one's Strength score is equivalent to the stat utilized for Arcane Weapon, the game indicates it will use Strength for the to-hit and damage, possibly preventing certain features (like the Elven Accuracy feat) from functioning.
(I haven't been able to test this yet, the game just lists Str as the weapon to-hit in the tooltip whilst having Arcane Weapon.)

What I can do is follow same behavior as SoulBlade and allow the modifier on off hand only if TWF is taken

That sounds fair enough.  I did see an allusion in prior UB patch notes about the chang of these features to more closely reflect tabletop rules, but was unsure what that entailed or where to find such info.  I wouldn't want to stray too far from tabletop, as Solasta's strength is it's fidelity to the 5e system.

changed in local dev. description also updated to reflect the behavior:
"Your non two-handed weapon attacks count as magical and you use your spell casting modifier for your attack and damage rolls. If you have the Two Weapon fighting style these changes also apply to your offhand attack."


Issue with SSL certificate

Trace :
2017-09-14 16:48:35,768 [MainThread  ] [INFO ]  Retrieving http://search.maven.org/remotecontent?filepath=org/apache/tika/tika-server/1.15/tika-server-1.15.jar to /tmp/tika-server.jar.
Traceback (most recent call last):
File "test.py", line 4, in
parsed = parser.from_file('./R1.pdf', xmlContent=True)
File "build/bdist.linux-x86_64/egg/tika/parser.py", line 38, in from_file
File "build/bdist.linux-x86_64/egg/tika/tika.py", line 316, in parse1
File "build/bdist.linux-x86_64/egg/tika/tika.py", line 510, in callServer
File "build/bdist.linux-x86_64/egg/tika/tika.py", line 559, in checkTikaServer
File "build/bdist.linux-x86_64/egg/tika/tika.py", line 665, in getRemoteJar
File "/usr/lib/python2.7/urllib.py", line 98, in urlretrieve
return opener.retrieve(url, filename, reporthook, data)
File "/usr/lib/python2.7/urllib.py", line 245, in retrieve
fp = self.open(url, data)
File "/usr/lib/python2.7/urllib.py", line 213, in open
return getattr(self, name)(url)
File "/usr/lib/python2.7/urllib.py", line 364, in open_http
return self.http_error(url, fp, errcode, errmsg, headers)
File "/usr/lib/python2.7/urllib.py", line 377, in http_error
result = method(url, fp, errcode, errmsg, headers)
File "/usr/lib/python2.7/urllib.py", line 642, in http_error_302
headers, data)
File "/usr/lib/python2.7/urllib.py", line 669, in redirect_internal
return self.open(newurl)
File "/usr/lib/python2.7/urllib.py", line 213, in open
return getattr(self, name)(url)
File "/usr/lib/python2.7/urllib.py", line 443, in open_https
h.endheaders(data)
File "/usr/lib/python2.7/httplib.py", line 1053, in endheaders
self._send_output(message_body)
File "/usr/lib/python2.7/httplib.py", line 897, in _send_output
self.send(msg)
File "/usr/lib/python2.7/httplib.py", line 859, in send
self.connect()
File "/usr/lib/python2.7/httplib.py", line 1278, in connect
server_hostname=server_hostname)
File "/usr/lib/python2.7/ssl.py", line 353, in wrap_socket
_context=self)
File "/usr/lib/python2.7/ssl.py", line 601, in init
self.do_handshake()
File "/usr/lib/python2.7/ssl.py", line 830, in do_handshake
self._sslobj.do_handshake()
IOError: [Errno socket error] [SSL: UNKNOWN_PROTOCOL] unknown protocol (_ssl.c:590)

are you behind a proxy? You may need to download the jar by hand and place it in /tmp, can you try that?

no comments since Sept, closing


[Enchancement](schema scanner) add SchemaScanner profile

Proposed changes
Issue Number: close #xxx
Problem summary
Add some profile information to the schema scanner to facilitate performance optimization.
Example:
SchemaScanner:
      -  FillBlockTime:  9s131ms
      -  GetDbTime:  12.816ms
      -  GetDescribeTime:  1s645ms
      -  GetTableTime:  25.433ms

Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run COMPILE

run buildall


The minimal QT dialog

The dialog class takes full advantage of features of the Qt framework and the
matplotlib plotting widgets. The first dialog is one used in the sct_propseg
command.
Partial implementation #1240

Test#1: labelvertebrae
Data: /Volumes/folder_shared/sct_issues/20170811_gui_charley/
python -m spinalcordtoolbox.gui.labelvertebrae t2_ax.nii.gz t2_ax_vert.nii.gz
DEBUG:spinalcordtoolbox.gui.base:Image orientation LAI
/Users/chgroc/spinalcordtoolbox/python/lib/python2.7/site-packages/matplotlib/axes/_base.py:1215: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
  if aspect == 'normal':
/Users/chgroc/spinalcordtoolbox/python/lib/python2.7/site-packages/matplotlib/axes/_base.py:1220: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
  elif aspect in ('equal', 'auto'):
DEBUG:__main__:Point clicked (0, 131, 160)
DEBUG:__main__:Point Selected (0, 131, 160, 1)
DEBUG:__main__:Point clicked (12, 110, 160)
DEBUG:__main__:Point Selected (12, 110, 160, 3)
DEBUG:__main__:Point clicked (17, 106, 160)
DEBUG:__main__:Point Selected (17, 106, 160, 4)
DEBUG:spinalcordtoolbox.gui.base:Overlay shape (47, 220, 320)
160,106,23,4:160,110,23,3:160,131,23,1
DEBUG:spinalcordtoolbox.gui.base:Data: (array([160, 160, 160]), array([106, 110, 131]), array([23, 23, 23]))

Inputs: 3 clics: Top of C1, C2/C3, C3/C4
Remarques:

Output name = manual_propseg.nii.gz
Fslview screenshot:

@peristeri: i've installed the new branch but i'm a bit confused as to what should be tested: viewer? if so for which functions (propseg? labelvert? labelutils?...) QT? if so for which functions? Please make an exhaustive list of things we should test. Thx

comments here:
https://www.dropbox.com/s/fdynbvy3tqngeqk/20170814_test_sct-qt.m4v?dl=0

I've reinstalled completely SCT but I am getting the following error:

The same error occurs when trying to use sct_segment_image or the vertebral labeling.
Any idea how to fix this?

I still had the same scipy issue as illustrated above. I fixed it by downgrading scipy to 0.17.0 using this:
conda install --force scipy=0.17.0

Then, unsetting the DYLD_FALLBACK_LIBRARY_PATH variable:
unset DYLD_FALLBACK_LIBRARY_PATH

Source here: https://github.com/ContinuumIO/anaconda-issues/issues/899. The issue should be fixed in the next version of scipy.
Next try on sct_segment_image:
(root) bendeleener:~/code/sct $ sct_segment_image -i ~/sct_example_data/t2/t2.nii.gz -o toto.nii.gz -mode labelvertebrae
Traceback (most recent call last):
  File "/Users/benjamindeleener/code/sct/python/bin/sct_segment_image", line 9, in <module>
    load_entry_point('spinalcordtoolbox', 'console_scripts', 'sct_segment_image')()
  File "/Users/benjamindeleener/code/sct/python/lib/python2.7/site-packages/setuptools-23.0.0-py2.7.egg/pkg_resources/__init__.py", line 542, in load_entry_point

  File "/Users/benjamindeleener/code/sct/python/lib/python2.7/site-packages/setuptools-23.0.0-py2.7.egg/pkg_resources/__init__.py", line 2569, in load_entry_point

  File "/Users/benjamindeleener/code/sct/python/lib/python2.7/site-packages/setuptools-23.0.0-py2.7.egg/pkg_resources/__init__.py", line 2229, in load

  File "/Users/benjamindeleener/code/sct/python/lib/python2.7/site-packages/setuptools-23.0.0-py2.7.egg/pkg_resources/__init__.py", line 2235, in resolve

  File "/Users/benjamindeleener/code/sct/spinalcordtoolbox/gui/cli.py", line 17, in <module>
    from spinalcordtoolbox.gui.sagittal import SagittalControler, SagittalDialog
ImportError: No module named sagittal

Seems like there are some issues with the installation because the file spinalcordtoolbox.gui.sagittal is missing from my installation. I don't find it either on GitHub.

@peristeri : I have the same problem as Ben

It works now. Thank you.
General comments:

there is no indication about what the labels mean and should be. The viewer should have an appropriate indication about the labels that need to be added.
before, it was possible to adjust the contrast and intensity of the image. It was useful to make sure we click in the right spot. We should have a discussion about it.

Register to template:
Here is a working command for the register_to_template example:
sct_segment_image -i ~/sct_example_data/t2/t2.nii.gz -o toto.nii.gz -mode registertotemplate -vertebraes 5,10,12

I don't understand the documentation and the choice of labels, but I guess it will change as we will move to a viewer integrated to specific tools (sct_propseg, sct_register_to_template, sct_label_vertebrae, etc.).
PropSeg:
When clicking in the images, the coordinates are added on top of the viewer as a list. After a few points, the window starts expanding in the left-right direction, and at some point, it is not possible to click anymore on the image...
After the last point, nothing changes and nothing happens. The viewer should probably close or at least indicate to the user what to do (save and quit).
After saving and quitting, I got the following error, even if the image was created:
Traceback (most recent call last):
  File "/Users/benjamindeleener/code/sct/spinalcordtoolbox/gui/propseg.py", line 183, in select_point
    self._controller.select_point(x, y, z)
  File "/Users/benjamindeleener/code/sct/spinalcordtoolbox/gui/propseg.py", line 58, in select_point
    raise ValueError('Invalid point selected {}'.format((x, y, z)))
ValueError: Invalid point selected (330, 251, 41)

hi,
i just tested version: https://github.com/neuropoly/spinalcordtoolbox/pull/1379/commits/82ec05ec8649e4b882bb5ce989947125595cb2c7
MAJOR ISSUES:

after clicking "save & quit", i get the message on the terminal "Output file toto.nii.gz" however this file is not generated (at least not locally).
mode registertotemplate fails (see below).
mode registertotemplate: how does the user specify the labels via the commandline?
mode propeg: add quick-and-dirty info to user, i.e., select center of the cord in axial view. When i clicked on the sagittal, i got the message "Can only select a slice in CUSTOM mode", but then when i clicked on "skip", the red bar goes down, but the axial view stays the same.

MINOR ISSUES:

SCT version should be added when launching the command (like what is done for all other functions)
typo+imprecision at top of the window: maunally segment --> manually label
indications to the user should be added (the design should be done after discussion with the team)

issue with registertotemplate:
sct_segment_image -i t2.nii.gz -mode registertotemplate -o toto.nii.gz
Traceback (most recent call last):
  File "/Users/julien/code/sct-qt/python/bin/sct_segment_image", line 9, in <module>
    load_entry_point('spinalcordtoolbox', 'console_scripts', 'sct_segment_image')()
  File "/Users/julien/code/sct-qt/spinalcordtoolbox/gui/cli.py", line 135, in segment_image_cli
    controller = launch_modes[mode](input_file, output_file, params)
  File "/Users/julien/code/sct-qt/spinalcordtoolbox/gui/cli.py", line 91, in launch_registertotemplate_dialog
    params.vertebraes = [2, 5]
  File "/Users/julien/code/sct-qt/spinalcordtoolbox/gui/base.py", line 73, in vertebraes
    raise ValueError('The values are not all valid vertebraes labels')
ValueError: The values are not all valid vertebraes labels

@benjamindeleener
The zoom, contrast and intensity are features that I wanted to implement with control buttons under each canvas.
I did not have a working format for the label name. It can be added easily.
@jcohenadad
You can override the list of vertebraes using -verterbraes 2,4,6
I will work on correcting the issues with registertotemplate and propseg.

@benjamindeleener @jcohenadad @charleygros I finished most of the suggestions.

my comments for version bf5028c500c32b8fbc8664fb2356ca5f4b564db6:

labelvertebrae: fig title: "manual labeling"
propseg: Benjamin's comment not addressed (the coordinates are added on top of the viewer as a list. After a few points, the window starts expanding...). Simple fix: do not display coordinates. They are irrelevant anyway because image is re-oriented.
change flag -vertebraes for -label
when typing "sct_segment_image -i t2.nii.gz -o toto.nii.gz -mode registertotemplate -vertebraes 2,3,10" i get "ValueError: The values are not all valid vertebraes labels". Why aren't these values valid?
i would name modes in a different manner. For example, i think we can merge mode labelvertebrae and registertotemplate, because they have the same functionality. The only difference is the number of labels, which can be specified by the parent function. Thus, i would call this mode "sagittal". For propseg, i would maybe call it "centerline", because the purpose here is to create a centerline (i.e. not specific to propseg). What does everyone think?

Will fix that
I will show something like 'Labelled x points'
Will fix that
2 is not a valid label value (according to the list found in sct_viewer)
5.Sounds good. Will fix that.

@jcohenadad @benjamindeleener can you review the changes. I change the command name to sct_label_image

Tested commit 2ef30ffea63c7f532bb6b04293cee35d703c5161:

inconsistency between cursor position and label creation. See: https://www.dropbox.com/s/082bwnyqxh9wzj3/20170919_bug_viewer.m4v?dl=0
unexpected behavior with button "undo": https://www.dropbox.com/s/fr6l2pysmgzmnif/20170919_bug_viewer2.m4v?dl=0

I just saw that sct_label_image is only available when sourcing SCT python, which is not the usual user case. I guess we should talk about this?

I think I found what caused the problem in Travis. When running sct_register_to_template, the module sct_label_utils is called. When calling this module, spinalcordtoolbox.gui is imported, which effectively opens a "Python 2.7" window in the GUI of the OS. See video here:
https://www.dropbox.com/s/wv1qx0gfxyj8qbc/20170929_bug_viewer.m4v?dl=0
When commenting the following lines in sct_label_utils, the window does not open:
from spinalcordtoolbox.gui import base
from spinalcordtoolbox.gui.sagittal import launch_sagittal_dialog

Given that Travis does not support opening windows, this might cause the problem.


Stop comparing modified timestamps in flutter.bat

Previously the last modified dates were being compared instead, but the
default Windows zip extraction sets this to be the time the files were
extracted. The creation time is always consistent.
Fixes flutter/flutter#22062

Can we test this to make sure we don't accidentally revert it the next time someone tries to make the unix and windows versions consistent? Or at a minimum add a comment to ward people off...


Add unit tests for Rect.hpp

Added basic unit test coverage for Rect.hpp using IntRect, similar to the existing Vector2 tests. All constructors, methods, and operators are covered. There is an open issue to increase test coverage, #623.
I know the contribution guide (http://www.sfml-dev.org/contribute.php) says to target the master branch, but this feature branch hasn't been merged into master yet so I didn't think it appropriate.

I know the contribution guide (http://www.sfml-dev.org/contribute.php) says to target the master branch, but this feature branch hasn't been merged into master yet so I didn't think it appropriate.

It is, indeed. :wink:
@SFML, we should probably have a m:unittest tag or do you see this in the config category?
For float comparison, I'm wondering if we should have a similar mechanism as:
#define CHECK_EPSILON 0.0001
#define CHECK_APPROX_EQUAL(a, b) CHECK(std::abs((a) - (b)) <= CHECK_EPSILON)

At least, that's what I've done for my personal unit tests. It could probably written as a template but I'm not sure it's 100% necessary for something that simple.

@zackthehuman Thank you! Just a few minor comments.
What we haven't tested here are negative widths and heights, but we can add that later.
@mantognini As usual, Catch provides all you need, including floating point comparisons :grimacing:
m:unittest is a good idea in my opinion.

As usual, Catch provides all you need, including floating point comparisons :grimacing:

Huhu, maybe it didn't exist when I started using Catch? Anyway, that very good news!

@Bromeon The PR has been updated. I didn't include Rects with negative widths because I wasn't sure about their behavior. For example, sf::IntRect(0, 0, -10, -10) doesn't contain (0, 0). Based on the math in the implementation it's correct, but I'm not sure if that would be my expectation as a user.

Thanks, looks good. If you could now squash the two commits into one (and force-push to your branch), that would be perfect :wink:

I didn't include Rects with negative widths because I wasn't sure about their behavior.

Good point... And they're not documented either. I remember that negative rectangles became relevant as soon as the sf::Sprite::flipX/Y() methods were removed, but it seems like they were never an official API feature.

Done. Squashed and fixed up the history :)

Thank you! :)


Update README.md

A small changement on the readme ...

Thanks!

You're welcome. Thanks for this library !


Is this library interfering with nock in some way?

I'm trying to use nock to intercept requests to your services and mock out a response, however i seem to be receiving this from your library when i do:
Error: write after end
    at Constructor._Error (/Users/jared/Projects/scratch/js-server/node_modules/hellosign-sdk/lib/Error.js:36:19)
    at new Constructor (/Users/jared/Projects/scratch/js-server/node_modules/hellosign-sdk/lib/utils.js:112:19)
    at OverriddenClientRequest.<anonymous> (/Users/jared/Projects/scratch/js-server/node_modules/hellosign-sdk/lib/HelloSignResource.js:214:17)
    at OverriddenClientRequest.emit (events.js:210:5)
    at /Users/jared/Projects/scratch/js-server/node_modules/nock/lib/intercepted_request_router.js:145:34
    at processTicksAndRejections (internal/process/task_queues.js:75:11) {
  type: 'HelloSignError',
  stack: 'Error: write after end\n' +
    '    at Constructor._Error (/Users/jared/Projects/scratch/js-server/node_modules/hellosign-sdk/lib/Error.js:36:19)\n' +
    '    at new Constructor (/Users/jared/Projects/scratch/js-server/node_modules/hellosign-sdk/lib/utils.js:112:19)\n' +
    '    at OverriddenClientRequest.<anonymous> (/Users/jared/Projects/scratch/js-server/node_modules/hellosign-sdk/lib/HelloSignResource.js:214:17)\n' +
    '    at OverriddenClientRequest.emit (events.js:210:5)\n' +
    '    at /Users/jared/Projects/scratch/js-server/node_modules/nock/lib/intercepted_request_router.js:145:34\n' +
    '    at processTicksAndRejections (internal/process/task_queues.js:75:11)',
  rawType: undefined,
  code: 'ERR_STREAM_WRITE_AFTER_END',
  param: undefined,
  message: 'write after end',
  detail: undefined,
  raw: Error: write after end
      at InterceptedRequestRouter.handleWrite (/Users/jared/Projects/scratch/js-server/node_modules/nock/lib/intercepted_request_router.js:143:19)
      at OverriddenClientRequest.req.write (/Users/jared/Projects/scratch/js-server/node_modules/nock/lib/intercepted_request_router.js:90:35)
      at InterceptedRequestRouter.handleEnd (/Users/jared/Projects/scratch/js-server/node_modules/nock/lib/intercepted_request_router.js:198:9)
      at OverriddenClientRequest.req.end (/Users/jared/Projects/scratch/js-server/node_modules/nock/lib/intercepted_request_router.js:91:33)
      at OverriddenClientRequest.<anonymous> (/Users/jared/Projects/scratch/js-server/node_modules/hellosign-sdk/lib/HelloSignResource.js:423:21)
      at OverriddenClientRequest.emit (events.js:210:5)
      at InterceptedRequestRouter.startPlayback (/Users/jared/Projects/scratch/js-server/node_modules/nock/lib/intercepted_request_router.js:302:11)
      at InterceptedRequestRouter.maybeStartPlayback (/Users/jared/Projects/scratch/js-server/node_modules/nock/lib/intercepted_request_router.js:253:12)
      at InterceptedRequestRouter.handleEnd (/Users/jared/Projects/scratch/js-server/node_modules/nock/lib/intercepted_request_router.js:200:10)
      at OverriddenClientRequest.req.end (/Users/jared/Projects/scratch/js-server/node_modules/nock/lib/intercepted_request_router.js:91:33)
      at Socket.<anonymous> (/Users/jared/Projects/scratch/js-server/node_modules/hellosign-sdk/lib/HelloSignResource.js:417:29)
      at Socket.emit (events.js:210:5)
      at InterceptedRequestRouter.connectSocket (/Users/jared/Projects/scratch/js-server/node_modules/nock/lib/intercepted_request_router.js:128:14)
      at /Users/jared/Projects/scratch/js-server/node_modules/nock/lib/intercepted_request_router.js:69:33
      at processTicksAndRejections (internal/process/task_queues.js:75:11) {
    code: 'ERR_STREAM_WRITE_AFTER_END'
  }
}

This is based on the code:
const helloAPI = require('hellosign-sdk')({key: process.env.API_KEY});
class CreateLive {
  constructor() {

  }

  async acknowledge(header, body) {
    const contractFile = await this._download(body)
      .catch((err) => {
        throw err;
      });
  }

  async _download(body) {
    const requestID = body.signature_request.signature_request_id;
    const downloadedData = await helloAPI.signatureRequest.download(requestID, {file_type: 'pdf'})
      .then((res) => {
        return new Promise((resolve, reject) => {
          let downloadData = Buffer.from('');
          res.on('data', (data) => {
            downloadData = Buffer.concat([downloadData, data]);
          });
          res.on('end', () => {
            resolve(downloadData);
          });
        });
      })
      .catch((err) => {
        console.log(err);
        throw err;
      });
    console.log(downloadedData)
    return downloadedData;
  }
}
module.exports = CreateLive;

then using nock in my tests here:
// common.js
'use strict';

global.chai = require('chai');
global.chai.should();

global.expect = global.chai.expect;
global.sinon = require('sinon');

global.sinonChai = require('sinon-chai');
global.chai.use(global.sinonChai);

global.nock = require('nock');

// .mocharc.js
'use strict';

module.exports = {
  require: '/Users/jared/Projects/scratch/js-server/test/common.js',
  harmony: true,
  recursive: true,
  bail: true
};

const CreateLive = require('../src/Events/Event/CreateLive');
describe('CreateLive', () => {
  describe('acknowledge', function() {
    it('should call _download', async () => {
      const event = getEvent() // code to get a mocked out hellosign event
      const contract = getContract() // code to get a contract (.pdf file)
      nock('https://api.hellosign.com:443', {"encodedQueryParams":true})
          .get('/v3/signature_request/files/' + event.body.signature_request.signature_request_id, "file_type=pdf")
          .query({"file_type":"pdf"})
          .reply(200, contract, [
            'Access-Control-Allow-Headers',
            'Authorization, Origin, X-Requested-With, Content-Type, Accept',
            'Access-Control-Allow-Methods',
            'GET, POST, OPTIONS',
            'Access-Control-Allow-Origin',
            '*',
            'Cache-Control',
            'cache-control=must-revalidate',
            'Content-Description',
            'File Transfer',
            'Content-Disposition',
            'attachment; filename="abcd"',
            'Content-Transfer-Encoding',
            'binary',
            'Content-Type',
            'application/pdf',
            'Date',
            'Fri, 26 Jun 2020 16:39:49 GMT',
            'ETag',
            '"57c83-0"',
            'Expires',
            'Sat, 26 Jul 1997 05:00:00 GMT',
            'Last-Modified',
            'Fri, 26 Jun 2020 16:39:50 GMT',
            'P3P',
            'CP="NOP3PPOLICY"',
            'Pragma',
            'public: 1',
            'Server',
            'Apache',
            'Strict-Transport-Security',
            'max-age=15768000',
            'Content-Length',
            '359555',
            'Connection',
            'Close'
          ]);
        const createEvent = new CreateLive();
        const actual = await createEvent.acknowledge(event.headers, event.body)
          .catch(function(err) {
            console.log(err);
            expect(function() { throw err })
              .to.not.throw();
          });
    });
  });
});

Dependencies:
"chai": "^4.2.0",
    "mocha": "^8.1.1",
    "nock": "^13.0.4",
    "sinon": "^9.0.3",
    "sinon-chai": "^3.5.0"
"hellosign-sdk": "^1.6.0",

Hi Jared,
This is Hazem from API support.
Would you mind getting back to us by creating a ticket to<EMAIL_ADDRESS>with what the HelloSign SDK is doing in response when hitting the Get Files endpoint outside of the Nock implementation?
I will be on the look-out for your ticket in our queue.

@JaredCE did you ever get this resolved? Having similar issues.

The issue seems to be with nock v13. I have some tests that work just fine using nock v12, but when I upgrade to nock v13 i'm getting these same errors.
Please reopen.

Hi @toymachiner62,
This is LaToya from API support.
Would you mind getting back to us by creating a ticket to<EMAIL_ADDRESS>with what the HelloSign SDK is doing in response when hitting the endpoint in your test suite outside of the Nock implementation?
We will be on the look-out for your ticket in our queue.

@toymachiner62
When i asked about this, i got this response:

Digging deeper into the Node SDK, the error does seem to be due to the way we're making the request in our SDK (looks originate from this line, we call req.end( two times which is what triggers the Nock error). Yet, we are not able figure out if what we're doing is actually an error or not.

As you say, it started happening with Node 13... I've suppressed the tests for now.  Hopefully this might get fixed in the future when they move off of the request package?

I was able to get it figured out by creating an issue on the nock repo. Seems it was a bug in nock. Solution is here https://github.com/HelloFax/hellosign-nodejs-sdk/issues/80#issuecomment-725212634


⚠ Bofrost.be has degraded performance

In 6342324, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1086 ms

Resolved: Bofrost.be performance has improved in 2c6ccbd.


False positive: duplicate assertion

Project: pip
File link: https://github.com/pypa/pip/blob/12dad051804907fae1b2232fba3d218035881a60/tests/unit/test_req.py#L494

@OlesiaSub
Do we need to check that there was a reassignment of the variable between duplicate assertions to avoid such FPs?

yes, I think we even discussed it a while ago. and I guess I could implement it.


[question] jump to matching bracket

Is there a way to jump to the matching bracket? Like % in vim.
Currently, micro underlines the matching bracket but it's not very visible. Changing the background color of the matching bracket would be much more visible. Is that possible?

Is there a way to jump to the matching bracket? Like % in vim.

Yes, there is JumpToMatchingBrace action for that, although not bound to any key by default. You can bind it to any key you like. I have it bound to Alt-k in my bindings.json.

Currently, micro underlines the matching bracket but it's not very visible. Changing the background color of the matching bracket would be much more visible. Is that possible?

Currently micro always only underlines the matching brace, without any color highlighting. But it should be quite easy to implement possibility to override it in the colorscheme file, to highlight it with any color you like.

Thank you! It's very useful. I use the following line:
"Alt-k": "JumpToMatchingBrace,CursorLeft",

I prefer the vim style, i.e. stay on the bracket, hence the step left at the end.

Currently micro always only underlines the matching brace, without any color highlighting. But it should be quite easy to implement possibility to override it in the colorscheme file, to highlight it with any color you like.

It's not clear what you mean. Is it possible now by editing the colorscheme file, or should it be implemented in micro as a new feature?

It's not possible now, but it can be implemented in micro as a new feature.
...Well, it's really easy to implement, so I've just done it: #3019.

Wow, thanks a lot! I can't wait to try it.

I've noticed that is it also already implemented in another (still pending) PR #2876, in a better way: it adds an option to switch between underlining and highlighting, without requiring to modify the colorscheme. (If there is no match-brace color in the colorscheme, it defaults to highlighting braces with reversed colors.)


requireDotNotation breaks for non-latin variable name

Example (copy to the demo, jQuery preset)
obj["π"] = 1;
obj["test"] = 2;

The requireDotNotation error is only reported for the last line, but should also be reported for the first.
Reason for the bug is in
https://github.com/jscs-dev/node-jscs/blob/master/lib/utils.js#L66
The RegExp
/^[a-zA-Z_$][a-zA-Z0-9_$]*$/;

is not describing all possible JavaScript identifiers see section 7.6 in the ES5 spec.

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

Might be useful:
https://mathiasbynens.be/notes/javascript-properties
https://mathiasbynens.be/notes/javascript-identifiers
https://gist.github.com/mathiasbynens/6334847


Enable Zookeeper 3.4 compatibility mode for ZKMasterInquireClient

Both PrimarySelectorClient and ZKMasterInquireClient communicate with ZK servers, but only PrimarySelectorClient has the ZK 3.4 compatibility flag enabled. This brings both in line with each other.

Codecov Report

Merging #14547 (fb635eb) into master (f7b7558) will decrease coverage by 12.59%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##             master   #14547       +/-   ##
=============================================
- Coverage     29.55%   16.95%   -12.60%
+ Complexity     5951     2705     -3246
=============================================
  Files          1494     1494
  Lines         87681    87682        +1
  Branches      10452    10452
=============================================
- Hits          25910    14870    -11040
- Misses        59668    71572    +11904
+ Partials       2103     1240      -863

Impacted Files
Coverage Δ

...ain/java/alluxio/master/ZkMasterInquireClient.java
0.00% <0.00%> (-61.91%)
:arrow_down:

...src/main/java/alluxio/client/UnderStorageType.java
0.00% <0.00%> (-100.00%)
:arrow_down:

.../main/java/alluxio/master/file/meta/InodeView.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...main/java/alluxio/master/metastore/BlockStore.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...ain/java/alluxio/master/table/CatalogProperty.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...ain/java/alluxio/master/table/PartitionScheme.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...n/java/alluxio/master/AbstractPrimarySelector.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...java/alluxio/master/journal/raft/OnceSupplier.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...java/alluxio/master/file/BlockDeletionContext.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...java/alluxio/master/file/contexts/CallTracker.java
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 294 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 f7b7558...fb635eb. Read the comment docs.

alluxio-bot, merge this please

alluxio-bot, merge this please

alluxio-bot, cherry-pick this to branch-2.6 please


@sweir27 => [Artist] Add artist series to works tab

Looks like

Pretty simple, reused the same component as in https://github.com/artsy/force/pull/6000
Will add some tests.

Updated with specs.

Looks good to meee 🚀


chore(CI, packaging): Replace yarn

Completes the move from yarn to just npm, also resolves a reach/router error that I was encountering when attempting to build the docs.
I think this issue stems from a difference in how npm and yarn resolve dependency issues, and that the issue will likely be resolved on its own after switching to the latest (currently alpha) version of the documentation framework. In the meantime adding reach/router as a devDep and initially doing a force install seemed to work around the issue.

@florkbr offered to review.  Thanks, Bryan!


resolve multi-type sets in zng spec and zq implementation

On another topic triggered by working on zst, I would like to figure out what we do with sets.  They come from zeek and show up in the brim app, but we've only ever seen single-type sets and the spec currently says <ntypes> must be 1, in conflict with zeek's generality.  e.g., I think you could declare
set[string,int]
in zeek then say
1 in [["foo",2],["bar",1]]
and this would be true (maybe).  Certainly you could say
["foo",2] in [["foo",2],["bar",1]]
If we got rid of  from the set typedef spec, then we could by future-proofed by knowing if we really had to someday map a zeek multi-typed set, we could do so with a type alias
#zeek_mset0=set[record[c0:type0,c1:type1,...]]
and the app could even hide the dummy column names in the UI because it knows it's funky type alias.  And if you really put set[record[]] in the zng, then the UI could display as is.  I'm guessing this will never need to be done so I like this approach.  Specfically, the proposal is to simplify the set typedef encodinig by getting rid of the   field...
https://github.com/brimsec/zq/blob/zst/zng/docs/spec.md#3113-set-typedef

There was no user-facing change in functionality here. The prior set typedef in the ZNG spec had the concept of ntypes (number of types, i.e. so each element of the set could be a tuple, where each tuple is made up of multiple typed values) but also specified that it could only be equal to 1. To be in sync with this, zq populated ntypes with 1 when creating sets and checked it to be 1 when reading them, but this all effectively added up to only supporting single-typed sets. With the change in the linked PR, ntypes for sets has been dropped from the ZNG spec and zq entirely, locking in support for only single-typed sets. Therefore if a user wants to create a set where each element contains multiple values, they'd just need to define that using one of the existing multi-value types (set, array, record, union) and hence have "a set of sets", "a set of arrays", etc.
The closing comments in the issue description above still apply in that the current building blocks (such as aliasing) could allow us to one day support multi-type sets (i.e. sets of tuples) without further changes to the ZNG spec. However, we don't anticipate this will be necessary because Zeek is the only system we're aware of that has them, and even then it's only inside their "script" land. The last time we tested it, Zeek's own logger has no way to output them when multi-typed.


feat(forms-web-app): add "your appeal statement" page

Adds "your appeal statement" page and placeholder for next step - /task-list

Just so you know, on my PR I added govuk-body in the main.njk because otherwise we had to write it everywhere as you did and from what I understood everything should inherit or override it. I'm not 100% confident, what do you think about that ?

Just so you know, on my PR I added govuk-body in the main.njk because otherwise we had to write it everywhere as you did and from what I understood everything should inherit or override it. I'm not 100% confident, what do you think about that ?

Nice, thanks for flagging. CSS isn't my strong point. I was wondering how that was working differently on the prototype.
I have removed all the extra class attributes.
Please could you re-review? Thanks

Well me neither, at least at the beginning of each project... I think I have a brain issue and no matter how much time I spend on it, if I do not practice 12h everything is being flushed. Frameworks like saas helped me a little bit though.

thanks


Submissions view doesn't show repo name

After I created all the groups, I navigated to the Submissions view, and the repo name was not shown.  The student account name was given in the repo column.
This is related to #5496 where I was suprised that repos were created with the group_xxxx name instead of the student account name.

The "Repository" column on the submissions table displays the group name, not the basename of the group's repository.
This is the expected behaviour so I think this is not a bug.


googlemaps pom incorrect

Hi when updating to 1.0.5 for the google maps version the base dependency is not referenced correctly in the pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>nz.co.trademe.mapme</groupId>
  <artifactId>googlemaps</artifactId>
  <version>1.0.5</version>
  <packaging>aar</packaging>
  <description>MapMe is an Android library that brings the adapter pattern to Maps, simplifying the management of markers and annotations.</description>
  <name>MapMe GoogleMaps</name>
  <url>https://github.com/TradeMe/MapMe.git</url>
  <licenses>
    <license>
      <name>MIT License</name>
      <url>http://www.opensource.org/licenses/mit-license.php</url>
      <distribution>repo</distribution>
    </license>
  </licenses>
  <scm>
    <url>https://github.com/TradeMe/MapMe.git</url>
  </scm>
  <dependencies>
    <dependency>
      <groupId>com.google.android.gms</groupId>
      <artifactId>play-services-maps</artifactId>
      <version>11.8.0</version>
    </dependency>
    <dependency>
      <groupId>com.android.support</groupId>
      <artifactId>appcompat-v7</artifactId>
      <version>27.0.1</version>
    </dependency>
    <dependency>
      <groupId>MapMe</groupId>
      <artifactId>mapme</artifactId>
      <version>unspecified</version>
    </dependency>
    <dependency>
      <groupId>org.jetbrains.kotlin</groupId>
      <artifactId>kotlin-stdlib-jre7</artifactId>
      <version>1.2.31</version>
    </dependency>
  </dependencies>
</project>

Hi @aegis123, good catch!
@jamiesanson looks like this may have been an issue with the way the last version was published. I've just tried publishing to my local m2 repo and the pom seems correct.
Can you try to publish again?

Hi @aegis123,
We had some issues with the Bintray gradle plugin in use for publishing. We removed the plugin in #21, and published version 1.0.6 with the correct *.pom files


which CardDefs.xml do you use?

it seems that some cards in CardDefs.xml are not implemented in fireplace,so which vision of  CardDefs.xml do you use?
the link:https://github.com/HearthSim/hsdata

I used the standard CardDefs.xml, but I only trained with the core/basic card set. There's a function in gameUtils.py that allows you to exclude all cards in training except for a specified set
https://github.com/sirmammingtonham/alphastone/blob/06e633b4b750c002d2d488334aa75b292482651d/alphabot/utils/gameUtils.py#L26-L35
so the non-implemented cards are ignored.
This will be called if is_basic=True. Hopefully fireplace is still being worked on so more cards can be implemented soon.

i run the code with default parameters,so it use the notbasicset files of yours. i can also finds some cards whose effects are not implemented.


Move this into a health.md file in the aio-cli repo

working on this

Closing. Already implemented


Allow overriding tag for synch actions.

It could be useful to test synch actions on alternate image tags

possibly related https://github.com/keboola/docker-bundle/issues/333


Rewrite Installation Manual

Update the Installation Manual to include what we've learned about developing the app on our personal devices/profiles.

Bundle identifiers
Clone, not download, repository
Ignored files
Pushing and committing
Connecting iPad and accessing the Device Management tab
Screenshots

I'd like to do this when I'm away starting July 13th

Here is the installation manual: it does not have the informal section for future researchers included. Installation Manual.pdf
Here is the Google Docs version with the informal section for future researchers: https://docs.google.com/document/d/1zhlsqv8bJtwv9bzFrSA9chb6S54UnqKZZtMW7Iv1Vn8/edit


Use preferred form of traitlets integer

Change Int to the preferred Integer. Traitlets doc

Looks good to me!


Select Big Video More than 10 Minutes

is their any way to upload a big video without trimming it I want to upload video more than 10 mins
Please See to it its urgent
I am using this code
InsGallery.openGallery(this@CreateUserPostActivity, GlideEngine.createGlideEngine(),
GlideCacheEngine.createCacheEngine(), this@CreateUserPostActivity)
InsGallery.applyInstagramOptions(this@CreateUserPostActivity,PictureSelector.create(this)
.openGallery(PictureMimeType.ofVideo())
.videoMinSecond(1200)
.videoMaxSecond(2100)
.recordVideoMinSecond(1200)
but still the trim part gives me only 59 second video how to increase trim size
Thank you

on recording video from camera at 4 minute its crashing please tell me how to handle long duration videos from camera and recording and uploading from gallery as well

@omer-ok have you found the solution? I'm facing the same problem


Splits out ebook generation logic into a seperate module

In anticipation of supporting multiple output formats, and other operations (e.g. checking to see if a story has been updated, reading in terminal).
Two notable changes or flaws I may need to tweak further:

I changed the default text from Helvetica to FreeSans because I didn't have Helvetica on my system and it was causing problems. Not sure if this is the right choice though. Feel free to tell me to nix that change.

No longer will cache base.css if the user is using a cached session. If this is a problem, I could move the session making code into it's own module to share it, but I figure given that it's a small site and github if fairly reliable, it's a small price to pay.

I'm generally okay with all this.
I'm going to come back and change the font stuff after I merge it -- I don't have FreeSans on my system, after all. Seems like the sane approach would be to pick one of the "safe" fonts and have it be a fallback to whatever the user tried to pass in.
There's some unrelated stuff with adding the url to Sections, but I don't mind that and can see the use.

I made 619a013 for cover font fallbacks.

...and 8ac1aa8 so people can set their own font and other cover options, if my fallback choices were terrible.


AttributeError: 'App' object has no attribute 'server'

when i try “python app.py”， it returns “AttributeError: 'App' object has no attribute 'server'”. what's wrong

I encountered the same problem, found any solution ?

No progress

Same problem using docker-compose up

Same problem here! Any help would be great

+1

https://github.com/bhaskatripathi/pdfGPT/issues/60

Suggest closing this in favor of #60


Associated Stations: flip-flop between IPv4 name and useless IPv6 name

Associated Stations seems to now show both IPv4 and IPv6 for clients. It used to be the case that only IPv4 was shown with the correct host name based on a reverse DNS lookup.
I do not use IPv6 on my network and these IPv6 addresses are all link local that sometimes don't resolve to any name and other times they resolve to useless names such as Android-3.local when the IPv4 resolves to a useful name, e.g. myphone.
What's worse is that as the Associated Stations page auto-refreshes, sometimes you see the IPv4 name other times the useless IPv6 name, it just keeps flip-flopping between the two.
Can Luci just show the name corresponding to the IPv4 and ignore names from link local IPv6 (those that start with fe80::)?
Or is there something in OpenWRT that I can turn off to not discover these IPv6 addresses at all?

Same Problem, different description.... #5368

Should've been addressed with 93bd93e220714276eff95ea51793bb2f826328e8, 45a398e1ed86c9706d47ff46be73bdaa303ff661 and af4352c07ef33ebb06a0c7f684f3f753b9c23f4f
Will be cherry-picked to openwrt-21.02 once it received more testing

Awesome, thanks! Look forward to the next 21.02 release.

I thought it come up with the update function, isnt it ?
Or do we have to wait until 21.02.1 ?


feat(react-query): add queryOptions

fix #767 with @wes5510
@wes5510 I guess that this issue is simmilar issue with https://github.com/TanStack/query/issues/6556
I want to solve this issue like https://github.com/TanStack/query/issues/6556#issuecomment-1863164001 (Is this solution same with your opinion?). In my opinion, I think it would be a good idea to add queryOptions

select type when I hover on field name

select type when I hover on select's arg
I expected TData but it's any!!??🥲

I mention you because you suggested this interface(queryOptions) and I've wanted to add it for a while too. I would like to request a review to you with our maintainers.
Solution: new queryOptions
This new queryOptions will solve select's type issue like https://github.com/TanStack/query/issues/6556#issuecomment-1863164001
More advantages
Tkdodo, The maintainer of TanStack Query explains well why this interface is needed in video explaining queryOptions in TanStack Query v5.
You can also use queryOptions in TanStack Query v4.

QueryKey management becomes easier by processing queryKey and queryFn together.
You can remove unnecessary custom query hooks. This is because they can all be used directly in useQuery, useQueries of TanStack Query v4, and useSuspenseQuery, useSuspenseQueries, and SuspenseQuery of Suspensive React Query.
TanStack Query v5 already supports queryOptions. This Suspensive React Query's queryOptions will make migration from TanStack Query v4 to TanStack Query v5 easier.

import { queryOptions, useSuspenseQuery, useSuspenseQueries, SuspenseQuery } from '@suspensive/react-query'
import { useQuery, useQueries, useQueryClient } from '@tanstack/react-query'

const postQueryOptions = (postId) =>
   queryOptions({
     queryKey: ['posts', postId] as const,
     queryFn: ({
       queryKey: [, postId], // You can use queryKey.
     }) => fetch(`https://example.com/posts/${postId}`),
   })

// No need to create custom query hooks.
// You can use queryOptions directly in useQuery, useQueries, useSuspenseQuery, useSuspenseQueries, SuspenseQuery.
const post1Query = useQuery(postQueryOptions(1))
const { data: post1 } = useSuspenseQuery({
   ...postQueryOptions(1);
   refetchInterval: 2000, // Extensibility is clearly expressed in usage.
})
const [post1Query, post2Query] = useQueries({
   queries: [postQueryOptions(1), { ...postQueryOptions(2), refetchInterval: 2000 }],
})
const [{ data: post1 }, { data: post2 }] = useSuspenseQueries({
   queries: [postQueryOptions(1), { ...postQueryOptions(2), refetchInterval: 2000 }],
})
const Example = () => <SuspenseQuery {...postQueryOptions(1)}>{({ data: post1 }) => <>{post1.text}</>}</SuspenseQuery>

// You can easily use queryKey and queryFn in queryClient's methods.
const queryClient = useQueryClient()
queryClient.refetchQueries(postQueryOptions(1))
queryClient.prefetchQuery(postQueryOptions(1))
queryClient.invalidateQueries(postQueryOptions(1))
queryClient.fetchQuery(postQueryOptions(1))
queryClient.resetQueries(postQueryOptions(1))
queryClient.cancelQueries(postQueryOptions(1))

PR Checklist

[x] I did below actions if need

I read the Contributing Guide
I added documents and tests.

@wes5510 FYI
If you okay, approve this Pull Request please

@wes5510 This is Pull Request for @suspensive/react-query beta version. so I'll merge first. and then we will improve it gradually if need. Your interest has made our library better. thank you!


Some fields insert unnecessary markup into templates

Current:

hello world

Ideal:

hello world

This also happens with StreamBlocks, where each item is wrapped in a
. I've yet to find a use for these blocks, and in fact have written code to disable them every time I use a StreamBlock.

I think this comes under the category of "it seemed like a good idea at the time" :-)
As I recall, the rationale for this was that you often want to give images (and potentially other elements) CSS rules such as max-width: 100% within rich text areas, without having to make those rules universal for all images across the site. The assumption was that the extra div wouldn't interfere with the styling for people who didn't want to make use of it (unless their CSS was particularly odd!) and therefore it would be better to include it as standard, rather than require template developers to insert a wrapper element manually when they did need one.
(I think it may also have been related to the ongoing difficulty in ensuring that rich-text content is consistently wrapped in
 tags - the wrapper element gives an extra place to fix up margins.)
However, it does break our rule of Wagtail not dictating your front-end markup.
Clearly this isn't going to be straightforward to change, given that there's plenty of existing CSS in the wild that relies on that element. We'd probably want a flag in settings to restore the old behaviour. (Going through the formal deprecation process would be even more of a faff - having the flag set to the old behaviour by default, and then explicitly setting it to new behaviour in the settings file of the project template. That's probably overkill.)
My gut feeling is that the situation with StreamBlock is a bit different - I think that's more akin to Django forms, where you get a certain default rendering if you output it as a single unit ({{ self.body }}), and if you don't like that, you have the option to iterate over it instead. Admittedly, I can't think of many situations where the
 wrapper is absolutely necessary to distinguish between different blocks for CSS purposes - if you're working with StructBlocks then you'll be specifying your own template (which can include all the identifying element classes you want), so it's only relevant if you have, say, two different 'flavours' of RichTextBlock.
It's worth noting that if we make both of these proposed changes, then in the default rendering, there will be no difference in markup between a single RichTextBlock containing two paragraphs, and two consecutive RichTextBlocks with one paragraph each. I can't decide whether that's a good thing or not!

In my implementations of streamfield so far i've never used the default rendering, so the difference between two individual paragraphs blocks and one two-paragraph block hasn't been an issue. As you say like with Django forms, if you're making even slightly custom layouts you start by discarding the default rendering.
I think with improved documentation we could persuade more people to use custom streamfield block rendering. Documenting with a direct comparison to django forms (if we aren't already) would provide much of the.

For now I'll add an optional param to the richtext filter to disable the wrapping div. quick fix!

Is there any way to disable the creation of these wrapping elements? It completely breaks my CSS :( I tend to use logical CSS instead of heaps of classes; so this breaks stuff like section + section { … }. Any help would be appreciated!

:+1: for solve this, i have very anoying thins when i was trying update hallo.js

Just wanted to +1 this. Is there a work-around to at least remove the richtext class?

@gasman should we put this back on the radar in the context of 2.0 / new draftail editor?
I personally ran into this issue yesterday with a StreamField RichTextBlock using specific layout rendering, also this question came up on Stack Overflow:
https://stackoverflow.com/questions/47415978/custom-render-richtextblock-to-remove-div-class-rich-text
I am happy to do this as it seems simple, except not sure how to go about backwards compatibility (or if we want that for this area in 2.0).

We created https://github.com/springload/wagtaildraftail (a third-party plugin integrating https://springload.github.io/draftail/ into Wagtail) in part to address this.
This integration of Draftail gives developers more control over how the rich text HTML is rendered, so that classes can be added on arbitrary elements if needed. This makes the wrapper .rich_text div unnecessary.
Here is an [example from the config](https://github.com/springload/wagtaildraftail/blob/87f1ae3ade493c00daff021394051aa656136c10/tests/testapp/testapp/grains/rich_text.py#L130-L145], adding classes to lists to facilitate their styling:
DRAFT_EXPORTER_BLOCK_MAP = dict(BLOCK_MAP, **{
    BLOCK_TYPES.UNORDERED_LIST_ITEM: {
        'element': 'li',
        'wrapper': 'ul',
        'wrapper_props': {'class': 'list-styled'},
    },
    BLOCK_TYPES.ORDERED_LIST_ITEM: {
        'element': 'li',
        'wrapper': 'ol',
        'wrapper_props': {'class': 'list-numbered'},
    },
})

If anyone is interested in this, a rough but good demonstrator of how this works is available at http://draftjs-exporter.herokuapp.com/. That one doesn't use WagtailDraftail, but is nonetheless a good demo of how this handles rich text.

@lb- for Wagtail 2.0, the general direction we discussed at the Bristol sprint was to focus on changing the rich text editor widget (so, Hallo to Draftail) first and foremost, then attack other issues that this will help address in following releases.
I'm not sure if/when we will get to porting the WagtailDraftail feature that allows customisation of how rich text HTML is rendered, but if/when that happens the migration path is rather simple: remove the .rich_text tag, and ask people to either add it manually in their templates, or configure this HTML generation to add the wrapper where appropriate.

This is causing us some headaches. Would you accept a pull-request adding a new setting to disable the
 divs?
My only solution at the moment is to monkey-patch the RichText.__html__ method 😟

Generally we want to keep the proliferation of settings in check – but we’ve recently added a setting for a very similar type of "Wagtail shouldn’t be opinionated about HTML" in WAGTAILEMBEDS_RESPONSIVE_HTML, making this type of front-end customization opt-in. So – it feels like that wrapper div could get the same treatment.
I’ll mark this as "Design decision needed" so we bring it up and discuss at a future core team meeting.

At the moment the richtext filter hardcodes the wrapping div.
If Wagtail used a template it would be easy to override and drop the div.
wagtail.core.templatetags.wagtailcore_tags.richtext returns:
 return mark_safe('
' + html + '
')

If we change that to:
 from django.template.loader import render_to_string
 ...
 return render_to_string('wagtailcore/richtext.html', {'html': html})

With a template at wagtail/core/templates/wagtailcore/richtext.html:

{{ html|safe }}

Now an integrator can override by creating a template file in /path/to/app/templates/wagtailcore/richtext.html. Eg:
 {{ html|safe }}

Resolved via #6036

Is there a timeline on 2.10?


Upgrade all npm packages.

Description
Upgrade all npm packages and fixes some code to supports new maplibre-gl-style-spec.
It includes some security fixes, and update for sprite-one new release.
Type of Pull Request

[ ] Adding a feature
[ ] Fixing a bug
[ ] Maintaining documents
[x] Others (maintenance libraries)

Verify the followings

[x] Code is up-to-date with the main branch
[x] No build errors after npm run build
[x] No lint errors after npm run lint
[x] No errors on using charites help globally
[x] Make sure all the existing features working well
[ ] Have you added at least one unit test if you are going to add new feature?
[ ] Have you updated documentation?

Refer to CONTRIBUTING.MD for more details.

16.x Windows build was failed, but I did re-run test, the build was passed.


feat: file transfers analytics rules based on threshold

Change(s):

Add file transfer analytics rules

Reason for Change(s):

More data exfiltration detection based on static threshold to adapt to context
Adapted for OpenSSH SFTP, Sharepoint and Progress MoveIt logs

Version Updated:

No (new rules, starting 1.0.0)

Testing Completed:

Yes

Checked that the validations are passing and have addressed any issues that are present:

Pending CI

Note: for moveit, I put in Windows Forwarded Event folder but not sure if best. In my case, logs are in Events table collected through AMA.

Hi @juju4, please shorten the description of all the analytical rules to 255 characters only.

description was inspired of Syslog/Analytic Rules/ssh_potentialBruteForce.yaml and many other yaml files seem to be above 255.
If too long, where do we put other information? any extended description or note field?
mostly the entity mapping for array limitation information.
Also how to add grouping (aggregationKind) on selected entities?
If not already, it would be nice if the yaml rule schema was documented somewhere public as it does not seem to be 1:1 mapping of the ARM template.

Hi @juju4, we acknowledge your concern, let me get back to you by 10 Oct 2023.

Hi @juju4, sorry for delay in response.
To answer your first question, the limit for 255 characters is only for Hunting queries and not for Analytical rules, so please ignore that.
Regarding second question, we will get back to you by 12 Oct 2023.

Also how to add grouping (aggregationKind) on selected entities? If not already, it would be nice if the yaml rule schema was documented somewhere public as it does not seem to be 1:1 mapping of the ARM template.

Hi @juju4, for this question, you can refer to this document - https://github.com/Azure/Azure-Sentinel/wiki/Query-Style-Guide

Apart from that, I could there are some validations which are failing in the PR.
To fix them, please change the extensions of files Solutions/Windows Forwarded Events/Analytic Rules/moveit_file_transfer_above_threshold.yml, Solutions/Windows Forwarded Events/Analytic Rules/moveit_file_transfer_folders_above_threshold.yml to .yaml

file extension renaming done.
On eventGroupingSettings, this is not the grouping that I was looking for.
I was searching for setting to group repeated alerts based on selected entities, typically Hostname and Account.
Not grouping based on multiple KQL results.
Would this be exist in the yaml definition?
In ARM template, it would be groupingConfiguration as per https://learn.microsoft.com/en-us/azure/templates/microsoft.securityinsights/2022-01-01-preview/alertrules?pivots=deployment-language-bicep#groupingconfiguration with matchingMethod = Selected

Tests all green now

Thanks!


intermittent segfault on featureview draw

Program raises segfault 11 during the updateGL() call in FeatureView.set_data() (line 1325). This intermittently happens when using the wizard to select 2 clusters. I can't figure out what makes any given cluster pair cause the fault.
This is intermittent in many datasets, but reproducible in one dataset that I have. This occurs on MacOS 10.10.3 but not on Windows (at least with the same clusters in the dataset I am using).
When it doesn't fault, this cluster pair creates a weird pattern on the featureview.

I am working to see if I can fix today.

Closed by #51.


Translation does not work completely

Hi there,
I just at your module to my MMM, but the translation to other languages than "en" didn't work to 100%.
So in "Today" and "Tomorrow" in the views will not translate, I only see the view.
Tested with fr, de, nl and it.
Is there a way to fix this?

https://github.com/eouia/MMM-CalendarExt2/wiki/Localization

I tried this but it still not work. "Today" and "Tomorrow" is only viewed in english

What's your default locale and what is done in config.js and what to expect? tell me more details.
Show your configuration about this module.

So my default-language is de-DE,
in all my config I define "de.DE" like in your Wiki. Also I changed the config for the views with german. But the result is the same, in the button_bar an the config looks like below:
{
module: "MMM-CalendarExt2",
config: {
locale: "de-DE",
calendars: [
{
name: "Joern Privat",
beforeDays: 10,
afterDays: 30,
scanInterval: 1000605,
url: ,
icon: "fa-solid:swimmer",
className: "Joern",
},
{
name: "Zelda Multi",
beforeDays: 10,
afterDays: 30,
scanInterval: 1000605,
url:
icon: "emojione-monotone:family-man-woman-girl-boy",
className: "Zelda",
},
{
name: "Nora Work",
beforeDays: 10,
afterDays: 30,
scanInterval: 1000605,
url: ,
icon: "fa-solid:laptop-house",
className: "Nora",
},
],
views:[
{
name: "Overview Private",
title: "Aktuelle Termine",
mode: "daily",
type: "row",
position: "bottom_bar",
slotCount: 5,
locale: "de-DE",
hideOverflow: false,
filterPassedEvent: true,
dateFormat: "MM/Do",
dateTimeFormat:{
sameDay: "[Heute] HH:mm",
nextDay: "[Morgen] HH:mm"
},
calendars: ["Joern Privat","Zelda Multi","Nora Work"],
},
],
scenes:[
{
name: "DEFAULT",
views: ["Overview Private"],
},
]
},
	},

use this into your target view configuration.
slotTitleFormat:{
          sameDay: "[Heute]",
          nextDay: "[Morgen]",
          nextWeek: "dddd",
          lastDay: "[Gestern]",
          lastWeek: "[Letzen] ddd",
          sameElse: "MM/Do"
},

Mam you saved my day! Special thanks to your support!

okay, I tried your documentation and don't know how to fix the problem for a daily entry.

Currently I don't find the solution to translate this position....

that is dateFormat. override it as same with slotTitleFormat


Fixed #27653 -- Improved Ukrainian locale formats.

Thanks, could you ask a Ukrainian colleague to review the patch?

Maybe @sorenabell?

Looks good. The main Ukrainian pecularity - datetime order date.month.year is preserved.

buildbot, add to whitelist.

Thanks Zoriana for the prompt review!

Always happy to help)