[SPARK-10816][SS] Support session window natively

What changes were proposed in this pull request?
This PR proposes to support native session window. Please refer the comments/design doc in SPARK-10816 for more details on the rationalization and design (could be outdated a bit compared to the PR).
The definition of the boundary of "session window" is [the timestamp of start event ~ the timestamp of last event + gap duration). That said, unlike time window, session window is a dynamic window which can expand if new input row is added to the session. To handle expansion of session window, Spark defines session window per input row, and "merge" windows if they can be merged (boundaries are overlapped).
This PR leverages two different approaches on merging session windows:

merging session windows with Spark's aggregation logic (a variant of sort aggregation)
updating session window for all rows bound to the same session, and applying aggregation logic afterwards

First one is preferable as it outperforms compared to the second one, though it can be only used if merging session window can be applied altogether with aggregation. It is not applicable on all the cases, so second one is used to cover the remaining cases.
This PR also applies the optimization on merging input rows and existing sessions with retaining the order (group keys + start timestamp of session window), leveraging the fact the number of existing sessions per group key won't be huge.
The state format is versioned, so that we can bring a new state format if we find a better one.
Why are the changes needed?
For now, to deal with sessionization, Spark requires end users to play with (flat)MapGroupsWithState directly which has a couple of major drawbacks:

(flat)MapGroupsWithState is lower level API and end users have to code everything in details for defining session window and merging windows
built-in aggregate functions cannot be used and end users have to deal with aggregation by themselves
(flat)MapGroupsWithState is only available in Scala/Java.

With native support of session window, end users simply use "session_window" like they use "window" for tumbling/sliding window, and leverage built-in aggregate functions as well as UDAFs to simply define aggregations.
Quoting the query example from test suite:
    val inputData = MemoryStream[(String, Long)]

    // Split the lines into words, treat words as sessionId of events
    val events = inputData.toDF()
      .select($"_1".as("value"), $"_2".as("timestamp"))
      .withColumn("eventTime", $"timestamp".cast("timestamp"))
      .selectExpr("explode(split(value, ' ')) AS sessionId", "eventTime")
      .withWatermark("eventTime", "30 seconds")

    val sessionUpdates = events
      .groupBy(session_window($"eventTime", "10 seconds") as 'session, 'sessionId)
      .agg(count("*").as("numEvents"))
      .selectExpr("sessionId", "CAST(session.start AS LONG)", "CAST(session.end AS LONG)",
        "CAST(session.end AS LONG) - CAST(session.start AS LONG) AS durationMs",
        "numEvents")

