Add OS validation before deployment

Type: Feature
Enter Task Name: AzureFunctionApp
Environment
Hosted AzureDevOps Agent.
Issue Description
It would be good if the AzureFunctionApp task verified the host OS before deploying and provide a user-friendly error message if something is mismatched. For example, if you have a Windows app service setup, but you deploy using the "functionAppLinux" appType, then you get a confusing error message (see below). It looks like some of the code knows how to go get certain properties about the function app in Azure, so it should be able to verify if the app service host OS is Windows or Linux. A quick validation and proper error message would be helpful.
The background is that I ran into this error when migrating function apps and consolidating app service plans. I didn't realize that updated ARM template to configure the app service plan was not set for Linux. The app service plan deployed fine, but it was Windows, so when I ran the deployment pipeline, I got an error that led me on a debugging hunt.
A simple error message like the following would be helpful: "The app to deploy specified {os} appType, but the host machine is running {hostOS}. Please verify your app service settings."
Task logs
Error logs
Using the following command to generate deployment script: 'azure site deploymentscript -y --no-dot-deployment -r "C:\local\Temp\zipdeploy\extracted" -o "C:\home\site\deployments\tools" --basic --sitePath "C:\local\Temp\zipdeploy\extracted"'.
Generating deployment script for Web Site
Running deployment command...
Command: "C:\home\site\deployments\tools\deploy.cmd"
Handling Basic Web Site deployment.
Creating app_offline.htm
Error: Could not find file 'C:\home\site\wwwroot\host.json'.
KuduSync.NET from: 'C:\local\Temp\zipdeploy\extracted' to: 'C:\home\site\wwwroot'
Copying file: 'host.json'
Failed exitCode=1, command="kudusync" -v 50  -f "C:\local\Temp\zipdeploy\extracted" -t "C:\home\site\wwwroot" -n "C:\home\site\deployments\dd41704c933f4a71811c1e22b399b02f\manifest" -p "C:\Program Files (x86)\SiteExtensions\Kudu\91.21119.4922\bin\Scripts\firstDeploymentManifest" -i ".git;.hg;.deployment;deploy.cmd"
An error has occurred during web site deployment.
Error: Could not find file 'C:\home\site\wwwroot\host.json'.\r\nC:\Program Files (x86)\SiteExtensions\Kudu\91.21119.4922\bin\Scripts\starter.cmd "C:\home\site\deployments\tools\deploy.cmd"
##[error]Failed to deploy web package to App Service.
##[error]To debug further please check Kudu stack trace URL : [url]
##[error]Error: Package deployment using ZIP Deploy failed. Refer logs for more details.
Troubleshooting
Checkout how to troubleshoot failures and collect debug logs: https://docs.microsoft.com/en-us/vsts/build-release/actions/troubleshooting

We can't add any logic or validation in the task, we just pass on any returned errors that we get as is from the kudu rest api's. We return the stack trace url for you to further debug.
The task assistant while setting up yaml/release pipeline does show filtered out values to help in choosing the right values based on the subscription and app service type.

We can't add any logic or validation in the task, we just pass on any returned errors that we get as is from the kudu rest api's. We return the stack trace url for you to further debug.
The task assistant while setting up yaml/release pipeline does show filtered out values to help in choosing the right values based on the subscription and app service type.


Fix build for upcoming LibreSSL version

SSL will become opaque in LibreSSL 3.4.x, hence the code reaching inside
it will result in build breakage. This was done at the time for lack of
BIO_up_ref() support, which has been available since LibreSSL 2.7.0, so
adjust the relevant #ifdefs accordingly.

@freerdp-bot test

Don't see this commit in stable-2.0 (2.4.1 release).

@VVD cherry-pick -x pull requests against stable-2.0 is required, we only backport fixes that are requested or are security related to 2.0 ourselfes.

@rozhuk-im, can you create pull requests against stable-2.0?

@VVD did have some spare time, see https://github.com/FreeRDP/FreeRDP/pull/7446

@VVD did have some spare time, see #7446

Thanks!


TabBar: expose padding parameter from SingleChildScrollView

Use case
Problem arise when I need to have a horizontal padding on the TabBar as follow.

Proposal
Just by adding an additional parameter as follow.

Hi @pczn0327
This is already possible https://api.flutter.dev/flutter/widgets/SingleChildScrollView/padding.html

code sample
import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Material App',
      theme: ThemeData.dark(),
      home: Home(),
    );
  }
}

class Home extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Material App Bar'),
      ),
      body: Center(
        child: SingleChildScrollView(
          padding: const EdgeInsets.all(20),
          child: Column(
            children: [
              FlutterLogo(
                size: 300,
              )
            ],
          ),
        ),
      ),
      floatingActionButton: FloatingActionButton(
        child: Icon(Icons.add),
        onPressed: () {},
      ),
    );
  }
}

Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and I will reopen it.
Thank you

Hi @pczn0327
This is already possible https://api.flutter.dev/flutter/widgets/SingleChildScrollView/padding.html

code sample
import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Material App',
      theme: ThemeData.dark(),
      home: Home(),
    );
  }
}

class Home extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Material App Bar'),
      ),
      body: Center(
        child: SingleChildScrollView(
          padding: const EdgeInsets.all(20),
          child: Column(
            children: [
              FlutterLogo(
                size: 300,
              )
            ],
          ),
        ),
      ),
      floatingActionButton: FloatingActionButton(
        child: Icon(Icons.add),
        onPressed: () {},
      ),
    );
  }
}

Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and I will reopen it.
Thank you

Hi @TahaTesser , I apologise if I forgot to mentioned that this is not really an issue, it is more on feature request.
I am requesting for TabBar, to expose the padding from SingleChildScrollView.
In particular, I mean this.

Hi @TahaTesser , I apologise if I forgot to mentioned that this is not really an issue, it is more on feature request.
I am requesting for TabBar, to expose the padding from SingleChildScrollView.
In particular, I mean this.


Home Assistant Integration

You have mentioned in the README that you have only implemented endpoints needed for Home Assistant, is there plans for adding this integration to HA?

Sorry, I see there is already a closed issue about this. https://github.com/tkhadimullin/contact-energy-nz/issues/10


Adding a gem.bat to fix the ruby.exe path issue

We've merged changes in https://github.com/sensu/sensu-omnibus/pull/203 that I believe will make it unnecessary for puppet to directly manage this file. I've kicked off builds for 0.29.0-9 packages so we may test that theory.

@cwjohnston great news but I'm slightly confused.

you didn't want to move to gem.cmd because this would break installs for versions <0.27
without doing this change it will only fix versions >0.29

So this fix will work with all older versions... and would still work with 0.29
At the point that you've decided to deprecate older than 0.27 the bat file wouldn't be necessary and the cmd PR #616 would work for >0.27
I knew you wouldn't go back and release older versions updating the bat file so figured this was a better solution to cover all scenarios... you're call obviously.

you didn't want to move to gem.cmd because this would break installs for versions <0.27

To be clear, I'm not fully 👎  on using gem.cmd over gem.bat, I am merely calling out risks I see and trying figure out what will cause the least confusion.
To me there's still an open question of how gem.cmd came to be part of the package build. I believe it was added by upstream Ruby when we moved from 2.0 to 2.3.0 circa Sensu 0.27. As I continue to look into this I see that gem.cmd is present in 0.27, 0.28 and 0.29 packages and isn't being explicitly added by our omnibus build toolchain. I think we can merge #616.

So this fix will work with all older versions... and would still work with 0.29

I am reluctant to endorse unconditionally overwriting a file provided by official packages, as it adds a corner case we have to consider should changes to that aspect of packaging be needed in the future.

I knew you wouldn't go back and release older versions updating the bat file so figured this was a better solution to cover all scenarios...

I agree, we won't be back-porting a fix and releasing new packages for these older versions.

@cwjohnston ok whatever the internal team feels is best...
#616 will break versions older than 0.27 as you've pointed out.
Yes this creates a corner case but until < 0.27 are officially deprecated from support I think it might become a necessary evil in order to have a module that works in those cases.
I see 3 options:
1. Officially stop supporting versions < 0.27

Merge #616

2. Support older versions

Merge #636
a. When official support deprecates for versions < 0.27****

Revert #636
Merge #616

b. When official support deprecates for versions < 0.29.0-9****

You can either leave #616 since cmd is present or Revert #616 since the bat file is now fixed.

3. Drop support for all versions < 0.29.0-9

No PR merge necessary

@jaxxstorm @hprins

I see 3 options

I agree with your analysis. I've merged #616 to address this.


Kotlin 1.5.0 Issues

More of a heads up, but this plugin (and probably any AspectJ plugin) doesn't seem to play nicely with lambdas in Kotlin 1.5.0 due to changes to Single Abstract Method conversions during compilation.
As a concrete example, in my sample AOP project, if you only change kotlin_version to 1.5.0 instead of 1.4.32, the following pointcut:
@Pointcut("execution(void *.onClick(..))")
fun onButtonClick() {
}

doesn't generate a join point for the following lamba:
button2.setOnClickListener {
    Toast.makeText(this@MainActivity, "Button 2 clicked", Toast.LENGTH_SHORT).show()
}

whereas it does if you just revert the version back to 1.4
This issue is resolved for me by adding the following kotlinOptions block:
kotlinOptions {
    freeCompilerArgs = ["-Xsam-conversions=class"]
}

This option is explained a bit more in the "What's New" article for Kotlin 1.5.0 here. However, I'm wondering if there is a way to fix this without needing the additional compiler arg (since using the new feature would be ideal as it generates less bytecode). The bytecode method signature inside the apk seems to be the same to me with and without the new compiler option, so I'm not totally sure what's going on here.
Attaching generated bytecode for both 1.4 and 1.5 versions of Kotlin in case it's helpful to have as reference
1.4.32.txt
1.5.0.txt

This is sounding familiar to me. We ran into something like this, and if I remember correctly, attributed it to the new JVM IR. We had to disable it.
@vdelricco @yoxjames Can you confirm whether what I just said is accurate?

@jdvp Thanks for the heads up, and the sample app! We'll take a look a closer look at this for sure.

@jdvp I've been playing around with your sample app trying to get a pointcut to match on lambdas. I used javap to analyze the bytecode for MainActivity.class. I can see mention of onCreate$lambda-0 in there, and figured that would be what the pointcut should target. But it's just not working.
After reading the Kotlin documentation on the 1.5.0 changes, invokedynamic is now used for lambdas. And I think the important snippet I came across is this:
Kotlin 1.5.0 is introducing experimental support for compiling plain Kotlin lambdas (which are not converted to an instance of a functional interface) into dynamic invocations (invokedynamic ). The implementation produces lighter binaries by using LambdaMetafactory.metafactory(), which effectively generates the necessary classes at runtime. Currently, it has three limitations compared to ordinary lambda compilation:

