vectorize _rng functions

It would be nice to include R-like versions that take a first argument for the number of draws to make and return an array of those draws.  There's an issue with array types not being assignable to vectors (yet, anyway).  I don't think it's worth having additional row vector and column vector versions --- it's usually just for constructing simulation draws for the output.
Although not strictly necessary, it would be most useful if the vectorized methods did the heavy lifting on things like solving systems of equations for generating multivariate normals only once.
A really ambitious version would also allow vectorized parameters and set everything up to work like the probability functions with repeated computations minimized.
This is a pretty simple modular project that doesn't get into any of Stan's complicated internal data types for automatic differentiation.  But there are a lot of distributions, so a lot of functions and tests to add.

This issue was moved to stan-dev/math#45


[CI] Remove libxsmm-dnn buildkite scripts

For some reason the tests did not run. I'm not sure why but I'm assuming a glitch in Buildkite. I'll force merge this and if I break the CI on main, we can revert and investigate.


kfctl should support using kustomize to compose a stack of applications

kfctl should support using kustomize to compose a stack of applications.

Design doc: http://bit.ly/kf_kustomize_v3

Issue: kubeflow/manifests#774

Update kfctl to properly generate a kustomize application based on the
Kubeflow application stack. The new application will use as a base
the stack as provided in the KfDef.

Here's how this works. A KFDef would define a new application "kubeflow-apps"
apiVersion: kfdef.apps.kubeflow.org/v1
kind: KfDef
metadata:
  creationTimestamp: null
  name: stack_test
  namespace: kubeflow
spec:
  applications:
  - kustomizeConfig:
      repoRef:
        name: manifests
        path: stacks/gcp
    name: kubeflow-apps

The "path" would point to a kustomize application that composes all of the packages to be deployed.

Instead of copying this kustomize package to ${KFAPP}/kustomize, kfctl defines a new kustomize application that uses the stack as a base

The advantage of this approach is that to upgrade and pull in any changes the user just
needs to refresh the .cache directory

For this application we change the logic for setting application parameters; instead of modifying the parameters in the KFDef we generate a configmap patch for the application that sets the
parameter.

This change is

/assign @gabrielwen
/assign @yanniszark
The design was approved at this week's community meeting so this PR is ready to go.

@gabrielwen I made your changes could you please re-lgtm?

/hold cancel

/lgtm
/approve


babel-node command not found error when starting docker

Partial return of docker-compuse up:
web_1    | npm info using<EMAIL_ADDRESS>web_1    | npm info using<EMAIL_ADDRESS>web_1    | npm info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>web_1    | npm info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>web_1    |
web_1    | ><EMAIL_ADDRESS>start /usr/src/app
web_1    | > babel-node src/server/
web_1    |
web_1    | sh: 1: babel-node: not found
web_1    |
web_1    | npm info lifecycle<EMAIL_ADDRESS>Failed to exec start script
web_1    | npm ERR! Linux 4.4.27-moby
web_1    | npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "start"
web_1    | npm ERR! node v6.9.1
web_1    | npm ERR! npm  v3.10.8
web_1    | npm ERR! file sh
web_1    | npm ERR! code ELIFECYCLE
web_1    | npm ERR! errno ENOENT
web_1    | npm ERR! syscall spawn
web_1    | npm ERR<EMAIL_ADDRESS>start: `babel-node src/server/`
web_1    | npm ERR! spawn ENOENT
web_1    | npm ERR!
web_1    | npm ERR! Failed at the<EMAIL_ADDRESS>start script 'babel-node src/server/'.
web_1    | npm ERR! Make sure you have the latest version of node.js and npm installed.
web_1    | npm ERR! If you do, this is most likely a problem with the launchpad package,
web_1    | npm ERR! not with npm itself.
web_1    | npm ERR! Tell the author that this fails on your system:
web_1    | npm ERR!     babel-node src/server/
web_1    | npm ERR! You can get information on how to open an issue for this project with:
web_1    | npm ERR!     npm bugs launchpad
web_1    | npm ERR! Or if that isn't available, you can get their info via:
web_1    | npm ERR!     npm owner ls launchpad
web_1    | npm ERR! There is likely additional logging output above.
web_1    | npm WARN Local package.json exists, but node_modules missing, did you mean to install?
web_1    |
web_1    | npm ERR! Please include the following file with any support request:
web_1    | npm ERR!     /usr/src/app/npm-debug.log

This was resolved by defcb20108a7b3bd312af3f72cc11baac4dba128. The node_modules directory was being rebound when the root directory was copied into the container. Specifying node_modules as a separate volume in the Dockerfile prevents this from happening.


[11.x] Add support for AVIF image format in validation

Hello All!
This PR adds support for avif image extensions in the Validation for image files. Avif is now a Baseline 2024 format (it works across all browsers) and is now the recommended image format for the web.
It also adds tests and removes some duplicated assertions that i found inside the tests.
Thanks!

https://github.com/laravel/framework/pull/36803#issuecomment-809621851
target 12.x maybe?

#36803 (comment)
target 12.x maybe?

Supporting the AVIF format shouldn’t be considered a breaking change; in fact, the validator’s lack of support for it is more akin to a bug.
When you request image validation, you expect the validator to handle all popular formats.
If an application chooses not to support AVIF (or any other specific image format), it should explicitly define its accepted MIME types

It is a breaking change as noted. People currently expect that rule to do what it is documented as doing.

can i PR to 12.x then?


Messy handling of vectorized is.na and is.nan

Vectorized is.na does not work through compilation but could be supported.  Vectorized is.nan compiles but silently only operates on the first element.

See also #987

@paciorek is nimble's any_nan function the one you're meaning to use?

@danielturek I don't understand your question. "meaning to use" when/where?


suppress versionCheck

is there a way to prevent the versionCheck ajax call from happening without e.g. making a custom build of glimpse?

Currently there is no way to do this. We never thought anyone would be interested in not knowing about updates. That said, if you are interested in doing the work, it shouldn't be that hard to put in and I can give you some pointers on where to start.

Well, it's not so much about not knowing about updates as it is not appropriate to be making gratuitous network calls in a production environment. I could probably do the work when I get some time.

Sounds like a plan.
On Monday, April 27, 2015, ariovistus<EMAIL_ADDRESS>wrote:

Well, it's not so much about not knowing about updates as it is not
appropriate to be making gratuitous network calls in a production
environment. I could probably do the work when I get some time.
—
Reply to this email directly or view it on GitHub
https://github.com/Glimpse/Glimpse/issues/895#issuecomment-96904519.

Looks like the check happens in javascript and can be short circuited here: https://github.com/Glimpse/Glimpse/blob/61857be49fdab5af887d70cc9d85ff4a4a3a7358/source/Glimpse.Core/glimpse.js#L2129
A global variable would git 'er done, but wouldn't go too far towards ensuring no page in your webapp does the check. Would it make sense to add a policy to glimpse and inject a bit of javascript if the policy says it's appropriate?


createSPList subactions

Hello folks,
Why does not "subactions" addFolder work at defined in schema?

Bump?


[BUG] Sync latest cypress to functional test repo

What is the bug?
https://github.com/opensearch-project/opensearch-dashboards-functional-test/tree/main/cypress/integration/plugins/notifications-dashboards don't have latest cypress test code
How can one reproduce the bug?
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

What is the expected behavior?
A clear and concise description of what you expected to happen.
What is your host/environment?

OS: [e.g. iOS]
Version [e.g. 22]
Plugins

Do you have any screenshots?
If applicable, add screenshots to help explain your problem.
Do you have any additional context?
Add any other context about the problem.

#https://github.com/opensearch-project/opensearch-dashboards-functional-test/pull/773


Drop @types/react peer dependency from ^18.2.25 to ^18.0

Overview
According to the DefinitelyTyped project FAQ here,  @types dependencies should align with the MAJOR.MINOR of the source project, while the PATCH version is managed independently.

Because the version is listed as 20.8.9999, the npm version of the @types/node package will also be 20.8.x. Note that the version in package.json should only contain major.minor version (e.g. 10.12) followed by .9999. This is because only the major and minor release numbers are aligned between library packages and type declaration packages.

This alignment helps prevent dependency duplication in the node_modules folder, particularly for projects using pinned or tilde versions.
Below is an example of a project with the @types/react dependency version lower than the one required by the current react-redux project peer dependency.
This is the output of running yarn install:

Here is is the output of running yarn explain peer-requirements <hash>:

This output advises the user to update their dependencies to match those required by react-redux in order to avoid duplication.
This PR

drops @types/react peer dependency from ^18.2.25 to ^18.0

Are we dependent on anything from 18.1 or 18.2?

I'm not sure. I feel like there was something in 18.2-ish that mattered when we made that change, but I don't remember the specifics.

#2092 I think?

Ah, yes, that sounds right.
Given that I think we should close this. Thanks anyway!


Bug: Curtain closed in SwitchBot app, appears open in Homekit

