Checksum verification failed on Windows 2019 and Windows 2022

Description
Attempted to build both Windows 2019 and Windows 2022 images based on the current repo, but they are both failing with the error below:
==> azure-arm: Checksum verification failed: expected 2655938bc0e94e788b847c45adcc87a8c4afd160294a0f374c7306a1015ec83d300c1092f11f3869
==> azure-arm: 58686b70431cec109257ace163a79551f5be797fb8b6a0ba, got A48E753165286E567507C2C73ABF3C38BB0C50015352424851ADCEE75DD884564
==> azure-arm: C29DC66DC82346E62CD95BDED680D5A6722D12253088B1E6717C0FDE8570042
==> azure-arm: At C:\Program Files\WindowsPowerShell\Modules\ImageHelpers\InstallHelpers.ps1:919 char:9
==> azure-arm: +         throw "Checksum verification failed: expected $expectedHash,  ...
==> azure-arm: +         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
==> azure-arm:     + CategoryInfo          : OperationStopped: (Checksum verifi...717C0FDE8570042:String) [], RuntimeException
==> azure-arm:     + FullyQualifiedErrorId : Checksum verification failed: expected 2655938bc0e94e788b847c45adcc87a8c4afd160294a0f374
==> azure-arm:    c7306a1015ec83d300c1092f11f386958686b70431cec109257ace163a79551f5be797fb8b6a0ba, got A48E753165286E567507C2C73ABF3
==> azure-arm:   C38BB0C50015352424851ADCEE75DD884564C29DC66DC82346E62CD95BDED680D5A6722D12253088B1E6717C0FDE8570042
Platforms affected

[X] Azure DevOps
[ ] GitHub Actions - Standard Runners
[ ] GitHub Actions - Larger Runners

Runner images affected

[ ] Ubuntu 20.04
[ ] Ubuntu 22.04
[ ] Ubuntu 24.04
[ ] macOS 11
[ ] macOS 12
[ ] macOS 13
[ ] macOS 13 Arm64
[ ] macOS 14
[ ] macOS 14 Arm64
[X] Windows Server 2019
[X] Windows Server 2022

Image version and build link
Private builds of Azure DevOps agents based on Windows Server 2019 and Windows Server 2022 from this repo
Is it regression?
Yes
Expected behavior
Checksums match and builds proceeds successfully.
Actual behavior
==> azure-arm: Provisioning with powershell script: /agent/_work/1/s/runner-images/images/windows/scripts/build/Install-DotnetSDK.ps1
azure-arm: Downloading package from https://dot.net/v1/dotnet-install.ps1 to C:\Users\packer\AppData\Local\Temp\dotnet-install.ps1...
azure-arm: Package downloaded in 0.81 seconds
azure-arm: Downloading package from https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/6.0/releases.json to C:\Users\packer\AppData\Local\Temp\releases.json...
azure-arm: Package downloaded in 0.56 seconds
azure-arm: Installing dotnet 6.0.131
azure-arm: dotnet-install: Remote file https://dotnetcli.azureedge.net/dotnet/Sdk/6.0.131/dotnet-sdk-6.0.131-win-x64.zip size is 251514428 bytes.
azure-arm: dotnet-install: Downloaded file https://dotnetcli.azureedge.net/dotnet/Sdk/6.0.131/dotnet-sdk-6.0.131-win-x64.zip size is 251514428 bytes.
azure-arm: dotnet-install: The remote and local file sizes are equal.
azure-arm: dotnet-install: Extracting the archive.
azure-arm: dotnet-install: Adding to current process PATH: "C:\Program Files\dotnet". Note: This change will not be visible if PowerShell was run as a child process.
azure-arm: dotnet-install: Note that the script does not resolve dependencies during installation.
azure-arm: dotnet-install: To check the list of dependencies, go to https://learn.microsoft.com/dotnet/core/install/windows#dependencies
azure-arm: dotnet-install: Installed version is 6.0.131
azure-arm: dotnet-install: Installation finished
azure-arm: Downloading package from https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/6.0/releases.json to C:\Users\packer\AppData\Local\Temp\releases.json...
azure-arm: Package downloaded in 0.13 seconds
==> azure-arm: Checksum verification failed: expected 2655938bc0e94e788b847c45adcc87a8c4afd160294a0f374c7306a1015ec83d300c1092f11f3869
==> azure-arm: 58686b70431cec109257ace163a79551f5be797fb8b6a0ba, got A48E753165286E567507C2C73ABF3C38BB0C50015352424851ADCEE75DD884564
==> azure-arm: C29DC66DC82346E62CD95BDED680D5A6722D12253088B1E6717C0FDE8570042
==> azure-arm: At C:\Program Files\WindowsPowerShell\Modules\ImageHelpers\InstallHelpers.ps1:919 char:9
==> azure-arm: +         throw "Checksum verification failed: expected $expectedHash,  ...
==> azure-arm: +         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
==> azure-arm:     + CategoryInfo          : OperationStopped: (Checksum verifi...717C0FDE8570042:String) [], RuntimeException
==> azure-arm:     + FullyQualifiedErrorId : Checksum verification failed: expected 2655938bc0e94e788b847c45adcc87a8c4afd160294a0f374
==> azure-arm:    c7306a1015ec83d300c1092f11f386958686b70431cec109257ace163a79551f5be797fb8b6a0ba, got A48E753165286E567507C2C73ABF3
==> azure-arm:   C38BB0C50015352424851ADCEE75DD884564C29DC66DC82346E62CD95BDED680D5A6722D12253088B1E6717C0FDE8570042
==> azure-arm:
Repro steps
Build the Windows Server 2019 or Windows Server 2022 image using the code in runner images

I am also receiving the same error. Could someone please verify and update this?
=> azure-arm.image: Checksum verification failed: expected 2655938bc0e94e788b847c45adcc87a8c4afd160294a0f374c7306a1015ec83d300c1092f11f3869
==> azure-arm.image: 58686b70431cec109257ace163a79551f5be797fb8b6a0ba, got A48E753165286E567507C2C73ABF3C38BB0C50015352424851ADCEE75DD884564
==> azure-arm.image: C29DC66DC82346E62CD95BDED680D5A6722D12253088B1E6717C0FDE8570042

Same. I temporarily worked around it by commenting out the lines doing that checksum verification in the Install-DotnetSDK.ps1 script:

The same issue with running a build locally for win-19 server to update Chrome Browser to v125 from:
https://github.com/actions/runner-images/releases/tag/win19%2F20240526.1
and from successful main build:

I notice that the Install-DotnetSDK.ps1 downloads the install package from here: https://dotnetcli.azureedge.net/dotnet/Sdk/6.0.131/dotnet-sdk-6.0.131-win-x64.zip (by using https://dot.net/v1/dotnet-install.ps1).
Then it checks the hash code with the corresponding value obtained from https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/6.0/releases.json:
           {
              "name": "dotnet-sdk-win-x64.zip",
              "rid": "win-x64",
              "url": "https://download.visualstudio.microsoft.com/download/pr/ce77d3f6-4248-463d-931c-30f67208dd2c/ee2e8a08f2e490028d58450cf40a9cca/dotnet-sdk-6.0.131-win-x64.zip",
              "hash": "2655938bc0e94e788b847c45adcc87a8c4afd160294a0f374c7306a1015ec83d300c1092f11f386958686b70431cec109257ace163a79551f5be797fb8b6a0ba"
            },

These are different sources. The file downloaded with the url in the releases.json is consistent with the hash.
Apparently there is a mismatch between the package hosted by https://dotnetcli.azureedge.net and the package hosted in https://download.visualstudio.microsoft.com.

HI @vamshisiram , we're working on your request , we will share the latest update ASAP.

Thanks for the acknowledgment @kishorekumar-anchala

Same. I temporarily worked around it by commenting out the lines doing that checksum verification in the Install-DotnetSDK.ps1 script:

@kishorekumar-anchala  the workaround suggested by @pbcahill  worked for me. Just wanted to let you know, in case it helps troubleshooting @kishorekumar-anchala

Hi @Ami-007
Could you please try to re-deploy by forking the main repo , confirm back if same error occurs.

Hi @kishorekumar-anchala,
Retrying now, we will know in about 4-5 hours.
Thanks

This is very good news. Thanks Kishore for taking care of this.
Get Outlook for iOShttps://aka.ms/o0ukef

From: Johan Markenstein @.>
Sent: Friday, May 31, 2024 6:33:27 AM
To: actions/runner-images @.>
Cc: vamshisiram @.>; Mention @.>
Subject: Re: [actions/runner-images] Checksum verification failed on Windows 2019 and Windows 2022 (Issue #9958)
I just successfully completed the build using the main branch.
The checksum issue seem to be solved: the package downloaded from https://dotnetcli.azureedge.nethttps://dotnetcli.azureedge.net/ results in the hash code that matches https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/6.0/releases.json.
No code changes (or workarounds) needed.
—
Reply to this email directly, view it on GitHubhttps://github.com/actions/runner-images/issues/9958#issuecomment-2142176064, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVU36WS6QVJQLSVOCF2PIPDZFB32PAVCNFSM6AAAAABIPMITUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBSGE3TMMBWGQ.
You are receiving this because you were mentioned.Message ID: @.***>

I just successfully completed the build using the main branch. The checksum issue seem to be solved: the package downloaded from https://dotnetcli.azureedge.net results in the hash code that matches https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/6.0/releases.json. No code changes (or workarounds) needed.

When did you run a build? We are now seeing a signature thumbprint error when packer is installing AWSTools. @kishorekumar-anchala we can’t check if the checksum is working due to this issue now as pipeline is failing there instead

@Ami-007 : my message concerns only the "Checksum verification failed on Windows 2019 and Windows 2022" Issue.
Not related to anything AWSTools related.


fix(nuxt): improve nuxt implementation

A few small suggestions. Feel free to pick and choose.
I would recommend adding @nuxt/kit as a dependency rather than a peer dependency.

thanks a lot!


Fix type of notification_func

fix comment https://github.com/godotengine/godot/pull/78634#discussion_r1335673625
cc @dsnopek

Pulled the Gun too early with my approval. My issue seems solved by initializing to nullptr.
struct {
		GDExtensionScriptInstanceNotification notification_func = nullptr;
	} deprecated_native_info;

@Gallilus Ack, I think you're right! We're only initializing that value if you call script_instance_create, but not if you call script_instance_create2. Good catch!
@Sauermann If you don't mind adding the = nullptr, we can fix two problems at once :-)

Of course. done.

Thanks!


Anchor links not working for dynamically loaded anchors #1241

Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):
Fix #1241
Test URLs:

Before: https://main--moleculardevices--hlxsites.hlx.page/products/microplate-readers/multi-mode-readers/spectramax-id3-id5-readers#protein-detection-quantitation-and-analysis

After: https://1241-fix--moleculardevices--hlxsites.hlx.page/products/microplate-readers/multi-mode-readers/spectramax-id3-id5-readers#protein-detection-quantitation-and-analysis

Before: https://main--moleculardevices--hlxsites.hlx.page/applications/3d-cell-models/organoids#cardiac-organoids

After: https://1241-fix--moleculardevices--hlxsites.hlx.page/applications/3d-cell-models/organoids#cardiac-organoids

TBT increased because we need to wait til element exists. Checking if I can improve this.