More specifically: "which effectively generates the necessary classes at runtime"
Seeing as AspectJ is performing compile time weaving, the runtime classes generated wouldn't be captured by any AspectJ pointcuts. I'm wondering if it's as simple as that? And I'm thinking there's probably no way around it, other than the compile argument you found to turn off the sam conversions.
Granted, a lot of the stuff I was looking at felt a bit over my head. But if my understanding is correct, then I think we're SOL in supporting the new 1.5.0 invokedynamic feature for lambdas.

@eschlenz thanks for looking into it. What you're saying about invokedynamic makes sense to me and my impressions were similar about not being really having any workaround for doing both invokedynamic and using aspectj
I also felt similarly though. I don't know if there is anything to do at this point so we can close this issue! I wonder though as Kotlin gets more and more features if we will get more issues like this.

@jdvp Yeah, I share those concerns about the future of Kotlin + AspectJ. I'm going to keep this open until I at least document this issue on our readme. Thanks for the report!

Updated documentation. Closing this out for now.


New check idea: find CVEs against the current version of the build platform

New check idea: Macaron can look for CVEs against the build platform/CI service version that builds an artifact.
The idea of this new check was originally motivated by this security update from GitLab: https://about.gitlab.com/releases/2023/09/18/security-release-gitlab-16-3-4-released/.

Thanks! That would be a helpful check.


update to 0.7.4 of systemjs-builder (based on another commit to the seed...)

not really sure why we don't just pass the whole config object?

@marjan-georgiev didn't you upgrade the seed and have problems w/ CSS plugin?

Yes. Using plugin-css 0.1.3 and systemjs-builder 0.7.3 will not build bundles which import css modules.
See https://github.com/Swimlane/systemjs-route-bundler/issues/1
This was addressed with today's release of plugin-css 0.1.5 and systemjs-builder 0.7.4. However we'll have to setSystem.buildCSS to false (defaults to true) if we want it to build our bundles.
Bundling CSS is only supported if we use systemjs builder with jspm.

@marjan-georgiev - any problems using the jspm builder?


feat: add new typography and spacing values

Summary | Résumé
Updating our typography and spacing values based on the new values we decided on in alignment with Canada.ca standards.
Updates applied in this PR:

Updated typography core values to adjust our vertical rhythm calculations.
New font size values for all desktop & mobile font size tokens.
New line-height values for all desktop & mobile line-height tokens.
New spacing values for all existing spacing tokens.
Addition of new spacing tokens for increased flexibility.
Mapping of all old spacing tokens to the matching new spacing token for component tokens.
The font tokens for the text-long tokens have been removed, as all text tokens will be using the same line-height moving forward.

Documents
The document for the new typography and spacing decisions can be found here.
Fixes
I noticed that the compiled text tokens file was also loading in textarea tokens, and the font tokens file was also loading in font sizes + weights. I added some fixes to the config to avoid accidentally including tokens from sibling directories starting with the same name.
NOTE: DO NOT MERGE YET!

NOTE: DO NOT MERGE YET! PRE-RELEASE MESSAGING NEEDS TO GO OUT FIRST!

@daine @ethanWallace I added the token updates needed after the typography and spacing updates.


Editors as None on Repldex entries

On both Repldex server and Repl.it server.
Affecting most people, very weird please fix.

Ok I can try to fix it later in the day when I can

Fixed by mat, closing issue

Ok :)


Max Array Sum

Feature ✅
Description

Given an array of integers, find the subset of non-adjacent elements with the maximum sum. Calculate the sum of that subset.
For example, given an array [-2,1,3,-4,5]  we have the following possible subsets:

Subset
Sum

[-2, 3, 5]
6

[-2, 3]
1

[-2, -4]
-6

[-2, 5]
3

[1, -4]
-3

[1, 5]
6

[3, 5]
8

Our maximum subset-sum is 8.
Example

Input Format
The first line contains an integer, n.
The second line contains n space-separated integers arr[i].
Output Format
Return the maximum sum described in the statement.
Input
5
3 7 4 6 5
Output
13
Explanation
Our possible subsets are [3,4,5], [3,4], [3,6], [3,5], [7,5], [7,6] and [4,5]. The largest subset sum is  13 from subset [7,6]
Checklist:

[x] I have read the project guidelines.
[x] I have checked all the existing projects, before submitting a new project issue.
[x] This issue will be meaningful for the project.
[x] I will contribute more in future

Contributors are supposed to mention their coding language while asking for assignment

Hey, @pallavivaswani I would like to contribute in C/C++ language

Hey! can I work on this in C++.

I would like to complete this in C++


Modifying elastix parameters

This is not an issue, rather a suggestion.
Currently, the only way to modify a parameter is to edit the text file. Here is a draft of my idea:

All the parameters and their options are saved in a text file.
Users can modify the current parameters file by using two QComboBoxes, a QComboBox for the parameter and another for its values  (QLineEdit in case of numbers).

This makes it easier and faster to experiment on different parameters.

Registration parameters are not independent from each other but have very complex relationships between them. Anybody who understands what registration parameters can be changed and how should have no problem handling a text editor.


The delete directory process exits

Don't want him to back out and help

@zdwork sorry?

Is there any good way to solve it? I did it with a gorouting, as long as we don't let the main process exit

Sorry I still don't understand what you're trying to say.

Don't let main exit.goroutine exec tail

How do you delete a file without letting it exit

You can remove the directory from watcher before deleting it.

Excuse me, how do I do that

w.RemoveRecursive(path)
//or
w.Remove(path)

Sorry, what I just said is wrong, we all delete it first

if name == err.(*os.PathError).Path {
//w.Error <- ErrWatchedFileDeleted
w.RemoveRecursive(name)
}
howdy  Is that ok？


Update Guzzle version

Not working

Can't just update to guzzle 6, multiple changes will need to be made to the Client class. I'll look into it, but not sure if i can get it finished soon

I pushed the changes to the guzzle6 branch. Let me know if it works for you.
composer require tuurbo/spreedly:dev-guzzle6

Yes, I have seen that they change Response Class by Psr7 one. I will try to help you with the changes. I will try this branch Thanks!

lets merge

Now available in 1.7.0


Applied Linked Geo. Metadata

James Griffin<EMAIL_ADDRESS>1.5 hours
Developers, Metadata people
+
"- A preliminary understanding of geospatial metadata

An elementary understanding of linked geospatial metadata
Practical metadata modeling for Hyrax
An introduction to RDF Graph stores for linked spatial data
Methods for analyzing spatial linked data as RDF Graphs"

This workshop aims to provide a set of overviews and technical exercises which shall provide participants with an understanding of linked geospatial data, and what role it could serve within a Samvera repository application.  The objective of the exercises will be to provide participants with experience modeling geospatial metadata for Samvera repository resources.  Building upon this, an understanding of how this linked geospatial metadata may be indexed for content discovery, or exported into separate platforms for analysis shall be demonstrated.  As much of this work is derived from the undertakings of the Geo. Predicates Working Group, striving to remain aligned with larger community web standards (such as those published by the W3C) should be considered the proper context for any practical usage of linked geospatial metadata.
Laptop (with WiFi or other access to the World Wide Web)
Max: 30

James confirmed 30/5 - sole presenter

8/27 Registered


typo in enhanced protection

https://github.com/iam-py-test/my_filters_001/blob/6d9ad426b506bb1e095ac07f4678beb2f767df56/enhanced_protection.txt#L12-L14
Missing a line break after top exceptions. monster should be on a new line:
 ! Abused TLDs
 ||bid^$document
 ||top^$document,domain=~corriente.top|~gdtot.top|~nicenature.top|~reminder.top|~magocoro.top|~castlevania.top|~suiten.top
 ||monster^$document
 ||ooo^$document

Also: The TLD will break 3rd party streaming sites (example) . I recommend adding:
 ||monster^$document,domain=~cloudcdn.monster
There was another site that used a .monster TLD, but I can't recall it.

Thank you.


WIP: Limit velocity and temperature in Kinetic jet injection region

Limits the velocity and temperature within the kinetic jet injection zone to below specified ceilings. In the current state of this PR, this will enforce the ceiling whether or not hitting the ceiling was due to kinetic jet injection or not. If this ceiling fixes the issue we could explore less aggressive ceilings.

@par-hermes format

@pgrete Since this fix seems to be working fine for the current suite of simulations, we can merge this into the other PR if it's alright

I think this has been tested enough over the past weeks. I'm merging this and closing the alternative #76


Tweaks for 1.2b3

Some tweaks for Swift 1.2b3 support, needed by https://github.com/Carthage/Carthage/pull/368.

Thanks for the pull request, Rob! :sparkles:
You might have missed the swift-1.2 branch?
I meant to post about that in Carthage/Carthage#368, apologies :expressionless:

5c8411d and d36ac13 have counterparts there, which allow PrettyColors to compile under Xcode 6.3 beta 3.
As far as the other commits, no objections — just curious, why are the the deployment targets now necessary: change in Xcode and build system, change in Carthage, other?
Also, would you mind explaining GCC_NO_COMMON_BLOCKS a bit? :heart:

I did indeed miss that branch!
Deployment target changes are necessary due to Xcode changes. It didn’t enforce them before (it ought to have).
GCC_NO_COMMON_BLOCKS was suggested by Xcode and I get tired of staring at the :warning: icon.

First thing I found about GCC_NO_COMMON_BLOCKS was this Stack Overflow answer — it quotes:

In C, allocate even uninitialized global variables in the data section of the object file, rather than generating them as common blocks. This has the effect that if the same variable is declared (without extern ) in two different compilations, you will get an error when you link them. The only reason this might be useful is if you wish to verify that the program will work on other systems which always work this way.

I have no idea why this would be necessary in Swift with namespaces, but I’m cool with adding it just to shut Xcode up.

A couple git best practices questions:

Should I cherry-pick those commits before 5c8411d or would you prefer to open a new pull request for the  the swift-1.2 branch?
It would be nice if the messages of the commits were a little more precise (“bump”ing what, “recommend”ing why, “target”ing which). If I was hypothetically to cherry-pick the commits, would it be poor etiquette to amend the commits myself (aka does commit authorship indicative of both the message and the code of the commit) :question:

@jdhealy Honestly, whatever you prefer is fine by me. I have zero concern beyond unblocking Carthage.

@robrix Okay, thanks for your time and effort.
If all's fine with you, I'll make these same commits on the swift-1.2 branch and credit you in the commit messages. :smiley:

