info addon and storyshot seem to be incompatible

I am having trouble getting storyshots to work when using the info addon, when I try and run storyshots, it gives me the error:
yarn test-storybook v0.22.0
$ storyshots
=> Loading custom .babelrc
TypeError: (0 , _storybook.storiesOf)(...).addDecorator(...).addWithInfo is not a function
    at Object.<anonymous> (/Users/localuser/lendi/learning/antd-forms/src/form-schema/stories/ArrayType.story.js:69:4)
    at Module._compile (module.js:571:32)
    at loader (/Users/localuser/lendi/learning/antd-forms/node_modules/babel-register/lib/node.js:144:5)
    at Object.require.extensions.(anonymous function) [as .js] (/Users/localuser/lendi/learning/antd-forms/node_modules/babel-register/lib/node.js:154:7)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.require (module.js:498:17)
    at Module.module.constructor.require.original (/Users/localuser/lendi/learning/antd-forms/node_modules/require-middleware/lib/require-middleware.js:32:21)
    at Module.module.constructor.require (/Users/localuser/lendi/learning/antd-forms/node_modules/require-middleware/lib/require-middleware.js:28:69)
error Command failed with exit code 1.

I am using an ejected create-react-app, the .babelrc looks like:
{
  "presets": [
    "react-app"
  ],
  "plugins": [
    "transform-class-properties",
    [
      "import",
      {
        "libraryName": "antd",
        "style": "css"
      }
    ]
  ]
}

My configuration looks like this:
import {configure, setAddon} from '@kadira/storybook'
import infoAddon from '@kadira/react-storybook-addon-info'

const req = require.context('../src', true, /.story.js$/)

setAddon(infoAddon)

function loadStories () {
  req.keys().forEach(filename => req(filename))
}

configure(loadStories, module)

The webpack configuration for storybook looks like this:
// you can use this file to add your custom webpack plugins, loaders and anything you like.
// This is just the basic way to add addional webpack configurations.
// For more information refer the docs: https://getstorybook.io/docs/configurations/custom-webpack-config

// IMPORTANT
// When you add this file, we won't add the default configurations which is similar
// to "React Create App". This only has babel loader to load JavaScript.

module.exports = {
  plugins: [
    // your custom plugins
  ],
  module: {
    loaders: [
      // add your custom loaders.
      {
        test: /\.svg$/,
        loader: 'svg-sprite'
      },
      {
        test: /\.css$/,
        loader: 'style!css'
      }
    ]
  }
}

Is there a workaround for using these two plugins together.

I have updated to the new storyshots and have configured the Storyshots.test.js file like this:
import initStoryshots from 'storyshots'
initStoryshots()

I added the matchMedia.js polyfill to config/polyfills.js, I enforced the env of development for the import plugin .babelrc to avoid breaking yarn test when it tries to require js files from the antd module.
I then find that the error is back again:
{
  "presets": [
    "react-app"
  ],
  "plugins": [
    "transform-class-properties",
  ],
    "env": {
      "development": {
        "plugins": [
          "import",
        {
          "libraryName": "antd",
          "style": "css"
        }
        ]
      }
    }
}

I have this error again now:
TypeError: (0 , _storybook.storiesOf)(...).addDecorator(...).addWithInfo is not a function

      at Object.<anonymous> (src/form-schema/stories/ArrayType.story.js:69:1)
      at node_modules/storyshots/dist/require_context.js:40:24
      at Array.forEach (native)
      at requireModules (node_modules/storyshots/dist/require_context.js:34:9)
      at node_modules/storyshots/dist/require_context.js:49:7
      at Array.forEach (native)
      at requireModules (node_modules/storyshots/dist/require_context.js:34:9)
      at node_modules/storyshots/dist/require_context.js:49:7
      at Array.forEach (native)
      at requireModules (node_modules/storyshots/dist/require_context.js:34:9)
      at Function.newRequire.context (node_modules/storyshots/dist/require_context.js:92:5)
      at evalmachine.<anonymous>:11:21
      at runWithRequireContext (node_modules/storyshots/dist/require_context.js:104:3)
      at testStorySnapshots (node_modules/storyshots/dist/index.js:72:35)
      at Object.<anonymous> (src/form-schema/Storyshots.test.js:2:52)

How can I get the new storyshots to work with info addon? Is there any workaround or is there any configuration for the issue.

When reading the source, I found that addWithInfo is syntactic sugar for the add method with an Info component containing the actual story. So I changed my stories to look like:
import {Story as Info} from '@kadira/react-storybook-addon-info'

 storiesOf('MyComponent', module)
   .add('my component is amazing', context => {
          const myCompProps = {a: 'b'}
   const info = `This string can get really long`
   return (
      <Info
        info={info}
        context={context}
        showInline
        propTables={[MyComponent]}
        styles={s => s}
        <MyComponent {...myCompProps} />
      </Info>
    )
   })

A few things are still giving me trouble though:
The Info component is now unfortunately a part of the snapshot, changes to the documentation will force me to update my snapshots. Also, I am having a bit of trouble introducing custom examples into info because Prism is not defined.

Thanks for the report @vamsiampolu.
We should get rid of the addWithInfo API, it is a bit of a historical anomaly.
In terms of your second problem, I agree it's an issue with all decorators. It's something we'd like to solve as part of a new addon API #1212

@tmeasday @vamsiampolu see also #1147

Adding this to our .storybook/config.js seems to work:
import { setAddon } from '@storybook/react';
import infoAddon from '@storybook/addon-info';
if (process.env.NODE_ENV === 'test') { // for storyshots
    setAddon({
        addWithInfo: function addWithInfo(storyName, info, storyFn) {
            return this.add(storyName, (context) => {
                const renderStory = typeof info === 'function'
                    ? info
                    : storyFn;

                return renderStory(context);

            });
        },
    });
} else {
    setAddon(infoAddon);
}

#1147 info will be moved into a panel
And we have a solution:
https://github.com/storybooks/storybook/issues/1011#issuecomment-313439490

If you use the latest addon-info (>3.2.0) 's withInfo, the workaround can be even simpler:
// storybook.test.js
import initStoryshots from '@storybook/addon-storyshots';

const addonInfo = require('@storybook/addon-info');
addonInfo.withInfo = () => storyFn => storyFn;

initStoryshots();

Thank for the additional help @MrOrz


MySQL test changes

@JohnMcLear I moved your test/lib/mysql.sql changes from the linting branch to this PR.

Just a note here that it should actually execute the procedure 1M times not 1K times but afaik it was reduced so the tests ran quick enough / were stable.  I'm not sure how stable it would be now on github actions vs travis.

Just a note here that it should actually execute the procedure 1M times not 1K times but afaik it was reduced so the tests ran quick enough / were stable. I'm not sure how stable it would be now on github actions vs travis.

For MySQL the time it takes to bulk execute N operations appears to be O(e^N) (not O(N) as expected) due to incremental query construction, so 1M operations will take an long time, and the time per op will be really high. The nonlinear growth should be fixed before increasing the count.

Closing as stale.


⚠ Bofrost.de has degraded performance

In aad5604, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1155 ms

Resolved: Bofrost.de performance has improved in e57c7b2 after 6 minutes.


Define border radius

Define border radius and identify impacted components.
Agree simplified approach to border radius, test radius' and identify any potential component changes
Add border as a foundation and update components to use it. Create rounded border radius fragment.

Border radius added into Salt 2 variables library.
Applied to relevant components in unstable component library
Applied to relevant components in stable component library in branch ready to merge.

Dark mode component library still requires updating


Dump TagRouterRule

Dump TagRouterRule since the TagRouterRule can be changed to null by ConfigCenter.
Since his Issue[1] does not give a stack trace, I am not sure that his problem is caused by this.
[1] https://github.com/apache/incubator-dubbo/issues/3533

Codecov Report

Merging #3536 into master will increase coverage by <.01%.
The diff coverage is 14.28%.

@@             Coverage Diff              @@
##             master    #3536      +/-   ##
============================================
+ Coverage     64.07%   64.08%   +<.01%
  Complexity       71       71
============================================
  Files           664      664
  Lines         28617    28618       +1
  Branches       4770     4770
============================================
+ Hits          18337    18340       +3
+ Misses         8056     8055       -1
+ Partials       2224     2223       -1

Impacted Files
Coverage Δ
Complexity Δ

...apache/dubbo/rpc/cluster/router/tag/TagRouter.java
40.24% <14.28%> (+0.73%)
0 <0> (ø)
:arrow_down:

...ache/dubbo/remoting/transport/AbstractChannel.java
75% <0%> (-12.5%)
0% <0%> (ø)

...che/dubbo/remoting/transport/mina/MinaChannel.java
43.42% <0%> (-10.53%)
0% <0%> (ø)

...bbo/registry/support/ProviderConsumerRegTable.java
80.48% <0%> (-4.88%)
0% <0%> (ø)

.../apache/dubbo/remoting/transport/AbstractPeer.java
58.69% <0%> (-4.35%)
0% <0%> (ø)

...bo/rpc/cluster/support/FailbackClusterInvoker.java
67.21% <0%> (-3.28%)
0% <0%> (ø)

.../java/org/apache/dubbo/config/ReferenceConfig.java
57.89% <0%> (+0.37%)
0% <0%> (ø)
:arrow_down:

...pache/dubbo/registry/support/AbstractRegistry.java
80.7% <0%> (+1.57%)
0% <0%> (ø)
:arrow_down:

...dubbo/remoting/exchange/support/DefaultFuture.java
72.97% <0%> (+2.02%)
0% <0%> (ø)
:arrow_down:

...c/main/java/org/apache/dubbo/rpc/RpcException.java
86.2% <0%> (+3.44%)
0% <0%> (ø)
:arrow_down:

... and 2 more

Continue to review full report at Codecov.

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

LGTM, I think your change is critical to guarantee consistent behavior when rule changes.
But what's the possible relation with the issue mentioned here.

When I saw his issue before, he did not give his exception stack. Later, the issuer added the stack. I looked at the code and found that this place also caused some problems, so I modified it. @chickenlj