which is same as StructuredSessionization (native session window is shorter and clearer even ignoring model classes).
https://github.com/apache/spark/blob/39542bb81f8570219770bb6533c077f44f6cbd2a/examples/src/main/scala/org/apache/spark/examples/sql/streaming/StructuredSessionization.scala#L66-L105
(Worth noting that the code in StructuredSessionization only works with processing time. The code doesn't consider old event can update the start time of old session.)
Does this PR introduce any user-facing change?
Yes. This PR brings the new feature to support session window on both batch and streaming query, which adds a new function "session_window" which usage is similar with "window".
How was this patch tested?
New test suites. Also tested with benchmark code.

Test build #136371 has started for PR 31937 at commit 724557a.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40955/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40955/

This PR leverages two different approaches on merging session windows:

merging session windows with Spark's aggregation logic (a variant of sort aggregation)
updating session window for all rows bound to the same session, and applying aggregation logic afterwards

Is the second one the approach we took in #31570?

Is the second one the approach we took in #31570?

It's not copied from #31570 but the approach is similar. Actually, my old PR was having both approaches to address all cases.

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

Test build #136376 has started for PR 31937 at commit 4689597.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40960/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40960/

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

Test build #136371 has finished for PR 31937 at commit 724557a.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test build #136381 has started for PR 31937 at commit 70bf13e.

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

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40965/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40965/

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

Test build #136376 has finished for PR 31937 at commit 4689597.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test build #136387 has started for PR 31937 at commit 0f18455.

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

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40971/

Test build #136381 has finished for PR 31937 at commit 70bf13e.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40971/

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

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

Test build #136392 has started for PR 31937 at commit 7bcd536.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40976/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40976/

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

Test build #136387 has finished for PR 31937 at commit 0f18455.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

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

Test build #136392 has finished for PR 31937 at commit 7bcd536.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

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

Test build #136413 has started for PR 31937 at commit 0391959.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40997/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40997/

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

retest this, please

Test build #136422 has started for PR 31937 at commit 0391959.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/41006/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/41006/

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

Test build #136422 has finished for PR 31937 at commit 0391959.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

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

cc. @tdas @zsxwing @viirya @xuanyuanking @gaborgsomogyi @Ngone51
Appreciate your efforts on reviewing. Thanks!

Please let me know if the code diff is too huge to review in a single PR. I can leave this PR as reference and break down to several PRs. Probably need to add more code to ensure there're proper test suites per PR, but I can volunteer to add the new test suites. Really appreciated if someone can help adding test suites as well.

I can help to add test suites for the breakdown PRs. Let's leave this one as a panoramic pre-view PR for few days. Make sure others have no more opinions on the whole picture.

Sounds good to me. I will also help on new test suites.

@xuanyuanking @viirya
Sounds great! Thanks for lending your hands.
My current plan on breakdown of PR follows:

UpdatingSessionIterator + UpdatingSessionIteratorSuite
StreamingSessionWindowStateManager and relevant changes (StateStoreType, SymmetricHashJoinStateManager) - no test suite for StreamingSessionWindowStateManager now, volunteer welcome!
MergingSortWithSessionWindowStateIterator - no test suite for now. volunteer welcome, or I can volunteer
MergingSessionIterator - there's no test for AggregateIterator implementations so far, but would be good if we can have one for this
all other parts including physical exec node for above iterators

Appreciate the voices on the plan; I'm also OK to attach physical exec node along with iterator (e.g. UpdatingSessionIterator + UpdatingSessionExec).

Let me go through filing PRs as there doesn't look to be further voice on the overall direction.

I filed 5 JIRA issues for all parts, and submitted 3 PRs which are not dependent to others. Remaining 2 parts depend on others and I'll deal with them once we merge dependents.

(no dependency) MergingSessionIterator - there's no test for AggregateIterator implementations so far, but would be good if we can have one for this. volunteer welcome!.

I'll take a look for this in this week :) .

Will take a look too. Thanks.

UPDATE: I've added test suite for MergingSessionIterator and updated the relevant PR.

UPDATE: I've added test suite for state store manager PR.


Warnings when viewing plugins page on multisite site

If the site is part of a multisite network, then we currently might see this when viewing the Plugins:
Warning: fopen(/REDACTED/wp-content/plugins/fallback-plugin/wp-gatsby/wp-gatsby.php): failed to open stream: No such file or directory in /REDACTED/wp-includes/functions.php on line 6111

This does not seem to affect the functionality otherwise.  Possibly, this is from the get_plugin_data($file) call, but I cannot say why the $file path would be different when looking at the plugins than otherwise browsing the admin interface.

Oh, now I see that it is checking the fallback-plugin/xxx, which means that it did not detect that this was a "dummy placeholder" just to make sure we did not load this twice.  I will look into it when I have the time.

This is fixed in version 1.0.4.


contractions, gomerel

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.4
logical conflict every: 100
sleep for: 300s
[pullrequest]
requests per hour: 30
deps=[c,g]

/trunk merge


Video Stream Player in Facebook Website doesnt Play

I found that live streaming to facebook live works great, but after a few minutes of streaming.
Users CANT see the live feed. except for OPERA (which uses flash player) and plays okay.
This is very easy to reproduce...
How to reproduce
1- get your urls and streamkey from Facebook
2- hardcode it into your app, and start a stream
3- post/publish the stream to your facebook timeline
4- Visualize the video feed in your Browser of choice (Chrome/Safari/Firefox)
5- wait a few minutes... keep streaming
6- Open a new browser window and go to your facebook timeline and try to play the LIVE video, at this point you will notice.. it WONT load, no matter what you do. But the first window where you are still visualizing your stream... is playing fine. If you close that player.. you wont be able to go back and see it again.
This behaviour doesnt happen with other streaming libraies in facebook live. So Im assuming is the LF streaming lib. This is very sad.. because I cant do anything about it, dont know how to debug it 😩

Im still investigating this issue, it seems the problem is related to my implementation.
Because Im using rtmpStream.appendSampleBuffer(buffer, withType: .video); maybe the timestamp in my sample buffer is wrong or something.

Close. Dupliate #217.

Sorry, this is not a framework/library issue. Apparently It is the way I'm implementing the rtmpStream.appendSampleBuffer(buffer, withType: .video) Im doing something inefficiently. which I posted on #222
Thanks again @shogo4405


Add ECOSYSTEM.md and Resources section

Related to #269, #257

Coverage remained the same at 91.369% when pulling 256f87e9542ec841693a0af3e260527790a39530 on nickuraltsev:ecosystem into 7c039e89945c67c8ed036847c1b01556a95bb84c on mzabriskie:master.


Rotation Axis Constraint Ignored By Title Bar

Describe the bug
The Rotation Axis Constraint component is sometimes ignored for the "Grab to manipulate the entire scene" panel title bar. This is particularly annoying as the entire scene pitches up and down to face the camera (verified to happen in build in Hololens 2). Switching to/from Manual Constraint Selection (the act of hitting the button itself) magically makes the constraint work as intended.
To reproduce

Open any example scene with a "Grab to manipulate the entire scene" title bar (HandInteractionExamples for example).

Use far proximity manipulation to move the title bar up and down / forward and back.

Notice the panel and scene is pitching up and down on X axis to satisfy the Face User Constraint, but not the rotation constraint.

Expected behavior
"Grab to manipulate the entire scene" has a Rotation Axis Constraint which should only allow Y axis yaw rotation
"Solution"

In the Constraint Manager in the TitleBar change the constraint selection mode. The act of hitting one of the buttons seems to correct the issue.
Use far proximity manipulation to move the title bar up and down / forward and back.
Notice the panel and scene now respect the constraint and only rotate on the Y axis.

Setup

Unity 2019.4.21f1
MRTK v2.6.0

Target platform

HoloLens
HoloLens 2

Additional context
Something is extra cursed about this issue. After cycling between manual and automatic mode, in some scenes the issue is fixed even after restarting the project. In other scenes it always happens, and I have to set the selection mode to manual.

Thanks for reporting this @Waffle1434. This is due to our constraints executing in a non-deterministic order. We test for the correctness of multiple constraints when they do not interfere with each other, but in this case, the two constraints directly affect each other.
In your case, in one order, the two constraints sometimes executed in the "correct" (i.e., obtaining expected result) order, but sometimes did not. This is because the constraints are backed by an unordered hashset.
I have a fix for this coming soon, which should allow for configurable execution order of constraints.


Adding Laravel course

Adding Laravel course link from CodeSchool, please check and accept Pull-request

Nice, thanks!

Welcome :)

Wow!!  Many thanks for all your contributions.


Deployment failed with Available in MDX Column Property changed to false

Hey, I was wondering if there were plans to make the Available in MDX Column Property  work. The error message I get saving changes directly to the database says something like error in function MDNaivecell::InitPrototype.
This would be very handy for dealing with a user community that always wants to pull detail rows as part of their analysis. I want to hide the very high cardinality primary key of detail rows from excel pivot table field lists because users have severely bogged down the server, going straight for the detail, with no limitations on the amount of data pulled in Excel. The detail rows expressions for drill through are a great alternative and highly customizable.
On the other hand, I don't see a problem with having the very high cardinality column exposed in Power BI, because it does a great job of pulling just the data that can be seen, and pulling more while scrolling. I'd like the Power BI using folks to be able to take advantage of this.
If you can get this property to work, giving us all the ability to customize available objects based on the type of client connecting, it would definitely make for a healthy ecosystem of user satisfaction and server performance. Thank you.