Cherry-picked the commits and amended their messages.
Appended the following to the end of the messages:

Credit to @robrix. Commit message amended by @jdhealy. See <https://github.com/jdhealy/PrettyColors/pull/5>.

Closing this pull request.
Thanks again Rob!


posix: implement fread()

This is part of the See POSIX Roadmap for LTSv3 (RFC #51211).
fread() is required as part of POSIX_DEVICE_IO Subprofiling Option Group.
For more information, please refer to https://pubs.opengroup.org/onlinepubs/9699919799/functions/fread.html

Hi @ycsin and @cfriedt , I would like to give this a shot. Can you please assign me this issue? I'm thinking of using this pr - https://github.com/zephyrproject-rtos/zephyr/pull/68516 as a base. Thanks!

@RAJAGOPALAN-GANGADHARAN - done!
However, something to keep in mind is that fread() is actually just a part of ISO C, all the way back to C89. That means, that the implementation of this function should likely go into the common libc, and tests should be added to the common libc test suite.
https://en.cppreference.com/w/c/io/fread
Additionally, a fairly fundamental problem needs to be solved for this to be done The Right Way (TM). Namely, we need a way to easily associate FILE * objects to (and from) integer file descriptors.
That would ideally be done in ZVFS (which is itself a kind of relocation of code from various libraries and subsystems to avoid dependency cycles at the API level.

Thanks @cfriedt - Looking at how fwrite has been implemented in minimal libc currently, seems like it only supports write to stdout and stderr. No fs support seems to be added (the use of zephyr fs apis like fs_open etc - https://docs.zephyrproject.org/latest/services/file_system/index.html#c.fs_dir_t.), is this what is expected from the fread (read from stdin) as well? Also in the future will the support be expanded to fs operations for these apis? Thanks!

@RAJAGOPALAN-GANGADHARAN  Currently stdin / stdout / stderr should work, but we do want to support operations on other files as well.

@RAJAGOPALAN-GANGADHARAN - done!
However, something to keep in mind is that fread() is actually just a part of ISO C, all the way back to C89. That means, that the implementation of this function should likely go into the common libc, and tests should be added to the common libc test suite.
https://en.cppreference.com/w/c/io/fread
Additionally, a fairly fundamental problem needs to be solved for this to be done The Right Way (TM). Namely, we need a way to easily associate FILE * objects to (and from) integer file descriptors.
That would ideally be done in ZVFS (which is itself a kind of relocation of code from various libraries and subsystems to avoid dependency cycles at the API level.

@cfriedt Is correct.
C standard is subset of POSIX standard (or POSIX standard is superset over C).
This can be seen when comparing read and fread functions using the OpenGroup documentation:
read -> https://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html
fread -> https://pubs.opengroup.org/onlinepubs/9699919799/functions/fread.html
Look also at the C standard, draft, here https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf - you will notice that the fread is part of stdlib definition (Chapter 7).
Note also that C standard wins with POSIX when differs:


Add documentation for Prometheus metrics in Training Operator

Follow up from https://github.com/kubeflow/training-operator/issues/2254
Description
This PR adds a new section to the documentation explaining how to monitor Kubeflow training jobs using Prometheus metrics exposed by the Training Operator.
Changes

Rewrote and added a new page titled "Prometheus Monitoring" under the Training Operator documentation.
Explained how to access the Prometheus metrics for the Training Operator.
Provided a detailed list of relevant metrics, including description and label information.

Thanks for the review @andreyvelich and @tenzen-y !
I have created a PR for removing the doc from the Training Operator repo: https://github.com/kubeflow/training-operator/pull/2301


Add WIP Microbiome Explorer

While the Microbiome Explorer isn't done, there is enough added functionality that making a release will be needed in order to validate the HTML render for further testing


CreateItemStreamAsync for partition key name containing special characters fails with BadRequest

We are continuously addressing and improving the SDK, if possible, make sure the problem persist in the latest SDK version.

Describe the bug
When attempting to call CosmosClient.CreateItemStreamAsync() for an item/collection with partition key name containing special characters, the request always fails with BadRequest "PartitionKey extracted from document doesn't match the one specified in the header".
To Reproduce

Create collection with partition key name containing special characters.
Attempt to insert a document (with a defined partition key) into the collection using CosmosClient.CreateItemStreamAsync().
Examine the ResponseMessage status code and error message.

See emulator test added in branch users/jopao/pkSpecialCharacters:
https://github.com/Azure/azure-cosmos-dotnet-v3/compare/users/jopao/pkSpecialCharacters?expand=1
Expected behavior
Expect that the request succeeds and the item is inserted into the collection.
Actual behavior
The response message indicates failure with status code BadRequest and error message "PartitionKey extracted from document doesn't match the one specified in the header".
Environment summary
SDK Version: 3.10.1
OS Version: Windows 10 Enterprise, Version 10.0.18363

On Stream APIs, the Stream is the one you generate. The error is related to the Partition key header value not matching with the data in the document represented in the Stream.
Do you have a property in the document that matches the PartitionKeyDefinition in the Container with the same encoding as you are passing the PartitionKey value?
For example,if you container has /myPartitionKey as PK, does your stream contain a property myPartitionKey with a value that matches what you are passing as Partition Key to the parameter? Are you using UTF8 encoding to generate the stream?

@john-pao the issue with your example is the item does not have the partition key path specified in the container creation. The container has the path to the partition key. The item operations require the partition key value which must be at the path specified in the container.
Here are valid values for your test.
const string PartitionKeyPath = "/\"/my !@#$%&*()_+|?.,><~`/ pk\"";
const string ItemJsonPayload = "{\"label\":\"blah\",\"id\":\"08d39221-15f5-4312-ad9a-bd40923469e8\",\"/my !@#$%&*()_+|?.,><~`/ pk\":\"blah2\"}";
const string ItemPartitionKey = "blah2";

I created a container using the same PartitionKeyPath as is specified in the ItemJsonPayload.
The path is: /"/my !@#$%&*()_+|?.,><~`/ pk"
const string PartitionKeyPath = "/"/my !@#$%&*()_+|?.,><~`/ pk"";
this.containerSettings = new ContainerProperties(id: containerName, partitionKeyPath: PartitionKeyPath);
The property name is: "/my !@#$%&*()_+|?.,><~`/ pk"
const string ItemJsonPayload = "{"label":"blah","id":"08d39221-15f5-4312-ad9a-bd40923469e8","/my !@#$%&*()_+|?.,><~`/ pk":"blah2"}";

@j82w  After further testing it seems your suggested correction was not quite correct for the scenario
const string PartitionKeyPath = "/\"/my !@#$%&*()_+|?.,><~`/ pk\"";
const string ItemJsonPayload = "{\"label\":\"blah\",\"id\":\"08d39221-15f5-4312-ad9a-bd40923469e8\",\"/my !@#$%&*()_+|?.,><~`/ pk\":\"blah2\"}";
const string ItemPartitionKey = "blah2";

Using this, the partition key property name embedded in the document is missing the surrounding escaped double-quotes, which while successful, seems to lead to the SDK creating the document in the Undefined partition rather than using the desired "blah2" partition key value.
I'm going to re-open this for tracking.
I've also fixed the collection partition key path in the repro sample to both simplify it and reflect my intentions:
const string PartitionKeyPath = "/\"mypk\"";
const string ItemJsonPayload = "{\"label\":\"blah\",\"id\":\"08d39221-15f5-4312-ad9a-bd40923469e8\",\"\\\"mypk\\\"\":\"blah2\"}";
const string ItemPartitionKey = "blah2";

The special characters in this case around the escaped double-quotes in the partition key property name.

This seems to be more of a bug in v2 SDK/Cosmos DB. The PK path specified does exist and it does have a value. The correct PK value is "blah2". The fact that the v2 SDK is extracting the value as undefined and the backend also is not able to find it seems like a bug.

The V2 SDK correctly extracts the partition key value "blah2" from the document.
In my above comment, I was referring to the 'valid values' you had previously provided; they do work with the V3 SDK test, but only because you omitted the embedded double-quotes that should be embedded in the document's PK property name such that the document is assigned the Undefined partition key rather than correctly extracting "blah2":
const string PartitionKeyPath = "/\"/my !@#$%&*()_+|?.,><~`/ pk\"";

versus
const string ItemJsonPayload = "..., \"/my !@#$%&*()_+|?.,><~`/ pk\":\"blah2\"}";

When the values are corrected as follows for the V3 SDK, the request fails as I had initially described in this issue.
const string PartitionKeyPath = "/\"/my !@#$%&*()_+|?.,><~`/ pk\"";
const string ItemJsonPayload = "{\"label\":\"blah\",\"id\":\"08d39221-15f5-4312-ad9a-bd40923469e8\",\"\\\"/my !@#$%&*()_+|?.,><~`/ pk\\\"\":\"blah2\"}";
const string ItemPartitionKey = "blah2";

{"Response status code does not indicate success: BadRequest (400); Substatus: 1001; ActivityId: c4c02641-41c9-454d-89e8-a09aaee29b18; Reason: (Message: {"Errors":["PartitionKey extracted from document doesn't match the one specified in the header"]}\r\nActivityId: c4c02641-41c9-454d-89e8-a09aaee29b18, Request URI: /apps/DocDbApp/services/DocDbServer6/partitions/a4cb4952-38c8-11e6-8106-8cdcd42c33be/replicas/1p/, RequestStats: Please see CosmosDiagnostics, SDK: Windows/10.0.18363 cosmos-netstandard-sdk/3.11.1);"}

After more testing the only reason this is working in v2 is it is always setting the partition key to undefined. This makes it not possible for the user to read the document back if they use the partition key value specified in the document. They have to switch the partition key value to the undefined in order to read it.
V3 since it requires the user to pass in the partition key value on the CreateItemStreamAsync method it fails on the insert rather than the read. Users could still do what v2 is using a specify the undefined partition key value, but that seems like the incorrect behavior.

Looking at our partition key documentation, it seems like this may not even be a valid scenario to begin with.
https://docs.microsoft.com/en-us/azure/cosmos-db/partitioning-overview

The partition key path accepts alphanumeric and underscore(_) characters. You can also use nested objects by using the standard path notation(/).

We're going to adjust our test case to match the valid characters described there (just combinations of alphanumerics and underscores) and not test against values such as escaped double-quotes in the partition key path
Thanks for your help investigating this issue, Jake.


✨ catalog: add ds.tables to get list with all tables

When working with a dataset with multiple tables, we sometimes need to load all of them. This is specially true for Grapher steps when we just want to push propagate all tables coming from garden to Grapher.
The idea would be that, instead of doing:
# Load dataset
ds_garden = paths.load_dataset("leading_causes_deaths")

# Read all tables
all_tb = [ds_garden[tb_name for tb_name in ds_garden.table_names]

# Create a new grapher dataset with the same metadata as the garden dataset.
ds_grapher = create_dataset(
    dest_dir,
    tables=all_tb,
    check_variables_metadata=True,
    default_metadata=ds_garden.metadata,
)

one can simply write
# Load dataset
ds_garden = paths.load_dataset("leading_causes_deaths")

# Create a new grapher dataset with the same metadata as the garden dataset.
ds_grapher = create_dataset(
    dest_dir,
    tables=ds_garden.tables,
    check_variables_metadata=True,
    default_metadata=ds_garden.metadata,
)

Unsure where the unit-test errors are coming from. It looks as if method named tables is not allowed?
ERROR tests/apps/wizard/utils/test_env.py - AttributeError: 'function' object has no attribute 'Table'
ERROR tests/backport/datasync/test_data_metadata.py - AttributeError: 'function' object has no attribute 'Table'
ERROR tests/data_helpers/test_geo.py - AttributeError: 'function' object has no attribute 'Table'
ERROR tests/test_command.py
ERROR tests/test_converters.py - AttributeError: 'function' object has no attribute 'Table'
ERROR tests/test_datadiff.py - AttributeError: 'function' object has no attribute 'Table'
ERROR tests/test_etl.py
ERROR tests/test_grapher_helpers.py - AttributeError: 'function' object has no attribute 'Table'
ERROR tests/test_grapher_model.py - AttributeError: 'function' object has no attribute 'Table'
ERROR tests/test_helpers.py - AttributeError: 'function' object has no attribute 'Table'
ERROR tests/test_metadata_schemas.py - AttributeError: 'function' object has no attribute 'Table'
ERROR tests/test_prune.py - AttributeError: 'function' object has no attribute 'Table'
ERROR tests/test_snapshot.py - AttributeError: 'function' object has no attribute 'Table'
ERROR tests/test_steps.py - AttributeError: 'function' object has no attribute 'Table'
ERROR tests/test_version_tracker.py - AttributeError: 'function' object has no attribute 'Table'

@Marigold right! that makes sense ー i'll close this issue for now then.


Munkireport Python3?

Hi @davidbpirie
I see you have written AutoPkg recipes for both Python2 and Python3 supposedly downloading from the munkireport/MunkiReport-Python repo.
There is indeed a Python2 available via that repo for use with MunkiReport but I cannot see a Python3 in that repo. I am presuming the MunkiReport author has removed it as MunkiReport sadly still uses only Python2.
I was wondering if you could confirm this?
I was contemplating using this as a way to install a copy of Python3 for other uses.

@jelockwood if you haven't already found a solution, I would suggest looking at https://github.com/gregneagle/relocatable-python.


Weird InvalidOperationException

Version
8.0.11
On which operating system(s) are you experiencing the issue?
Linux
Using which broker(s) did you encounter the issue?
RabbitMQ
What are the steps required to reproduce the issue?
Unfortunately I was not able to reproduce the bug locally, so I'm posting here my app configuration and possible steps to reproduce:
Main configuration:
builder.Services.AddMassTransit(x =>
{
    x.AddEntityFrameworkOutbox<SomeContext>(
        o =>
        {
            o.QueryDelay = TimeSpan.FromSeconds(5);
            o.UsePostgres();
            o.UseBusOutbox(ot => ot.MessageDeliveryLimit = 500);
            o.DuplicateDetectionWindow = TimeSpan.Zero;
            o.IsolationLevel = IsolationLevel.ReadCommitted;
        });
...

x.UsingRabbitMq(
            (
                context,
                cfg) =>
            {cfg.UseMessageRetry(
                    r =>
                    {
                        r.Interval(3, TimeSpan.FromSeconds(5));
                        r.Handle<DataException>(exception => exception.Message.Contains("SQL"));
                    });
...

Consumers configured with:
endpointConfigurator.UseEntityFrameworkOutbox<SomeContext>(_serviceProvider);

Basically I have few consumers than receive millions of messages per month and about 100-150 of messages fail with exception(see below). It might be related to DuplicateDetectionWindow, but I'm not sure
What is the expected behavior?
No exception
What actually happened?
InvalidOperationException
Related log output, including any exceptions
The instance of entity type 'InboxState' cannot be tracked because another instance with the same key value for {'MessageId', 'ConsumerId'} is already being tracked. When attaching existing entities, ensure that only one entity instance with a given key value is attached. Consider using 'DbContextOptionsBuilder.EnableSensitiveDataLogging' to see the conflicting key values.

 at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.IdentityMap`1.ThrowIdentityConflict(InternalEntityEntry entry)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.IdentityMap`1.Add(TKey key, InternalEntityEntry entry, Boolean updateDuplicate)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.StartTracking(InternalEntityEntry entry)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.InternalEntityEntry.SetEntityState(EntityState oldState, EntityState newState, Boolean acceptChanges, Boolean modifyProperties)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.InternalEntityEntry.SetEntityStateAsync(EntityState entityState, Boolean acceptChanges, Boolean modifyProperties, Nullable`1 forceStateWhenUnknownKey, Nullable`1 fallbackState, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.EntityGraphAttacher.PaintActionAsync(EntityEntryGraphNode`1 node, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.EntityEntryGraphIterator.TraverseGraphAsync[TState](EntityEntryGraphNode`1 node, Func`3 handleNode, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.EntityGraphAttacher.AttachGraphAsync(InternalEntityEntry rootEntry, EntityState targetState, EntityState storeGeneratedWithKeySetTargetState, Boolean forceStateWhenUnknownKey, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.DbContext.AddAsync[TEntity](TEntity entity, CancellationToken cancellationToken)
   at MassTransit.EntityFrameworkCoreIntegration.EntityFrameworkOutboxContextFactory`1.<>c__DisplayClass5_0`1.<<Send>g__Execute|0>d.MoveNext() in /_/src/Persistence/MassTransit.EntityFrameworkCoreIntegration/EntityFrameworkCoreIntegration/EntityFrameworkOutboxContextFactory.cs:line 104
--- End of stack trace from previous location ---
   at MassTransit.EntityFrameworkCoreIntegration.EntityFrameworkOutboxContextFactory`1.<>c__DisplayClass5_0`1.<<Send>g__Execute|0>d.MoveNext() in /_/src/Persistence/MassTransit.EntityFrameworkCoreIntegration/EntityFrameworkCoreIntegration/EntityFrameworkOutboxContextFactory.cs:line 104
--- End of stack trace from previous location ---
   at MassTransit.EntityFrameworkCoreIntegration.EntityFrameworkOutboxContextFactory`1.<>c__DisplayClass5_0`1.<<Send>g__Execute|0>d.MoveNext() in /_/src/Persistence/MassTransit.EntityFrameworkCoreIntegration/EntityFrameworkCoreIntegration/EntityFrameworkOutboxContextFactory.cs:line 104
--- End of stack trace from previous location ---
   at MassTransit.EntityFrameworkCoreIntegration.EntityFrameworkOutboxContextFactory`1.Send[T](ConsumeContext`1 context, OutboxConsumeOptions options, IPipe`1 next) in /_/src/Persistence/MassTransit.EntityFrameworkCoreIntegration/EntityFrameworkCoreIntegration/EntityFrameworkOutboxContextFactory.cs:line 115
   at MassTransit.Middleware.OutboxConsumeFilter`2.Send(ConsumeContext`1 context, IPipe`1 next) in /_/src/MassTransit/Middleware/OutboxConsumeFilter.cs:line 42
   at MassTransit.Middleware.OutboxConsumeFilter`2.Send(ConsumeContext`1 context, IPipe`1 next) in /_/src/MassTransit/Middleware/OutboxConsumeFilter.cs:line 42
   at MassTransit.Middleware.RetryFilter`1.MassTransit.IFilter<TContext>.Send(TContext context, IPipe`1 next) in /_/src/MassTransit/Middleware/RetryFilter.cs:line 134
   at MassTransit.Middleware.RetryFilter`1.MassTransit.IFilter<TContext>.Send(TContext context, IPipe`1 next) in /_/src/MassTransit/Middleware/RetryFilter.cs:line 134
   at MassTransit.Middleware.TeeFilter`1.<>c__DisplayClass5_0.<<Send>g__SendAsync|1>d.MoveNext() in /_/src/MassTransit/Middleware/TeeFilter.cs:line 43
--- End of stack trace from previous location ---
   at MassTransit.Middleware.OutputPipeFilter`2.SendToOutput(IPipe`1 next, TOutput pipeContext) in /_/src/MassTransit/Middleware/OutputPipeFilter.cs:line 110
   at MassTransit.Middleware.OutputPipeFilter`2.SendToOutput(IPipe`1 next, TOutput pipeContext) in /_/src/MassTransit/Middleware/OutputPipeFilter.cs:line 110
   at MassTransit.Middleware.DeserializeFilter.Send(ReceiveContext context, IPipe`1 next) in /_/src/MassTransit/Middleware/DeserializeFilter.cs:line 45
   at MassTransit.Middleware.RescueFilter`2.MassTransit.IFilter<TContext>.Send(TContext context, IPipe`1 next) in /_/src/MassTransit/Middleware/RescueFilter.cs:line 63

Link to repository that demonstrates/reproduces the issue
No response

I'm fairly sure you need either Serializable or RepeatableRead for the outbox, but this seems like you're getting a duplicate message delivery. Make sure you're on 8.0.16 and see if it goes away.

Thank you for suggestions, will try

@milkweed-crs - I'm curious if you've gotten anywhere with this issue. I'm experiencing the same thing.

@codyspeck-ppa, not yet, unfortunately. Our release cycle is not that fast because we fully test any changes on development/staging environments, and this problem is only occurring in production. I'll try the suggested changes and reply to you when we get any results.
I must mention that we also use "EnableRetryOnFailure" and DbContext pooling, so it might be related to this issue.

I've gone ahead and opened up another ticket with more details on the specifics of this issue here - https://github.com/MassTransit/MassTransit/issues/4474.


Update suggested from 2020-07-22 workshop.

Adding the optimize step that was needed to be updated.

Workshop was on 2020-06-22, not 2020-07-22.


Post request with querystring

I think Zuul has bug in SimpleHostRoutingFilter.java.
When thos route filer is executed on post request it trying to create HttpPost object with URI encoder but there are some characters like pipe (|) that os not valid for URI and it throws exception for that value.
Am i right or i missing something ?

I believe that issue was fixed with https://github.com/Netflix/zuul/pull/161, assuming I understand the question correctly.


Fix image registry's rollout parameter

Add omitempty tag so empty values are not validated by the regex.

/assign @deads2k
fyi @sttts seems that the verify test isn't picking up mismatches between the godoc and the generated CRDs.

Note - the RolloutStrategy field is new and has not been installed on any OpenShift cluster yet.

/lgtm


Fatal error when compiling SFML from sources

Subject of the issue
Compiling SFML from sources from current master (commit 59df9d0d887f11724679f2c99dec0f05d6caeaf4) causes a fatal error:
/home/jul3x/SFML/src/SFML/Window/Unix/CursorImpl.cpp:32:10: fatal error: X11/Xcursor/Xcursor.h: No such file or directory
   32 | #include <X11/Xcursor/Xcursor.h>

Your environment

OS: Ubuntu 20.04
SFML from master (commit 59df9d0d887f11724679f2c99dec0f05d6caeaf4)
gcc 9.3.0

Steps to reproduce
Commands:
sudo apt-get install libudev-dev libvorbis-dev libflac-dev libopenal-dev libfreetype6-dev libx11-dev libxrandr-dev
git clone https://github.com/SFML/SFML --branch master
cd SFML
cmake .
make

Expected behavior
Compilation should be successful.
Actual behavior
Fatal error occured:
/home/jul3x/SFML/src/SFML/Window/Unix/CursorImpl.cpp:32:10: fatal error: X11/Xcursor/Xcursor.h: No such file or directory
   32 | #include <X11/Xcursor/Xcursor.h>

I suppose that I am missing some dependency but why CMake haven't found any errors then?

Executing:
sudo apt-get install libxcursor-dev

fixes compilation process.

Yes, with #1694 we added a new dependency, so this is expected. 🙂


Download options, full article pdf only for now

Problem / Motivation

WHO Reader
WHAT I would like to be able to download and copy of the full article
WHEN & WHERE any time, in the article page (first load, after reading part of it, after coming back to it)
WHY To read the article offline, index into a reference management system, to read on other devices

Proposed solution

Use the existing download icon. The icon opens an overlay menu.
We only need a link to download PDF full article link for now, no other links there

Tasks

[ ] Article schema must include a link or a reference that can be used to build a link
[ ] Journal needs to render the download icon and menu

Clarification needed and assumptions

We will only store the latest article version PDF

It would be the most recently supplied PDF

The PDF asset location will be provided in the XML

It won't be the absolute path. It's just file name in the XML.

Follows: the article store will copy the PDF and substitute the link in the stored XML

Technical notes

Use Content-Disposition: attachment; filename="elife-35692-v1.pdf"
Start with a persistent volume attached to the relevant article store container(s)? Limits only one container of that kind being created, doesn’t scale
Start with a cloud provider specific solution and provide alternatives? Google Cloud Storage or S3 as default?

User interface / Wireframes

JATS to read:
<article-meta>
    <self-uri content-type="pdf" xlink:href="[something]"/>
</article>

taking @xml:base into account (must be an absolute URI).


Implement signing with sessions and devices

Description
Implement the in the IDM Wallet the ability to sign with sessions and devices.
.session.sign(sessionId, ArrayBuffer data, { SignatureKeyType keyType = 'session', String ?previewUrl } ?options): Promise<IdentifiedSignature>

Acceptance Criteria

[x] Have the ability to sign with sessions and devices.

Done, repos:

https://github.com/ipfs-shipyard/js-idm-signatures
https://github.com/ipfs-shipyard/js-idm-client

The IDM spec was updated as well.

The previewUrl will be made in a later stage.


⚠ Bofrost.de has degraded performance

In 6c9e88e, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1680 ms

Resolved: Bofrost.de performance has improved in 053fdbc after 19 minutes.


Investigate changes WRT selection handling in either Hoist or Ag-grid

We have recently seen unexplained changes with the behavior of selections in a flagship client app on Hoist 41-SNAPSHOT. The observed changes have manifested two ways:

In a grouped grid that displays tickets, one can now click on a group row and have it display as if it is truly selected (ie with borders around it highlighting it as a selection. Then, an auto refresh might come in, and select the first row automatically (indicating that the "selected" group row is not truly considered a selection), but confusingly also leaving the group row confusingly display as if it is still the selection.

In another grid there are a variable number of grid thats should only allow one selection between them. If a row is selected in one grid, the other grids selections are cleared. For an extended period of time @lbwexler and I both recall the code in place for this working fine. Recently QA reported that clicking on a second grid clears the selection entirely from all grid. (this one may or may not relate API changes as there has been other work done surrounding these grids)

Don -- lets go over case #2 and make sure we are ok there in the app in question.  If so, we would like to just close this bug.  The current behavior does not necessarily seem broken.

We made some adjustments to compensate. You and I were reviewing that at the time of the breakage IIRC. Then we noticed the group rows being highlighted as selected, hence this ticket.


Migrate away from Uglify

Uglify-js does not have support for ES6, and the existing ES6 support (Uglify-es) has been deprecated.
https://github.com/mishoo/UglifyJS2/issues/3156#issuecomment-392943058
To support minification in modern browser build targets, we may need to migrate to an alternative library.
Some alternatives include https://github.com/terser-js/terser and https://github.com/babel/minify

hmm, thought I was using terser already but def worth doing if not.

https://github.com/elmsln/wcfactory/blob/eb50c2d8ff8a699c665ab4727e58a45de28e7b19/packages/generator-wcfactory/generators/init/templates/scripts/rollup.config.factory.js#L4

oh, well that would explain why my roll ups are failing since it's attempting to roll up es6 :)
This is something I had previously fixed and then borked in juggling all these dev branches I had.
So which should we use, terser which has a rollup plugin or the babel minify one (which probably does too, haven't looked)


Create a simple Drone testing latest 3 Go versions

master is broken, but better add this now than later.

Examples now have some httptest.Server we mock upstream calls with. :)
All tests pass now :tada:


Add ASWF Digitial Assets license v1.0

Signed-off-by: John Mertic<EMAIL_ADDRESS>

Thanks Steve! Made the changes suggested.
Made one comment above on the license URI - thinking of having a URI under aswf.io that forward to here. Not sure if that is ok.

Thanks!
On the license URI... hmm. My one concern is that redirecting to a GitHub address might lead to it pointing to the wrong version, if/when the license is updated in the future. Or you might have to redirect to the GitHub URI for a specific commit, which could get confusing too.
I think if you point to the GitHub URI for the version 1.0 of the license, that's likely fine as long as you can make sure that the file isn't edited in the future, and the repo isn't reorganized or the path changed, etc. That could get complicated but could be fine if you think that's manageable.

Good point - I was thinking for new versions I'd just add a whole new file and URI which might make this easier. But I likely am also overthinking things :-)


Updated validations.py python script

Fixed the behavior of validate_user function to check and return True if the first character isalpha()
Closes: #1
Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

@googlebot I signed it


[appdaemon] create separate chart outside of home-assistant

Special notes for your reviewer:
Step 1 of removing from the home-assistant chart
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [radarr])

Hm.. looks like a /conf/appdaemon.cfg is required and needs at least the following config:
appdaemon:
  latitude: xxxx.xxxx
  longitude: -xxxx.xxxx
  elevation: xx
  time_zone: us/pacific

Bummer it doesn't pick it up from the environment variables :(

@alexdor will be building a custom image that hopefully takes care of this issue :)

I am having difficulties getting the custom image I built to work correctly 🙄
Seems like an issue with Python on start :/

maybe try an older python? I saw an issue saying it didn't work with 3.9, but maybe 3.8 as well?

I pinned to 3.8 but also had issues. I think we should revert to 3.0.5 until the following PR is merged
https://github.com/AppDaemon/appdaemon/pull/1002

This should be ready for review!

Finally ready for review @bjw-s this was a fun char tot work on 🙄


Support -F for feature

Recent cargo supports "-F" for the feature argument.
I'm not sure a) how long cargo has supported this b) which versions of the cargo CLI this crate targets, but I'm trying to use it with cargo 1.62.0.

Yes, I added this to cargo in 1.62.0.  Thanks for getting it into clap-cargo!


Section for GitHub CLI

Add a section to talk about how to configure GitHub cli on the local computer

Completed


Error message shows a wrong char limit for users who are not logged in

This is the limit for the request, not for the user

This is the limit for the request, not for the user

It's PER request FOR users that are not signed in (did not provide API keys). The right limit per request, as I was told, is 333 characters. Regardless, this is clearly a bug, given it literally says "1640 > 2500" in the error message

Yep, you're right, missed that. Can you provide the code to reproduce the error?

The following code does it for me:
from elevenlabs import generate generate(text='a'*400, model='eleven_monolingual_v1')


Add Pt translation to d3 and c3 renderers

Add Pt translation to d3 and c3 renderers. Was removed the dependence of the gchart renderer, too.

Super, thanks very much!


Redesign connectivity

The main goal of this pull request is to improve external interface of connectivity.
The first few commits make API documentation more specific and particularly require authentication of connection destination. Then, more interfaces are defined to clarify how replica support handling of incoming connections. After some prompted refactoring, the API is extended to allow replicas distinguish between incoming peer and client connections. Please find more details in corresponding commit messages.
Finally, the last commit (with RFC tag) suggests to require mutual authentication between replicas. This deserves more consideration since it adds more complexity burden onto external component implementation. An alternative approach would be to reverse the direction of communication between replicas. Namely, when a replica initiates a connection to its peers, as opposed to feeding its messages there, it would only receive messages supplied by the connection destinations. Since all replicas are fully connected, it would be roughly equivalent to establishing mutually authenticated connections, but only requires to authenticate destinations, which seems to be less complicated to achieve.

Sorry, commits are in showed by GitHub in wrong order...

This PR updates with sections of the code that I am not yet too familiar with, but I agree with the functionality that it introduces. But I am not sure I understand how the alternative approach to mutual authentication would work. If each process would only be able to receive data from the destination it connects to, wouldn't it be necessary to establish two separate connections between each pair of processes? In any case, I think the way it is implemented in this PR is the way to go.

@jcs47

This PR updates with sections of the code that I am not yet too familiar with, but I agree with the functionality that it introduces.

I would be grateful if you could also have a deep look and leave detailed feedback.

If each process would only be able to receive data from the destination it connects to, wouldn't it be necessary to establish two separate connections between each pair of processes?

Yes, each pair of replicas anyway establish cross-connections to each other. If just the connection destination is authenticated then two unidirectional cross-connections virtually provide a mutually-authenticated bidirectional channel.
The only difference from a truly mutually-authenticated channel I can think of is that two independent connections are not automatically bound to each other. So a message passed in one direction would not automatically share the same communication context with messages passed in the opposite direction. Do you think this difference might have some effect in our case?

In any case, I think the way it is implemented in this PR is the way to go.

I'm still in doubt. It puts an extra requirement onto external code. Implementing mutual authentication doesn't seem as easy as normal destination-only authentication. This added complexity might be error-prone. If there's no good reason to require truly mutually-authenticated channels, as discussed above, I now tend to rather drop the last commit and adopt the alternative approach.

I would be grateful if you could also have a deep look and leave detailed feedback.

One thing that I noticed is that you converted the Replica struct into an interface. I am thinking that this might be provide a much simpler way to achieve the generic connectivity that I was trying to do. It would be a matter of developers creating their own implementation of this object.

The only difference from a truly mutually-authenticated channel I can think of is that two independent connections are not automatically bound to each other. So a message passed in one direction would not automatically share the same communication context with messages passed in the opposite direction. Do you think this difference might have some effect in our case?

None that I can think off. I just wonder if this approach does not create too many file descriptors, specially with dozens of peers. Is this approach supposed to be more efficient at the cost of more resources?

I'm still in doubt. It puts an extra requirement onto external code. Implementing mutual authentication doesn't seem as easy as normal destination-only authentication. This added complexity might be error-prone. If there's no good reason to require truly mutually-authenticated channels, as discussed above, I now tend to rather drop the last commit and adopt the alternative approach.

I don't think this is a huge downside, but if the alternate approach does not fundamentally change how the connectivity is used, maybe it worth going for it.

I just wonder if this approach does not create too many file descriptors, specially with dozens of peers. Is this approach supposed to be more efficient at the cost of more resources?

The approach (of unidirectional authenticated cross-channels) assumes each replica would still connect to each other only once (no additional connection when handling incoming ones). Only the direction of message flow would change so that the peer messages come from an authenticated connection target rather than from an unauthenticated connection source.

As for [RFC] part, I think that some authentication mechanism in minbft might be useful, but this project focuses on a consensus component and it's assumed to be used by more generic products (like blockchain platforms or other distributed computing platforms) which should have more robust authentications on their own. So it's close to "out of scope" at this point.

The actual motivation for this was to better express requirements on the external components. Therefore, the absolute requirement to authenticate the conneciton destination was clearly documented.
It seems also desirable to distinguish client/peer connections at the core level. Consider, we want to reverse the direction of message flow between replicas. (This has its benefits.) Then the ability to distinguish client/peer connections would prevent clients from pretending as a peer replica and receiving messages they are not supposed to see, like requests of other clients embedded in Prepare messages. It would then be up to the external code to find a proper way of distinguishing client/peer connections, depending on the use-case requirements. For example, it could use mutual TLS, or separate networks, or maybe even no enforcement.
The RFC part considers requiring the external code to provide precise mutual authentication between replicas. Now, I think it would, indeed, be an excessive requirement. Mutual authentication seems to be the only choice if we cannot establish a connection back, like in a client-server architecture where clients might not have public network addresses to connect to. But in our case, replica are always interconnected in both directions. So one-side authentication seems to be enough.


Having a pip installable file(like requirements.txt) that can be used directly(without installing pixi or conda) inside docker environment.

Problem description
I use pixi for managing my project dependencies, However, it seems redundant to Install pixi inside a docker container.

docker container is an isolated environment, so installing dependencies is relatively 'safe'
by using pixi in local development, I already have a clean dependency lock file.
it feels difficult Installing pixi in docker using os like alpine
pip freeze > requirements.txt  would only list dependencies in current conda environment.

Feature Request:
Having a pip installable file(like requirements.txt) that can be used a docker environment.
I noticed that in recent version of pixi
'pixi project export' is introduced, however, AFAIK, it only exportx conda environment.yaml files, but I don't want to include conda inside my docker image, same reasons as 1,2,3 listed above.

pixi project export also supports explicit conda specs that don't require a solve and can be installed via micromamba, which is very lightweight. I also started a draft of exporting a pip requirements file in https://github.com/prefix-dev/pixi/pull/2049, but that will only be for pypi dependencies, not conda packages.

pixi project export also supports explicit conda specs that don't require a solve and can be installed via micromamba, which is very lightweight. I also started a draft of exporting a pip requirements file in #2049, but that will only be for pypi dependencies, not conda packages.

Yeah, it is just that it takes some extra effort to install a package manager inside docker container, most importantly, package managers does not do much inside docker.
I was expecting that it might be a little tricky to export a requirements.txt when I am relying on conda dependencies.
I am comfortable switching to pypi-dependencies, but just ouf of curiousity:
Since we can already export conda environment to a requirements.txt by "pip freeze", does that mean it would automatically 'translate' dependencies we installed via "conda install" to pypi dependencies, or it just ignores them?

No it won't @raceychan .
There is likely a more idiomatic way to achieve what you want (not including pixi in the docker image). I recommend you have a look at the Docker example, which shows how to achieve that efficiently.
Let me know how you go 😃 !

No it won't @raceychan .
There is likely a more idiomatic way to achieve what you want (not including pixi in the docker image). I recommend you have a look at the Docker example, which shows how to achieve that efficiently.
Let me know how you go 😃 !

The docker example you provided make more sense than the ones I found, would definitely try it out!


Demo: Images point to offline ngrok instance

Hi Team,
Was just clicking around the demo, and noticed that in the current deployment, all the images are attempting to be loaded from an ngrok instance, which is obviously no longer online / hostname potentially changed after restart.
See:

Just figured I'd bring this to your attention.

Yes for temporary purposes and testing we have done that. We will fix it.

Any update here? It's not just the images, the cart and other AJAX calls fail too.


TGV denoiser

The following code
denoiser = dinv.models.TGV(n_it_max=1000)
sigma = .1
xnoisy = x+torch.randn_like(x)*sigma
xhat = denoiser(xnoisy, sigma)
dinv.utils.plot([x, xnoisy, xhat], `titles=['original','noisy','restored'])

seem to not denoise properly.

Yes, this is because the sigma parameter in the TGV denoiser (and in variational denoisers) are equal to the regularisation parameter when solving min 1/2|Ax-y|^2+lambda*g(x). Something like 10*sigma tends to work well for TGV but it depends on the image.

I see, thanks !


Modified Tip box on min() page for grammar and to match language used on max() page

@shsagir

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


Fix erroneous creation of plots

On branch main-workflow:
After cloning the repository and running build_scenario.py for the first time one network-plot and one empty timeseries plot are shown. With every other run of build_scenario.py two different network plots are shown + the correct timeseries plot.
--> Tasks: 1) Reduce number of network-plots to one plot. 2) Fix empty plot problem

If I run build_scenario there is an error massage that I need to provide an project_dir. If I run build_scenario on projects/example_projects/example_project (with no scenario folder existing) I receive two correct network plots and after this one time series plot... can you confirm?

The problem has something to do with scenario.py calling power_network.to_image(dirpath) in line 275. If this commented out plots appear as expected. So I guess that in power_networkt.py from line 112 the network is stored in fig and than plotted once plt.show() is called in scenario.py line 306. A fix might be to clear fig after to_image was executed.

solved see commit above


perf: use fixed-length arrays for known result sizes

🔗 Linked issue

📚 Description

Using fixed length arrays with direct assignment is very useful for performance when the output size is known. It allows for a constant O(1) as opposed to amortized O(1) like that of Array.prototype.push, which in hot code paths could make quite a big difference given it will not resize itself dynamically internally . This also optimizes its memory efficiency because the engine does not need to allocate more objects than necessary, and the GC has less work to do.

Once again, the ui-templates directory has been left untouched


Issue when using query in a nested observable

When using CRUDRepository.query as a nested observable where the results of the query are converted to an array before continuing. The query should have been run 77 times, but every time it stopped after 45.
Additionally this issue only occurred when parameters were specified, there were no issues with an empty query
Code:
    let opportunities = await oppCollection.query(         {         _jobId: job._id,         }).toArray().toPromise();

@nbarnett did the observable close? Or just hang?

I'm pretty sure what was happing was that it would complete one query and then hang when trying to start the next one

I have managed to reproduce this bug.
When running 100 simultaneous queries, the code which checks and closes the stream throws an exception. Which is likely to cause unexpected behaviours with the result stream.
MongoError: Cursor not found, cursor id:<PHONE_NUMBER>10
    at Function.MongoError.create (/usr/src/app/node_modules/mongodb-core/lib/error.js:31:11)
    at /usr/src/app/node_modules/mongodb-core/lib/connection/pool.js:483:72
    at authenticateStragglers (/usr/src/app/node_modules/mongodb-core/lib/connection/pool.js:429:16)
    at Connection.messageHandler (/usr/src/app/node_modules/mongodb-core/lib/connection/pool.js:463:5)
    at Socket.<anonymous> (/usr/src/app/node_modules/mongodb-core/lib/connection/connection.js:339:20)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at readableAddChunk (_stream_readable.js:176:18)
    at Socket.Readable.push (_stream_readable.js:134:10)
    at TCP.onread (net.js:551:20)


Changelog generation broken in tag mode

Splitting https://github.com/relekang/python-semantic-release/issues/109#issuecomment-586504170 off into a separate issue.
I'm having some trouble getting release notes to publish to GitHub. Here's the relevant section from the debug log:
Updating changelog
New release published
Wed, 12 Feb 2020 23:34:00 GMT semantic_release:hvcs 'get_hvcs: hvcs=' 'github' +7.1s
Wed, 12 Feb 2020 23:34:00 GMT semantic_release:history:logs 'generate_changelog("0.4.0", "1.0.0")' +7.1s
Wed, 12 Feb 2020 23:34:00 GMT semantic_release:history:logs 'markdown_changelog(version="1.0.0", header=False, changelog=...)' +4.2ms
Wed, 12 Feb 2020 23:34:00 GMT semantic_release:hvcs 'post_changelog(owner=AlphaMycelium, repository=numunit, version=1.0.0)' +4.4ms
Wed, 12 Feb 2020 23:34:00 GMT semantic_release:hvcs 'get_hvcs: hvcs=' 'github' +71.75us
Wed, 12 Feb 2020 23:34:00 GMT semantic_release:hvcs:github 'listing releases' +0.0us
Wed, 12 Feb 2020 23:34:01 GMT semantic_release:hvcs:github 'response #1, status_code=201, status=True' +235.7ms

The created release does not contain the Markdown changelog but instead just the version number.

This is strange, because the API is returning 201 Created yet the release doesn't actually appear.

This only happens when version_source=tag. I think it's something to do with creating and pushing the tag before the release, compared to creating the tag directly through the release API as when version_source=commit.

Found the cause of this bug. When version_source=tag, no new commits are created containing the version number. So, during generation of the changelog, we skip straight over where the version begins:
https://github.com/relekang/python-semantic-release/blob/e427658e33abf518191498c3142a0f18d3150e07/semantic_release/history/logs.py#L108-L111
Therefore the generated changelog is blank and GitHub replaces it with the tag message automatically.

I thought that was working for a second, but apparently not :confused:. I guess someone more experienced will have to work on this.

Any movement on this? I'm switching our CI to us semantic-release version with the tags option to avoid pushing commits from the pipeline. Currently, this defect means I'll just lose changelog generation. Not the end of the world, but not ideal either.


Not allowed create job if integration is disabled

What happened:
When we apply any job from an integration (JobSet, MPIJob, etc) with a local queue specified in the metadata.labels section and this integration is disabled in the queue controller configuration, we can see the uncontrolled behavior of creating / deleting jobs.
What you expected to happen:
When applying a job with kueue.x-k8s.io/queue-name label, get an error saying that integration is not enabled
How to reproduce it (as minimally and precisely as possible):

Deploy Kueue controller manager with default configuration
Deploy Jobset controller manager
Create local queue
Apply one of JobSet examples with defined kueue.x-k8s.io/queue-name label

Anything else we need to know?:
Environment:

Kubernetes version (use kubectl version):
Kueue version (use git describe --tags --dirty --always):
Cloud provider or hardware configuration:
OS (e.g: cat /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

/assign


Night Vision does not function properly

Describe the bug
IrvinSoSerious, Mallycakes
I seem to be having some issues getting night eye working, as it is right now it doesn't seem to do anything other than make my vision a little blurry, not sure how to fix this
With ENB off its red with it on it does what I described
To Reproduce
Expected behavior
Screenshots
Modlist version
1.5.2
Did you add any additional mods?
no

NightEyeENBFix.esp must be disabled in case if ENB is disabled >> added to README
Fix for when ENB is enabled would be included in next version after v1.5.3


Added support for symbolic file links

Resolved / Related Issues
Items resolved / related issues by this PR.

Closes #6995

Details of Changes
Add details of changes here.

Adds basic support for symlinks (the ones generated by e.g. > mklink dest_file.txt source_file.txt. Currently treated as Shortcut files.

Validation
How did you test these changes?

[x] Built and ran the app

@gave92 if you open the shortcut properties it won't let you use the Ok button:

I guess shortcut properties should be only readable since the symlink can't be modified at the actual state. Hopefully that will also fixes the issue.
I mean, those fields should be read-only:

I mean, those fields should be read-only

Totally agree, explorer does the same. Just did not want to do UI things in this PR =)

EDIT: Okay, this seems to be also on main with normal shortcuts, so it's not related to this PR.

Ouch, I'll look into this if I can

/azp run

@gave92 now it's not compiling because ItemNameRaw is not defined:

BTW, I don't know what pipeline failed since I didn't have any issue while compiling lol.

You still need to merge main (it's defined on main)

Ok, should be good now.


As an operator, I can disable/enable resurrection based on rules

Latest resurrection config is used to get resurretion rules for the health monitor
Rules are updated each 60 secs
Resurrection rules are applied based on deployment names and instance group names
Information about request to recreate/no request is stored in the logs
#135955231
Signed-off-by: Konstantin Maksimov<EMAIL_ADDRESS>

@mikexuu Code updates are done. Could you please have a look one more time?

Hi @barthy1,
We talked about this internally and we want to drop the nested options has from the resurrection rules and flatten the properties to be top level:
---
- enabled: true
  include: ...
  exclude: ...

Is there any chance you could make this change?
Best,
@jfmyers9 && @monkeyherder, CF BOSH

Hi @jfmyers9 && @monkeyherder, following your comments code is updated. Could you please have a look again?


Add type='button' to buttons in system console, to prevent unintentional button clicks

Summary
Add types to buttons in admin_console, so that actions are not unintentionally triggered.
Ticket Link
https://github.com/mattermost/mattermost-server/issues/15682
Jira ticket: https://mattermost.atlassian.net/browse/MM-29178
Related Pull Requests
None
Screenshots
None

@outofgamut thanks for contributing!

@hahmadia Thanks for the feedback! It looks like the tests are failing. Anything I need to do on my end to update those snapshots?

@outofgamut
Can you run npm run updatesnapshot in your web-app directory and the push those changes? Let's see if that solves the problem. Thanks!

/update-branch

This will require testing throughout the system console

@mickmister Heads up that there is a merge conflict to resolve

/update-branch

Error trying to update the PR.
Please do it manually.

@mickmister
Any advice for how to QA this particular PR? I'm not even sure how this PR should be properly QA'ed. Thanks!

/branch-update

/update-branch

@hahmadia I've put some qa test steps in the Jira ticket https://mattermost.atlassian.net/jira/software/c/projects/MM/issues/MM-29178 Feel free to ask me any questions

Thank you for the test steps @hahmadia and @mickmister! I tested the said form in the environment/web_server page as well as a couple other forms in admin console that I could recognize.
@mickmister Do you suspect this PR could break any cypress tests at all? Wondering if I should keep an eye out on the E2E tests as well.

Do you suspect this PR could break any cypress tests at all? Wondering if I should keep an eye out on the E2E tests as well.

@prapti I don't think it would break them, as we are just adding an attribute to the buttons. I'd be very surprised if any existing document element queries in the cypress tests are affected. The only tests I can think would be affected are snapshot tests, which have been updated in this PR.


Corrected the Create Channel Registration, added screenshot for Streaming Endpoint and Web Socket

as the Channel Registration is now deprecated, corrected title of a section and some content that still has channel registration.
added also screenshot for enabling web socket and streaming endpoint

@patrickfarley Could you review the updates for the content team? The new image files and updates MD file can't be merged as they are; the file names, highlighting, and Markdown references need to follow the quality standard that are described in the internal contributor guide.
Thanks!

@MariaVrabie Please update file names https://review.docs.microsoft.com/en-us/help/contribute/file-path-guidelines?branch=master
and screenshots https://review.docs.microsoft.com/en-us/help/contribute/contribute-how-to-create-screenshot?branch=master
Since you're internal, it'll be easier if you create the PR against the azure-docs-pr repo instead

#please-close


Fix typos in cluster.yaml comments regarding volumeMounts

A few incorrect variable names were found lingering in the volumeMount set-up section of cluster.yaml (https://github.com/coreos/kube-aws/commit/1b37b13567135b48538b51f1968d0ce5bf246882).
Apologies for any inconvenience.

Good catch! Thanks for the follow up @jollinshead :+1:

Codecov Report

Merging #374 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #374   +/-   ##
=======================================
  Coverage   38.64%   38.64%
=======================================
  Files          29       29
  Lines        2280     2280
=======================================
  Hits          881      881
  Misses       1281     1281
  Partials      118      118

Continue to review full report at Codecov.

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


GET RID OF assertr/assertthat???
maybe later:
replace tidyverse/dplyr with data.table to be fast???
OR do we do everything in matrices inside? --- what's faster?

mostly done -- pared things down to dplyr, rlang, cli


Bring PR up to date with ethereum-optimism/superchain-registry:main

activates genesis allocs validation test
adds optimism config

hi @geoknee
I would love to engage in your team


jetty jars /version

Hi, I tried to run.
What version of jetty jars do I need?
What jars?
Cheers

Hi
I have added the section "Starting HtmlSpeed" to the README file.
You will find the answer there.
In a few days from now I will add a complete ready-to-run example.
In the meantime you can package all Java source files in a war-file and
create the directory "htmlspeed" under Jetty home-directory, In that
directory you should place the properties.txt file and all other configuration files.

I got it, it's a war w/ a servlet, not jar. Any reason it would not work w/ Jetty 9?

Now you can download a ready-to-run example.
Read the "Example" section in the README file.


[FrontEnd] Update Chart.js

undefined

The FrontEnd built on HTML, CSS and Javascript has been essentially replaced by Streamlit.
Heretofore, the frontend didn't require any python modules expect from API calls.
We now want to implement Streamlit in a very primordial form.


Support "Cascading/Inheritable" Writes

Problem
Consider a tree of Object subclasses:
Client
    Project
        Job
            Version

Each object is complex, with many properties and relationships. The user can delete any object at any time and all descendent objects should be deleted as well.
Because each object's deletion flow must be carefully customized to cleanup all side-effects, we would logically have methods that specialize in each operation:
func deleteClient(_: Client) {...}
func deleteProject(_: Project) {...}
func deleteJob(_: Job) {...}

When we delete, say, a Client, we also need to delete all the Project, Job, and Version objects underneath that client. The problem is that we can't simply re-use these methods because we can't open a write transaction while we're inside another write transaction—we can't "inherit" the open write transaction.
Solution
I'd like the ability to piggyback on an open write transaction, if there is one, and create a new transaction otherwise. Something like this:
@discardableResult
    public func cascadingWrite<Result>(withoutNotifying tokens: [NotificationToken] = [], _ block: (() throws -> Result)) throws -> Result
    {
        var didOpenWrite: Bool = false
        if !isInWriteTransaction {
            beginWrite()
            didOpenWrite = true
        }

        let ret: Result
        do {
            ret = try block()
        } catch let error {
            if isInWriteTransaction && didOpenWrite { cancelWrite() }
            throw error
        }

        if isInWriteTransaction && didOpenWrite { try commitWrite(withoutNotifying: tokens) }
        return ret
    }

This API would grant a lot of flexibility for situations where cascades are necessary.
Alternatives
There are two alternatives:

Repeat the deletion logic for each lower-level object in the deletion function for the higher-level objects. Disaster waiting to happen.

Manually re-implement what I put above, either with an extension on Realm or by sticking the same code around each write in the deletion functions for everything but top-level objects.

How important is this improvement for you?
I would like to have it but have a workaround
Feature would mainly be used with
Local Database only

Alternately, if there's something that's going to blow up about my approach above, I'd love to know that as well. There's a little extra overhead involved in capturing all the blocks, and you could certainly end up with a write transaction that has 700 billion operations in it if you abused this, but that's no different than abusing any other API.

I am probably misunderstanding the intent here, so a question: this seems more relationship than subclass to me. Is the setup "Consider a tree of Object subclasses:" where each object is an actual subclass of the object above it?
class Client: Object {
... some client properties
}

class Project: Client {
... some project properties
}

class Job: Project {
... some job properties
}

class Version: Job {
... some version properties
}

so Job inherits properties from Project and Client and Object?

@Jaycyn No. Each of the tree levels is a direct subclass of Object.

Ah! Make way more sense then. Thanks for the clarification on that part.
When we delete, say, a Client, we also need to delete all the Project, Job, and Version objects underneath that client.
What does 'underneath' mean in this use case - as in related objects? For example, is this how the client model is set up?
class Client: Object {
@Persisted var relatedProject: Project!
}
If so, when the client object is deleted, you want to cascade delete the relatedProject object as well. Correct?

@jaycyn that's correct. The client owns projects, which own jobs, which own versions.
Any one level can be deleted directly and, when that happens, all lower levels need to be deleted as well. But because each level is complex, with many side-effects to clean up (e.g. jobs hold other objects that must be deleted), I have a dedicated function to delete each type.
I want to re-use those functions when I delete higher-level objects. For example, when deleting a Client I would simply invoke my deleteProject function, which in turn would invoke deleteJob, and so forth. This lets me re-use the deletion code for each level.
When the deletion functions are called as part of the "cascade", they will use the existing open write transaction. When I call the deletion function directly and there is no open write transaction, they'll open a new one.

We've explored the cascade delete process a number of times but I don't think that's a single feature that could be added that would work across the board.
In one of our larger projects we have something similar where removing an object should also remove corresponding objects as one should not exist without the other. These objects are complex with dozens of properties and relationships.
For our case we simply pass the realm that's in a write 'state' to our function to clean up the parent object, before then deleting the parent object. I am sure you have worked through this but it wasn't really a lot of code so I thought I'd throw it out there. This is kinda like the alternatives you mentioned.
Here are 4 sample objects where each rely on the existence of it's "parent" object. e.g. a Version cannot exist without it's "Parent" Job etc
class Client: Object {
    @Persisted var clientName = ""
    @Persisted var relatedProject: Project!

    //this code could just be within the calling write.realm but wanted to put it here
    //to have the a parent object responsible for cascade deleting it's "child" objects
    func cascadeDelete(fromRealm: Realm) {
        fromRealm.delete(relatedProject.relatedJob.relatedVersion)
        fromRealm.delete(relatedProject.relatedJob)
        fromRealm.delete(relatedProject)
    }
}

class Project: Object {
    @Persisted var projectNumber = ""
    @Persisted var relatedJob: Job!
}

class Job: Object {
    @Persisted var jobLocation = ""
    @Persisted var relatedVersion: Version!
}

class Version: Object {
    @Persisted var versionInfo = ""
}

then the code to delete the client (and in turn delete all of the objects relying on that parent object) is
let client = realm.objects(Client.self).first! //get the client
try! realm.write {
    client.cascadeDelete(fromRealm: realm)
    realm.delete(client)
}

One of the points in the question was:

we can't open a write transaction while we're inside another write transaction

but doesn't doing it like the above avoid that issue altogether?
Why code for opening and committing write transactions when the delete can be accomplished within a single write or does your use case prevent that.
On that note, per your feature request, you could just use an extension and roll all the cascade delete code into that - that makes deleting a client a one-liner.
extension Realm {
    func cascadeDelete(client: Client) {
        try! self.write {
            self.delete(client.relatedProject.relatedJob.relatedVersion)
            self.delete(client.relatedProject.relatedJob)
            self.delete(client.relatedProject)
            self.delete(client)
        }
    }
}

call with
        let client = realm.objects(Client.self).first!
        realm.cascadeDelete(client: client)

The point of my suggestion is to let the deleteJob() function be flexible. I can call it DIRECTLY and it'll open a new write transaction to delete a single job. Or, I can call it INDIRECTLY (from within the deleteProject() function, where I need to delete all the jobs in that project) and it will use the existing open write transaction that deleteProject() opened.
Rationale:
I suggested the API addition for two reasons:

to make sure there's not a footgun here that I don't see.

I don't like extending third-party APIs if I can avoid it; I prefer to use officially supported approaches.

There's two core reasons why we stubbornly require explicit write transactions rather than just letting you write at any time:

Beginning a write transaction has to refresh the Realm. Doing this implicitly in the middle of your code would be surprising, and more importantly would make a lot of code subtly incorrect. A very simple example would be that running obj.foo = obj.foo + 1 on multiple threads at once could lose writes due to incrementing from stale reads, while realm.write { obj.foo = obj.foo + 1 } guarantees that the read is always of the latest value.
We really want you to do batched writes. Our writes have enough per-transaction overhead that we really want to discourage putting a write inside a loop, or even just doing several writes in a row without a loop which could be combined.  In addition, atomic transactions make a lot of correctness problems around seeing partially written state go away. In an app using a local Realm this is mostly a problem if your app happens to crash after committing an inconsistent state before it can then commit the final state, but when sync gets involved it gets spicy.

The approach you're taking is the sort of thing we're trying to discourage for the second reason. If you have two Jobs, it'd be perfectly natural to just write deleteJob(job1); deleteJob(job2) and perform an extra write transaction. If deleteJob() instead required you to call it in a write transaction, you'd probably write realm.write { deleteJob(job1); deleteJob(job2) } instead of realm.write { deleteJob(job1) }; realm.write { deleteJob(job2) }. We originally didn't even have isInTransaction because we had the idea that there should be a total division between the code managing transaction state and code doing actual mutations and if you structure your code that way you'll never need to be able to check it.
Ultimately though, this is all just recommendations from our perspective and not rules that you must follow or the Realm Police will arrest you. If you don't have trouble remembering that two adjacent calls to a delete function should be manually wrapped in a write block even though it'll work without it, then you should feel free to write the more elegant code, especially if having one of the deletions run but not the other isn't a meaningful correctness problem in your specific scenario and it's just some slightly suboptimal code. Our SwiftUI stuff even has a similar function, although that should not necessarily be taken as an endorsement of it being a good idea.

@tgoyne I may not be explaining my approach clearly. Batching operations in a single write transaction is EXACTLY what I'm doing here.
I'm trying to make the function flexible enough that it can either be called directly to delete a single object, OR it can be called during the deletion routine of a parent object and inherit that parent function's already-open write transaction.
I'm explicitly minimizing the number of write transactions.

Here's an example of where I'm using this technique. When I delete ScopedCueFlag objects from my Realm, there is a side-effect I must manage: Map is the only Realm collection that doesn't auto-clean itself, so I must go find all Map<String, ScopedCueFlag> collections that contained this flag and remove the keys that were assigned to the value.
This logic is encapsulated in deleteCueFlags().
Now, sometimes I need to just delete flags directly: the user clicked a "delete flag" UI command. Other times, (such as in the code pane on the left in my screenshot) I need to delete the flags as part of a larger operation where I'm modifying/deleting the objects that "own" the flag objects.
I don't want to repeat the deletion logic; I want to be able to call deleteFlags() and have it ask, "Is there a write transaction already open? Yes? Okay, use that transaction. No? Okay, open a write transaction."
Bottom Line:
This "cascading write" approach is working well for me and I think it ought to be an official part of the SDK.

Another Way To Think About It
Right now, if you call write() while in an open write transaction, Realm throws an exception instead of just making it a no-op and piggybacking on the write transaction that's already open. That seems...weird:
"You can't possibly write right now! We have to be PREPARED to write!"
"Aren't you already prepared to write from this other thing I'm writing?"
"Yes."
"Well...could you maybe just write this stuff, too, without pitching a fit about it?"
"No."
(I'm sure there's edge cases.)

The reason for the behavior above is to ensure the durability aspect of ACID. Imagine the following code:
func updateName() {
    realm.write {
        person.name = "Peter"
    }

    // We've committed a write - we should be confident this is persisted
}

func updateAddress() {
    guard addressNeedsUpdate else {
        fatalError("updateAddress was called when update is not needed")
    }

    realm.write {
        person.address = "some new address"
    }
}

// somewhere
realm.write {
    updateName()
    updateAddress()
}

Since updateName is now called inside another write transaction, it will not actually do a commit at the end of the write, meaning that if you then triggered an update to an external system, you'd be in an inconsistent state since updateAddress has the potential to crash the process and revert the name change. While there are scenarios where this may be fine, we can't make that decision in a general-purpose way. If the cascadingWrite extension fits the needs of your application, that's great and you should by all means continue to use it, but we don't plan to add it as a first-party method at this point because we feel the complexity involved of making it general-purpose are too much right now. We do have this (fairly stale) ticket tracking adding support for checkpoints/subtransactions. The folks on the Core team lay out some of the considerations around this problem, but it hasn't garnered sufficient interest that would justify prioritizing it.
I'm going to close this issue as the approach here is similar to that in https://github.com/realm/realm-swift/issues/2502 and in both cases, real support for nested transactions will require a fair amount of Core work, which is tracked in https://github.com/realm/realm-core/issues/1149.

@nirinchev That makes sense! To confirm: is there a point at which a single write transaction becomes too large?
Obviously there's some point where we run out of RAM, etc. but is there a practical guideline for how many changes should be included in a single write before it's better to batch that write into several pieces? With my approach here, I can end up with 10,000+ changes in a single write. I'm unclear how that translates to sync changesets and whether there's a point where I might create a changeset that's too large to function performantly if I use these cascading writes.

We don't have some very strict guidance here, but as a rule of thumb, you probably want to avoid making changes to more than a few thousand objects in a single transaction when using sync. I'm not sure how easy it would be to do with the cascading write approach short of adding some change tracking logic to it - perhaps if you're looping over objects at the top level, you could inject code that does commitWrite+beginWrite every x iterations.

@nirinchev got it, thanks! Just to clarify: is there a difference between "changes" and "deletes"? The only time my app can potentially touch a huge swath of Objects in one transaction is if a user deletes a top-level model entity that has many descendent children, grandchildren, etc. (The root object in a branch of the OutlineView, essentially.)
Do deletes count as "changes" for the purposes of this advice?


Introduce Options Menu component

We require an options menu that is similar to a Dropdown, but is used to select among groups of options rather than to trigger an action. This is required for toolbar features like sorting or Items per Page selection, and may have general use elsewhere. Visual designs can be seen as part of the Toolbar work here: https://redhat.invisionapp.com/share/67PFEYCRWZF#/335107769_V2_Toolbar_-PDF-
It should be possible to open the menu from a labeled button or an icon button (as shown for Sort referenced above). This may be considered as a new variant of a Dropdown or a new component.

@LHinson @rachael-phillips This is something that we should get on the roadmap as a requirement for the toolbar.


refactor: inline Copy component

Related #1156
Related #1174
This PR inlines the Copy component in CopyButton and CodeSnippet. There should be no breaking changes. This should be merged before deleting Copy entirely.

Released in v0.62.0


Export styling: Right-align the em-dashes

Minor styling issue, not a release blocker: Noticed that the em dashes we use in exports when no value was entered, is centered instead of right-aligned to match the rest of the column. (We right-align everything in the web view as well.)

Em dashes look good!