Describe The Bug
Curtain closed in SwitchBot app, appears open in Homekit
To Reproduce
Calibrate curtain, close, check homekit
Expected behavior
Closed in Switch app is closed in Homekit
Relevant log output
[18/11/2022, 19:44:38] [SwitchBot] [DEBUG] Curtain: Gordijnen openAPIRefreshStatus
[18/11/2022, 19:44:38] [SwitchBot] [DEBUG] Curtain: Gordijnen sign: 3uAxyhUQam0bUot5fe8Ccgyim0m+p93FbW0ZuzbLXXXX
[18/11/2022, 19:44:38] [SwitchBot] [DEBUG] Curtain: Gordijn rechts openAPIRefreshStatus
[18/11/2022, 19:44:38] [SwitchBot] [DEBUG] Curtain: Gordijn rechts sign: akcDya7YGig8kqJjop9mYyq7FzGRoNp0pLDF2xxwXXXX
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijnen statusCode: 200
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijnen d: {"statusCode":100,"body":{"deviceId":"E3255EA7XXXX","deviceType":"Curtain","hubDeviceId":"CD482162XXXX","slidePosition":0},"message":"success"}
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijnen refreshStatus: {"statusCode":100,"body":{"deviceId":"E3255EA7XXXX","deviceType":"Curtain","hubDeviceId":"CD482162XXXX","slidePosition":0},"message":"success"}
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijnen openAPIparseStatus
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain Gordijnen CurrentPosition: 100
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijnen Standby, CurrentPosition: 100
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijnen Stopped
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijnen CurrentPosition: 100, TargetPosition: 100, PositionState: 2,
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijnen CurrentAmbientLightLevel: 6001
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijnen updateCharacteristic CurrentPosition: 100
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijnen updateCharacteristic PositionState: 2
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijnen updateCharacteristic TargetPosition: 100
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijnen updateCharacteristic CurrentAmbientLightLevel: 6001
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijn rechts statusCode: 200
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijn rechts d: {"statusCode":100,"body":{"deviceId":"F4786AF8XXXX","deviceType":"Curtain","hubDeviceId":"CD482162XXXX","slidePosition":0},"message":"success"}
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijn rechts refreshStatus: {"statusCode":100,"body":{"deviceId":"F4786AF8XXXX","deviceType":"Curtain","hubDeviceId":"CD482162XXXX","slidePosition":0},"message":"success"}
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijn rechts openAPIparseStatus
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain Gordijn rechts CurrentPosition: 100
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijn rechts Standby, CurrentPosition: 100
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijn rechts Stopped
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijn rechts CurrentPosition: 100, TargetPosition: 100, PositionState: 2,
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijn rechts CurrentAmbientLightLevel: 6001
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijn rechts updateCharacteristic CurrentPosition: 100
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijn rechts updateCharacteristic PositionState: 2
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijn rechts updateCharacteristic TargetPosition: 100
[18/11/2022, 19:44:39] [SwitchBot] [DEBUG] Curtain: Gordijn rechts updateCharacteristic CurrentAmbientLightLevel: 6001
[18/11/2022, 19:45:31] [SwitchBot] [DEBUG] Curtain: Gordijnen No Changes, Set TargetPosition: 33
[18/11/2022, 19:45:31] [SwitchBot] [DEBUG] Curtain: Gordijnen value: 33, CurrentPosition: 100
[18/11/2022, 19:45:31] [SwitchBot] [DEBUG] Curtain: Gordijnen updateRate: 7
[18/11/2022, 19:45:32] [SwitchBot] [DEBUG] Curtain: Gordijnen OpenAPI pushChanges
[18/11/2022, 19:45:32] [SwitchBot] [DEBUG] Curtain: Gordijnen sign: dn49xvlcZxmS+HyBT9vAMP8NEsyxpiIwxUbm6GRwXXXX
[18/11/2022, 19:45:32] [SwitchBot] [DEBUG] Pushing 33
[18/11/2022, 19:45:32] [SwitchBot] [DEBUG] Gordijnen Mode: Default Mode
[18/11/2022, 19:45:32] [SwitchBot] [DEBUG] Curtain: Gordijnen Sending request to SwitchBot API, body: {"command":"setPosition","parameter":"0,ff,67","commandType":"command"},
[18/11/2022, 19:45:32] [SwitchBot] [DEBUG] Curtain: Gordijnen openAPIpushChanges: {"_events":{"response":[Function],"error":[Function]},"_eventsCount":2,"_maxListeners":[Undefined],"outputData":[{"data":"POST /v1.1/devices/E3255EA7XXXX/commands HTTP/1.1\r\nAuthorization: 8668c1cd56faef6d66e6226497b815c36ea08c41c1a47b8a715a548c83d4258c0ff370ad65f65fffe050e1d84a81XXXX\r\nsign: dn49xvlcZxmS+HyBT9vAMP8NEsyxpiIwxUbm6GRwXXXX\r\nnonce: requestID\r\nt: 166879713XXXX\r\nContent-Type: application/json\r\nContent-Length: 71\r\nHost: api.switch-bot.com\r\nConnection: close\r\n\r\n{\"command\":\"setPosition\",\"parameter\":\"0,ff,67\",\"commandType\":\"command\"}","encoding":[Undefined],"callback":[Function]},{"data":"","encoding":"latin1","callback":[Function]}],"outputSize":422,"writable":true,"destroyed":false,"_last":true,"chunkedEncoding":false,"shouldKeepAlive":false,"maxRequestsOnConnectionReached":false,"_defaultKeepAlive":true,"useChunkedEncodingByDefault":true,"sendDate":false,"_removedConnection":false,"_removedContLen":false,"_removedTE":false,"strictContentLength":false,"_contentLength":71,"_hasBody":true,"_trailer":"","finished":true,"_headerSent":true,"_closed":false,"socket":null,"_header":"POST /v1.1/devices/E3255EA7XXXX/commands HTTP/1.1\r\nAuthorization: 8668c1cd56faef6d66e6226497b815c36ea08c41c1a47b8a715a548c83d4258c0ff370ad65f65fffe050e1d84a81XXXX\r\nsign: dn49xvlcZxmS+HyBT9vAMP8NEsyxpiIwxUbm6GRwXXXX\r\nnonce: requestID\r\nt: 166879713XXXX\r\nContent-Type: application/json\r\nContent-Length: 71\r\nHost: api.switch-bot.com\r\nConnection: close\r\n\r\n","_keepAliveTimeout":0,"_onPendingData":[ReferenceTo this.outputData[0].callback],"agent":{"_events":{"free":[Function],"newListener":[Function]},"_eventsCount":2,"_maxListeners":[Undefined],"defaultPort":443,"protocol":"https:","options":{"noDelay":true,"path":null},"requests":{},"sockets":{"api.switch-bot.com:443:::::::::::::::::::::":[{"_tlsOptions":{"allowHalfOpen":[Undefined],"pipe":false,"secureContext":{"context":{}},"isServer":false,"requestCert":true,"rejectUnauthorized":true,"session":[Undefined],"ALPNProtocols":[Undefined],"requestOCSP":[Undefined],"enableTrace":[Undefined],"pskCallback":[Undefined],"highWaterMark":[Undefined],"onread":[Undefined],"signal":[Undefined]},"_secureEstablished":false,"_securePending":false,"_newSessionPending":false,"_controlReleased":true,"secureConnecting":true,"_SNICallback":null,"servername":null,"alpnProtocol":null,"authorized":false,"authorizationError":null,"encrypted":true,"_events":{"close":[[Function],[Function],[Function]],"end":[[Function],[Function]],"newListener":[Function],"connect":[Function],"secure":[Function],"session":[Function],"free":[Function],"timeout":[Function],"agentRemove":[Function]},"_eventsCount":9,"connecting":true,"_hadError":false,"_parent":null,"_host":"api.switch-bot.com","_closeAfterHandlingError":false,"_readableState":{"objectMode":false,"highWaterMark":16384,"buffer":{"head":null,"tail":null,"length":0},"length":0,"pipes":[],"flowing":null,"ended":false,"endEmitted":false,"reading":false,"constructed":true,"sync":true,"needReadable":false,"emittedReadable":false,"readableListening":false,"resumeScheduled":false,"errorEmitted":false,"emitClose":false,"autoDestroy":true,"destroyed":false,"errored":null,"closed":false,"closeEmitted":false,"defaultEncoding":"utf8","awaitDrainWriters":null,"multiAwaitDrain":false,"readingMore":false,"dataEmitted":false,"decoder":null,"encoding":null},"_maxListeners":[Undefined],"_writableState":{"objectMode":false,"highWaterMark":16384,"finalCalled":false,"needDrain":false,"ending":false,"ended":false,"finished":false,"destroyed":false,"decodeStrings":false,"defaultEncoding":"utf8","length":0,"writing":false,"corked":0,"sync":true,"bufferProcessing":false,"onwrite":[Function],"writecb":null,"writelen":0,"afterWriteTickInfo":null,"buffered":[],"bufferedIndex":0,"allBuffers":true,"allNoop":true,"pendingcb":0,"constructed":true,"prefinished":false,"errorEmitted":false,"emitClose":false,"autoDestroy":true,"errored":null,"closed":false,"closeEmitted":false},"allowHalfOpen":false,"_sockname":null,"_pendingData":null,"_pendingEncoding":"","server":[Undefined],"_server":null,"ssl":{"_parent":{"reading":false,"onconnection":null},"_parentWrap":[Undefined],"_secureContext":[ReferenceTo this.agent.sockets.api.switch-bot.com:443:::::::::::::::::::::[0]._tlsOptions.secureContext],"reading":false,"onkeylog":[Function],"onhandshakestart":[Function],"onhandshakedone":[Function],"onocspresponse":[Function],"onnewsession":[Function],"onerror":[Function]},"_requestCert":true,"_rejectUnauthorized":true}]},"freeSockets":{},"keepAliveMsecs":1000,"keepAlive":false,"maxSockets":null,"maxFreeSockets":256,"scheduling":"lifo","maxTotalSockets":null,"totalSocketCount":1,"maxCachedSessions":100,"_sessionCache":{"map":{},"list":[]}},"socketPath":[Undefined],"method":"POST","maxHeaderSize":[Undefined],"insecureHTTPParser":[Undefined],"path":"/v1.1/devices/E3255EA7XXXX/commands","_ended":false,"res":null,"aborted":false,"timeoutCb":null,"upgradeOrConnect":false,"parser":null,"maxHeadersCount":null,"reusedSocket":false,"host":"api.switch-bot.com","protocol":"https:"}
[18/11/2022, 19:45:32] [SwitchBot] Curtain: Gordijnen Set TargetPosition: 0
[18/11/2022, 19:45:32] [SwitchBot] [DEBUG] Curtain: Gordijnen value: 0, CurrentPosition: 100
[18/11/2022, 19:45:32] [SwitchBot] [DEBUG] Curtain: Gordijnen updateRate: 7
[18/11/2022, 19:45:32] [SwitchBot] [DEBUG] Curtain: Gordijnen OpenAPI pushChanges
[18/11/2022, 19:45:32] [SwitchBot] [DEBUG] Curtain: Gordijnen sign: 8zDRMazsiyBs8yYNno3veYYXMJp5+AtxKSyYyKFnXXXX
[18/11/2022, 19:45:32] [SwitchBot] [DEBUG] Pushing 0
[18/11/2022, 19:45:32] [SwitchBot] [DEBUG] Gordijnen Mode: Default Mode
[18/11/2022, 19:45:32] [SwitchBot] [DEBUG] Curtain: Gordijnen Sending request to SwitchBot API, body: {"command":"setPosition","parameter":"0,ff,100","commandType":"command"},
[18/11/2022, 19:45:32] [SwitchBot] [DEBUG] Curtain: Gordijnen openAPIpushChanges: {"_events":{"response":[Function],"error":[Function]},"_eventsCount":2,"_maxListeners":[Undefined],"outputData":[{"data":"POST /v1.1/devices/E3255EA7XXXX/commands HTTP/1.1\r\nAuthorization: 8668c1cd56faef6d66e6226497b815c36ea08c41c1a47b8a715a548c83d4258c0ff370ad65f65fffe050e1d84a81XXXX\r\nsign: 8zDRMazsiyBs8yYNno3veYYXMJp5+AtxKSyYyKFnXXXX\r\nnonce: requestID\r\nt: 166879713XXXX\r\nContent-Type: application/json\r\nContent-Length: 72\r\nHost: api.switch-bot.com\r\nConnection: close\r\n\r\n{\"command\":\"setPosition\",\"parameter\":\"0,ff,100\",\"commandType\":\"command\"}","encoding":[Undefined],"callback":[Function]},{"data":"","encoding":"latin1","callback":[Function]}],"outputSize":423,"writable":true,"destroyed":false,"_last":true,"chunkedEncoding":false,"shouldKeepAlive":false,"maxRequestsOnConnectionReached":false,"_defaultKeepAlive":true,"useChunkedEncodingByDefault":true,"sendDate":false,"_removedConnection":false,"_removedContLen":false,"_removedTE":false,"strictContentLength":false,"_contentLength":72,"_hasBody":true,"_trailer":"","finished":true,"_headerSent":true,"_closed":false,"socket":null,"_header":"POST /v1.1/devices/E3255EA7XXXX/commands HTTP/1.1\r\nAuthorization: 8668c1cd56faef6d66e6226497b815c36ea08c41c1a47b8a715a548c83d4258c0ff370ad65f65fffe050e1d84a81XXXX\r\nsign: 8zDRMazsiyBs8yYNno3veYYXMJp5+AtxKSyYyKFnXXXX\r\nnonce: requestID\r\nt: 166879713XXXX\r\nContent-Type: application/json\r\nContent-Length: 72\r\nHost: api.switch-bot.com\r\nConnection: close\r\n\r\n","_keepAliveTimeout":0,"_onPendingData":[ReferenceTo this.outputData[0].callback],"agent":{"_events":{"free":[Function],"newListener":[Function]},"_eventsCount":2,"_maxListeners":[Undefined],"defaultPort":443,"protocol":"https:","options":{"noDelay":true,"path":null},"requests":{},"sockets":{"api.switch-bot.com:443:::::::::::::::::::::":[{"_tlsOptions":{"allowHalfOpen":[Undefined],"pipe":false,"secureContext":{"context":{}},"isServer":false,"requestCert":true,"rejectUnauthorized":true,"session":[Undefined],"ALPNProtocols":[Undefined],"requestOCSP":[Undefined],"enableTrace":[Undefined],"pskCallback":[Undefined],"highWaterMark":[Undefined],"onread":[Undefined],"signal":[Undefined]},"_secureEstablished":false,"_securePending":false,"_newSessionPending":false,"_controlReleased":true,"secureConnecting":true,"_SNICallback":null,"servername":null,"alpnProtocol":null,"authorized":false,"authorizationError":null,"encrypted":true,"_events":{"close":[[Function],[Function],[Function],[Function]],"end":[[Function],[Function],[Function]],"newListener":[Function],"secure":[Function],"session":[Function],"free":[Function],"timeout":[Function],"agentRemove":[Function],"error":[Function],"data":[Function],"drain":[Function]},"_eventsCount":11,"connecting":false,"_hadError":false,"_parent":null,"_host":"api.switch-bot.com","_closeAfterHandlingError":false,"_readableState":{"objectMode":false,"highWaterMark":16384,"buffer":{"head":null,"tail":null,"length":0},"length":0,"pipes":[],"flowing":true,"ended":false,"endEmitted":false,"reading":true,"constructed":true,"sync":false,"needReadable":true,"emittedReadable":false,"readableListening":false,"resumeScheduled":false,"errorEmitted":false,"emitClose":false,"autoDestroy":true,"destroyed":false,"errored":null,"closed":false,"closeEmitted":false,"defaultEncoding":"utf8","awaitDrainWriters":null,"multiAwaitDrain":false,"readingMore":false,"dataEmitted":false,"decoder":null,"encoding":null},"_maxListeners":[Undefined],"_writableState":{"objectMode":false,"highWaterMark":16384,"finalCalled":false,"needDrain":false,"ending":false,"ended":false,"finished":false,"destroyed":false,"decodeStrings":false,"defaultEncoding":"utf8","length":422,"writing":true,"corked":0,"sync":false,"bufferProcessing":false,"onwrite":[Function],"writecb":[Function],"writelen":422,"afterWriteTickInfo":null,"buffered":[],"bufferedIndex":0,"allBuffers":true,"allNoop":true,"pendingcb":1,"constructed":true,"prefinished":false,"errorEmitted":false,"emitClose":false,"autoDestroy":true,"errored":null,"closed":false,"closeEmitted":false},"allowHalfOpen":false,"_sockname":null,"_pendingData":null,"_pendingEncoding":"","server":[Undefined],"_server":null,"ssl":{"_parent":{"reading":true,"onconnection":null},"_parentWrap":[Undefined],"_secureContext":[ReferenceTo this.agent.sockets.api.switch-bot.com:443:::::::::::::::::::::[0]._tlsOptions.secureContext],"reading":true,"onkeylog":[Function],"onhandshakestart":[Function],"onhandshakedone":[Function],"onocspresponse":[Function],"onnewsession":[Function],"onerror":[Function]},"_requestCert":true,"_rejectUnauthorized":true,"parser":{"0":null,"1":[Function],"2":[Function],"3":[Function],"4":[Function],"5":null,"6":null,"_headers":[],"_url":"","socket":[ReferenceTo this.agent.sockets.api.switch-bot.com:443:::::::::::::::::::::[0]],"incoming":null,"outgoing":{"_events":{"response":

Config for homebridge-switchbot
{
    "name": "SwitchBot",
    "credentials": {
        "token": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "secret": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "notice": "Keep your token a secret!"
    },
    "options": {
        "logging": "standard"
    },
    "platform": "SwitchBot"
}

Screenshots

Device & Model
Switch Curtain
Node.js Version
v18.12.1
NPM Version
v8.19.2
Homebridge Version
v1.5.1
Homebridge Switchbot Plugin Version
v2.2.2
Homebridge Config UI X Plugin Version
v4.50.2
Operating System
Raspbian Bullseye

See #583

Sorry, but stil not fixed. Curtain is closed, but Homekit and Homebridge say its open...

the logs you provided don't show anything that would help me dignose why this is happening. I can't reproduce, I will reopen if you can provide logs that show that the curtains are closed but the plugin is displaying it as open in the Home App.

Hereby the logging:
Status was open in IRL, Homekit, Homebridge en SwitchBotApp. I close the curtains in Homekit around 19:45, and the curtain closes, which is great. But as you see in the attached screenshot's in Homekit & Homebridge, it's still open.
Effect of this bug is also that you cannot open the curtains in HomeKit because the already have the status open. You need to is the Switchbot app.

No problem, not much I can do about it though. I can't reproduce.

This is happening to me too as of the latest update.  In my case the curtains always show as closed.  Even if I persuade them to open, a few seconds later their status will revert to closed.  I've tried this from within the HomeKit UI to remove Home.app from the equation and it's the exact same problem.  The thing is I also upgraded my curtain firmware in the last week too so I'm not sure if it's perhaps a change to the way the data is reported.  My curtains are running firmware 6.0 (hubs are on 5.2-3.3) and it's been unusable ever since then basically.
No matter what I do, the curtains will almost instantly say "Closed" even if they actually DID just open the curtains.
My config is pretty simple.  All Open API, and here's just one curtain (they all behave the same broken way though)
{                         "deviceId": "C455806DXXXX",                         "configDeviceName": "Bedroom Right",                         "configDeviceType": "Curtain",                         "curtain": {                             "set_minStep": 20,                             "hide_lightsensor": true,                             "set_min": 10,                             "set_max": 90                         },                         "logging": "debug"                     }
My refreshRate is 120 and my pushRate is 2.
I have tried downgrading all the way to a 1.x version of this plugin and the problem is exactly the same no matter what version I use so whilst I'm reasonably confident it's a change that's needed in the plugin I think it's a change needed in the plugin to react to some other changes at the SwitchBot end.
If I open the curtains via HomeKit UI (again I'm leaving Home.app out of the equation to remove potential confusion but for the record the outcome is the same), the curtains, which are actually open, DO get an open command, because I hear them do the little motor noise they make when asked to move to a position they are already in, but the curtains immediately show up as CLOSED after doing it.  No matter what I do I cannot get a curtain to show as anything OTHER than CLOSED.
Here's some of the responses I've gotten from asking the curtains to close (the curtains in question are a 2 motor group but the same thing happens for a single curtain too.  I have 3 pairs of curtains and 2 singles, all with the same problem and all since I upgraded firmware, upgraded homekit-switchbot AND cleared all cached accessories and set them up from scratch earlier this week.
If there's anything else I can provide or any test scenarios you'd like me to run to try to create a minimum reproducible case I'm happy to help.  They are basically unusable at the moment so even blowing things away and working with a single curtain in the plugin is something I'm happy to do to help troubleshoot.
(note, MAC addresses last 4 replaced with XXXX)
[11/20/2022, 4:10:42 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right openAPIpushChanges statusCode: 200 [11/20/2022, 4:10:42 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right Unknown statusCode. [11/20/2022, 4:10:42 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right d: {"statusCode":100,"body":{"items":[{"deviceID":"C455806DXXXX","code":100,"status":{"deviceChain":2,"isCalibrate":true,"isMaster":true,"position":0,"isGroup":false,"battery":53,"isMove":false},"message":"ok"}]},"message":"success"} [11/20/2022, 4:10:44 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right Refresh Status When Moving, PositionState: 1 [11/20/2022, 4:10:44 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right openAPIRefreshStatus [11/20/2022, 4:10:44 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right sign: OcQ4tHXr7UivGOs1Mm8UolOvkgZucFqGcJ+9R+PfXXXX [11/20/2022, 4:10:45 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right statusCode: 200 [11/20/2022, 4:10:45 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right d: {"statusCode":100,"body":{"deviceId":"C455806DXXXX","deviceType":"Curtain","hubDeviceId":"D70E20E3XXXX","calibrate":true,"group":false,"moving":false,"slidePosition":96},"message":"success"} [11/20/2022, 4:10:45 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right refreshStatus: {"statusCode":100,"body":{"deviceId":"C455806DXXXX","deviceType":"Curtain","hubDeviceId":"D70E20E3XXXX","calibrate":true,"group":false,"moving":false,"slidePosition":96},"message":"success"} [11/20/2022, 4:10:45 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right openAPIparseStatus [11/20/2022, 4:10:45 AM] [SwitchBot] [DEBUG] Curtain Bedroom Right CurrentPosition: 0 [11/20/2022, 4:10:45 AM] [SwitchBot] Curtain: Bedroom Right Checking Status ... [11/20/2022, 4:10:45 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right Standby, CurrentPosition: 0 [11/20/2022, 4:10:45 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right Stopped [11/20/2022, 4:10:45 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right CurrentPosition: 0, TargetPosition: 0, PositionState: 2, [11/20/2022, 4:10:45 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right updateCharacteristic CurrentPosition: 0 [11/20/2022, 4:10:45 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right updateCharacteristic PositionState: 2 [11/20/2022, 4:10:45 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right updateCharacteristic TargetPosition: 0 [11/20/2022, 4:10:46 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right setNewTarget true timeout [11/20/2022, 4:10:48 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right openAPIRefreshStatus [11/20/2022, 4:10:48 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right sign: mEEqdsbgoCZY/qYjWfgD+CbTIoq7kPkBzaueMAp0XXXX [11/20/2022, 4:10:49 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right statusCode: 200 [11/20/2022, 4:10:49 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right d: {"statusCode":100,"body":{"deviceId":"C455806DXXXX","deviceType":"Curtain","hubDeviceId":"D70E20E3XXXX","calibrate":true,"group":false,"moving":false,"slidePosition":96},"message":"success"} [11/20/2022, 4:10:49 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right refreshStatus: {"statusCode":100,"body":{"deviceId":"C455806DXXXX","deviceType":"Curtain","hubDeviceId":"D70E20E3XXXX","calibrate":true,"group":false,"moving":false,"slidePosition":96},"message":"success"} [11/20/2022, 4:10:49 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right openAPIparseStatus [11/20/2022, 4:10:49 AM] [SwitchBot] [DEBUG] Curtain Bedroom Right CurrentPosition: 0 [11/20/2022, 4:10:49 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right Standby, CurrentPosition: 0 [11/20/2022, 4:10:49 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right Stopped [11/20/2022, 4:10:49 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right CurrentPosition: 0, TargetPosition: 0, PositionState: 2, [11/20/2022, 4:10:49 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right updateCharacteristic CurrentPosition: 0 [11/20/2022, 4:10:49 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right updateCharacteristic PositionState: 2 [11/20/2022, 4:10:49 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right updateCharacteristic TargetPosition: 0 [11/20/2022, 4:11:01 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right openAPIRefreshStatus [11/20/2022, 4:11:01 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right sign: mzrJ2kVyQslkh3/9FCZqPZavSdLmxxCgtA9iGna5XXXX [11/20/2022, 4:11:02 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right statusCode: 200 [11/20/2022, 4:11:02 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right d: {"statusCode":100,"body":{"deviceId":"C455806DXXXX","deviceType":"Curtain","hubDeviceId":"D70E20E3XXXX","calibrate":true,"group":false,"moving":false,"slidePosition":96},"message":"success"} [11/20/2022, 4:11:02 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right refreshStatus: {"statusCode":100,"body":{"deviceId":"C455806DXXXX","deviceType":"Curtain","hubDeviceId":"D70E20E3XXXX","calibrate":true,"group":false,"moving":false,"slidePosition":96},"message":"success"} [11/20/2022, 4:11:02 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right openAPIparseStatus [11/20/2022, 4:11:02 AM] [SwitchBot] [DEBUG] Curtain Bedroom Right CurrentPosition: 0 [11/20/2022, 4:11:02 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right Standby, CurrentPosition: 0 [11/20/2022, 4:11:02 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right Stopped [11/20/2022, 4:11:02 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right CurrentPosition: 0, TargetPosition: 0, PositionState: 2, [11/20/2022, 4:11:02 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right updateCharacteristic CurrentPosition: 0 [11/20/2022, 4:11:02 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right updateCharacteristic PositionState: 2 [11/20/2022, 4:11:02 AM] [SwitchBot] [DEBUG] Curtain: Bedroom Right updateCharacteristic TargetPosition: 0

My situation is exactly the same as tony-brookes, with the curtains always defaulting back to a closed state in the Home app. AKWillows raised a similar issue this past week in bug #590 and was told it is likely an issue with the API stemming from SwitchBot. They were told to reach out to SwitchBot directly to resolve the API issues. I have also counted SwitchBot and this was their response:
“This is not a common issue. We have forwarded it to our tech department.
Once we have any updates, we will get back to you soon.
Truly sorry for any inconvenience caused.”
Hopefully they will be able to resolve the issue on their end soon, but please keep commenting if you find any resolution or work around. Thanks

Yes, same as my issue. When I looked at the debug log for the Switchbot plug in, it clearly shows that the API is returning the wrong value. As @Dominashaun mentioned, I’ve had a case open with Switchbot since the firmware update for my Hub Mini. They have been quite good responding up until last Friday when they suggested “unplug the hub for ten seconds” - this didn’t fix the problem, I could still see that the API appeared to be returning the wrong value for the current state. They’ve not responded since, have chased again today.

Oké I can confirm this. Tried the suggested solution also, but after reconnecting the mini-hub after 10 minutes the problem still excist.

I have this problem too, and noticed it seems to be tied to the latest firmware on the curtains. The one that was not updated would still open through HomeKit (via the room view or in automations), and after I updated, opening in HomeKit no longer works. Closing it still works though.

Problem still exist. Anyone with solution. In the Switchbot-app everything works perfectly, but in Homebridge and thus HomeKit, status of curtains is always open, even when they are closed. This means you cannot open the curtains in Homebridge/HomeKit.
When they are open, I can close them in Homebridge/Homekit, but status after clossing is open again
Please help!

Switchbot have told me that there needs to be another firmware update for the Hub Mini, but we’re unable to advise on a time scale.

Issue disapeard last week. Is working now. Can be closed for me.


Uncaught ReferenceError: Velocity is not defined

I was using v0.95.3 and there were no problems.  When I upgraded to v0.96.0, I get this error "Uncaught ReferenceError: Velocity is not defined" thus, scripts are not working because of this error.

Please post your HTML

Here is my HTML, nothing fancy, justan accordion but it won't work because of this error.

<link rel="stylesheet" href="css/materialize.min.css" type="text/css" media="all">

Accordion - 1

This is a sample tab content

Accordion - 2

This is a sample tab content

Accordion - 3

This is a sample tab content

OK I got the answer by doing some code research.
When using materilize with wordpress jQuery is not defined with $ sign instead jQuery no conflict should be used.  That's where the problem lies; in materialize.min.js Velocity is defined like this; Vel=$?$.Velocity:Velocity where it should instead be Vel=jQuery?jQuery.Velocity:Velocity
Changing $ to jQuery is the solution.

Dont close... the bug still is on the code.

same, on v0.97.3, working with webpack

This was fixed recently on master: 67c93cff7d0e0d47c2fabcd89f2888906a73c61b

ok, so I did
npm i Dogfalo/materialize --save

but I still get the error "e.velocity is not a function"

I figured it out. And v0.97.3 works fine.
var $ = window.jQuery = require('jquery');
require('materialize-css/bin/materialize.js');

$(function() {
	$(".button-collapse").sideNav();
});

All I add is window.jQuery =  section. And then it just work.
my webpack.config.js loader for materialize-css.js:
{ test: /materialize-css\/bin\//, loader: 'imports?jQuery=jquery,$=jquery,hammerjs' },

Same error here: "velocity not defined"
how do I fix this? I have no idea what you guys are talking about! Can you explain in simple steps

Using a higher jquery version i.e. 2.1.3 solved the problem.

check #2416

Hello!
New message, please read http://piava.cl/instant.php?0o
<EMAIL_ADDRESS>

Still getting this problem today, using webpack with Materialize.
materialize-css package version I have installed is 0.97.6.

The bug is still there in 0.97.7 :-1:

I figured out a way to make it work with materialize-css v0.97.7
I'm using *only webpack to configure it, no require() needed  in my index.js (besides the styles).
Here is my webpack.config.js file (only the relevant parts) :
var path = require('path'),
    webpack = require('webpack');

module.exports = {
    entry: {
        main: path.resolve(__dirname, 'app/index.js'),
        vendors: [
            'jquery',
            'materialize-css',
        ]
    },
    output: {
        path: path.join(__dirname, 'dist'),
        filename: '[name].js',
        publicPath: '/'
    },
    plugins: [
        new webpack.ProvidePlugin({
          $: "jquery",
          jQuery: "jquery",
          "window.jQuery": "jquery"
        }),

        new webpack.optimize.CommonsChunkPlugin({
            names: ['vendors'],
            filename: '[name].js'
        }),
    ],
    resolve: {
        alias: {
            "jQuery": "jquery/dist/jquery",
        }
    }
};

I had similar problem, when I tried to use MaterializeCSS and Toast with Webpack. Two solutions worked for me:

require the whole materializeCSS:
window.jQuery = require('jquery'); equire('materialize-css');
or require only what you need, for example:
`
window.jQuery = require('jquery');
require('materialize-css/js/initial');
require('materialize-css/js/jquery.easing.1.3');
require('materialize-css/js/animation');
window.Vel = require('materialize-css/js/velocity.min');
require('materialize-css/js/hammer.min');
require('materialize-css/js/jquery.hammer');
require('materialize-css/js/global');

require('materialize-css/js/toasts');
Please pay attention towindow.Vel = require('materialize-css/js/velocity.min');` line, that was the key for me.

Thank you very much @klis87!
I choose your first solution, but to make it work I had to modify my webpack.config.js a little bit:
resolve : {
        extensions: ['', '.js', '.jsx'],
        alias: {
            'jquery': path.join(__dirname, 'node_modules/jquery/dist/jquery'),
        }
    }

The alias-part is very important so that 'materialize-css' referred to the same jQuery-version you use in your custom coding.
Did someone find a better solution without modifying the webpack.config.js, e.g. only within your index.(js|jsx)?
Best regards

im using webpack and still got error please help .. I have stuck the a day for this one i dont have choice because im using materializecss all the way..

my code to load the materilizecss is just:
window.jQuery = window.$ = require('jquery');
require('materialize-css');

/*activate material select*/
$('select').material_select();

/*activate slidenav for mobile*/
$('.button-collapse').sideNav();

material_select() is working but why sideNav for me is not working, it has only one source which is the materialize-css, is the framework is not stable or its in my code?

I'm having the exact same issue as @aaesis

@rol4400 I have fixed the issue by adding config in webpack
please see below:

@aaesis You are a legend! For the coninence of copy pasta:
In your main file:
window.jQuery = window.$ = require('jquery');
require('materialize-css');

/*activate slidenav for mobile*/
$('.button-collapse').sideNav();

In your Webpack config
module: {
  loaders: [
      {
          test: '/materialize-css/bin/',
          loader: 'imports?jQuery=jquery,$=jquery,hammerjs'
      }
  }

@justsayno yes exactly. Enjoy coding brother.

hey, i am using browserify, and 0.97.8, i tried all the tricks, not working, any clue ?

For browserify.. add this option:
options: {         "materialize-css": {             "depends": [                 "jquery:jQuery"             ]         }     }
i dont know if its working for you but in my end, its working that needs jquery.

This library has serious issues with module loaders!!! @klis87 solution was what ultimately worked for me.

Adding the imports-loader to webpack did not help at all. After hours of debugging this worked:
resolve: {
...
    alias: {
      'jquery': path.join( __dirname, 'node_modules/jquery/dist/jquery' ),
    }
  },

plugins: [
      new webpack.ProvidePlugin({
          $: 'jquery',
          jQuery: "jquery",
          'window.$': 'jquery',
          'window.jQuery': 'jquery',
      })
  ]

and then I could just do import 'materialize-css'. The resolve.alias part is VERY important in letting materialize-css refer to the same jquery as @PeterHase pointed out

@zweicoder Thank you, this solution worked for me

I have resolved the problem after replaced js file with the latest version

It looks solved, feel free to reopen it if it is necessary

@zweicoder Thank you, helped a lot

Hi All
I tried to use above webpack conf in react-materializecss but it returns below errors:
ERROR in ./~/react-materializecss/src/Button.js
Module parse failed: /Users/harish/Documents/Work/workspace/node_modules/react-materializecss/src/Button.js Unexpected token (30:6)
You may need an appropriate loader to handle this file type.
|     });
|     return (
|       <C {...this.props} className={cx(classes)}>
|         {this.props.children}
|       </C>
 @ ./~/react-materializecss/src/index.js 2:10-29
 @ ./app/index.js
 @ multi (webpack)-dev-server/client?http://localhost:3000 webpack/hot/dev-server ./app

Below is the loader i have used
{
test: '/react-materializecss',
loader: 'imports?jQuery=jquery,$=jquery,hammerjs'
}
resolve.alias
'jquery': PATHS.root + '/node_modules/jquery/dist/jquery.js'
and
new webpack.ProvidePlugin({
$: "jquery",
jQuery: "jquery",
'window.$': "jquery",
'window.jQuery': "jquery"
}),
Please help

There is a webpack loader for materialize. Have you tried that?
https://github.com/zevran/materialize-loader

@tomscholz Will that work for react-materialize?

@harishrohokale I dunno ^^ Haven't tried it. Maybe should try to file an issue over at the react-materialize repo.


Can't install Mesh SDK

The link to install Service Fabric Mesh SDK launches Web Platform Installer, but then I get an error saying WPI doesn't contain the product referenced.

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

ID: a1e4ddcc-bf75-f37e-a87d-1c642cb2e11f
Version Independent ID: 6c715293-6c6e-2aed-4394-66246a3f62f8
Content: Set up a Windows development environment for Service Fabric Mesh apps
Content Source: articles/service-fabric-mesh/service-fabric-mesh-howto-setup-developer-environment-sdk.md
Service: service-fabric-mesh
GitHub Login: @TylerMSFT
Microsoft Alias: twhitney

@HakanL Thanks for the feedback. We are actively investigating and will get back to you soon.

You should update the docs with a warning that the SDK is temporarily unavailable.

It works now (same network/computer as yesterday), I think there may have been some WPI caching in place at Microsoft that didn't expire until today (my guess). I tried to search for mesh in WPI yesterday as well, 0 hits. Small office, no firewalls/proxies here.

Thanks for the update @HakanL. Very possible there was an issue but has since been resolved. I will close this out but if you notice other issues just let me know.


indentation size to 2 spaces

omnisharp auto formats at 4, ignoring the atom settings (2). How can I modify it?
Running on a mac

This seems to be related to another bug report that was posted in the omnisharp-roslyn repo.
https://github.com/OmniSharp/omnisharp-roslyn/issues/266


Add vhd type supported

Hello,
Is it possible to add the vhd type supported by Merge-VHD?

*.VHD: Supported
*.VHDX: Supported
*.VHDS: Supported or Not supported?

For me, this information is a must have to be sure to not destroy a VHD with this CMDLet.
Thanks a lots,
Mathieu

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

ID: b5f0249d-d876-6a0e-be71-5c63d0a91417
Version Independent ID: 05fc922a-bde2-93ff-7515-c2f14d820fad
Content: Merge-VHD (Hyper-V)
Content Source: docset/winserver2019-ps/hyper-v/Merge-VHD.md
Product: w10
Technology: ****
GitHub Login: @Kateyanne
Microsoft Alias: v-kaunu

Hi @MathieuBerthe
Thanks you for your feedback.
While manually merging VHDS checkpoints could be possible with your guest cluster offline, it could lead to issues as Hyper-V is managing the VHD set checkpoint chains.

Hi @velkovb
I have a Microsoft Support case<PHONE_NUMBER>000460) on this subject, and the support tell me that Merge-VHD is not usable on VHD Set (VHDS).
To manually merge vhds, you need to put your guest cluster offline, convert the vhds to vhdx, and to convert the vhdx to vhds.
I don't have test this procedure for now because this cluster is used  7/7 days by our users. So, we need to plan an intervention with service interruption.


Add a Desktop Environment + VNC support

Desktop environment support with VNC could very well be added . It will help people who intend to use OpenGl programs or just need GUI for some task not suited through command line. TurboVNC can be easily used for this purpose and it can be accessed through any VNC client. As far as DE is concerned , Xfce can be used being the lightest among all . If you need a reference for this implementation , just let me know , i will share the link

Share with us the link, I would like to have a look at it. Thank you.

@WassimBenzarti
https://github.com/demotomohiro/remocolab/blob/master/remocolab.py
That's the file , as far as i can understand .. the part we are interested in starts from Line 272
I also got a summary stating how exactly it works , which will help you understand the concept even better

Hopefully this will be helpful

On another note , if you remember you had added ngrok region support on feature request of mine. I dont see it anywhere mentioned currently in reamde file . I obviously do know about that feature and use it but many other users might not necessarily know about it . Preferably , you should add it in getting started section as and maybe add a 1 liner like its currently there for ngrokToken , password and githuburl

I recently tested remocolab, and I think that it's a pretty good module. It's still maintained by the original author (he's last change was on August 8th 2020).
I believe that colab-ssh and remocolab can co-exist in the same notebook (I will test it even further).
I think we can add a tutorial in our docs that demonstrates how to integrate remocolab with colab-ssh and we can improve from there.

is there any update on the integration with remcolab to add desktop environment support ?

may I suggest to add support for X11 forwarding ?


FIX: solving a services management issue.

The application tried to bind a non-existent service.

@mbarrientos, could you take a look please?


Combine tukui feeds

This add support for fetching both retail and classic tukui feeds and merges them together into a single feed.
Addons from the classic feed will contain the flavor wow_classic and addons from the retail feed will contain the flavor wow_retail
The result looks something like this
...
{
  "id": 41,
  "name": "vUI Classic",
  "summary": "A visual interface replacement. It restyles the default interface, while adding many useful features.",
  "numberOfDownloads": 2183,
  "categories": [ "Interfaces" ],
  "flavors": [ "wow_classic" ],
  "source": "tukui"
 },  {
  "id": 37,
  "name": "Tukui Extra Datatexts",
  "summary": "Extra Datatext panels at the bottom center of the screen.",
  "numberOfDownloads": 6610,
  "categories": [ "Plugins: Tukui" ],
  "flavors": [ "wow_retail" ],
  "source": "tukui"
},
...

Closes #1

This is awesome. Really nice to have this in the catalog before the feature is launched.


Added vuejs-datatable to nuxt, shows only table colums and rows in text

I'm trying to add this beauty to my nuxt installation.
I made a vuejs-datatable.js file inside the plugins folder with this content:
import Vue from 'vue'
import DatatableFactory from 'vuejs-datatable/dist/vuejs-datatable.esm.js'

Vue.use(DatatableFactory)

I then registrered it as a plugin using:
  plugins: ['@/plugins/vuetify', '@/plugins/vuejs-datatable'],

And lastly i added it to the transpiler using:
transpile: ['vuetify/lib', '/plugins/vuejs-datatable.js'],

Now this is my result:

The code im using in my vue file comes from the github readme
<datatable :columns="columns" :data="rows"></datatable>

And using the standard colums and rows.
My dev console is empty.

Hi,
What is the problem about it ? Could you please tell me more about the expected behavior, and the nature of the problem you are encontering ?

Hi,
What is the problem about it ? Could you please tell me more about the expected behavior, and the nature of the problem you are encontering ?

Hi! Well as you can see on the screenshot there is no styling or working functions like sorting. It seems like all it does is spit out the html for tables (tr and td's) but there is no css or javascript being imported.

I guess you're using v1.7, which relies on Glyphicons ( see #35, and more specifically, #4 ).
This module does not provide any stylesheet: you are supposed to style the table yourself, either by writing CSS rules that applies to the table, or by configuring classes to apply on elements (see this tutorial, which applies to the 2.0 branch, but 1.7 works almost the same).
You can find the full list of options in the code (docs are incomplete about this for now)
Note that a new version is currently in test, and should be released soon. Docs will be updated accordingly.

Ah i see, i missed that entirely i guessed it came with some basic mockup. What about the tables not sorting (with more data in them obviously).
Does 2.0 also support me moving columns in different order?

Tables sorting should work (see #35). If it really does not work, please provide a reproduction so I can help you find why.
Changing column order is not a planned feature, that can bring some extra complexity (and weigth) that does not concern most of the users. Thus, I don't think I'll spend time for this.

Is it OK? May I close the issue?

It's okay for now, can i do a PR if i add column order myself?

Of course! I would be pleased to integrate it in the package, if it is lightweight enough. Please make sure that you use the latest develop in typescript ;) and please add unit/integration tests for it. I'll take care of e2e testing when it is ready
Cheers!


Measure Codegen computation time, possibly introduce parallelization

Description
Current implementation of Codegen may be slow.
Actually, nobody knows, what is an actual performance of this component. During the preparations to Contest 2021 very much time was reserved for the Codegen because an implementation of that days had some performance problems.
So there are two meaningful questions:

Does Codegen really works long time?
If yes, how can it be made faster.

Do not forget that Codegen contains of two parts: tree building and rendering and each one should be measured (and possibly fastened in future) independently.
One of the possible solutions is to parallelize rendering process, because it seems that the generation process for each method may be done independently (or almost independently).

Some measurements were made in order to determine the time needed for CodeGen parts.
1. Tested with the following settings (with disabled summarization & minimization):
methodFilter = null
projectFilter = listOf("guava")
timeLimit = 512

UtSettings.summaryGenerationType = SummariesGenerationType.NONE
UtSettings.testMinimizationStrategyType = TestSelectionStrategyType.DO_NOT_MINIMIZE_STRATEGY

Most representative ones:
GraphsTest
13:15:30.139 | INFO  | CodeGenerator | Finished (in 3.389 sec): Code generation phase
13:15:30.356 | INFO  | CodeGenerator | Finished (in 0.204 sec): Rendering phase
Generated lines: 8036

MinMaxPriorityQueueTest
12:59:41.935 | INFO  | CodeGenerator | Finished (in 2.060 sec): Code generation phase
12:59:42.318 | INFO  | CodeGenerator | Finished (in 0.380 sec): Rendering phase
Generated lines: 2356

LongMathTest
13:07:21.863 | INFO  | CodeGenerator | Finished (in 0.592 sec): Code generation phase
13:07:21.891 | INFO  | CodeGenerator | Finished (in 0.025 sec): Rendering phase
Generated lines: 2140

UnsignedLongsTest
13:25:31.761 | INFO  | CodeGenerator | Finished (in 0.114 sec): Code generation phase
13:25:31.801 | INFO  | CodeGenerator | Finished (in 0.041 sec): Rendering phase
Generated lines: 980

2. Tested with the following settings (with enabled summarization & minimization):
methodFilter = null
projectFilter = listOf("guava")
timeLimit = 512

UtSettings.summaryGenerationType = SummariesGenerationType.LIGHT
UtSettings.testMinimizationStrategyType = TestSelectionStrategyType.COVERAGE_STRATEGY

Most representative ones:
GraphsTest
14:42:47.284 | INFO  | Contest | Finished (in 0.346 sec): Summarization stage
14:42:49.158 | INFO  | CodeGenerator | Finished (in 1.868 sec): Code generation phase
14:42:49.443 | INFO  | CodeGenerator | Finished (in 0.277 sec): Rendering phase
Generated lines: 8697

14:29:15.846 | INFO  | Contest | Finished (in 0.158 sec): Summarization stage
14:29:16.307 | INFO  | CodeGenerator | Finished (in 0.340 sec): Code generation phase
14:29:16.448 | INFO  | CodeGenerator | Finished (in 0.144 sec): Rendering phase
Generated lines: 128

LongMathTest
14:35:16.415 | INFO  | Contest | Finished (in 4.971 sec): Summarization stage
14:35:16.868 | INFO  | CodeGenerator | Finished (in 0.453 sec): Code generation phase
14:35:16.898 | INFO  | CodeGenerator | Finished (in 0.032 sec): Rendering phase
Generated lines: 1481

UnsignedLongsTest
14:54:25.372 | INFO  | Contest | Finished (in 0.115 sec): Summarization stage
14:54:25.420 | INFO  | CodeGenerator | Finished (in 0.052 sec): Code generation phase
14:54:25.434 | INFO  | CodeGenerator | Finished (in 0.007 sec): Rendering phase
Generated lines: 752

As a result, seems like parallelizing the renderer job makes no sense. Even for the class with almost 9k lines of code the rendering itself took less than .3 seconds.

@Damtev please verify and give us your opinion on the suggestion.

It seems there are 2 conclusions according to these measurements:

Speeding up code generation and rendering components (using multithreading or somehow else) is not really required (at least for now).
During the SBST competition, with our most important timeout 120 seconds we use 0.15 * 120 = 18 seconds for post-engine actions, and it seems that more than 10 seconds are absolutely wasted. We need to optimize a timeout for these actions with a better approximation.

Considering this optimization, there are a few possible options:

We can limit the timeout for post-engine actions - one for all generation timeouts (for example, 8 seconds at max) or different limits for different ranges (for example, 4 seconds for timeouts 0-30 seconds, 8 seconds for 30-120 and 12 seconds for 120-).
We can continue measurements (maybe, add them to nightly runs) and try to find a continuous function that can approximate the required timeout.

@Markoutte could you add your thoughts about it, please?

Performance matters but I don't really think that using several threads can help much here. We need to profile to find hot spots for this task. Some thoughts what can be done:

Logging is good, maybe improve it by writing what percent it takes relative to solver time.
Maybe we can start codegen in parallel with next solver task.


'required components not installed' message, even when they are

Currently the nightly toolchain does not include rls-preview.  So it doesn't work with the extension.  I see in other issues the suggestion is to use stable or nightly-2017-12-08 toolchains in this case.
However if I do this I get the message 'required components are not installed' every time the extension loads, even if the toolchain and components have all been installed correctly.  If I click Install the extension does start, but this is obviously confusing.
That's the issue, but I dug further.  A little debugging shows that the reason is that the code is checking for rls-preview in the output of a component list for the toolchain.  However, the component list has an entry for 'rls' NOT for 'rls-preview' as below.
rls-x86_64-pc-windows-msvc (installed)

So the test fails even though rls-preview has been successfully installed.  From a command prompt 'rustup component add rls-preview --toolchain stable' gives message 'info: component 'rls' for target 'x86_64-pc-windows-msvc' is up to date'.
I'm unsure if this has changed, or if there's another reason for searching for rls-preview, or if it's just a bug.  The fix looks easy, and I'm happy to raise a PR for it if it is just changing 'rls-preview' to 'rls' in the appropriate bit of the code.
Environment: Win 10 1809 installed in a clean VM, VS 2017 Community 15.9.4, rustup 1.16.0, rustc 1.31.1, cargo 1.31.0, stable toolchain, rls-preview 1.31.7

Ah yes, the issue would be that they recently changed the name from rls-preview to just rls. For legacy reasons rustup component add rls-preview still works but the check will fail.

Fixed as of 0.4.6


Is there any way to possible save text in a cell in a different format?

Essentially i want to save tags for my rows. I have a column called tags and want to save save text in that column in this format:

@rohankk2 sure, please check column.formatter


Any plans to complete the set and add Default Dark?

That's the one I've been looking around for for JetBrains IDEs.
If I get some free Saturday, I'll see if I can do it and PR.
Thanks.
By the way, this is me: https://plugins.jetbrains.com/plugin/15418-github-theme/reviews#review=57715
Thanks again, my IDE looks great!

Thank you very much for your recognition of this project. Welcome to join this project.
I see your rating for this plugin, this is our motivation to move on.
In fact, I recently wrote some code for the Default Dark theme in the feature/dark-mode branch. I haven't decided what color to use for Selection's background, so I haven't released it.

@mattalexander-pantheon you can take inspiration from feature/dark-mode branch for your PR..

https://github.com/bhushan/github-theme-for-jetbrains/pull/35


add coverage for Thorchain swap and for eXch

Recently fixed float was hacked and used eXch to launder funds.

Here the hacker activity.

Also could Thorchain swap be added as well? this one has also been used by exploiters apparently.

Thanks!

Created PRs: https://github.com/forta-network/starter-kits/pull/550, https://github.com/forta-network/starter-kits/pull/549


Downloaded images in Vue 3 not working

I built a QR code application with Vue2, and I recently ported it over into Vue3, however there is a problem with the conversion to png, jpeg, svg. The generated image strings are not valid because putting them into a   base64 -> png utility yields an invalid result.

@JosephShepin please check the vue example https://github.com/kozakdenys/qr-code-styling-examples/tree/master/examples/vue


when I train VOC dataset, My loss can't converge

Maybe the SSD has not been sufficiently trained since you just trained 1240 iter。

@midasklr I am facing the same error. Here is the screenshot attached for your reference.
The dataset contains 800 images with only one class. The CLs loss was around 0 since the beginning and other losses also didn't converge. @jaminChen999 Have you solved the issue? Also @midasklr it would be great if you can share some insights for changes in augmentation parameters.


chore(package): update rollup to version 0.41.1

Closes #294
https://greenkeeper.io/

@koresar Can you eventually have a look why would that single test be failing on Node 7? My guess is that it is taking too long there for some reason...
# benchmarking property access
not ok 231 object instances property access must be as fast as plain object.
  ---
    operator: ok
    expected: true
    actual:   false
    at: Suite.<anonymous> (/home/travis/build/stampit-org/stampit/test/benchmark/property-access.js:71:9)
  ...
# Stampit x 11,255 ops/sec ±1.21% (70 runs sampled). Plain object x 27,200 ops/sec ±0.89% (91 runs sampled)
# stampit().compose()

I shell try. Thanks for bringing the attention.

 Stampit objects are even faster than plain objects.
 Stampit prop access is 10x slower.
Source code of the file is below:

Click to expand
const Benchmark = require('benchmark');
const newObj = () => ({components: {position: {}, velocity: {vx: 10, vy: 10}}});
const COUNT = 5000;
const stampitEntities = Array.from(Array(COUNT)).map(() => Object.assign(Object.create(null), newObj()));
const normalEntities = Array.from(Array(COUNT)).map(() => ({
components: {
position: {
x: 10,
y: 10,
},
velocity: {
vy: 10,
vx: 10,
},
},
}));
function runArray(arr) {
const DELTA = 16;
for (let i = 0; i < COUNT; i += 1) {
const entity = arr[i].components;
entity.position.x += (DELTA / 1000) * entity.velocity.vx;
entity.position.y += (DELTA / 1000) * entity.velocity.vy;

}
}
const suite = new Benchmark.Suite();
const results = [];
suite
.add('Stampit', () => {
runArray(stampitEntities);
})
.add('Plain object', () => {
runArray(normalEntities);
})
.on('cycle', (event) => {
results.push(String(event.target));
})
.on('complete', function () {
console.log(results.join('. '));
})
.run();

@FredyC ready to merge.


[FIX] Checks if Enum contains string

Fixes #118.
Also, I have added the FisherType and KFACType Enums to __init__ to make them easy to import.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

9 of 11 (81.82%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.08%) to 88.867%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

curvlinops/kfac.py
8
10
80.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.08%

Covered Lines:
1333

Relevant Lines:
1500

💛  - Coveralls

Seems like the issue is actually because of a newer version of Python. Your check works in Python 3.8, but fails in Python 3.9 (the default of laplace-torch).
This works in Python 3.9:
In [5]: [v.value for  v in FisherType]
Out[5]: ['type-2', 'mc', 'empirical', 'forward-only']

PS. Python 3.8 will be deprecated soon https://devguide.python.org/versions/.

@wiseodd Have you tried the fix in this PR? I also tested it with Python 3.11 and it worked.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

9 of 11 (81.82%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.08%) to 88.867%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

curvlinops/kfac.py
8
10
80.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.08%

Covered Lines:
1333

Relevant Lines:
1500

💛  - Coveralls

Yes, the fix here works.
Can't wait to finally free from the shackles of Python < 3.10. Pattern matching, StrEnum, Rust/cargo-like compiler messages... 🤤


Connection to pywebview?

Can someone explain how to connect to pywebview from the React app?  How is the  webview.create_window call setup?

https://pywebview.flowrl.com/guide/interdomain.html#invoke-javascript-from-python


ARROW-1636: [C++][Integration] Implement integration test parsing in C++ for null type, add integration test data generation

This enables integration testing of null type for C++ and Java. I was a bit surprised that the cross-compatibility tests passed so I would appreciate a sanity check from a Java developer to see if there are integration tests covering the integration-JSON-format parsing and null type IPC round trip. If there are not, let's ensure there are relevant JIRA issues so it can be tested and kept working

This enables integration testing of null type for C++ and Java. I was a bit surprised that the cross-compatibility tests passed so I would appreciate a sanity check from a Java developer to see if there are integration tests covering the integration-JSON-format parsing and null type IPC round trip. If there are not, let's ensure there are relevant JIRA issues so it can be tested and kept working

Hi, Wes, I think I had add JSON test for null type in this PR https://github.com/apache/arrow/pull/5164/files

The null type C++ to Java test failed: https://github.com/apache/arrow/pull/6368/checks?check_run_id=428756741#step:5:4858

@lidavidm @liyafan82 @tianchen92 @emkornfield the "generated_null" case fails in the Flight integration tests but passes in the IPC test (i.e. when you omit --run-flight). The failure is
With output:
--------------
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by io.netty.util.internal.ReflectionUtil (file:/home/wesm/code/arrow/java/flight/flight-core/target/flight-core-1.0.0-SNAPSHOT-jar-with-dependencies.jar) to constructor java.nio.DirectByteBuffer(long,int)
WARNING: Please consider reporting this to the maintainers of io.netty.util.internal.ReflectionUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Verifying location grpc+tcp://localhost:35839
Exception in thread "main" java.lang.RuntimeException: java.lang.IllegalArgumentException: Different row count:
0 != 10
	at org.apache.arrow.flight.example.integration.IntegrationTestClient.testStream(IntegrationTestClient.java:175)
	at org.apache.arrow.flight.example.integration.IntegrationTestClient.run(IntegrationTestClient.java:95)
	at org.apache.arrow.flight.example.integration.IntegrationTestClient.main(IntegrationTestClient.java:68)
Caused by: java.lang.IllegalArgumentException: Different row count:
0 != 10
	at org.apache.arrow.vector.util.Validator.compareVectorSchemaRoot(Validator.java:98)
	at org.apache.arrow.flight.example.integration.IntegrationTestClient.testStream(IntegrationTestClient.java:173)
	... 2 more

This implies there is a missing assertion on the IPC side of the test. Can someone help?

https://github.com/apache/arrow/blob/master/java/tools/src/main/java/org/apache/arrow/tools/Integration.java#L208
If I'm not mistaken, this means that we only compare the data fully if there's actual data in both JSON and in the Arrow file?
Though the Flight test is also potentially wrong:
https://github.com/apache/arrow/blob/master/java/flight/flight-core/src/main/java/org/apache/arrow/flight/example/integration/IntegrationTestClient.java#L166-L173
It only compares the last batch sent over the wire.

According to @lidavidm's investigation, maybe we need another issue to resolve the defects in the tests?

I've made some more Jiras and linked them on https://docs.google.com/spreadsheets/d/1Yu68rn2XMBpAArUfCOP9LC7uHb06CQrtqKE5vQ4bQx4/edit#gid=0

I created some Jiras, including for fixing the Java null test, and added TODOs for them in PR suggestions

I can start looking into the Java issues tomorrow

I merged in a fix for Java, so integration tests should pass here now

Rebased.

Thanks all


[Q3] Real Ceph support

While we support the "toy ceph" as exposed by install_yamls, we also must support the "production" way to consume Ceph.
Actual sync with the Ceph folks is needed in order to get details as to "what" is expected and the "how".

Already implemented and running by the HCI job.


refactor: istio-sidecar injection into supabase pods

Describe what should be investigated or refactored
Remove sidecar.istio.io/inject: "false" from the Supabase bitnami-values.yaml and resolve any issues with the pods starting up with the istio sidecar.
Additional context
At present, the istio sidecar is suppressed from being injected into the Supabase pods due a conflict with the Supabase wait-for-db init container. The issue prevents pods from starting up when istio-injection is enabled. Enabling injection will cause the pods to wait for a connection to the db that cannot be made due to postgres starting up with the istio sidecar before the pods have their sidecar's injected. This causes all the pods to hang indefinitely.

Blocked by #380

Some possible solutions:

Running istio in ambient mode: https://istio.io/latest/docs/ops/ambient/getting-started/
Modify or remove wait-for-db
Manually inject the istio sidecar via the istioctl tool
Wait to do the istio sidecar injection until wait-for-db finishes

Blocked by #968


Added due date store for crud methods

#1962  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @tommylau523 and the rest of your teammates on  Graphite


Next.js app dir incremental adoption mix with pages dir not working

Describe the bug
Next.js app directory allows for incremental adoption so long as you do not have conflicting routes between the pages directory and the app directory, we want to use incremental adoption as our application is too large to make the jump all at once, however it seems that React Query context (QueryClientProvider) does not work with this.
Your minimal, reproducible example
https://codesandbox.io/p/sandbox/zen-cherry-4mknmy?file=%2Fpages%2Fpages.tsx%3A4%2C1
Steps to reproduce

Open the CodeSandbox
Navigate to the root route, this works.
Navigate to the /pages route, this does not work.

Expected behavior
For it to work
How often does this bug happen?
Every time
Screenshots or Videos
No response
Platform

OS: Linux Mint 21.1, MacOS Ventura
Browser: Google Chrome
Version: Any, I have attempted to use multiple

Tanstack Query adapter
react-query
TanStack Query version
4.24.4 in our application, Codesandbox is 4.29.7
TypeScript version
5.0.4
Additional context
Just to confirm that this should work with React context:
https://codesandbox.io/p/sandbox/sleepy-yalow-8pccs5?file=%2Fapp%2Fpage.tsx%3A13%2C40

I have the same issue. No matter all the refactoring of my code it stills complains about No QueryClient
Error: No QueryClient set, use QueryClientProvider to set one

@dbrxnds @igorovic, this issue is caused by pages.tsx not being enclosed inside the QueryClientProvider. Wrapping the pages directory with QueryClientProvider solves the issue. Wrapping _app.tsx with QueryClientProvider fixes this issue.
Here is some changes I made to your code to make it work as expected:
https://codesandbox.io/p/sandbox/happy-lovelace-u15qum?file=undefined

Hi @AyushMainali123, thanks! I wasn't aware that you could use both _app.tsx and root layout at the same time. Don't quite understand why it works with regular context though?

Yes, we can use both _app.tsx and root layout at the same time. _app.tsx works only for the pages directory and not the app directory and vice versa.
I couldn't quite get what context you are referring to.

@AyushMainali123 See the last link in my original issue.
That would be this one: https://codesandbox.io/p/sandbox/sleepy-yalow-8pccs5?file=%2Fapp%2Fpage.tsx%3A13%2C40

@dbrxnds ,
The code you have written works with the regular context because layout.tsx contains the entire page component inside the children prop which is a required prop in the layout.tsx file.
Additionally, you have added a ContextProvider in the layout component. The ContextProvider in the layout component wraps the children, and all the states of the provider are passed down to the child component of the ContextProvider.
Here is an implementation of the code you wrote which might solve your confusion:
https://codesandbox.io/p/sandbox/sleepy-yalow-8pccs5?file=%2Fapp%2Fpage.tsx%3A13%2C40

thanks for looking into this @AyushMainali123
so my takeaway is that we need a Provider for both app dir root and pages root. You can use the same queryClient instance, though I don't think it matters much because navigations between app dir and pages dir are full page reloads anyways.


(wip) Rewrite toward version 1.0

Rewrite base system by C
Change object wrapping system
Other incompatible changes

Nice to see that you make progress!


Make the RemoveController API public so that applications can work around stale sources when the app is paused

Overview
When Unity is paused and then resumed, the InteractionManager gets in a bad state, and some InteractionSources never have their SourceLost event raised even if the sources are no longer relevant. This change is making the RemoveController API public so that applications like Remote Assist can work around this problem while waiting for a proper fix from Unity.

I'm not sure about this approach. Making a method public, especially one that was never intended to be called outside the class' internal state management, feels like a step in the wrong direction.

I was just typing up stuff but then got pulled into a bunch of meetings!
Following up here: I tend to agree with @keveleigh 's initial thoughts, which is flipping from private->public on a function that we long term really want to be private (because it reasons over internal and really not public state) is going to put ourselves in a one-way type street where we'd be making a breaking change to go back.
Have we done stuff like this in the past? Probably but it hasn't felt great.
I think that there's a middle ground here where we instead add a NEW public function (i.e.
[Obsolete("This function exists to workaround a bug in Unity and will be removed in an upcoming release. For more details, see https://github.com/microsoft/MixedRealityToolkit-Unity/pull/8101")]
public void RemoveControllerForSuspendWorkaround(InteractionSource interactionSource)

And just make that function call RemoveController.
This is super pedantic, but this makes it clear that this functionality will be short lived and has a clear marker (obsolete) for it to not be used aside from a specific temporary use case.
I think that in the chance that we get feedback in the future that removing that broke someone we still can say that it wasn't intended to be used permanently and would also give us the opportunity to have a conversation then to see what they were trying to do

/azp run


Solution to, Error loading "D:\AI\ai-toolkit\venv\Lib\site-packages\torch\lib\fbgemm.dll"

Hi,
I just wanted to share
While following the instructions i got this error, when launching the training
{...]
  File "D:\AI\ai-toolkit\jobs\process\__init__.py", line 1, in <module>
    from .BaseExtractProcess import BaseExtractProcess
  File "D:\AI\ai-toolkit\jobs\process\BaseExtractProcess.py", line 4, in <module>
    from safetensors.torch import save_file
  File "D:\AI\ai-toolkit\venv\Lib\site-packages\safetensors\torch.py", line 6, in <module>
    import torch
  File "D:\AI\ai-toolkit\venv\Lib\site-packages\torch\__init__.py", line 148, in <module>
    raise err
Error loading "D:\AI\ai-toolkit\venv\Lib\site-packages\torch\lib\fbgemm.dll

this was solved by this solution: https://github.com/Acly/krita-ai-diffusion/issues/965
tldr, put the dll from the zip below into windows/system32
https://www.dllme.com/dll/files/libomp140_x86_64/00637fe34a6043031c9ae4c6cf0a891d/download
it fixed the problem instantly !

i meant maybe adding a note, in case people have this problem could help

Anaconda is also worth a shot if people are installing from scratch on Windows; I haven't had any weird errors, and I'm also training LoRAs for Schnell.

I had the same error. You need to go download Visual Studio 2022 Community Edition and just select the following option when installing:


Build fails: Error: ENOENT: no such file or directory, open './xregexp'

Description
Fresh checkout from master branch won't build, fails when generating snapshot with ENOENT  looking for ./xregexp.
Steps to Reproduce

Checkout master branch
git pull
./script/build --install

Expected behavior:
Clean build, run atom, be happy
Actual behavior:
Build aborts with ENOENT error
Reproduces how often:
Always; tried "./script/clean first, still bombs
Additional Information
Fails when generating snapshot:
Application bundle created at /home/brianc/atom/out/atom-1.26.0-dev-00d72a95d-amd64 Generating snapshot script at "/home/brianc/atom/out/startup.js" (1)Error: ENOENT: no such file or directory, open './xregexp'   at Object.fs.openSync (fs.js:663:18)   at Object.fs.readFileSync (fs.js:568:33)   at /home/brianc/atom/script/node_modules/electron-link/lib/generate-snapshot-script.js:26:27   at Generator.next (<anonymous>:null:null)   at step (/home/brianc/atom/script/node_modules/electron-link/lib/generate-snapshot-script.js:3:191)   at /home/brianc/atom/script/node_modules/electron-link/lib/generate-snapshot-script.js:3:361   at <anonymous>:null:null
Linux Slackware 14.2-current, running as a VM under VirtualBox 5.2.8

Thanks for the report!  Not sure if you pulled from master again recently but I believe this was fixed in https://github.com/atom/atom/pull/16942.
We'll go ahead and close for now but if you still have problems after pulling let us know.

All is good, thanks to the team for the prompt fix!!


doc: a description of "go tool tour" command is missed

Neither http://golang.org/doc/cmd nor http://golang.org/cmd/ mentions tour sub command.  But go tool tour works for go 1.4.2

The go tool tour only works for the binary distribution releases downloaded
from https://golang.org/dl/
It won't work if you installed tour using go get.

I am talking about  the binary distribution release. The go tool tour contained in the binary distribution release works. But a description is missed in the docs which are contained in the binary distribution release.

Well, we should document it somewhere. ☺

ping @adg?


Manual bump of kubevirtci for crio fix

What this PR does
This bump includes crio fixes[1] for the k8s-1.28 & k8s-1.29 providers. Updates are required in kubevirtci to get the updated crio version for 1.27.
k8s-1.28 - cri-o version v1.28.4
k8s-1.29 - cri-o version v1.29.2
k8s-1.27 remains on cri-o version v1.27.2 which does nto include the required fix.
[1] https://github.com/cri-o/cri-o/pull/7735

Fixes #
Why we need it and why it was done in this way
The following tradeoffs were made:
The following alternatives were considered:
Links to places where the discussion took place:
Special notes for your reviewer
/cc @dhiller @xpivarc
This should stop the slower vmi deletion flakes that we have been seeing for the 1.28 & 1.29 lanes.
I will work on the updates required to take the fixed 1.27 rpm.
Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note

NONE

/lgtm

/cherrypick release-1.2


PowerShell LTS:Continue releasing version for ubuntu1404 please, after one year more than EOL

Continue releasing powershell version to ubuntu1404, after one year or more than Linux distribution eol
Welcome discussion.
Most software does not stop releasing, at the Linux distribution eol day.
Especially powershell is developing.
on the powershell 6.2 release day ,i post news at china group,a debian8 user tell me he can not install 6.2.
Recently, ubuntu 1404 went to eol,so i  hope powershell-team can agree ，give powershell release to that distribution . one years or more.
There are a lot of ubuntu 1404 and debian 8 users. ubuntu 1404 users more than debian 8 users. Would rather not release the version of fedora, but also ubuntu 1404 and debian8 for release.

A problem is that we need .Net Core support before we can support PowerShell Core.
Please move request to .Net Core repo.

hi @iSazonov .this issue talk about powershell version LTS topic. Not related to .Net Core.Please correct the label.
Why did you close the issue too early?
At https://github.com/dotnet/core-setup ,see "Debian 8.2 (x64)",
A problem is that  .Net Core support debian 8 ,but powershell-team give not PowerShell release now.
ubuntu 1404 users more than debian 8 users.If powershel-lteam doesn't want to release the version to debian8, I don't want to stick to it. But at least it should be released to ubuntu 1404.

Ubuntu 14.04 is in supported list .Net Core 2.1 https://github.com/dotnet/core/blob/master/release-notes/2.1/2.1-supported-os.md
.Net Core 2.1 is LTS https://dotnet.microsoft.com/platform/support/policy/dotnet-core with end of support August 21, 2021
Ubuntu 14.04 End of Standard Support is April 25, 2019 then only paid support.
This information is in PowerShell docs https://docs.microsoft.com/en-us/powershell/scripting/powershell-support-lifecycle?view=powershell-6#powershell-release-end-of-life
PowerShell Core 6.1 end of life is September 28, 2019. For 6.2 I guess - + 6 months (April, 2020)
So we will get servicing updates for the versions for all supported platforms.
It is nor clear will .Net Core release servicing updates for Ubuntu 14.04 or no.
/cc @SteveL-MSFT @joeyaiello

For powershell lts, my point of view is:
Powershell should not be exactly the same as the .net support cycle.
For these versions, at least one year is postponed and two years are recommended.
Ubuntu 1404 = 1 year. After eol one year.
Ubuntu 1604 = 2 years.
Ubuntu 1804 = 2 years.
Debian8=1 years.
Debian9=2 years.
Centos7=2 years.
Last suse enterprize=2 years.
So my main point of view is:
Let powershell 6.2 give debian8, ubuntu1404, one year powershell software release.----For the going to eol version of Linux distribution , Force users to use the latest version of powershell.
Let powershell 6.1 stop publishing the version for debian8, ubuntu1404.

Because there is no support rule for eol linux distribution, the powershell version is released at will.
There 2 easy way:（Here I use debian8 as an example.Treat ubuntu1404 equally.）
1 continue release newest version (6.2) to debian8 (eol linux distribution), until 1 year is full.
2 if  first  powershell ga version （6.1.0 ，or 6.2.0） release for debian8 (eol linux distribution), then continue release powershell version for debian8, until this powershell version eol day.

PSCore6 has a different support lifecycle than .NET Core.  However, for PS7, we plan to align with .NET Core LTS-style support.  Since

@SteveL-MSFT We should consider the compliance of any such builds in the committee review.

DotNet Support for Ubuntu 14.04 ends when the OS EOL's per https://github.com/dotnet/core/blob/master/os-lifecycle-policy.md#net-core-supported-os-lifecycle-policy

Another problem, is that we cannot test the releases post EOL, without changes to our infrastructure as Ubuntu takes down their repos.

We could make servicing branches public (and unsupported by MSFT) so consumers could fork and compile locally if they really need.

Servicing releases are made as a tag, people can branch a tag.  There is no reason to keep a branch alive.  This is the same process we follow.

I think,
The powershell committee should first determine a principle.
Which Linux distributions will lose the powershell release (such as fedora) on the day of its eol;
which delays are 1 year (such as ubuntu1404);
which delays are 2 years.
Then, make a table listing the above in html.

Or keep the current policy where the EoL of the underlying distro determines our EoL.

For release, there is also a suggestion for the name of the linux package: (not to use it does not matter)
Suppose we release 7.0 preview1 , 7.0 preview2 , 7.0 rc1 , 7.0 rc2 ,
Then it is recommended to use the package name powershell-preview-7.0.1.rpm,powershell-preview-7.0.2.rpm, powershell-preview-7.0.3, powershell-preview-7.0.4 ...
(rc1 package name uses preview3, rc2 package name uses preview4, the order is not easy to make mistakes, because yum does not know "powershell-rc1" is newer than "powershell-prewiew2" .yum don't know if they are a piece of software )
The same thing we hinted at the release note, (rc1 packagename is preview3).

@chuanjiao10 that list issue definitely sounds like a real one. I think there's other solutions to it, but please file an issue for that one separately.
As for this issue, I don't understand how we can support something without underlying support in .NET Core and the OS. Sometimes things will "just work", and we won't ever restrict you from using that, but "supported" implies we're keeping pace with security updates, and if there are no underlying security updates, we're leaving our customers vulnerable.
@SteveL-MSFT might have context here that I don't have, though. We'll discuss it today.

@PowerShell/powershell-committee reviewed this and agrees that we cannot support unsupported OS' nor unsupported .NET Core releases.  Anyone who wants to use it can build their own and support it themselves.

no no no , my point never at "support"! ，my point never at "keeping pace with security updates"!  "support" is iSazonov say. my point is  "release powershell version after eol day".
Now that the powershell committee has reached a conclusion, I just want to hear the results now.
Powershell-team will not release the powershell version for  Linux distribution after them EOL day , right?

Whether to release the version, regardless of "support" and "keeping pace with security updates"
eg：
on https://www.mongodb.com/download-center/community ，we can download newest version of mongodb software for debian8.
on http://nginx.org/packages/debian/pool/nginx/n/nginx/ , we can download newest version of nginx, the binary package is http://nginx.org/packages/debian/pool/nginx/n/nginx/nginx_1.16.0-1~jessie_amd64.deb                   23-Apr-2019 15:13              835644

@chuanjiao10 MSFT team haven't resources to release PowerShell for platforms after EOL.
This is also prohibited by Microsoft security policies.
Some Linux communities release PowerShell distributives by themselves. Ubuntu community can do the same too.

@iSazonov  i known now.
Obviously, after 2020-01-15, ms will release new version to .net framework on win7,
Ms will release new version to .net core on win7,
With the increase in powershell users, powershell will have to do this in the future.
Should not be lazy to give up the existing powershell users!
Powershell-team will give up release ps version 6&7  to win7 after 2020-01-15? Time is not far away, let us wtaching.

Powershell-team will give up release ps version 6&7 to win7 after 2020-01-15?

If only an interested community I think.


Feature image has sides cropped, can I stop this?

Issue Summary
macOS Chrome on Ghost(Pro) them: alto Version 1.0.0. Not sure if a theme problem or an editor problem.
To Reproduce
Try to set this image as the feature image

It looks good in the editor:

Preview the blog:

The sides are cut off
It has a gray background. Not sure why? This is probably a theme bug because if changes with night mode.

Technical details:

Ghost Version: Whatever's on GhostPro right now.

Hey @mhansen,
Sorry about the delay! This is theme specific design which crops the images to ration of 1:2. I understand that it's not suitable for diagram type images. You can change this behavior by adding this CSS in Settings > Code inject > Site Header.
<style>
    .post-feed .post-image,
    .single-post .post-image {
        position: static;
    }

    .post-feed .post-media .u-placeholder::before,
    .single-post .post-media .u-placeholder::before {
    	display: none;
    }
</style>


Unable to fetch data from CISA.

Hi, I am unable to fetch any threat data from Cisa. I always get the following output:

Software.txt consists of following keyword:

MISP config is as follows:

I checked the latest Cisa Advisories, there are threats related to my keyword (i.e. in software.txt) but still the output shows that there are no new threats or vulnerabilities.

Hi!!
Check the entries.db SQLite file in the config folder. I created that SQLITE file to quickly check if a threat was already gathered. If it's already stored it won't be printed nor sent to MISP.
Remove the registers, and rerun it. Take also this into account for the future if you run this periodically.

Hi, I have cleared the Database, but now I am getting this error.

Hi!! It seems you have a MISP instance version that is not compatible with your pymisp library. I didn't test it with a new version yet.
Anyway, I've just uploaded some changes for managing the exception. Could you test it with the new changes?
Thanks!

Hi, I tested it with changes. Still doesn't work.

P.s: What's the version of your MISP instance?

Try it again, I've updated the cast to string when printing the exception.
I tested the script successfully with the 2.4.150 version.

Hi, I am getting these errors now. Also, do I have to make any changes in the project except adding Misp Url and API key in config.ini file?
The methodology I followed was to create a virtual environment, clone the project and install requirements.txt file. Then added Misp Url and API key in config.ini file. And used the command "python3 main.py --full" to run the project. Is there anything which I am missing ?

Probably it cannot find the package. Try "python setup.py install" within your virtualenv.

Hi, I tried "python setup.py install" but still getting the same error. Anything else that you would suggest to make it work?

Hi there!
Did you solve your issues? I've been out from home for a week and I couldn't answer you before. I uploaded a Dockerfile that may help you to test the script.
docker build -t cisa_test .
docker run -it cisa_test

Hey, the issues got resolved and it works perfectly now. I did few changes in misp.py file that helped to resolve the errors.


Revert "Update the Windows SDK version for RestartAgent"

Reverts microsoft/WindowsAppSDK#2043
I'm reverting this PR as it seems that it is causing the nightly build to fail. I am not sure I fully understand why that it the case as the other projects for the WindowsAppSDK seem to be happy with 10.0 (latest installed verion)
I find it strange that this project is specifically targeting v10.0.20348.0 but I assume that we're relying on a bug fix that wasn't present before. Then the question becomes why is WindowsTargetPlatformMinVersion set to 10.0.17134.0.

/azp run

On hold for now, as this may not be what broke the build originally

Closing for now as this doesn't seem to be the root cause of the build break.