winget upgrade --all gets cancelled if winget needs to be updated

Brief description of your issue
If winget upgrade --all is run and winget needs upgrading, the whole command is aborted.
Steps to reproduce
On a system where winget v1.22.10582.0 is install, run winget upgrade --all.
The upgrade process will start, then abort after reaching winget.
Expected behavior
winget should either update itself last, or defer the update after the whole command has been run. Or even better: update itself first, then proceed with the rest of the updates.
Actual behavior
PS> winget upgrade --all; Remove-UselessDesktopShortcuts.ps1
Name                                              Id                                Version       Available      Source
-----------------------------------------------------------------------------------------------------------------------
Creative App version <IP_ADDRESS>                   CreativeTechnology.CreativeApp    <IP_ADDRESS>    <IP_ADDRESS>     winget
FileMenu Tools 8.4                                LopeSoft.FileMenuTools            8.4           8.4.1          winget
KDiff3                                            KDE.KDiff3                        1.10.6        1.10.7         winget
MKVToolNix 82.0.0 (64-bit)                        MoritzBunkus.MKVToolNix           82.0.0        83.0.0         winget
MediaInfo 23.11                                   MediaArea.MediaInfo.GUI           23.11         24.01          winget
App Installer                                     Microsoft.AppInstaller            1.22.10582.0  1.22.10661.0   winget
WinDbg                                            Microsoft.WinDbg                  1.2308.2002.0 1.2402.24001.0 winget
Oh My Posh version 19.11.7                        JanDeDobbeleer.OhMyPosh           19.11.7       19.17.2        winget
iMazing                                           DigiDNA.iMazing                   <IP_ADDRESS>     <IP_ADDRESS>      winget
Microsoft .NET SDK 6.0.419 (x64)                  Microsoft.DotNet.SDK.6            6.0.419       6.0.420        winget
Microsoft .NET SDK 6.0.321 (x64)                  Microsoft.DotNet.SDK.6            6.0.321       6.0.420        winget
Microsoft Visual C++ 2015-2022 Redistributable (…  Microsoft.VCRedist.2015+.x64      14.38.33135.0 14.40.33617.1  winget
Microsoft Windows Desktop Runtime - 6.0.27 (x64)  Microsoft.DotNet.DesktopRuntime.6 6.0.27        6.0.28         winget
Microsoft Windows Desktop Runtime - 6.0.27 (x86)  Microsoft.DotNet.DesktopRuntime.6 6.0.27        6.0.28         winget
Microsoft .NET SDK 7.0.313 (x64)                  Microsoft.DotNet.SDK.7            7.0.313       7.0.407        winget
Microsoft Windows Desktop Runtime - 7.0.16 (x64)  Microsoft.DotNet.DesktopRuntime.7 7.0.16        7.0.17         winget
23 upgrades available.
1 package(s) have version numbers that cannot be determined. Use --include-unknown to see all results.
1 package(s) have pins that prevent upgrade. Use the 'winget pin' command to view and edit pins. Using the --include-pinned argument may show more results.

Installing dependencies:
This package requires the following dependencies:
  - Packages
      Microsoft.UI.Xaml.2.8 [>= 8.2310.30001.0]
(1/19) Found Creative App [CreativeTechnology.CreativeApp] Version <IP_ADDRESS>
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://files.creative.com/creative/bin/apps/swureleases/win/creativeapp/release/CreativeAppSetup_<IP_ADDRESS>.exe
  ██████████████████████████████  76.7 MB / 76.7 MB
Successfully verified installer hash
Starting package install...
Successfully installed

(2/19) Found FileMenu Tools [LopeSoft.FileMenuTools] Version 8.4.1
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://www.lopesoft.com/fmtools/FileMenuTools-setup.exe
  ██████████████████████████████  11.6 MB / 11.6 MB
Successfully verified installer hash
Starting package install...
Successfully installed

(3/19) Found KDiff3 [KDE.KDiff3] Version 1.10.7
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://download.kde.org/stable/kdiff3/kdiff3-1.10.7-windows-x86_64.exe
  ██████████████████████████████  66.8 MB / 66.8 MB
Successfully verified installer hash
Starting package install...
Successfully installed

(4/19) Found MKVToolNix [MoritzBunkus.MKVToolNix] Version 83.0.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://mkvtoolnix.download/windows/releases/83.0/mkvtoolnix-64-bit-83.0-setup.exe
  ██████████████████████████████  25.3 MB / 25.3 MB
Successfully verified installer hash
Starting package install...
Successfully installed

(5/19) Found MediaInfo [MediaArea.MediaInfo.GUI] Version 24.01
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://mediaarea.net/download/binary/mediainfo-gui/24.01.1/MediaInfo_GUI_24.01.1_Windows.exe
  ██████████████████████████████  6.33 MB / 6.33 MB
Successfully verified installer hash
Starting package install...
Successfully installed

(6/19) Found App Installer [Microsoft.AppInstaller] Version 1.22.10661.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Successfully verified installer hash
Starting package install...
  ████████████████████████████▌   95%
Successfully installed. Restart the application to complete the upgrade.

Cancelled
22 package(s) have version numbers that cannot be determined. Use --include-unknown to see all results.

Environment
Windows Package Manager v1.7.10661
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22631.3235
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.22.10661.0

Winget Directories
-----------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Diag…
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\sett…
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled

(version info is obviously not the version that was in effect when the problem occurred)

After running the command, what are the results of winget -v? This behavior appears to be working correctly. I routinely upgrade WinGet like this, and the rest of the upgrades that can succeed, will succeed.

I hate to say, but I can't repro right now since winget doesn't need to be updated anymore....

Haven't repro'ed this today:
Name                                                        Id                                      InstalledVersion  Available        Source
-----------------------------------------------------------------------------------------------------------------------------------------------
Visual Studio Enterprise 2022                               Microsoft.VisualStudio.2022.Enterprise  17.9.3            17.9.5           winget
Progress Telerik Fiddler Classic                            Telerik.Fiddler.Classic                 5.0.20211.51073   5.0.20242.10753  winget
App Installer                                               Microsoft.AppInstaller                  1.22.10661.0      1.22.10861.0     winget
Dell Command | Update for Windows Universal                 Dell.CommandUpdate.Universal            5.0.0             5.1.0            winget
AWS Command Line Interface                                  Amazon.AWSCLI                           <IP_ADDRESS>         2.15.33          winget
Windows Software Development Kit - Windows 10.0.22621.2428  Microsoft.WindowsSDK.10.0.22621         10.1.20348.1      10.1.22621.2428  winget
Microsoft Visual C++ 2008 Redistributable - x64             Microsoft.VCRedist.2008.x64             9.0.30729         9.0.30729.6161   winget
Wireshark                                                   WiresharkFoundation.Wireshark           <IP_ADDRESS>           4.2.4            winget
Microsoft .NET Windows Desktop Runtime 6.0                  Microsoft.DotNet.DesktopRuntime.6       6.0.26            6.0.28           winget
Microsoft .NET Runtime 3.1                                  Microsoft.DotNet.Runtime.3_1            > 3.1.32          6.0.28           winget

[3/10] Upgrading 'App Installer' (Id='Microsoft.AppInstaller') from version '1.22.10661.0' to version '1.22.10861.0' via 'winget upgrade --id Microsoft.AppInstaller --version 1.22.10861.0'
Found App Installer [Microsoft.AppInstaller] Version 1.22.10861.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
This package requires the following dependencies:
  - Packages
      Microsoft.UI.Xaml.2.8 [>= 8.2310.30001.0]
Successfully verified installer hash
Starting package install...
  ████████████████████████████▌   95%
Successfully installed. Restart the application to complete the upgrade.
winget exit code: 0x80004004

[4/10] Upgrading 'Dell Command | Update for Windows Universal' (Id='Dell.CommandUpdate.Universal') from version '5.0.0' to version '5.1.0' via 'winget upgrade --id Dell.CommandUpdate.Universal --version 5.1.0'
Found Dell Command | Update for Windows Universal [Dell.CommandUpdate.Universal] Version 5.1.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://dl.dell.com/FOLDER10791716M/1/Dell-Command-Update-Windows-Universal-Application_JCVW3_WIN_5.1.0_A00.EXE
  ██████████████████████████████  25.7 MB / 25.7 MB
Successfully verified installer hash
Starting package install...

I encountered the same problem today on my work laptop. winget -v returns v1.7.10861.
At the same time, on the other laptop, everything upgraded fine and winget -v returns v1.7.11132.

Occured on my three Windows 11 boxes with the latest update:


(Un)commenting in AsciiDoc files should use flush-left comment prefix

Contributing guidelines

[X] I have read CONTRIBUTING.md
[X] I have read CODE_OF_CONDUCT.md
[X] I have updated 'mini.nvim' to latest version

Module(s)
mini.comment
Description
The plugin fails to account for the fact that for filetype asciidoc (assuming a 'commentstring' of //%s), a line can be considered a comment only when the // is flush left.
Thus, if // occurs indented on a line, that line is not a comment, so invoking gcc on that line should add another //, not remove the existing one.
I've pushed a commit https://github.com/ds26gte/mini.comment/commit/a19c2bceffc98383c6cca2563c9d47e19ae4925a to my fork of your repo. Please inspect and consider for inclusion after suitable modification. Thanks.
Neovim version
0.7.2
Steps to reproduce

Install mini.comment repo and setup anyway you choose
Open an empty file j.adoc
At the neovim command line, type setl cms=//%s
Add a line         abc  (i.e., with some leading spaces)
Call gcc on that line
You fill find that the added // is indented, which is not a valid AsciiDoc comment
Type gcc again. You will find that the // is removed, even though the line is not a valid AsciiDoc comment

Expected behavior
Typing gcc on an indented line should add a new // flush left, not an indented //.
Typing gcc on an indented line with leading // should not remove that //, but should a new // flush left.
Actual behavior
Typing gcc on an indented line that doesn't lead with // preserves the indent and adds a //  . (Adding the // is correct, indenting it is wrong.)
Typing gcc on an indented line with a leading // removes the //.

I don't really like to add filetype-specific code in any 'mini.nvim' modules, to be honest. I'll look into a possibly better way of supporting this.

That's fair. Perhaps a flushleft field in the setup argument table that takes a user-supplied array of filetypes?  E.g.,
require('mini.comment').setup{
  flushleft = { 'asciidoc' }
}

That's fair. Perhaps a flushleft field in the setup argument table that takes a user-supplied array of filetypes? E.g.,
require('mini.comment').setup{
  flushleft = { 'asciidoc' }
}

A step up, but still not the way I would like it to be supported.
I am right now toying with the idea of allowing buffer-local variable with Lua pattern defining comment. This should allow more flexibility with a relatively small code overhead. Not sure yet that it will be implemented, though.

This should be resolved in latest main.
The 'mini.comment' now has options.start_of_line option (similar to 'vim-commentary' name) which detects lines as comments only if they don't have indent.
Your use case should be solved with something like this:
au FileType asciidoc lua vim.b.minicomment_config = { options = { start_of_line = true } }


Feat(exporter): export all till all data loaded

When using external pagination and want to use the native export function, this PR will do some help. Also see #2967 .

I'm OK with the concept here, but a couple of things:

I think we should use a promise for the data, rather than doing a $timeout in a loop.  Usually when they request all the data from the server they'll get a promise back, so they can give us that promise (or chain onto it in a then, and give us the resulting promise), and we can just wait on that promise.

We need to squash all the commits into a single commit before merging.

Is it OK now? I am not familiar with promise, sorry for that.

@PaulL1 any chance you couuld look at this again?

OK, there's a couple gremlins there, but I need to test it anyway, so I'll merge then update.  I'm not quite sure what the callback function does - I think it's not needed with the promise.  And I think in the tutorial we can directly return the $http promise rather than creating a new deferred.  But I'll run it and check.

I've updated the code a bit for some usage of deferred - I think you'd chained too many things together.
You can directly set the total items and data in the success block of the $http get, and you can return the promise from the $http rather than creating a new one.
I've tidied up a bit in the main code too - you shouldn't need the callback function, you can just put that content into a .then block.  This avoids passing around references too much.
Overall good though - thanks for the contribution.

Thanks for the cleanup works :satisfied:

@PaulL1 Hi paul, I am looking to implement export all data to pdf on server side paging. I dont see any code here on this page for doing this. Can you please help me to implement this functionality on UI-grid server side paging. appreciate your help.

There should be code there for export all with paging - there is a callback that is triggered that asks the programmer to get "all data", which can then be exported.

@PaulL1 I am not seeing any code on this page, can you provide me a link for the code that I can refer to. I greatly appreciate your help :)

@PaulL1 Thank you, i figured the problem , when binding the Ui-grid properties i have something like this:
$scope.couponGridOptions = {
data: 'CouponsList',
enableRowSelection: true,
enableRowHeaderSelection: false, etc...
so when i use that property "data" instead of:
var getPageSuccess = function (result) {
$scope.couponGridOptions.data = result.Promotions;
$scope.couponGridOptions.totalItems = result.totalItems;
};
explicitly loading when page is successful I am had problems.

@PaulL1 I am having trouble in resetting page number, When I am on page number 2 and I have refresh button which rebinds the ui-grid, when i do that the data is getting rebind but the page number still is 2, how do i reset the page number to 1 after i click on refresh button. Any help is appreciated, lot of people asked this question but I did not find solution. Thanks

My recollection is that you can set the page number property directly when you reset the group.

Thank you very much :)  its  $scope.yourGridOptions.paginationCurrentPage = 1; in case for anyone who is looking


"amplify env pull --restore" disables apns in notifications module

Note: If your issue/bug is regarding the AWS Amplify Console service, please log it in the
Amplify Console GitHub Issue Tracker

Describe the bug
"amplify env pull --restore" disables apns in notifications module:
To Reproduce

add notifications module

add APNS channel with p12 key with CLI
amplify notifications update
? Choose the push notification channel to configure. APNS
? Do you want to enable the APNS channel Yes
? Choose authentication method used for APNs Certificate
? The certificate file path (.p12):  notif.p12
? The certificate password (if any):
MAC verified OK
✔ The APNS channel has been successfully enabled.

amplify push

verify everything works and you can send notifications

amplify env pull --restore

✔ Initialized provider successfully.
✔ Channel information retrieved for APNS
✔ Channel is not setup for FCM
✔ Channel is not setup for Email
✔ Channel is not setup for SMS
✔ The APNS channel has been disabled.
Initialized your environment successfully.
I have to run amplify notifications add to add certificate again every time anyone pulls
Expected behavior
I should only provide certificate once and it should never erase it on pull

PLEASE WE NEED THIS FIX SUDDENLY !!!

This issue also relevant to FCM and SMS channels.
@kaustavghosh06 can you please let us know what is the status of this issue?

my workaround was to manually create 2 pinpoint projects one for APNS and one for APNS_SANDBOX and then directly use their application ids from all of my environments.
let apnsConfig = [
{
// The Amazon Pinpoint project ID that you want to use when you send this
// message. Make sure that the push channel is enabled for the project that
// you choose.
applicationId: "blah",
channelType: "APNS"
},
{
applicationId: "blah",
channelType: "APNS_SANDBOX"
},
];


Add binary feature matching

Add binary feature matching using the hamming distance. The hamming crate may be useful.

I'm closing this issue for now, as I think it's pretty much covered by the linked hamming crate. Feel free to reopen if you disagree.


Support DX attachments

Please up-vote if you want this feature. Do not submit a new feature request.

Closing. We don't plan to support this feature in the near future.


creating note from abc notation

Are there any functions for creating a note from abc notation?

No, I dont think so, but I dont know the ABC notation very well.. I sit possible to give a description of a single note in ABC? If so, i think we could support it.
Otherwise you’d want to write a separate parser, that maybe uses teoria for harmonic purposes

Thanks for the reply. Yes you can give a description of a single note with abc notation.

Its now possible in tonal with this abc notation extension: http://danigb.github.io/tonal/api/module-abc-notation.html


Allow path to be merged into route config

There is no way to specify a dynamic path with regular expression.
I expect this will work, but it won't.
<route>
{
  path: "/:category(foo|bar|baz)"
}
</route>

can we merge the path as well?

What is the use case for that?

@ktsn There is no way to specify a dynamic path with regular expression, currently you have to modify the generated routes.


Installation on nixos

When I try to install calcure on nixos i get
error: taskw-2.0.0 not supported for interpreter python3.12
I'm in unstable branch, my python version is 3.12.5, calcure is 3.0.1, and its dependency python312Packages.taskw is 2.0.0.
This is probably not a error from calcure but from tasw itself.
The support for taskw was dropped in 3.1 but nixos is still in 3.0.2 in unstable and 3.0.1 in stable. Maybe updating it would fix the problem as the pipx version works.
Can the maintainer @dit7ya please update it?

That made me realize that we also need to remove taskw library from all imports and dependencies. Not sure about the error you have, but looks like outdated taskw causes the problem.


DOI regular expression fails on some cases

What version of Citation.js are you using?
@citation-js/core 0.6.1, @citation-js/plugin-doi 0.6.1
How are you running Citation.js (npm package, browser bundle, self-rolled bundle, webpack)?
npm package
Where are you running Citation.js? * The OS usually will not matter much, but the browser really does.
Firefox 105.0.3
What is your input data and code?
Input: 10.1002/1520-6394(2000)12:3<118::AID-DA2>3.0.CO;2-G
code: Cite.async("10.1002/1520-6394(2000)12:3<118::AID-DA2>3.0.CO;2-G")
What did you expect to happen, and what actually happened?
It should get the metadata but it gives This format is not supported or recognized

I checked the code and it seems the package uses an outdated regular expression recommended by Crossref.
The input is a valid doi as you can see here: https://pubmed.ncbi.nlm.nih.gov/11126185/
and it's resolvable by Crossref API: https://api.crossref.org/works/10.1002%2F1520-6394(2000)12%3A3<118%3A%3AAID-DA2>3.0.CO%3B2-G
A possible solution would be to update the regular expression as this comment suggest:
\b(10[.][0-9]{4,}(?:[.][0-9]+)*/(?:(?!["&\'])\S)+)\b

Thank you for the report. Unfortunately changing the pattern is a (small) breaking change as other plugins may have similar formats and the new overlap would break the second-loaded plugin. I don't think this matters in practice though, and I am not aware of published third-party plugins. While I mull this over, you can work-around by locally updating the type parser:
const { plugins } = require('@citation-js/core')

plugins.input.add("@doi/api", {
  parseType: {
    dataType: 'String',
    predicate: /\b(https?:\/\/(?:dx\.)?doi\.org\/(10[.][0-9]{4,}(?:[.][0-9]+)*\/(?:(?!["&\'])\S)+))\b/i,
    extends: '@else/url'
  }
})

plugins.input.add("@doi/id", {
  parseType: {
    dataType: 'String',
    predicate: /\b(10[.][0-9]{4,}(?:[.][0-9]+)*\/(?:(?!["&\'])\S)+)\b/
  }
})

(Try it online)

Thanks for the snippet and your efforts!

The DOI is a SICI. They were used mainly in the early years of Crossref and are difficult to handle, as the contain characters that break URLs unless escaped.
There is no regex that detects all valid DOIs, just the majority of them. There are very few hard rules, e.g. about the prefix, or that DOIs are case insensitive.


Merge pull request #1 from ponylang/master

eliminate need to use let when declaring typeparam values

I was about to point out this was empty, but I guess you realised first :)


hugo-cloudflare-docs package needs to be open-sourced

the hugo-cloudflare-docs package is a private dependency in our bitbucket - we need to publish it on NPM so that the docs repo can be built by non-CF contributors

AH this is the wrong repo, closing :)


Adds Request Logging Support for Debugging API Issues

@MattParr here is a suggested PR that adds support for logging the XML requests/responses that occur when communicating with the AutoTask API. This can be super helpful when troubleshooting API issues or specific failures that are not caught elsewhere. It is disabled by default via a constant in constants.py and then can be enabled via a connection parameter much the same as the other ATWS parameters.

I think this feature already exists
On Wed, 22 Jul 2020, 3:02 pm Eli Keimig<EMAIL_ADDRESS>wrote:

@MattParr https://github.com/MattParr here is a suggested PR that adds
support for logging the XML requests/responses that occur when
communicating with the AutoTask API. This can be super helpful when
troubleshooting API issues or specific failures that are not caught
elsewhere. It is disabled by default via a constant in constants.py and
then can be enabled via a connection parameter much the same as the other
ATWS parameters.
You can view, comment on, or merge this pull request online at:
https://github.com/MattParr/python-atws/pull/83
Commit Summary

add support for logging requests sent to autotask and responses
received from autotask

File Changes

M atws/connection.py
https://github.com/MattParr/python-atws/pull/83/files#diff-f277de5515fffeb963dd1b7287ecb09c
(36)
M atws/constants.py
https://github.com/MattParr/python-atws/pull/83/files#diff-bac389a2e4f080be4d08cf3f30c32846
(1)
M docs/usage.rst
https://github.com/MattParr/python-atws/pull/83/files#diff-6b8768d928ef9ab4f13707da19516369
(11)

Patch Links:

https://github.com/MattParr/python-atws/pull/83.patch
https://github.com/MattParr/python-atws/pull/83.diff

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MattParr/python-atws/pull/83, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABIM7454G2ARXBUSX3YFQY3R4ZJD3ANCNFSM4PEIIGYQ
.


CLI - separate build codegen actions

Closes #1365 and allows for further work on #1363 and others (namely Plugin Build Strategies, TBD).
CLI test cases will be fixed once #1384 is merged! Merged.
This PR entirely separates the build and codegen command functionalities.
Running polywrap codegen on a plugin project will no longer emit wrap.info into the ./build folder.
This PR also introduces a possible circular dependency issue, as some of our plugin projects will stop working once the newest CLI version is released.
A possible workaround for this is to have the build script of each project run polywrap codegen and continue with the build regardless of the result of the codegen, then removing it once we have the next release up.
Thoughts?
Remaining work/merge prerequisites:

[x] Merge #1384
[x] See what to do in regards to the circular dependency issue described above.

I have decided to solve this by adding a build:patch script to all plugin packages which attempts to run polywrap build in order to output the WRAP ABI. If it fails, a message is echoed and the script exits with code 0, making the build work for the current version polywrap in dependencies and for the new, unreleased version. This way we won't have an interruption in the build process, and can later on write out the proper codegen/build logic (which is first codegen then build AND make sure that both exit succesfully).

Can this be merged @pileks @dOrgJelli ?

@krisbitney From a standpoint of implementation - Yes, it's just a matter of being reviewed! 😄

@dOrgJelli I've performed the minimal required changes to the readme just now.
We can refactor the readme to use doc-snippets in a later PR - for now this should be it.
LMK if this works.


Reduce reliance on main "canonicalize" pattern

I think the correct thing here is to do the following:

where we rely on specific canonicalization patterns as an integral part of the pass pipeline, put those patterns in a specific name passed, so that if they ever get removed/etc upstream, we don't get sudden failures without warning)
Verify that all pipelines still produce code succesfully if the canonicalization is removed/replaced with no-op

how to efficiently set all canonicalize passes to no-op? (Maybe overwrite the definition of addCanonicalizerPass to be no-op?)
how to efficiently check that the output is still "correct" even though it's now syntactically different (i.e., FileCheck tests will fail?)

The only place I know that we do this involves HEIR-owned patterns being added to the canonicalizer (for the HECO-ported pipeline). We could easily extract those into their own pass. This could also fail if patterns removed from the canonicalizer result in code that we haven't code-genned things for yet (e.g., a leftover tensor.extract that isn't yet code-genned as a manual mask+rotate)
For other cases, the proposed solution (an automated test to check if they work when canonicalize is replaced by a no-op) would be ideal, but in my opinion a relatively low priority considering everything else we have to work on. By the same token, should we check that the pipelines still work when all folders are replaced by no-ops (in every single application of the greedy rewrite engine)?
If we had to do it, I'd say the best approach would be to add a CLI flag for no-op-canonicalize, replace the heir-opt.cpp invocations of createCanonicalizerPass with a helper function that branches on "no-op" vs actually creating the canonicalizer pass, and then be deliberate about the chosen end-to-end pipeline tests to replicate with the flag enabled. Mainly the tests whose assertions only involve running the final code and asserting an expected output.


fixed the minor linting issues

The one questionable message was not so questionable in my opinion, so it has been left in. Please let me knwo if you are on the linters side and think it is questionable or if you agree.

@BenBals @sinnaj-r Any idea regarding the merge conflict? It is literaly just normal changes that need to be made for the linter. Any help would be appreciated

Just merge dev into this branch manually using the git browser and see what comes up.

@BenBals I fixed the merge conflict, it was because philip deleted that class. Once the tests pass, I will merge into development


Cosmos DB is using Jackson AfterBurner and it is causing some serious weird issues on jdk16

Describe the bug
Cosmos DB is using Jackson AfterBurner and it is causing some serious weird issues jdk16.
see details:
https://github.com/FasterXML/jackson-modules-base/tree/master/blackbird

The Afterburner has long been your engine of choice for maximum Jackson performance. But in the brave new Java 11  world, the trusty Afterburner is showing its age. It uses horrifying bytecode manipulation and cracks Unsafe.defineClass
which will stop working soon.
Blackbird is Afterburner Mk II - powered by 100% renewable Lambda based fuel.

Please remove line:
https://github.com/Azure/azure-sdk-for-java/blob/e8781bc27c8f2fd7b5d11e756f62833e806723d4/sdk/cosmos/azure-cosmos/src/main/java/com/azure/cosmos/implementation/Utils.java#L86

Hi @cemo could you share more details on the exact issues you're experiencing on jdk16?
@kushagraThapar could you help assign this to someone in Cosmos please?

@moderakh  - can you please investigate this issue ?

@cemo are you running into a specific issue? could you provide more details?
or is it more a pre-cautionary ask because of blackbird documentation?

I have been using immutables project with Cosmos DB. It has some processors to generate sources. When I narrowed the issue, it was related to AfterBurner module.
https://github.com/cemo/immutable-afterburner-issue
I had created such a project to demonstrate. You can see tests. One of them is working without Afterburner other one is failing with it.

@cemo thanks for sharing the code, do you only see this issue on jdk16 and above? are jdk11 and  jdk8 work file with respect to your repro?

jdk11 can be fine. At least I remember like that. But as I mentioned before AfterBurner project is using reflection and EOF is soon.

Running into the same issue here with AutoValue. The problem never occurred with Java 11 for us but only after upgrading to Java 17. Weird thing is, as posted above, most of the tests succeed but one particular test fails with an Afterburner reflection "warning" but the call itself just hangs. I suspect despite the warning, that deserialization is foobar'd and just blocks the whole request. Here is the stack trace:
Oct 18, 2021 5:31:14 PM com.fasterxml.jackson.module.afterburner.ser.OptimizedBeanPropertyWriter _reportProblem
WARNING: Disabling Afterburner serialization for class com.yammer.feedie.core.cosmos.model.AutoValue_MutedUserItem (field #0; mutator com.fasterxml.jackson.module.afterburner.ser.ObjectMethodPropertyWriter), due to access error (type java.lang.IllegalAccessError, message=failed to access class com.yammer.feedie.core.cosmos.model.AutoValue_MutedUserItem from class com.yammer.feedie.core.cosmos.model.AutoValue_MutedUserItem$Access4JacksonSerializerc79c2cf8 (com.yammer.feedie.core.cosmos.model.AutoValue_MutedUserItem is in unnamed module of loader 'app'; com.yammer.feedie.core.cosmos.model.AutoValue_MutedUserItem$Access4JacksonSerializerc79c2cf8 is in unnamed module of loader com.fasterxml.jackson.module.afterburner.util.MyClassLoader @3103b024))

java.lang.IllegalAccessError: failed to access class com.yammer.feedie.core.cosmos.model.AutoValue_MutedUserItem from class com.yammer.feedie.core.cosmos.model.AutoValue_MutedUserItem$Access4JacksonSerializerc79c2cf8 (com.yammer.feedie.core.cosmos.model.AutoValue_MutedUserItem is in unnamed module of loader 'app'; com.yammer.feedie.core.cosmos.model.AutoValue_MutedUserItem$Access4JacksonSerializerc79c2cf8 is in unnamed module of loader com.fasterxml.jackson.module.afterburner.util.MyClassLoader @3103b024)
	at com.yammer.feedie.core.cosmos.model.AutoValue_MutedUserItem$Access4JacksonSerializerc79c2cf8.objectGetter(com/yammer/feedie/core/cosmos/model/AutoValue_MutedUserItem$Access4JacksonSerializer.java)
	at com.fasterxml.jackson.module.afterburner.ser.ObjectMethodPropertyWriter.serializeAsField(ObjectMethodPropertyWriter.java:45)
	at com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:722)
	at com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:166)
	at com.fasterxml.jackson.databind.ser.DefaultSerializerProvider._serialize(DefaultSerializerProvider.java:480)
	at com.fasterxml.jackson.databind.ser.DefaultSerializerProvider.serializeValue(DefaultSerializerProvider.java:319)
	at com.fasterxml.jackson.databind.ObjectMapper._configAndWriteValue(ObjectMapper.java:4110)
	at com.fasterxml.jackson.databind.ObjectMapper.writeValue(ObjectMapper.java:3369)
	at com.azure.cosmos.implementation.Utils.serializeJsonToByteBuffer(Utils.java:647)
	at com.azure.cosmos.implementation.InternalObjectNode.serializeJsonToByteBuffer(InternalObjectNode.java:116)
	at com.azure.cosmos.BridgeInternal.serializeJsonToByteBuffer(BridgeInternal.java:110)
	at com.azure.cosmos.implementation.RxDocumentClientImpl.getCreateDocumentRequest(RxDocumentClientImpl.java:1382)
	at com.azure.cosmos.implementation.RxDocumentClientImpl.createDocumentInternal(RxDocumentClientImpl.java:1707)
	at com.azure.cosmos.implementation.RxDocumentClientImpl.lambda$createDocument$35(RxDocumentClientImpl.java:1699)
	at com.azure.cosmos.implementation.ObservableHelper.lambda$inlineIfPossibleAsObs$1(ObservableHelper.java:44)
	at com.azure.cosmos.implementation.BackoffRetryUtility.lambda$executeRetry$0(BackoffRetryUtility.java:36)
	at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:44)
	at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:64)
	at reactor.core.publisher.FluxRetryWhen.subscribe(FluxRetryWhen.java:76)
	at reactor.core.publisher.MonoRetryWhen.subscribeOrReturn(MonoRetryWhen.java:46)
	at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:57)
	at reactor.core.publisher.MonoDeferContextual.subscribe(MonoDeferContextual.java:55)
	at reactor.core.publisher.Mono.subscribe(Mono.java:4150)
	at reactor.core.publisher.FluxFlatMap.trySubscribeScalarMap(FluxFlatMap.java:200)
	at reactor.core.publisher.MonoFlatMap.subscribeOrReturn(MonoFlatMap.java:53)
	at reactor.core.publisher.Mono.subscribe(Mono.java:4135)
	at reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onError(FluxOnErrorResume.java:103)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onError(MonoFlatMap.java:172)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.FluxDoOnEach$DoOnEachSubscriber.onError(FluxDoOnEach.java:195)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.MonoPeekTerminal$MonoTerminalPeekSubscriber.onError(MonoPeekTerminal.java:258)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.MonoPeekTerminal$MonoTerminalPeekSubscriber.onError(MonoPeekTerminal.java:258)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.MonoPeekTerminal$MonoTerminalPeekSubscriber.onError(MonoPeekTerminal.java:258)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.MonoPeekTerminal$MonoTerminalPeekSubscriber.onError(MonoPeekTerminal.java:258)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.FluxPeekFuseable$PeekFuseableConditionalSubscriber.onError(FluxPeekFuseable.java:553)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.MonoSingle$SingleSubscriber.onError(MonoSingle.java:150)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onError(FluxMapFuseable.java:140)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.SerializedSubscriber.onError(SerializedSubscriber.java:124)
	at reactor.core.publisher.FluxRetryWhen$RetryWhenMainSubscriber.whenError(FluxRetryWhen.java:224)
	at reactor.core.publisher.FluxRetryWhen$RetryWhenOtherSubscriber.onError(FluxRetryWhen.java:273)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.checkTerminated(FluxFlatMap.java:842)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.drainLoop(FluxFlatMap.java:608)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.drain(FluxFlatMap.java:588)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.innerError(FluxFlatMap.java:863)
	at reactor.core.publisher.FluxFlatMap$FlatMapInner.onError(FluxFlatMap.java:990)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.checkTerminated(FluxFlatMap.java:842)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.drainLoop(FluxFlatMap.java:608)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.drain(FluxFlatMap.java:588)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.onError(FluxFlatMap.java:451)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.onNext(FluxFlatMap.java:416)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onNext(FluxOnAssembly.java:387)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onNext(FluxOnAssembly.java:387)
	at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2397)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.request(FluxOnAssembly.java:497)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.request(FluxOnAssembly.java:497)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.onSubscribe(FluxFlatMap.java:371)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onSubscribe(FluxOnAssembly.java:481)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onSubscribe(FluxOnAssembly.java:481)
	at reactor.core.publisher.FluxFlatMap.trySubscribeScalarMap(FluxFlatMap.java:192)
	at reactor.core.publisher.MonoFlatMap.subscribeOrReturn(MonoFlatMap.java:53)
	at reactor.core.publisher.Flux.subscribe(Flux.java:8213)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.onNext(FluxFlatMap.java:426)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onNext(FluxOnAssembly.java:387)
	at reactor.core.publisher.FluxMap$MapSubscriber.onNext(FluxMap.java:120)
	at reactor.core.publisher.EmitterProcessor.drain(EmitterProcessor.java:491)
	at reactor.core.publisher.EmitterProcessor.tryEmitNext(EmitterProcessor.java:299)
	at reactor.core.publisher.SinkManySerialized.tryEmitNext(SinkManySerialized.java:97)
	at reactor.core.publisher.InternalManySink.emitNext(InternalManySink.java:27)
	at reactor.core.publisher.FluxRetryWhen$RetryWhenMainSubscriber.onError(FluxRetryWhen.java:189)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.secondError(MonoFlatMap.java:192)
	at reactor.core.publisher.MonoFlatMap$FlatMapInner.onError(MonoFlatMap.java:259)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onError(FluxMapFuseable.java:140)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onError(MonoFlatMap.java:172)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.MonoPeekTerminal$MonoTerminalPeekSubscriber.onError(MonoPeekTerminal.java:258)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onError(FluxOnErrorResume.java:106)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:142)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onNext(FluxOnAssembly.java:387)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onNext(FluxOnAssembly.java:387)
	at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2397)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.request(FluxOnAssembly.java:497)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.request(FluxOnAssembly.java:497)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onSubscribe(MonoFlatMap.java:110)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onSubscribe(FluxOnAssembly.java:481)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onSubscribe(FluxOnAssembly.java:481)
	at reactor.core.publisher.FluxFlatMap.trySubscribeScalarMap(FluxFlatMap.java:192)
	at reactor.core.publisher.MonoFlatMap.subscribeOrReturn(MonoFlatMap.java:53)
	at reactor.core.publisher.Mono.subscribe(Mono.java:4135)
	at reactor.core.publisher.FluxFlatMap.trySubscribeScalarMap(FluxFlatMap.java:200)
	at reactor.core.publisher.MonoFlatMap.subscribeOrReturn(MonoFlatMap.java:53)
	at reactor.core.publisher.Mono.subscribe(Mono.java:4135)
	at reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onError(FluxOnErrorResume.java:103)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.SerializedSubscriber.onError(SerializedSubscriber.java:124)
	at reactor.core.publisher.FluxRetryWhen$RetryWhenMainSubscriber.whenError(FluxRetryWhen.java:224)
	at reactor.core.publisher.FluxRetryWhen$RetryWhenOtherSubscriber.onError(FluxRetryWhen.java:273)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.checkTerminated(FluxFlatMap.java:842)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.drainLoop(FluxFlatMap.java:608)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.drain(FluxFlatMap.java:588)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.innerError(FluxFlatMap.java:863)
	at reactor.core.publisher.FluxFlatMap$FlatMapInner.onError(FluxFlatMap.java:990)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.Operators.error(Operators.java:197)
	at reactor.core.publisher.FluxFlatMap.trySubscribeScalarMap(FluxFlatMap.java:182)
	at reactor.core.publisher.FluxFlatMap.subscribeOrReturn(FluxFlatMap.java:93)
	at reactor.core.publisher.Flux.subscribe(Flux.java:8213)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.onNext(FluxFlatMap.java:426)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onNext(FluxOnAssembly.java:387)
	at reactor.core.publisher.FluxMap$MapSubscriber.onNext(FluxMap.java:120)
	at reactor.core.publisher.EmitterProcessor.drain(EmitterProcessor.java:491)
	at reactor.core.publisher.EmitterProcessor.tryEmitNext(EmitterProcessor.java:299)
	at reactor.core.publisher.SinkManySerialized.tryEmitNext(SinkManySerialized.java:97)
	at reactor.core.publisher.InternalManySink.emitNext(InternalManySink.java:27)
	at reactor.core.publisher.FluxRetryWhen$RetryWhenMainSubscriber.onError(FluxRetryWhen.java:189)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:142)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onNext(FluxOnAssembly.java:387)
	at reactor.core.publisher.Operators$MonoInnerProducerBase.complete(Operators.java:2659)
	at reactor.core.publisher.MonoSingle$SingleSubscriber.onComplete(MonoSingle.java:180)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onComplete(FluxOnAssembly.java:397)
	at reactor.core.publisher.FluxPeekFuseable$PeekFuseableSubscriber.onComplete(FluxPeekFuseable.java:277)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onComplete(FluxOnAssembly.java:397)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onComplete(FluxOnAssembly.java:397)
	at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:151)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onNext(FluxOnAssembly.java:387)
	at reactor.core.publisher.Operators$MonoInnerProducerBase.complete(Operators.java:2659)
	at reactor.core.publisher.MonoSingle$SingleSubscriber.onComplete(MonoSingle.java:180)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onComplete(FluxOnAssembly.java:397)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.checkTerminated(FluxFlatMap.java:846)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.drainLoop(FluxFlatMap.java:608)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.innerComplete(FluxFlatMap.java:894)
	at reactor.core.publisher.FluxFlatMap$FlatMapInner.onComplete(FluxFlatMap.java:997)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onComplete(FluxOnAssembly.java:397)
	at reactor.core.publisher.FluxSwitchIfEmpty$SwitchIfEmptySubscriber.onComplete(FluxSwitchIfEmpty.java:84)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onComplete(FluxOnAssembly.java:397)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onComplete(FluxOnAssembly.java:397)
	at reactor.core.publisher.FluxConcatArray$ConcatArraySubscriber.onComplete(FluxConcatArray.java:192)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onComplete(FluxOnAssembly.java:397)
	at reactor.core.publisher.MonoIgnoreElements$IgnoreElementsSubscriber.onComplete(MonoIgnoreElements.java:88)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onComplete(FluxOnAssembly.java:397)
	at reactor.core.publisher.FluxTakeUntil$TakeUntilPredicateSubscriber.onComplete(FluxTakeUntil.java:120)
	at reactor.core.publisher.FluxTakeUntil$TakeUntilPredicateSubscriber.onNext(FluxTakeUntil.java:98)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onNext(FluxOnAssembly.java:387)
	at reactor.core.publisher.FluxRepeatPredicate$RepeatPredicateSubscriber.onNext(FluxRepeatPredicate.java:85)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onNext(FluxOnAssembly.java:387)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onNext(FluxOnAssembly.java:387)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onNext(FluxOnAssembly.java:387)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:127)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onNext(FluxOnAssembly.java:387)
	at reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onNext(FluxOnErrorResume.java:79)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onNext(FluxOnAssembly.java:387)
	at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1815)
	at reactor.core.publisher.MonoCollectList$MonoCollectListSubscriber.onComplete(MonoCollectList.java:128)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onComplete(FluxOnAssembly.java:397)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.checkTerminated(FluxFlatMap.java:846)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.drainLoop(FluxFlatMap.java:608)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.innerComplete(FluxFlatMap.java:894)
	at reactor.core.publisher.FluxFlatMap$FlatMapInner.onComplete(FluxFlatMap.java:997)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onComplete(FluxOnAssembly.java:397)
	at reactor.core.publisher.Operators$MultiSubscriptionSubscriber.onComplete(Operators.java:2057)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onComplete(FluxOnAssembly.java:397)
	at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2399)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.request(FluxOnAssembly.java:497)
	at reactor.core.publisher.Operators$MultiSubscriptionSubscriber.set(Operators.java:2193)
	at reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onSubscribe(FluxOnErrorResume.java:74)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onSubscribe(FluxOnAssembly.java:481)
	at reactor.core.publisher.FluxJust.subscribe(FluxJust.java:68)
	at reactor.core.publisher.Flux.subscribe(Flux.java:8227)
	at reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onError(FluxOnErrorResume.java:103)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.checkTerminated(FluxFlatMap.java:842)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.drainLoop(FluxFlatMap.java:608)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.drain(FluxFlatMap.java:588)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.onError(FluxFlatMap.java:451)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.FluxContextWrite$ContextWriteSubscriber.onError(FluxContextWrite.java:121)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.FluxDoFinally$DoFinallySubscriber.onError(FluxDoFinally.java:136)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onError(FluxOnErrorResume.java:106)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.Operators.error(Operators.java:197)
	at reactor.core.publisher.MonoError.subscribe(MonoError.java:52)
	at reactor.core.publisher.Mono.subscribe(Mono.java:4150)
	at reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onError(FluxOnErrorResume.java:103)
	at reactor.core.publisher.FluxOnAssembly$OnAssemblySubscriber.onError(FluxOnAssembly.java:392)
	at reactor.core.publisher.MonoCompletionStage.lambda$subscribe$0(MonoCompletionStage.java:76)
	at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:863)
	at java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:841)
	at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
	at java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2162)
	at com.azure.cosmos.implementation.directconnectivity.rntbd.RntbdRequestManager.messageReceived(RntbdRequestManager.java:865)
	at com.azure.cosmos.implementation.directconnectivity.rntbd.RntbdRequestManager.channelRead(RntbdRequestManager.java:181)