opencv 相关库报错

QObject::moveToThread: Current thread (0x55c44bf87060) is not the object's thread (0x55c4553307a0).
Cannot move to target thread (0x55c44bf87060)
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "/root/miniconda3/lib/python3.8/site-packages/cv2/qt/plugins" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: xcb, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl.
你好，请问这个错误如何解决呢？在网上找了很多办法也没有解决。这似乎是opencv库的问题？你们没有遇到这个问题吗?

问题解决了，我原来是用autoDL跑的，这是linux系统，所以会出现问题，用windows本地的系统跑就不会有问题。


Add Mixins (stack customizations)

Idea to make stack customizations easier to manage.

@sclevine How well is the requirement that everything go into a specific folder going to work?  I thought one of the biggest issues was that packages have hard coded paths and have to be installed into standard system locations?

And this might be broader than just this issue (I'm not especially familiar with the platform spec), but should we be writing the spec in terms of Dockerfiles?  I know @dgodd had a preference for doing this stuff programmatically rather than using them, and that feels like a noble long-term goal that would run counter to a specific that defines Dockerfiles as a base requirement.

How well is the requirement that everything go into a specific folder going to work? I thought one of the biggest issues was that packages have hard coded paths and have to be installed into standard system locations?

Packages would be installed into standard system locations. Rebasing would only be possible after the new image has the associated mixins installed.
The difference between this and the previous iteration of stack modifications is that the stack author and/or platform maintainer would control what mixins buildpacks/apps can request. E.g., a platform like PWS or Heroku could provide a small, medium, and large versions of the stacks with different mixin sets, while a private deployment of CF could have custom mixins.

@sclevine Then I don't think I understand the line:

A mixin MUST be stored in a directory with an identical name to the mixin.

That's just describing the format for storing the mixin before it is applied to a stack -- it's a directory containing two Dockerfiles that modify the different base images.

@sclevine i also have concerns about basing this on Dockerfile. Can we start this as an extension, and discuss it a bit more?

Removed all references to Dockerfiles. Happy to re-write this an extension, but I'd like to keep it here until we can discuss in more depth.
Also, I created an alternative PR #25 that would use operating system package names instead of mixins for comparison.

@sclevine Besides packages like imagemagick, what are some other examples of mixins?

Actually, according to these changes a mixin is only a package. Should we not just call the TOML key packages?

Actually, according to these changes a mixin is only a package. Should we not just call the TOML key packages?

It's a collection of packages. A single Ubuntu package may depend on many other packages, so it would be tricky to map each mixin to one package. Also, that's only a recommendation (SHOULD), and a mixin could contain any change that the stack author deems "safe."

I'm good with this, but I wonder if we should define a stronger mechanism for installing packages. I'm glad this won't be Dockerfile based, but maybe we can introduce some other mechanism in the future (bin/mixin or something).

Awesome! A mixin is defined by the stack author or operator, so maybe this could be fleshed out wherever we describe how to construct a stack?


Improve Get-ResourceIdsOfDeployment script naming

Description
Discuss and propose a more intuitive naming for variables used by the Get-ResourceIdsOfDeployment script.
e.g. The outer function refers to $deployments, the inner one refers to a mix of $deployments, $deploymentTargets, $resultSets. The function name itself suggests the output should be resourceIds.

Done ;) @eriqua


When fonipa script selected, LangTag uses default script instead

On any language, select the IPA script (fonipa) and click SAVE. The LangTag used for setInfo has the language's default for Script instead of fonipa. Moreover, clicking on the language picker to alter the selection has the script dropdown menu back on the default instead of on IPA.
Edit: "fonipa" is available under .variant instead of .script.

This now works correctly in the program with version 2.0

@gtryus I think this is still an issue, and may be related to #14

I think this was resolved in 2.1.2.


Madcatz rb4 config

Fixes https://github.com/delabrcd/rockband-4-midi-drums/issues/1
I cleaned up the code changes I made for the MadCatz toy brain and used conditional preprocessor directives. The user can still change the settings on their own, but it should be more streamlined, hopefully.

I originally thought this too, but after doing a lot of back and forth with the kick wires, this worked for me. Any other configuration would either not trigger the kick at all, would make the Mad Catz board unusable, would go into some spasm, or it would work, but the kick would stay active all the time. This was noticeable while playing the game where the colors under the gamertag would light up.
I do recall finding this other DIY from back in 2015 https://rkuo.com/2015/10/18/rock-band-4-drum-kit-teardown-midi-mod-and-general-problems/comment-page-1/

The kick pedal works differently from the other pads.  Like the cymbals, it also has a small helper board at the peripheral input point that does the signal amplification.  However, at the main board, instead of poking the connection point with a 3.3V signal, the kick pedal is activated by pulling the kick pedal’s 3.3V line to ground.  To account for this, the MIDIWidget output for the kick pedal needs to be inverted.


Added rdf attribute to namespace which enables svg's exported from In…

…kscape.

I'd rather this were done in a more sensible way, otherwise we're going to end up with lots of namespaces for different applications. Might be worth adding a check in for namespaces within an SVG and adding those to the parent.


Azure AI Face SDK v1.1

Description
Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[ ] The pull request does not introduce [breaking changes]
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[ ] I have read the contribution guidelines.

General Guidelines and Best Practices

[ ] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-ai-vision-face

Will try to fix pylint issue before the PR merge:
https://github.com/Azure/autorest.python/issues/2817
https://github.com/Azure/autorest.python/issues/2800

https://dev.azure.com/azure-sdk/public/_build/results?buildId=4164022&view=logs&j=b70e5e73-bbb6-5567-0939-8415943fadb9&t=e3f8f308-6e5f-58aa-3a2a-fe425958de32
@Han-msft Please update _patch.py to fix the mypy/pyright error.


Location of from_pandas code

System information

Modin version: 0.5.4

Describe the problem

The from_pandas code seems to have the same function as some of the read_csv code so should it be moved to io.py for consistency?

Thanks @dulinda, I agree. from_pandas should share code with the other data ingest methods.

By version bd326f1c4175102489f08d271a53cf374bd9125e or earlier, from_pandas is in the IO code: https://github.com/modin-project/modin/blob/41e32e9edcd1e6755d6f959e573f807a75c7ae7e/modin/core/io/io.py#L60


HADOOP-18390. Fix out of sync imports for HADOOP-18321

Description of PR
Fix out of sync imports for HADOOP-18321
JIRA - HADOOP-18390
For code changes:

[X] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 44s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 4 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
16m  1s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
25m 30s

trunk passed

+1 :green_heart:
compile
23m 18s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
20m 44s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
4m 27s

trunk passed

+1 :green_heart:
mvnsite
3m 47s

trunk passed

+1 :green_heart:
javadoc
3m  0s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
2m 34s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
5m 17s

trunk passed

+1 :green_heart:
shadedclient
22m 39s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 32s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 50s

the patch passed

+1 :green_heart:
compile
22m 22s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
22m 22s

the patch passed

+1 :green_heart:
compile
20m 47s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
20m 47s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
5m 30s

the patch passed

+1 :green_heart:
mvnsite
3m 45s

the patch passed

+1 :green_heart:
javadoc
2m 50s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
2m 36s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
5m 28s

the patch passed

+1 :green_heart:
shadedclient
22m 50s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
18m 43s

hadoop-common in the patch passed.

+1 :green_heart:
unit
7m 29s

hadoop-mapreduce-client-core in the patch passed.

+1 :green_heart:
asflicense
1m 36s

The patch does not generate ASF License warnings.

249m 11s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4694/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4694

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux aefefd39af5c 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 14b28a3103cc53c915f7b2a01306ea37c4ab0852

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4694/1/testReport/

Max. process+thread count
2108 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4694/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

Thank you @ashutoshcipher for the fix.


Update input-forms.md

Fixed typo, made spelling of "drop-down" consistent with other documentation. Removed use yii\helpers\ArrayHelper from code example as ArrayHelper is no longer used in example.

W3 concern suggests "dropdown" spelling http://www.w3schools.com/bootstrap/bootstrap_dropdowns.asp

"Drop-down" is used throughout the Yii documentation:
http://www.yiiframework.com/doc-2.0/yii-helpers-basehtml.html#activeDropDownList()-detail
We're talking about HTML  here, not the Bootstrap component.

Looks OK to me. Thanks!


Should paths for plane group 2 include parts of the BZ boundary?