Increasing timeout to 3500 when detecting anchor improves TBT and brings back LHS to 75


fold mochajs.github.io into this repo

GH Pages now supports docs/ since whenever.
I propose we fold that repo into this one, because:

Discoverability is an issue if the docs live in a separate repo.
The alternative is a gh-pages branch, but it's plainly silly to maintain a branch with a completely separate VCS root.

Potential drawbacks:

Tooling on that repo is kind of iffy.
May need to manually move some issues over.

What does @mochajs/core think?

LGTM. I like that PRs can update the docs at the same time.

The pros definitely outweigh the potential cons here.
Only one minor thing to consider, re. concern # 1: If the site currently requires additional tooling of some sort instead of just updating Markdown and/or HTML files, we may want to figure out how to cut that out first in the existing repo and then copy the page source files over into this one, so we don't have to add anything here but the page source files.
But I think ultimately, as long as we aren't adding anything to the package.json of the main project (e.g. if any needed tooling can go inside docs), it's not a dealbreaker either way.

it wouldn't add any production deps anyhow. would prefer to keep the dev deps all together so a contributor doesn't need to npm install from docs/. agree?

Agree. It doesn't hurt afaik. The simpler for the contributor/maintainer the better.

On 5 Sep 2017, at 18:03, Christopher Hiller<EMAIL_ADDRESS>wrote:
it wouldn't add any production deps anyhow. would prefer to keep the dev deps all together so a contributor doesn't need to npm install from docs/. agree?

Reply to this email directly, view it on GitHub, or mute the thread.

Hmm. I was thinking of avoiding adding to our already lengthy dev install times e.g. in CI, but simplicity for contributors is a compelling argument. Well, in that case, I'm fine bringing it over here as-is to start with and we can look at any potential for trimming dependencies later.


StillMaintained-style badges

So, it's pretty simple to create a static ‘this is unmaintained’ badge:
: https://img.shields.io/badge/maintained%3F-no!-red.svg?style=flat
However, what I'd really like to see, as a hopefully-easy-to-implement feature, is ‘yes this is maintained’ badges that expire:
https://img.shields.io/maintenance/STATUS/2015.svg
If STATUS is yes, then during 2015, this shows ; but let's say three months into 2016, any badges with a number lower than 2015.svg show  … and then perhaps three months into 2017, 2015.svg will resolve to .
Basically, I want a way to actively continue to signal that a project is maintained, that is trustworthy to the end-user: at the moment, I'm including the year in the manual badge I'm adding to my projects; but this is bulky and ugly, IMHO. It'd be much better for ‘yes!’ to simply mean yes, by definition, and to become ‘no!’ automatically.

Alternatively, the ‘value’ of the badge could simply be the year; and the only thing that changes could be the colour; but, personally, I like the ability to have custom words: https://img.shields.io/maintenance/feature-frozen/2015.svg, for instance.

That is smart.
I implemented it and it is now live. Your link is now functional, although this one may be of better use:
https://img.shields.io/maintenance/yes/2016.svg

Damn, that was fast!
@espadrine, you rock. Keep up the slick work.


Sanic exceptions

How does sanic exceptions are supposed to work? The docs states that

Exceptions can be thrown from within request handlers and will automatically be handled by Sanic. Exceptions take a message as their first argument, and can also take a status code to be passed back in the HTTP response.

This is my route
@app.route("/")
async def test(request):
    abort(401)

When I make a request on the path I get a response of :

Internal Server Error
The server encountered an internal error and cannot complete your request.

2017-08-24 10:18:43 - (sanic)[ERROR]: Traceback (most recent call last):   File "/home/nikos/.virtualenvs/3.6/lib/python3.6/site-packages/sanic/app.py", line 503, in handle_request     response = await response   File "/home/nikos/Desktop/Side Projects/micro/test2.py", line 15, in test     abort(401)   File "/home/nikos/.virtualenvs/3.6/lib/python3.6/site-packages/sanic/exceptions.py", line 262, in abort     raise sanic_exception(message=message, status_code=status_code) TypeError: __init__() missing 1 required positional argument: 'scheme'
Also after a bit the connection times out and the log trace is
2017-08-24 10:18:43 - (network)[INFO][<IP_ADDRESS>:34734]: GET http://<IP_ADDRESS>:8001/<PHONE_NUMBER>-08-24 10:19:43 - (sanic)[ERROR]: Traceback (most recent call last):   File "/home/nikos/.virtualenvs/3.6/lib/python3.6/site-packages/sanic/server.py", line 143, in connection_timeout     raise RequestTimeout('Request Timeout') sanic.exceptions.RequestTimeout: Request Timeout

There might be a bug with abort(401).
The Unauthorized exception requires an argument scheme, but SanicException doesn't.
You can try:
@app.route("/")
async def test(request):
     raise Unauthorized("Unauthorized", "Basic")

or
@app.route("/")
async def test(request):
    abort(400)

Actually, I was just testing it. Yes, the Unauthorized exception needs a scheme argument .From source code:
    def __init__(self, message, scheme, **kwargs):
        super().__init__(message)

        values = ["{!s}={!r}".format(k, v) for k, v in kwargs.items()]
        challenge = ', '.join(values)

        self.headers = {
            "WWW-Authenticate": "{} {}".format(scheme, challenge).rstrip()
        }

This might be a solution?
    def __init__(self, message, scheme=None, **kwargs):


bug: Controller executing twice - nested states.

Type: bug
Platform: all
Nested states with parameters and tabs execute the controller twice.
How to reproduce:
The first state manages the tabs
  .state('tabs', {
      url: "/tab/:projectID",
      cache: false,
      templateUrl: "tabs.html",
      controller: "TabsCtrl  as vm",
      resolve: {
        project: function($stateParams, Projects) {
          return Projects.get($stateParams.projectID);
        }
      }
  })

  .state('tabs.tab1', {
      url: "/tab1",
      views: {
          'tabs-tab1': {
              templateUrl: "tab1.html",
              controller: 'Tab1Ctrl as vm'
          }
      }
  })

the seconds loads the specific tabs in the tab list.
Plunker here.
Question asked on StackOverflow.

It seems that this line calls the controller twice.

Greetings @Leftyx!
I've closed this issue because my sensors indicated it was old and inactive, and may have already been fixed in recent versions of Ionic. However, if you are still experiencing this issue, please feel free to reopen this issue by creating a new one, and include any examples and other necessary information, so that we can look into it further.
Thank you for allowing me to assist you.

FWIW the original Plunker appears to still demonstrate the problem (Ionic, v1.1.0-nightly-1583). Perhaps related to nested <ion-nav-view></ion-nav-view> elements?
If nobody else has been bitten by this then maybe it's not worth addressing or opening a new issue for.

I hit the same route today.. I could see that my controller was called twice when I set cache false on one of the page. Is this something to worry about?

Yes, it is causing data to load twice for me in the controller.  Oddly enough, if I put a check in the service that loads the data to make sure it doesn't load if already started, the data change doesn't get noticed in the scope.  If I remove the abstract parent (for ionic tabs) it works fine.

+1

+1

I'm having a similar problem, but for me the controllers are being called more than twice.  I'm tracking it with simple console.log's when the state is called (e.g. console.log('Tab1.child is active').  I'll see that message sometimes 2 times, sometimes 4 times, sometimes 8, sometimes 10.  Not sure what's going on, but definitely seems to affect performance.  Any forward movement on this issue?

+1
I'm hitting this issue with ionic version 1.7.15. To get around it should I dispense with having nested views? I'm trying to build the view structure in a well-composed way but this issue is really putting a damper on that.

+1,
Ionic 1.3.1.
The controller fires +1 times every time I enter to it.....

I'm observing this also. I have 4 tabs, and each tab controller loads 4 times.

I am also seeing the same thing as queejie.  Any solution to this yet?

+1 / ionic 1.3.0
One instance more on each invocation! with and without caching ...
Does anyone found out where is a problem, do we do something wrong??
So long with no answer, where is the ionic team

@matiu , I suppose you've found some way.... can you tell, pls?

+1

I am experiencing exactly the same problem and any workaround like constructing some kind of singleton leads to even more headache. @Ionitron, @Leftyx or @kylefox  can this issue please be re-opened?

Oh, and to not come here empty-handed: In the application where I have the same problem, I added a console.trace() to the controller's constructor. The interesting thing is that the trace is different for the two calls. So I added the console.trace() to the plunkr as well: http://plnker.co/edit/xJ6WBLubrx4bCbJmCqNE?p=preview
The one trace contains the lines:
$RootScopeProvider/this.$get</Scope.prototype.$broadcast()ionic.bundle.js:30717 transitionTo/$state.transition<()
The other one these lines:
publicLinkFn()ionic.bundle.js:21582 tabSelected()
So while the one constructor is directly triggered by the switching of the tabs, the other one seems to be triggered by the URL/state change which itself is triggered by the tab click.
Maybe one of those events should be prevented when clicking on a tab?


Link back to repo from SPEC website

From https://scientific-python.org/specs/ , it is not easier to come back to this GitHub repo. I propose to add a link so people can come to this repo more easily from that site.

That sounds like a good idea; do you want to make a PR, or should I?

I do not know where the rendering code is. It is faster if you do it, but if you point me to the correct file, I won't mind filing a PR. Up to you. 😸

It'd be great if you want to give it a shot!
The code lives here and here.

Thanks for the pointers. What do you think about https://github.com/scientific-python/specs/pull/163 ?


Skip API testing in CI/CD pipeline

In the CI/CD pipeline, since the service is not running on localhost, API tests can't pass. The tests can be configured to be skipped if the service (on localhost) cannot be reached.

Conditional skip statements added to tests.


[QNN] Concat - Refactoring to C++

There are 2 reasons for moving to C++

With python interface earlier, we had to call infer_type in the op python definition. This broke the nice abstraction that we have with Relay and QNN ops.
Working with different targets, I realized that we need to write QNN passes, that will work on the abstraction of QNN ops. For example, Intel needs the conv to be uint8 x int8. However, TFLite graphs can be uint8 x uint8. This can resolved by writing a legalize pass for QNN conv2d op for Intel machines, that will insert a requantize on the weight matrix to go from uint8 x int8. With earlier python interface, the ops were already getting lowered to relay ops, before I could even run this pass.

Please review @yzhliu @jackwish @FrozenGene @vinx13 @tqchen @zhiics

@vinx13 @zhiics @yzhliu Can you please review this?
Refactoring to C++ removes InferType dependency. Relevant comment - https://github.com/dmlc/tvm/pull/3730#discussion_r314184102

Thanks @zhiics and @vinx13 for the comments. The changes are in.


Create an AWS account

Title: Create an AWS account
User Stories

As a developer, I want to be able to view the management console in AWS.

As a developer, I want to manage my IAM role.

As a developer, I want to set up a billing alert.

done


ARROW-14923: [Java] AllocationListener should be called during ownership transferring

@davisusanibar Would you like to take a look?

Closing because it has been untouched for a while, in case it's still relevant feel free to reopen and move it forward 👍


Add bitmap (bmp) support

subj.
See https://www.php.net/manual/ru/function.imagecreatefrombmp.php
https://stackoverflow.com/questions/16557822/imagecreatefrombmp-not-working-on-php