Alternatively, since latest Jackson is removing afterburner it may be just easier to let it go entirely as suggested above.

I actually ended up monkey patching the afterburner module itself to be a dummy module and this fixed the problem for us, so it's definitely to do with some afterburner bug in Java 16+.

Also see comments here.
Blackbird might be the right replacement for Afterburner, at least with J9+.


Minor improvement: Make max_items Option rather than u8

Currently max_items is Option<u8> which imposes a maximum item count of 255, which is not enough to parse the aws provider's schema.
This change ups that to u16 (seems big enough to me).

Thanks for the improvement Robert.

Any chance you could release this on crates? The version on there still suffers from the u8 issue.
Also, why not u32 or something? This doesn't seem like the sort of tool that needs to economize on memory.


Revert "nix: improve redacted nix error (#1776)"

Summary
How was it tested?

Current dependencies on/for this PR:

main

PR #1778   👈

This stack of pull requests is managed by Graphite.

@savil fixed in #1782.


rules: Allow recorded rules expressions to be scalars.

This is useful if you want to build up a constant metric,
such as a set of alert thresholds that vary by label value.
Closes #1007

:+1: race condition, did the same one earlier :)

It did occur to me that even with this we'll still want a one() or unity() function that behaves as absent() but that always returns 1 - so we could just rely on that. I still think this is cleaner for this use case though..


