feat: Expose internal interfaces' members to JS

(runtime/metadata generator) Add metadata for additional implemented protocols
in method signatures
(runtime) Walk the additional protocols when searching for members
(runtime) Keep Class pointers to unknown private classes
and check for availability of members inside them as well
(runtime) Create an additional Constructor/Prototype pair for each
combination of { known class, unknown class, additional protocols }
(runtime) Keep global object instead of exec state in FFICallback
(runtime) Check whether uncaught JS error is an object before
casting it. It could be a primitive type and cause the handler to crash
before reporting the actual error
(tests) Improve version availability tests to better mimic
unavailable APIs (add COMPILING_FOR_LINKING directives in
TestFixtures)
(tests) Add unit tests for private classes returned with protocol
specification and ones that are hierarchically unrelated to
the declared type

PR Checklist

[x] The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/CONTRIBUTING.md#commit-messages.
[x] There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
[x] You have signed the CLA.
[x] All existing tests are passing: https://github.com/NativeScript/ios-runtime/blob/master/CONTRIBUTING.md#contribute-to-the-code-base
[x] Tests for the changes are included.

refs #1149, #1127

test --performance


Suggestion: use a futures API rather than callbacks

So instead of writing:
    syn.type(a, "x", function() {
        syn.click(b, function() {
            syn.click(c, function() {
               syn.click(d)
           })
        })
    })

you could write something like:
syn.type(a, "x").then(function() {
     return syn.click(b)
}).then(function() {
     return syn.click(c)
}).then(function() {
     return syn.click(d)
}).done()

so you don't get all stuck in callback hell. I'd suggest a futures library but i don't wanna plug my stuff too much all at once ; )

Although futures prevent callback hell, a few things to consider:

Promises create "debugging hell".  It can be very hard to trace through to the source of problems.

  I think it does it better than promises.  After all you shouldn't be able to run 2 events at the same time (excluding multi-touch which can still be done like FuncUnit) I would rather see:
Syn.type(a,"x")
Syn.click(b,"x")

We'd have to depend on some promise library.

How are promises more difficult to debug than callbacks?
I would certainly rather see that as well, but my opinion is that FuncUnit should be considered as separate, and the API for syn should be improved without assuming it will be wrapped with a different API
Depending on a library isn't so bad is it?

Another consideration is exception handling.

If code breaks within a promise, the error is caught because everything happens within a try/catch. Then, the promise is rejected asynchronously.  It can be very difficult to trace the source of the problem.

Another consideration is exception handling. If errors happen within the callbacks, you get a whole nother kind of debugging hell

Callback make debugging much easier in my opinion.   Promises make handling exceptions much easier.  But that is not something commonly needed from Syn.  It doesn't "throw" exception.  I wouldn't want syn's code to always be running within a try/catch.

I would certainly rather see that as well, but my opinion is that FuncUnit should be considered as separate, and the API for syn should be improved without assuming it will be wrapped with a different API. It seems to me that most functionality in Syn isn't fully synchronous, and in a lot of cases, users will have to know that an action is complete before running some other code (like assertions for example).

My point was if Syn's API was going to be developed, should reflect FuncUnit's.  No promises or callbacks necessary.
The reason we extracted Syn from FuncUnit was to keep it simple as possible.  I'd like to avoid adding other dependencies, even something as banal as a promise.  Especially as I'd like to make this sharable via UMD / AMD / CJS, which can be very tricky when you have dependencies (and don't want to bundle them).

The reason we extracted Syn from FuncUnit was to keep it simple as possible.

The idea is that Syn ONLY does event simulation.  If a nicer API is needed, someone can use FuncUnit.

everything happens within a try/catch

I think this is also the case with callbacks. How do you do error handling without catching errors?

It doesn't "throw" exceptions.

But code written in the callback might.
Sounds like you already have a firm opinion about this, and its your project so its your call.

I think this is also the case with callbacks. How do you do error handling without catching errors?

In tests, I rarely "catch" exceptions.  I want them to be thrown uncaught.
I guess I could see wanting to handle exceptions with promises in other use cases, where if an error happens you want to do something other than have the tests break.

Sounds like you already have a firm opinion about this, and its your project so its your call.

Well, would you be alright with making an promise adapter we could bundle?  Similar to how Q can wrap node's fs methods.  I'm fine including another version of Syn that supports this API in the download.  I just think the core should remain using callbacks.
Thoughts?

In tests, I rarely "catch" exceptions.

Usually true for me too - unless you're explicitly testing for errors. When I use promises in testing, I expect that too. The exceptions I get will show me the exact line of code where the exception came from, and so I'm just as happy with the exceptions.
I'm also of the mindset that you don't know everything people are going to want to use your system for. I would probably only use it for testing, but some people might find other uses for it, where good error would come in more handy.
I could certainly make a wrapper. I definitely agree with a lean core.

Actually, your other comment is relevant to this. You mentioned you could do this:
it("foo", function(done){
  F("#abc").click(function(){
     assert.equal($("#abc").val(), "x", "X gon' give it to ya" );
  });
  F("#abc").type(function(){
     assert.equal($("#abc").val(), "x", "X gon' give it to ya" );
  });
})

However, I think this could cause very unintuitive behavior. Lets say you wanted to this:
it("foo", function(done){
  F("#abc").click(function(){
     var someStateINeed = someFunction($("#abc")) // needed in both asserts
     assert.equal($("#abc").val(), someStateINeed.Y, "X gon' give it to ya" );
     F("#abc").type(function(){
         assert.equal($("#abc").val(), someStateINeed.Y, "Y gon' give it to ya" );
     });
  });
  F("#abc").type("something", function(){
     assert.equal($("#abc").val(), "Z", "Z gon' give it to ya" );
  });
})

Without thinking about it, it looks like the asserts would go in the order X, Y, Z, but in reality, wouldn't they go in the order X, Z, Y?

No, it would go X, Y, Z.  FuncUnit handles nesting.

Ah ok, that's good

I thought of a case where the unintuitive behavior does come out:
it("foo", function(done){
  var abc= F("#abc")
  abc.click(function(){
     var someStateINeed = someFunction(abc) // needed in both asserts
     assert.equal(abc.val(), someStateINeed.Y, "X gon' give it to ya" );
     doSomethingAsynchronous(function() {
         abc.type('something else', function(){
           assert.equal(abc.val(), someStateINeed.Y, "Y gon' give it to ya" );
         });
      });
  });
  abc.type("something", function(){
     assert.equal(abc.val(), "Z", "Z gon' give it to ya" );
  });
})

In this case, the click handler fully finishes before scheduling any new actions, and so the thing of "something" will happen before "something else". Its an edge case, but in complicated schenarios, it will trip people up.

I'm not sure why someone would doSomethingAsynchronous in that situation.  But we can make it easy to prevent the next action from happening before doSomethingAsynchronous completes.

Well I actually didn't just come up with it in my head, I came across a similar issue while doing exactly that in my test. Problem was a completely different test was running concurrently, so it was typing one character in one input, and then a character in a completely different input, and switching back and forth. Javascript is a very asynchronous language, you gotta expect that code can be run asynchronously at any time.
Anyways, its easy for me to fix since I'm using futures, without futures you'd need some fancy footwork.

Imo, I don't have to expect tests to be running async. No popular testing framework does this.
Sent from my iPhone

On Feb 19, 2015, at 7:13 PM, fresheneesz<EMAIL_ADDRESS>wrote:
Well I actually didn't just come up with it in my head, I came across a similar issue while doing exactly that in my test. Problem was a completely different test was running concurrently, so it was typing one character in one input, and then a character in a completely different input, and switching back and forth. Javascript is a very asynchronous language, you gotta expect that code can be run asynchronously at any time.
Anyways, its easy for me to fix since I'm using futures, without futures you'd need some fancy footwork.
—
Reply to this email directly or view it on GitHub.

My case is just an example. There's an infinity of async possibilities in javascript. The fact is, its not only possible, but it happens.
In any case, I'm using a real simple wrapper. If you're interested in using the wrapper here it is:
// requires: syn (loaded as a global variable from an html script tag)

var Future = require('async-future')

exports.click = wrap(syn.click)
exports.type = wrap(syn.type)
exports.key = wrap(syn.key)

function wrap(fn) {
    return function() {
        var resultFuture = Future.wrapSingleParameter(fn).apply(this,arguments)

        // for chaining
        var target = arguments[0]
        resultFuture.click = function() {
            exports.click.apply(this, [target].concat(arguments))
        }
        resultFuture.type = function() {
            exports.type.apply(this, [target].concat(arguments))
        }
        resultFuture.key = function() {
            exports.key.apply(this, [target].concat(arguments))
        }

        return resultFuture
    }
}

That uses https://github.com/fresheneesz/asyncFuture

Why do your tests run at the same time?
Sent from my iPhone

On Feb 19, 2015, at 10:06 PM, fresheneesz<EMAIL_ADDRESS>wrote:
My case is just an example. There's an infinity of async possibilities in javascript. The fact is, its not only possible, but it happens.
In any case, I'm using a real simple wrapper. If you're interested in using the wrapper here it is:
// requires: syn (loaded as a global variable from an html script tag)
var Future = require('async-future')
exports.click = wrap(syn.click)
exports.type = wrap(syn.type)
exports.key = wrap(syn.key)
function wrap(fn) {
return function() {
var resultFuture = Future.wrapSingleParameter(fn).apply(this,arguments)
    // for chaining
    var target = arguments[0]
    resultFuture.click = function() {
        exports.click.apply(this, [target].concat(arguments))
    }
    resultFuture.type = function() {
        exports.type.apply(this, [target].concat(arguments))
    }
    resultFuture.key = function() {
        exports.key.apply(this, [target].concat(arguments))
    }

    return resultFuture
}

}
That uses https://github.com/fresheneesz/asyncFuture
—
Reply to this email directly or view it on GitHub.

The only reason to choose do it would be if you have tests that have a lot of asynchronous downtime - so your test suite doesn't take forever to run. So there's a reason to do it, even if its not common. The real reason is that I haven't implemented automatic completion-waiting in deadunit yet. I do plan to make that default, and have a switch allowing concurrent behavior.


Usage question for reducing response time with multiple requests

Whats the fastest approach to perform multiple requests sequentially or parallel with cpr?
I tried cpr::Response r = cpr::Get() but i have response times up to > 1 second which is too long for my use case.
Should i use session object instead? What about the ssl options? Or should i use libcurl instead ?

Using cpr::Session is the way to go here, since it keeps the underlying SSL/TLS connection up.
In case you use cpr from multiple threads, ensure every thread has its own session object, since cpr is not thread save on it's own.
cpr acts as a wrapper around libcurl.
If you want to set some specific options which are not (yet) provided by cpr you can access the curl object directly.
https://whoshuu.github.io/cpr/advanced-usage.html#session-objects
(at the end of this chapter is an example for that)

@COM8 Thanks. I read the guide. Its really helpful.
I tried multiple threads and it worked out of the box, reduced my average request/response time a lot :)
Also switched to cpr::Session, but couldn't see much of a difference. Maybe there is not much room a improvement when you use a different url for each request.