Please consider the following points:

The IsAvailableInMdx property can only be set to false if you’re using Azure Analysis Services or SQL Server 2017 CU8 (or newer). There’s nothing I can do in Tabular Editor to let you set the property if you’re not using a version of Analysis Services that supports it.
The property does not necessarily hide the column from MDX clients, and it might still cause you errors in DAX clients when used as a grouping column. When you set it to false, what really happens is that Analysis Services no longer builds a hierarchy for that column during processing. So it’s mostly useful for speeding up processing and reducing model size for numeric columns used only in aggregations, as well as key columns that have their IsHidden property set to true.

More details here: https://blog.crossjoin.co.uk/2018/07/02/isavailableinmdx-ssas-tabular/

Thank you for the response. Still a useful feature.  I'm using a 1400 compatibility level model for SQL Server Analysis Services 2017 enterprise edition, not using Azure. You're saying it's only available for Azure Analysis Services?

According to this page, you should also be able to set the property in SQL Server 2017 starting from Cumulative Update 8.

That settles it. Thank you.


Need a reasonable way to either cancel ReadConsole or poll for text input

In my library I expose a terminal input API that looks like this:
public static class Terminal
{
    public static ValueTask<string?> ReadLineAsync(CancellationToken cancellationToken = default)
    {
        // ..
    }
}

On Unix, implementing cancellation support was quite easy:

Create an anonymous pipe at startup.
When the CancellationToken is triggered, write a dummy value to the write end of the pipe.
In ReadLineAsync, poll for input on the read end of the pipe and stdin.
If the poll returns indicating input on the pipe, drain the pipe and throw OperationCanceledException.
If the poll returns indicating input on stdin, actually read the data and return it.

(For reference, the implementation of the above can be found here and here.)
I would now like to implement something similar for Windows. Unfortunately, as far as I can tell, this is bordering on impossible at the moment.
I naïvely tried to replicate the approach above on Windows, only to discover that WaitForMultipleObjects does not support polling on pipes. I replaced the pipe with an event since WaitForMultipleObjects supports those. I then ran into another problem: Polling on a console input handle will return when any INPUT_RECORD arrives, not just KEY_EVENT_RECORDs. I decided to try CancelIo and CancelSynchronousIo on the off chance that they'd work instead of polling, but they just don't work on console input, apparently. At that point, things got hairy; I went back to the polling approach and tried to inspect the input buffer looking for KEY_EVENT_RECORDs specifically, discarding other event records, and then resuming the wait if there are no KEY_EVENT_RECORDs. Besides being very gross and hacky, this fell apart quickly as it turns out there's no clean way to figure out if a given KEY_EVENT_RECORD (or a series of them) will actually result in text input being available on the next ReadConsole call. Worse yet, even when I did hack together some heuristics, the behavior turned out to be different between CMD and Windows Terminal. At that point, I gave up and ripped out Windows cancellation support.
So I suppose this issue boils down to me asking: Is there a way to achieve what I'm trying to do that I just haven't realized yet? If not, could one be implemented?

try CancelIo and CancelSynchronousIo on the off chance that they'd work instead of polling,
but they just don't work on console input

In Windows 8+, CancelSynchronousIo() works for a console ReadFile() or ReadConsoleW(), but only in a half-baked way. It respectively cancels the NtReadFile() or NtDeviceIoControlFile() request on the client side. However, the console host doesn't cancel its operation. It continues a cooked read, and the contents of the read are discarded after the user enters a line.
It would be a good thing to properly support cancelling I/O requests in the console host, if the design permits it. This may require changes to the console device driver, condrv.sys, if it's currently not canceling the associated IOCTL request in the console. I haven't checked that.
Note that ReadConsoleW() succeeds with the last error set to ERROR_OPERATION_ABORTED when the underlying NtDeviceIoControlFile() call returns either STATUS_ALERTED (due to Ctrl+C or Ctrl+Break) or STATUS_CANCELLED (due to a cancel). The latter can be distinguished by initially setting lpNumberOfCharsRead = (DWORD)-1. It will be set to 0 if the read is interrupted by Ctrl+C or Ctrl+Break.
Since Windows 8, ReadFile() for a console file is no longer special cased. It uses a normal NtReadFile() system call. ReadFile() generically handles the console's STATUS_ALERTED result for Ctrl+C or Ctrl+Break as a success code, without setting the last error. Thus with ReadFile(), a console read that's canceled by Ctrl+C or Ctrl+Break is indistinguishable from an empty read (i.e. a line that starts with Ctrl+Z). OTOH, ReadFile() generically handles STATUS_CANCELLED as a failure code, which sets the last error to ERROR_OPERATION_ABORTED.

WaitForMultipleObjects does not support polling on pipes.