No API detected

My attempts to use this result in 'No API detected'
I have tried to run the suggested action by pressing enter.
I have also run 'harvest'
Same issue continues to occur.

Hello @olitreadwell, it seems the api is not built correctly. First, delete any file in ~/Library/Caches/com.runningwithcrayons.Alfred/Workflow Data/com.benjamino.emoji_wine. Then check that you have python 3.8 or above with python --version and ensure you have pillow with which pillow command in your terminal. If everything seems ok, would you mind opening the Alfred debugger and telling me what's the error message ? See here on how to use it.

@olitreadwell could you try using the latest release v1.2.2 ?

@BenjaminOddou You’re hardcoding pillow_dir = '/usr/local/Cellar/pillow' which will not work on Apple Silicon Macs, because Homebrew installs to /opt/homebrew there.

Installing dependencies has worked for me.

@BenjaminOddou You’re hardcoding pillow_dir = '/usr/local/Cellar/pillow' which will not work on Apple Silicon Macs, because Homebrew installs to /opt/homebrew there.

Do you have the full path of pillow dependency installed via homebrew with apple silicon chips ? I'll recode that part. Don't hesitate to make a pull request

It follows the same pattern: /opt/homebrew/Cellar/pillow. But is it worth doing at all? Seems like this was just a matter of missing dependencies. Alfred already includes both Homebrew paths so no need to link to the specific Python version or anything.
A suggestion is to instead try to run a simple pillow command and on failure tell the user they may be missing the dependency. You can open alfredpreferences://navigateto/workflows>resolvedependencies to send people directly to the dependencies manager.

