Google/Facebook native login

@devnetics I merged master into this branch. Couple notes:

do npm install first
TypeScript 2 (I already fixed some compilation errors from this change)
we're now using rollup instead of browserify

clone ionic-native and switch to the rollup branch, then npm run build
in ionic-native repo, run npm link
in ionic-cloud repo, run npm link ionic-native

removed gulp in favor of npm scripts - see package.json and CONTRIBUTING.md

Sorry to thrust all this upon you, but your branch was really old 😛
The reason for rollup is because the ionic-native adds over a MB to our bundle, and I was hoping to slim it down to just what we need, which is Facebook, Google, Device, and maybe the Push plugin in the near future. But it includes basically all the plugins, which is kinda gross. Rollup also isn't "working" yet, as in it's still including all of ionic-native (I think because of the @Plugin decorators).

You may not be using Typescript 2 locally. Make sure to update your dependencies


Renew KeyStores in API-M 4.3

Description
Current self signed certificate expires on 2025. Hence need to update the current certificate with the validity period of 825 days.
4.2 commits
https://github.com/wso2/carbon-kernel/pull/3523
https://github.com/wso2/product-apim/pull/13156
Affected Component
APIM
Version
4.3
Related Issues
No response
Suggested Labels
No response

Created KeyStores for APIM 4.3

We have discussed and decided to remove expired certs from the JKS

Note - For the future references when someone is doing this task for future releases
When investigating a failed test case in local integration tests (ExternalIDPJWTTestCase), it was possible to observe that a special cert is required for the test. Cert was intentionally added for the test case, and it is missing in the renewal JKS. In order to overcome this, cert was exported and imported to the JKS which is used in the test case.

All the related repositories was build with test locally.

Kernel / Carbon APIMGT / MultiTenancy / Product APIM

Failed tests
ELKAnalyticsWithRespondMediatorTestCase.testELKAnalyticsWithRespondMediator
GraphqlSubscriptionTestCase.testGraphQLAPISubscriptionThrottling
As discussed, 1st one is expected to fail for the current pack and other one is intermittent.
Kernel PR - https://github.com/wso2/carbon-kernel/pull/3915
Product PR - https://github.com/wso2/product-apim/pull/13391

Kernel is merged. Once a kernel version is release, we will merge the product PR.


[Feature]

Description
Navbar that hides when scrolling down and shows when scrolling up
Screenshots
Here's a demo ⤵, observe the movement of navbar while scrolling
https://github.com/Rakesh9100/CalcDiverse/assets/146806880/a555c4f8-1fd3-4a02-8a3c-316b45c2df79
Checklist

[X] I have checked the existing issues.
[X] I follow Contributing Guidelines of this project.
[X] I am a GSSOC'24 contributor.
[ ] I am a IWOC'24 contributor.
[ ] I am a JWOC'24 contributor.
[ ] I am a SWOC'24 contributor.

Code of Conduct

[X] I agree to follow this project's "Code of Conduct".

No, navbar will be fixed or sticky only. Pls work on good issues @Ketanop321


Automated Package Upgrade

:tada: This PR is included in version 5.0.116 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Versions for each file info class

Hey Lori,
It would be really handy if we could get an indication of which build number included which FileInfoClass.
I may be wrong but in my test against 19041 FileNetworkOpenInformation returns STATUS_INVALID_PARAMETER (which is a pain since I just added support for that to my filter).
I know that Stat and StatLx have worked since forever and I have seen a certain AV product using FileCaseSensitiveInformation so I know that works.
[Enter feedback here]

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

ID: 226fe146-f4fb-0df5-4f5b-c7e577b4e6d1
Version Independent ID: d34f936a-8045-534c-bdde-fa80f65cd581
Content: NtQueryInformationByName function - Windows drivers
Content Source: wdk-ddi-src/content/ntifs/nf-ntifs-ntqueryinformationbyname.md
Product: windows-hardware
Technology: windows-devices
GitHub Login: @lorihollasch
Microsoft Alias: loriwhip

Arg @rodwiddowson , sorry to say but FileNetworkOpenInformation is not supported at all - probably a cut and paste error! I've removed it from the page, and have added version info for the remaining 3 supported FileInfoClasses. Changes will go live soon (commit is 97a44c32)

😁


Refactor Tracer to check presence of Zone global variable

This checks the presence of Zone in Tracer as there might be some case where zone.js library is not imported.
Also, modify Tracer to be Singleton as there will be only one instance.

Codecov Report

Merging #103 into master will increase coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #103      +/-   ##
==========================================
+ Coverage   96.23%   96.29%   +0.05%
==========================================
  Files          26       26
  Lines         637      647      +10
  Branches       80       83       +3
==========================================
+ Hits          613      623      +10
  Misses         24       24

Impacted Files
Coverage Δ

src/trace/model/tracer.ts
97.22% <0%> (+1.06%)
:arrow_up:

Continue to review full report at Codecov.

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


proposal: x/exp/maps: add Merge

Prior to my PR, I didn't see that this feature was already discussed here.
Even though the change was retracted in favor of maps.Copy, I believe that for a large number of maps to merge, the semantics of a Merge function are more meaningful.
The implementation I've proposed has no mechanism for key conflicts resolution.
But this mechanism (if implemented) could possibly justify this function existence alongside maps.Copy.

what's the proposed API?
and do you have numbers to back up your claim?

Here's the proposed API
func Merge[M ~map[K]V, K comparable, V any](m ...M) M
What I'm saying is
m := maps.Merge(m1,m2,m3,m4,m5)

is more explicit IMO than

m := maps.Clone(m1)
maps.Copy(m, m2)
maps.Copy(m, m3)
maps.Copy(m, m4)
maps.Copy(m, m5)

I don't know: the maps.Clone+maps.Copy implementation seems more explicit to me. There is no ambiguity about which maps override which other maps.
I don't understand the comment about the benefit of "the ability to allocate one time". Perhaps this is talking about precalculating the size of the map and preallocating, but that doesn't end up working that well for maps, and it's difficult to predict the amount of overlap anyway. If m1 through m5 contain mostly the same keys, you need max(len(mX)) for the result. If they contain mostly different keys, you need sum(len(mX)) for the result. Those are very different preallocated sizes.

This also doesn't seem like a very common operation. How important is this? How often does it come up?

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

Sorry, I forgot to answer !
It is quite right for the rule about the overrides.
For the allocation part, I think that most users would not want to discard values and will use this function to merge Set values. Yet, I can't predict how this will  be used.
It is probably not frequent enough to justify its use instead of using a loop with maps.Copy.
(I've never massively sampled code to identify this pattern)

No change in consensus, so declined.
— rsc for the proposal review group


Upgrade actions/cache to v4

@eenagy Thanks for making this action.
This change should make the following warning (which shows up when running the action) go away:
The following actions uses Node.js version which is deprecated and will be forced to run on node20: actions/cache@v3. For more info: https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/

Thank you. I will bump the version number and release the new version.


Move IPPICV binaries to GitHub opencv_3rdparty repository

3rdparty repo scripts: https://github.com/Itseez/opencv_3rdparty/pull/3

:+1:


Update CODEOWNERS

Change CODEOWNERS to @hugo-goncalves-kununu and @joaoalves-kununu as we are now in separate teams and we are more inside the logic of the bundle

The build is failing because of conflicts due to the changes in Symfony 5.3. They introduced the method getContainer which collides with our method.
This is addressed in: https://github.com/kununu/testing-bundle/pull/28


Add readme

@biklas7 please just check the copyright date. I don't know which year should we use

@tmpduarte i think I've copied that from another demo project 🤔


Bump up device  api verison

Signed-off-by: Xiang Dai<EMAIL_ADDRESS>

/cc @fisherxu

/cc @fisherxu

/approve

Signed-off-by: Xiang Dai<EMAIL_ADDRESS>
do you test it?  when i use this in kubeedge-1.4.0,kubeedge-counter-demo can not work ,  just update crd.yaml can not resolve question

It is the first step :)

Manually merging as bot not yet enabled on this repo


building on armhf: implicit declaration of function ‘ftello64’; did you mean ‘ftello’?

Hi,
This is some fallout from the time64 rebuild in Debian with -Werror=implicit-function-declaration
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069527
I can certainly fix it in some ugly way, I 'll have a look later.
I guess the same bug can be reproduced on a i386 chroot with the right compilation flags.
https://www.gnu.org/software/libc/manual/html_node/File-Positioning.html#index-ftello
https://lwn.net/Articles/938149/

If the sources are compiled with _FILE_OFFSET_BITS == 64 on a 32 bits machine this function is available under the name fseeko

This is related to another open issue; I've documented the problems with libchdr's attempts to detect the compilation environment here: https://github.com/rtissera/libchdr/issues/92#issuecomment-1534074775


Query parameters and Angular child routes causes active route not to be selected in navigation menu

To reproduce:

Add some query parameters to the current route and hit Enter key to reload
Check the navigation menu on the left

Result: the active route is no longer selected
The reason for it is that you just use url directly to select the active item. This approach fails when there are some child routes ("customers/details/1") or query parameters ("customers?page=2").

@ovchinnikov Your fix only fixes the issue with query parameters but not the child route ("customers/details/1") issue.

In the case of child routes, you can do either of the following:

Separate the menu item for the child route
Use one menu item for several routes

In this application template, we don't use child routes. So, we have implemented only the first strategy. If you need custom navigation, feel free to implement custom menu selection.


404 in Mobile Example

[✔] I've looked at the documentation to make sure the behavior is documented and expected
[✔] I'm sure this is a Leaflet code issue, not an issue with my own code nor with the framework I'm using (Cordova, Ionic, Angular, React…)
[✔] I've searched through the issues to make sure it's not yet reported

Steps to reproduce
Steps to reproduce the behavior:
-step1:
Visit: https://leafletjs.com/examples/mobile/example.html
-step2:
Open your browser developer tools and look at the Javascript console.
-step3:
Locate the 404 message saying: GEThttps://api.mapbox.com/styles/v1/mapbox/streets-v11/tiles/-1/0/0?access_token=pk.eyJ1IjoibWFwYm94IiwiYSI6ImNpejY4NXVycTA2emYycXBndHRqcmZ3N3gifQ.rJcFIG214AriISLbB6B5aw
[HTTP/1.1 404 Not Found 26ms]
Expected behavior
The expected behavior would be no 404 errors with the Mapbox API such as in the quickstart example found at: https://leafletjs.com/examples/quick-start/example.html
Current behavior
The current behavior displays a 404 error complaining that the API URL cannot be found which I also believe is causing a significant delay on the map loading while it somehow recovers from the crash/404.
Environment

Leaflet version<EMAIL_ADDRESS>Browser (with version): Firefox 87.0
OS/Platform (with version): Ubuntu 20.04