The system wait routines support waiting on file objects. It's generally only meaningful in user mode when waiting for I/O completion with an asynchronous-mode file. If I/O requests never overlap, it's safe to wait for I/O completion by waiting on the file object itself. (It's recommended to use events, APCs, or a completion port instead of waiting on the file object, since generally there will be multiple pending I/O requests.) Either end of a named pipe can be opened in asynchronous mode by passing the flag FILE_FLAG_OVERLAPPED to the CreateNamedPipeW() or CreateFileW() call.
Console input files are an exception to this rule. As background, note that the File type can reuse the FsContext2 field of a file object to store the address of a custom event to wait on if a file object needs non-standard wait semantics. This is how waiting on a console input file implements the POSIX pattern of waiting for a synchronous file to be ready for I/O. Otherwise, the address of the default event to use when waiting on a file object is stored in its Event field, which gets signaled for I/O completion.

Polling on a console input handle will return when any INPUT_RECORD arrives

The most noise is from mouse events, which can be disabled. But you'll still have menu, focus, and window size events in the input buffer that have to be ignored.
A high-level PeekConsoleW() function that's non-blocking might make this simpler:
BOOL PeekConsoleW(
  [in]            HANDLE  hConsoleInput,
  [out, optional] LPVOID  lpBuffer,
  [in]            DWORD   nNumberOfCharsToRead,
  [out, optional] LPDWORD lpNumberOfCharsRead,
  [out, optional] LPDWORD lpNumberOfCharsAvail,
  [out, optional] LPDWORD lpNumberOfCharsLeftThisLine
);

This mirrors PeekNamedPipe(), but based on characters and lines instead of bytes and messages. For example, PeekConsoleW(h, NULL, 0, NULL, &m, &n) would set m to the total number of characters in the input buffer and n to the number of characters up to and including a "\r" or "\r\n" line ending, if any. The value of n would be zero if the input buffer doesn't contain a line ending.

Off-topic comment:
The library's SendSignal() method is flawed. GenerateConsoleCtrlEvent() takes a process group ID, or group 0 for all processes in the console session (including the calling process). The only documented way to know the group ID of a process is to spawn it with the process creation flag CREATE_NEW_PROCESS_GROUP. GenerateConsoleCtrlEvent() supports CTRL_C_EVENT (cancel) and CTRL_BREAK_EVENT. It does not support CTRL_CLOSE_EVENT.
The cancel event is initially ignored by the root process of a new group. This state gets inherited by child processes. The cancel event can be enabled manually via SetConsoleCtrlHandler(NULL, FALSE). The break event, on the other hand, is never ignored.
For console apps, the nearest equivalent to a POSIX process group is to spawn the root process of a new group with CREATE_NEW_PROCESS_GROUP, and add the process to a job object. When it's time to terminate the group, akin to killpg(pgrp, SIGTERM) in POSIX, call GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT, rootProcessId). The default handler calls ExitProcess(), so at least loaded DLLs will be notified to shut down gracefully. Any processes that remain after waiting can be terminated forcefully via TerminateJobObject(), which is equivalent to following up with killpg(pgrp, SIGKILL) in POSIX.

The most noise is from mouse events, which can be disabled. But you'll still have menu, focus, and window size events in the input buffer that have to be ignored.

Even if entirely discarding these, the primary challenge seemed to be interpreting KEY_EVENT_RECORDs correctly. I never managed to figure out a reliable way to know whether a given KEY_EVENT_RECORD would mean that text is available to be read.
See alexrp/system-terminal#61 for some background.

The library's SendSignal() method is flawed.

Originally, it was just used to synthesize signals for the current process. That should be roughly equivalent on Windows and Unix.
I later used it for sending signals to child processes which is indeed where it becomes problematic. I've been meaning to remove that method for this exact reason.

It does not support CTRL_CLOSE_EVENT or CTRL_SHUTDOWN_EVENT.

This particular issue was addressed in alexrp/system-terminal@db81ecfb10ad38ff7c8e067642f26dec9225ba87.

As far as PeekConsoleW, note we have PeekConsoleInputW, but I think the problem Alex is pointing out is there's no way to peek (nonblocking), process events, then consume the events that are processed from the queue.  The only way is to call ReadConsoleInput and hope that nothing else has removed those events in the meantime, because if they did, the read will block.  The events need to be consumed somehow otherwise the handle remains signalled so there's no way to wait for more.
I think any PeekConsoleW equivalent to ReadConsoleW has the same issue: it would need to specify a timestamp/identifier that can later be used to say "please consume these specific things/please consume up to this point in time."

@malxau
Well, to be clear, ideally I don't even want to have to deal with INPUT_RECORDs. That was just one avenue I explored in my quest to achieve either (text) polling or cancellation.
Note that when I say "polling" here, I mean poll(2), which blocks until input is available. What I do on Unix is poll on stdin and the read end of a pipe. When I want to cancel, I write something to the write end of the pipe. When poll returns, I can then tell whether it's because the user typed something (stdin) or because cancellation was requested (pipe). This isn't 'true' cancellation but it's close enough.
The problem with this approach is that, on Windows, WaitForMultipleObjects (the poll(2) sort-of-equivalent) on a console input handle does not poll for text, but rather for input records (of any kind - mouse, focus, etc included). Even if there was a way for me to process those 'atomically', it would be very difficult for me to match the behavior of the console host in regards to how INPUT_RECORDs are translated to text for ReadConsole purposes. It also seems like a total breakdown in the console abstraction on at least two levels.
It's probably not acceptable to change WaitForMultipleObjects on a console input handle to poll for text only, due to compatibility concerns. Given @eryksun's comments, I would imagine the only sane way forward would be to support CancelSynchronousIo on console input handles. (IIRC, last time I tested, I got ERROR_NO_MATCH when calling CancelSynchronousIo on a thread blocked in ReadConsole, but I would need to double-check to be sure.)

@eryksun

In POSIX, pid 0 includes all processes in the caller's process group. In Windows, group 0 includes all processes in the console session. Sending a signal to just the current process is possible in POSIX, but nothing like that is possible for Ctrl+C or Ctrl+Break in Windows.

Right, that's why GenerateSignal is implemented as kill(0, sig) rather than kill(getpid(), sig). It seemed the only way to get reasonably consistent behavior between Windows and Unix.

Unfortunately, passing this flag requires calling CreateProcessW() directly. It's not supported by .NET.

This is why I'll likely end up removing that ChildProcess.SendSignal method. At least for as long as ChildProcess is implemented in terms of System.Diagnostics.Process (as opposed to calling Win32 APIs directly) there isn't a way for me to set CREATE_NEW_PROCESS_GROUP. ☹ I might remedy that one day once I've moved terminal platform code to a native library...

That update mistakenly removed CTRL_BREAK_EVENT and kept CTRL_CLOSE_EVENT.

Good catch! Will fix that.

I'd map CTRL_BREAK_EVENT to TerminalSignal.Terminate. It's never ignored and the closest to SIGTERM. The equivalent of SIGKILL is TerminateJobObject() or TerminateProcess().

In principle I agree completely and this is what I wanted to do originally.
Unfortunately, an (IMO) poor decision was made during the design of the .NET 6 System.Runtime.InteropServices.PosixSignalRegistration API to map SIGTERM to CTRL_SHUTDOWN_EVENT, so I decided to be consistent with that to avoid confusion.

API to map SIGTERM to CTRL_SHUTDOWN_EVENT, so I decided to be consistent with that to avoid confusion.

Their choices aren't completely wrong. Mapping CTRL_BREAK_EVENT to SIGQUIT isn't without merit, since it's associated with Ctrl+\ in the terminal, a common way to immediately kill a process and return to the shell. Though in Linux it defaults to an abnormal termination that dumps a core file, which is more extreme than Ctrl+Break. I think mapping it to SIGTERM is more useful considering the break event is the only one that we can rely on to always work more or less like sending SIGTERM to a process group. AFAIK, it's not normal to send SIGQUIT to a child process or group via kill() or killpg().
Mapping CTRL_CLOSE_EVENT to SIGHUP makes sense, except CTRL_CLOSE_EVENT can't be ignored or handled in a way that lets the current process continue. By default a process has 5 seconds (HungAppTimeout) to exit on its own before the system terminates it.
CTRL_SHUTDOWN_EVENT is mapped to SIGTERM probably because most POSIX systems shut down by first sending SIGTERM to running processes, followed by SIGKILL after a timeout. For some reason they're not also handling CTRL_LOGOFF_EVENT. The shutdown and logoff 'console' events are sent directly by the system (not by the console host) to any process that isn't connected to a window station and desktop -- i.e. a process that doesn't load user32.dll, which can be hard to prevent since many DLLs depend on it.

@DHowett Hmm, at first glance, I don't think this will solve the problem. It seems to me that this isn't meaningfully any different from using WaitForMultipleObjectsEx on a console input handle and a cancellation event handle. If anything, achieving cancelability with ReadConsoleInputEx seems like it would be more trouble than that approach.
It would also still require me to interpret the key events returned and pray that I can figure out how to determine if the key events in the buffer correspond to what ReadConsole considers to be valid text input - which is untenable.

Just checking in here again. Is there any hope of making progress in this area? This issue (AFAIK) remains a hard blocker for reasonable input cancellation support in Windows terminal apps.

It's January again (🎆) and I once again find myself thinking about this issue. (Still kinda shocked that I seem to be the only(?) person running into this limitation. :eyes:)
Changing console APIs is apparently a tough sell, judging by the megathread this is included in, so I spent some more time scouring the internet for ideas. I came across this relatively recent answer on SO: https://stackoverflow.com/a/70557694
My gut reaction was "that's kinda whack", but then, thinking about it... my library does input reading under a lock, so the likelihood of a caller discovering that the handle was briefly closed and reopened is very minimal. It can basically only happen if another thread checks the handle's IsValid property at just the right time while the primary thread is reading from it and gets a cancellation request. I figure that's an acceptable quirk to have working input cancellation on Windows until this issue is addressed. 🤔
Any other downsides I ought to consider for this approach?

I can't immediately figure out how NtCreateFile on a CON works, but I'm afraid this may leak handles. I don't see an issue with the approach per se, but I would definitely test if it leaks system resources before shipping such code to others (e.g. by running such code in a tight loop for a test).
Supporting proper cancellation within conhost would definitely be nice and not that difficult to implement. But I'm not sure how to make the necessary changes to condrv and I'm not sure there are any others either who'd readily be able to make such a change. For me personally this definitely falls under the category of "what I'd do if I could clone myself". Alas. 🥲

I can't immediately figure out how NtCreateFile on a CON works, but I'm afraid this may leak handles. I don't see an issue with the approach per se, but I would definitely test if it leaks system resources before shipping such code to others (e.g. by running such code in a tight loop for a test).

Well, I figure that input cancellation is a rare enough event that this probably doesn't matter in practice. At least the handles go away when the process exits. At any rate, it still seems better than the status quo, which is that my library supports input cancellation on Unix but on Windows it just does nothing, despite the API appearing fully cancellation-aware.
Anyhow, I went and tested this approach yesterday. Unfortunately, my first attempt was unsuccessful. I do have some more ideas - namely, dropping down to NtClose() instead of CloseHandle(), and perhaps combining CloseHandle()/NtClose() + CreateFile("CONIN$", ...) with CancelSynchronousIo() somehow... will see how it goes. 😰

@alexrp Could you use the method described here?
https://www.meziantou.net/cancelling-console-read.htm
I just tested it quickly now on Windows 11 on .NET 8, and it seems to work fine in Windows Terminal at least on this setup.

I recall having tried all the Win32 I/O cancellation functions in the past and all of them having undesirable results. I think that was on Windows 10, though. I'll give it another shot on Windows 11 and report back.

@alexrp OOC, as things stand right now, what actually happens in cathode on Windows when cancellation is requested on the token provided to the Terminal.ReadLineAsync() API you mentioned above?

@DaRosenberg nothing currently. On Windows, there's only an upfront cancellation check before the read, because none of the options I tried back then worked.

@DaRosenberg I reimplemented the CancelIoEx() approach and now I see what the problem was: Indeed, it cancels the read, but it also leaves the handle in a permanently-canceled state. So it's suitable for terminating an application, but if what you're hoping to do is to cancel a read and then do another one later, you're out of luck.
That said, maybe combining this with the handle-reopening part of https://github.com/microsoft/terminal/issues/12143#issuecomment-1873533831 might be the answer? Hmmmmmmm...

Completely ignore the previous comment. I had a bug where I was reusing a CancellationTokenSource. 🤦
It.... actually seems to work, even with repeated cancellations.
I'm now super curious if something changed in Windows somewhere along the lines, or if my testing 2 years ago was just flawed. 🤔
Either way, thanks a ton for pointing me in the right direction, @DaRosenberg!
I believe we can close this, then. I don't immediately see anything about the CancelIoEx() behavior that stands out to me as being "unreasonable".

@DaRosenberg

When would you estimate that this fix (assuming it holds up) might make it into a Cathode release?

I posted on https://github.com/vezel-dev/cathode/issues/63#issuecomment-1895171899 looking for people to test it a bit. If no issues present themselves within a few days, I'll probably just go ahead and push a release.

Is there any documentation just showing the basic API surface and usage of Cathode? I found the samples in the repo but it's not clear to me which one is best suited just to show where to start.

Unfortunately, not yet. https://github.com/vezel-dev/cathode/issues/83 tracks actually writing some proper conceptual docs; I just need to get around to actually doing it. But, for the most part, the API is very obvious if you just IntelliSense your way through. Most of it mirrors System.Console (sans Windows-isms). I'm happy to answer any questions you have over on the discussions page though - that's also helpful to know what people are looking for in terms of docs.

Couple of caveats before you commit to using Cathode:

Don't expect full-blown ncurses-like functionality just yet. Right now, it can read line input in cooked mode as you'd expect from any console I/O API, but when you drop down to raw mode, you have to parse the input control sequences yourself. This isn't terribly difficult, just a minor annoyance. I do consider the inclusion of an in-box parser for these to be a blocker for 1.0 - see https://github.com/vezel-dev/cathode/issues/59.
Since the latest release, I switched the project over to using a native helper library for all the P/Invoke and signal handling stuff. This has mostly brought benefits -- fairly reliably cleaning up console state on non-crashy process exit, significantly reducing managed metadata bloat, easier porting to new platforms, etc -- but it does also mean that projects that use Cathode now also pull in a [lib]Vezel.Cathode.Native.{dll,dylib,so}.

If these caveats aren't blockers for you, then Cathode will probably be a good fit.

@alexrp I'm not quite sure what you mean by cooked vs. raw line input, but today we are basically doing this when reading line input (in order to support some form of user cancellation):
while (true)
{
    var key = Console.ReadKey(intercept: true);

    if (key.Key == ConsoleKey.Enter)
    {
        if (!isRequired || chars.Count > 0)
        {
            var responseText = new string(chars.Reverse().ToArray());

            if (typeof(T) == typeof(string))
            {
                return (T)Convert.ChangeType(responseText, typeof(T), CultureInfo.InvariantCulture);
            }

            if (TryParse(responseText, out T response))
            {
                return response;
            }
        }
    }
    else if (key.Key == ConsoleKey.Escape && !isRequired)
    {
        return default;
    }
    else if (key.Modifiers.HasFlag(ConsoleModifiers.Control) && key.Key == ConsoleKey.C)
    {
        throw new OperationCanceledException();
    }
    else if (key.Key == ConsoleKey.Backspace && chars.Count > 0)
    {
        chars.Pop();
        PrintToError("\b \b"); // VT100 sequence for an erasing backspace...
    }
    else if (!Char.IsControl(key.KeyChar))
    {
        chars.Push(key.KeyChar);
        var charToPrint = isSecret ? '*' : key.KeyChar;
        PrintToError(charToPrint.ToString(CultureInfo.CurrentCulture), color: SemanticColor.UserAction);
    }
}

If we can simply migrate this approach to Cathode, I would be happy with that.
The additional native DLL I also cannot see any problem with.
However, I just noticed this:
https://github.com/vezel-dev/cathode/issues/142
Can you elaborate a bit on what the issue is there? Does it completely prevent us from using Cathode on any MUSL-based OS, or is the issue limited to some specific functionality? It might be an issue as we do support Alpine and we also provide MUSL-based Docker images. ..

@DaRosenberg

I'm not quite sure what you mean by cooked vs. raw line input, but today we are basically doing this when reading line input (in order to support masking of secrets and some form of user cancellation):

You would basically have to do similar stuff with Cathode, but the downside (due to the missing parser) is that you don't have the convenience of ReadKey() translating the control sequences into ConsoleKey/ConsoleModifiers for you. Still, tools like showkey -a are helpful here to quickly figure out what you should be parsing.
In terminal lingo, 'cooked mode' basically refers to the mode that programs operate in by default, i.e. Write("foo\n") will imply \r to bring the caret to the first column, ReadLine() will provide a super basic, unsophisticated line edit mode that just barely functions, etc.
On the other hand, 'raw mode' is where you're in charge of everything: Write("foo\n") will only move the cursor down a line, so you need to also write \r if you want to move it to the first column. For input, you get the raw control sequences when the user presses keys. This mostly only matters for special key combinations. For example, Ctrl-O vs o in showkey -a:
^O 	 15 0017 0x0f
o 	111 0157 0x6f

There's more nuance to it than that, but that's the gist. You trade complexity for much greater control and flexibility (some things can't really be done sensibly unless you're in raw mode). Most non-trivial terminal apps (shells, editors, etc) use some flavor of raw mode.

Can you elaborate a bit on what the issue is there?

When targeting musl-based distros (such as Alpine), Zig isn't properly linking to musl's libc.so dynamically, instead linking it in statically. This basically means libVezel.Cathode.Native.so for musl gets a full copy of the entire musl libc in it. It's tracked upstream here: https://github.com/ziglang/zig/issues/11909

Does it completely prevent us from using Cathode on any MUSL-based OS, or is the issue limited to some specific functionality?

I don't actually know for sure, but I would expect so. I don't have an Alpine system on hand to test with. Generally speaking, in Unix land, it's not expected to have multiple copies of libc in the same process. This is in contrast with Windows where it's fairly commonplace to link MSVCRT statically into DLLs.

I believe we can close this, then.

I spoke too soon, unfortunately. 😢 Cooked input does not cancel properly with CancelIoEx(). The user has to explicitly press Enter to complete the line before the app is unblocked. So we do still need something to be improved here.
(Still, as far as Cathode is concerned, shipping support for raw input cancellation is better than nothing.)

And I spoke too soon again. It only sort of works in raw mode, as we discovered in https://github.com/vezel-dev/cathode/issues/165. The next input byte will just be dropped on the floor after a CancelIoEx(), resulting in incorrect input afterwards. So the CancelIoEx() approach is only good for the use case of canceling input reading and then exiting the program.
I am officially giving up trying to work around this issue; it's a bug farm.


Generic code for connecting to currently running window and checking if an UI element exists

I am new to Pywinauto. I want to write a generic code, where my code will be able to connect to the App that has launched and find if a UI element is displayed or not.
For Example:
I will launch an app like Microsoft Teams/Slack
Pywinauto will connect to the app which has just launched
And it will tell me a specific UI Handle like Profile picture or something is visible or not
I was able to do it with Selenium, but that's too slow in detecting UI Handles. Is it possible with Pywinauto?

Any way to do it? Please help.


SFT training doesn't fully go through all samples

Current training uses ConstantLengthDataset. This dataset return fixed length of tokens (2048) in every step, however, the total number of steps are calculated based on the number of samples. I checked some samples and found that quite a few of them are much longer than 2048 (~7000), this means that some of the samples have never been seen in one epoch of training.
Could you please verify if my understanding is correct?
Thanks, appreciate.

Hello @hanxiaotian yes there is a small bug in TRL's SFTTrainer with how the training steps are counted and is being fixed here: https://github.com/huggingface/trl/pull/979

Another quick question, after concatenate tokens from different samples seperated by "eos" token, the loss are calculated over the whole sequence without any mask, does my understanding correct? Thanks!

So the fix is merged, but there is no release yet, and when there will be, the requirements should be update to new version of TRL


[BUG]  OTP AutoFill hint

When i tried to implement hint (for number) isn't work. I see popup and then he quickly closed.

  @override
  void initState() {
    // TODO: implement initState
    saveCurrentRoute('$PhoneConnection');
    setRouteArray('$PhoneConnection', true);
    Future.delayed(Duration(milliseconds: 2000))
        .then((value) async => await getNumber());
    super.initState();
  }

Future<dynamic> getNumber() async {
    var _otpInteractor = OTPInteractor();
    String number = await _otpInteractor.hint;
    debugPrint('$number');
  }

Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 2.2.3, on Microsoft Windows [Version 10.0.22000.258], locale ru-RU)
[√] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
[√] Chrome - develop for the web
[√] Visual Studio - develop for Windows (Visual Studio Community 2022 17.0.0 RC2)
[!] Android Studio (not installed)
[√] VS Code (version 1.61.2)
[√] Connected device (4 available)