It seems that when running the python script, the pillow dependency installed with homebrew is not included in pythonpath by default.

Check the Dependencies Manager. Does Python ask to be installed? Homebrew separates python per version and that matters regarding which version Pillow is built against.

I have python 3.11 installed and my pillow version is located here /usr/local/Cellar/pillow/10.0.0.
==> pillow: stable 10.0.0 (bottled), HEAD
Friendly PIL fork (Python Imaging Library)
https://python-pillow.org
/usr/local/Cellar/pillow/10.0.0 (243 files, 4.6MB) *
  Poured from bottle using the formulae.brew.sh API on 2023-07-17 at 21:23:55
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/pillow.rb
License: HPND
==> Dependencies
Build: pkg-config ✔<EMAIL_ADDRESS>✔<EMAIL_ADDRESS>✔
Required: jpeg-turbo ✔, libimagequant ✔, libraqm ✔, libtiff ✔, libxcb ✔, little-cms2 ✔, openjpeg ✔, tcl-tk ✔, webp ✔

print(sys.path)
['~/Library/Application Support/Alfred/Alfred.alfredpreferences/workflows/user.workflow.8B870FAD-33DF-4867-AF18-0FE255A691FF'<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>'/usr/local/lib/python3.11/site-packages']

The problem is that /usr/local/Cellar/<Homebrew package>/nested_folder/ link is not included in the path. Normally I would include a ./lib folder path if I bundle the library but this time it's a bit trickier.