It seems that the imagecreatefrombmp function will be available on php-7.2 version at least.
It should implement imagecreatefrombmp function before php-7.2 version if we want to resolve this issue.

set feature request mark.


Enable browser code bundling without aliases

First off, this change removes the dependency on the os package and the setImmediate function (which is only available in node).
Secondly, it splits Langium into a browser and node package area. Both export a createDefaultSharedModule function which should be used in the respective environment (browser can be used anywhere, node only in node.js). This enables us to bundle Langium for the browser without needing to alias the fs library.
Thirdly, export ESM modules from Langium. ESM modules are supported starting from node 12.
Lastly, updates/removes some dependencies and resolves security issues.

It seems we need CommonJS builds for VSCode extensions for now. So, either we stay with module=node  for now or we follow a ESM + CJS output strategy with different exports as long as CJS modules are still required.


[bug] dbt-osmosis breaking upon upgrading to dbt v1.8

I just tried upgrading to dbt v1.8.1 and it's causing dbt-osmosis to break. I know dbt-osmosis recently added support for 1.8 so I'm not sure of the issue here. I tried removing and reinstalling my virtual environment (using Poetry) but the same problem persists. If I downgrade to v1.7.x then it works again.
dbt-osmosis --version
Traceback (most recent call last):
  File "/home/vscode/workspaces/analytics-platform/.venv/bin/dbt-osmosis", line 5, in <module>
    from dbt_osmosis.main import cli
  File "/home/vscode/workspaces/analytics-platform/.venv/lib/python3.10/site-packages/dbt_osmosis/main.py", line 14, in <module>
    from dbt_osmosis.core.diff import diff_and_print_to_console
  File "/home/vscode/workspaces/analytics-platform/.venv/lib/python3.10/site-packages/dbt_osmosis/core/diff.py", line 10, in <module>
    from dbt_osmosis.vendored.dbt_core_interface.project import DbtProject
  File "/home/vscode/workspaces/analytics-platform/.venv/lib/python3.10/site-packages/dbt_osmosis/vendored/dbt_core_interface/__init__.py", line 2, in <module>
    from .project import *  # noqa: F401, F403
  File "/home/vscode/workspaces/analytics-platform/.venv/lib/python3.10/site-packages/dbt_osmosis/vendored/dbt_core_interface/project.py", line 88, in <module>
    from dbt.clients.system import make_directory
ModuleNotFoundError: No module named 'dbt.clients.system'

These are some of the related installs I have:
dbt-adapters==1.2.1
dbt-common==1.1.0
dbt-core==1.8.1
dbt-extractor==0.5.1
dbt-osmosis==0.12.10
dbt-snowflake==1.8.2

https://github.com/z3z1ma/dbt-osmosis/pull/149 is dbt 1.8 compliant, but the reason it doesn't work on your end is that it is not yet included in the latest release (v0.12.10 was released 3 weeks ago, but dbt-osmosis's dbt 1.8 support was merge last week).
@z3z1ma Could you please create a new release?

@z3z1ma any chance we could create a new release here? Looking to upgrade my team's infra to dbt 1.8 but want to keep being able to use this tool 🙃

Completed in 0.13.0


Issue with precipitation totals