Glad to hear :)


Updated .NET Core 2.0 Supported OS Versions

Added Win10 IoT Core
Unify [C]/[S] in front of architecture (clarifies application to just 1 architecture - Ubuntu)
Collapsed Configurations into Notes for readability

@Petermarcu can you please verify IoT lines? I am not sure if I got them right (as [C], their versions, etc.)
Thanks!

LGTM. Thanks!


migrate write_to, full_scan and drop_from to use schema and table id

no issue to close
Description
migrate CatalogManager::write_to, CatalogManager::full_scan and CatalogManager::drop_from to use u64 schema and table id
Client output
no changes to client output

Pull Request Test Coverage Report for Build 240687381

32 of 58 (55.17%)  changed or added relevant lines in 8 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.2%) to 86.31%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/sql_engine/src/catalog_manager/mod.rs
19
45
42.22%

Totals

Change from base Build 240674372:
-0.2%

Covered Lines:
5977

Relevant Lines:
6925

💛  - Coveralls


LoadBalancer logs

I'm not able to find the logs from the rancher loadbalancer in order to debug it.

Look for the Lb Agent container.. The round little button has a dropdown menu for the logs..

If you need more, there's always the Execute Shell option as well, where you can look at (and tweak, for testing purposes) the haproxy config, etc..

The troubleshooting FAQs might help you find out how to debug a bit more in detail. It has instructions on how to look at your haproxy config.
http://docs.rancher.com/rancher/faqs/troubleshooting/

@silviupanaite Please re-open if you need more logs or information for Load Balancers.

I gave up using the rancher lb's until they're finished with the lb refactor
In the mean time i just created my own image which does this amongst other handy things:
https://hub.docker.com/r/nodeintegration/rancher-haproxy/


About Page: Our Mission and Our Values Allignment

The our mission and our values paragraphs take a while for me to decipher because of the alignment.
Instead of having them right next to each other can we place the paragraphs on top of each other and still keep the center alignment like the rest of the page. I feel it would it would connect better and reduce the visual confusion.
                                                        [ Our Vision ]

Our vision is to create a network of empowered women who feel confident in their abilities to code and build beautiful web and mobile applications. By teaching women around the world from diverse backgrounds to learn software development, we can help women improve their careers and confidence in their everyday lives.
                                                        [ Our Values ]

We are committed to making sure women of all races, education levels, income and upbringing can build confidence in their skill set to develop web and mobile applications. Our goal is to provide powerful hands-on programs to women seeking professional help in software development and create basic to advanced web and mobile applications.

Any designers/UXers want to share their thoughts on this one?

@Cara-Jo @Roenok @corinnepw thoughts?

I agree with these comments and say :shipit: with these suggestions.

Anyone willing to try this out? Just swapping the Vision and Values from the side-by-side layout to a stacked look.

Hi, I'm willing to work on this.

hey @johnmarinelli can you post your screenshot here? We typically discuss these changes as a group and then create the pull requests that reflect the decision. We'd appreciate it!

no problem:

Ello folks!
I just pushed @johnmarinelli's changes to staging so you can see them here. I will push them to production this week unless I hear any reasons not to. Thanks again, @johnmarinelli!
https://girl-develop-it-staging.herokuapp.com/about

Fixed with #353


Add complex prefix map data structure

This new data structure allows for prefixes to map to multiple URI prefixes

Codecov Report

Merging #2 (0c36da6) into main (a9213df) will decrease coverage by 3.87%.
The diff coverage is 71.42%.

@@            Coverage Diff             @@
##             main       #2      +/-   ##
==========================================
- Coverage   87.87%   84.00%   -3.88%
==========================================
  Files           3        3
  Lines          66       75       +9
  Branches        7       11       +4
==========================================
+ Hits           58       63       +5
- Misses          7       11       +4
  Partials        1        1

Impacted Files
Coverage Δ

src/curies/api.py
92.85% <71.42%> (-7.15%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us.


KILL QUERY should work during all phases of a query

Feature Request
Opening a feature request kicks off a discussion.
Requests may be closed if we're not actively planning to work on them.
Proposal:
Make it so queries can be interrupted during the planning phase, not just the execution phase.
Current behavior:
KILL QUERY can't interrupt queries until the query is at the execution phase, actually sampling data from disk. With large datasets, a query like SELECT * FROM /.*/ will spend a long time and a very large amount of RAM just instantiating the query engine iterators. During that phase, KILL QUERY won't interrupt the process and the RAM use will continue to rise.

This is blocked until #7646 is merged. That PR changes the structure of the query engine enough that any work on this will conflict with that PR.


Support for Artemis engine .ast

Hi this is just a little hope I have if anybody here would add support for the .ast file of the Artemis engine the games I've looked in so far all have the files unencrypted so it's just a matter of targeting the text

I mean this is editable sure but you know.....It's not ideal

Well, if you know how to run .lua then here the tool :)) or you can use this

Support added.

Thanks dude works great


fix: generate cache keys of collections using expand_cache_key method

closes #8

@eyupatis thanks for the PR! I'm looking forward to merging it, but could add a spec which covers the fix?

Yeah, sure. I'll work on the tests soon.

Hey @pawurb, I just pushed some specs for testing what was happening when we were fragment caching using this gem. Let me know if the specs look good or need improvement.

@eyupatis thanks. I'll merge it, but please remove all the code style changes, and other changes not related to this PR.

Sure. My editor is configured to auto-format the ruby code using standardrb. I just removed the styling related changes.

@eyupatis thanks! it was an important fix. It looks like before any cache_key apart from strings did not work correctly :/


Add a new Channel API for experimental plugins feature

Example usage:
local pajs = c2.Channel.by_name("pajlada", c2.Platform.Twitch)
pajs:add_system_message("Hello there")

When Chatterino deletes the Channel, all lua ChannelRefs to it expire and using them will produce an error. It is possible to check for this before using those functions with Channel:is_valid(). I expect that other weak objects will have identical methods, I created IWeakResource interface class which defines this method.
Breaking
This PR removes c2.system_msg and c2.send_msg.

I saw this PR just now and noticed two things:

With the removal of c2.system_msg and c2.send_msg we now need  the channel name and platform to send a (system-)message. The CommandContext should therefore be extended to also contain the platform so that replying to a command is possible without assuming that the command was triggered in a twitch channel.
Since this changes quit a lot how the API works it would be great if docs/wip-plugins.md would be changed to stay consistent with the current implementation.

@4rneee Could you create an issue to track that? Super helpful feedback


Update reference from existingBucketInterface to existingBucketObj

Issue #, if available: n/a
Description of changes: Tiny README change, updating a reference from the previous existingBucketInterface to the new existingBucketObj.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v2
Commit ID: 08a9eb382cae81f843042201d7e80c65d2d236a6
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v1
Commit ID: 08a9eb382cae81f843042201d7e80c65d2d236a6
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


SPAPT: Seidel Code is not seidel

Kernel code needs to be checked for correctness

This is a special case. Gauss seidel is a stencil computation for certain differential equations (e.g poisson). So the code is correct in terms of

does represent a good proxy for stencil proxy\
is gauss-siedel for a subset of problems


Fixes to build with WinRT

A simple fix that allows us to build on the Windows RT platform

Ok, thanks!


Add LeaderfQuickFix and LeaderfLocList

The following two commands have been added

LeaderfQuickFix
LeaderfLocList

Refer #558
Thank you!

Thanks.


Infiltration: Count entry - either remove or get to update based on order

Same issue as in Dehydration. Consider either removing or updating functionality/name. Needs a convo with Sriram.

@MicheleCD confirmed that we can delete this field

Ready for review pull request #49


contracts: complete native contract hashes list

Coverage increased (+0.02%) to 87.55% when pulling 35ed9a87f8242e3c81fbd266f2cd714a7a0669d9 on update-contracts into 1882483ca4afee7e509d55a17f0f85b31d05745e on master.


Add variadic generics to metrics util

Pending on PEP 646. This will allow having an arbitrary number of labels for metrics, instead of having to hard code them.

Obsolete, non-variadic elegant solution found.


[APM-Server] Fix label deployment not match service pod selector

[ ] Chart version not bumped (the versions are all bumped and released at the same time)
[ ] README.md updated with any new values or changes
[ ] Updated template tests in ${CHART}/tests/*.py
[ ] Updated integration tests in ${CHART}/examples/*/test/goss.yaml

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

/review


BUG: Duration is longer than excepted

Version information

fluent-ffmpeg version: fluent-ffmpeg/node-fluent-ffmpeg#master
ffmpeg version: 4.3.1
OS: macOS Catalina 10.15.7

Code to reproduce
async function convertJpgToVideo(jpegFilePath, duration = 5) {
  const instance = ffmpeg();
  const [width, height] = [600, 600]

  return instance
    .addInput(jpegFilePath)
    .inputFPS(1)
    .outputFPS(1)
    .loop()
    .duration(duration)
    .outputOptions('-movflags frag_keyframe+empty_moov')
    .toFormat('mp4')
    .size(`${width}x${height}`)
    .noAudio();
}

(note: if the problem only happens with some inputs, include a link to such an input file)
Expected results
Output video with duration === 5 seconds
Observed results
Output video with duration 6 seconds
Checklist