The paths for plane group 2 (and, similarly, other space groups with mP Bravais type; e.g., space group 3), currently only go from the origin to [0, ½], [½, 0], and [½, ½]. This is inherited from seekpath's choices but doesn't make a ton of sense: e.g., the lines are not actually symmetry lines in plane group 2 (since there aren't any) and, practically, one would likely like to include parts of the BZ boundary as well.
There are extra points in seekpath that aren't included in the path - they don't seem to generally get the BZ boundary right, but frequently (there probably needs to be a branch and more points in general). The code below illustrates the extra points in space group 3 (the "parent" space group of plane group 2):
using LinearAlgebra, Brillouin, Crystalline, PlotlyJS

Rs = directbasis(3)
Gs = reciprocalbasis(Rs)
cell = wignerseitz(Gs)
kp = irrfbz_path(3, Rs)

a, b, c, = norm(Rs[1]), norm(Rs[2]), norm(Rs[3])
cosβ = dot(Rs[3], Rs[1])/(c*a)
sinβ = sin(acos(cosβ))
Y = ((((1 + (a / c) * cosβ) / 2) / sinβ) / sinβ)
N = (1 / 2 + (Y * c * cosβ) / a)
pts = Dict(:Γ => [0, 0, 0],
       :Z => [0, 1/2, 0],
       :B => [0, 0, 1/2],
       :Y₂ => [-1/2, 0, 0],
       :C₂ => [-1/2, 1/2, 0],
       :D => [0, 1/2, 1/2],
       :A => [-1/2, 0, 1/2],
       :E => [-1/2, 1/2, 1/2],
       # extra points not included in the path (but in seekpath's point lists)
       :H => [-Y, 0, 1-N],
       :H₂ => [-1+Y, 0, N],
       :H₄ => [-Y, 0, -N],
       :M => [-Y, 1/2, 1-N],
       :M₂ => [-1+Y, 1/2, N],
       :M₄ => [-Y, 1/2, -N])

kp′ = deepcopy(kp)
merge!(kp′.points, pts)
plot(cell, kp′)

Here's some code for visualizing the 2D situation, with some additional points included.
function prep_bz_path(Rs)
    Gs = reciprocalbasis(Rs)
    cell = wignerseitz(Gs)
    kp = irrfbz_path(2, Rs)

    a, b = norm(Rs[1]), norm(Rs[2])
    cosβ = dot(Rs[1], Rs[2])/(a*b)
    sinβ = sin(acos(cosβ))
    Y = ((((1 + (b / a) * cosβ) / 2) / sinβ) / sinβ)
    N = (1 / 2 + (Y * a * cosβ) / b)
    pts = Dict(
        :Γ => [0, 0],
        :B => [1/2, 0],
        :Y => [0, 1/2,],
        :A => [1/2, 1/2],
        # not included in path:
        :H => [1-N, -Y],
        :H₂ => [N, -1+Y],
        :H₄ => [-N, -Y],
        :H′ => [-1+N, Y],
        :H₂′ => [-N, 1-Y],
        :H₄′ => [N, Y],
        )

    merge!(kp.points, pts)
    return cell, kp
end

b = 1.0
β = π/2 + π/3
Rs = crystal(1.0, b, β)
cell, kp = prep_bz_path(Rs)

f = Figure();
ax = Axis(f[1,1]; aspect=1.0)

plot!(ax, cell)
plot!(ax, kp)
f

The additional points e.g., don't match when β<π/2 (but if b≠1 it also fails in other cases).
When it works, it looks like this (β = π/2 + π/3):

When it doesn't work, it looks like this (β = π/2 - π/7):

The situation can be explore a bit better by tuning a parameter continuously and following the BZ shape and points:
sl_β = Slider(f[1, 2], range = range(0.0+π/10, π-π/10, 100), startvalue = β, horizontal = false)
on(sl_β.value) do β
    Rs = crystal(1.0, b, β)
    cell, kp = prep_bz_path(Rs)
    empty!(ax)
    plot!(ax, cell)
    plot!(ax, kp)
end
f

In general, it looks quite painful: many cases to control for. Probably related to Rs no longer being a "minimal" choice of the basis.


launch options: optional shortkeys for different modes

In launch.json or settings.json i have
    "launch": {
        "version": "0.2.0",
        "configurations": [
            {
                "name": "debug",
                "request": "launch",
                "type": "dart",
                "flutterMode": "debug"
            },
            {
                "name": "release",
                "request": "launch",
                "type": "dart",
                "flutterMode": "release"
            },
            {
                "name": "profile",
                "request": "launch",
                "type": "dart",
                "flutterMode": "profile"
            }
        ]
    },

a i have to start very often in another mode. So i would like to have shortkeys defined (which will be with highest priority in keyboard-shortcuts), like the following:
    "launch": {
        "version": "0.2.0",
        "configurations": [
            {
                "name": "debug",
                "request": "launch",
                "type": "dart",
                "flutterMode": "debug",
                "shortkey": "F5" *
            },
            {
                "name": "release",
                "request": "launch",
                "type": "dart",
                "flutterMode": "release",
                "shortkey": "F6" *
            },
            {
                "name": "profile",
                "request": "launch",
                "type": "dart",
                "flutterMode": "profile",
                "shortkey": "F7" *
            }
        ]
    },

* optional

Not sure,
i found "debug.showInStatusBar": "always" which works good, too 👍
My intention was to not switch to debug in sidebar all the time where i just have to run apps on my phone. Now i can click at statusbar and then choose the mode - which is good enough.
Feel free to close this request

"debug.showInStatusBar": "always" seems not to work after closing the folder and opening a new project. Now its gone again, but is set to "debug.showInStatusBar": "always"` as written.

"debug.showInStatusBar": "always" does not work as espected to me - sometimes it is shown, sometimes not. Whats that state? There are differences in openening closing projects / vs code.

So, maybe it's not optimal as suggested

The first request to launch a specific launch configuration can be done via an extension and we do not want this behavior in the core vscode. The extension can contribute a command, assign any keybinding to it, read the content of the launch.json and launch a new debug seassion using this api
As for the statusBar visibility.
"debug.showInStatusBar": "always"  always show the status bar entry for me.
If that is not he case for you please file a new issue with exact reproducable steps so we can investigate more and fix this. Thanks

As the bot would say
We try to keep VS Code lean and we think the functionality you're asking for is great for a VS Code extension. Maybe you can already find one that suits you in the VS Code Marketplace. Just in case, in a few simple steps you can get started writing your own extension. See also our issue reporting guidelines.\n\nHappy Coding!


compilation error in macro statement: "cannot unpack non-iterable NoneType object"

Howdy partner,
I ran into an error creating a minimal dbt-duckdb example. I wish I could give more information but I'm a dbt newbie. Below is a repository that (hopefully) recreates this issue w/ a couple of essentially trivial model files:
https://github.com/hamilton/dbt-duckdb-test
dbt run gives this output:
00:08:05  Running with dbt=1.0.1
00:08:05  Found 2 models, 4 tests, 0 snapshots, 0 analyses, 165 macros, 0 operations, 0 seed files, 0 sources, 0 exposures, 0 metrics
00:08:05
00:08:05  Concurrency: 1 threads (target='dev')
00:08:05
00:08:05  1 of 2 START table model main.ingest............................................ [RUN]
00:08:05  1 of 2 ERROR creating table model main.ingest................................... [ERROR in 0.08s]
00:08:05  2 of 2 SKIP relation main.second................................................ [SKIP]
00:08:05
00:08:05  Finished running 1 table model, 1 view model in 0.34s.
00:08:05
00:08:05  Completed with 1 error and 0 warnings:
00:08:05
00:08:05  Compilation Error in macro statement (macros/etc/statement.sql)
00:08:05    cannot unpack non-iterable NoneType object
00:08:05
00:08:05    > in macro materialization_table_default (macros/materializations/models/table/table.sql)
00:08:05    > called by macro statement (macros/etc/statement.sql)
00:08:05
00:08:05  Done. PASS=0 WARN=0 ERROR=1 SKIP=1 TOTAL=2

My profiles.yml:
duckdb_test:
  outputs:
    dev:
      path: /Users/hamiltonulmer/Code/tmp/duckdb_test/db.duckdb
      type: duckdb
  target: dev

Thank you @hamilton ! pretty sure this is some API update I missed when I did the upgrade, will dig into it and figure it out

Hey @hamilton-- this took me a stupid long time to track down, but the issue is in model definitions themselves, which should not have semi-colons at the end of the files for ingest.sql and second.sql; if you remove them everything works as expected. However, this is an obvious case where I need a much better error msg that I'm getting right now, so I read some other adapter impls and got some ideas on how I can make these errors more obvious to the user. Thank you so much!

Yikes! Thanks for putting in time to figure this out, and sorry it was a newbie error. Will update the title to reflect this.

Fix is in 1.0.2

what a mensch! thanks for the fix.


Added translator

update  Spanish translations on poeditor

Hey there! Are you wiling to be a translator for the project or have you already contributed translations?

Hello! Yes, I've already made some translations on Poeditor for the Spanish language. I'd be more than willing to continue contributing as a translator for the project. Please let me know if there's anything specific you need help with.

Thank you very much! Yes, we'd love more contributions from you. I'm accepting this PR :)

... but it takes someone with write access and the original creator seems to be on hiatus right now...

Pushed this to my fork of the project. See this for more information.
Thank you for your contribution :)


Starting node-red with PM2 on Windows: Unexpected token ILLEGAL

Hi there,
when I try to PM2 start node-red I get the following error:
SyntaxError: Unexpected token ILLEGAL     at exports.runInThisContext (vm.js:53:16)     at Module._compile (module.js:413:25)     at Object.Module._extensions..js (module.js:452:10)     at Module.load (module.js:355:32)     at Function.Module._load (module.js:310:12)     at Function._load (C:\Users\Arakno\AppData\Roaming\npm\node_modules\pm2\node_modules\pmx\lib\transaction.js:62:21)     at Object.<anonymous> (C:\Users\Arakno\AppData\Roaming\npm\node_modules\pm2\lib\ProcessContainerFork.js:46:21)     at Module._compile (module.js:434:26)     at Object.Module._extensions..js (module.js:452:10)     at Module.load (module.js:355:32)

Hi!  Thanks for reporting. I'm not sure how this is related to the plugin. Can you provide some thoughts to help clarify?
I'll close for now until we get more information. Happy to reopen if this turns out to be a bug in the plugin.

Ok, which kind of info do you need?

Any ideas on how is this related to the JSCS-Formatter plugin would be helpful.
Neither Pm2, node-red, nor the stracktrace point to this plugin causing any issues.
Did you try executing a command through this plugin that caused the issue?
Did you file this issue on the wrong repo?

Sorry, I'm very newbie to theese topics... I'm only trying to launch node-red via PM2, writing "pm2 start node-red" in win cmd shell. It starts but, after a few minutes, if i PM2 status, then I see that node-red status is "errrored" and in the logs you can see the stacktrace I pasted before... should I do any configuration? I get the same error by typing pm2 start node-red -i max
Thanks!

ok now I got the meaning of your words... sorry I submitted it in the wrong repo!!!!

Thanks for the info. Yes, please file an issue with https://github.com/Unitech/pm2 or ask on stackoverflow.
Glad we could point you in the right direction! Cheers!

Cheers!


Allow other currencies than USD

Support other currencies than USD (needed that for german tax)
Merge all reward events that happened on the same day (coingecko historic API only reports price once per day)
Improve error reporting
Bugfixes and quality of life fixes

The merge of same day events is also useful to keep the amount of entries to a manageable level for the tax office.

Thanks! This is great!


/gp unlockdrops not working again

http://puu.sh/omJvk/9f88bc78da.png
/gp unlockdrops is not working again. It says you've unlocked drops after you do the commands but the message that other players cant pick it up still appears(spams it)
When drops are not unlocked yet, it spams both receiver and dropped of the item a lot. The screenshot above is from the receiver.

I cannot reproduce this issue. Remove all your plugins and test again.

Closing as this is not a GP issue.


double clicked node

Hello,
I see in your example, that it is possible to make a node that has a method ondbclick() in the HTML to execute a modal.
However, I would like to know if there is a trigger directly by the editor for a double click on a node.
I know that there is for a selected node:
editor.on('nodeSelected', function (id) {
        toggleSidebar("right");
    });

however I would like to trigger a double click on the node. Is there a way to do this without having to use the method in the HTML?

Its possible to do, here is a link to the same: https://github.com/jerosoler/Drawflow/issues/299#issuecomment-968281180
The above example is for connector but I guess you can do the same for node.

I used the doubleclick rewrite because the clickEnd doesn't fit my needs as I need an event on a doubleclick but is there a way to get the ID of the clicker node or do I have to use the read data-id technique in the event.target ?
`editor.dblclick = function(e) {
if(this.node_selected != null){
console.log(HERE MY NODE ID);
}
if(this.connection_selected != null && this.reroute) {
this.createReroutePoint(this.connection_selected);
}
if(e.target.classList[0] === 'point') {
this.removeReroutePoint(e.target);
}
if (e.detail === 2 && e.target.classList[0] === "main-path") {
console.log(editor.connection_selected);
}
} `


Postgres Support

Tweaked to use with postgres,  also fixed some bugginess
DISCLAIMER: This has not been tested with MySql although it should be fine, mostly changed environment variables and some knex.config references

Thanks, @jsuna! Looks all good. I agree, MySQL support should not be affected by any of the changes.


Move from just hashing time to using actual entropy.

When we activate a vane, we should pass in real entropy instead of just hashing now. When we modify entropy, we should hash the concatenation of the old entropy and the new entropy instead of just xoring them.

@jtobin What do you think of hashing the concatenation here, vs. XOR? I recall you had some opinions about this sort of thing.

Merging per @belisarius222 , but I'm still curious about @jtobin 's thoughts.


Broken sequenceAnimation test

The feature appears to work but the component sequenceAnimation test is currently broken in the test suite (and has been marked 'pending' for some time).

This was fixed in f95d1f6b0580c524b4997b515a4468ca83a526c2


Microsoft Entra Id Workload Federation Missing Network Connectivity requirements

For workload federation to work Microsoft Entra Id needs to be able to reach out to Open ID IdP to verify tokens. Some of the Open ID IdP hosted on AKS or Github can be located on private network and protected by firewall.
Need to add URLs or IP ranges for firewall configuration to allow Microsoft Entra Id to validate Open ID token from Federated IdP

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

ID: cf644d11-51ae-8ef0-34c8-d471a47d5cf1
Version Independent ID: d5e3190b-f287-6542-fd2b-f8fe9066c23e
Content: Workload identity federation - Microsoft Entra
Content Source: articles/active-directory/workload-identities/workload-identity-federation.md
Service: active-directory
Sub-service: workload-identities
GitHub Login: @rwike77
Microsoft Alias: ryanwi

@noendscripting
Thanks for your feedback! We will investigate and update as appropriate.

@noendscripting
Thank you for bringing this to our attention.
I've delegated this to content author @rwike77, who will review it and offer their insightful opinions.

@rwike77
Could you please review add comments on this, update as appropriate.

#please-close no movement


[1.0] Thread Network Diagnostics cluster: impossible to obtain RLoc16 for the current node

Reproduction steps
The Thread Network Diagnostics cluster seems to lack an attribute that would return an RLoc16 for the node being queried. There are RLoc16s in the routes and neighbors table, but no way of obtaining the device's own RLoc16.
It could have been derived from the General Diagnostics Cluster -> Network Interfaces -> IPv6Addresses, but these also do not expose the routing locator IP (::ff:fe00:).
Is there any way to obtain the current Thread node RLoc16 that I have overlooked?
Bug prevalence
always
GitHub hash of the SDK that was being used
561d23d0db215a99705ff0696e73853c8edf11b2
Platform
core
Platform Version(s)
No response
Type
Common Cluster Logic
Anything else?
No response

It looks like it may be an oversight.  I would ask why you need the ephemeral RLOC of a node, but I would assume the answer is “to make meaning out of the RouteTable and NeighborTable entries”.
The IPv6 address parsing method could potentially work. My reading of General Diagnostics Cluster -> Network Interfaces -> IPv6Addresses is that the full 128-bit IPv6 addresses are listed, so RLOCs could potentially be gleaned as follows:

Thread_Mesh_Local_Prefix::RLOC_IID
Where RLOC_ID has the form per <IP_ADDRESS> Routing Locator (RLOC): 0000:00FF:FE00:xxxx where ‘xxxx’ is ... the RLOC

Thank you @turon for a quick response!
Indeed, I also thought that I could derive the RLoc from the IPv6 addresses, but as I have originally mentioned, the needed IP containing that is also not exposed.
I also been thinking the routes table may have a "self" entry with a cost of 0 (or something), but it seems to not be the case as well.
So far the only weak method I found is if the surveyed node is a router having children connected, it's possible to deduct its RLoc16 from the children's.
And yeah, I need the RLoc to create the topology map of the network (shown in the Thread Network view of the Eve app for the iOS). :)
I agree it changes over time, but having rloc references in the routes and neighbors lists and not having it for the node itself is a little odd.
So I assume we will need an additional attribute in the cluster for the future versions of Matter.
BTW, the description for the PanId attribute reads like it was really about an RLoc16 (as the panId identifies the network and not a single node):

<IP_ADDRESS>. PanId Attribute
The PanId attribute SHALL indicate the 16-bit identifier of the Node on the Thread network. A value of null SHALL indicate that the Thread interface is not currently configured or operational.

I created https://github.com/CHIP-Specifications/connectedhomeip-spec/issues/6153 to track the spec change.
The PANID description bug is an interesting observation as well.

Closing this, given the spec issue is tracking this now.


Creating Control Logic and UI

3 commits including:

Deleting non relevant HTML templates
Updating all models to support Control Logic
Creation of Control Logic and UI

tests?

tests?

Tests will be added today and tomorrow by Assaf and Shay

I know you put effort into this
so
approving even though, it was really preferable to have tests within the same PR


Unable to move mesh elements into separate files for reusability (IDFGH-10805)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
I have the following code:
// note: this implicity defines onoff_pub_0 as a static
ESP_BLE_MESH_MODEL_PUB_DEFINE(onoff_pub_0, 2 + 3, ROLE_NODE);
static esp_ble_mesh_gen_onoff_srv_t onoff_server_0 = {
    .rsp_ctrl.get_auto_rsp = ESP_BLE_MESH_SERVER_AUTO_RSP,
    .rsp_ctrl.set_auto_rsp = ESP_BLE_MESH_SERVER_AUTO_RSP,
};

// ...

static esp_ble_mesh_model_t root_models[] = {
    ESP_BLE_MESH_MODEL_GEN_ONOFF_SRV(&onoff_pub_0, &onoff_server_0),\
    // ...
};

I'd like to be able to isolate these definition into separate file, and root_models in a separate file (to allow for reusability of code), but I can't seem to get around accessing static variables from another file (and yes, I've read a lot of posts on StackOverflow about using statics in C for encapsulation)... Is there any better option when the library I'm using implements static variables in their macros?
FYI, here's a more complete example if someone wants to propose a more general architecture approach...

I am not able to understand what we want to achive here.


Tox has a hidden failing testcase with no Exception Caught

Currently when running tox on main:
$ tox -e py3
there is one failing testcase without a caught exception. This potentially leads to tox passing successfully when it should not.

Closing this issue. The above failure is an expected failure from pytest for the compute_create_address() helper function:


Connect server to server with docker

Dual to the budget and the architecture I can not apply this to the project


Test for segfault in factorize (gh12666)

[x] closes #12666
[x] tests added / passed
[ ] passes git diff upstream/master | flake8 --diff

Not sure about the last. It's my first PR.

Current coverage is 85.26% (diff: 100%)

Merging #14112 into master will not change coverage

@@             master     #14112   diff @@
==========================================
  Files           139        139
  Lines         50502      50502
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits          43062      43062
  Misses         7440       7440
  Partials          0          0

Powered by Codecov. Last update 8d1646c...8a6ab59

thanks!


[Feature Request] Support fabric?

As Quilt diverges we'll eventually need to instead support Quilt if we tried to support Fabric at first.
We could support Fabric, but it'd mean depending on a different API that Quilt might not support in the future.
We could totally do it, we just didn't see the point as it was a fun personal project that we wanted on our own server, if the mod gets more traction we'll do it.

I see, thank for your response


Handle EXTRACT elements containing more complex child elements

This means elements that cannot be expressed using only inline Markdown, for example, EXTRACT elements containing GPOTABLE elements.
Overload node_type to include lower-level semantic information about the node, in this case that the node is an extract. regulations-site will need to be adjusted accordingly.
Remove the approach of surrounding the extract nodes with Markdown code delimiters, as this will be handled by node_type instead.

Addressed in pull 104.


Open Seating

In our office, we have several areas with open seating, which results in multiple employees having the same location in Azure, for example, L1-OPEN. Will this cause problems mapping locations? I'm able to import my file, and it claims it has a people count of 30, but it does not work.  "In the floor plan, the office locations must be unique and cannot repeat. For example, if two people share office 2/1173, 2/1173 can only have one unique instance in your floor plans, but the user accounts in Azure AD will both have the same office location."

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

ID: bc0c9359-bfda-34f9-4cd5-4522751cc986
Version Independent ID: 1a13448f-3931-c2e8-362f-26fc6d13d594
Content: Manage floor plans
Content Source: MicrosoftSearch/manage-floorplans.md
Service: mssearch
GitHub Login: @rasrivas
Microsoft Alias: rasrivas

Hi Heidi,
Gentle ping. Did you get a chance to submit the feedback?
Thanks,
Rahul

Hi Ruhal!
Yes, I did it the same day you posted the suggestion. I currently have an open ticket with support on the issue.
Thanks for your assistance, much appreciated.
Heidi

The issue turned out not to be related to the open seating. Microsoft was able to fix something on the back end that un-stuck the import and got things working. All is now good and my imports now show the correct number of seats and work grand.

Great. Should we consider this issue resolved?


Add unawaited to package:meta.

Adding a nicer-looking way to suppress the unawaited_futures lint, so we can enforce it.
Once this is in and published I'll send a PR updating the lint description to point to this new way of suppressing the lint
https://github.com/dart-lang/linter/compare/master...davidmorgan:document-unawaited-futures

This marks an interesting departure. Prior to this the meta package only defined top-level constants and classes that were intended to be used as annotations (or "metadata", hence the package name). If this is accepted, then we are not only extending the content of the package to include top-level functions, but, more importantly, we are creating a precedent of using no-op functions to annotate expressions. I think we want to think carefully about creating such a precedent.
@leafpetersen @lrhn @eernstg Given that the language does not allow annotations to be associated with expressions (or statements, or anything other than declarations), what are your thoughts on using functions to annotate expressions?
If we decide to add this function, we might also consider putting it and any similar future functions in a separate library.

Thanks. For context, see discussion on<EMAIL_ADDRESS>The other option considered was using a comment:
/* unawaited */ doSomethingAsync();

But there seemed to be slight preference for a function. package:meta seems the logical place, since it's effectively an annotation. (Note however that we don't have to do anything special with it; you can use any function like this from any package and it will silence the unawaited_futures lint).

Wow, that's a long thread.
I don't like the idea of a second comment-format for ignoring hints. Such "enhancements" tend to multiply to the point where they become unusable.
Given that there are other functions already being proposed, I'd really like to see them in a separate library, perhaps one dedicated to support (functions or annotations) related to dart:async.

Yes, it's a hot topic :)
The other suggested methods were unsafeCast, which would signal to compilers that they're allowed to omit a type check, and allowDynamicCall, which turns off the --strict-dynamic-calls check. Ignoring the details of these proposals, it's not clear to me where we'd put them, or things of the same type, if not in package:meta. So I think the proposal is explicitly to expand the scope of package:meta to include functions acting as annotations. @matanlurey
(I hadn't actually worked out that the name meta refers to annotations, I'd always understood it in a more general sense.)

The other suggested methods were unsafeCast, which would signal to compilers that they're allowed to omit a type check, and allowDynamicCall, which turns off the --strict-dynamic-calls check.

Oh, well, that's likely to be a whole other ball of wax. There has been strong opposition in the past to putting anything that controls the behaviors of the various compilers anywhere other than in the dart: libraries. I'll be surprised if that sentiment has changed.
Of course, unsafeCast might just work like unawaited in the sense that it's use effective accomplishes the goal without any need to change the compilers.

@bwilkerson:

Such "enhancements" tend to multiply to the point where they become unusable.

Luckily the lint is already unusable today (internally), so this makes it usable! If the trade-off is that we need to add a no-op function into a package whose goal is entirely to allow different types of static analysis, so be it?
@bwilkerson:

Putting it and any similar future functions in a separate library.

@davidmorgan:

So I think the proposal is explicitly to expand the scope of package:meta to include functions acting as annotations

I don't know anywhere there is a rule written that package:meta is constrained to just annotations. It's pretty ... meta to try to set strict guidelines on what is meta, no? I don't believe this hurts users not interested in these functions.
@bwilkerson:

Oh, well, that's likely to be a whole other ball of wax. There has been strong opposition in the past to putting anything that controls the behaviors of the various compilers ...  I'll be surprised if that sentiment has changed.

There is already such configuration in package:meta:
https://github.com/dart-lang/sdk/blob/master/pkg/meta/lib/dart2js.dart
But as you mentioned, neither unsafeCast nor allowDynamicCalls actually change compiler behavior. They are both no-op functions that allow more strict types of static analysis to take place (ban implicit casts, ban dynamic calls, respectively).

Such "enhancements" tend to multiply to the point where they become unusable.

Luckily the lint is already unusable today (internally), so this makes it usable! If the trade-off is that we need to add a no-op function into a package whose goal is entirely to allow different types of static analysis, so be it?

I'll note that by "enhancements" I was referring to additional comment structures, not functions. I don't want analyzer to have to try to interpret lots of different comment structures, nor have to worry about possible conflicts with comments that were not intended to suppress errors but happen to do so.

Putting it and any similar future functions in a separate library.

I don't know anywhere there is a rule written that package:meta is constrained to just annotations.

So, again, I never claimed that there's any rule. I was merely noting that this is a change from what we have accepted into the package before. I didn't even claim that the change was bad, only that I thought it was worth thinking about before accepting it.
Also, note that I said "library", not "package". We already have multiple libraries in the package, and I think it's worth considering whether we want this function to be in a separate library.
(And while it's not a rule, I will point out that the README states:

This package defines annotations that can be used by the tools that are shipped with the Dart SDK.

so we might also want to expand the README if we're adding this.)

@bwilkerson:

I don't want analyzer to have to try to interpret lots of different comment structures, nor have to worry about possible conflicts with comments that were not intended to suppress errors but happen to do so.

I thought the point of the linter was to do extra analysis you didn't want on (by default). It seems reasonable that if we opt into unawaited_futures, we'd do this analysis. If we need to fork the rule (unawaited_futures_google), I'd be open to that as well (/cc @davidmorgan) but it would be unfortunate.

So we might also want to expand the README if we're adding this.)

I'd be very happy to help expand the README.

We're obviously not communicating well :-) Apologies for my part in it. I'll try again to be clear.

I don't want analyzer to have to try to interpret lots of different comment structures, nor have to worry about possible conflicts with comments that were not intended to suppress errors but happen to do so.

I thought the point of the linter was to do extra analysis you didn't want on (by default). It seems reasonable that if we opt into unawaited_futures, we'd do this analysis. If we need to fork the rule (unawaited_futures_google), I'd be open to that as well (/cc @davidmorgan) but it would be unfortunate.

Yes. The point of the linter is to do extra analysis that should be optional. Yes, if a user opts into a lint rule then the lint should run. But that's not what I'm talking about.
I was assuming a familiarity with the implementation that might not exist. We have architected the linter in order to attempt to make it as easy as possible to write lint rules. One aspect of that was a decision to not require lint authors to be concerned with whether their lint is being ignored in some location. The whole "ignore" comment mechanism is handled as a post-processing step. Lint authors generate all lints and the linter framework weeds out the ones that shouldn't be reported.
I don't want to ask lint authors to add code to check whether there is a special comment that disables their lint. But I also don't want to try to teach the linter framework about a large number of possible comment contents that should disable specific lints. There are several negatives to either approach, and I don't think either would be a positive change to the lint ecosystem.

There is already such configuration in package:meta:
https://github.com/dart-lang/sdk/blob/master/pkg/meta/lib/dart2js.dart

I missed commenting on this the first time, but I think it's important to clear up a potential misunderstanding.
That library is not used by dart2js.
The meta package was created by the analyzer team in order to define annotations (or functions, or whatever) that are used by the analyzer to provide additional hints or lints. The annotations in that library are specifically designed to provide additional analysis for users writing code that is expected to be compiled by dart2js. But dart2js does not use those annotations.
As long as none of the backends (other than analyzer) need to have special knowledge of the functions that are being proposed, then there won't likely be any push back.
But that is one of my concerns (though previously not explicitly expressed): the analyzer doesn't need to know about these functions either. The function unawaited could be defined anywhere and still have the effect of disabling the lint. The unsafeCast is the same way.
I would like to preserve the use of the meta package for things that are used by the analyzer. I understand the convenience argument, and I'm not necessarily saying "no", but I really don't want this package to be a catch all for things not needed by the analyzer. The unsafeCast function seems like a good example. Analyzer doesn't produce the error being avoided, so the meta package doesn't seem like the right place for it.

@bwilkerson:

We're obviously not communicating well :-) Apologies for my part in it. I'll try again to be clear.

No worries. We've tried to be very transparent and have lots of discussions in the open internally in dart-lints@ - it's impossible to make every internal discussion public - so please let us know if there is a better way to have internal-specific discussions with your team. I think dart-lints@ works well?

I don't want to ask lint authors to add code to check whether there is a special comment that disables their lint. But I also don't want to try to teach the linter framework about a large number of possible comment contents that should disable specific lints.

I totally understand this requirement. I have two ideas/points:

We already ask lint authors to add code to check for certain code to disable specific lints, that's called writing the lint 😏 - there are always cases that lints ignore and cases that lints lint, and sometimes we even split into multiple lints because it's not clear what cases should or should not be covered by a specific lint.

I would be open to, but regret, forking the linter project, and having one that complies more with internal Google requirements, but as a result, is harder to contribute to. We're trying to avoid that, though.

But dart2js does not use those annotations.

 Dart2JS does check for the existence of those annotations to compile differently. But maybe the wording I am looking for is utilizing and not using?

As long as none of the backends (other than analyzer) need to have special knowledge of the functions that are being proposed, then there won't likely be any push back

I talked at length about this with @dgrove @leafpetersen and @vsmenon already before suggesting these changes, and I did not get any pushback. If there is anyone else you feel I should try and reach out to/convince I'm happy to spend the time.

... [but] the function unawaited could be defined anywhere and still have the effect of disabling the lint. The unsafeCast is the same way

I guess I misunderstand, the idea was to statically check that unawaited is defined in package:meta/meta.dart (or wherever it goes), not just an arbitrary function called unawaited.

The unsafeCast function seems like a good example. Analyzer doesn't produce the error being avoided, so the meta package doesn't seem like the right place for it.

We can track the requirements for specific functions (like unsafeCast) elsewhere, but the idea here is just that is an allowed implicit cast. That is, you could use --no-implicit-casts, and still do an implicit cast if its done through a unsafeCast.
(Whether Dart2JS decides to emit different code in an unsafe/non-spec mode for that function is an entirely different discussion unrelated to this request or the analyzer)

I think dart-lints@ works well?

Unfortunately, I'm not subscribed to that group. I don't have time to engage in all of the conversations there. I do care about the linter, but most of the conversations appear to revolve around whether and how to use existing lints. When the conversation changes to one about how to change the lints, linter, or meta package, then perhaps the analyzer team could be looped in.

We already ask lint authors to add code to check for certain code to disable specific lints ...

Sure, but I'm talking about a different kind of checking. At least in my mind they are different in significant ways.

But dart2js does not use those annotations.

No, I was just mistaken. Your comment prompted me to look again at the library, and I'm saddened to see that it isn't what I thought it was. The annotations do appear to be applicable only to dart2js and to have nothing to do with analyzer. Sigh.

... [but] the function unawaited could be defined anywhere and still have the effect of disabling the lint. The unsafeCast is the same way ...

I guess I misunderstand, the idea was to statically check that unawaited is defined in package:meta/meta.dart (or wherever it goes), not just an arbitrary function called unawaited.

As David already pointed out:

(Note however that we don't have to do anything special with it; you can use any function like this from any package and it will silence the unawaited_futures lint).

Analyzer won't care where the function is defined or what it's name is. The lint looks for expression statements within an async method where the type of the expression is Future. The proposed function has a return type of void, and that's all that's needed to disable the lint. Any function from any library that does not return Future could perform the same function.
I believe that unsafeCast is the same way. I think that anyone could write a generic function that encapsulates the cast and it would stop the CFE from reporting an error at the site of the invocation of that function. The CFE won't need to care what the function is named or where it was defined.

@bwilkerson:

When the conversation changes to one about how to change the lints, linter, or meta package, then perhaps the analyzer team could be looped in.

OK. We are hoping to keep the current processes pretty lightweight. If you have any feedback on how we could loop in your team more appropriately - neither too much nor too little I guess is the request - then @davidmorgan can definitely keep those ideas in mind!

Thanks Brian, Matan. I'll try to loop in people from the analyzer team on lint discussions when we start talking about changes to lints, that makes perfect sense.
Brian, thanks for clearing up "library" vs "package", I also got confused on that point. I currently think package:meta is the right package for unawaited, although I'm open to other suggestions. I'm not too worried about which library it ends up in, but I'm not sure I see a strong case for a new library, either.
It is true that the analyzer does not need to know about unawaited, but there is a dependency of sorts: the linter docs and the lint message itself will need to refer to it, making it the recommended way to suppress the lint. Here's a preview of what that could look like:
https://github.com/dart-lang/linter/compare/master...davidmorgan:document-unawaited-futures
So in my mind even though it's a no-op, and could be defined anywhere and everywhere, it is part of the linter API.
Brian, do you have any suggestions for making progress on the PR, please? I agree that it needs careful consideration--it looks like you pinged various people who might weigh in but they do not seem to have done so yet :)--if the next step is to get feedback from them then I'll ping them.
That said, I'm completely open to take a step back and considering other options. My impression was that the discussion had reached the bikeshedding stage and it was time to send a PR, but that may have been premature.
I've updated the PR: updated README.md, added 'import dart:async', and changed the Future<Object> arg to a Future<void>.
Thanks!

That said, I'm completely open to take a step back and considering other options.

Thanks! I really appreciate that.
I can understand why this method could look like it's strongly related to the linter, but the more I think about it the more convinced I am that we don't want functions like unawaited or unsafeCast to be in the meta package. I really think they belong in a separate (as in new) package. (I'm not sure what to call the new package, but that's because I'm not sure how to characterize what will go in it. Right now we're effectively talking about functions that get around limitations in the type system, but that seems like too narrow a definition for a package :-)
As for documentation for the lint, I'd probably say something like:

Fixing Violations
There are two common ways to fix a violation of this lint.
The first, and usually best, is to add an await before the flagged expression. This will change the semantics of the code by causing the code following the flagged expression to wait until after the future has been completed, but that's typically the semantics you want (and what this lint was designed to catch).
The second is to wrap the expression in the invocation of a function that does nothing other than accept a Future and return void. The function unawaited, defined in package:newPackage/async.dart is an example of such a function. This should only be done if you really want the computation of the Future's value to occur at an unknown time relative to the code following the flagged expression.
Of course, you can also, as always, add an 'ignore' comment to suppress the violation.

That makes it clear that there's nothing special about unawaited other than its signature. (And the lack of anything special about the function is one of the reasons I think it should not be in the meta package.)

Thanks Brian. That's certainly an option. My main worry is that if we set the barrier to adoption too high, people will just use // ignore comments. Learning about a new package just to avoid // ignore might be asking too much. Adding a dependency on a package is already quite a lot to ask, I think, and because of that I wasn't really a big fan of using package:meta in the first place. I'm looking for the least worst option at this point :)
In the SDK it would be much more accessible/usable, but I don't want to go down that route because I think that if/when it does make it into the SDK it should be as a keyword, not a function. If we add a function to the SDK it'll be a lot more work to clean up later than if we add it to a package. I could be persuaded on this, but I don't think there is much enthusiasm for adding this sort of thing to the SDK anyway.
One option we didn't yet consider is to just define unawaited inline where it's needed. This is the same line of code count as adding the import, and avoids adding a dependency :/ ...
If that sounds ridiculous as a means to avoid writing '// ignore: unawaited_futures', maybe it is. But there are a few good reasons we don't want people to do that:

The 'ignore' format is brittle; it has to be on the exact line before or as a suffix on the exact line where the warning would occur; for multi-line statements this can be awkward; and it can be broken by whitespace changes.
There is no indication as to which lints are okay to ignore. For almost everything we're going to end up enforcing in google3, we don't expect any false positives. So we don't want to train people to use '// ignore'.

Maybe another way to approach this would be to ask: can we create a better story for all the lints that we know have false positives?
Any ideas greatly appreciated ;)

My main worry is that if we set the barrier to adoption too high, people will just use // ignore comments. ... I'm looking for the least worst option at this point :)

That's a valid concern, but even putting it in meta won't guarantee that people will add a dependency on meta rather than adding a comment.
But from my perspective, adding it to meta is also a significantly bad option. :-)

... I don't think there is much enthusiasm for adding this sort of thing to the SDK anyway.

I agree, it seems unlikely that we could add it to the SDK.

One option we didn't yet consider is to just define unawaited inline where it's needed.

I believe this was mentioned in the other thread, but you could write
var _ = futureValuedFunction();

It has the advantage that it will often not add any lines to the code and should be fairly easy to spot in a code review (maybe even easier than unawaited(futureValuedFunction())).

The 'ignore' format is brittle ...

Yes, it is a bit. We discussed the format for a long time and eventually settled on this as a "least bad" option. But I'm happy to re-open the discussion if you have a better alternative.

There is no indication as to which lints are okay to ignore.

True. I suppose we could entertain the notion of an extended syntax for lints that allows users to specify whether a lint is ignorable, and then produce a hint if there is an ignore comment for an un-ignorable lint.

Maybe another way to approach this would be to ask: can we create a better story for all the lints that we know have false positives?

I think that's a great question to ask. I don't know that I have any answers to offer, but maybe others do.

Thanks. Let me throw it back to the (internal) gallery...

Perhaps add some or all of the analyzer team to the mailing list?

I believe this was mentioned in the other thread, but you could write
var _ = futureValuedFunction();

It has the advantage that it will often not add any lines to the code and should be fairly easy to spot in a code review (maybe even easier than unawaited(futureValuedFunction())).

This doesn't scale well when there are multiple calls that aren't awaited.
var _ = returnsFutureString();
_ = returnsFutureInt();

Static error, can't assign Future<int> to Future<String>
Future _ = returnsFutureString();
_ = returnsFutureInt();

Noisier and adds ceremony when refactoring code - remove the call to returnsFutureString() and need to touch unrelated lines to move the variable declaration.
var _1 = returnsFutureString();
var _2 = returnsFutureInt();

Pretty ugly...

I agree it's ugly. I did realize after writing that that if we were going to use this trick (which I don't think we are) that we should use void rather than var.

My preference would be to put such functions (used to silent linter warnings) directly in the linter package. That means that devs would have to add a linter dev_dependency in their pubspec.yaml (but if/when linter package becomes an analyzer plugin it would be the same thing).

My preference would be to put such functions (used to silent linter warnings) directly in the linter package.

I should have say: in the linter repository . So there will be 2 packages : the current linter and a new linter_helper (or something like that).
My point was that code used only to silence lints should be really close to the code defining the lints.

I'm not sure why. Most of the functions being discussed do not need to be known to the linter. Instead, they work by changing the static type information in such a way that the lint simply won't fire. Hence, there's no reason for them to be in the linter's repo.

Indeed, some of the contents of the package (i.e. around dynamic calls) are unrelated to the linter.

Closing this PR in favour of creating a new package. Thanks everyone!

(Just coming back from a nice vacation ;-) I can see that this issue was just closed, but here's my response to a question that was raised here:

@leafpetersen @lrhn @eernstg Given that the language does not
allow annotations to be associated with expressions (or statements,
or anything other than declarations), what are your thoughts on using
functions to annotate expressions?

In the concrete examples that I've gleaned from this long thread, it seems that the need for declaring an expression to be 'unawaited' may be caused by questionable design choices elsewhere. Here's an example that was given to show what we might do when we don't want to await a future:
/* unawaited */ doSomethingAsync();

In the case where doSomethingAsync was designed to be a fire-and-forget action, it should have had return type void in the first place.
A fire-and-forget action should have some semantic encapsulation property (as in "this invocation will do things asynchronously, but nobody else depends on those things being completed", e.g., because it's writing to a finite logging buffer and it might take time until the logging process makes room for more data—but nobody else in this process depends on that). Conversely, if doSomethingAsync does work that any caller whatsoever may need to await the completion of then it is a delicate and error-prone choice for a particular call site to ignore (and "unawait") the returned future. This means that it should be a property of the callee whether the action is fire-and-forget, not a property of the call site.
So, ideally, there aren't any of these call sites because fire-and-forget async functions will have return type void, and expressions with static type Future<T> for some T should be awaited. Every time.
Not so ideally there will be exceptions, but if we can make them rare then there is no need to work really hard to make them concise or convenient—in which case an // ignore: unawaited_futures comment seems OK to me.
For the general question about using functions to annotate expressions: I suspect that it wouldn't be very good for the overall readability of the code (and I don't know whether we can rely 100% on compilers to inline those functions, so they may also cause some overhead at run time).
So if we can't avoid having them, it would at least be nice if we could use some naming convention to make them stand out as "not a real function call, just an annotation", say lintIgnore_UnsafeCast(e).
But my primary recommendation would be to use // ignore comments also for expressions (maybe by declaring fresh local variables in order to be able to associate a specific expression with such a comment), and then strive to keep the rest of the ecosystem in a good shape such that this kind of exception isn't needed very often.

Well, specifically for this case, we do mean // ignore: unawaited_futures. But the problem in telling people they should use that (i.e. creating a workflow where it's expected) is that they may then also think it's okay to write e.g. // ignore: unused_imports, and we'd really prefer they didn't.

they may then also think it's okay to write e.g. // ignore: unused_imports, and we'd really prefer they didn't.

Now you need a new lint only_ignore_lints :)

// ignore: ignore.  All the ones we've enforced so far, for example:
https://github.com/dart-lang/linter/blob/master/example/google.yaml


Move s3_dst config to top level config

Description of proposed changes
Nested configs for s3 URLs are challenging to override by the Snakemake --config option, as discussed in the following comment:
https://github.com/nextstrain/dengue/pull/13#discussion_r1361131210
This moves the url to the top level as a s3_dst config value, and propagate those changes to the relevant Snakefiles.
It's important to note that I haven't conducted thorough testing, and there may be nuances in the implementation meant by the comment. Suggestions or clarification welcome.
Additionally, I was unsure regarding whether the s3_dst config should be a required value or an optional default (Snakemake styleguide: config values).
Related issue(s)

https://github.com/nextstrain/dengue/pull/13#discussion_r1361131210

Checklist

[ ] Checks pass

Since we can use: --config upload='{"s3": {"dst": "NEW URL"}}'
https://github.com/nextstrain/dengue/pull/13#discussion_r1375081279
This PR is no longer necessary.


Check if the drawer is open before responding to escape keystrokes.

Currently the escape key can not only close but also re-open the drawer, which makes no sense to me.

LGTM. Good catch.
However, this should go into the mdl-1.1 branch instead of master to make the next patch release.

LGTM2.

@Garbee Do I need to close this and create a new PR targeting the mdl-1.1 branch or is there another way around?

I see quite many differences between master and mdl-1.1. I should rebase the changes onto mdl-1.1, correct?

You will be best off closing. Then doing a new local branch off mdl-1.1 and then redoing the changes.


Bug: When update nested array of object

for test reason, I have such a model:
Items = new Mongo.Collection('items');

Item = Astro.Class({
    name: 'Item',
    collection: Items,
    fields: {
        subItems: {
            type: 'array',
            nested: {
                name: 'SubItem',
                fields: {
                    subItems: {
                        type: 'array',
                        nested: {
                            name: 'SubSubItem',
                            fields: {
                                images: {type: 'array', nested: 'string', default(){return []}},
                                image: {type: 'string'}
                            }
                        }
                    }
                }
            }
        }
    }
});

while I can insert correctly: Item.insert({subItems:[{subItems:[{images:['1']}]}]})

I can't update it correctlly: Item.update('hFM2u6vBdt2r9qbc3', {$set:{subItems:[{subItems:[{images:['2']}]}] }})

You have to have an error somewhere in your code. Create a reproduction. If I use the following code, it works:
Items = new Mongo.Collection(null);

Item = Astro.Class({
    name: 'Item',
    collection: Items,
    fields: {
        subItems: {
            type: 'array',
            nested: {
                name: 'SubItem',
                fields: {
                    subItems: {
                        type: 'array',
                        nested: {
                            name: 'SubSubItem',
                            fields: {
                                images: {type: 'array', nested: 'string', default(){return []}},
                                image: {type: 'string'}
                            }
                        }
                    }
                }
            }
        }
    }
});

Item.insert({subItems:[{subItems:[{images:[1]}]}]});
var item = Item.findOne();
Item.update(item._id, {subItems:[{subItems:[{images:[2]}]}]});

sorry, but your code doesn't work, your update modifier is wrong. In meteor, you must use $set or something else, but you can't just replace the doc.
here is the result of your doc. note the update has no effect:

Sorry I've pasted wrong code

Oh yes even by fixing code, it does not work properly. I haven't noticed that the problem is about how data is stored in most nested field. I will have to investigate it further.

Ok it will be fixed in 1.2.1 which is going to be publish today

thanks


DUPLO-18931 Data source duplocloud_k8_secrets mask non read only user secrets

Overview
Fixed masking bug for secret readonly for non readonly user for  duplocloud_k8_secrets data source
Summary of changes
This PR does the following:

removed line that sets user_readonly flag which overrights actual state
fixed secret_annotations set issue

Testing performed

[ ] Using unit tests
[ ] Manually, on my local system
[✓ ] Manually, on a remote test system

Describe any breaking changes

...

Task linked: DUPLO-18931 TF Provider: Data source duplocloud_k8_secrets mask non read only user secrets


Notify trade partner the action and reason when the offer has been handled

Describe the feature you'd like

The bot should notify the trade partner when it accepts / declines / skips the offer, and why it did it.

Could simply send a message inside the applyActionToTrade function
https://github.com/Nicklason/tf2-automatic/blob/f066b89621f0242f9c9adee13e529b75bab92722/src/classes/Trades.ts#L288-L319


Preview image not showing...

Hello, i found recent problem, when im about to create new world and to customize, the preview doesn't want to show.
Here's screenshot exactly what i mean:

I have the same issue but after changing the preview mode a few times it shows up.

Simply pressing New Seed should do it for now. This behaviour wasn't intended though

Addressed in 0.0.6


DG Appendix: Manual Testing

This is branched from https://github.com/AY2122S1-CS2103T-W08-3/tp/pull/282, so there are a lot of overlapped changes.
So merging #282 before this will make this easier.
All new changes in this PR are in the DeveloperGuide.md.

Codecov Report

Merging #286 (c2ce52d) into master (47e934c) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #286   +/-   ##
=========================================
  Coverage     66.27%   66.27%
  Complexity      837      837
=========================================
  Files           135      135
  Lines          2758     2758
  Branches        333      333
=========================================
  Hits           1828     1828
  Misses          815      815
  Partials        115      115

Impacted Files
Coverage Δ

...rc/main/java/seedu/address/model/ModelManager.java
66.91% <0.00%> (ø)

...java/seedu/address/logic/commands/HelpCommand.java
100.00% <0.00%> (ø)

Continue to review full report at Codecov.

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

I suggest you add 2-3 more cases for manual testing or provide a more general guide for the testing. Thanks.

Note that corrupting salesBook.json will start with empty data. It will wipe the data in addressBook.json. This is the behaviour, although unexpected.
Output in command prompt:

(continued)

Note the last WARNING.


Documentation link is broken

https://web.archive.org/web/20150912005358/http://www.bdmg.com.ar/?page_id=176


[6.0] [Index] Mark accessors as implicit in modules

6.0 cherry-pick of #74991

Explanation: Marks accessors as implicit in indexed modules
Scope: Affects the indexing of accessors in modules
Issue: rdar://130775560
Risk: Low, the change is very straightforward and only affects the index
Testing: Added tests to test suite
Reviewer: Ben Barham

@swift-ci please test


Other drivers

Hello.
How can I add new driver, for example Vertica driver?
Is it possible?

This bundle only implements the Eloquent ORM in Symfony. It does not cover Eloquent ORM development. Please contribute to Laravel directly (https://github.com/laravel/framework).


kubernetes: 1.28.4 -> 1.28.7

Description of changes

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Perhaps superseded by #274635?

@wegank indeed yes. Let's go with 1.29.x

However it might be a good idea to backport the latest 1.28.x to stable


Support Invoices recognition for Form Recognizer

TODO:

Add samples

Add testing

Closing this in favor of https://github.com/Azure/azure-sdk-for-java/pull/17167. Moving to feature branch.


Fix wrong installation instruction

the rpc-server bin is now located in sui-gateway, the doc was mistakenly installing sui-json-rpc crate

To be clear, @patrickkuo, we should still list the binary as rpc-server in the install doc, correct?

To be clear, @patrickkuo, we should still list the binary as rpc-server in the install doc, correct?

the binary name is still rpc-server

To be clear, @patrickkuo, we should still list the binary as rpc-server in the install doc, correct?

the binary name is still rpc-server

Thanks for confirming!

can someone double check on this? I believe something similar has resurfaced.

can someone double check on this? I believe something similar has resurfaced.

the binaries installation command works on main branch e.g. cargo install --locked --git https://github.com/MystenLabs/sui.git sui sui-gateway
We are still fixing some issue so still haven't merged the latest to devnet branch.
@Clay-Mysten As merging main to devnet is happening not as quick as we like, I think we are now accepted we will need separated doc site for main and devnet? We will need to have different installation command for different env...

can someone double check on this? I believe something similar has resurfaced.

the binaries installation command works on main branch e.g. cargo install --locked --git https://github.com/MystenLabs/sui.git sui sui-gateway We are still fixing some issue so still haven't merged the latest to devnet branch.
@Clay-Mysten As merging main to devnet is happening not as quick as we like, I think we are now accepted we will need separated doc site for main and devnet? We will need to have different installation command for different env...

Agreed. @Jibz1 and I met yesterday on the topic, and we are working toward distinct versions of the site per branch. See:
https://github.com/MystenLabs/sui/issues/1244#issuecomment-1164625717


Bump up preflight tool version to 1.9.2

All Submissions:

[ ] Have you signed our CLA?
[ ] Put closes #XXXX in your comment to auto-close the issue that your PR fixes (if there is one).
[ ] Update docs/release-notes/release-notes-template.md if your changes should be included in the release notes for the next release.

Is this needed for the release or unrelated?
Why do we need it now?

Is this needed for the release or unrelated? Why do we need it now?

Yes, the preflight-tool is outdated: Error: could not submit to pyxis: could not create test results: status code: 400: body: {"type": "about:blank", "title": "Bad Request", "detail": "Validation error: 'github.com/redhat-openshift-ecosystem/openshift-preflight' version '1.9.1' is not supported. Supported versions are: ['1.9.2', '1.9.4']", "status": 400, "trace_id": "0xa1aabed1b8c70960041f62de7632cfb4"} 2024/05/08 17:46:34 could not submit to pyxis: could not create test results: status code: 400: body: {"type": "about:blank", "title": "Bad Request", "detail": "Validation error: 'github.com/redhat-openshift-ecosystem/openshift-preflight' version '1.9.1' is not supported. Supported versions are: ['1.9.2', '1.9.4']", "status": 400, "trace_id": "0xa1aabed1b8c70960041f62de7632cfb4"}


compose: Add url to 'scroll down' sent banner.

Fixes #19857.
This notification ("scroll down to view your message" with a link
for the user to click to scroll down) was added in e2c388c and
removed in 657e1f1 in a commit almost immediately afterwards.

Later the notification was added again, but there was notably no
link to scroll, just the message to scroll down. 372cb20

The link to scroll down was "added" in 1a63c2d when it was fixing
a similar link in another notification. But the implementation
didn't actually use the link (because there was no classname passed
through).

The first commit commit adds a classname so that the link is clickable by
the user.

--
Previously the message would disappear after 300ms, but it can be
annoying for a useful link to disappear so quickly like that.

This commit removes that logic. Now the banner is closed only when
the user explicitly closes it or clicks on the link.

Note that the banner doesn't go away if the user manually scrolls
down. I still think this change is overall better, but if there's
an easy way to add that as well we should do it!

Since there are no existing tests for out-of-view-notification, I didn't spend time setting that up in this PR.

Just to make sure we didn't accidentally lose something, what is this banner, and why was the link removed?

It looks like this notification -- "scroll down to view your message" with a link the user to click to scroll down -- was added in e2c388c49c6b6c4c3b51f3975d0e3cef55f20683 and removed in
657e1f1f9afee946420f187ad5acd35d7cec7f6e in a commit immediately, both in 2013. But the click handler was never removed, and this PR removes it.
Later the notification was added again -- "Sent! Scroll down to view your message." but there was notably no clicky-link to scroll, just the message to scroll down. 372cb20f9ede094f5a9e5e3c53494a63cf9305af
The link to scroll down was "added" in this commit 1a63c2d187c8558a6cebd1715a67d12fefe6effc when it was fixing a similar link in another notification. But the implementation didn't actually use the link (because there was no classname passed through) so the link wasn't used. This PR removes it.

Hm, so did we actually intend to link it in https://github.com/zulip/zulip/commit/1a63c2d187c8558a6cebd1715a67d12fefe6effc? Looking at that banner, it seems very sensible for it to be a link, so I'm wondering if that's actually the right fix here.
@timabbott What do you think?

Reading the commit message for https://github.com/zulip/zulip/commit/1a63c2d187c8558a6cebd1715a67d12fefe6effc, it sounds much more like that accidentally broke the link than that it intended to remove it, so I'd propose we resolve this bug by restoring the link.

I think the link never worked since 2013. I started a conversation on CZO for it https://chat.zulip.org/#narrow/stream/6-frontend/topic/scroll.20to.20bottom

PR has been updated to keep the banner and add the url, after discussion on CZO

Great! Could you please post an updated screenshot?

The banner not disappearing when you scroll to the bottom seems annoying, and I think it's not hard to change.
I would look at unread_ops.process_scrolled_to_bottom for how to trigger a hook when we get there. It's probably a horrible abstraction violation to just call this from there, but maybe one can do a hook that calls message_viewport.bottom_message_visible in the scroll handler.
I'm not sure if that function is cheap enough that it's important to avoid calling it twice, but it might be. Perhaps a prep refactor in this PR could move the message_viewport.is_visible_and_focused check into process_scrolled_to_bottom and then we could call that directly? Idunno, needs study.

@evykassirer Looks like my comment above was missed as well.

@timabbott made an update to address that
@alya screenshot posted!

Thanks!
The x in dark theme doesn't look right to me. Is this what was intended?

Also, not a blocker for merging this, but for @terpimost to take a look at -- links in dark theme seem hard to read to me on this one:

Works for me in manual testing other than that!

Ah, right, I the x is the same as in main. Re-adding the "integration review" label.

I noticed that the link here was to a conversation view for the message you sent -- but the label and click handler do "scroll to bottom". I added a bonus commit to remove the URL from the link -- so it's now just an a element that scrolls you to the bottom on click, as expected.
Otherwise this looks good to me; I especially appreciate the fact that we're doing a clearly very cheap outer if statement in scroll_finished, so we can be confident it'll disappear on scroll without weird overhead in the common case that one of these notices isn't visible.


Enable jwt_claims to header for jwt_based routing

Add the ability to copy jwt_claims to headers to enable jwt_based routing
Description:
jwt_authn_filter
validates jwt tokens and rejects a token if it is invalid. May times we want to route a request at ingress based on the jwt-token presented. For example a claim me be related to canary in which case the user should be routed to the canary backend.
At present this can be done using Lua or a Wasm filter, however this is an often requested feature and makes sense for it to be directly supported.
Options
A: jwt_authn_filter configuration

Add action configuration to the jwt_authn_filter, which will copy claims to a header.
Ensure that the target header is sanitized.
Relies on RBAC to happen afterwards
flush route to generate new route.

B: support jwt-match in http routes

Add nested jwt claims as route matches.
The match will be done on unvalidated claims, which is fine since it will be rejected by jwt later anyway.
This saves us from flushing routes. It makes it equivalent to a client that also populates the said header along with sending the jwt token.

@yangminzhu @kyessenov

For A:  we just add following into JwtProvider:
message PayloadToHeader {
   // it is the path in payload json, such as "a.c"
   string payload_path = 1;

   // the header key
   string header_key = 2;
};

repeated PayloadToHeader payload_to_headers = 13;

bool clear_route_cache = 14;

for A, after the jwt filter clear the route cache, will the request go through the same filter chain again? If so how does the jwt filter know if should not clear the cache again?
for B, the routing part probably still need to validate the token to some extent, sometimes a path is excluded from the JWT so the jwt filter might be configured to bypass validation of it, in that case, the routing should not use any information from the token.
or maybe C: add a metadata_to_header filter, the metadata will only be populated after validation and the filter will be a bit more general, but this has the same drawback for flushing routing.

@yangminzhu if you believe “B” is equivalent to a client also populating the header then there is no validation needed during routing. If a route is not protected then it does not need a validated token. Can you help me understand the failure case?

@yangminzhu clear_route_cache will not cause request to re-pass filter chain.

I like your C:  add a metadata_to_header filter.  So not to put too much specialize code  into jwt_authn.

@yangminzhu if you believe “B” is equivalent to a client also populating the header then there is no validation needed during routing. If a route is not protected then it does not need a validated token. Can you help me understand the failure case?

I was actually thinking the opposite, the use case of routing based on the jwt token that cannot be faked by client side: the routing part checks the token and makes the decision without even validating the token as it relies on the later jwt_authn filter for the validation. Later the jwt_authn filter also bypassed the validation for some reasons (e.g. path is excluded from validation). That's why I mean the routing part should still validate the token to prevent such cases.
If the path excluded from the routing is consisting with the routing, i.e. it is also excluded from the routing, then I guess this is not a big issue because it will not be routed anyway?
Or if you are thinking the use case of routing based on header that could be freely configured by the client, then yes I think this is not an issue. But I'm not sure if that is the use case here? I thought the reason of using JWT token is to prevent such cases.

normally we keep routing, authentication and authorization separate. The client and route is free to request anything they want. Jwt validation filter should be inserted if we want that resource to be protected, and jwt to be validated.
I see your point from an API / user experience standpoint, but XDS api need not be user friendly. we will surely tie it together in the Istio API.
we can leave it to envoy api shepherds if they are ok with including jwt validation config embedded in the route.

We still do need this. Someone from Google will work on it.


2017.1.0p4 Released

Unity Editor 2017.1.0p3 released with Mixed Reality Toolkit Specific Fixes:
(911008) - UWP: Fixed the issue where locking the mouse in UWP player would cause wrong values returned from Input.GetAxis() on the next Update.
(923806) - XR: Fixed an issue where stereo Convergence setting had no actual impact.
(918634) - XR: Added VRUsage parameter to GetTemporary(). This fixes an issue with blitting to a temporary renderTexture.

Unity Editor 2017.1.0p4 released with Mixed Reality Toolkit Specific Fixes:

Editor: Fixed Security Vulnerability UNITY-SEC-844 - https://unity3d.com/security

Unity Editor 2017.1.0p5 released with Mixed Reality Toolkit specific fixes:

(none) - Universal Windows Platform: Fixed building generated UWP projects with Visual Studio 2017.3 when using .NET scripting backend.
(928646) - Windows: Crash dumps are written to users' Persistent Data Path, resolving an issue where installing Unity games to Program Files caused crash dumps to fail.


JWT signing methods

Description
Adds configurable signature algorithm used by GenerateTokenWithClaims(), JWTAuthenticator and JWTController.
Possible drawbacks
None.
Related issue(s)
List all related issues here:

closes #137

Pull Request Test Coverage Report for Build 778273261

108 of 108 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.09%) to 99.027%

Totals

Change from base Build 755675767:
0.09%

Covered Lines:
4171

Relevant Lines:
4212

💛  - Coveralls