I'm not exactly sure what's happening but the precipitation totals are off, it's been like that for a few releases at least but I thought maybe it was Open-Meteo related. My local weather provider is alerting 10-15cm of snow but the app is showing 0.3cm for the day (Monday).
If I tap the individual bars in the hourly chart it comes up to 0.8cm, then the last 6 bars are 0.8mm, 0.7mm and 0.4mm for the last 2 (basically all higher than 0.3cm but still not close to the weather alert of 10-15cm of snow.
You can also see in the screenshot that ECMWF doesn't show any stacked bars for rain/snow, but GFS shows the stacked bars, and those last 6 bars are reporting the measurement in mm which I'd attribute to rain but it's well under -10 celcius in all those scenarios so there shouldn't be any rain.
I tried various models, ECMWF 0.25, GFS, GEM with the same results.
For testing the location is Ottawa Ontario

@0-5-0 i found the issue. For total precipitation i was showing the rain + snowfall melted water height equivalent.
But it is not correct when showing like on your screenshot. I will now show what you are expecting


ES6 modules & Rollup

This an in-progress PR that switches Leaflet to use ES6 modules system and Rollup for bundling. Closes #3229. It's A LOT of tedious work going through all the code, but it looks like it's going to be a major improvement.

Dependencies will be imported explicitly in each file instead of depending on global namespaces, making the code easier to maintain and reason about.
Things like L.Util.bind will turn into just bind, which means pretty much all references to Leaflet functions/classes will be properly minified, reducing the bundle size significantly (in theory).
I love the syntax, it just comes along very naturally.
We'll switch to a rollup-watch-based debug workflow, eliminating the document.write hack.
People who use ES6 modules or Rollup in their apps will be able to benefit from tree shaking (import stuff they need directly and discard all the rest).

cc @IvanSanchez @patrickarlt @olanod @tmcw @perliedman @yohanboniface @hyperknot
Status:

[x] src/**
[x] publish.sh script
[x] Manually check pointer event handling hacks
[x] Manually check touch event handling hacks
[x] Cleanup old build script & custom builds system
[x] Move unrunnable L.Path tests from suites/layer/vector/PathSpec.js to somewhere else
[ ] Tweak build script to output file sizes
[x] Rename output files from leaflet-rollup-src.js to leaflet-src.js
[x] Wait until https://github.com/rollup/rollup/pull/1069 is fixed (IE8 is broken until then)
[x] Rollup config/plugin to replace L.version to a string including revision

I have the same experience. ./node_modules/.bin has to be specified to take priority over globally installed executables.

I tried to make some clever use of rollup in the browser, but hit a lot of roadblocks. Thus, rely on npm run-script watch or yarn run watch for the time being. The script includes a hack in the JS banner so devs are reminded to use a fresh bundle.

Let's rebase to fix the Canvas conflict, and also maybe ditch all uses of as in favor of importing namespaces (which, as @IvanSanchez showed, are still neatly unrolled by rollup).

@mourner Rebased. I'll take a break from this branch, and will let someone else rewrite the named DomUtil, Util and DomEvent imports.

@IvanSanchez BTW what's up with the unrunnable Path tests?

@mourner L.Path is no longer exported (because it should be something like an un-instantiable abstract class), thus the tests involving new L.Path cannot work.
Maybe we should export L.Path as well, but I'm unsure.

After some rebasing hell and some fiddling with the VML code, the IE8 builds work again.

@simon04 You make a few good points! As far as I'm aware, Rollup (et al) can tree-shake better if the modules are not assigned, but just imported/exported.
However, right now I think it'd be better to just merge this as it is, and worry about cleaner ES6 module exports later.
As long as the ES5 bundle works exactly the same, all that can be postponed.


fix: Allow line cursor next/prev to visit connected inputs

Allow the next/prev methods on LineCursor to visit inputs, even if the input has a block connected to it.
Without this it's impossible to visit the connection between an statement input and the top block of the connected substack.
Fixes #99.

Inadvertently pushed an extra commit.  Have force-pushed to reset to correct branch state.


Update Vaultwarden to 1.23

New Emergency Access feature implemented.

Hi @sgissi ,
any updates on this? Very probably we hit https://github.com/dani-garcia/vaultwarden/issues/1920 issue, and upgrade to 1.23 could be a solution (not guaranteed, though).
My plan is to test a simple upgrade with changing the image.tag. Do you think, would it be enough?

Thanks for the info! I've upgraded to 1.23.0 directly with changing image.tag, and all went smoothly.


Upgrade question

I am looking to upgrade from v3 to v5 or v6
I see that there is a new mandatory property called tokenPattern. We currently use this Task for *.json, *.tfvars, *.properties etc files.
I use the Task inside a Task Group that is consumed by multiple file types across different pipelines (.NET, Terraform etc)
I'm not sure what to enter for this new property. Any advice?

Hi @DomBurf,
The tokenPattern input was added to "replace" tokenPrefix and tokenSuffix for common values.
Here is a table with the correspondance:

tokenPrefix
tokenSuffix
tokenPattern
Comments

#{
}#
default
you can remove tokenPrefix and tokenSuffix inputs

$(
)
azpipelines
you can remove tokenPrefix and tokenSuffix inputs

{{
}}
doublebraces
you can remove tokenPrefix and tokenSuffix inputs

__
__
rm
only for v5, you can remove tokenPrefix and tokenSuffix inputs

__
__
doubleunderscores
only for v6, you can remove tokenPrefix and tokenSuffix inputs

#{
}
octopus
you can remove tokenPrefix and tokenSuffix inputs

${{
}}
githubactions
only for v6, you can remove tokenPrefix and tokenSuffix inputs

other
other
custom
keep tokenPrefix and tokenSuffix inputs

@qetza  thanks for the response I am running into an issue as well. Below is how we had the task
  # Replace secret token
  - task: replacetokens@3
    inputs:
      targetFiles: '$(TEMPLATE_FILE)'
      keepToken: false
      tokenPrefix: '#{'
      tokenSuffix: '}#'
    displayName: 'Replace secret token'

Would my new version look like this
**      # Replace secret token
- task: replacetokens@6
inputs:
targetFiles: '$(TEMPLATE_FILE)'
keepToken: false
tokenPattern: default
displayName: 'Replace secret token'**

Hi @tdotcdot88,
I've just added 2 pinned discussions to explain how to migrate:

https://github.com/qetza/replacetokens-task/discussions/33
https://github.com/qetza/replacetokens-task/discussions/34

In you case the correct syntax would be:
- task: replacetokens@6
  inputs:
    sources: '$(TEMPLATE_FILE)' # make sure your path uses slashes and not backslashes
    missingVarAction: none      # this the default value so you can omit the input
    missingVarLog: warn         # this the default value so you can omit the input
    tokenPattern: default       # this the default value so you can omit the input
  displayName: 'Replace secret token'


[FeatureReq - Partner Center] Upload images by drag and drop

Is your feature request related to a problem? Please describe.
Right now it's only possible to upload an image, whether it's a logo or a screenshot, using the system's file picker
Describe the solution you'd like
Add support for dragging a file from the file system and dropping it in a dropzone

Hi @avi12 thank you for your feedback! We appreciate your suggestion of dragging and dropping files into a dropzone. We have forwarded your request to our development team for consideration.


Follow frame/iframe src URLs as links in FilterSpider

I thought this seemed reasonable, as frames/iframes in HTML are as valuable or more valuable to follow than a tag links.  There are a few sites that we've found that weren't getting scraped properly because links were embedded in frames.  On an individual basis, we can change the URL to that of the frame, but this should fix it more generally and shouldn't have any significant downsides.  @wearpants Thoughts?

An example is http://www.gavilan.edu/curriculum/frame_co.html. It seems to work for that.

@wearpants You said you approved of the idea. Did you want to take a quick look at the implementation before I merge it?

@wearpants You said you approved of the idea. Did you want to take a quick look at the implementation before I merge it?


Log all rejected requests (#1295).

Hi @troySteveHUNT, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla2.dotnetfoundation.org.

TTYL, DNFBOT;


Null key on Android keyboard input

Steps to Reproduce
This is on Android API 23 (Marshmellow)
Run the following on an Android 23 device:
https://gist.github.com/mitenko/303aa0268e5a02f2a80a1e34b98b74ad
The bottom right key of the keyboard has text that says null

Logs

start -a android.intent.action.RUN -f 0x20000000 --ez enable-background-compilation true --ez enable-dart-profiling true --ez enable-checked-mode true --ez
verify-entry-points true com.example.flutter_sandbox/com.example.flutter_sandbox.MainActivity
[+1053 ms] Starting: Intent { act=android.intent.action.RUN flg=0x20000000 cmp=com.example.flutter_sandbox/.MainActivity (has extras) }
[        ] Waiting for observatory port to be available...
[ +947 ms] Observatory URL on device: http://<IP_ADDRESS>:34795/
[   +3 ms] executing: D:\Dev\AndroidSDK\platform-tools\adb.exe -s P5SW310HT000345 forward tcp:0 tcp:34795
[  +71 ms] 59970
[        ] Forwarded host port 59970 to device port 34795 for Observatory
[   +4 ms] Connecting to service protocol: http://<IP_ADDRESS>:59970/
[ +580 ms] Successfully connected to service protocol: http://<IP_ADDRESS>:59970/
[   +3 ms] Sending to VM service: getVM({})
[  +11 ms] Result: {type: VM, name: vm, architectureBits: 64, targetCPU: arm64, hostCPU: MT8163, version: 2.2.1-dev.0.0.flutter-571ea80e11 (Mon Mar 4 19:30:53 2019 +0000) on "android_arm64", _profilerMode: VM, _nativeZoneMemoryUsage: 0, pid: 10765, startTime:
155474...
[   +4 ms] Sending to VM service: getIsolate({isolateId: isolates/149738854})
[   +3 ms] Sending to VM service: _flutter.listViews({})
[  +14 ms] Result: {type: FlutterViewList, views: [{type: FlutterView, id: _flutterView/0x7f8007bb18, isolate: {type: @Isolate, fixedId: true, id: isolates/149738854, name: main.dart$main-149738854, number: 149738854}}]}
[   +5 ms] DevFS: Creating new filesystem on the device (null)
[   +2 ms] Sending to VM service: _createDevFS({fsName: flutter_sandbox})
[  +46 ms] Result: {type: Isolate, fixedId: true, id: isolates/149738854, name: main.dart:main(), number: 149738854, _originNumber: 149738854, startTime:<PHONE_NUMBER>198, _heaps: {new: {type: HeapSpace, name: new, vmName: Scavenger, collections: 0,
avgCollectionPeriod...
[  +68 ms] Result: {type: FileSystem, name: flutter_sandbox, uri: file:///data/user/0/com.example.flutter_sandbox/cache/flutter_sandboxJBLSRT/flutter_sandbox/}
[   +1 ms] DevFS: Created new filesystem on the device (file:///data/user/0/com.example.flutter_sandbox/cache/flutter_sandboxJBLSRT/flutter_sandbox/)
[   +4 ms] Updating assets
[  +90 ms] Syncing files to device Poynt P5...
[   +3 ms] DevFS: Starting sync from LocalDirectory: 'D:\Dev\FlutterSandbox\flutter_sandbox'
[        ] Scanning project files
[   +3 ms] Scanning package files
[  +75 ms] Scanning asset files
[   +1 ms] Scanning for deleted files
[  +41 ms] Compiling dart to kernel with 458 updated files
[  +10 ms] D:\Dev\flutter\bin\cache\dart-sdk\bin\dart D:\Dev\flutter\bin\cache\artifacts\engine\windows-x64\frontend_server.dart.snapshot --sdk-root D:\Dev\flutter\bin\cache\artifacts\engine\common\flutter_patched_sdk/ --incremental --strong --target=flutter
--output-dill build\app.dill --packages D:\Dev\FlutterSandbox\flutter_sandbox\.packages --filesystem-scheme org-dartlang-root
[+1363 ms] I/SurfaceView(10765): updateWindow -- setFrame, this = io.flutter.view.FlutterView{3a8587f VFE...... .F....I. 0,0-720,1216}
[   +9 ms] Updating files
[ +387 ms] DevFS: Sync finished
[   +1 ms] Syncing files to device Poynt P5... (completed in 1,896ms)
[        ] Synced 0.8MB.
[   +1 ms] Sending to VM service: _flutter.listViews({})
[  +21 ms] Result: {type: FlutterViewList, views: [{type: FlutterView, id: _flutterView/0x7f8007bb18, isolate: {type: @Isolate, fixedId: true, id: isolates/149738854, name: main.dart$main-149738854, number: 149738854}}]}
[   +1 ms] Connected to _flutterView/0x7f8007bb18.
[   +2 ms] �  To hot reload changes while running, press "r". To hot restart (and rebuild state), press "R".
[   +3 ms] An Observatory debugger and profiler on Poynt P5 is available at: http://<IP_ADDRESS>:59970/
[        ] For a more detailed help message, press "h". To detach, press "d"; to quit, press "q".
[ +444 ms] I/SurfaceView(10765): Punch a hole(dispatchDraw), w = 720, h = 1216, this = io.flutter.view.FlutterView{3a8587f VFE...... .F...... 0,0-720,1216}
[ +319 ms] I/SurfaceView(10765): updateWindow -- setFrame, this = io.flutter.view.FlutterView{3a8587f VFE...... .F...... 0,0-720,1216}

Analyzing flutter_sandbox...
No issues found! (ran in 1.9s)

[√] Flutter (Channel beta, v1.3.8, on Microsoft Windows [Version 10.0.17763.379], locale en-CA)
    • Flutter version 1.3.8 at D:\Dev\flutter
    • Framework revision e5b1ed7a7f (5 weeks ago), 2019-03-06 14:23:37 -0800
    • Engine revision f4951df193
    • Dart version 2.2.1 (build 2.2.1-dev.0.0 571ea80e11)

[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at D:\Dev\AndroidSDK\
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • ANDROID_HOME = D:\Dev\AndroidSDK\
    • ANDROID_SDK_ROOT = D:\Dev\AndroidSDK\
    • Java binary at: D:\Dev\AndroidStudio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1248-b01)
    • All Android licenses accepted.

[√] Android Studio (version 3.3)
    • Android Studio at D:\Dev\AndroidStudio
    • Flutter plugin version 34.0.1
    • Dart plugin version 182.5215
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1248-b01)

[√] IntelliJ IDEA Ultimate Edition (version 2018.3)
    • IntelliJ at D:\Dev\IDEA\IntelliJ IDEA 2018.2.2
    • Flutter plugin version 34.0.2
    • Dart plugin version 183.6156.10

[√] Connected device (1 available)
    • Poynt P5 • P5SW310HT000345 • android-arm64 • Android 6.0 (API 23)

• No issues found!

Duplicate of https://github.com/flutter/flutter/issues/29798

Having this issues with Android v4.4.2
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, v1.3.14-pre.63, on Linux, locale en_US.UTF-8)
[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[!] Android Studio (not installed)
[✓] Connected device (1 available)
! Doctor found issues in 1 category.

1 connected device:

Lenovo A606 • <IP_ADDRESS>:5555 • android-arm • Android 4.4.2 (API 19)


version and note added in README.md file

version and note added in README.md file

Changes look good, merging the PR.


Enable batch processing of requests.

In many cases, it can be faster to process a batch of requests rather than multiple concurrent requests. Think e.g. inserting into a database.
I'd love for SignalR Core to allow me to transition this:
Task SendMessage(string user, string message)
{
    ...
}

To something like this:
[Batch(MaxSize = 100)]
Task SendMessage(IEnumerable<(string user, string message)> requests)
{
    ...
}

The idea being that when reading messages from the socket it would queue messages for as long as the socket had data immediately available, up to MaxSize. From the protocol's perspective this would be transparent.

Not sure if SignalR would efficiently handle it, but doing this with a Nagle-like algorithm can already be handled at a higher level right now due to being able to return tasks.
The primary benefit of integrating this idea of batching directly into SignalR is to optimize around I/O patterns: at a minimum, deplete your sockets 100% (or up to some limit) and then process all the requests you received as a single batch. An optional Nagle feature on top of that would be a cherry on top.

I'm not a fan of adding this level of complexity unless there were massive benefits. It complicates the dispatching code and it complicates the programming model.

I'm not a fan of adding this level of complexity unless there were massive benefits (and I'm not seeing them).

As I said, bulk updates in databases (maybe via a TVP) tend to be significantly faster than concurrent individual updates.
This isn't a problem we need SignalR itself to solve, of course, and there are arguments to be had against more tightly coupling the simple idea of a Hub with I/O patterns. However, having implemented it on top of SignalR already and dealt with those issues firsthand, I think some rock-solid core code is worth exploring.
In my implementation I first started with a timeout-based approach (as @anurse mentioned), but quickly realized that the simplest approach would result in large latency issues during lulls in request frequency.
Next I added some code to detect those lulls and disable the timeout. Didn't feel quite perfect because it didn't 100% remove the issue, but it worked pretty well.
Following this, rather than detecting lulls, I made a second operation Flush() which felt cleaner and removed the latency issue completely. However, this also has its own complexity once you need to decide what Flush() means when multiple callers are sending requests concurrently.
So, while I do feel like a timeout-based approach would be a useful tool to have, I also believe that the complexity of this may be a bit much. Which lead me to a much simpler ask of simply following the I/O of the sockets:

SignalR effectively already "drains the socket" already.

It's a suggestion on how one would enable batches with minimal complexity while avoiding the latency issues I arrived at. I want to drain the socket's buffers. Once the buffers are drained (and we're waiting for more data from the wire), dispatch the batch. Some pseudocode:
Task readTask = socket.ReadAsync();

for(;;)
{
	var batch = new List<Request>();

	do
	{
		await readTask;

		while(socket.HasRequest)
		{
			batch.Add(socket.DequeueRequest());
		}

		readTask = socket.ReadAsync();
	} while(readTask.IsCompleted);

	DispatchBatchToHub(batch);
}

it complicates the programming model.

I'd argue that doing it on top of SignalR complicates hub code a whole lot more than an attribute and IEnumerable. I decided in the end to scrap my implementation because I was not confident a jr/mid dev would be able to maintain it.

The process you went through to solve this seems very application-specific. Each application is going to have significant differences in the way messages are received. If we build something into the core, we have to handle all those edge cases and provide deep configuration in order to allow an application to take advantage of it. We've been burned before with these kinds of things (automatic message replay comes to mind) and generally find that application-specific logic is necessary no matter how we implement it because of how complex the space is.
More questions to consider:

Would we only batch messages from the same caller?

If so, what value is this providing over batching on the client?
If not, how would thinks like Context.Caller react to this (since there would be multiple "callers")?

If the connection drops mid-batch, do we dispatch the batch in-progress or drop it?

If we dispatch it, we're invoking a Hub method when we know there's no connection, which isn't something we've done before.

It'd definitely be interested to look at what extensibility SignalR could provide to allow a batching extension to be built. I'm a lot more open to that since it allows application developers to choose the solutions that work for them.
As @davidfowl said, we already do drain the socket. The socket read is not coupled to the invocation of the Hub method, so we'll keep reading messages from the socket while the Hub method is running and then we'll dispatch the incoming messages as quickly as possible. We do synchronize Hub method invocations so that a single connection is only running a single invocation at a time, but if you had your Hub methods add the incoming messages to a batching system that you control you'd effectively end up with the batching system you're discussing. Something like the below would accomplish what you're looking for (presuming _batchProcessor.Add adds a data item to the current batch and a background process is flushing the batches according to your policy):
public class MyHub: Hub
{
    public Task ReceiveItem(string data)
    {
        _batchProcessor.Add(data);
        return Task.CompletedTask;
    }
}

I'm sure there are plenty of existing tools out there to handle batching in .NET, and I'm not sure we could do as well as they could given everything else we have to focus on.

We aren't looking to provide this kind of batching as a native SignalR scenario. It's totally reasonable to do batching on top of our APIs.


Update Lucene to 8.5.0

Summary of the changes / Why this improves CrateDB
https://lucene.apache.org/core/8_5_0/changes/Changes.html
Checklist

[x] Added an entry in CHANGES.txt for user facing changes
[x] Updated documentation & sql_features table for user facing changes
[x] Touched code is covered by tests
[x] CLA is signed
[x] This does not contain breaking changes, or if it does:

It is released within a major release
It is recorded in CHANGES.txt
It was marked as deprecated in an earlier release if possible
You've thought about the consequences and other components are adapted
(E.g. AdminUI)

I would be curious if we are able to measure this optimization https://issues.apache.org/jira/browse/LUCENE-9147. We use heavily stored fields, and this should reduce memory.


[SW-1180] feat(bitcoin): show unconfirmed balance

LGTM

The code changes looks good. We will probably let the user know that the balance includes unconfirmed balance too. Display the confirmed balance as subtext in the accounts card.


build.getConversation error 404 "Resource not found"

Dear Recast developers,
with pseudo-placeholders "my_name" and "my_bot_name":
this.build.getConversation('my_name', 'my_bot_name', 2).then(res => {console.log(res)})
returns

Error: cannot GET /build/v1/users/my_name/bots/my_bot_name/builders/v1/conversation_states/2

even if I definitely know that the conversation ID exists, because I can successfully call
sendDialogText(text, callback) {         this.build.dialog(             { 'type': 'text', content: text },             { conversationId: 2 })             .then(res => {                 callback(JSON.parse(JSON.stringify(res)))                             })     }
Am I doing something wrong?
Thanks for your help,
Simon

Hi @shprman, your code works fine for me, are you sure that your user name and your bot name match your token ?

Ok, so I need to use the Developer Token, not the Request Token... :)

Hi @shprman, sorry for the inconvenience, it isn't very clear that the developer token is required :)


parallel::copy_if is broken

The current implementation of parallel::copy_if is broken as it does not properly account for elements not to be copied in the middle of the input sequence. The current test is broken as well as it does not detect this issue.

@dcbdan: adding you to this ticket

This has been fixed by merging #1385


TINKERPOP-1263 Pass SASL mechanism through to server

Ran $ mvn clean install && mvn verify -pl gremlin-server -DskipIntegrationTests=false -DincludeNeo4j and all is good
VOTE +1

Hey @mike-tr-adamson .
I had a look at RFC 4422 section 3.2 and it seems to imply that mechanism negotiation implementations are essentially our choice. I was wondering why you decided to prepend it to the payload, rather than say, add it to the payload, or negotiate it after authentication as pointed out in the RFC (to avoid downgrade attacks for users who want to extend the server capabilities here)

@PommeVerte I'm not sure what prepending it or adding it makes any difference to the negotiation. I prepended it so it was (potentially) the first element in the payload that could be checked without having to read the whole payload. As you said, it was a choice.
I believe that the RFC says that a negotiation can happen after authentication but that doesn't provide any real protection against downgrade. I'd prefer that this sort of protection was left to 3rd party implementations in the form of additional authorization checks against mechanism usage.

Hey Mike. Sounds fair enough. I wasn't pointing fingers, just wanted to understand the thought process a bit better.
Just to explicit what I meant by the difference between prepending and adding. The payload is constructed of a wrapper which is basically a byte and a mimetype at this point for binary payloads. And a message to be deserialized (via GraphSONMessageSerializer, GryoMessageSerializer, etc.).
Prepending is basically adding the mechanism to the wrapper.
Adding would be including it in the message as an argument. Along side the sasl credential argument for example (or some other variation)
The difference here is that with the curent implementation, existing drivers will need to be upgraded to support this feature change in the payload, along the lines of the changes you made in this PR on the Java Driver.
The first point here is that this can be an issue with drivers that separate the wrapper building logic from the message building. ie: the wrapper is always built the same way and reused for all operations. Adding the mechanism for only the authentication message becomes a special use case in the wrapper. Depending on the implementation this can either get ugly, or be less trivial than expected. (PHP, javascript and python drivers fall in this category)
The second point is that if the mechanism were included as a message argument instead, then most drivers out there either already support this feature or have mechanisms in place to extend authentication message building. So we basically provide the feature keys in hand for users of those drivers. And if the drivers really have no support for what was just mentioned, it's a trivial upgrade.
I tried to keep this clear but it's not one of my fortes. Let me know if it wasn't clear, or if there's some conflicting logic in implementing this in the message rather than the wrapper.
Cheers.

I didn't realize from my review that this was a breaking change to the drivers/protocol. @mike-tr-adamson do you see any problem in trying to make this a backward compatible change by implementing as @PommeVerte suggested?

The more that I think about this the more I think we'd make it easier for driver devs to handle this change if the modification came as @PommeVerte suggested.

I have changed the Handler::channelRead0 to add the mechanism as an argument to the initial SASL message. These means that the SaslAuthenticationHandler is now unchanged.
I agree that this is a more elegant solution and allows 3rd party auth implementations to use or not use the mechanism at their leisure. Note that it is down to the auth implementation to handle the case of no mechanism being passed. It shouldn't be a requirement.

thanks @mike-tr-adamson but travis took a compilation error:
[ERROR] /home/travis/build/apache/incubator-tinkerpop/gremlin-driver/src/main/java/org/apache/tinkerpop/gremlin/driver/Handler.java:[92,35] cannot find symbol
  symbol:   method arrArg(java.lang.String,saslClient[...] null)
  location: variable messageBuilder of type org.apache.tinkerpop.gremlin.driver.message.RequestMessage.Builder

Is there something to fix here?

@spmallette Yes, apologies. My tidying up, over-tidied the code. I've pushed again with something that will hopefully compile.

I re-ran all the tests as i did on the last vote - all good. I'll re-iterate my VOTE +1

This looks really good. Simple enough. VOTE +1 from me.

VOTE +1.

Not sure why but I had to close this PR manually. Looks like the merge went as it should so.....maybe just some broken automation.  I updated changelog and dev/upgrade docs as well.


Connection inactive timeout [moved]

This is Issue 1080 moved from a Google Code project.
Added by 2012-10-02T00:00:36.000Z by<EMAIL_ADDRESS>Please review that bug for more context and additional comments, but update this bug.
Original labels: Type-Enhancement, Priority-Low
Original description
When a connection is inactive but not closed, this must be forcibly closed server-side.
A shrink function could control all active connection and force to close the connections inactive.

The configured parameters could be :
-shrink time (the scheduled time for do the shrink action)
-inactive time ( the max time of inactivity of a connection)

Not relevant anymore. Closing it.


About memory bank

Thank you for your code. But I can not find the implementations of memory bank. How do you realize the contrastive loss?

Thanks for your interest. The code of memory bank will be provided upon paper acceptance. The contrastive loss (over each batch) code can be found at:
https://github.com/tfzhou/ContrastiveSeg/blob/9a381b9799c16d81e18d8f9f25ab509b93fb56de/lib/loss/loss_contrast.py#L91.


Cmd+r to rename a folder/file when focused

It would be wonderful to be able to have a folder/file selected in the explorer and hit cmd+r to rename 💭

There is default shortcut for this F2 but you can use Keyboard Shortcuts editor to set Ctrl+R for renameFile command.
Not that Ctrl+R already used for other global action like Recent Files

Thanks @IllusionMH 💯


⚠ Samsung has degraded performance

In 9593b85, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 1934 ms

Resolved: Samsung performance has improved in 432c75e.


Mount point info not showing for sidecar (and main pod info is showing only on workload)

Rancher versions: 2.1 master 9/4
Steps to Reproduce:

Create a workload and add a volume with a mount point
Add a sidecar to that workload and add another mount point
Go to workload details
Go to main pod and sidecar details

Results:  The mount point for the main pod is showing up in the workload details and the sidecar mount isn't showing up anywhere.  Mount points are specific to the pod and should show up on the pod details pages.  Also if you want to show mount points on the workload level, you should show all mount points.

Volumes section has been added in the pod detail page.


Add entry for Osram proprietary cluster.

This will allow lights to remember color/brightness/temp if power is
reset.

Thanks!


feat(Tests): extra commands to run unit tests TDD style as well as e2e in interactive mode. Also improved README.

This adds the following:

extra commands to make testing more convenient and flexible:

For unit tests: npm run test-watch for TDD style development
For e2e tests: npm run e2e-live to place protractor in interactive mode (details mentioned in README)

Also improved the README to remove all broken links and some cleanup.
Various other small refactorings to help improve and strengthen.

Awesome, thanks.
You don't like the pink ? :D

I'm actually a big fan of pink, but it was a tad bit hard to read on that
gray background. Yellow may pop better. But if it's not any better to you,
by all means bring the pink back :)
On Sat, Jan 2, 2016 at 9:31 PM Olivier Combe<EMAIL_ADDRESS>wrote:

Awesome, thanks.
You don't like the pink ? :D
—
Reply to this email directly or view it on GitHub
https://github.com/ocombe/ng2-webpack/pull/2#issuecomment-168464094.

No worries, I actually started typing #F and took whatever webstorm offered, I was just testing my build at the time :)

I improved the design a lot in one of my lasts commits :-)


How to estimate pose using given IMU/GPU info data?

I need some help getting the ground truth 6DoF poses from IMU/GPS data. Will be great if the toolkit included a script to do that.

Also, is magnetometer available?

Here are examples of using the GPS information: https://github.com/ucbdrive/bdd-data#trajectories


LosslessJSON very slow compared to native JSON

Doing crude benchmarks by just observing the "deserialize" time in the console, LosslessJSON seems to take about twice as much time as native JSON.
Another interesting observation: Firefox is significantly faster than Chome and taking about 30% of the time.

LosslessJSON is only used to preserve Int64 numbers. JSON encoding itself does not use too much time comparing to the parsing of the Gvas I think;
I'm unsure if there are any usages of Int64 outside of timestamp which is (or could pratically be) larger than 2^53, and if there's none I'm considering switching back as the error is less than 0.05ms.

Using native JSON cut the time down from about 15 seconds to 7 seconds for me on Chrome.

LosslessJSON is only used to preserve Int64 numbers

Ah that makes sense. They could be serialized as strings to preserve precision.


Update MAINTAINERS.md

@jesusbagpuss Please accept this PR to accept this nomination to the maintainers for the eprints project(s)

:shipit:  👍


Package interfering with code autocomplete

I'm having an issue with the atom-html-preview package interfering with the autocomplete package and causing it to not work in Atom. When I begin typing code the autocomplete box pops up for a second, then when the preview page refreshes it causes the autocomplete box to disappear. Upon pressing the command Ctrl + Space to bring up the autocomplete I can then select what I need but it makes it a cumbersome way to use the autocomplete function.

Also having the autocomplete issue

I also ran into this issue, and it should be resolved as of #71 being merged.
Please let me know if it's not.

Just checked it, and it seems to be working very nicely.  Thank you!!


fabric8:build crashes on xml-config sample

f-m-p version : 4.2-SNAPSHOT
Sample project : https://github.com/fabric8io/fabric8-maven-plugin/tree/master/samples/xml-config

what error are you getting?

There was error in  for Pnew, now for Pexternal why we are using digest in from image, it throws image not found and it fails. So if you say I will correct that as well
@dev-gaur @rohanKanojia

@theexplorist : Is this issue fixed now? Or is there still something left to fix?

It's fixed


check if autostart permission is active for my app

Every time i open the app, it would open autostart settings window, how can I check if the autostart permission is selected before open the settings window?
do you have any idea?
class MainActivity : FlutterActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        if (AutoStartPermissionHelper.getInstance().isAutoStartPermissionAvailable(context))
            AutoStartPermissionHelper.getInstance().getAutoStartPermission(context)
    }
}

Closing since this is a duplicate of #4 , given that these aren't standard android apis, there is no way of knowing this information.


Compile failure with GHC 7.8

The Hackage matrix builder detected the following compile failure:
Configuring component lib from giphy-api-<IP_ADDRESS>
Preprocessing library giphy-api-<IP_ADDRESS>...
[1 of 2] Compiling Paths_giphy_api  ( /tmp/matrix-worker/1480361044/dist-newstyle/build/x86_64-linux/ghc-7.8.4/giphy-api-<IP_ADDRESS>/build/autogen/Paths_giphy_api.hs, /tmp/matrix-worker/1480361044/dist-newstyle/build/x86_64-linux/ghc-7.8.4/giphy-api-<IP_ADDRESS>/build/Paths_giphy_api.o )
[2 of 2] Compiling Web.Giphy        ( src/Web/Giphy.hs, /tmp/matrix-worker/1480361044/dist-newstyle/build/x86_64-linux/ghc-7.8.4/giphy-api-<IP_ADDRESS>/build/Web/Giphy.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-<IP_ADDRESS> ... linking ... done.
Loading package deepseq-<IP_ADDRESS> ... linking ... done.
Loading package bytestring-<IP_ADDRESS> ... linking ... done.
Loading package containers-<IP_ADDRESS> ... linking ... done.
Loading package fail-<IP_ADDRESS> ... linking ... done.
Loading package binary-<IP_ADDRESS> ... linking ... done.
Loading package text-<IP_ADDRESS> ... linking ... done.
Loading package hashable-<IP_ADDRESS> ... linking ... done.
Loading package transformers-<IP_ADDRESS> ... linking ... done.
Loading package primitive-<IP_ADDRESS> ... linking ... done.
Loading package vector-<IP_ADDRESS> ... linking ... done.
Loading package scientific-<IP_ADDRESS> ... linking ... done.
Loading package pretty-<IP_ADDRESS> ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package nats-1.1.1 ... linking ... done.
Loading package transformers-compat-<IP_ADDRESS> ... linking ... done.
Loading package tagged-0.8.5 ... linking ... done.
Loading package unordered-containers-<IP_ADDRESS> ... linking ... done.
Loading package semigroups-0.18.2 ... linking ... done.
Loading package attoparsec-<IP_ADDRESS> ... linking ... done.
Loading package old-locale-<IP_ADDRESS> ... linking ... done.
Loading package time-1.4.2 ... linking ... done.
Loading package unix-<IP_ADDRESS> ... linking ... done.
Loading package base-compat-0.9.1 ... linking ... done.
Loading package dlist-<IP_ADDRESS> ... linking ... done.
Loading package time-locale-compat-<IP_ADDRESS> ... linking ... done.
Loading package aeson-<IP_ADDRESS> ... linking ... done.
Loading package base64-bytestring-<IP_ADDRESS> ... linking ... done.
Loading package mtl-2.2.1 ... linking ... done.
Loading package stm-<IP_ADDRESS> ... linking ... done.
Loading package exceptions-0.8.3 ... linking ... done.
Loading package blaze-builder-<IP_ADDRESS> ... linking ... done.
Loading package uri-bytestring-<IP_ADDRESS> ... linking ... done.
Loading package random-1.1 ... linking ... done.
Loading package uuid-types-1.0.3 ... linking ... done.
Loading package http-api-data-0.3.3 ... linking ... done.
Loading package case-insensitive-<IP_ADDRESS> ... linking ... done.
Loading package data-default-class-<IP_ADDRESS> ... linking ... done.
Loading package cookie-<IP_ADDRESS> ... linking ... done.
Loading package filepath-<IP_ADDRESS> ... linking ... done.
Loading package http-types-0.9.1 ... linking ... done.
Loading package mime-types-<IP_ADDRESS> ... linking ... done.
Loading package network-<IP_ADDRESS> ... linking ... done.
Loading package parsec-3.1.11 ... linking ... done.
Loading package network-uri-<IP_ADDRESS> ... linking ... done.
Loading package async-2.1.1 ... linking ... done.
Loading package directory-<IP_ADDRESS> ... linking ... done.
Loading package process-<IP_ADDRESS> ... linking ... done.
Loading package zlib-<IP_ADDRESS> ... linking ... done.
Loading package streaming-commons-0.1.16 ... linking ... done.
Loading package http-client-0.5.4 ... linking ... done.
Loading package byteable-0.1.1 ... linking ... done.
Loading package cereal-<IP_ADDRESS> ... linking ... done.
Loading package socks-0.5.5 ... linking ... done.
Loading package hourglass-0.2.10 ... linking ... done.
Loading package memory-0.13 ... linking ... done.
Loading package asn1-types-0.3.2 ... linking ... done.
Loading package asn1-encoding-0.9.4 ... linking ... done.
Loading package cryptonite-0.20 ... linking ... done.
Loading package asn1-parse-0.9.4 ... linking ... done.
Loading package pem-0.2.2 ... linking ... done.
Loading package x509-1.6.4 ... linking ... done.
Loading package x509-store-1.6.2 ... linking ... done.
Loading package x509-validation-1.6.5 ... linking ... done.
Loading package tls-1.3.8 ... linking ... done.
Loading package x509-system-1.6.4 ... linking ... done.
Loading package connection-0.2.6 ... linking ... done.
Loading package http-client-tls-0.3.3 ... linking ... done.
Loading package http-media-0.6.4 ... linking ... done.
Loading package safe-0.3.10 ... linking ... done.
Loading package mmorph-1.0.9 ... linking ... done.
Loading package utf8-string-<IP_ADDRESS> ... linking ... done.
Loading package string-conversions-0.4 ... linking ... done.
Loading package vault-<IP_ADDRESS> ... linking ... done.
Loading package servant-<IP_ADDRESS> ... linking ... done.
Loading package servant-client-<IP_ADDRESS> ... linking ... done.
Loading package microlens-<IP_ADDRESS> ... linking ... done.
Loading package microlens-th-<IP_ADDRESS> ... linking ... done.

src/Web/Giphy.hs:170:12:
    Not in scope: ‘<$>’
    Perhaps you meant ‘<>’ (imported from Data.Monoid)

src/Web/Giphy.hs:170:25:
    Not in scope: ‘<$>’
    Perhaps you meant ‘<>’ (imported from Data.Monoid)

src/Web/Giphy.hs:171:12:
    Not in scope: ‘<*>’
    Perhaps you meant ‘<>’ (imported from Data.Monoid)

src/Web/Giphy.hs:171:25:
    Not in scope: ‘<$>’
    Perhaps you meant ‘<>’ (imported from Data.Monoid)

src/Web/Giphy.hs:172:12:
    Not in scope: ‘<*>’
    Perhaps you meant ‘<>’ (imported from Data.Monoid)

src/Web/Giphy.hs:172:25:
    Not in scope: ‘<$>’
    Perhaps you meant ‘<>’ (imported from Data.Monoid)

src/Web/Giphy.hs:173:12:
    Not in scope: ‘<*>’
    Perhaps you meant ‘<>’ (imported from Data.Monoid)

src/Web/Giphy.hs:173:25:
    Not in scope: ‘<$>’
    Perhaps you meant ‘<>’ (imported from Data.Monoid)

src/Web/Giphy.hs:174:12:
    Not in scope: ‘<*>’
    Perhaps you meant ‘<>’ (imported from Data.Monoid)

src/Web/Giphy.hs:174:25:
    Not in scope: ‘<$>’
    Perhaps you meant ‘<>’ (imported from Data.Monoid)

src/Web/Giphy.hs:175:12:
    Not in scope: ‘<*>’
    Perhaps you meant ‘<>’ (imported from Data.Monoid)

src/Web/Giphy.hs:175:25:
    Not in scope: ‘<$>’
    Perhaps you meant ‘<>’ (imported from Data.Monoid)

src/Web/Giphy.hs:176:12:
    Not in scope: ‘<*>’
    Perhaps you meant ‘<>’ (imported from Data.Monoid)

src/Web/Giphy.hs:176:25:
    Not in scope: ‘<$>’
    Perhaps you meant ‘<>’ (imported from Data.Monoid)

src/Web/Giphy.hs:177:12:
    Not in scope: ‘<*>’
    Perhaps you meant ‘<>’ (imported from Data.Monoid)

src/Web/Giphy.hs:177:25:
    Not in scope: ‘<$>’
    Perhaps you meant ‘<>’ (imported from Data.Monoid)

Yeah, I don't support GHC 7.8 for the newer releases anymore. But if it's only the Data.Monoid import, I'm happy to add that.

@passy if you don't want to support GHC 7.8 / base-4.7 that's totally reasonable. All you have to do is add a lower bound on base, i.e. base >= 4.8.
You can simply fixup the meta-data via
https://hackage.haskell.org/package/giphy-api-<IP_ADDRESS>/giphy-api.cabal/edit

@hvr Thanks for reporting this and the explanations. I've published <IP_ADDRESS> to hackage; I hope this will work for you!


Set voltages on all mirrors on energy change

Fixes #521
Requires https://github.com/DiamondLightSource/dodal/pull/834
To test:

Confirm tests pass

Although curious to know what is the thinking was behind merging horizontal and vertical voltages into a single device? The mirrors themselves are still separate devices. Is it always going to be the case that horizontal and vertical mirrors will be controlled using the same power supply mechanism on all different beamlines?

It wasn't that deliberate a decision. They are powered by the same physical hardware and so share an IOC/EDM. They're also mostly changed at the same time i.e. this ticket. So I think having them together is fine but I don't mind breaking them up if you feel strongly about it?


Listing: NPE when editing data settings

Describe the bug
A Null Pointer Exception when attempting to change data settings for a selection with multiple strings
java.lang.NullPointerException
	at ghidra.app.plugin.core.data.AbstractSettingsDialog$1.isChangeAllowed(AbstractSettingsDialog.java:73)
	at ghidra.app.plugin.core.data.AbstractSettingsDialog.buildWorkPanel(AbstractSettingsDialog.java:216)
	at ghidra.app.plugin.core.data.AbstractSettingsDialog.buildPanel(AbstractSettingsDialog.java:131)
	at ghidra.app.plugin.core.data.AbstractSettingsDialog.<init>(AbstractSettingsDialog.java:82)
	at ghidra.app.plugin.core.data.DataSettingsDialog.<init>(DataSettingsDialog.java:45)
	at ghidra.app.plugin.core.data.DataPlugin.dataSettingsCallback(DataPlugin.java:596)
	at ghidra.app.plugin.core.data.DataPlugin.lambda$addActions$2(DataPlugin.java:162)
	at docking.action.builder.ActionBuilder$1.actionPerformed(ActionBuilder.java:48)
	at docking.PopupMenuHandler$1.run(PopupMenuHandler.java:63)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

To Reproduce
Steps to reproduce the behavior:

Open the Defined Strings window
Select two strings and make selection
Right click the listing -> data -> settings

Expected behavior
It should be possible to change the data settings for a selection, given that there is a check which returns Common data settings were not found across selection for invalid selections.
Environment (please complete the following information):

Ghidra master (commit c6cb8a0d)

Context
Stumbled upon this thanks to @astrelsky on #4366 while trying to mark multiple strings as constant

You can just set the default settings for the string data type to constant. Since the decompiler cant directly use the dynamic string data type and will use char * instead you don't have to worry about having one written to. The first thing I do in every program is set the default settings for string and unicode.
This isn't related to the issue at hand but it's good info.


Update README.md

Codecov Report
Base: 84.18% // Head: 84.18% // No change to project coverage :thumbsup:

Coverage data is based on head (48feec3) compared to base (32e95dc).
Patch has no changes to coverable lines.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #14   +/-   ##
=======================================
  Coverage   84.18%   84.18%
=======================================
  Files         281      281
  Lines        4826     4826
=======================================
  Hits         4063     4063
  Misses        763      763

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


set my container port and bridge to connect via putty

The template below is mostly useful for bug reports and support questions.
Feel free to remove anything which doesn't apply to you and add more information where it makes sense.
Required information

Distribution: 16.04
Distribution version: Ubuntu
The output of "lxc info" or if that fails:
Name:           ubuntu_01
State:          RUNNING
PID:            24075
IP:             <IP_ADDRESS>
CPU use:        9.32 seconds
BlkIO use:      4.45 MiB
Memory use:     69.41 MiB
KMem use:       0 bytes
Link:           vethQTPB73
TX bytes:      100.01 KiB
RX bytes:      567.51 KiB
Total bytes:   667.53 KiB

Issue description
installed lxc, default bridge setup as ip <IP_ADDRESS>, I need to setup port for my container and then nat my one public ip to multiple containers.
port forwarding is enabled.
root@sd-94858:/etc/default# lxc-ls  -f
NAME      STATE   AUTOSTART GROUPS IPV4       IPV6
ubuntu_01 RUNNING 0         -      <IP_ADDRESS>   -
ubuntu_02 RUNNING 0         -      <IP_ADDRESS> -
root@sd-94858:/etc/default#
root@sd-94858:/etc/default# cat /etc/network/interfaces
source /etc/network/interfaces.d/*
The loopback network interface
auto lo
iface lo inet loopback
The primary network interface
auto enp0s20f0
iface enp0s20f0 inet dhcp

That's LXC not LXD.
What you're after is a simple NAT rule on the host that you should put in an init script or firewall script if you have one.
Something along the lines of:
iptables -t nat -A PREROUTING -s <IP_ADDRESS> -p tcp --dport 2222 -j DNAT --to <IP_ADDRESS>:22

Which will have any traffic hitting <IP_ADDRESS> on port tcp/2222 hit <IP_ADDRESS> on port 22.


feat(build): add version bump

This PR adds version bumping automation through command npm version minor -m "chore(release): %s"

@SyntaxStacks please review

me gusta! :+1:


[Bug] HMR of *.stories.svelte causes all template args to be overwritten by the last story

Describe the bug
If you use a <Template let:args> for your story, and you make a change to the *.stories.svelte file, your Docs view will overwrite all args for all stories with whatever the last story is
Steps to reproduce the behavior
Test.svelte
<script lang="ts">
  export let text: string;
</script>
<div>
  {text}
</div>

Test.stories.svelte
<script lang="ts">
  import { Meta, Story, Template } from '@storybook/addon-svelte-csf';

  import Test from './Test.svelte'
</script>

<Meta title="Inputs/Test" component={Test} />

<Template let:args>
  <Test {...args} />
</Template>

<Story name="Story1" args={{ text: 'Story1' }} />
<Story name="Story2" args={{ text: 'Story2' }} />
<Story name="Story3" args={{ text: 'Story3' }} />

pnpm storybook
open the Docs view

Change any code in Test.stories.svelte and save
page refreshes with this

Expected behavior
Stories should retain their proper args
Environment

OS: MacOS
Node.js version: 19.7.0
pNPM version: 8.6.9

I did see some HMR issues were fixed https://github.com/storybookjs/storybook/issues/21053. Does this still happen with the latest versions of storybook and the plugins?

I don't know what you mean by "open the Docs view". Do you need to setup @storybook/addon-docs. I've done that, but am not seeing anything new. Where's that button? It would really be helpful if you could share a repository that reproduces this issue

Sorry Ben, just got back from vacation and haven't had a chance to update our repo with the latest versions and test out if its fixed.
as for docs view, that's just what I thought the default "view" was when you clicked on a storybook in the left-nav:

Here's what I was using in my repo:
    "@storybook/addon-essentials": "7.2.1",
    "@storybook/addon-interactions": "7.2.1",
    "@storybook/addon-links": "7.2.1",
    "@storybook/addon-styling": "^1.3.5",
    "@storybook/addon-svelte-csf": "^3.0.7",
    "@storybook/blocks": "7.2.1",
    "@storybook/svelte": "7.2.1",
    "@storybook/sveltekit": "7.2.1",
    "@storybook/testing-library": "0.2.0",

I'll try to see if the new version fixes things today or tomorrow.  Thanks!

Just updated to these versions and the bug still exists.
    "@storybook/addon-essentials": "7.4.2",
    "@storybook/addon-interactions": "7.4.2",
    "@storybook/addon-links": "7.4.2",
    "@storybook/addon-styling": "^1.3.7",
    "@storybook/addon-svelte-csf": "^4.0.7",
    "@storybook/blocks": "7.4.2",
    "@storybook/svelte": "7.4.2",
    "@storybook/sveltekit": "7.4.2",
    "@storybook/testing-library": "0.2.0",

I might have found something that could help find the cause:

Open the Test.stories.svelte storybook in your browser, see the top "Story1" and down below Story1,2,3
Change the "text" property to something else.  Only the top updates as expected
Open Test.stories.svelte in your IDE, change the first stories text to "Story11"
browser refreshes with the HMR update, now all of the stories read "Story3"
Change the "text" property at the top to something else.  All stories now update to the this new value instead of just the top one

So it seems like the HMR is messing up the IDs or event listeners or something and causes all the stories to be bound to the same value.  Let me know if there's anything else I can do to help

If you could share a repository that reproduces the issue that would help a lot.

https://github.com/rory-orennia/addon-svelte-csf-114
I even updated the stories to use export const meta instead of the old <Meta> tag and it still breaks

:rocket: Issue was released in v4.0.9 :rocket:


Update the query parameters and refactoring of code.

This PR updates the following:

Query parameters
Updates the metrics every 60 seconds.

Signed-off-by: Pradeep<EMAIL_ADDRESS>

@Akash4927 Binary file is being deleted not added.


New package: Universal-Debloater-Alliance.uad-ng version 1.0.3

Checklist for Pull Requests

[x] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.6 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Verify:


rename types.ts to config.ts?

In #1251 I separated the instrumentation types into 2 files called: types.ts (for public types) and internal-types.ts (for private-types), and documented the convention in GUIDELINES.md.
However, after working on this lately, I now realize that the types.ts file only contains the instrumentation config and related types.
I want to suggest renaming the files to
config.ts
for the public types which are instrumentation config and the related types like hooks and enums.
and
types.ts
for internal types of instrumentation (which should not be exported).
Since this is an internal change, it should not affect end users (which only import from index.ts)
I think this is a good time to do this change, because in the future we might have more complex dependencies and more users, and I was already touching a lot of the files around this area lately.
The name internal-types.ts doesn't feel like the best fit IMO.
What do you think?

I think it makes sense. I cannot think of types we're using that will not fall under these two categories.


fix(tier4_perception_rviz_plugin): fix build error in Humble

Description
以下を修正
tf2_geometry_msgs.h -> tf2_geometry_msgs.hpp
Related Links
https://tier4.atlassian.net/browse/AEAP-488
Tests performed

tier4_perception_rviz_pluginがビルドできること
Effects on system behavior

Not applicable.
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[ ] I've confirmed the contribution guidelines.
[ ] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

Codecov Report

:exclamation: No coverage uploaded for pull request base (beta/v0.3.16@6b341aa). Click here to learn what that means.
Patch has no changes to coverable lines.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@              Coverage Diff               @@
##             beta/v0.3.16    #449   +/-   ##
==============================================
  Coverage                ?   0.00%
==============================================
  Files                   ?       8
  Lines                   ?     348
  Branches                ?       0
==============================================
  Hits                    ?       0
  Misses                  ?     348
  Partials                ?       0

Flag
Coverage Δ

differential
0.00% <0.00%> (?)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


feat(wmg): WMG Compare Function Dropdown

Reason for Change

#4112
If the reason for this PR's code changes are not clear in the issue, state value/impact

Changes

add
remove
modify

Testing steps

Either list QA steps or reasoning you feel QA is unnecessary
Describe how you made sure to know that your changes worked. Should allow someone else to go verify your code without in depth knowledge.
"Unit tested only", "tested in rdev by a, b, c, verifying feature worked by... ", "manually ran pipeline locally with these results: ..."

Notes for Reviewer

@ashin-czi @seve should we just use this as the feature branch?

I cherrypicked code from this branch already, so we can close this now! Thank you!


missing Flask on new Parsl install

On doing a fresh install of Swag, which requires Parsl, I get the following error:
Searching for Flask
Downloading https://files.pythonhosted.org/packages/9b/62/80a56f9d223f0b89cdcf7d592455375f8c9d73866f337fa85f39f45fe0c5/Flask-SQLAlchemy-2.4.0.tar.gz#sha256=0c9609b0d72871c540a7945ea559c8fdf5455192d2db67219509aed680a3d45a
Best match: Flask SQLAlchemy-2.4.0
Processing Flask-SQLAlchemy-2.4.0.tar.gz
Writing /tmp/easy_install-8akdu_kl/Flask-SQLAlchemy-2.4.0/setup.cfg
Running Flask-SQLAlchemy-2.4.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-8akdu_kl/Flask-SQLAlchemy-2.4.0/egg-dist-tmp-39pas_5e
no previously-included directories found matching 'docs/_build'
warning: no previously-included files matching '*.pyc' found anywhere in distribution
zip_safe flag not set; analyzing archive contents...
removing '/afs/crc.nd.edu/user/a/awoodard/.conda/envs/swag/lib/python3.7/site-packages/Flask_SQLAlchemy-2.4.0-py3.7.egg' (and everything under it)
Moving Flask_SQLAlchemy-2.4.0-py3.7.egg to /afs/crc.nd.edu/user/a/awoodard/.conda/envs/swag/lib/python3.7/site-packages
Flask-SQLAlchemy 2.4.0 is already the active version in easy-install.pth

Installed /afs/crc.nd.edu/user/a/awoodard/.conda/envs/swag/lib/python3.7/site-packages/Flask_SQLAlchemy-2.4.0-py3.7.egg
error: The 'Flask' distribution was not found and is required by parsl

Do you have whatever is specifying the list of things to install, eg swag requirements.txt?

This does not work:
git clone https://github.com/PittGenomics/Swag
cd Swag
python3 setup.py install

This works:
git clone https://github.com/PittGenomics/Swag
cd Swag
pip install .

Googling round for error messages like this, I've seen what looks like a lot of occurences of setup.py misresolving "Flask" to "Flask SomeOtherPackage" - eg Flask SQLAlchemy above, but in other bug reports Flask WTF (https://github.com/pypa/setuptools/issues/1013), or Flask Login (https://github.com/lingthio/Flask-User/issues/254).
It sounds like some bug in the setup stack, rather than in parsl
@ZhuozhaoLi also noted that he saw this when using setup.py
The pip based install is frequently tested in CI (every run) and hasn't shown this behaviour.
Hopefully using pip is a suitable workaround.

I think this is a third-party bug in setuptools that there is a decent workaround for (as noted above). If so, maybe this issue should be closed? @annawoodard

Agreed


Debug address sanitization crashes in github actions

Trying to figure out where the test address sanitization errors are coming from. Can't repro locally so doing it by pushing to this branch to trigger github actions.

Experimentation complete, workaround identified.

Oh, I see that there's like no granularity in choosing images so the workaround of using ubuntu-20 doesn't actually work when using C++20...


Add plane to stasis constraint and remove pressure constraints

Description
Following the implementation of temperature-dependent solid domain constraint for both single-phase and two-phase flows, a need for an additional condition was identified. Indeed, in some simulations, splatters may happen, and with the previous implementation, splatter could freeze "mid-air" which is non-physical and therefore undesired. This PR adds a plane to divide the problem domain in two parts and only the one in the opposite direction to the normal vector is considered for stasis constraints to be applied. The plane is defined through a point and an outward pointing normal vector.
During this PR, a bug regarding the pressure constraints was detected and fixed. Previously, the pressure DOFs were also constrained, but this resulted in an ill-posed problem when sources terms in the momentum equation were pressure-dependent. Therefore, as of this PR, the constraints on pressure DOFs were removed.

Testing
Previous tests with solid domain constraints were updated due to the pressure DOFs that are no more constrained.
Additionally, two new application tests were added for the new plane restriction feature (1 for single fluid flows and one for VOF).

Documentation
The "Constrain Stasis" page in the parameter documentation was updated with the new features and disabled ones.

Miscellaneous (will be removed when merged)

Checklist (will be removed when merged)
See this page for more information about the pull request process.
Code related list:

[x] All in-code documentation related to this PR is up to date (Doxygen format)
[x] Lethe documentation is up to date
[x] New feature has unit test(s) (preferred) or application test(s), and restart files are in the generator folder
[x] The branch is rebased onto master
[x] Changelog (CHANGELOG.md) is up to date
[x] Code is indented with indent-all and .prm files (examples and tests) with prm-indent

Pull request related list:

[x] Labels are applied
[ ] There are at least 2 reviewers (or 1 if small feature) excluding the responsible for the merge
[x] If this PR closes an issue or is related to a project, it is linked in the "Projects" or "Development" section
[x] If the fix is temporary, an issue is opened
[x] The PR description is cleaned and ready for merge

can you rebase? Then I would merge afterwards

I'll wait until @oguevremont and @hepap accept the PR before merging


需求13: 优化配置文件代码高亮

https://github.com/baidu/bfe/tree/develop/docs/en_us/modules/
https://github.com/baidu/bfe/tree/develop/docs/zh_cn/modules/

Codecov Report

Merging #490 into develop will increase coverage by 0.02%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop     #490      +/-   ##
===========================================
+ Coverage    53.21%   53.24%   +0.02%
===========================================
  Files          257      257
  Lines        23604    23604
===========================================
+ Hits         12561    12567       +6
+ Misses        9558     9555       -3
+ Partials      1485     1482       -3

Impacted Files
Coverage Δ

bfe_http2/server.go
71.67% <0.00%> (-0.17%)
:arrow_down:

bfe_spdy/server_conn.go
78.98% <0.00%> (+0.44%)
:arrow_up:

bfe_spdy/frame_read.go
58.11% <0.00%> (+0.75%)
:arrow_up:

bfe_http2/writesched.go
80.91% <0.00%> (+1.52%)
:arrow_up:

bfe_util/fixed_pool.go
100.00% <0.00%> (+16.66%)
:arrow_up:

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 368c1b5...8410fc3. Read the comment docs.


Links inside dynamically loaded section will never trigger navigo routes.

If links with data-navigo are loaded with XHR after navigo was initialized they will be ignored when clicked and I will be taken to non existent URL

Did you try using https://github.com/krasimir/navigo/blob/master/DOCUMENTATION.md#augment-your-a-tags


Discard adaptation samples

This PR modifies the hmc.jl file to discard the adaptation samples from AdaptiveHamiltonian samplers. I've added a keyword to the sample function for NUTS and HMCDA which is temporary until the sampling API is reworked, but for now you can choose to keep the adaptation samples using
c1 = sample(model(. . .), NUTS(1000, 200, 0.65), discard_adapt = true)
c2 = sample(model(. . .), NUTS(1000, 200, 0.65), discard_adapt = false)

In the above case, c1 has length 800, while c2 has length 1000. discard_adapt defaults to true, so you must call discard_adapt = false explicitly if you want to hang on to them for some reason.
I also threw in a couple tests just to make sure this was sane.

Thanks, @cpfiffer!


Allow supplying existing custom certificate in settings

Let's Encrypt support is already working nicely, but we might as well add the ability to supply a local PEM that has already been created.

Suggest we add the
certificate_cert, certificate_keyandcertificate_chain` fields in the settings unless you can think of better names!

Related? https://github.com/Miserlou/Zappa/issues/565

Its probably best to keep the actual certificate outside of source control.  Really, once you've installed the custom certs into aws, they should be destroyed.  However, there should be some way to map the custom domain name to the deployed api gateway.
At the moment, that mapping has to be a manual step.  Would be nice if zappa looked for the existence of custom domain names matching the "domain" field in the settings.  If one is found, it would map that to the newly deployed api gateway.


MINOR: Use distinct consumer groups in dynamic listener tests

Dynamic listener tests should use distinct consumer groups to ensure there are no committed offsets.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@hachikuji Saw this failure in the jenkins build: https://builds.apache.org/job/kafka-trunk-jdk9/538/testReport/junit/kafka.server/DynamicBrokerReconfigurationTest/testAddRemoveSslListener/. Can you review the fix please? Thanks.

@hachikuji Thanks for the review. You are right, that was just a very bad fix. The issue was duplicate reads and I think that was because the test was reusing the same consumer group with a second consumer and the first one could have committed some offsets before the broker was restarted. I have updated the test to use distinct consumer groups and reverted the previous change.

@rajinisivaram I agree that it's a bit dangerous in this test case to use the same groupId. It seems we could even use the simple consumer and disable auto commits to take group state totally out of the picture. That said, and I may be being a bit slow here, but how are the duplicates explained by this?

@hachikuji Removing auto-commit should also work, I have updated the code, but left the groups in there.
I think the scenario is:

we create a new listener, produce and consume some messages on topic using first consumer
we shutdown and restart the servers. the servers use ephemeral ports, so they get new ports this time and the first consumer can no longer connect to the servers
we produce and consume some more messages on topic using a second pair of producer/consumer that use the new server ports. The consumer is created with auto-offset-reset latest. If the group is reused, this requires 1) to have not committed at all or committed the last offset. Anything in between could result in the second consumer consuming some of the messages produced in 1).


System.threading.thread.currentprincipal.identity.name is returning null .Net Core

Thread.CurrentPrincipal is not used in ASP.NET Core. You have to pass around the identity/principal as a parameter to other methods based on what you get in HttpContext.User after authentication has taken place.

@Eilon, But why it works for 4.6.2 and it does not work for ,Net Core

It works on ASP.NET 4.6 apps, but does not work in ASP.NET Core. This was a design decision for the reasons mentioned above.

Hi Elion,  What I meant when using   ASP.NET Core targeting 4.6 it works but when you have it on ASP.NET Core targeting.Net Core it does not work

It's luck it works for your targetting 4.6. We make no promises it will work, because it ends up using HttpContext.Current and this just doesn't work well for multi-threading or async. Don't use it.


--ctu flag not handled during analysis

Describe the bug
The documentation states that Cross Translation Unit Analysis can be enabled with the --ctu flag. Using this flag is also included in the GitLab CI tutorial.
The flag is not recognized, instead the CodeChecker: error: unrecognized arguments: --ctu message is printed.
CodeChecker version
6.23.1
To Reproduce
Steps to reproduce the behaviour:

Run command: CodeChecker analyze --ctu -o ./reports ./compile_commands.json
See error

Expected behaviour
The Cross Translation Unit Analysis is performed when the --ctu flag is passed.
Desktop

OS: Linux
Browser: N/A
Version: N/A

What is the Clang version on the machine? The --ctu flag is conditionally enabled based on the Clang available in the system. You'll need a new enough clang and clang-extdef-mapping in the PATH.

Thanks for the quick response @whisperity.
That was indeed the source of the issue. (Clang SA was not made properly available on the PATH due some typo in the CI configuration I am working on.)
In that case I think the given error message is highly misleading, since CodeChecker has a separate error message for cases when clangsa (or any other analyzer) is not found on the PATH. In my opinion in this case that error message should have been printed, instead of stating that a documented flag (--ctu) is not recognized.

Yeah the problems is that argparse hijacks the execution to throw a full error from parse_args() before we could detect the actual lack of CTU options... Will have to come up with a solution for this problem.


Subcommand help is not showing

I seem to never be able to get help to print the subcommand help. Looking at the code, I would expect SubcommandHelpTemplate to be used for this, but it is not used anywhere in the code. If stacks is a command with sub commands, it will print the list of subcommands with a command like this: cli stacks help which uses AppHelpTemplate.
In this case however:

Email and Author revert back to unknown and <IP_ADDRESS> (as if the command is app)
There is no way to get the help for a subcommand.

I found out that I can get the subcommand help by doing something like cli stacks help subcommand but find this unintuitive. Should not the help be shown by typing the following?
cli help stacks
cli help stacks subcommand

I also feel it's unintuitive that the output for cli help stacks subcommand is not the same as cli stacks help subcommand. Also, assuming stacks has subcommands, cli help stacks doesn't mention the fact, but cli stacks help does.
I spent an hour trying to fix this just now but ran into dependency initialisation loops. I'll have another crack at it at a later date probably.

I agree, the same output should be shown for cli help stacks subcommand as cli stacks help subcommand. Thanks for bringing this up!

(Note you can also see it via cli stacks subcommand -h)

I ended up working around this by doing my own global flag parsing, then scanning through looking for any argument called "help". If help, --help or -h were found, then it sticks --help on the end.
I'm no closer to actually fixing the problem though.

In case anyone is interested in fixing this issue, I would love to review a PR for ya! ✨

Manually closing this as stale! We can re-open if there's interest in the future.