[x] I have read the FAQ
[ ] I tried the same with command line ffmpeg and it works correctly (hint: if the problem also happens this way, this is an ffmpeg problem and you're not reporting it to the right place)
[ ] I have included full stderr/stdout output from ffmpeg

This is the expected output. Ffmpeg will cut to the nearest GOP which in
your case will be at second nr 6. Try the same command in ffmpeg and post
your result.
On Thu, 24 Dec 2020, 13:44 dalisoft<EMAIL_ADDRESS>wrote:

Version information

fluent-ffmpeg version: fluent-ffmpeg/node-fluent-ffmpeg#master
ffmpeg version: 4.3.1
OS: macOS Catalina 10.15.7

Code to reproduce
async function convertJpgToVideo(jpegFilePath, duration = 5) {
const instance = ffmpeg();
const [width, height] = [600, 600]
return instance
.addInput(jpegFilePath)
.inputFPS(1)
.outputFPS(1)
.loop()
.duration(duration)
.outputOptions('-movflags frag_keyframe+empty_moov')
.toFormat('mp4')
.size(${width}x${height})
.noAudio();}
(note: if the problem only happens with some inputs, include a link to
such an input file)
Expected results
Output video with duration === 5 seconds
Observed results
Output video with duration 6 seconds
Checklist

I have read the FAQ
https://github.com/fluent-ffmpeg/node-fluent-ffmpeg/wiki/FAQ
I tried the same with command line ffmpeg and it works correctly
(hint: if the problem also happens this way, this is an ffmpeg problem and
you're not reporting it to the right place)
I have included full stderr/stdout output from ffmpeg

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/fluent-ffmpeg/node-fluent-ffmpeg/issues/1094, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AB2X4DUYO5VXONV7WT3HJUTSWMSTHANCNFSM4VID2BAA
.

After a lot of tries i found fix.
If anyone gets same issue, set fps to 25


Restore support for NVM

Fixes #33.

Thanks for the pull requests, i'll kickout another patch release to undo the broken patch release ;9


Default python interpreter doesn't work

What is the issue?
When I setup the toolkit locally on Mac the python interpreter tool does not work.
Using make attach and the python debugger I see:
-> res = requests.post(self.interpreter_url, json={"code": code})
(Pdb) p self.interpreter_url
'http://localhost:8080/'
(Pdb) n
2024-05-03 22:22:45,509 - urllib3.connectionpool - DEBUG - Starting new HTTP connection (1): localhost:8080
requests.exceptions.ConnectionError: HTTPConnectionPool(host='localhost', port=8080): Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0xffff4a881390>: Failed to establish a new connection: [Errno 111] Connection refused'))
> /workspace/src/backend/tools/function_tools/python_interpreter.py(48)call()

SOLUTION: Update PYTHON_INTERPRETER_URL in the .env file to specify the docker container name cohere-toolkit-terrarium-1 instead of localhost then this works:
PYTHON_INTERPRETER_URL='http://cohere-toolkit-terrarium-1:8080'

I found this name from Docker desktop, the python tool is running on port 8080:

This must be a Docker network permission issue. Outside the docker in a shell, curl works:
 curl --location 'http://localhost:8080/' \
                        --header 'User-Id: me' \
                        --header 'Content-Type: application/json' \
                        --data '{
                                        "code": "1+3"
                        }'
{"success":true,"output_files":[],"final_expression":4,"std_out":"","std_err":"","code_runtime":26}

Additional information
No response

@acanis possible from the Docker services we need to point to the service name, do you mind retesting with http://terrarium:8080 as the url?

Yes I confirmed that setting the URL to:
PYTHON_INTERPRETER_URL='http://terrarium:8080'

Works fine. I will create a PR changing the default.

Thank you, let's go with that


[$500] Difference between last message on LHN and task action message when canceled a task

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.3.91-5
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @namhihi237
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1697129972953389
Action Performed:

Open a chat
Click plus button in composer
Click assign task and create a task
Cancel the task, Observe the last message on LHN and task report differently.

Expected Result:
Last message on LHN and task report are the same when canceled task
Actual Result:
last message on LHN and task report differently.
Workaround:
unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/38435837/3348e342-c9f7-4e37-ac11-20a3a32a5ea2

Android: mWeb Chrome

https://github.com/Expensify/App/assets/38435837/85379956-c5eb-4fb4-b6a1-12b44ba69188

iOS: Native

https://github.com/Expensify/App/assets/38435837/0109cfc4-7740-418b-b6f6-22653b9ca4ce

iOS: mWeb Safari

https://github.com/Expensify/App/assets/38435837/ffb749c4-ba31-4006-b285-318dec52d1a9

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/38435837/1986b9d6-2c47-428e-972e-29dc9fbf7aea
https://github.com/Expensify/App/assets/38435837/2dae94bd-686e-4f4b-86df-efeb869e1095

MacOS: Desktop

https://github.com/Expensify/App/assets/38435837/9738fa67-9f6f-4e26-a17d-e2b14f7f19d7

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~0162e3426964bd58f2
Upwork Job ID:<PHONE_NUMBER>049146880
Last Price Increase: 2023-11-02
Automatic offers:

jjcoffee | Reviewer | 27513102
namhihi237 | Contributor | 27513103
namhihi237 | Reporter | 27513105

Proposal by @namhihi237
Please re-state the problem that we are trying to solve in this issue.
The last message on LNH is different last message on the task report when cancel the task
What is the root cause of that problem?
We only have the logic showing completed and reopened task in LHn here so when canceling it is taking the value from the backend and there is no translation.
https://github.com/Expensify/App/blob/3b98327273d361b2afd3617f93ca2718ab0aaf61/src/libs/SidebarUtils.js#L353-L356
In Task action in the report, we are using the function getTaskReportActionMessage to get the message task action
https://github.com/Expensify/App/blob/3b98327273d361b2afd3617f93ca2718ab0aaf61/src/components/ReportActionItem/TaskAction.js#L24
That's why there is a difference here.
What changes do you think we should make in order to solve the problem?
We should add logic to show the last message on LHN when the task canceled
else if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKCANCELLED) {
    result.alternateText = `${Localize.translate(preferredLocale, 'task.messages.canceled')}`;
}

Or we can use the function getTaskReportActionMessage for consistency:
else if (ReportActionsUtils.isTaskAction(lastAction)) {
   result.alternateText = Task.getTaskReportActionMessage(lastAction.actionName, report.reportID, false);
}

What alternative solutions did you explore? (Optional)
In addition, we can update the message when canceling the task
https://github.com/Expensify/App/blob/489e1aa7a7d1dfffac590d0703712b43ec481539/src/libs/actions/Task.js#L735
Or we can update the action message on the same backend/

This bug is discovered and I posted a solution to resolve this bug before
Re-post proposal here
Proposal
Please re-state the problem that we are trying to solve in this issue.
Difference between last message on LHN and task action message when canceled a task
What is the root cause of that problem?
The translation for complete task and re-open task work well in LHN because we have logic to update alternativeText in getOptionData for LHN options
https://github.com/Expensify/App/blob/08b75f39d32ab5ecfa1577ebdbb79c3fb24797fb/src/libs/SidebarUtils.js#L300-L304
But we don't have logic for the translation cancel task
What changes do you think we should make in order to solve the problem?

we need to translate cancelled task in LHN

https://github.com/Expensify/App/blob/08b75f39d32ab5ecfa1577ebdbb79c3fb24797fb/src/libs/SidebarUtils.js#L300-L304
add condition:
else if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKCANCELLED) {
                result.alternateText = `${Localize.translate(preferredLocale, 'task.messages.canceled')}: ${report.reportName}`;
            }

Optional: 2. Update complete task, reopen task and cancel task in share destination options
In here: https://github.com/Expensify/App/blob/08b75f39d32ab5ecfa1577ebdbb79c3fb24797fb/src/libs/OptionsListUtils.js#L505
we should add
if ((result.isChatRoom || result.isPolicyExpenseChat || result.isThread || result.isTaskReport)) {
            const lastAction = visibleReportActionItems[report.reportID];
            if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.RENAMED) {
                const newName = lodashGet(lastAction, 'originalMessage.newName', '');
                result.alternateText = Localize.translate(preferredLocale, 'newRoomPage.roomRenamedTo', {newName});
            } else if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKREOPENED) {
                result.alternateText = `${Localize.translate(preferredLocale, 'task.messages.reopened')}: ${report.reportName}`;
            } else if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKCOMPLETED) {
                result.alternateText = `${Localize.translate(preferredLocale, 'task.messages.completed')}: ${report.reportName}`;
            } else if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKCANCELLED) {
                result.alternateText = `${Localize.translate(preferredLocale, 'task.messages.canceled')}: ${report.reportName}`;
            }
}

With this approach, we need to define visibleReportActionItems as we did in SidebarUtils.
We also can consider to create utils function to update alternative text to avoid duplicated code

Proposal
Please re-state the problem that we are trying to solve in this issue.
Difference between last message on LHN and task action message when canceled a task
What is the root cause of that problem?
When a task is deleted the backend returns deleted as the alternateText which is rendered directly here:
https://github.com/Expensify/App/blob/8da0ab14749918c72e2a4c40bcde1230c11d9334/src/components/LHNOptionsList/OptionRowLHN.js#L264
What changes do you think we should make in order to solve the problem?
Borrowing from this concepts:
https://github.com/Expensify/App/blob/8da0ab14749918c72e2a4c40bcde1230c11d9334/src/components/ReportActionItem/TaskPreview.js#L83
we can add one line :
    optionItem.alternateText = (optionItem.alternateText === 'deleted', optionItem.isTaskReport) ? translate('task.messages.canceled') : optionItem.alternateText;

https://github.com/Expensify/App/blob/8da0ab14749918c72e2a4c40bcde1230c11d9334/src/components/LHNOptionsList/OptionRowLHN.js#L160
What alternative solutions did you explore? (Optional)
N/A

I think we're good to go with @namhihi237's proposal here. The RCA is correct and the fix is nice and simple - I do also like the idea of using getTaskReportActionMessage for consistency.
@namhihi237 Please comment in this thread so that you can be assigned.
:ribbon::eyes::ribbon: C+ reviewed

Not overdue, just assigned

PR merged

The PR that introduced the bug has been identified. Link to the PR: N/A - looks like the behaviour has always been there
The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: N/A
A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: N/A
Determine if we should create a regression test for this bug. Yes
If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Regression Test Proposal

Open any chat
Click + in composer and Assign task
Fill out any details to create the task
Cancel the task
Verify that the last message on LHN and task report both display the same message, deleted task

Do we agree 👍 or 👎