Additional context
No further context
Example:
https://leafletjs.com/examples/mobile/example.html

[✔] this example is as simple as possible
[✔] this example does not rely on any third party code

I can confirm the bug, with such prerequisites:

geolocation forbidden
size of map<512px (either x or y)
If both dimensions > 512 - different tile is requested: https://api.mapbox.com/styles/v1/mapbox/streets-v11/tiles/0/0/0?access_token=pk.eyJ1IjoibWFwYm94IiwiYSI6ImNpejY4NXVycTA2emYycXBndHRqcmZ3N3gifQ.rJcFIG214AriISLbB6B5aw

At first sight, this seems that that example is gonna need a minZoom: 1 setting.

I've confirmed that adding "minZoom: 1" fixed the issue. Thanks a lot.

@johnd0e why is this issue still open

Because the bug is still here, and it is not completely clear whether we should fix the the example or the library itself.

Assuming zoom should always be >-1
I made an update to the _getZoomForUri func in the TileLayer.js
In order to verify that the zoom is not a negative number
Also, made an update to the TileLayerSpec.js to match the new behavior

Unable to reproduce anymore


Feature/couchdb

@MarcoDima You seem to have commited a bunch of unrelated files. Can you please rebase this PR and add only the ones relevant to the feature you're planning to add?


Add KICS and trivy workflows

Do you publish images of your frontend, if so where? @mhellmeier

Thanks a lot for your pull request, @the-tatanka!
Soon, images of the frontend will be published in the catenax-ng organization:
https://github.com/catenax-ng/tx-puris-frontend/
Therefore, they should be made available in the corresponding package space:
https://github.com/orgs/catenax-ng/packages/container/package/tx-puris-frontend%2Fpuris-frontend

Ok, as soon as the images are published there, we will adjust the trivy scans accordingly

@the-tatanka looks good to me for initial workflows. As mentioned above, we will need to align them on container registry update


Editable Prefixed Address Input EIP-3770

What it solves
Resolves #2756
How this PR fixes it
How to test it
Screenshots

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

50 of 53 (94.34%)  changed or added relevant lines in 8 files are covered.
3 unchanged lines in 3 files lost coverage.
Overall coverage increased (+1.0%) to 32.428%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/routes/safe/components/Balances/SendModal/screens/AddressBookInput/index.tsx
10
11
90.91%

src/routes/safe/components/Settings/ManageOwners/AddOwnerModal/screens/OwnerForm/index.tsx
0
1
0.0%

src/routes/safe/components/Settings/ManageOwners/ReplaceOwnerModal/screens/OwnerForm/index.tsx
0
1
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/routes/safe/components/Balances/SendModal/screens/AddressBookInput/index.tsx
1
66.67%

src/routes/safe/components/Settings/ManageOwners/AddOwnerModal/screens/OwnerForm/index.tsx
1
0%

src/routes/safe/components/Settings/ManageOwners/ReplaceOwnerModal/screens/OwnerForm/index.tsx
1
0%

Totals

Change from base Build<PHONE_NUMBER>:
1.0%

Covered Lines:
3053

Relevant Lines:
8426

💛  - Coveralls

Awesome PR! Left some minor comments.

In every input it was tested that the address with our without the index was a valid one. Was also tested the QR code and ENS names.
Lastly it was checked that only the prefix of the currently selected network works (so xdai: cannot work on rinkeby and viceversa)
Sections checked:
Safe creation > Owners
Add existing safe
Send funds
Send collectibles
Contract interaction
Address book add entry
Owner settings Add owner
Owner settings Replace owner
Spending Limit Add Allowance
Looks Good to me
Question:
In the Contract Interaction > Receiver input the address set doesn't show the prefix once you enter a valid address. I've seen this work fine in other inputs like the one in "Add existing safe" and Address book Add entry. So the issue is only how the address shows, but it works fine regarding if the input has the prefix or not. So, it should there the prefix for a valid address or not?
Contract interaction snapshot:

Add existing safe snapshot:

There's one behavior that I noticed and think is confusing:

Disable prefixes in Settings -> Appearance
Go to Address Book -> Create Entry
Enter rin:0x4f9BD57BCC68Bf7770429F137922B3afD23d83E7
It will remove the rin: part

I think we shouldn't remove prefixes if the user inputted them intentionally.


hydrogen tempo changes and skips on ubuntu 18.04

Prerequisites

[* ] Have you checked the solutions in our troubleshooting guide for common problems ?
[ *] Have you checked that your issue isn't already filed ?

Description
[Description of the bug]
Steps to Reproduce

Run hydrogen on Ubuntu 18.04, plenty of ram, no processor load
start running a simple 1-beat drum track
tempo speeds up and slows down, lots of glitchy speed changes