! Doctor found issues in 1 category.

Hello @rGradov,
We tried to reproduce described error on the similar telephone - Huawei p20 like, but we failed.
Thank you for provided additional information.

Hello @rGradov,
In order to resolve this issue, we'd like to get more details on it, such as device model or full case issue-code.
Unfortunately, provided code above didn't failure within our checks, so we aren't able to identify the problem.
Also we'd like to mention that phone number hint feature relies on sim-card based contacts. Thus, we can assume that in your case the issue could have arisen because of this.
We'd like to help you further if issue persists.


accesskey for next, previous links

cf https://github.com/rtfd/readthedocs.org/issues/1136
It would be nice to have an accesskey="n" and accesskey="p" attribute on the next and previous links in the page footer and pagination widgets. This should improve accessibility without breaking any current behavior.

Happy to merge this if you send a PR

Thanks, but I think you already did: https://github.com/snide/sphinx_rtd_theme/pull/187
Closing: please reopen if there are any loose ends.


Bring read-only message to explorer decoration

Follow up from https://github.com/microsoft/vscode/issues/166971:
https://github.com/microsoft/vscode/pull/185216#discussion_r1231796181

//cc @lramos15

Having played with this, I am no longer so convinced to actually do it because decorations already have lots of text and this makes it only longer. The user will get the feedback in the editor with a nice action to resolve it, so I think we can close this as out of scope.