@johncschuster Checklist complete, friendly bump for payment! :bow:

@johncschuster bump for payment

Thanks for the pings, everyone! Working on this now.

Ok folks! Payment has been issued! Thanks for your patience!

(Leaving this open for me to create the Regression test issue)


Matching up predicted with ground truth sites

Both for identification and for quantification one needs to identify which predicted site corresponds to which ground truth site, if a 'site' is not a single base. The script should take as input bed files for both predicted and ground truth data, as well as a distance parameter that specifies the maximum shift between predicted and ground truth site.

Related: #8 and #9

After our discussion @ninsch3000 found bedtools window as a promising approach to accomplish the distance based overlaps between BED files.


javascript code inside rails view not running

I have a javascript code in a rails view which runs depending on the URI of the page. For example if it has a fragment in the URI it changes it to query string.
if(window.location.hash)
    window.location.href = window.location.href.replace(/#/, '?fragment=')

I need this in order to do something with the fragments on the server side. But it appears that capybara-webkit is not running this javascript, cause when I check the current_url is not displaying the expected behavior. For example i have a request /login#users then i convert that to '/login?return_to=users'. This works with selenium though

We have a number of test cases around current_url and window.location, but the behavior there isn't always clear cut. Is there a minimal test case you could put together for the issue you're seeing?

Sorry for the late reply. Sure, I will gladly do it, but can you please give me some instructions on how to do it?

Sure, I will gladly do it, but can you please give me some instructions on how to do it?

Sure!
If you can put together a running example that I have access to, such as a GitHub repo or Gist, I can run it locally and poke at it to try and debug. The fewer moving pieces there are, the easier it will be for me to determine what the issue is.
A popular choice is a single repository with a Sinatra app and a single Capybara test.

Here is the repo url though funny thing is here with Sinatra it works. But with Rails I wasn't able to do it. I will setup a scenario with Rails just to make sure that I'm not the one that gives a false issue.

Alright, thanks for the update.

Really sorry for delaying this. I've managed to simulate the fail. Here is the repo. It appears that capybara-webkit doesn't run the script on redirects. If I'm not clear enough you can ping me at any time.

@ristovskiv that's not valid JS you need {}s around the code that executes when the conditional is true - you're writing JS in the view not coffeescript

@twalpole  It's valid http://stackoverflow.com/questions/4797286/are-curly-braces-necessary-in-one-line-statements-in-javascript

Whoops, my mistake - deleting

@ristovskiv I am unable to get that repo to run - I get a a stack level too deep error when attempting to migrate the database.  If you can fix and update the repo to current gem versions and ensure it works I will take a look ASAP

@twalpole the database is pretty simple, it only has one 1 migration file with 1 table/relation.

@ristovskiv Now that you locked the repo to ruby 2.3.3 it works for me, not sure why it wasn't before.
Looking at the output of this I don't think it has anything to do with capybara-webkit, rather the redirect from / doesn't include the fragment, so the request to /user/sign_in doesn't have a fragment for the JS to work with.
Started "Visit(http://<IP_ADDRESS>:61640/#something)"
Load started
"Visit(http://<IP_ADDRESS>:61640/#something)" started page load
Started request to "http://<IP_ADDRESS>:61640/#something"
Finished "Visit(http://<IP_ADDRESS>:61640/#something)" with response "Success()"
Started request to "http://<IP_ADDRESS>:61640/users/sign_in"
Received 302 from "http://<IP_ADDRESS>:61640/#something"
Started request to "http://<IP_ADDRESS>:61640/assets/application-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.css"
Started request to "http://<IP_ADDRESS>:61640/assets/application-2076ceeb8dca6913905558947e208161252b023ab6c101b318654fdc580fd838.js"
Received 200 from "http://<IP_ADDRESS>:61640/users/sign_in"
Received 200 from "http://<IP_ADDRESS>:61640/assets/application-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.css"
Received 200 from "http://<IP_ADDRESS>:61640/assets/application-2076ceeb8dca6913905558947e208161252b023ab6c101b318654fdc580fd838.js"
Page finished with true

This would appear to be an issue with QtWebkit, and may just have been the way webkit browsers worked back when the QtWebkit version being used was released - https://www.w3.org/TR/cuap#uri

@jferris @mhoran I don't know enough about the Qt network handling to quickly figure this out.  Do you know where capybara-webkit is handling redirects itself, or just letting the QtWebkit default behavior happen?

These redirects are handled by QtWebKit itself. We hook in to the network manager in a few places but mostly such behavior is inherited from WebKit.


Very large images due to multistage Dockerfile error

Hello,
I noticed that images for 23.10-trtllm-python-py3 are about 10 GB larger than other Triton server images. This is due to a bug in your Dockerfile here: https://github.com/triton-inference-server/tensorrtllm_backend/blob/47b609b670d6bb33a5ff113d98ad8a44d961c5c6/dockerfile/Dockerfile.trt_llm_backend#L51
-FROM trt_llm_backend_builder as final
+FROM base as final

You are accidentally including all the builder stages, defeating the point of having a multi-stage Dockerfile.

@mtaron  Thanks for pointing that out, we already have a fix in the internal codebase, which will be included in the next update to GitHub.
Before that, please use the modification as you shared as a workaround, thanks!

Sorry, the changes are not going to be included in today's update to GitHub. We realized that if the line is modified to FROM base as final, the latest version of TensorRT is not going to be included in the container, which will lead to an issue when using it. However, if you install TensorRT and PyTorch in the last stage of the dockerfile, the size of the container is not going to be reduced much compared to what we have for now.
We'll keep the dockerfile for a while until we find a better solution, does that make sense to you? @mtaron Thanks again for reporting the issue.

Ah, yeah - you'll always have two versions of TensorRT in the container (as far as image size is concerned) unless you use a base image without it or the base image has the version you want.


Just a question about how I can exit boot services correctly.

I've tried my best to look for the docs about how I can exit boot services in last few days. However, I don't found anything about it.
I'm a green hand on this, sorry. QAQ
I know that on EDKII, I can just use BootServices->ExitBootServices(ImageHandle, Mapkey), but what should I do when I'm using this crate?
I tried  this:
let _ = system_table.exit_boot_services(MemoryType::BOOT_SERVICES_DATA);
But whether the memory structure changes has nothing to do with whether I execute this
And this:
let _ = system_table.exit_boot_services(MemoryType::CONVENTIONAL);
qemu just reboot.
I have seen a signature similar to that implemented in EDKII in &BootServices, but it cannot be used for security reasons.
So, ...
What should I do?
Best wishes for everyone can help me (and cannot help me).
QAQ
My code:
fn main(image_handle: Handle, mut system_table: SystemTable<Boot>) -> Status {
    uefi::helpers::init(&mut system_table).unwrap();
    system_table.stdout().reset(false).unwrap();
    let boot_services = system_table.boot_services();

    //File Init
    let simple_file_system = boot_services.get_image_file_system(image_handle).unwrap();

    //Load Kernel
    let entry_point_addr = load_kernel(cstr16!("\\kernel.elf"), boot_services, simple_file_system);
    let entry_point: extern "sysv64" fn(&FrameBufferInfo, &MemoryMapInfo) -> ! = unsafe { mem::transmute(entry_point_addr) };

    //Graphic Init
    let frame_buffer_info = get_frame_buffer_info(boot_services);
    println!("FrameBuffer Info:\n - base_addr: {:#x}\n - screen_width: {}\n - screen_height: {}\n - stride: {}",
        frame_buffer_info.base_addr,
        frame_buffer_info.screen_width,
        frame_buffer_info.screen_height,
        frame_buffer_info.stride,
    );

    //Memory Map Init
    let memory_map = get_memory_map_info(boot_services);
    println!("MemoryMap Info:\n - map_size: {}\n - map_desc_size: {}",
        memory_map.map_size,
        memory_map.map_desc_size
    );

    //Exit Boot Services
    println!("Now Exit the Boot Services");
    let _ = system_table.exit_boot_services(MemoryType::BOOT_SERVICES_DATA);

    //To Kernel
    entry_point(&frame_buffer_info, &memory_map);
}

//...

fn get_memory_map_info(boot_services: &BootServices) -> MemoryMapInfo {
    let memory_map_size = boot_services.memory_map_size();
    let entry_size = memory_map_size.entry_size;
    let map_size = memory_map_size.map_size;

    let buffer_size = map_size + 8 * entry_size;
    let buffer = boot_services.allocate_pool(MemoryType::LOADER_DATA, buffer_size).unwrap();

    let memory_map_ptr = buffer as *mut u8;
    let mut memory_map_buffer = unsafe { slice::from_raw_parts_mut(memory_map_ptr, buffer_size) };

    let memory_map = boot_services.memory_map(&mut memory_map_buffer).unwrap();

    let memory_map_descriptors = memory_map.get(0).map_or(ptr::null_mut(), |desc| desc as *const _ as *mut MemoryDescriptor);

    MemoryMapInfo {
        memory_map: memory_map_descriptors,
        map_size: (memory_map.entries().count() * entry_size) as u64,
        map_desc_size: entry_size as u64
    }
}

The rest parts are ok.

Hey there!
First, I'd like to ask you to provide an example that compiles and runs the next time you are asking for help. This makes it much easier to reproduce.
I stripped down your example to a version that compiles:
#![no_main]
#![no_std]

use log::info;
use uefi::prelude::*;
use uefi::println;
use uefi::table::boot::MemoryType;

#[entry]
fn main(image_handle: Handle, mut system_table: SystemTable<Boot>) -> Status {
    uefi::helpers::init(&mut system_table).unwrap()

    //Exit Boot Services
    log::info!("Now Exit the Boot Services");
    let _ = unsafe {
        let _x = system_table.exit_boot_services(MemoryType::BOOT_SERVICES_DATA);
    };
    log::info!("Exited boot services");

    loop {}
}

Here, I can't reproduce anything.
Tip: You can put your minimal reproducer into <uefi-repo>/uefi-test-runner/examples/your_example.rs and run it using cargo xtask run --example your-example. The <uefi-repo>/integration-test-debugcon.log file will contain log messages even after boot services have been exited.
Perhaps you can debug further with that.

OK
For now, I've found that the problem I met isn't how I can exit(Maybe I don't understand the docs correctly)
It is just I can't get the correct entry_size and map_size
for me,
map_size / entry_size == 111
however, when i try to check every desc, the last few is like this:
type = EfiReservedMemoryType
size = (a big number)
type = EfiReservedMemoryType
size = 0
type = EfiReservedMemoryType
size = 0
......
(Size is in pagination units)
We all know that the type EfiReservedMemoryType means 0
so maybe i've tried to read some wrong data.(because size won't be 0)
How i can do to get correct data?
    let memory_map_size = boot_services.memory_map_size();
    let entry_size = memory_map_size.entry_size;
    let map_size = memory_map_size.map_size;

Cannot I just use this?
(Then I'll exit the boot services)
    let (_system_table_runtime , _iter) = system_table.exit_boot_services(MemoryType::LOADER_DATA);
    let memory_map_descriptors = _iter.get(0).map_or(ptr::null_mut(), |desc| desc as *const _ as *mut MemoryDescriptor);
    let memory_map = MemoryMapInfo {
        memory_map: memory_map_descriptors,
        map_size: map_size as u64,
        map_desc_size: entry_size as u64
    };

I'm not sure what you are doing there. Why are you creating your own MemoryMapInfo type? The MemoryMap that is returned by uefi already combines the meta data and the memory map itself?

Any update, @OrdChaos ? Will re-open if you reply and there are things to do on our side


Plan always wants to add USAGE permission, although it already exists

Terraform CLI and Provider Versions
Terraform Cloud, terraform v1.6.5
snowflake-tf-provider v0.87.2
Terraform Configuration
resource "snowflake_grant_privileges_to_account_role" "tenant_warehouses_grants" {

  privileges        = ["USAGE", "MONITOR", "OPERATE", "MODIFY"]
  account_role_name = "MY_ROLE_NAME"

  on_account_object {
    object_type = "WAREHOUSE"
    object_name = "\"${var.warehouse_name}\"" # note this is a fully qualified name!
  }
}

Expected Behavior
I expect the warehouse to be created with all permissions.
Actual Behavior
Warehouse is created.
On all following plans, the plan is shown as adding the USAGE permission, although it already exists. This results in the plan always showing a change that should not be happening.
Steps to Reproduce

plan and apply the resource once
run another plan, see plan to add USAGE permission again.

How much impact is this issue causing?
Medium
Logs
No response
Additional Information
This is a similar issue to: https://github.com/Snowflake-Labs/terraform-provider-snowflake/issues/2533
however, I upgrade the snowflake provider to v0.87.2, and the issue persists.

Hey @nick-amplify
Do you see in the logs that something similar to grant usage on warehouse "TEST_WAREHOUSE" to role "MY_ROLE_NAME"; is ran on terraform apply and show grants on warehouse "TEST_WAREHOUSE"; returns USAGE as one of the warehouse grants? For now, I don't see why that wouldn't work, but I'll try to reproduce the issue tomorrow morning.

Usage is definitely shown as one of the grants when I run show grants on the warehouse.
I'm not sure if terraform cloud gives me access to the raw snowflake commands that it runs. I am looking for them now. If found, I will update this ticket

As far as I remember the only thing you need to set is the TF_LOG environment variable to DEBUG. Then you'll have more logs in terraform plan/apply along with logs that show exactly what SQLs are being run. I ran the following config and it worked (no plan produced by Terraform):
resource "snowflake_warehouse" "test" {
  name = "test_warehouse_grants"
}

resource "snowflake_role" "test" {
  name = "test_account_role_grants"
}

resource "snowflake_grant_privileges_to_account_role" "test" {
  privileges        = ["USAGE", "MONITOR", "OPERATE", "MODIFY"]
  account_role_name = snowflake_role.test.name

  on_account_object {
    object_type = "WAREHOUSE"
    object_name = snowflake_warehouse.test.name
  }
}

Try to post the logs with TF_LOG=DEBUG enabled, so I'll be able to see SQLs.

Hey 👋
Try changing this: object_name = "\"${var.warehouse_name}\"" to this object_name = var.warehouse_name. If no logs will be provided, I'm closing the issue as I'm not able to reproduce it from the given example.


How get buffer of converted Image

hi
Is that possible to get Buffer of converted Image.I've tried it but it return null
let ImageURI = req.body.data.thumbnailBlob;

    let buf = new Buffer(ImageURI.replace(/^data:image\/\w+;base64,/, ""),'base64');

    Jimp.read(buf,(err,image) => {
       if(err) {
           console.log(err)
       }
       image.cover(250,250)
           .getBuffer( "image/jpeg",(Buff) => {
               console.log(Buff)//null
           })
    })

@githubitsme Same issue here, how did you managed to overcome this situation?

The code of write can help in this situation:
https://github.com/oliver-moran/jimp/blob/7fe1d467417b995939019bc5f4fdb919741e9113/packages/core/src/index.js#L507


api: Document realm/emoji and realm/filters/* endpoints.

Testing Plan: test-api, mypy and lint checks passed locally. Made sure that the docs display properly.

I merged the first few commits, after fixing the link to regular expressions to point to the Python 3 docs for them.

Fixed the merge conflicts. Let me know if the remaining commits need further work.

I cleaned this up, added d13bd6e8d3963a74d5845b3084ef376f9e5150eb to reflect a rename we recently did, and merged this, thanks @YagoGG!
If you have a bit of time, it'd be super awesome if you were able to add API docs for adding a new realm emoji soon!  (That's why I prioritized finishing this PR today, before I discovered that endpoint was missing).  We have a bunch of users who want to import just their custom emoji from other tools like Slack, and having API docs for this would help a lot with that.


Fix stm32wl i2c driver LPM

Description
This PR introduce a fix for this issue :https://github.com/zephyrproject-rtos/zephyr/issues/37414 by adding a timing reinitialization  when PM resume
Type of change

Bug fix

Test steps

Choose a i2c sensor sample (Choose the one you have). For example samples/sensor/bme280.
Add CONFIG_PM=y
Build for the nucleo_wl55jc
Check that the sample work well with and without CONFIG_PM

Please squash your commits and provide a commit with a clear message. See urls provided by bot in upper message.

@Martdur you have some CI compliance issues (https://github.com/zephyrproject-rtos/zephyr/actions/runs/9112793159/job/25053821771?pr=72805).
Code can be formatted using clang-format -i my_source_file.c & you can check for compliance issues locally before pushing again using ./scripts/ci/check_compliance.py --commits HEAD~n..HEAD (with n being the number of commits in your PR)

I have been testing this pull request on a fleet of ~100 devices in production for the past two weeks, and it works very well. Huge thanks to @Martdur - delivering our project on a tight schedule without your commit would be hard.

I have been testing this pull request on a fleet of ~100 devices in production for the past two weeks, and it works very well. Huge thanks to @Martdur - delivering our project on a tight schedule without your commit would be hard.

Thanks for this feedback. Unfortunately, this can't be merged as is and basically the way to go is https://github.com/zephyrproject-rtos/zephyr/pull/72805#discussion_r1612262810

Thanks for this feedback. Unfortunately, this can't be merged as is and basically the way to go is #72805 (comment)
@erwango The last modification that I brought doesn't satisfy what aurel32 said ?

Thanks for this feedback. Unfortunately, this can't be merged as is and basically the way to go is #72805 (comment)
@erwango The last modification that I brought doesn't satisfy what aurel32 said ?

I understand this PR can be further optimized from a power consumption perspective, but this commit fixes something that is broken today. How about splitting this work into two steps - fix the main branch first and optimize it with the correct PM approach?
What do you think @Martdur and @aurel32 ?

Keep it open

Thanks for this feedback. Unfortunately, this can't be merged as is and basically the way to go is #72805 (comment)
@erwango The last modification that I brought doesn't satisfy what aurel32 said ?

@erwango Maybe @Martdur is stuck because there is an unanswered question in this thread. I have also overlooked this before... Thank you.

@erwango Maybe @Martdur is stuck because there is an unanswered question in this thread. I have also overlooked this before... Thank you.

@hubpav Are you referring to this comment ? I've just answered. If you see another point, just let me know.


Feature/fix sass warning chlorophyll

Created new PR with changeset. As earlier PR didnt result in release

@GauriKudtarkar This is correct, but I already added a changeset for this to an other PR :) #1573


Can't select an option rendered in a portal in a Dialog modal=true

I'm using the Dialog primitive to build a Drawer component and inside the Dialog / Drawer I need to use a headlessui combobox which has some options to select rendered in a portal (hence outside the radix Dialog root) but when trying to select any option from the combobox won't let me do that because the Dialog is a modal and it prevents clicking outside the Dialog (unless is the overlay).
If I set modal= false I can selected the wanted options from the portal but I lose the Dialog Overlay. Can someone advise if there's a way to have both the Dialog modal= true AND the option to interact with elements in a portal outside of the Dialog?
this is the version used for radix ui Dialog: "1.1.1"

Same here. Does anyone have a good idea?

Same here

Same issue here.
For now I switched to using the prop modal set to false and rendering a manual backdrop like below.
But just tried if it works in general. It's possible that it might cause some issues I am not aware of right now.
export const Dialog = ({ children, ...props }: DialogPrimitive.DialogProps) => {
  return (
    <DialogPrimitive.Root modal={false} {...props}>
      {props.open ? (
        <div className="fixed inset-0 z-50 grid items-center overflow-y-auto bg-black/30 data-[state=open]:animate-overlayShow" />
      ) : null}
      {children}
    </DialogPrimitive.Root>
  )
}```

Would love to know what the real answer is to this issue. There appears to be no way to manage the stacking of portals across libraries. (i.e. Radix / Headlessui)

The problem is that both the Radix Modal and HeadlessUI Combobox are rendered in two separate portals, where they don't know from each other which state they are in. If you use anchore={} in your Combobox this will cause the issue that you can't click it anymore. You can absolutely position it relative to the modal it is in. You can also use useFloating (which is used by headless under the hood), and assign this to the container of the Combobox:
const { refs, floatingStyles } = useFloating({}) and then on the container: ref={refs.setFloating} style={floatingStyles}.
Now you should be able to use the Radix dialog as a Modal, and still use the HeadlessUI Combobox inside of it.


nitroshare is just a garbage. it can not work for ubuntu18 between Android at all.

@nathan-osman This issue can be closed. It is a duplicate.


[e2e]: generic tag main annotated slsa3

Repo: https://github.com/slsa-framework/example-package/tree/v26.0.605
Run: https://github.com/slsa-framework/example-package/actions/runs/8548291485
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.generic.tag.main.annotated.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.generic.tag.main.annotated.slsa3.yml
Trigger: push
Branch: v26.0.605
Date: Thu Apr  4 02:17:28 UTC 2024

Repo: https://github.com/slsa-framework/example-package/tree/v26.0.606
Run: https://github.com/slsa-framework/example-package/actions/runs/8564026089
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.generic.tag.main.annotated.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.generic.tag.main.annotated.slsa3.yml
Trigger: push
Branch: v26.0.606
Date: Fri Apr  5 02:16:58 UTC 2024
Tests are passing now. Closing this issue.


[2JH] UI Profile Page

Describe the issue
A page to view and edit the information of a pentester / manager
Resource request
route backend to get user info @bogdzn
Choose the location and add an icon to go to this page @claraxuxu
Definition of done

user can view the information available in his profile
user can edit and save info

testing plan
-unit test
JEH
2

To get the full API specifications, you can just use /docs endpoint in the API in your browser. There is currently a crash on startup for the back-end but i'm working on it.

^ fixed in #70; please check docs once it's merged in next =)


Should we expect Windows container base images labelled 21H1/10.0.19043.X?

In a discussion related to https://github.com/adamrehn/ue4-docker/issues/164, we realised with growing concern that there doesn't seem to be hide-nor-hair of either a Windows Server SAC 21H1 release, and neither 21H1 nor 10.0.19043.985 are listed in the tags on https://hub.docker.com/_/microsoft-windows-servercore
That said, I also noticed that the Windows Server container update history has always marked the feature-enablement releases (1909, 20H2) with the same kernel as their base release (1903, 2004), which matches my existing intuition that those containers would be cross-compatible, but conflicts with the Windows container version compatibility docs regarding process isolation.
So for those use-cases where it's useful to have a Windows 10 client with the recommended release (currently 21H1), even if there's no matching Windows Server SAC release to go to production with, do any of the following apply?

❌ Process-isolation of 2004 and 20H2 images on 21H1 is supported, and the cross-version compatibility tables were simply overlooked?
❌ There will be a 21H1 set of container images in the June updates, and it's only missing now because the May update of the container images for 10.0.1904n.985 was a week before Windows 10 21H1 was released?
❌ Is there a Windows Server SAC 21H1 release in the pipeline that will bring 10.0.19043.X container images, and we just haven't heard much about it because everyone's focused on (excited for) Windows Server LTSC 2022?

Edit: None of the three dot-points above have proved out, in retrospect.

I want to add that [Windows base image](https://hub.docker.com/_/microsoft-windows] also still doesn't exist for 21H1 after a month since its release.

I think the "Windows" base image, is still technically Windows Server, just with more DLLs, rather than being a Windows 10 (Client) container image.
That might be why it's being replaced with the new "Windows Server" container image, since that will be less confusing. I suspect they had the same build source, "Windows Server with Desktop Experience".
I saw mention the other day that there won't be a 21H1 SAC release.
So I guess 21H1 is the point where Windows 10 and Windows Server diverge now, rather than 21H2/LTSC 2022 as I would have predicted. I don't know if there's any plans to reconverge them or not... I feel like the 20H2/21H1 feature update releases took quite a few people by surprise, so it's an open field for predictions now.

@adamrehn inadvertently tested a Windows Server 20H2-based container image on a Windows 10 21H1, and it indeed failed to run in Process Isolation mode.

@TBBle I had also assumed that mcr.microsoft.com/windows was derived from Windows Server, but it actually reports itself as a client version of Windows 10 when querying the system information, and the announcement for the new Windows Server image variant confirms this:

Some of the constraints are by design because that Windows container image is built from a full Windows Client edition and enabled to run on Windows Server.

There also doesn't seem to be any suggestion that the new container image will replace the old one, but rather that both will coexist as available options for developers who are weighing image size against application compatibility.

The above information of course makes it all the more puzzling that there isn't a Windows 10 version 21H1 container image available, especially given that 20H2 images fail to run in process isolation mode under 21H1 host systems.

Ah, I had missed that note that the Windows image was derived from the Client edition.
The reason I assume the Windows Server image replaces the Windows image, is that the Windows insider image tags stop at build 20324, and the Windows Server insider image tags start at build 20329, weeks before the latter was formally announced with build 20344 (the last Insider build before Windows Server 2022 Preview locked down).
It also makes sense to me to drop a Windows 10-based image, since there was no Windows 10 release from that series for installation after 20279, the next Insider Preview was a 21xxx release from a different branch, so this is basically keeping a client build alive for a fairly niche use-case that should be covered by the Windows Server image. There won't be a Windows 10 release matching the kernel for Windows Server 2022 LTSC, so this isn't just a temporary "Insider-only" situation anymore.

The one concern I would have about the Windows Server base image replacing the Windows client base image is whether the former will have SAC releases like the latter has up until now. For both Windows Server 2016 and 2019, the Desktop Experience component was exclusive to LTSC releases, and the new Windows Server image is built with Desktop Experience as a key component. I've not seen any indication yet as to whether Windows Server 2022 will reflect its predecessors in this regard (Server Core and Desktop Experience configurations available for LTSC, only Server Core available for SAC.)

Any update on this? Can i launch windows containers with process isolation on w10 pro 21H1 laptop?
Downloaded 20H2 container and got " The container operating system does not match the host operating system." error.

@BumbrT as far as we can tell, there's currently no way to run process-isolated containers under Windows 10 version 21H1. If your machine has an Intel CPU then you can run 20H2 in a Hyper-V virtual machine with nested virtualisation enabled in order to use both process isolation mode and Hyper-V isolation mode as needed. If your machine has an AMD CPU like mine does then the best workaround I've found is to boot a copy of 20H2 from a VHDX file using Native Boot, which as a bare metal installation also has the benefit of being able to run GPU accelerated Windows containers. If you're interested in doing this, it's pretty easy to configure:

Obtain an installation ISO for Windows 10 version 20H2 (either using Rufus or through your Microsoft account if you have a Visual Studio subscription or a volume license that includes software assurance.)

Use my Windows Insider VHDX Boot script to prepare a VHDX file and add a boot entry for it, modifying the variables (and optionally the boot entry description string) to point to the Windows 10 version 20H2 ISO file rather than an Insider Preview ISO.

Still no updates from Microsoft? @weijuans-msft?

This is an incredible oversight. @weijuans-msft

The next Windows Server release is Windows Server 2022, an LTSC. There is no Windows Server version 21H1 or any container image of that version planned.
Curious why folks need to run process isolated containers on Windows 10. Process isolated containers are officially only supported on Windows Server.
You could try Windows 11 with Windows Server 2022 container images with process isolated containers.

Windows Server 2022 Preview is build 20348, Windows 11 Insider Preview is 22000. Will the latter run the former process-isolated?
Also, there are no Windows Server 2022 Preview container images for build 20348, the most recent builds on Docker Hub are for the last Windows Server 2022 Insider Preview, build 20344.
There are probably a lot of use-cases for running process-isolated containers on Windows 10. My primary ones are:

Iterating on large-scale container software (like ue4-docker) on my development environment.

Hyper-V isolation is blocked here because docker build doesn't support --cpu-count on Windows, and with the default (2 core) available, an 8-hour build in process isolation becomes more than 24 hours.
My desktop machine is significantly more powerful than a server I would be allocated if I needed to use Windows Server to iterate on the software, unless I pull one of the actual build-pipeline servers which slows everyone else's builds down.

Using utility containers (e.g. ue4-docker, again) on my desktop machine. I don't want to need to copy my work to a Windows Server machine, run the container, and then copy the results back every time.

I don't do this much, mostly when working on the above.

Actually working on the container infrastructure itself as a hobby project. I don't have a license for Windows Server personally, so Windows 10 is the only platform where I can work on integrating WCOW features into containerd, or contribute changes to hcsshim, etc.

Without process isolation, I would be building and testing a code-path that is significantly different than what is intended for production use.
Docker's WCOW integration tests, for example, don't support Hyper-V isolation currently. Neither does Kubernetes currently.

The next Windows Server release is Windows Server 2022, an LTSC. There is no Windows Server version 21H1 or any container image of that version planned.
Curious why folks need to run process isolated containers on Windows 10. Process isolated containers are officially only supported on Windows Server.
You could try Windows 11 with Windows Server 2022 container images with process isolated containers.

I can only find these usages, mostly from Microsoft examples: https://grep.app/search?q=--isolation[%3D ]process mcr\.microsoft\.com/windows&regexp=true
In the industry process isolation is the most efficient way to run many DirectX applications concurrently for e.g. streaming games. But I don't know if DirectX supports Present in that context because my tests segfault. Process isolation would be way nicer if you called NVIDIA and asked them to enable WDDM 2.7+ features on their GPUs - similar for other device manufacturers. Otherwise if you're building Unreal Engine or Unity games and don't need DXR, people use Vulkan on Linux.
Thanks for taking a look at this issue.

@doctorpangloss the NVIDIA drivers are already WDDM 2.7 compliant, and offscreen rendering with DirectX works just fine in GPU accelerated Windows containers. If you copy the right files to System32 at runtime you can even use other APIs such as CUDA and NVENC. See these articles for details:

https://unrealcontainers.com/blog/offscreen-rendering-in-windows-containers/
https://unrealcontainers.com/blog/enabling-vendor-specific-graphics-apis-in-windows-containers/

With the code from those articles, I've been able to successfully run Unreal Engine applications inside Windows containers (with raytracing enabled) and stream the output to a web browser over WebRTC using the Unreal Engine Pixel Streaming system. Testing this functionality has been my primary use case for process-isolated Windows containers outside of the ue4-docker development use cases that @TBBle already mentioned above.

Curious why folks need to run process isolated containers on Windows 10.

We develop .NET applications (full framework, not .NET 5 (yet)) and use process isolation to run the application. Without process isolation, there's a significant overhead while developing. Using process isolation is much better performant and way more stable.

Process isolated containers are officially only supported on Windows Server.

According to the MS docs (https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container#isolation-examples), process isolation on Windows 10 is only for development / testing (which we all do above) and production workloads should only be deployed on Windows Server (which makes sense).

Curious why folks need to run process isolated containers on Windows 10.

+1 to https://github.com/microsoft/Windows-Containers/issues/117#issuecomment-886278767.
We develop containers on our desktop machines. Process isolation is faster and has smaller memory overhead. Process isolation supports device sharing unlike Hyper-V isolation.

Also chiming in to say that not having 21H1 images hurts us since we use them for application development (i.e. we cannot upgrade the machines, and had to downgrade the ones that already updated).
Hyper-V is not a viable alternative due to it needing significantly more resources (i.e. it's a lot slower) and some issues with the version of MS build tools that we're using (https://github.com/dotnet/msbuild/issues/3360).
It's very disappointing that MS seemingly discontinued this without much fuss. It can't be that hard to provide these images...

Curious why folks need to run process isolated containers on Windows 10.

One clear advantage of having process isolation for containers on a development machine is RAM usage.
A running Hyper-V can require blocking a lot of RAM for the container (the maximum RAM needs to be known when starting the container).
With process isolation a developer can start as many containers as necessary since the RAM will be shared with the host.
In process isolation you only incur the RAM cost when starting tasks in containers versus having it reserved all the time with Hyper-V witch brings a lot more flexibility.

It's very disappointing that MS seemingly discontinued this without much fuss. It can't be that hard to provide these images...

I suspect it might be actually hard to provide the servercore and nanoserver images, because there was no Windows Server SAC release to build them from.
I agree that it should have been messaged better (or messaged at all...) so that alternative measures could be taken earlier. The missing Windows Server 2022 Preview images makes me wonder what MS's own Containers team are using for their development flow.
Also, an addendum for my previous answer: My development box at home doesn't qualify for Windows 11, as I have a 5th-Generation i7, and Windows 11 requires 7th Generation (or 8th?). As it is, this issue is holding me back from the 21H1 upgrade, and I wouldn't upgrade to Windows 11 unless I knew there was a process-isolation-compatible Windows base image set available to me after the upgrade.

Well, I see that Windows Server SAC is dead, and with Windows Server Insider Previews also (temporarily) gone, and no container base image for Windows Server 2022 Preview, the answer to this question is "No, and unless you grabbed the Insider ISOs already, you can't use Windows Server for this either".

Interesting. Although Azure Stack HCI is stated to be the container-focussed replacement for SAC, it looks like that doesn't have a release newer than 20H2 at the moment either: https://docs.microsoft.com/en-us/azure-stack/hci/release-information

Azure Stack HCI 20H2 is build 17784, i.e. it's an iteration on Windows Server 2019 (build 17763) underneath but was released in H2 2020; release name is the only relation it has to Windows 10 20H2 or Windows Server SAC 20H2, aka build 19042.
The Azure Stack HCI 21H2 Public Preview is build 20348, i.e. Windows Server 2022. So at least to start with, it should be process-isolation-compatible with Windows Server 2022, assuming neither Server 2022 Preview nor Azure Stack HCI 21H2 Preview see a build bump before leaving Preview.
So it'll be interesting to see if Azure Stack HCI sees SAC-frequency build updates or not. It'd be weird if it did, as that requires either making cross-build process isolation feasible and supported, or releasing new base images every six months to go with the new SAC release of Azure Stack HCI, without a Windows Server SAC release to go with them. I guess that's feasible, if you're not updating the new Windows Server image for Azure Stack HCI, just Server Core and (hopefully...) Nanoserver.
Despite the SAC announcement pointing at Azure Stack HCI for containers, Azure Stack HCI docs don't seem to discuss containers, except in the context of AKS-on-HCI, and that doesn't yet acknowledge the Azure Stack HCI 21H2 Public Preview. I've never looked at HCI, so I don't know if it's just going unmentioned that you could run DockerMSFTProvider like you would on Windows Server if that's the use-case you have.
Anyway, if Azure Stack HCI is going to be semi-annually updated, then we'll be back to where we were before dropping SAC (i.e. a Server LTSC release or two plus some number of more-frequently-released targets to support when building images for WCOW), except we lose the ability to develop on Windows 10.

no container base image for Windows Server 2022 Preview

Container base images for the Windows Server 2022 Preview have been published to the "Insider" pages on Docker Hub now.

Thanks @TBBle. This was a human error re: no Insider builds of 20348 container images were published early. I have thought the eval version of Windows Server 2022 was 20344 and didn't notice it was updated to 20348. My bad. We now have it fixed. Please do feel free to ping me on Twitter or use our email<EMAIL_ADDRESS>for urgent issues. This Git-Hub community is great too but I missed seeing this issue in this long thread.

Windows 10 Enterprise is a Client build, and the Server Core and Nano Server images are built from the Server build; there was no Windows Server 21H1 (build 19043) release, so there are no container images for build 19043 available or planned, per https://github.com/microsoft/Windows-Containers/issues/117#issuecomment-886266148.
I have a PR open to update that table: https://github.com/MicrosoftDocs/Virtualization-Documentation/pull/1596

Okay, so 21H1 is a dead end and better would never exist container-wise and technically this issue can be clised as WONTFIX. Now the question is whether Windows 11 is going to get a matching Windows Server image that can be run with process isolation. If not... I don't quite understand how you expect people to do container development at all. Buying and installing Windows Server for desktops/notebooks just not going to work and Hyper-V isolation has too many shortcomings to be usable.

Hi @weijuans-msft  , I would like to raise awareness to another reason why isolation mode can be a necessity and would appreciate it very much if isolation mode is robustly supported across all Windows 10 versions.
Hyper-V does not support symbolic links or directory junctions to shared volumes for Windows containers. In my use case, these are heavily used for build tasks in a Dockerized CI/CD system for Windows targets. I have not been able to find a workable solution with Hyper-V, see https://github.com/moby/moby/issues/37024 and https://github.com/moby/moby/issues/40125 .

I'm going to test the LTSC-2022 Windows Server Core image on a WIN-21H1 (OF COURSE in 'process' isolation mode) and I think it will work just fine as it does for LTSC-2019 on a WIN-1809. ;-)
I will write here the result. :-)

@mtola, in order to run image in process isolation you need to have matching kernel versions of OS and image, you can run older versions in hyperv isolation mode and it is not possible to run fresher images in any mode. 21H1 is 19043.1165, ltsc2022 is 10.0.20348.169 - there is a small chance that you can run ltsc2022 in 21H2, but not in 21H1

Windows 10 21H2 Insider Preview builds are 19044.xxxx, I doubt that will change.

Yes, it is more likely that windows 11 will have matching kernel (currently it is 22000.168) but I have a feeling that docker on client windows is dead. Waiting for WSL2 like windows server support now.

Windows 11 kernel is 22000, so it's also not the same as 20348 (it's in fact much newer).
So Windows 11 would be able to run Windows Server 2022-based containers in Hyper-V isolation, but not process isolation.

I don't see much difference between docker in hyper-v isolation mode and client windows containers are dead.

I agree, 'process' isolation mode very very important for performance !

It is not just about performance, in my case hyper-v is not working at all (cygwin on mapped volume).

Hyper-V isolation solves a very similar problem to the problem of running Linux containers on Windows (VM-based, WSL2-based or LCOW), or the problem WSL solves (which depends on whom you ask).
Hyper-V isolation (and LCOW) is about running non-native userspace, which requires a matching isolated kernel, be it Linux or older Windows.
The main thrust of 'Containers' is running native userspace fast with a shared kernel but isolated resources. Process isolation delivers that.

Both Hyper-V and LCOW are working in limited set of cases, seeing that kernel compatibility is gone (having both Win10 & Win11 almost guarantees that). I'm hoping that at some point we will have server kernel available in client windows and some point - in that case we can have multiple different server kernels and they can run WCOW containers without restrictions of hyper-v mode.

I'm going to test the LTSC-2022 Windows Server Core image on a WIN-21H1 (OF COURSE in 'process' isolation mode) and I think it will work just fine as it does for LTSC-2019 on a WIN-1809. ;-) (because same 'kernel')
I will write here the result.

Ok, it don't works under 21H1...
docker pull mcr.microsoft.com/dotnet/framework/runtime:4.8-windowsservercore-ltsc2022
4.8-windowsservercore-ltsc2022: Pulling from dotnet/framework/runtime
a Windows version 10.0.20348-based image is incompatible with a 10.0.19043 host

So, hoping that microsoft decides to make a 21H1 image...

They cannot decide it. There is no 21H1 server, and looks like we would not have any more images which will work in process isolation mode on windows 10 and 11 anymore - unless some new approach would be introduced. If you need process isolation on windows 10 install 20H2 and never upgrade it.

They cannot decide it. There is no 21H1 server, and looks like we would not have any more images which will work in process isolation mode on windows 10 and 11 anymore - unless some new approach would be introduced. If you need process isolation on windows 10 install 20H2 and never upgrade it.

You can uninstall the feature update pack on Windows 10.

Windows 11 kernel is 22000, so it's also not the same as 20348 (it's in fact much newer).
So Windows 11 would be able to run Windows Server 2022-based containers in Hyper-V isolation, but not process isolation.

Windows 11 22000.168 seems to support docker with process isolation mode for Server 2022 LTSC. Interestingly in the container, it has version ".169" instead of ".168".
C:\>docker run -t --rm --isolation process mcr.microsoft.com/windows/server:ltsc2022 cmd.exe /c ver

Microsoft Windows [Version 10.0.22000.169]

Interestingly in the container, it has version ".169" instead of ".168".

The Windows Server 2022 LTSC container images are version 10.0.20348.169 (The original release version). I don't know if that's coincidental, a surprising new feature, or a bug that is going to get patched as soon as someone notices this...
Is everything I know wrong?
Conversely, is there any chance it ignored --isolation process and was running Hyper-V isolation?

Conversely, is there any chance it ignored --isolation process and was running Hyper-V isolation?

No. I thought it was possible too, but I confirmed it is using the 'silos' functionality (as visible in the object manager), and no VMs were running, processes in the container show up in the host task manager, etc.
Hopefully this is just some new scheme they haven't told us about and not something internal that slipped through. As long as the kernel interfaces are compatible, it doesn't matter if the kernel number is an exact match for the user components. Perhaps they have a new kernel interface versioning scheme that is independent of the actual kernel number.

Folks, to close on this conversation: We just released this blog post: https://techcommunity.microsoft.com/t5/containers/windows-server-2022-and-beyond-for-containers/ba-p/2712487
It covers SAC and LTSC plans as well as some important information about version compat. Please take a look and let us know if you have any questions/feedback.

@vrapolinario This is great news, thanks for the pointer!
But does this mean that there will never be images that work on 21H1 with process isolation?

Not for Windows 10 - Windows 11, yes.
21H1 has a higher build number than previous images and lower build number than Windows Server 2022.
Please let us know what your thoughts are on this. While there's no immediate answer other than what we shared in the blog post, we still like to know how this impact our customers.

That blog post also doesn't cover Windows 10 21H2, though one might assume it will work the same way as 21H1.

Any updates to Windows 10 will continue to be on the same build (19043), so this applies to any future update to Windows 10.

To be sure I understand the blog post completely, is this accurate:

the intention is that for any host kernel version 20348 or later, either Client (Windows 11) or Server (Windows Server 2022), process isolation will be supported for 20348-based images; and
container base images will be released with Windows Server LTSC releases, but will be usable in process isolation on kernels newer than that Windows Server release.

If I'm following correctly, this would mean an Azure Stack HCI release after 21H2 (i.e. with a kernel newer than 20348) can also be expected to run ltsc2022 base images in process isolation correctly?
The other thing I'm concluding from this is that the ltsc2022 base image is supported for 5 or 5+5 years, and this include being able to run in process isolation on newer kernels, so in theory rather than needing a slew of base images (five or six today, but with SAC ended and LTSC 2016 expiring soon, it was already trending towards two), we can just manage ltsc2022 images for the next 5 or 10 years, and Windows Server 2025 would still run those perfectly well, and it's only Windows Server 2028 where we might need to use a new image base. And ltsc2019 if required, as a legacy of the "before times". ^_^
That'll be a nice cost-of-play reduction for Windows containers, particularly for open-source where you have to either limit your users' options, or maintain a wide coverage of support. It'll help decouple migrations, allowing upgrading of, e.g., host systems in a build cluster, and validating them while the same images keep running on the existing, working hardware.
Obviously I'm making up "2025" and "2028" there, but those numbers illustrate one more question, if the above holds: Is the ltsc2022 image going to be supported by 5 years of kernels, or 10 years? Does "extended support" mean "It works with kernels released in that time", or just "it keeps working with kernels released while it was mainstream"?
Or perhaps I am conflating things, and the upper limit of "kernel versions that can host ltsc2022 images in process isolation" will be defined some other way.

Windows Server 2025 would still run those perfectly well

Err... Why do you think that? I'm under impression that ltsc2022 images are not going to be supported by Windows Server after 2022:

customers will be able to run their Windows Server 2022 container images with either process or Hyper-V isolation on any build of Windows Server 2022 or Windows 11.

The only improvement this new scheme has over what we had in the past is that now Microsoft promises not to break ABI in  minor updates (like Feb 2020 issue).
I do not count as improvement the fact that ltsc2022 images can be run on Windows 11 with process isolation. We could run containers with process isolation on client Windows since 1809 and it is a regression that 21H1/21H2 doesn't have a corresponding image that it can use for process isolation.

I was going from

Customers won’t need to worry whether their container image will run on a newer build of Windows Server 2022 or Windows 11 host.

I think I had parsed "newer build of Windows Server 2022" as "newer build of Windows Server". There won't be a newer build of Windows Server 2022, unless there are other significant release cadence changes coming, it'll be 20348 forever, while Windows 11 I expect will see newer builds after 22000 or whatever ships in October, like Windows 10 saw a new build every six months.
So yeah, I might have read that overeagerly... We never had the worry about LTSC 2019 container images running on newer builds of LTSC 2019, that was a supported use case (but not for LTSC 2016). So I guess I assumed that as a new promise, we'd be getting more than we already had.
Also, it seems a little arbitrary if you can run 20348-based containers on 22000 and 25456 (Windows 11 25H1), but not 25659 (LTSC 2025) (Invented build numbers, obviously). And the spirit of the whole paragraph seemed to me to be that the intention is to support down-version container images between Server releases, and we got Windows 11 hosting as a side-effect or preview of that, so that it's rock-solid once it becomes a 10-year-supported feature in LTSC 2025.
But that was really why I was checking my understanding, because I might have been reading too much into it.
I consider the Feb 2020 issue to be different, because that wasn't (AFAIK) a deliberate ABI breakage, but it was noticed after the fact that the security patch update had broken the ABI.
I definitely count "Can run older kernels in process isolation" as an improvement, that's a pretty big shift from where we were since LTSC 2019. I don't think it's fair to say it's not an improvement, because some other thing regressed.

it seems a little arbitrary if you can run 20348-based containers on 22000 and 25456 (Windows 11 25H1), but not 25659 (LTSC 2025) (Invented build numbers, obviously).

It also seems arbitrary that you can run 20348 on 21H1 but can't on 20H2. What's so different between them that makes 21H1 capable, but 20H2 uncapable? Anyway, I believe that if MS wanted to say "good news folks, now we have backward kernel compatibility and you'll be able to run your ltsc2022 containers on Windows Server 2022 and later + Windows 11 and later" they could say that in a much clearer way.

I consider the Feb 2020 issue to be different, because that wasn't (AFAIK) a deliberate ABI breakage, but it was noticed after the fact that the security patch update had broken the ABI.

I mean, now MS would ensure that kernel<->userspace ABI remains stable across patches. Before this promise, they were not expected to care about it.

Although the inability to use process isolation mode under Windows 10 version 21H1 has been frustrating, I'm far more interested in exploring the compatibility story going forward. (The temporary forwards-compatibility for Hyper-V isolation mode under Windows 10 version 21H1 is also really neither here nor there, other than to serve as a reminder that Microsoft is perfectly capable of enabling this scenario if they so choose.)
Much like @TBBle, I interpreted the blog post as stating that backwards-compatibility for process isolation mode would span across LTSC releases, and I'm very interested in hearing whether this is indeed the case.

It also seems arbitrary that you can run 20348 on 21H1 but can't on 20H2. What's so different between them that makes 21H1 capable, but 20H2 uncapable?

Could be that 21H1 includes a later build of the HCS system as part of the feature update, but I'd be surprised if that was the case. It's possible, this branch of Windows (Iron) was in active development before Windows 10 21H1 shipped, even though 21H1's kernel is based on an older windows branch. And we know MS run multi-year roadmaps, so it's not unbelievable that this blog post's content has been planned since late 2020.
That said, I would guess that it is arbitrary, in order to limit the affected scope, since it's only a temporary measure. Coming out-of-the-blue like this (no mention during the Server 2020 preview cycle that I'm aware of), makes it feel arbitrary, though.
That said, a colleague of mine said last week that he'd thought Windows Server 2022 was going to be able to run Server 2019 images in process isolation. He later said he'd misunderstood something, but perhaps I wrongly assumed what he had misunderstood, and he had heard about this improvement somewhere else.
So yeah, lots of speculation. This is probably the wrong place for that...

I mean, now MS would ensure that kernel<->userspace ABI remains stable across patches. Before this promise, they were not expected to care about it.

They had a stable ABI across patches as a supported use-case in LTSC 2019 as well, at least for older-container-image and newer-host. And that's still true here, since the feature they've added is "Your existing container images will work on future host builds", so newer-container on older-host isn't any-more supported than it was.

I confirm that all of this is a very severe regression and a very surprising change (?) in policy on Microsoft's part.
From the start we have docker images for each version of Windows to make things run properly in process isolation mode (as hyper-v mode isn't always suitable).
We thus have:

1809/ltsc2019
1903
1909
2004
20H2

We have now:

ltsc2022

In the future we will therefore also need:

21H1 (we have been waiting for this since May !)
21H2 (if this version ever exists ?)
and of course all new future versions of Windows 10/11

This is very important especially for an operating system which requires mandatory updates (pure abberration...) that we can only pause them for 4/5 weeks...
Finally I will end with the fact that Microsoft knows how to generate Docker images for each version of Windows, so why since May we still do not have version 21H1 of the Docker Windows Server Core image ?

Coming to the conversation late (morning here on Pacific time here).
We will publish a blog post with more details on the down-level support with process isolation soon.
In the meantime, let me clarify a few things:

There won't another SAC release for Server. The last one was 20H2. The latest release is WS2022 which is LTSC.
Windows Client (10 and 11) follows a different approach than Server. Windows 10 and 11 will continue to get updates, always on the same build number. So Windows 10 won't be able to run WS2022 images. We have created images temporarily for WS2022 to run on Win10, but that's with hyper-v isolation.
ltsc2022 images will be supported on the next releases of Windows 11 and Windows Server. That means the next LTSC release of Windows Server (I won't give it a name/number, but it was referenced above as 2025) will run ltsc2022 images with process isolation. We can't guarantee at this point the the release after that will run ltsc2022.
Regardless of the above. If you stay on Windows Server 2022 or move one container host version up, we will support the ltsc2022 image for 5+5 years.
5+5 years means: 5 mainstream years with security + feature update. 5 years of extended support with security updates.

Hope that clarifies the question a bit. But please let us know if you still have questions.

Windows 10 21H2 also is in trouble. LTSC release without any chance to have normal containers perfomance

ltsc2022 image works perfectly in "process mode" with win11-21h2, and if I understood things correctly it will also work in the future with win11-22h1, win11-22h2, win11-23h1, etc...

For some people it is impossible to change OS each time when somebody forget about actual LTSC release.

For some people it is impossible to change OS each time when somebody forget about actual LTSC release.

I totally understand this and I agree 100%...

FWIW, today was the day I figured I'd try Windows Containers in isolation mode and was completely blocked by this issue. I'm running the current stable and supported release of Windows 10 (21H2). Really bummed that I have no option besides spinning up a new VM somewhere or upgrading my daily driver/development system to Windows 11..

upgrading my daily driver/development system to Windows 11

That doesn't work either, see https://github.com/microsoft/Windows-Containers/issues/197

The next Windows Server release is Windows Server 2022, an LTSC. There is no Windows Server version 21H1 or any container image of that version planned.
Curious why folks need to run process isolated containers on Windows 10. Process isolated containers are officially only supported on Windows Server.
You could try Windows 11 with Windows Server 2022 container images with process isolated containers.

For local development. I have been running my local builds for quite a while this way. I could try to update to windows 11, but it's a little strange to me that microsoft implements something like this and then just drops support for it.