Versions
OS version:
[Your OS's version]
ubuntu 18.04.02
hydrogen 0.9.7-6

Hydrogen version:
<!-- You can check this information in the settings view or via running `apm show hydrogen` -->
[Your Hydrogen's version]

### Plugins

no plugins, straight out of the box.

### Logs

[Please post any error logs and the output of the developer tools as described in our [Debugging Guide](https://nteract.gitbooks.io/hydrogen/docs/Troubleshooting.html).]

### Expected behavior

A drum machine should probably play the same tempo and not skip beats or speed up and slow down during one measure.

### Screenshots

[If applicable, add screenshots to help explain your problem.]

### Additional context

[Add any other context about the problem here.]

I think you are in the wrong repository as this makes no sense.


Requiring a module that cannot be found results in opaque error on windows

I have an aniseed config which works on windows. However when I tried to move to packer.nvim (by reading and emulating the magic-kit system) I started getting opaque errors like this:

I came to realize that the errors are due to not a module (in this case foobar). But I was really struggling to understand what was going on because of the Undefined Variable C
I think that this has something to do with windows, but I'm not sure. C seems suspiciously like c:/ drive name. But that really is just a hunch.

@Kethku it's better if you could provide your config, or I could highly recommend you take reference from https://github.com/datwaft/nvim, he's using windows like you.

https://github.com/Kethku/vim-config heres my config. Note: its currently working as I fixed the issues caused by using packer.nvim by switching to paq. Its easy to repro the problem though by adding something like {require {foobar foobar}} to one of the module definitions

Since you use paq, I have no idea what went wrong with packer. I'm using packer without any prob.

You don't need to use autoload but it's a helpful tool for delaying some larger modules until they're used by a key mapping etc 😄

I think that this has something to do with windows, but I'm not sure. C seems suspiciously like c:/ drive name. But that really is just a hunch.

This is definitely a possibility... I actually did a bunch of work to support Windows paths a little while ago and had some happy (I think?) Windows users after that, so it could be the C:\ prefix but I have my doubts since every windows user would face that issue.
This may come down to needing some better error catching and logging although it's hard since Aniseed deliberately steps out the way for performance after it's compiled everything. The whole design is based around letting your code get required as Lua so you lose the original Fennel (which is why Fennel traceback support makes little sense for the aniseed.env stuff).
Your config is only Fennel while you work on it and before you restart Neovim, then it's just plain old Lua that has no link to Fennel without sourcemaps... something that Fennel doesn't support as far as I know. Just a little bit of context on why showing nice errors is hard 😓
That being said, I should see if I can get it to print the full stack trace somewhere, that should be a bare minimum. And with the new Aniseed module system in the next version you'll get MUCH more minimal and human readable Lua so it should be easier to debug, yay!

Interesting that it's only when you moved to packer though... odd! I'll have a deeper dig into this in some free time, work now, just wanted to acknowledge and drop some more context from my end.

Just to be clear, I don't think packer has anything to do with it. My issues showed up because of a confusion I had with the order in which packer loads things. I couldn't figure out how to force packer to load from the compiled config so that I could then configure my syntax highlighting. So when I tried to set my color scheme in an aniseed module, the system would fail printing the above message.
So as an example, (module foo {require {foobar foobar}}) fails when foobar does not exist resulting in the opaque error message.
Sorry for the confusion


Wait-Job behavior with timeout

Steps to reproduce
The code is aim to set time timeout for back ground jobs. I removed unrelated code here. The behavior is strange for me. Here is the code.
function JobWithTimeout {
    param(
        [System.Management.Automation.Job]
        [parameter(
            Mandatory = $true,
            ValueFromPipeline = $true)]
        [ValidateNotNull()]
        $Job,

        [parameter(Mandatory = $true)]
        [ValidateNotNull()]
        [int]
        $TimeoutInSec
    )

    Process {
        $Job | Wait-Job -Timeout $TimeoutInSec
        if ($(Get-Job -Id $Job.Id).State -eq "Running") {
            Write-Warning "Job timeout."
        }

        $Job| Stop-Job
        $Job| Receive-Job
        $Job| Remove-Job
    }
}

Start-Job -ScriptBlock {
    Write-Warning "res"
    $aaaa = 1   # <-- remove this line cause timeout
} | JobWithTimeout -Timeout 10

Expected behavior
Always get "WARNING: res"
Actual behavior
This code works fine and get result “Warning: res”. But if I remove L30, which is meaningless, the job always timeout while Wait-Job. Is this a expected behavior? Could you explain the underlying mechanisms to me?

Environment data
Tested on both Windows Powershell and Powershell Core

Please check on latest PowerShell 7 Preview build.

Same issue on 7.0.0-preview3
PS D:\> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.0.0-preview.3
PSEdition                      Core
GitCommitId                    7.0.0-preview.3
OS                             Microsoft Windows 10.0.18362
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Still repro in PowerShell 7.3.9, same script


Create Extension Point Creators Guide

Relates to plugins. We have a Plugin Users Guide and a Plugin Creators Guide but no guide for developers who would like to create extension points in Spinnaker services.
See Rob Zienert's comment on the Plugin Creators Guide PR.

moved to #1792 (Umbrella) Plugin Guides


rust-bitcoin dependency 3.10

adding dependency
[dependencies]
bitcoin = "0.3"

In this moment cause some errors
https://gist.github.com/RCasatta/b04c778b06de02bf1f029cad6f5a7a97
(while building c4cc2a69496044e4130a4a323b7ae6e9a065162d from git works)

Can you try with bitcoin = "0.9"? This might break other things because the API has changed, but 0.3 was last updated with a much older version of the Rust language, so I'm not surprised that it no longer compiles.

Ehm, ops
sorry for trying a super old dependency, for some reason I thought was the last version

Ah! The README said "0.3". I fixed that :)


Implement the Raise Error route

See the spec for details: https://github.com/fusionalliance/autorenter-spec/blob/master/API_doc.md

This is included in pull request #25.


Error: agentID is EMPTY

I am using the version 2.5.0. I see this error in the console log soon after SAML login.
[CCP] [2023-06-17T17:02:15.400Z] [ERROR] [a4c61afb-253e-4b24-a33a-6bc3094274e0]: cannot decide clientApp config status from DB due to error: cannot get current agent AppConfig setting due to DB error {"stack":"Error: agentID is EMPTY\n
at https://.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:870410\n
at f (https://.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:863657)\n
at Generator. (https://.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:865013)\n
at Generator.next (https://.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:864020)\n
at qs (https://.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:869669)\n
at a (https://.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:869873)\n
at https://.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:869934\n
at new Promise ()\n
at https://.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:869813\n
at https://.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:870678",
"message":"agentID is EMPTY"}

any update?

Hello. We are aware of the issue and working to resolve it. Are you experiencing any direct impact or just reporting an error you see in the logs?

@beallc, in general, errors in the console log bother me. Plus CCP logs are excessively verbose. So much so that stuff gets lost in the noise.  Whenever I find a pearl like the error I reported above I relish it to see what side affect it's causing. So much is broken around CCP login that I do not know what is causing what.
I hope the SAML login can be smooth experience some day. At present, the login popup does not close fast enough after successful login. It sits there longer than desired displaying the entire CCP in the login dialog! Imagine how ugly it looks - the login box showing the CCP. I can change the target url after SAML login but what do I choose? CCP with the two smiling faces is best of the options. Is there something else I can choose that simply conveys 'successful login'?

I have noticed this as well in non-saml login usage on v2.5.0

I'm seeing this too, although the use case isn't using SAML and it's a containerised custom CCP.
    "level": "SEVERE",
    "message": "https://myconnect.my.connect.aws/connect/ccp-naws/static/streams/connect-streams-min.4208d2dc.js 0:425189 \"[2023-06-28T11:12:22.573Z] [ERROR] [22cfc840-99eb-4083-a03b-8367f70701d5]: cannot decide clientApp config status from DB due to error: cannot get current agent AppConfig setting due to DB error {\\\"stack\\\":\\\"Error: agentID is EMPTY\\\\n    at https://myconnect.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:870754\\\\n    at f (https://myconnect.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:864001)\\\\n    at Generator.\\u003Canonymous> (https://myconnect.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:865357)\\\\n    at Generator.next (https://myconnect.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:864364)\\\\n    at qs (https://myconnect.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:870013)\\\\n    at a (https://myconnect.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:870217)\\\\n    at https://myconnect.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:870278\\\\n    at new Promise (\\u003Canonymous>)\\\\n    at https://myconnect.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:870157\\\\n    at https://myconnect.my.connect.aws/connect/ccp-naws/static/client-app-interface.js:1:871022\\\",\\\"message\\\":\\\"agentID is EMPTY\\\"}\"",
    "source": "console-api",
    "timestamp":<PHONE_NUMBER>587
}```

This is impacting my ability to build a product because I can't currently place calls.


Add support for DistilBERT encoder

Currently, some parts of the code expect attributes of BertConfig, which DistilBERT does not use (DistilBertConfig is not a subclass of BertConfig, unlike with RoBERTa or xtremedistil).

From BertConfig documentation:

hidden_dropout_prob (float, optional, defaults to 0.1) — The dropout probability for all fully connected layers in the embeddings, encoder, and pooler.
hidden_size (int, optional, defaults to 768) — Dimensionality of the encoder layers and the pooler layer.

From DistilBertConfig documentation:

dropout (float, optional, defaults to 0.1) — The dropout probability for all fully connected layers in the embeddings, encoder, and pooler.
dim (int, optional, defaults to 768) — Dimensionality of the encoder layers and the pooler layer.

To support additional model config base classes for encoders, we will need to add the logic for retrieving the equivalent attributes for these two hyperparameters.

DistilBERT encoder is hitting a different error now:
  File "/home/ch226930/jobs/cnlp_transformers/src/cnlpt/HierarchicalTransformer.py", line 306, in forward
    outputs = self.encoder(
  File "/home/ch226930/.conda/envs/cnlpt-remote/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1102, in _call_impl
    return forward_call(*input, **kwargs)
TypeError: forward() got an unexpected keyword argument 'token_type_ids'

Can fix by calling self.encoder with different parameters depending on whether it is an instance of BertModel (or a subclass such as RobertaModel) or not.


[SPARK-14752][SQL] Explicitly implement KryoSerialization for LazilyGenerateOrdering

What changes were proposed in this pull request?
This patch fixes a number of com.esotericsoftware.kryo.KryoException: java.lang.NullPointerException exceptions reported in [SPARK-15604], [SPARK-14752] etc. (while executing sparkSQL queries with the kryo serializer) by explicitly implementing KryoSerialization for LazilyGenerateOrdering.
How was this patch tested?

Modified OrderingSuite so that all tests in the suite also test kryo serialization (for both interpreted and generated ordering).
Manually verified TPC-DS q1.

Test build #59838 has started for PR 13466 at commit 1d98085.

Test build #59838 has finished for PR 13466 at commit 1d98085.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class LazilyGeneratedOrdering(val ordering: Seq[SortOrder])

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/59838/
Test PASSed.

LGTM FWIW

Merging in master/2.0.


React should be a peerDependency

You've currently got react as a hard dependency and limited to v15.
React should be a peerDependency so it takes the React version that you've got in your application. Also, the range should be updated to allow v16. It's probably also a devDependency.
For example, react-redux has this as a peer dependency:
"react": "^0.14.0 || ^15.0.0-0 || ^16.0.0-0",
Not too fussed about 14, but this definitely works in 16.

Thanks,
fixed


D3D11 fix and leakage improvements

This fixes:

ID3D11CommandList leakage with new method.
ReportLiveObjects during D3D11 device dispose which was wrong.
Staging buffers not being disposed.
Calls non array ID3D11DeviceContext methods.

Looks good. Thanks for the fixes!


[Question] 请问这个文件怎么找不到了呢？convert_vipbench_for_eval.py

Question
请问这个文件怎么找不到了呢？convert_vipbench_for_eval.py

Thanks for noting this. Now this file should be added to the github repo.


Add metric conversion to bearing elements from table

The conversion to metric when bearings were instantiated from table was
left out by mistake. I'm adding it now.

Codecov Report

Merging #250 into master will decrease coverage by 0.22%.
The diff coverage is 18.18%.

@@            Coverage Diff             @@
##           master     #250      +/-   ##
==========================================
- Coverage   68.99%   68.76%   -0.23%
==========================================
  Files           9        9
  Lines        2609     2619      +10
==========================================
+ Hits         1800     1801       +1
- Misses        809      818       +9

Impacted Files
Coverage Δ

ross/utils.py
91.75% <18.18%> (-4.76%)
:arrow_down:

Continue to review full report at Codecov.

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

Codecov Report

Merging #250 into master will decrease coverage by 0.22%.
The diff coverage is 18.18%.

@@            Coverage Diff             @@
##           master     #250      +/-   ##
==========================================
- Coverage   68.99%   68.76%   -0.23%
==========================================
  Files           9        9
  Lines        2609     2619      +10
==========================================
+ Hits         1800     1801       +1
- Misses        809      818       +9

Impacted Files
Coverage Δ

ross/utils.py
91.75% <18.18%> (-4.76%)
:arrow_down:

Continue to review full report at Codecov.

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


[bug 1137022] Minor settings cleanup

remove some more settings that aren't used anywhere (DOMAIN, PROTOCOL,
PORT)
move NOSE_ARGS settings from local.py-dist to test.py where they
really should be
(cosmetic) fix a typo in requirements.txt
remove DEBUG = True from test.py since Django turns it False for
tests anyhow

Quick r?

I'm trying to break up this massive change to settings stuff into a few smaller PRs so it's easier to review. This one is mostly cosmetic.

Ugh. The settings are so messed up. Re-added the DEBUG = True to the travis.py-dist file so the tests pass with travis again. I'll nix it in the big PR later after I've fixed validate_settings.

lgtm. travis is happy. :ship:

99c84d3 [bug 1137022] Minor settings cleanup
Thank you!


Removed Filters out of FilterNodes

They were only referenced for columns and could therefor be refactored into a column reference.

@manuel-hegner please review


Issue with resolvers

Hi,
I'm having issue with resolvers, my caddyFile looks like:
[...]
tls {
   dns cloudflare MY_API_KEY
   resolvers <IP_ADDRESS>
}

But I'm getting this error because IT blocks DNS requests except from <IP_ADDRESS>.
"error": "[URL] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of "_acme-challenge.URL": dial tcp <IP_ADDRESS>:53: i/o timeout

Hi,
Please verify you are actually running that config (maybe put some gibberish in it and make sure there's an error when you try to run it, etc) -- and then if there's still a problem, open an issue at https://github.com/caddyserver/certmagic, as this is actually unrelated to Cloudflare.


Piler customize

How can I customise the piler templates before compiling?

The installer guides you through all configurations in the menu.
Only then the installation starts


Complex Field Support in Apache Hive & Custom Driver

Dbeaver doesn't handle the autocompletion of complex fields well with Hive.
For example given the example table
CREATE EXTERNAL TABLE `schmea.table`(
  `eventinfo` struct<baseinfo:struct<timestamp:bigint,source:string,platform:string,version:int>,sessionid:bigint>,
  `event_paylod` struct<payloadid:struct<high:bigint,low:bigint>,payloadtype:string,payload_pay:array<struct<payload_id:int,guid:bigint>>>

if i were to write eventinfo. and press auto complete instead of being presented with the list of fields in eventinfo i'm presented with the list of fields in the table.

DBeaver doesn't support complex types in Hive. It supports custom types (structs/arrays/etc) only in Oracle, PostgreSQL, MySQL, Cassandra and Mongo.

Ahh, I wasn't sure if complex field support was in for hive yet. In that case I guess its appropriate to mark this as a feature request.
Question: If I'm using custom drivers for a hive connection will using the datasource marked as Apache Hive be enough to use the complex field support or will there be code changes needed for a custom driver type?
Note the drivers I'm using are found http://www.cloudera.com/downloads/connectors/hive/jdbc/2-5-4.html

I can mark this as feature request. But honestly I don't think that I'll find time for Hive extension in near months.
For now DBeaver doesn't support any Hive features. You can create custom Generic driver so only basic JDBC functions will be available. You don;t need to specify any additional configuration.

No worries, I understand that you may not be able to get to it anytime soon.
I'm kind of curious about the code needed for the complex field type. Could you link me to the file/line numbers where you handle the complex fields for Postgres & Mysql?
I see the extensions here but theres a big difference in the amount of code for postgres vs say teradata (I know one is a stub extension wherease the other is a full extension).

Every database has its own data model for complex type. JDBC API supports struct and array data types but usually database vendors provide special APIs for that.
You can check JDBCComposite and PostgreStructValueHandler classes to see how standard JDBC complex types are handled in PostgreSQL.
MongoDB and Cassandra have their own very special data model.


ci: attempt to fix ci

@yaziine @gumuz @ferhatelmas I meant to say goodbye in the team channel but I got blocked on my gmail account 😱 I thought they'll block me at 8PM.

@peterdeme thank you again for all the amazing work you did, have fun and good luck for the future.


RVFI CSRs improvements

Improvements on the RVFI tracer to enable interrupt injection and correct CSRs comparison

Also adding RVFI debug signals


raft: fix test cases for #7042

Hi,
This PR fixes a test case for #7042
PTAL

Current coverage is 63.71% (diff: 100%)

No coverage report found for master at f99c76c.

Powered by Codecov. Last update f99c76c...7bb768b

lgtm


Fixed code analysis warning C28251.

Fix for C28251 "Inconsistent annotation for function: this instance has an error":
Inconsistent annotation for OutputDebugStringA: this instance has no annotations. See c:\program files (x86)\windows kits\8.1\include\um\debugapi.h(85). catch_debugger.hpp	85

Apologies for the premature closure - I deleted the branch and it auto-closed all associated PRs - it wasn't intentional.
I also can't re-open it at this point - but I'll come back and review shortly.

No problem. I can rebase and create another request if you prefer?

Sure - seems like that should be easy for you to do. Thanks.
My only concern with this (without looking into it too deeply) is whether this would introduce portability issues, since it relies on an MS extension. Although it's protected by a Windows #define, there are non MS compilers that target Windows.
But those compilers must also consume Windows.h, so either they must support those extensions, or there must be conditional code in there too.


Code Coverage Reports in Deploy Commands Produce Unreliable Covered Lines

Summary
This has already been reported as bugs such as https://github.com/forcedotcom/cli/issues/1568 but this has been closed due to "working as expected".
Please look into this soon for a new CLI Build.
When running sf project deploy start/sf project deploy validate commands with the code coverage flags (like --coverage-formatters json), the uncovered lines reported back are correct. The covered lines are incorrect for various reasons:

covered lines will sometimes be out-of-range lines (if there is a 98 line Apex Class, the coverage reports will report line 100 as covered)
covered lines are inconsistent and report back more lines than there are

Please update the Salesforce CLI to reliably report covered lines in the code coverage files so they can be exported to tools like SonarQube for code coverage tracking. In the current state, the uncovered lines can be exported to SonarQube correctly, but you need to have covered lines reported to SonarQube to calculate the coverage percentage. At this point, coverage in SonarQube will always be at 0% or the coverage % will be unreliable due to the covered lines being incorrectly reported.
I'm unclear if the CLI's apex commands produce the same outputs as the deploy commands in terms of code coverage. But we need reliable deploy coverage output so we can report back accurate code coverage during deployment and validation.
@xL3o - Please add anything I missed here based on our testing in my plugin.
See additional notes on my plugin here - https://github.com/mcarvin8/apex-code-coverage-transformer/issues/2
Steps To Reproduce

Deploy a package with apex classes or triggers with the code coverage formatted as a JSON or JSON summary. sf project deploy start -x manifest/package.xml --coverage-formatters json
Confirm the covered and uncovered lines in the coverage JSON file created by the CLI

Expected result
Uncovered and covered lines are reported back correctly. The covered lines should not have out-of-range line numbers.
Actual result
Uncovered lines are correct. Covered Lines are incorrectly reported back.
System Information
Tested on Windows 11/Powershell and Ubuntu/Bash (CI/CD).
{
  "architecture": "win32-x64",
  "cliVersion"<EMAIL_ADDRESS>  "nodeVersion": "node-v20.11.1",
  "osVersion": "Windows_NT 10.0.22621",
  "rootPath": "C:\\Users\\matthew.carvin\\AppData\\Local\\sf\\client\\2.30.8-d9ea14b",
  "shell": "cmd.exe",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.0.9 (core)",
    "@oclif/plugin-commands 3.1.4 (core)",
    "@oclif/plugin-help 6.0.13 (core)",
    "@oclif/plugin-not-found 3.0.11 (core)",
    "@oclif/plugin-plugins 4.2.5 (core)",
    "@oclif/plugin-search 1.0.16 (core)",
    "@oclif/plugin-update 4.1.13 (core)",
    "@oclif/plugin-version 2.0.12 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.12 (core)",
    "@oclif/plugin-which 3.1.0 (core)",
    "@salesforce/cli 2.30.8 (core)",
    "apex 3.0.25 (core)",
    "auth 3.3.13 (core)",
    "data 3.1.1 (core)",
    "deploy-retrieve 3.2.16 (core)",
    "dev 2.1.13 (user)",
    "info 3.0.27 (core)",
    "limits 3.1.10 (core)",
    "marketplace 1.0.25 (core)",
    "org 3.3.14 (core)",
    "packaging 2.1.10 (core)",
    "schema 3.1.3 (core)",
    "settings 2.0.27 (core)",
    "sobject 1.1.13 (core)",
    "source 3.1.15 (core)",
    "telemetry 3.1.13 (core)",
    "templates 56.0.16 (core)",
    "trust 3.3.10 (core)",
    "user 3.2.11 (core)",
    "sfdx-decomposer 3.1.0 (user)",
    "sfdx-git-delta 5.34.0 (user)"
  ]
}

Additional information

There is nothing new to report on the code coverage front from that last issue you mentioned.  The CLI team is dependent on some other internal teams and their priorities for any work to begin on this.  If the code coverage data in the API response is not accurate then there's nothing we can do except report what's given to us.  So from a CLI perspective, the code is making the correct calls and reporting the response as provided (i.e., working as designed), and to change that we need other teams to prioritize that work.  It's on their roadmaps but I don't know when it will be delivered.

Should we keep this issue open @shetzel or just close it since this seems out of the CLI team's responsibility? Seems like once the API team updates the API response to provide accurate code coverage, it will work fine on any version of the CLI.

@jfaderanga - Per @shetzel , this issue needs to be fixed by the team that manages the API first. I agree with you that this is a blocker for anyone who is trying to implement Quality Gates that enforce code coverage.
@shetzel - Is there a different way to contact the right team that owns updates to the API (outside of a general Salesforce support case)?

I agree with both of you that it's an issue, just not an issue that anyone on the CLI team can do anything about.  This repo is about issues with the CLI.  If it's open, it implies we can take some action on it but in this case we can't.

Is there a different way to contact the right team that owns updates to the API (outside of a general Salesforce support case)?

The best ways to influence the right team are opening a support case, and voting up the idea on the IdeaExchange.

it is a blocker for pipeline with Quality Gates. I've been struggling with this issue for few months now. One thing I noticed is the code should be modularized and clean for the issue not to happened. There are times that the error still shows up even the code is modularized and well written which becomes a blocker on development as the code can't be enhanced anymore.
Please re-open the issue. @mcarvin8 @shetzel

https://github.com/mcarvin8/apex-code-coverage-transformer/pull/3
@jfaderanga - I was working on this with my plug-in that converts the coverage JSON to an XML SonarQube will accept.
This will convert covered lines and work around this known issue by reassigning out of bound lines with unused lines. The coverage % will vary but it should still pass if you're hitting coverage. I could release this but I'm skeptical since the covered lines won't always report back the same way (comments and new lines can change it).

@jfaderanga - My plugin essentially just converts the JSON output from the deploy command into a XML file containing the uncovered lines/covered lines.
The latest build of my plugin just prints uncovered lines in the XML since that's accurate.
The beta build of my plugin prints covered and uncovered lines with some extra tinkering done on covered lines due to this bug.
All builds will take care of replacing no-map in the file name based on the --dx-directory flag (the default path being force-app/main/default.

The best ways to influence the right team are opening a support case, and voting up the idea on the IdeaExchange.

@shetzel is IdeaExchange really the best way forward in our situation? I mean this code coverage functionality for validation deployments is already part of the end product, rather than being a new "Idea" that the POs would need to prioritize. Therefore, there should be a more streamlined approach how to highlight this issue/bug directly to the correct team for them to start bug fixing.

@xL3o - I meant that more as a general statement of how to get issues in front of non-CLI teams.  For this issue, a support case is best.  However, I'll open this back up and transfer it to the apex-node library.  That team is a better choice to own this issue.


Setup frozen

My pipeline is now crashing as this step is frozen after I get this output indefinitely.
/usr/bin/xvfb-run --auto-servernum /home/runner/Unity Hub/UnityHub.AppImage --headless editors --installed

Please help me out with the solution as this was working properly earlier

I also get this error
(zenity:3154): dbind-WARNING **: 13:31:09.331: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files

Any update on this ?

have the same issue here, it's just stuck on the same line as above


V2 Preview2 - Pascal VOC ImageSets txt files contain duplicates with opposite values (-1, 1)

Describe the bug
When the user exports project as Tensorflow Pascal VOC, the generated txt files in ImageSets\Main folder list each image multiple times, often with a mixed values of 1 and -1.
Example: content of the file cat_train.txt:
cat_image_01.jpg -1
cat_image_01.jpg 1
cat_image_02.jpg 1
cat_image_03.jpg -1
cat_image_02.jpg 1
cat_image_03.jpg 1

To Reproduce
Label multiple images with multiple tags and then export as Tensorflow Pascal VOC.
Expected behavior
Each image should appear in the ImageSets txt file only once with the value of 1 if the image contains the class and -1 if it does not.
Platform
[x] Electron
[ ] Browser
OS
[x] Windows
[ ] Mac
[ ] Linux

@JacopoMangiavacchi - Can you please review.

This issue has been resolved and will be in upcoming release this week.


Remove -xtarget=ultra from solaris(64)-sparcv9-cc builds.

solaris64-sparcv9-cc was accidentally building 32-bit files because of the way -xtarget=ultra was being used. This patch removes -xtarget=ultra from both the 32-bit and the 64-bit Sparc builds. Details below.
The -xtarget=ultra flag was silently overriding the value of -xarch=v9 (and -xarch=v8plus) by causing the compiler to choose the best value for Ultra CPUs, which happens to be -xarch=v8plusa, a 32-bit mode. You can check the compiler behavior by using -xdryrun:
> cc -xdryrun -xarch=v9 -xtarget=ultra /dev/null
### -xarch=v8plusa -xcache=16/32/1:512/64/1 -xchip=ultra /dev/null

Swapping the order so that -xarch=v9 overrides the target default is one solution:
> cc -xdryrun -xtarget=ultra -xarch=v9 /dev/null
### -xarch=v9 -xcache=16/32/1:512/64/1 -xchip=ultra /dev/null

as is removing -xtarget=ultra completely.
> cc -xdryrun -xarch=v9 /dev/null
### -xarch=v9 /dev/null

There may be a good reason -xtarget=ultra is used here, but I can't think of a reason why ultra would be preferred over any of the other 20+ target CPU choices. If -xtarget is kept, please add a comment warning future devs to be careful when changing the ordering of these command-line flags.  The 1.0.2 branch had these values in the correct order, by the way (-xtarget=ultra -xarch=v9).
We use a fairly old compiler version (Sun C 5.8 2005/10/13), but as far as I can tell, these flags still work the same in later versions. The manual for this version is at https://docs.oracle.com/cd/E19422-01/819-3688-10/819-3688-10.pdf and these flags are documented in sections B.2.66 and B.2.138.

A somewhat-related question: Do you know why solaris64-sparcv9 uses BN_LLONG instead of SIXTY_FOUR_BIT_LONG? Configure outputs "THIRTY_TWO_BIT mode" in all-caps which no doubt worries anyone building this. It is still actually building 64-bit (with the above patch anyway) so I am not sure what that "THIRTY_TWO_BIT mode" line is referring to. BN_LLONG works fine of course, and it has been this way forever.

There may be a good reason -xtarget=ultra is used here, but I can't think of a reason why ultra would be preferred over any of the other 20+ target CPU choices.

The reason is hiding in this very sentence. The rationale behind targeting ultra is to ensure that resulting binary code is executable on all 20+ CPU, and not just top-most two or something.

The 1.0.2 branch had these values in the correct order, by the way (-xtarget=ultra -xarch=v9).

Yeah, we apparently got carried away in the shift. Will fix...

We use a fairly old compiler version (Sun C 5.8 2005/10/13)

Hmmm... Does it support -m32/-m64 options? Newer compilers "moan" about our flags being old and advising to switch to -m64, but that wouldn't work for you, would it?

Do you know why solaris64-sparcv9 uses BN_LLONG instead of SIXTY_FOUR_BIT_LONG? Configure outputs "THIRTY_TWO_BIT mode" in all-caps which no doubt worries anyone building this. It is still actually building 64-bit (with the above patch anyway) so I am not sure what that "THIRTY_TWO_BIT mode" line is referring to. BN_LLONG works fine of course, and it has been this way forever.

"Forever" is a dangerous word. I mean it has been this way forever, and it's actually reflected in CHANGES, look for "BIGNUM code on 64-bit SPARCv9 targets"... Well, the situation has actually changed with introduction of VIS3 extension, but since VIS3 support is implemented in assembly and as such protected by run-time switch (i.e. compiled always, but engaged only on VIS3-capable processors), it kind of slips in SIXTY_FOUR_BIT_LONG-ness behind the scenes, so that you are not missing anything even then.

In last comment I meant to write "It has not been this way forever". Edited...

The rationale behind targeting ultra is to ensure that resulting binary code is executable on all 20+ CPU, and not just top-most two or something.

OK, I don't know enough about these systems to know which one was the lowest common denominator. "Ultra" is a strange choice, but this is Sun after all. Sounds like just switching the order of the arguments is the best fix.

Hmmm... Does it support -m32/-m64 options?

It doesn't support those unfortunately, and -xarch=v9 is the (only?) way to build for 64-bit SPARC. It's a more obvious -xarch=amd64 for Intel. I think they first added -m32/-m64 in Sun Studio 12 (this one is 11).

"Forever" is a dangerous word. I mean it has not been this way forever...

Fair enough, the only thing I meant by it was that there's no bug to worry about, it was just some confusing log output. :)

The rationale behind targeting ultra is to ensure that resulting binary code is executable on all 20+ CPUs

On second thought this is achieved by -xarch flag alone. I mean v8plus, as well as v9, does limit compiler to the base instruction set, which defines criteria for broad binary compatibility. It is -xarch options like v8plusa and so on that allow compiler to use extension instructions which would affect binary compatibility... -xtarget rather instructs compiler to lay down code in way that benefits designated target processor. Well, it might happen that rationale behind it was that too fancy target is more likely to harm older ones more than venerable harms fancy one... Well, hardly relevant now, when original UltraSPARCs are not actually around. In other words, yeah, let's remove -xarget=ultra.
Out of curiosity, what's your system? And why do you stick with old compiler?

Yeah it's a good question, gcc would make my life a lot easier for sure. We have various enterprise builds of ActivePerl that are used by some very risk averse companies on pretty old hardware, and we don't want to do anything to potentially break compatibility either. Our ancient Solaris 8 box is a Sun Fire 280R, 2x1.2GHz UltraSPARC III. If you think this is bad, you should see the HP-UX systems...

yeah, let's remove -xarget=ultra.

Oops, protocol breach. It was meant as +1, but it has to be literal Now, another team member has to pick it up...

I do indeed believe that I have an rather ancient (powered off) ultrasparc system - however I have no plans to turn it on again ever - so if @dot-asm is okay then here is a +1 for him to commit this change into the tree for 1.1.0 and master.

Merged and being closed.
Since you mentioned HP-UX, does mention mean that you can confirm that 1.1 build works on HP-UX with vendor compiler? Trouble is that I had no opportunity to test vendor compiler...

Yeah, we do use the HP compiler on both PA-RISC and IA64. I haven't tried to build it there yet though, but I will check it out and let you know.


Review and clean up celery configuration

Celery is setup in the project but appears unused, so we need to make sure it works. This is a prerequisite for real time search index updates, but getting celery working cleanly will make it usable by developers for lots of things to improve performance. This is a low risk ticket.

Celery is now used in resource publication and RHEYSyS model file async unzipping. Closing this issue now.


Stryker dashboard support for private repos

Question
Does https://dashboard.stryker-mutator.io/ support private org repos? I can see my public repos but no way to authorise access to my private repos held under my enterprise?
Stryker environment

+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>

+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>
Additional context
N/A

Thanks for your issue. We currently don't support private repo's. The reason for that is that Stryker will by default also send the source code to the dashboard and since reports are publicly available... bye-bye private code 🤷♂
We will have to do some work to get this supported. It is planned but would take at least a year to implement with the current rate of features.

thanks @nicojs will keep an eye out for updates.


Swap regex characters allowing dashes in variables, to prevent range class

🤦♂

thank! Released as 2.3.1


AccessToken does not include email claim even when Email scope is requested

[x] I read and understood how to enable logging

Issue / Steps to reproduce the problem
I'm requesting the email scope when I'm authenticating, the email is returned form the User Info endpoint, but it is not included in the acess_token.
Is this expected? Should it be included in the access_token?
I can see from this code that the email claim will never be included unless I have a Resource Scope and I set it to IncludeAllClaimsForUser.
I think it is a bit weird that I explicitly request an email scope and it can only be included in the access_token if another scope is used and I have no way to customize this.
The relevant code is here:
ScopeStore implementation:
public async Task<IEnumerable<Scope>> FindScopesAsync(IEnumerable<string> scopeNames) =>
            (await GetScopesAsync()).Where(x => scopeNames.Contains(x.Name));

public Task<IEnumerable<Scope>> GetScopesAsync(bool publicOnly = true)
        {
            var list = new List<Scope>
            {
                new Scope
                {
                    Name = StandardScopes.OpenId.Name,
                    Required = true,
                    Type = (int) ScopeType.Identity,
                    Enabled = true
                },
                new Scope
                {
                    Name = StandardScopes.Profile.Name,
                    Type = (int) ScopeType.Identity,
                    Emphasize = true,
                    Enabled = true
                },
                new Scope
                {
                    Name = StandardScopes.Email.Name,
                    Type = (int) ScopeType.Identity,
                    Emphasize = true,
                    Enabled = true
                },
                new Scope
                {
                    Name = StandardScopes.OfflineAccess.Name,
                    Type = (int) ScopeType.Identity,
                    Emphasize = true,
                    Enabled = true
                }
            };

            return Task.FromResult(list.AsEnumerable());
        }

Then in my IProfileService I have implemented in my GetProfileDataAsync (simplified here) a method that returns the user email and some other info.
public async Task GetProfileDataAsync(ProfileDataRequestContext context)
        {
            var user = await people.FindByLoginOption(context.Subject.GetSubjectId());

            var claims = new List<Claim> { new Claim(Constants.ClaimTypes.Email, user.Email) };
            context.IssuedClaims.AddRange(claims);

            await Task.FromResult(0);
        }

Relevant parts of the log file
I can see that the email scope is correctly recognized by IS4
 Authorize request validation success
{
        "ClientId": "MyClientId",
        "ClientName": "Client Name",
        "RedirectUri": "http://localhost:5000/signin-oidc",
        "AllowedRedirectUris": [
          "hidden"
        ],
        "SubjectId": "foo",
        "ResponseType": "code",
        "ResponseMode": "form_post",
        "GrantType": "authorization_code",
        "RequestedScopes": "openid profile email offline_access",
...

Later I see this in the logs:
Scopes in access token: openid profile email offline_access

Then this, when it tries to put all the user claims in the access_token, which is the code I linked above:
Getting claims for access token for subject: foo

Seeing the code, I think the real question here is: is my assumption correct that the email claim should be in the access_token? If not, shouldn't this be something we could control? Right now the code does not allow for this unless I use a Resource Scope and then use IncludeAllClaimsForUser.

@brockallen Is this information present in the docs or I should have known for knowing the OAuth/OpenId process and flow? If it is in the doc could you please link it?

This is what we have: https://identityserver4.readthedocs.io/en/release/configuration/resources.html
If it's not clear, we accept PRs.

I read the docs but I still have some questions:
When you say "configure the claim in both" you mean that access_token information only come from Resource Scopes?
There is no way to add info to the access_token without adding a resource scope?

When you say "configure the claim in both" you mean that access_token information only come from Resource Scopes?

access_token claims come from ApiResources, and id_token claims come from IdentityResources.

Yes, I see that from the code I linked, but is this an OpenID/OAuth restriction or is it a IS limitation?

This is by design.

Please can you be more clear? What is the motivation of this decision? This is an OpenID design or IS design?
This is an open source software, people must be certain when they see something they can help improve before they send a PR.
Right now I'm not sure if this is something that the community can help improve or if doing this would break some OpenID specification.

This is an IS design. You get two tokens and you need a way to control what's in each. The IdentityResource and ApiResource configuration object mode is how that's expressed.
What needs changing?

Ok, now the decision is clear ;)
Do you think it makes sense to have another way to add claims to id_token or access_token that does not tie Claims with Scopes?

Scopes are resources the client is requesting access to. For id_token, those are absolutely tied. For access_tokens we felt it it was a good place to allow an API to express what info it needed about the user.
What other approach do you have in mind?

We have a scenario where one of our clients is a SaaS application that can't be customized, but it implements OAuth. The problem is that it tries to retrieve some claims (e.g. email) from the access_token, if it doesn't find it there, it throws an error, failing the authentication process. This client always sends the openid profile email scopes when authenticating.
So in our scenario, telling this client to request the api scope is not an option, but we think it makes sense to add the email claim inside the access_token since he is requesting this scope. I can see from the code that, since the email is an Identity Scope, it will not be included in the access_token. So we tried to find some way to work around this.
What we tried, with no success, was adding some claims inside the GetProfileDataAsync, using this:
context.IssuedClaims.AddRange(claims);

Since I have access to the ProfileDataRequestContext and the IssuedClaims and I can Add any number of claims to it, we thought it made sense.
But I saw that they only get added to the access_token when there is an additionalClaims to be added. Which will always be empty since I don't have an API Scope in the request.
My suggestion is having some way to control the additionalClaims or the IssuedClaims itself, so we could add other Claims to the access_token without having to necessarily introduce a new API scope.
Is this condition really necessary? Removing it would always try to add what is inside IssuedClaims, even when no API Resource is used.

one of our clients is a SaaS application that can't be customized, but it implements OAuth

So the SaaS is a client of your token service? It's getting an access token to call your API?

Actually it is not a SaaS, I did not express myself right. It is just an out of the box application that does not allow for customization in the authorization process.

Actually it is not a SaaS, I did not express myself right. It is just an application that does not allow for customization in many parts, one of them being the authorization process.
But yes, it gets an access_token to call our API.

But if it's the client and it's looking inside the access token, then it's really breaking the rules and I have little sympathy for them.
But yea, maybe we can remove the guard so your custom profile service can add custom claims regardless of the user claims configuration.

opened an issue to track: #683

I agree, we also think there are many wrong things with their implementation.
I can help sending a PR to this.

If you do a PR, please include automated tests. If not, we can get to it at some point.

As discussed in #683, this was fixed in 1.0.2. We can now add more claims to both the id_token and the access_token by adding them to the IssuedClaims from ProfileDataRequestContext.


Clarification on Inference engines

Hi @aniketmaurya
In all the inference engines that's behind the serving layer. I see the individual items in a batch are still processed individually inside a for loop. Is it for handling scenarios where user doesn't have GPUs?
Thanks,
Akash

hi @akashsonowal, the example might only be for demonstration. Here is a model that uses batched prediction.


When I do any search, a black modal box is generated before the page refreshes

Package
filament/filament
Package Version
3.2
Laravel Version
^10.10
Livewire Version
^3.5
PHP Version
8.1
Problem description
When I do an arbitrary search, there is a black modal box that covers the page before refreshing, the search takes effect, but the black popup doesn't close.
<form wire:submit.prevent="callMountedFormComponentAction">
        <div aria-modal="true" role="dialog" x-data="{
        isOpen: false,

        livewire: null,

        close: function () {
            this.isOpen = false

            this.$refs.modalContainer.dispatchEvent(
                new CustomEvent('modal-closed', { id: 'Uxkn5gjA7CvGrS2eWT54-form-component-action' }),
            )
        },

        open: function () {
            this.isOpen = true

            this.$refs.modalContainer.dispatchEvent(
                new CustomEvent('modal-opened', { id: 'Uxkn5gjA7CvGrS2eWT54-form-component-action' }),
            )
        },
    }" x-on:close-modal.window="if ($event.detail.id === 'Uxkn5gjA7CvGrS2eWT54-form-component-action') close()" x-on:open-modal.window="if ($event.detail.id === 'Uxkn5gjA7CvGrS2eWT54-form-component-action') open()" x-trap.noscroll="isOpen" wire:ignore.self="" class="fi-modal block" data-immersive-translate-walked="3fb33b97-ec96-4874-b66d-1c9a6dae62e6">

 {
                        isShown = isOpen
                        $watch('isOpen', () => (isShown = isOpen))
                    })
                " x-on:keydown.window.escape="$dispatch('close-modal', { id: 'Uxkn5gjA7CvGrS2eWT54-form-component-action' })" x-show="isShown" x-transition:enter="duration-300" x-transition:leave="duration-300" x-transition:enter-start="scale-95" x-transition:enter-end="scale-100" x-transition:leave-start="scale-95" x-transition:leave-end="scale-100" class="fi-modal-window pointer-events-auto relative flex w-full cursor-default flex-col bg-white shadow-xl ring-1 ring-gray-950/5 dark:bg-gray-900 dark:ring-white/10 mx-auto rounded-xl hidden max-w-sm" data-has-alpine-state="true">

    </form>

Expected behavior
Refresh the form data after searching, but don't have pop-ups!
Steps to reproduce
I've fully patched migration and seed, and the sample project helps us to easily reproduce the problem.
Reproduction repository (issue will be closed if this is not valid)
https://github.com/cnpap/yujian-admin
Relevant log output
No response

Donate 💰 to fund this issue

You can donate funding to this issue. We receive the money once the issue is completed & confirmed by you.
100% of the funding will be distributed between the Filament core team to run all aspects of the project.
Thank you in advance for helping us make maintenance sustainable!

Please provide the exact Filament and Livewire version. php artisan about

I've installed Livewire and updated the version info on the issue

Livewire is currently broken, and you have the broken version installed. This is because Filament is set to "filament/filament": "3.2", instead of "filament/filament": "^3.2",. Change this and update Composer to receive the latest Filament version and downgrade Livewire off the version that is broken.

okok, problem solved.


monaco-languageclient compatibility issue

monaco-editor version: 0.15.1
**Browser:**Chrome
OS: mac os
According to the https://microsoft.github.io/language-server-protocol/implementors/tools/
The demo （https://www.npmjs.com/package/monaco-languageclient）depends on monaco-editor -core has run successful  , but if i change to use momaco-editor, I get the following error：
Uncaught TypeError: Cannot read property 'TriggerCharacter' of undefined
at MonacoToProtocolConverter.webpackJsonp../node_modules/monaco-languageclient/lib/monaco-converter.js.MonacoToProtocolConverter.asTriggerKind (monaco-converter.js:88)
at MonacoToProtocolConverter.webpackJsonp../node_modules/monaco-languageclient/lib/monaco-converter.js.MonacoToProtocolConverter.asCompletionContext (monaco-converter.js:82)
at MonacoToProtocolConverter.webpackJsonp../node_modules/monaco-languageclient/lib/monaco-converter.js.MonacoToProtocolConverter.asCompletionParams (monaco-converter.js:77)
at Object.provideCompletionItems (monaco-languages.js:86)
at suggest.js:48
at Array.map ()
at suggest.js:44
at loop (async.js:169)
at first (async.js:177)
at provideSuggestionItems (suggest.js:76)
at SuggestModel.webpackJsonp../node_modules/monaco-editor/esm/vs/editor/contrib/suggest/suggestModel.js.SuggestModel.trigger (suggestModel.js:305)
at suggestModel.js:253
at async.js:204

@benbenqiang
Problem solved? I had the same problem


Possibility to use Send(object) and Publish(object) without the constraint of IRequest or INotification interfaces

Currently, MediatR requires that messages sent through the Send(object) and Publish(object) methods implement the corresponding IRequest or INotification interfaces. However, there might be a need to send or publish objects without being required to implement these interfaces.
Despite IMediator providing these overloads, it is currently not possible to send or publish objects without them being required to implement these interfaces.
When Send(object) or Publish(object) is used with an object that does not implement IRequest or INotification, an exception is thrown. This constraint restricts the usage to only objects that implement these interfaces.
I would suggest exploring the possibility of allowing the usage of Send(object) and Publish(object) without the constraint of IRequest or INotification interfaces. This would provide greater flexibility in sending messages without the need for such constraints.
I understand that the use of IRequest and INotification interfaces offers a standardized structure for message handling, but the possibility to send and publish objects without interfaces could simplify development in scenarios where advanced message handling is not required. Additionally, there are cases where direct control over types is not available, and there is no need to decouple them or wrap them inside an object that implements the interfaces, making the usage without interfaces even more advantageous.
I kindly request the community members to discuss this proposal and evaluate its feasibility, considering the potential implications and advantages it could offer for the flexibility of MediatR usage. Furthermore, it would be interesting to understand why it should be a required constraint for messages to implement these interfaces, especially considering that other Mediators, such as MassTransit, do not have this constraint.
Thank you for your attention and commitment to the development of this library.

I modeled this more off of NServiceBus, which uses these constraints to provide guardrails for developers so that they do not "publish" requests and "send" notifications. I don't have cases where I use MediatR and don't have control over the types. If types are defined by others, I'll wrap them up because MediatR is only meant to be in-process anyway, not for someone else's arbitrary contracts.

Hi Jimmy,
Thank you for your response, I really appreciate it.
I understand that you want to provide clear guidelines to developers, and that makes sense.
However, in our case, we have to deal with contracts from third parties.
We thought about wrapping these contracts in a generic class, but it would prevent us from using inheritance and publishing without knowing the exact type of the request or notification.
class MyRequestBase : IRequest {}

class MyRequestImplementation : MyRequestBase {}

// myRequestBase.GetType() == typeof(MyRequestImplementation)
MySend(MyRequestBase myRequestBase) => _mediator.Send(myRequestBase);

class MyRequestHandler : IRequestHandler<MyRequestImplementation> {} // works

class RequestWrapper<T> : IRequest { T Message; }

// requestWrapper.Message.GetType() == typeof(MyRequestImplementation)
MySend(RequestWrapper<MyRequestBase> requestWrapper) => _mediator.Send(requestWrapper);

class MyRequestHandler : IRequestHandler<RequestWrapper<MyRequestImplementation>> {} // doesn't work

Unfortunately, wrapping doesn't solve our problem in these situations.
Thank you for considering our perspective.

The way you make your request wrapper work is to create a concrete closed type, something like public class MyRequestWrapper : RequestWrapper<MyRequestImplementation>.


[Feature][plugins] refine plugin module

Search before asking

[X] I had searched in the feature and found no similar feature requirement.

Description
move all plugin modules to plugins/ submodule
Usage Scenario
No response
Related issues
No response
Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

👍


[New game]: text not visible

🎮 Game Request
text is not visible in light mode
Point down the features

Select program in which you are contributing
GSSoC24
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @dnyandeepchute !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

/assign

I want to Contribute to this issue. Pls assign me,

Hey @dnyandeepchute ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


feat: report hostname changes

Describe your changes
tcping now keeps tracks of successful(!) hostname changes, and reports them in json/plane printers in statistics screen
Example output of multiple unsuccessful resolves and some successful ones
This uses old output format, there are screenshots of the new format below

> go run . fb.com 443 -r 2
TCPinging fb.com on port 443
No reply from fb.com (2a03:2880:f103:83:face:b00c:0:25de) on port 443 TCP_conn=1
No reply from fb.com (2a03:2880:f103:83:face:b00c:0:25de) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f162:81:face:b00c:0:25de) on port 443 TCP_conn=1
No reply from fb.com (2a03:2880:f162:81:face:b00c:0:25de) on port 443 TCP_conn=2
retrying to resolve fb.com
No response received for 4 seconds
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1 time=182.082 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2 time=179.312 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=3 time=181.029 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=4 time=182.631 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=5 time=180.608 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=6 time=180.115 ms
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f103:83:face:b00c:0:25de) on port 443 TCP_conn=1
No reply from fb.com (2a03:2880:f103:83:face:b00c:0:25de) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f10d:83:face:b00c:0:25de) on port 443 TCP_conn=1
No reply from fb.com (2a03:2880:f10d:83:face:b00c:0:25de) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f131:83:face:b00c:0:25de) on port 443 TCP_conn=1
No reply from fb.com (2a03:2880:f131:83:face:b00c:0:25de) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f162:81:face:b00c:0:25de) on port 443 TCP_conn=1
No reply from fb.com (2a03:2880:f162:81:face:b00c:0:25de) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f162:81:face:b00c:0:25de) on port 443 TCP_conn=1
No reply from fb.com (2a03:2880:f162:81:face:b00c:0:25de) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f162:81:face:b00c:0:25de) on port 443 TCP_conn=1
No reply from fb.com (2a03:2880:f162:81:face:b00c:0:25de) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f175:181:face:b00c:0:25de) on port 443 TCP_conn=1
No reply from fb.com (2a03:2880:f175:181:face:b00c:0:25de) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f103:83:face:b00c:0:25de) on port 443 TCP_conn=1
No reply from fb.com (2a03:2880:f103:83:face:b00c:0:25de) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f112:182:face:b00c:0:25de) on port 443 TCP_conn=1
No reply from fb.com (2a03:2880:f112:182:face:b00c:0:25de) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f101:83:face:b00c:0:25de) on port 443 TCP_conn=1
No reply from fb.com (2a03:2880:f101:83:face:b00c:0:25de) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f111:83:face:b00c:0:25de) on port 443 TCP_conn=1
No reply from fb.com (2a03:2880:f111:83:face:b00c:0:25de) on port 443 TCP_conn=2
retrying to resolve fb.com
No response received for 29 seconds
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1 time=162.855 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2 time=76.537 ms
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No response received for 0 seconds
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1 time=40.054 ms
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No response received for 0 seconds
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1 time=40.104 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2 time=40.596 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=3 time=36.128 ms
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No response received for 0 seconds
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1 time=38.430 ms
^C
--- fb.com (<IP_ADDRESS>) TCPing statistics ---
50 probes transmitted on port 443 | 13 received, 74.00% packet loss
successful probes:   13
unsuccessful probes: 37
last successful probe:   2023-05-28 20:53:10
last unsuccessful probe: 2023-05-28 20:53:10
total uptime:   13 seconds
total downtime: 37 seconds
longest consecutive uptime:   6 seconds from 2023-05-28 20:52:26 to 2023-05-28 20:52:32
longest consecutive downtime: 29 seconds from 2023-05-28 20:52:32 to 2023-05-28 20:53:01
retried to resolve hostname 17 times
IP address changed from 2a03:2880:f103:83:face:b00c:0:25de to <IP_ADDRESS> at 2023-05-28 20:52:26
IP address changed from <IP_ADDRESS> to <IP_ADDRESS> at 2023-05-28 20:53:02
rtt min/avg/max: 36.128/116.960/182.631 ms
--------------------------------------
TCPing started at: 2023-05-28 20:52:21
TCPing ended at:   2023-05-28 20:53:11
duration (HH:MM:SS): 00:00:50

Printers:

Issue ticket number and link
Closes #17
Checklist before requesting a review

[x] I have performed a self-review of my code
[x] I have run make check and there are no failures.

Type of change

[x] New feature (non-breaking change which adds functionality)

This now reports all resolved attempts, even the ones that were pinged unsuccessfully
Example 1:

Full Log

❯ go run . fb.com 443 -r 2
TCPinging fb.com on port 443
No reply from fb.com (2a03:2880:f113:81:face:b00c:0:25de) on port 443 TCP_conn=1
No reply from fb.com (2a03:2880:f113:81:face:b00c:0:25de) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f113:81:face:b00c:0:25de) on port 443 TCP_conn=1
No reply from fb.com (2a03:2880:f113:81:face:b00c:0:25de) on port 443 TCP_conn=2
retrying to resolve fb.com
No response received for 4 seconds
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1 time=35.480 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2 time=52.093 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=3 time=72.185 ms
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No response received for 6 seconds
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1 time=57.891 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2 time=57.161 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=3 time=65.277 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=4 time=59.951 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=5 time=56.856 ms
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f134:183:face:b00c:0:25de) on port 443 TCP_conn=1
No reply from fb.com (2a03:2880:f134:183:face:b00c:0:25de) on port 443 TCP_conn=2
retrying to resolve fb.com
No response received for 7 seconds
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1 time=205.416 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2 time=197.442 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=3 time=198.731 ms
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No response received for 0 seconds
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1 time=200.187 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2 time=199.345 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=3 time=201.511 ms
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2
retrying to resolve fb.com
No reply from fb.com (2a01:54e0:fb00::301) on port 443 TCP_conn=1
No reply from fb.com (2a01:54e0:fb00::301) on port 443 TCP_conn=2
retrying to resolve fb.com
No response received for 8 seconds
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1 time=157.496 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=2 time=158.925 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=3 time=157.662 ms
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=4 time=161.980 ms
^C
--- fb.com (<IP_ADDRESS>) TCPing statistics ---
46 probes transmitted on port 443 | 18 received, 60.87% packet loss
successful probes:   18
unsuccessful probes: 28
last successful probe:   2023-05-29 11:41:15
last unsuccessful probe: 2023-05-29 11:41:11
total uptime:   18 seconds
total downtime: 28 seconds
longest consecutive uptime:   5 seconds from 2023-05-29 11:40:44 to 2023-05-29 11:40:49
longest consecutive downtime: 8 seconds from 2023-05-29 11:41:04 to 2023-05-29 11:41:12
retried to resolve hostname 13 times
IP address changes:
  from 2a03:2880:f113:81:face:b00c:0:25de to <IP_ADDRESS> at 2023-05-29 11:40:34
  from <IP_ADDRESS> to 2a03:2880:f134:183:face:b00c:0:25de at 2023-05-29 11:40:56
  from 2a03:2880:f134:183:face:b00c:0:25de to <IP_ADDRESS> at 2023-05-29 11:40:57
  from <IP_ADDRESS> to 2a01:54e0:fb00::301 at 2023-05-29 11:41:10
  from 2a01:54e0:fb00::301 to <IP_ADDRESS> at 2023-05-29 11:41:12
rtt min/avg/max: 35.480/127.533/205.416 ms
--------------------------------------
TCPing started at: 2023-05-29 11:40:30
TCPing ended at:   2023-05-29 11:41:16
duration (HH:MM:SS): 00:00:46

Example 2:

Full log

❯ go run . fb.com 443 -r 1
TCPinging fb.com on port 443
No reply from fb.com (2a03:2880:f103:83:face:b00c:0:25de) on port 443 TCP_conn=1
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f12c:183:face:b00c:0:25de) on port 443 TCP_conn=1
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f131:83:face:b00c:0:25de) on port 443 TCP_conn=1
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f103:181:face:b00c:0:25de) on port 443 TCP_conn=1
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f131:83:face:b00c:0:25de) on port 443 TCP_conn=1
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f134:83:face:b00c:0:25de) on port 443 TCP_conn=1
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f175:81:face:b00c:0:25de) on port 443 TCP_conn=1
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f134:183:face:b00c:0:25de) on port 443 TCP_conn=1
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f103:83:face:b00c:0:25de) on port 443 TCP_conn=1
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f103:83:face:b00c:0:25de) on port 443 TCP_conn=1
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f10d:183:face:b00c:0:25de) on port 443 TCP_conn=1
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f103:83:face:b00c:0:25de) on port 443 TCP_conn=1
retrying to resolve fb.com
No response received for 12 seconds
Reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1 time=44.546 ms
No reply from fb.com (<IP_ADDRESS>) on port 443 TCP_conn=1
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f134:183:face:b00c:0:25de) on port 443 TCP_conn=1
retrying to resolve fb.com
No reply from fb.com (2a03:2880:f175:81:face:b00c:0:25de) on port 443 TCP_conn=1
^C
--- fb.com (2a03:2880:f175:81:face:b00c:0:25de) TCPing statistics ---
16 probes transmitted on port 443 | 1 received, 93.75% packet loss
successful probes:   1
unsuccessful probes: 15
last successful probe:   2023-05-29 11:45:01
last unsuccessful probe: 2023-05-29 11:45:04
total uptime:   1 second
total downtime: 15 seconds
longest consecutive uptime:   1 second from 2023-05-29 11:45:01 to 2023-05-29 11:45:02
longest consecutive downtime: 12 seconds from 2023-05-29 11:44:49 to 2023-05-29 11:45:01
retried to resolve hostname 14 times
IP address changes:
  from 2a03:2880:f103:83:face:b00c:0:25de to 2a03:2880:f12c:183:face:b00c:0:25de at 2023-05-29 11:44:50
  from 2a03:2880:f12c:183:face:b00c:0:25de to 2a03:2880:f131:83:face:b00c:0:25de at 2023-05-29 11:44:51
  from 2a03:2880:f131:83:face:b00c:0:25de to 2a03:2880:f103:181:face:b00c:0:25de at 2023-05-29 11:44:52
  from 2a03:2880:f103:181:face:b00c:0:25de to 2a03:2880:f131:83:face:b00c:0:25de at 2023-05-29 11:44:53
  from 2a03:2880:f131:83:face:b00c:0:25de to 2a03:2880:f134:83:face:b00c:0:25de at 2023-05-29 11:44:54
  from 2a03:2880:f134:83:face:b00c:0:25de to 2a03:2880:f175:81:face:b00c:0:25de at 2023-05-29 11:44:55
  from 2a03:2880:f175:81:face:b00c:0:25de to 2a03:2880:f134:183:face:b00c:0:25de at 2023-05-29 11:44:56
  from 2a03:2880:f134:183:face:b00c:0:25de to 2a03:2880:f103:83:face:b00c:0:25de at 2023-05-29 11:44:57
  from 2a03:2880:f103:83:face:b00c:0:25de to 2a03:2880:f10d:183:face:b00c:0:25de at 2023-05-29 11:44:59
  from 2a03:2880:f10d:183:face:b00c:0:25de to 2a03:2880:f103:83:face:b00c:0:25de at 2023-05-29 11:45:00
  from 2a03:2880:f103:83:face:b00c:0:25de to <IP_ADDRESS> at 2023-05-29 11:45:01
  from <IP_ADDRESS> to 2a03:2880:f134:183:face:b00c:0:25de at 2023-05-29 11:45:03
  from 2a03:2880:f134:183:face:b00c:0:25de to 2a03:2880:f175:81:face:b00c:0:25de at 2023-05-29 11:45:04
rtt min/avg/max: 44.546/44.546/44.546 ms
--------------------------------------
TCPing started at: 2023-05-29 11:44:49
TCPing ended at:   2023-05-29 11:45:05
duration (HH:MM:SS): 00:00:16


feat(codegen): print bigint literal

closes #7285

#7286  👈
main

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

Join @camc314 and the rest of your teammates on  Graphite

Minification seems difficult, I'll restrict the feature to remove underscore only. https://github.com/oxc-project/oxc/pull/7367


Linting disappeares when using multiple folders in workspace

Environment data

Language Server version: 2022.11.30 (pyright 04a10583)
OS and version: Windows 10 Pro 21H2 19044.2251
Python version (& distribution if applicable, e.g. Anaconda): 3.10.8 64-bit, not python version dependent bug

Code Snippet

VS Code Workspace Python bug.zip
Repro Steps

Create two folders, add a python file in each of them.
Open one folder with VS Code and add the other to the workspace.
(Sometimes not needed) Restart VS Code, reopen the same folder.
Type anything into the file in the main folder. Linting will be gone.

Expected behavior
Linting does not disappear after opening other folders in workspace.
Actual behavior
After adding a folder to workspace, linting disappears (maybe language server crashes).
Logs
Python Language Server Output.txt

Video of the problem:
https://user-images.githubusercontent.com/68500992/202795016-38dd2e4d-4832-4963-9719-a9296cecbc8d.mp4

+1 Exactly the same behavior occurs for me.

Language Server version: 2022.11.30 (pyright 04a10583)
OS and version: Arch Linux 6.0.9-arch1-1
Python version: 3.11.0

This is strange:
[Info  - 21:03:27] (13772) Searching for source files
[Info  - 21:03:27] (13772) No source files found.

Can you include the contents of your user settings.json? For some reason we don't think there are any workspaces open.

@rchiodo, the "No source files found" is only for the "" service instance. That makes sense because we use the "" service instance for files that don't appear within any of the workspace roots — some other file that you happen to open in your editor. The logs show that there were are two workspaces called "Main" and "Other Project". We created one service instance for each, and one source file was found under each workspace.

This is strange:
[Info  - 21:03:27] (13772) Searching for source files
[Info  - 21:03:27] (13772) No source files found.

Can you include the contents of your user settings.json? For some reason we don't think there are any workspaces open.

Here is the settings.json (.txt because github does not support json for some reason):
settings.json.txt

Thanks. Can you turn on trace logging:

And try again?
I don't repro the problem. Semantic tokens are working for me on reload.
This should appear in the output log:
(23176) [BG(1)] getSemanticTokens range 0:0 - 7:1 at d:\Source\Testing\VS Code Workspace Python bug\Main\main.py (169ms)
(23176) [BG(3)]     parsing: c:\Users\aku91\.vscode\extensions\ms-python.vscode-pylance-2022.11.32\dist\typeshed-fallback\stdlib\_typeshed\__init__.pyi [fs read 1ms] (23ms)
(23176) [BG(3)]     binding: c:\Users\aku91\.vscode\extensions\ms-python.vscode-pylance-2022.11.32\dist\typeshed-fallback\stdlib\_typeshed\__init__.pyi (1ms)
(23176) [BG(3)]     parsing: c:\Users\aku91\.vscode\extensions\ms-python.vscode-pylance-2022.11.32\dist\typeshed-fallback\stdlib\types.pyi [fs read 0ms] (6ms)
(23176) [BG(3)]     binding: c:\Users\aku91\.vscode\extensions\ms-python.vscode-pylance-2022.11.32\dist\typeshed-fallback\stdlib\types.pyi (2ms)
(23176) [BG(3)]     parsing: c:\Users\aku91\.vscode\extensions\ms-python.vscode-pylance-2022.11.32\dist\typeshed-fallback\stdlib\abc.pyi [fs read 1ms] (1ms)
(23176) [BG(3)]     binding: c:\Users\aku91\.vscode\extensions\ms-python.vscode-pylance-2022.11.32\dist\typeshed-fallback\stdlib\abc.pyi (1ms)
(23176) [BG(3)]   checking: d:\Source\Testing\VS Code Workspace Python bug\Main\main.py (100ms)
(23176) [BG(3)] analyzing: d:\Source\Testing\VS Code Workspace Python bug\Main\main.py (210ms)

Hopefully if that's failing, we'll have some output about the failure.

Sorry my bad, I skipped a step.
Type anything into main.py and the colors will go away.
That caused the repro. And getSemanticTokens is failing.

Sorry my bad, I skipped a step.
Type anything into main.py and the colors will go away.
That caused the repro. And getSemanticTokens is failing. So we should be able to debug it here. Thanks.

No problem, if you need anything I'm happy to help.

Debugging it, it looks like the sourceFile has empty contents during the textDocument/didChange event. Not sure why yet.

Initial guess is that the adding of the new folder causes a textDocument/didOpen to be handled by the 'default' workspace, and not the workspace that will eventually handle the textDocument/didChange event.

Language Server version: 2022.11.30 (pyright 04a10583)
OS and version: Windows 11 Pro 22H2 22621.819
Python version: 3.11.0

Same issues with me.

This issue has been fixed in prerelease version 2022.11.41, which we've just released. You can find the changelog here: CHANGELOG.md


closures with cf is not supporting move in captures

Sample code:
#include <future>

#include "cf/cfuture.h"
#include "cf/sync_executor.h"

class Foo {
};

int main(int argc, char* argv[]) {
  std::unique_ptr<Foo> u_foo = std::make_unique<Foo>();
/*  cf::sync_executor executor;
  cf::async(executor, [c_u_foo = std::move(u_foo)] {
    return cf::unit();
  });*/
  std::async(std::launch::async, [c_u_foo = std::move(u_foo)] {
    return cf::unit();
  });
}

Same capture works with std::async,  but not with cf::async.  Error I get:
In file included from experimental/cf_test/main.cc:3:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/future:38:
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/functional:1711:10: error: call to implicitly-deleted copy constructor of '(lambda at external/com_github_spinorx_cf/cf/cfuture.h:891:17)'
new _Functor(__source._M_access<_Functor>());
^        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/functional:1746:8: note: in instantiation of member function 'std::_Function_base::_Base_manager<(lambda at external/com_github_spinorx_cf/cf/cfuture.h:891:17)>::_M_clone' requested here
_M_clone(__dest, __source, _Local_storage());
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/functional:2256:33: note: in instantiation of member function 'std::_Function_base::_Base_manager<(lambda at external/com_github_spinorx_cf/cf/cfuture.h:891:17)>::_M_manager' requested here
_M_manager = &_My_handler::_M_manager;
^
external/com_github_spinorx_cf/cf/cfuture.h:891:17: note: in instantiation of function template specialization 'std::function<void ()>::function<(lambda at external/com_github_spinorx_cf/cf/cfuture.h:891:17), void, void>' requested here
executor.post([promise_ptr, f = std::forward(f), args...] () mutable {
^
experimental/cf_test/main.cc:14:7: note: in instantiation of function template specialization 'cf::async<cf::sync_executor, (lambda at experimental/cf_test/main.cc:14:23)>' requested here
cf::async(executor, [c_u_foo = std::move(u_foo)] {
^
external/com_github_spinorx_cf/cf/cfuture.h:891:31: note: copy constructor of '' is implicitly deleted because field '' has a deleted copy constructor
executor.post([promise_ptr, f = std::forward(f), args...] () mutable {
^
experimental/cf_test/main.cc:14:24: note: copy constructor of '' is implicitly deleted because field '' has a deleted copy constructor
cf::async(executor, [c_u_foo = std::move(u_foo)] {
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/unique_ptr.h:356:7: note: 'unique_ptr' has been explicitly marked deleted here
unique_ptr(const unique_ptr&) = delete;
^
1 error generated.

Thank you! Fixed.


[Dotcom shell] Enable a version of the Dotcom Shell that renders Cloud Masthead and fetches Footer data from the Cloud endpoint

The problem

Now that we have a Cloud Masthead component defined within the library, I think it'll be helpful for adopters to have a wrapper component like the Dotcom shell that wraps the Mastead and Footer components in a UI shell using Carbon's grid.
@shixiedesign, let me know if this request makes sense and whether we need to review this with the larger design team as well.

The Solution

This version of the Dotcom shell component renders the Cloud Masthead + Megamenu with the correct attributes/props and fetches the Footer data from the Cloud endpoint.

Additional information
<dds-cloud-masthead-container
  platform="Cloud"
  auth-method="cookie"
  data-endpoint="/common/carbon-for-ibm-dotcom/translations/cloud-masthead"
></dds-cloud-masthead-container>

Investigate whether the Cloud Masthead and the global Masthead will converge.  If so, timeframe?
This includes discussions with Keegan.

@RobertaJHahn Yeah, this is something that I'd like to touch base with Keegan, once the new Cloud Masthead launches. This is just a post-launch follow-up ticket for us to track once we're at a place where the Cloud Masthead is no longer a feature flag and that we can converge the two variations into one component or keep them separate.
I'm going to mark this issue as a low priority and move it to a later milestone.

Need to set up a call to discuss this work, also may need to include some form of education on using this rather than using the Masthead/Footer adhoc on the page.

this issue can be closed out, superceded by https://github.com/carbon-design-system/carbon-for-ibm-dotcom/issues/8240.


WIP: Add PodPreset support to API

WIP.
Resolves #266

If our API depends on an Alpha API does that make our API Alpha? Hmn... :thinking:

@MHBauer

If our API depends on an Alpha API does that make our API Alpha? Hmn... 🤔

Very good question.  The answer is complex, but basically 'no'.  We have to be able to provide alpha-level fields on APIs that are more mature than alpha, see https://github.com/kubernetes-incubator/service-catalog/issues/753 for more info.

/assign pwittrock

TLDR: I am going to close this PR because I need to rethink the approach due to what we currently can and cannot validate about API objects in the core API server.
Commented at length here: https://github.com/kubernetes-incubator/service-catalog/issues/266#issuecomment-300637343