Preserve existing credentials of internal docker registry

Description
Changes proposed in this pull request:

...
...
...

Related issue(s)

/test all

/test pull-serverless-module-build


[Proposal] Add /run_checks permission

New Pull Request Checklist

[x] I have read and understood the CONTRIBUTING guide

[x] I have read the Documentation

[x] I have searched for a similar pull request in the project and found none

[x] I have updated this branch with the latest master to avoid conflicts (via merge from master or rebase)

[ ] I have added the required tests to prove the fix/feature I am adding

[x] I have updated the documentation (if necessary)

[x] I have run the tests and they pass

[x] I have run the lint and it passes (pod lib lint)

Pull Request Description
I'd like to limit the users who can execute /run_checks to collaborator and admin (I think it was the expected behavior?). I also simplified the action for checking out the pull requests from the fork. In fact, I have already implemented this method in some projects and they works fine.
Do you prefer this proposal? TBH, I'm not sure we really need this feature(limit the users who can execute /run_checks), but we can do it😅 and it gets better, I think.
As a reminder,  this change will work fine after the merge(not at pull request) due to GitHub Action issue_event specification.
Thanks.

/run_checks

@ffried
Thanks!  I'm glad to hear your idea! I reverted the lines about checking out the PR from the fork.
Now I've just added execution(run_check) limitation. If it's OK, could you merge this?