Pay

https://github.com/GoogleCloudPlatform/java-docs-samples/blame/57373926927d0a19880c86294e0b998eab869108/auth/src/main/java/LookupApiKey.java#L24

@BornNk please add in more context of what is happening and how we can tweak it.


Add dockerfile alias for docker language

Hello, this patch adds a new alias for Dockerfiles - dockerfile. For example, GitHub Markdown uses Dockerfile for highlighting Dockerfiles.
Thanks for considering merging it.

Thanks!


[Bug]: Handoff activity does not get triggered when the deeplink URL message is sent from M365 Copilot (or any other client)

Language
Javascript/Typescript
Version
latest
Description
Following this Developer Guide, I've created both the BotFramework project, based on this repository, and the Teams AI Library project - both implementing the handoff use case scenario.
While the BotFramework project is property get triggered every time the deeplink URL (https://teams.microsoft.com/l/chat/0/0?users=28:${botId}&continuationToken=${continuationToken}) is clicked from M365 Copilot response, the Teams AI Library seems to ignore this event.
The sample of the handoff code implementation using Teams AI Library can be viewed here: https://github.com/microsoft/teams-copilot-starter/blob/main/src/bot/teamsAI.ts#L377
Reproduction Steps
1.Add handoff handler to your Bot
2. Using M365 Copilot and the Developer Guide (link provided above) implement the Copilot plugin that returns the item containing the deeplink ("https://teams.microsoft.com/l/chat/0/0?users=28:${botId}&continuationToken=${continuationToken}") to the Bot chat.
3. When clicking on the deeplink URL, the Bot's chat is opened, but nothing is received in the bot handoff handler (nor there any other activities are triggered)
...
The expected behavior:
3. when clicking on the deeplink URL, the Bot's chat is opened and the Bot's handoff handler receives the activity containing the `continuationToken` passed in the deeplink URL.

@dannygar is the bot receiving an activity payload to your endpoint /api/messages before the adapter.process is called?

also it looks like your deeplike is not following the design document that states to use query param continuation not continuationToken


Add custom entrypoint to generate the configuration

Having to rebuild an image only to include the configuration is not ideal. This PR adds an rudimentary way to create the Caddyfile.

I made a change to the entrypoint, to make the PR a non-breaking change.


Add #[dead_code] to the Rust generated bindings.

This uses attributes on each pub mod instead of one at the top of the file, because wit-bindgen's output can sometimes be nested inside of other constructs.
Fixes #896.

This looks reasonable to me, although unfortunately there's not a great way to test this. I believe macro-generated code is generally automatically exempt from this lint which is why this hasn't cropped up before. Could you try running the test suite with WIT_BINDGEN_DEBUG=1 set? That should simulate rustc not seeing macro-generated code and it may serve for at least locally verifying that no extra warnings are generated.
I think, for example, that this won't handle dead code related to top-level world types/imports, only those in packages/interfaces.

I've tested that this PR fixes the warnings eported in #896.
I've now also run the tests with WIT_BINDGEN_DEBUG however that hits several pre-existing errors. I filed #900 to fix some warnings, at least.


Building on Windows : scripts/build_host_protoc.bat now fails (where are third_party files?)

Hi Guys,
I'm following the Windows Build from Source procedure.
I clone https://github.com/caffe2/caffe2 into a fresh local repository, and try to run scripts/build_host_protoc.bat. It now fails with error message
CMake Error: The source directory "C:/home/Tools/caffe2/third_party/protobuf/cmake" does not exist.
I am reasonably sure that this batch file used to work on earlier versions of Caffe2 but I guess it is possible that I am misremembering. Is something broken, or did something change, or am I doing something wrong?
EDIT: In fact it looks like there are no files at all under caffe2/third_party in my new local repository. I can see the folders exist, but there are no files under them at all.
Thanks!

you need to git clone in recursive mode to download protobuf submodules

Oh dammit! Thank you @jackyko1991, I am sure that's my problem. I appreciate your taking the time to help a noob!
Cheers,
Wilf


Kill subprocesses using psutils

When debug adapter ends, ensure we kill the entire process tree using the tree-kill npm package (tree-kill is something thats already used)

Option 1:

After DA shutsdown, call treekill on the parent process.
We already do this, & as we have users reporting issues, this means only one thing - its not working. After all, the parent process is already dead (killed by PTVSD itself - in response to shutdown request)!

Option 2:

TS DA, intercepts all messages and acts as a proxy. Today the TA DA listens to messages, it does not intercept it.
Once a shutdown request is received, TS DA could then decide to manually kill the python process using treekill, and then send the other DA messages to VSC (messages that would generally be sent back by PTVSD).

Option 3:

PTVSD does all of this.

Prescribed solution:

Use psutils to kill process tree

Blocked on https://github.com/microsoft/vscode/wiki/Roadmap#extension-authors

Possible solution

PTVSD implements proper DA host, then PTVSD can send an event back to extension
PTVSD would not kill the processes, but leave it upto the extension.
Extension can handle event and kill the processes using treekill

not needed anymore, closing for #6017


NanoMQ not forwarding data to client using persistent sessions upon re-connection

Describe the bug
I recently upgraded to version 0.10.8 of NanoMQ from 0.5.0. I am using the Paho MQTT client embedded client inside my application to connect to the broker. In the connection configuration I am disabling clean sessions and sending all MQTT payloads with QOS level 1.
In this configuration if the client disconnects from the broker and reconnects, the broker will stop forwarding the MQTT payloads for the subscribed topics to the client.
NOTE: from the clients perspective the connection request as well as the subscription requests were all valid upon reconnection.
Expected behavior
With clean session disabled and all payloads published using QOS 1; if a client disconnects and reconnects to the MQTT broker, the broker will forward all payloads for topics subscribed to by the client to the client. This includes any payloads that were sent while the client was disconnected as well as new payloads that were sent after the client reconnected.
Actual Behavior
The client does not receive any payloads from the broker after reconnecting.
To Reproduce

Run the NanoMQ broker nanomq start --url nmq-tcp://<IP_ADDRESS>:1243
Connect a client to the broker with clean sessions disabled
Continuously publish messages to a topic that the client is subscribed to
If the client disconnects and reconnects the client will no longer receive any data

One note, the exact same configuration on the client side is used between using versions 0.5.0 and 0.10.8. If I revert back to 0.5.0 I do not see this behaviour and after a disconnect+reconnect the client still receives all data from the broker.
** Environment Details **

NanoMQ versionL 0.10.8
Operating system and version: 20.04.1-Ubuntu
Compiler and language used: Clang-10

Client SDK
Paho MQTT Embedded-C Client
Additional context
Terminating NanoMQ and relaunching it resolves the issue and my application is able to receive the payloads.

Hi, Thanks for submitting this detailed issue according to the template.
As I just confirmed on code ver of  0.10.8 and 0.5.0. There is not much difference in terms of msg resending. And I also made a quick test on your scenario, the QoS 1/2 msg is successfully being resent when the client connects with a persistent session.
So I guess you might be considering to set the "qos_duration" in "nanomq.conf" to a minimum value for a faster resending.
qos_duration
The nano qos duration

Value: 1-infinity
qos_duration=2
This value controls the resend/checker timer of each client/pipe, if you set this value to 360s, then you have to wait another 360s to get the resending function started.
If this doesn't resolve your issue, please share your PAHO code/ or test it with an MQTT client tool, so that we can be guaranteed to work on the same page.

Thanks for this, we are looking into it. Are there any other settings that could possibly cause this issue? For reference, we are launching NanoMQ through another program and don't specify a nanomq.conf file. We will try the following: nanomq start --url nmq-tcp://<IP_ADDRESS>:1234 --qos_duration=2

We are still seeing this issue when setting the qos_duration to 2 . Since we are not launching using a nanomq.conf file, could any of the other defaulted settings be causing the behavior we see?

does it means, nanomq is failed to forward any msg to the client? or only the reconnected client?

Hello, I've also been able to reproduce this on the latest master (latest commit being: 116439b1aa794774ea5edbfc6a1e2d6d837120ba)
Summary:
While using nanomq, if a client is kicked for exceeding its keepalive time with clean-sessions off, the client will not be aware that it has been kicked by the broker. The client will be able to continue to send messages to the broker but no messages will ever be routed back to it. This behavior is not the case with clean-sessions enabled. The same test can be performed with the mosquitto broker and the client will indeed be able to recover and receive messages.
Steps to reproduce:
Terminal 1: Run broker with default configuration and settings:
> nanomq broker start --url nmq-tcp://<IP_ADDRESS>:1234

Terminal 2: Listen on test topic w/ mosquitto_sub
keepalive: 10s, clean-session: off, QOS: 1
> mosquitto_sub -p 1234 -t test/topic -k 10 -v -c -i test_client -q 1

Terminal 3: Publish message
> mosquitto_pub -p 1234 -t test/topic -m "test_message" -q 1

Terminal 2: Message should arrive
> mosquitto_sub -p 1234 -t test/topic -k 10 -v -c -i test_client -q 1
test/topic test_message

Terminal 2: Sleep process until kicked by the broker (ctrl-z)
mosquitto_sub -p 1234 -t test/topic -k 10 -v -c -i test_client -q 1
test/topic test_message
test/topic test_message
^Z
[1]  + 428099 suspended  mosquitto_sub -p 1234 -t test/topic -k 10 -v -c -i test_client -q 1

Terminal 1: Wait for broker to kick Terminal 2 (wait for this message to appear)
Warning: close pipe & kick client due to KeepAlive timeout!

Terminal 2: Wake up Terminal 2 (fg)
> fg
[1]  + 428099 continued  mosquitto_sub -p 1234 -t test/topic -k 10 -v -c -i test_client -q 1

Terminal 3: Transmit another test message
> mosquitto_pub -p 1234 -t test/topic -m "test_message_2" -q 1

Terminal 2: Notice that this message (or any subsequent messages) do not arrive and the client is unaware that it has been kicked.
This is basically irrecoverable at this point.
Terminal 4: Perform the same steps above with the mosquitto broker and observe that after the subscriber is awoken, it is able to receive messages.
> mosquitto -p 1234 -v

Before you guys reply me with your thoughts, I have submitted a PR to make it work as the same way of mosquito.

@JaylinYu
For session keeping, NanoMQ doesn't close the TCP socket explicitly, leaving this work to the client, this is the original design for reusing sockets. So in this case, NanoMQ take this client as a cached client still, all msg routed to this client will be stored.

For this thought, how is the client expected to know to close the socket? When the client is kicked does nanoMQ send some indication to the client itself?

Thank you for the quick reply and fix. I did some testing and your commit to nng seems to fix the bug we encountered.
I first tested that once kicked, the client is informed of the disconnect via the closed socket and therefore is able to reconnect and receive new messages.
I also tested the scenario where messages are published while the subscriber is asleep and those are delivered once the subscriber reconnects.
FWIW I do see some internal error logs from the broker that may or may not be interesting to you. Otherwise, it seems to behave properly after some quick testing.
Warning: close pipe & kick client due to KeepAlive timeout!
2023-03-17 10:21:51 [17979] WARN  /home/nschiffer/nanomq/nng/src/sp/transport/mqtt/broker_tcp.c:609 tcptran_pipe_recv_cb: nni aio recv error!! Object closed

2023-03-17 10:21:51 [17979] WARN  /home/nschiffer/nanomq/nng/src/sp/transport/mqtt/broker_tcp.c:609 tcptran_pipe_recv_cb: nni aio recv error!! Object closed

2023-03-17 10:21:51 [17979] WARN  /home/nschiffer/nanomq/nng/src/sp/transport/mqtt/broker_tcp.c:857 tcptran_pipe_recv_cb: tcptran_pipe_recv_cb: recv error rv: 139

2023-03-17 10:21:51 [17979] WARN  /home/nschiffer/nanomq/nng/src/sp/transport/mqtt/broker_tcp.c:857 tcptran_pipe_recv_cb: tcptran_pipe_recv_cb: recv error rv: 139

@JaylinYu Thank you for the quick reply and fix. I did some testing and your commit to nng seems to fix the bug we encountered.
❯ mosquitto_sub -p 1234 -t test/topic -k 10 -v -c -i test_client -q 1
test/topic test_message
^Z
[1]  + 18061 suspended  mosquitto_sub -p 1234 -t test/topic -k 10 -v -c -i test_client -q 1
❯ fg
[1]  + 18061 continued  mosquitto_sub -p 1234 -t test/topic -k 10 -v -c -i test_client -q 1
test/topic test_message     <-- sent while subscriber was asleep but before kick
test/topic test_message     <-- rx'd again
test/topic test_message     <-- rx'd again
test/topic test_message_2   <-- sent while subscriber was asleep but after kick
test/topic test_message_3   <-- sent after subscriber was woken up and reconnected

I first tested that once kicked, the client is informed of the disconnect via the closed socket and therefore is able to reconnect and receive new messages.
I also tested the scenario where messages are published while the subscriber is asleep and those are delivered once the subscriber reconnects. I sent messages while the subscriber was asleep before and after the kick. The messages sent before the kick are received a few times, but that is allowed with QOS1.
FWIW I do see some internal warning logs from the broker that may or may not be interesting to you. Otherwise, it seems to behave properly after some quick testing.
Warning: close pipe & kick client due to KeepAlive timeout!
2023-03-17 10:21:51 [17979] WARN  /home/nschiffer/nanomq/nng/src/sp/transport/mqtt/broker_tcp.c:609 tcptran_pipe_recv_cb: nni aio recv error!! Object closed

2023-03-17 10:21:51 [17979] WARN  /home/nschiffer/nanomq/nng/src/sp/transport/mqtt/broker_tcp.c:609 tcptran_pipe_recv_cb: nni aio recv error!! Object closed

2023-03-17 10:21:51 [17979] WARN  /home/nschiffer/nanomq/nng/src/sp/transport/mqtt/broker_tcp.c:857 tcptran_pipe_recv_cb: tcptran_pipe_recv_cb: recv error rv: 139

2023-03-17 10:21:51 [17979] WARN  /home/nschiffer/nanomq/nng/src/sp/transport/mqtt/broker_tcp.c:857 tcptran_pipe_recv_cb: tcptran_pipe_recv_cb: recv error rv: 139

Glad my PR works. Yes, only QoS 1 msg will be cached when session is kept.
Dont mind those logs, it just means client is being disconnected.

For this thought, how is the client expected to know to close the socket? When the client is kicked does nanoMQ send some indication to the client itself?

My original idea was like: never let client knows if it is still using the same socket of pre-existed connection. This is usually happens in real case in poor network situation. Networking is off for a while, both side of TCP is silence and will not send FIN to close the socket. And I think it is better to get over with it once the network back to normal (the disconnect is fired on MQTT layer).
However, you are right, currently NanoMQ expect client to send CONNECT when resumming the session, I would like to make it be like auto-recovering (session gonna be restored when any packet like PINGREQ is received?)

I gonna close this issue and convert it to discussion


Instagram Feature

What does this PR do?
This is an example asset for Screenly as part of the Screenly Playground.
It adds a folder to the Screenly playground containing a simple HTML file that can be edited to fetch the latest images from an Instagram account and displayed as a 2*2 grid on Screenly
What is the relevant GitHub Issue?
Checklist

[x] I've added tests for the relevant code
[x] The code passes linting (for the relevant language)
[x] I've tested the design in all supported resolutions
[x] I've attached relevant screenshots (to speed up code review)
[x] The final implementation is pixel perfect to the Figma design

Screenshots
The screenshot below is the web page using the default image and an example caption.

The screenshot below is the final product after adding the Instagram access token to the code, from my personal Instagram account.

@iamlawrenceonoja This doesn't look right:

Please fix the SVG version and delete the JPG version.

@iamlawrenceonoja This doesn't look right:

Please fix the SVG version and delete the JPG version.

I opened the svg image in Github and it is working fine on my end.

Since we are using multiple files, and Screenly (currently) requires a single HTML file, we need to combine these into one during the CI workflow.
One way to do this is to use inliner, which seems rather straight forward. The workflow would look something like this:
[...]
      - name: Setup Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '16'

      - name: Cache dependencies
        uses: actions/cache@v2
        with:
          path: ~/.npm
          key: npm-${{ hashFiles('package-lock.json') }}
          restore-keys: npm-

      - name: Install dependencies
         run: npm install -g<EMAIL_ADDRESS>
      - name: Combine and minimize code
         run: inliner index.html > output.html
[...]

The following things need to be addressed:

Aspect ratio of the photos is completely off (they're stretched)
There's no reason why there would be scroll bars, so there's probably something wrong with the site layout

Superseded by https://github.com/Screenly/playground/pull/53


Set pane name when hash is passed to panes config

Motivation
tmux allows setting pane titles and with the set-option set-title on it is possible to pass these on to the terminal emulator e.g konsole, gnome-terminal, etc.
man tmux

When a pane is first created, its title is the hostname.  A pane's title
can be set via the OSC title setting sequence, for example:
      $ printf '\033]2;My Title\033\\'

Example config
windows:
  - editor:
      pre:
        - echo "I get run in each pane, before each pane command!"
        -
      layout: main-vertical
      panes:
        - vim
        - #empty, will just run plain bash
        - top
        # The following pane will have the name of the hash/dict
        - pane_with_multiple_commands:
            - ssh server
            - echo "Hello"

Result
When calling display-message -p "#{pane_title}" in tmux, the pane title (or the window title if the pane title isn't set) is returned
Tests have been added and rubocop is ok with it too.
Extra
I was running on windows machine and had no way of testing, so I added a Vagrantfile with the bare minimum.

OK, a couple thoughts:

Just looking at this, it's not really clear what some of the implications are...  E.g. the newly-defined Pane#commands accessor method adds printf '\033]2;My Title\033\\' to the command array without checking the extant commands already there.  Further, Pane#name is also overridden, its definition substantively changing.  There is but one test for the former and none for the latter; DAE think that we need some more edge cases covered here?
Once we've decided what should happen, it's going to need to be documented in the README and the change added to the CHANGELOG (please see the contributing guide).  This alone may alleviate my concerns WRT edge cases, so maybe start there?
While I don't have anything in particular against including a Vagrantfile in the project, that shouldn't be mixed in with a functional PR.  I'd suggest creating a separate issue for lack of vagrant support and submit a PR with only those changes.  Then re-submit this one independently, so the team can decide each on their own merits.

Hi @adamstrickland
This was indeed a quick and dirty (possibly too dirty) PR while on holiday.
Thanks for having a look. I'll see when there's time again to address all your concerns to possibly get this in.
Would a "flag" at the project or window level make this PR more acceptable (of course with all the other concerns addressed)? e.g
pane_titles: True  # Project level flag
windows:
  - editor:
     pane_titles: True # Window level flag

Cheers

@LoveIsGrief not sure a flag is the right answer...
I feel as though my comments were taken to be critical of the intent of the PR; far from it, I think this is a good change.  But it's a change nonetheless, which means we have to make sure it's documented in the README and noted in the CHANGELOG (per the contribution guidelines).  I do think that there's probably some edge cases that should be covered by tests, but this is a gut-feel more than anything else (@Soliah, @ethagnawl, @J3RN any opinions?).  IMO it's just better to work through any issues before we merge it in than after.
As for the Vagrant stuff, again, I'm not against it, but it'd just be better to not mix it in with this functionality. I don't see us rejecting that (it's not very invasive), but personally I haven't used Vagrant in years, so someone with fresher knowledge in that area would be better-suited to take a look at that.  Looks like you could simply create a branch with just a6e5862, fc1feb3, and e42416a and submit that as a PR, and then either push this without Vagrant support (probably best) or rebase it off the vagrant branch.  While you're at it, you could probably also squash 92008a1 and 4016bcf, as well.

A few thoughts:

Since Pane#name is being overloaded, perhaps we should change title to name or vice versa?
A few tests which document the different paths Pane#name could take would be nice.
I think a helper method or some named variables would help make Pane#commands more readable, maintainable and extensible.
The introduction of a Vagrant file should be broken out into its own PR.

Thank you for this contribution @LoveIsGrief. I'm sorry that it sat dormant for so long.
However, I think a better (i.e. persistent) way forward would be to use a user provided variable and pane-border-format.

Hi.
Don't worry about it. I think it was a quick hack. It's so old now :joy:
Have a great day


Double slash on GCP leads to error

We are using the plugin in sarek here. When we have an outdir with a trailing slash, it leads to the following error:
The workflow execution failed to start. Exit status: 1

tee: /.nextflow/cache/nf-5A4aMc8MihPfiZ.txt: No such file or directory
N E X T F L O W  ~  version 24.04.2
Pulling FriederikeHanssen/sarek ...
 downloaded from https://github.com/FriederikeHanssen/sarek.git
Launching `https://github.com/FriederikeHanssen/sarek` [pedantic_wiles] DSL2 - revision: ec7bf3e65f [issue_1580]
Downloading plugin<EMAIL_ADDRESS>Downloading plugin<EMAIL_ADDRESS>ERROR ~ I/O not allowed on dot-dirs or extra slashes when !permitEmptyPathComponents: /rike/test_with_trailing_slash//pipeline_info/manifest_2024-07-02_15-14-49.bco.json

Other elements in that config work with a very similar output name declaration (i.e . https://github.com/nf-core/sarek/blob/b5b766d3b4ac89864f2fa07441cdc8844e70a79e/nextflow.config#L381) , which made us wonder if there is anything in particular to how this is handeled in this plugin.

Try<EMAIL_ADDRESS>and let me know if it's fixed


Does ScatterText somehow combine tokens?

I have many cases where two tokens such as བྱང་ཆུབ་ and སེམས་དཔ become a single thing in the scatterplot. Is this something that ScatterText is doing? The tokenizer I'm using does not do that.

Could you please provide a runnable example to show this? It's possible the tokenizer is merging those two words into a single token, or Scattertext ended up aligning them in the labeling phase.

But please submit a reproducible example of where this occurs. Otherwise, there's nothing I can do to look into this.

Just wanted to first know if there is a possibility for something like that happening which you are aware of.
The small background is that I'm very familiar with the tokenizer I'm using (botok), and am 100% sure it is not the cause of this as I've stared at material tokenized by it for thousands of hours.
Here is the data I'm using:
tibetan_strings.txt
Here is the one-liner to read it to ensure consistency with the way I have it:
open('tibetan_strings.txt', 'r').readlines()[0].split(' ')
Here is the wrapper for the tokenizer I'm using, inspired by the the chinese_nlp example:
import re
from botok import WordTokenizer
tokenizer = WordTokenizer()

class Tok(object):

    def __init__(self, pos, lem, orth, low, ent_type, tag):
        self.pos_ = pos
        self.lemma_ = lem
        self.lower_ = low
        self.orth_ = orth
        self.ent_type_ = ent_type
        self.tag_ = tag

    def __repr__(self): return self.orth_

    def __str__(self): return self.orth_

class Doc(object):

    def __init__(self, sents, raw):
        self.sents = sents
        self.string = raw
        self.text = raw

    def __str__(self):
        return ' '.join(str(sent) for sent in self.sents)

    def __repr__(self):
        return self.__str__()

    def __iter__(self):
        for sent in self.sents:
            for tok in sent:
                yield tok

class Sentence(object):

    def __init__(self, toks, raw):
        self.toks = toks
        self.raw = raw

    def __iter__(self):
        for tok in self.toks:
            yield tok

    def __str__(self):
        return ' '.join([str(tok) for tok in self.toks])

    def __repr__(self):
        return self.raw

import bokit
punct_list = bokit.utils.create_punctuation_list()

punct_str = "|".join(map(re.escape, punct_list))  # Escape special characters
punct_re = re.compile(r'^({})+$'.format(punct_str))  # Create the regex pattern

def tibetan_nlp(doc, entity_type=None, tag_type=None):

    toks = []

    for tok_obj in tokenizer.tokenize(doc):
        tok = tok_obj['text_unaffixed']
        pos = tok_obj['pos']

        if tok.strip() == '':
            pos = 'SPACE'
        elif punct_re.match(tok):
            pos = 'PUNCT'

        token = Tok(pos,
                    tok_obj['lemma'],
                    tok.lower(),
                    tok,
                    ent_type='' if entity_type is None else entity_type.get(tok, ''),
                    tag='' if tag_type is None else tag_type.get(tok, ''))

        toks.append(token)

    return Doc([Sentence(toks, doc)], doc)

I realize you have a lot of experience with this token, but have you programmatically checked the tokenizer's output on this file to verify that the token in question isn't there?

I realize you have a lot of experience with this token, but have you programmatically checked the tokenizer's output on this file to verify that the token in question isn't there?

Yes


Add Dominic Valenciana to contributors list.

This was a fun little exercise. I feel like I don't contribute enough outside my own projects with close friends. I appreciate the fun little task.

@Kiricon, I'm quite elated about your PR. I wanna evolve this project to addresses various problems faced by first time contributors. I'd love to learn about your journey in open source community, the problems, pain points you had etc.
Could you explain how you felt when you went through the tutorial, made a PR and learned that I accepted it?


WP-CLI and multisite

Hi, I'm having trouble to use wp-cli when multisite is enabled on Bedrock.
When these constants are defined in config/environment or config/application.php
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);

wp-cli does not return anything on the prompt (no error, nothing).
But if MULTISITE is set to false, wp-cli is ok.
This behaviour does not appear on a standard Wordpress multisite.
Anyone else have experienced these issue ?

I don't believe this is a bedrock issue. When you're on multisite, try setting the url to explicitly declare which blog you're connecting to.
http://wp-cli.org/config/
wp --url=<url>

OMG you're so right, I forgot to read this part of the doc... everything works indeed.
Thanks and sorry for this one !

@etcook :sunglasses:

@soifou I just know because I've been bitten by the same issue. WP CLI error output is not very helpful.


[Feature] Add Disk % Used to UI (without hovering)

Description of the feature
It would be cool if we could embed the % of disk used into the plots:

Then we wouldn't have to hover over the element. It would also make viewing the dashboard on a mobile device easier. You could make this the default behavior for the DASHDOT_ALWAYS_SHOW_PERCENTAGES = true option. If there was less than x% disk, you'd have to have it on the grey side. Otherwise, it would be nice to have it inside the green bar.
Additional context
No response

Hey, thanks for creating this issue. This sounds like a really great idea in theory, but I am having some issues with it:

The bars are responsive and change their size with the amount of drives as well as the amount of space available (display size). How would I make sure that the font is always viewable, centered and looks nice?
If there are some percentages on the green side and some on the gray side, it would look a bit inconsistent. But if I put them all on the left, they might overlap the border between green and gray + they might be completely on the gray side. This might not look too bad, though, so I think it could be a non-issue.

this is a good question. I suppose you could just turn the %s off when there are too many drives. You could also add a scroll bar here if this setting is enabled. Or just keep scaling the text smaller: even if it's too small to read, it's still there.
Very true, I guess having them overlap wouldn't be the end of the world. Personally, I think having the % information is worth it since the difference between 80% and 90% might be hard to tell visually, but the numbers help make decisions like "it's time to buy a bigger drive" or whatever. I know people have all these fancy systems to monitor this stuff, but a beautiful, yet simple dashboard is more than enough for a simple home server with a few drives.

Maybe I will make the bars limit to 3 per page (same as drives) and change them as well when the drives go to the next page. That would make sure there is enough space for this.
I will try this out, but currently it is a bit lower on my priority list (lots of bug-reports).

:tada: This issue has been resolved in version 4.5.0
Please check the changelog for more details.


Register the URL protocol only when installing (Windows)

The current flow use Electron's setAsDefaultProtocolClient for the registration of vscode URL protocol on windows on every startup.
This change move the registration to the setup files (like it is done with linux).

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: idanpa sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

I'm not a fan of this since the current behavior uses Electron's API, which is guaranteed to work. The only thing this fixes is the usage of URL before Code is ever run. This is very rare we haven't gotten an issue about it yet. Closing it, thanks any way!


1.3.1 doesn't save session on OSX 10.11.1

I encounter an issue with project saving with Atom 1.3.1. Here's my config  :
"*":
  "exception-reporting":
    userId: "631146f8-69d1-b154-4734-012195c538f5"
  welcome:
    showOnStartup: false
  core:
    openEmptyEditorOnStart: false
  editor:
    invisibles: {}
    fontSize: 11
    backUpBeforeSaving: true
    showInvisibles: true
  pigments: {}
  "terminal-plus":
    core: {}
    style: {}
  "save-session":
    dataSaveFolder: "/Users/radev09/.atom/packages/save-session/projects"

Can't find any same issues. Does it comes from my config or is it an issue related to the OS or something else?

Please try uninstalling the save-session package and trying again.

It works well, thanks 50Wliu! But I need to understand why it works when I remove this package. I guess more information are needed as mnquintana marked the issue. Thanks again, I will try to go deeper into this issue..

But I need to understand why it works when I remove this package.

Atom has offered this functionality since before 1.0.0, and so save-session has become mostly redundant (in fact, all of its features are now in Atom as in 1.4.0-beta0).  In addition, it seems to have stopped working entirely after Atom 1.2.0.
Glad you solved your issue!

Ok I now understand thanks a lot for all these explanations! Thank you!

Finally, I've again the same problem when I shut down the computer and when I restart it : I can't get my previous opened folders and files. Is there something else to do or is it a norma behavior of Atom?


Implement a Cache Data Store

This should be an IDataStoreProvider implementation.

The implementation should have a "backing data store" that persists data.
Caching should only be done for relatively static data (not JobHistory)
Implementation should work as a write-through cache.

Update the Web application to use this store.

Usage of this store probably should be configurable.

This is complete with a shift in the requirements.

The implementation should have a "backing data store" that persists data.
Caching should only be done for relatively static data (not JobHistory)
Implementation should work as a write-through cache.

The implementation utilizes the MockDataStoreProvider for a full in memory datastore that is initialized with data from an IDataStoreProvider that acts as the backing data store. Currently this backing data store is the SQLite implementation.
This effectively caches the entire backing data store where reads are only performed at initialization. Writes are performed against the backing data store and the in memory data store.
Memory usage will be monitored but this should be feasible for hundreds of thousands of JobHistory rows. Coupled with #10 #11 this should be maintainable.


Updated getting-started/part-2.md to properly link to Part 3

Hey @icnocop! Thanks for this. Can you please sign the CLA? It's a one-time requirement. Someone will merge this as soon as that is done. Thank you!

I signed the CLA. Thank you.

Great! Thank you for this. I've merged it.


[Bug]: Search does not show all matches

Is there an existing issue for this?

[X] I have searched the existing issues

Description
Some existing apps do not show up in the search dropdown.
Steps To Reproduce

Go to https://release.app.appsmith.com/
Search for an application.

Expected: All relevant apps should be shown in the search dropdown.
Actual: Not all relevant apps are shown in the dropdown.
Public Sample App
No response
Environment
Release
Issue video log
https://www.loom.com/share/47cf035e98ff45479964efb358435518
Version
Cloud

The search list is limited to 10 items based on the last edited history (not based on user but, in general last edited); it is not limited to selected workspace.

Will get prioritised when we have all entities (packages, workflows, environments, etc.) in production

Bumping this issue up to prod because it should have made it's way there by now if it was not fixed


Documents how to speed up extension development

Public-Facing Changes

Description

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Looking at our generated package.json I see we have a build command that runs foxglove-extension build but our scripts also run foxglove:prepublish when invoking foxglove-extension install. I find some of this confusing since I'd have thought the build script would be for building.
I'd prefer to keep foxglove:prepublish building production images since that is what is invoked during the package command. I think we should change/add commands for allowing local-install to default to development mode (with inline source maps) to aid in debugging and speed up builds.
I'm thinking the following set of scripts would be an improvement over today's setup for extension authors:

script
command

foxglove:prepublish
foxglove-extension build --mode production

local-install
foxglove-extension install --build development

package
foxglove-extension package

Users wanting to iterate with local-install will get the developer experience suited for debugging while still producing minified packages for production without having to manually change their scripts back before publishing.
cc @foxymiles @jtbandes @jhurliman

I looked into this and what I had hoped for turns out not to be so simple. Unfortunately the local-install command invokes the foxglove:prepublish script via yarn. This is the same command the package invokes. This means the two scripts both run the same command to build.
I did merge a change to include the source maps in production builds (which was broken before):
https://github.com/foxglove/create-foxglove-extension/pull/82
But unfortunately I don't see a good way to do a speedup here without a larger overhaul and a risk of folks leaving their package step in "dev" mode when they go to package.

Closing this. As I noted in my previous comment I've not found a good path forward here. In the meantime I did improve the source map situation for dev builds which I hope helps some folks during the development workflow. I understand build times can be a pain and I would welcome contribution from those that do have time to inspect what we can do here that does not require manually modifying the scripts back and forth.


chore(derive): README Touchups

Description
Small PR to touchup the README for kona-derive.

📚 $\text{Stack Overview}$
Pulls submitted in this stack:

#762 👈
main

This comment was automatically generated by st.


Fix CI core count

Currently we determine the number of (logical) cores on the CI system incorrectly:
On fineci:
> grep "core id" /proc/cpuinfo | sort -u
core id         : 0
core id         : 1
core id         : 10
core id         : 11
core id         : 12
core id         : 2
core id         : 3
core id         : 4
core id         : 8
core id         : 9

The Core IDs doesn't seem suitable to determine the number of cores, since they contain duplicates.
As far as I can see, this also causes our builds on the AMD machine to be executed with only a single core.
A better choice would be
> grep "^processor" /proc/cpuinfo | sort -u
processor       : 0
processor       : 1
processor       : 10
processor       : 11
processor       : 12
processor       : 13
processor       : 14
processor       : 15
processor       : 16
processor       : 17
processor       : 18
processor       : 19
processor       : 2
processor       : 20
processor       : 21
processor       : 22
processor       : 23
processor       : 24
processor       : 25
processor       : 26
processor       : 27
processor       : 28
processor       : 29
processor       : 3
processor       : 30
processor       : 31
processor       : 32
processor       : 33
processor       : 34
processor       : 35
processor       : 36
processor       : 37
processor       : 38
processor       : 39
processor       : 4
processor       : 5
processor       : 6
processor       : 7
processor       : 8
processor       : 9

Looking at the numbers again, I'm not convinced that a blanket NUM_CORES/10 is the best solution, especially on amdci. How about using 4 cores everywhere and setting the gitlab-runner concurrency to around 10-15 and 6-9 so we have at most 50% oversubscription?

I'm fine with setting 4 cores everywhere and manage the complexity in the runner's configuration.
Also, to get the number of cores, another solution could be:
lscpu | sed -n 's/^CPU(s):[\t ]\+\([0-9]\+\)$/\1/p'


⚠ SceneTime has degraded performance

In 228110b, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 2525 ms

Resolved: SceneTime performance has improved in 00f5825 after 14 minutes.