/run_checks (just in case🙂)

@sushichop After a quick glance at your GitHub action, I saw that you can post a comment if the user does not have the required permissions. Will this happen by default? If not, would you mind adding this to the action? I think that'll help to understand why the checks do not run in certain cases.

@ffried
Oh, I'm very glad you have checked my actions! It doesn't comment on anything by default.
So I added action definition when a user is not permitted.

/run_checks


[Bug] How to use ChimeraGPT

I used docker to build, which is the content of my configuration file.

After I ran it, I sent a message, and he asked me to enter key.

Then I set key and api in the settings

At this time, I encountered a new problem.

删除链接里的 /v1

删除链接里的 /v1

删掉环境变量里的v1就行了吗？其他的还有需要改动的吗？


Python内存管理机制 - Rain的博客 | Rain Blog

https://wheredoyouwanttogo.github.io/blog/2020/02/12/Python内存管理/
Every failure is leading towards success.

王婆婆卖瓜，自己评论

测试


Try removing boto config fix

Trello: https://trello.com/c/BK3NMYfV/583-review-whether-travis-workaround-is-still-required-after-migration-to-com
Let's see if we still get the GCE error.

Closing for now.


Add new iOS blurs featured in iOS 13+

Summary
Pull Request should solve #332 issue.
Adding new types of blurs which were featured in iOS version 13:
    'chromeMaterial',
    'material',
    'thickMaterial',
    'thinMaterial',
    'ultraThinMaterial',
    'chromeMaterialDark',
    'materialDark',
    'thickMaterialDark',
    'thinMaterialDark',
    'ultraThinMaterialDark',
    'chromeMaterialLight',
    'materialLight',
    'thickMaterialLight',
    'thinMaterialLight',
    'ultraThinMaterialLight',

More info at Apple UIKit documentation for UIBLurEffectStyle
Work is in progress.
Test Plan

What's required for testing (prerequisites)?
Just test all of the styles .
Compatibility

OS
Implemented

iOS
✅

Android
✅

Checklist

[ ] I have tested this on a device and a simulator
[x] I added the documentation in README.md
[x] I updated the typed files (TS and Flow)

I'll test it in soon as possible 🚀

Seems to work 👌


nextjs-docs: add support for opening docs in browser

Closes #3320
Description
Adds an action to the extension (list item and details view) to open the docs in a browser
Screencast
https://user-images.githubusercontent.com/63192115/198824471-f0fb6215-11fb-4d5d-9b0a-730201c3a4fb.mov
Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[ ] I checked that files in the assets folder are used by the extension itself
[ ] I checked that assets used by the README are placed outside of the metadata folder

Awesome @AnishDe12020 ! Looks perfect to me. Thanks a lot for your contribution.


[Speculative] Use FreeT for HalogenM

Closing this for now, will continue experimenting with this as it does seem like a more correct way to do things, but it'll be for a future version now.


Update sidebar GitHub links metadata

Thank you for helping make the Dapr documentation better!
Please follow this checklist before submitting:

[x] Commits are signed with Developer Certificate of Origin (DCO - learn more)
[x] Read the contribution guide
[x] Commands include options for Linux, MacOS, and Windows within codetabs
[x] New file and folder names are globally unique
[x] Page references use shortcodes instead of markdown or URL links
[x] Images use HTML style and have alternative text
[x] Places where multiple code/command options are given have codetabs

In addition, please fill out the following to help reviewers understand this pull request:
Description
This PR updates the template that generates the "edit page" and "open issue" buttons on the right side of the page for every docs page.
Lays the groundwork to edit the SDK repos
Issue reference
Partially addresses https://github.com/dapr/docs/issues/1895

@hhunter-ms do we also merge this in 1.12 now?


Update fetch.rs

Remove redundant information about toolchain fetch being an alias of toolchain fetch.

I just noticed this today. Glad to see a PR already.


CxxVector of CxxString cannot add more than 3 entries

Describe the bug
When I tried to add 4 CxxString into a CxxVector, it fails to.
To Reproduce
Steps to reproduce the behavior:
   const vec = (CxxVector.make(CxxString)).construct();     vec.push("1");     vec.push("2");     vec.push("3");     vec.push("4");     vec.push("5");     console.log(vec.toArray());
Expected behavior
It should log [ '1', '2', '3', '4', '5' ]
Error logs
It only logs [ '1', '2', '3' ]
Desktop (please complete the following information):

OS: Windows 10
Version 20H2

Additional context
This makes ServerPlayer.prototype.setFakeScoreboard crash when adding more than 3 lines of text and will probably break .sendTranslatedMessaage as well

Thanks for reporting it.
I fixed it on the latest commit.


Revert "[improve][misc] Update caffeine from 2.9.1 to 3.1.2 (#18647)"

Fixes: #18732
Motivation
Revert #18467 to fix the JVM crash issue, which has been described in #18732
After the CI gets passed. I will create a GitHub issue for the caffeine repo

Codecov Report

Merging #18751 (2c3aa07) into master (99e26f5) will decrease coverage by 7.75%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master   #18751      +/-   ##
============================================
- Coverage     44.79%   37.03%   -7.76%
+ Complexity    10026     1967    -8059
============================================
  Files           703      209     -494
  Lines         68808    14425   -54383
  Branches       7375     1574    -5801
============================================
- Hits          30822     5343   -25479
+ Misses        34378     8496   -25882
+ Partials       3608      586    -3022

Flag
Coverage Δ

unittests
37.03% <ø> (-7.76%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...rg/apache/pulsar/client/impl/PulsarClientImpl.java
43.85% <0.00%> (-0.95%)
:arrow_down:

...he/pulsar/client/impl/MultiTopicsConsumerImpl.java
22.86% <0.00%> (-0.12%)
:arrow_down:

...ar/broker/loadbalance/impl/UniformLoadShedder.java

...r/broker/delayed/DelayedDeliveryTrackerLoader.java

...g/apache/pulsar/broker/stats/MetricsGenerator.java

...r/broker/service/schema/AlwaysSchemaValidator.java

...rcegroup/ResourceGroupNamespaceConfigListener.java

...che/bookkeeper/mledger/ManagedLedgerException.java

.../apache/pulsar/broker/namespace/LookupOptions.java

...sar/proxy/extensions/ProxyExtensionDefinition.java

... and 486 more


Add more checks for SWT_NO_FILE_IO.

My recent change to add FileHandle didn't correctly handle the no-file-I/O case that we'd like to support. (My bad!) This PR corrects that, and I tested it this time I promise.
Checklist:

[x] Code and documentation should follow the style of the Style Guide.
[x] If public symbols are renamed or modified, DocC references should be updated.

@swift-ci please test

Self-reviewing after internal discussion.