Add Flux plugin

[ ] I added a CHANGELOG entry for this change.
[ ] I adjusted the corresponding documentation for this change.
[ ] I adjusted the values.yaml file and the documentation for all values.

Codecov Report

Merging #345 (4e05031) into rework-kobs-architecture (ac543b3) will decrease coverage by 0.53%.
The diff coverage is 10.60%.

@@                     Coverage Diff                      @@
##           rework-kobs-architecture     #345      +/-   ##
============================================================
- Coverage                     47.01%   46.48%   -0.54%
============================================================
  Files                           124      126       +2
  Lines                          8871     9003     +132
============================================================
+ Hits                           4171     4185      +14
- Misses                         4615     4733     +118
  Partials                         85       85

Impacted Files
Coverage Δ

plugins/plugin-flux/pkg/sync/sync.go
0.00% <0.00%> (ø)

plugins/plugin-flux/cmd/flux.go
17.94% <17.94%> (ø)

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 ac543b3...4e05031. Read the comment docs.


Improve the logout flow

This PR makes a couple of improvements to the logout flow, as mentioned in #1821.
Previously logging out happened by means of a GET request which in would technically count as a CSRF vulnerability. This PR changes the HTTP verb to POST to prevent fix this.
Because of this, I expanded the <x:filament::dropdown.item> component to allow form tags, which will render an inline form with a single submit button.
Additionally I added a LogoutResponse class with corresponding interface to allow users to modify the logout flow slightly. This still requires a redirect and by default redirects you to the login page.
This is useful for when the application has a custom authentication flow that doesn't rely on Filament's, for example when OAuth2 is being used.

Thanks!

Thanks but what about logout link on this widget view?
resources/views/widgets/account-widget.blade.php
GET route is removed so this logout link throws exception:
The GET method is not supported for this route. Supported methods: POST.

Good point.

Opened a PR to fixed account-widget.blade.php.


Fixed a bug because % doesn't behave like mod with negative numbers.

It cause reach orientation to choose the long rotation over the short rotation under some circumstances.

Thanks, you're right. :+1:
Just added the method wrapAngleAroundZero to the ArithmeticUtils class that fixes this issue without using the double modulo which is somewhat expensive. Apart from rounding errors, it should yield the same results.

No problem. I'm using extensively this library and it's really great. Unfortunately, I extend your library using Scala so I'm not able to contribute a lot :/


Fields with numbers - use dropdown instead of up/down arrow

Number UI (up/down arrow) is confusing and has a small touch target. This can occur both for admins (e.g. when trying to set minimum/required # of choices) and for applicants (e.g. when trying to select how many dependents they have).

Agree with removing the up/down arrow but don't see a need for incorporating a dropdown for number fields. Users should be able to accessibly enter a number without the use of a dropdown.

GOV.UK recommends against using <input type="number"/>, because it comes with various accessibility issues. Instead, it recommends this: <input type="text" inputmode="numeric" pattern="[0-9]*">
https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/
Thoughts?

Removing the stepper styling can be achieved with some custom CSS (https://www.w3schools.com/howto/howto_css_hide_arrow_number.asp). Note that Tailwind doesn't have any easy-to-use selector for disabling these controls right now.
I'm certainly open to the pattern of using inputmode="numeric". One note is that it appears that all of the accessibility issues from the article are marked fixed as of now. I believe the remaining benefits described in that article would be:

Browsers discarding non-number input
Scrolling would no longer increment the number

I don't think there's an easy decision here without tradeoffs. One could argue that scrolling to increment could be a benefit in use cases where the number field actually represents a number.
My inclination right now would be to start by visually removing the stepper control as @rahaghas described above. I'll defer to others as to whether we want to switch to type="text" inputmode="numberic".

Spoke with @rahaghas, who mentioned that type="text" inputmode="numeric" would likely be preferable from a UX perspective as well. As such, I'll likely revert the stepper change and instead convert all type=number fields to follow this pattern.
Estimated effort: <1 hour.

Updated estimate: 1 day
We have several parts of the code that assume that we've rendered form values with input[type="number"] and don't perform proper validation (example). These are existing tech debt that would benefit from server-side validaton. Additionally, our browser test scaffolding will need to be updated to disambiguate number inputs from id inputs (code).
Neither of these is large on their own, but I'll also need to audit for other cases where we might rely on this type.

This may actually be more complicated on the admin side. Presently, we don't have any patterns for per-field validation other than top-level messages. Fixing that up would definitely be nice (and likely part of our larger effort of improving the Admin UI). However, it also increases the scope of this quite a bit. I might file a separate issue for that work (and have it prioritized accordingly). Here, we can add a distinct FieldWithLabel.numeric helper for the new number input mode we want that is applicant-facing.

MDN documentation states that inputmode=numeric / inputmode=decimal might not show the minus key (https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode). This is be problematic if we want to accept negative numbers as input. Given this and the above, I'm not sure if switching to the pattern described will buy us much over what we currently have.
@rahaghas Do you have any thoughts on keeping these inputs as type="number"?

Spoke with @rahaghas. Given the above comments, we're going to stay with input[type="number"] rather than switching to inputmode=numeric.
As such, the work here is complete.


STIX flare list

I wonder if there'd be scope to include a way to search for the STIX flare list? https://pub023.cs.technik.fhnw.ch/view/flares/list

I think one that stabilises after we are in nominal we could so something for sure.


Adds memcached

Allows to use memcached to enable caching using dalli.

Have you tried building a fresh ansible box and standing up a simple rails app from this branch?
I have been using this repo to test smashing_boxer since we currently don't have any automated testing
https://github.com/BrandonMathis/vanilla-rails-app

No, but I did use it on malartu by running everything

@leonelgalan ansible-galaxy this dude :+1:

@leonelgalan what is the status of this pr. Do we still want to merge?

Needs rebase.

I just installed weaveup on my server (weaveups new dev) using this, works like a charm! :neckbeard:

doesn't memcached need to be restarted after every deploy?

No, you will destroy the cache that way. It might need, but that's up to the developer.


Shaka streamer input media from s3

Hi,
we actually using AWS trasncoding service for our application. In some cases we don't need a managed service for like on-premise setup. so we want to use shaka streamer to package the media input into multiple formats(360p,720p,etc). how to take input dynamically. not like to define static media name and path in input_vod_config.yaml. Is there any way to done that? input from s3?
*sorry for my english.

If I understand you correctly, you'd like to get input from S3 instead of a local file.  Is that correct?
How would you want to access the input from S3?  Via URL, as in "http://bucket.s3.amazonaws.com/foo/bar.mp4"?  Or via some other mechanism?
Would you need this access method to provide credentials?  Or would the input content be publicly accessible from your S3 bucket?

Also, do you really need to use Shaka Streamer if you already have an AWS transcoding service?  What Shaka Streamer does is run ffmpeg to transcode for you, then feeds that into a packager.
If you don't need transcoding, you probably don't need Shaka Streamer.  You might be interested in Shaka Packager, which takes your transcoded files, encrypts them, and produces the DASH manifests & HLS playlists.
Does this help?


[ASGenerator] Improved Assign statement to var

@Neverbirth please review this PR and merge

What about this?

I want to check in depth some parts of it :/. I think it will get fully reviewed by the end of tomorrow.

Ok, thanks

what's up

@Neverbirth Thanks

@SlavaRa The changes to ASComplete in this PR broke some stuff... for example trying to resolve some class is returning std\Class.hx instead of the class itself.

If it was not clear, I mean something like having
function test(class:Class<Dynamic>) {}

test(SomeClass);

SomeClass resolves to Class, not to SomeClass.

@Neverbirth thanks, I will fix it in the near future

@Neverbirth Could you create issue?

Done.


Make a Custom Data Consolidator Which Used Time-Value Only as FallBack

If ResolveConsolidator has no matching consolidator found which better suits the data type provided, use a BaseData consolidator which used only Time-Value which will be provided by the custom data itself.
This way indicators can be universally applied to any data types which implement BaseData.

This was handled with the addition of the BaseDataConsolidator for issue #12


Add link to vision_msgs_examples

These are not (yet?) owned by ros_perception, so a tiny tad harder to find.

Thanks!


global_farm.add_stake could add 0 stakes to the global farm while the valued_shares are non-zero

In the functions update_yield_farm_multiplier, resume_yield_farm and do_deposit_lp_shares, when adding the valued_shares to the global farm, it is not assured that math::calculate_global_farm_shares(yield_farm.total_valued_shares, multiplier) returns a non-zero value when yield_farm.total_valued_shares is non-zero and multiplier is ensured to be no less than MIN_YIELD_FARM_MULTIPLIER.
For the functions update_yield_farm_multiplier, resume_yield_farm, shares could be withdrawn beforehand to bring the total_valued_shares below the global_farm.min_deposit.
As for the function  do_deposit_lp_shares, the following checking
https://github.com/galacticcouncil/warehouse/blob/b67141958f31fc3af0894a22b5534a26e67f6334/liquidity-mining/src/lib.rs#L1357
won't guarantee the valued_shares  calculated at
https://github.com/galacticcouncil/warehouse/blob/b67141958f31fc3af0894a22b5534a26e67f6334/liquidity-mining/src/lib.rs#L1374
to be no less than global_farm.min_deposit since the spot price of the deposit token could be any value.
Thus, it is recommended to add the check ensure!(valued_shares >= global_farm.min_deposit, Error::<T, I>::InvalidDepositAmount); before depositing the valued shares to the global farm.
This checking could be wrapped with the call to math::calculate_global_farm_shares into an internal function add_stake_to_global_farm to encapsulate the stake-adding logic as a whole.

Though it might be acceptable to ignore small deposits to the global farm, i.e., the result of math::calculate_global_farm_shares(valued_shares, yield_farm.multiplier) is rounded to 0, it is not feasible in the current implementation when the valued_shares are subject to price manipulation risk.

In the fix #189 , the "add 0 stakes to global farm" issue is addressed in do_deposit_lp_shares, but not in the functions update_yield_farm_multiplier, resume_yield_farm. It seems there is no better way of addressing this issue in the latter cases. It also does not violate any design intentions at this stage.
This fix is acceptable so far. Thank you.


Remove smart space after punctuation in numbers (e.g. in "10.99")

Smart space after punctuation should be removed if the characters preceding and following the punctuation are both numbers.

Related to #127

Implemented using punctuation exceptions in default chord dictionaries.
A small downside of this implementation is that if a sentence ends in a full stop and the next sentence starts with a number (Preceding sentence. 20th century was...), a spacebar needs to be explicitly pressed before the number.
There could be a more robust implementation but unless people will be running into issues with this, I'm inclined not to overcomplicate the system.

Implemented more robustly using approach described in #186 (and removed the . 0 styled replacements from chord dictionary).


File not found:'texture_data_FLAME_256.npy'

Thank for your work!
I can't find "texture_data_FLAME_256.npy"
I only have "FLAME_texture.npz". Does "texture_data_FLAME_256.npy" come from FLAME_texture.npz?

Thanks for the bug report. The texture model of FLAME is available separately - here - https://github.com/TimoBolkart/TF_FLAME. I have modified the read me accordingly. Note also that I have renamed the file to be  - texture_data_256.npy as that is the default download name.

FLAME_texture.npz

where to download "FLAME_texture.npz"?


Improve control of content onCopy

Do you want to request a feature or report a bug?
Feature
What is the current behavior?
Currently there is no way to manipulate content before being copied to the clipboard. We are currently hacking the Editor instance to override the onCopy handler but this is not ideal.
What is the expected behavior?
Ideally, we could set the text/html that is copied to the clipboard and/or manipulate the editor state that is passed into getFragmentFromSelection(). (lib/editOnCopy.js:32)

@sarmstrong This sounds like a great feature to add. Sounds like you currently have something in place to do this, would you be able to create a pull request for it?

Thanks @tylercraft, what I have now is kind of a hack but I'll work on a more formal approach and submit a PR, thanks!

Can you give more details for your hack?  I'm actually in need of something like this but I'm having trouble getting anything to work

We ended up reverting the hack . . . it didn't work. I'm trying to find some time to do a formal pull request. The idea would be to manipulate the internal clipboard data before being set and also giving the option to manipulate the OS clipboard.

@sarmstrong @MrDarkHorse Check out my branch here to see if it it helps. I recreated the way in which Sublime Text will copy/cut the full line of text if your selection is collapsed. The branch has an example included (handleBeforeCutCopy) that shows this working. Just add a few lines of text, then Cmd+C/X on a line with a collapsed selection and then Cmd+V to see the pasted result.
@tylercraft let me know if you'd like me to create a PR for this. Here's a diff of the changes.
I achieved this by providing additional API methods on the Editor component: handleBeforeCopy and handleBeforeCut. But rather than just returning handled or not-handled from these methods, editOnCopy/editOnPaste also check if the return value is an object, using it as the new value for editorState in the remainder of those functions.

Looks good to me. Thanks @ericbiewener! Hope PR gets accepted

This would be really helpful, and I like what @ericbiewener has done! A few thoughts though:
While I agree that it could be convenient to access the editorState in the handleBefore-methods, it's not consistent with how other handlers work in Draft, e.g. handleBeforeInput. If the editorState is needed, it can still be passed (e.g. by currying).
The same is true for the option to return an editorState. It could be really convenient, but it's not how the other handler methods work.
Having said that, a PR would be a good next step! @ericbiewener are you still planning on creating one?

@tobiasandersen I'm also a bit uncomfortable with changing the way these handler methods work. That's partly why I never opened a PR for it -- I was hoping to get some discussion going that would lead to a more appropriate approach. At this point I'm not planning on opening a PR until one of the maintainers shows some interest.

We really need this... the text within an entity is not usually the best representation for copying.  Any insight as to whether this is possible to achieve without forking?

Having the same issue in 2018- would've been super awesome to have a handleBeforeCutCopy!
As it is, it looks like we may have to create our own fork of the codebase just to support just this  single feature

Starting with Draft.js 0.11.0 there are onCopy and onCut props which could be used for the use case suggested here, however they completely override the built-in editOnCopy and editOnCut) behavior. While the logic in editOnCopy is simple enough to replicate, that of editOnCut isn’t – so it would be nice for these to take the direction outlined here, and already implemented in #1757.
In the meantime, it looks like the solution to implement custom logic is something like:
import editOnCut from "draft-js/lib/editOnCut";
import editOnCopy from "draft-js/lib/editOnCopy";

export const onDraftEditorCopy = (
  editor: Editor,
  e: Event & {
    clipboardData: DataTransfer,
  },
) => {
  draftEditorCopyCutListener(editor, e);
  editOnCopy(editor, e);
};

export const onDraftEditorCut = (
  editor: Editor,
  e: Event & {
    clipboardData: DataTransfer,
  },
) => {
  draftEditorCopyCutListener(editor, e);
  editOnCut(editor, e);
};

// [...]

<Editor
  onCopy={onDraftEditorCopy}
  onCut={onDraftEditorCut}
/>

This isn’t that much easier than the snippet from @ibash but does have the advantage of not having extra event listeners that you then have to keep track of and remember to unregister.

Moreover onCopy function is not refreshed. If you try to consume inside the function the editorState you've stored into a State, you are not able to get it: you will get the initial editorState that at function creation time...
Feature is unusable if we've no way to get the correct EditorState


There is no info on what runconfig means? an example or github repo would be useful

Azure documentation issue guidance
Thanks for opening an issue in the Azure technical documentation repository.
We use GitHub issues as the primary channel for customer and community feedback about the Azure documentation.
Creating an issue
We prefer that you create documentation feedback issues using the Feedback link on the published article - the feedback control on the doc page creates an issue that contains all the article details so you can focus on the feedback part.
You can also create a feedback issue here in the repo. If you do this, please make sure your issue lists:

[ ] The relevant Azure service or technology.
[ ] A link to the published documentation article that you have feedback about.
[ ] Clear, specific feedback that the author can act on.

Pull requests and article contributions
If you know the change that is needed in an article, we encourage you to submit the changes directly using a pull request. If the change is large, or if you want to contribute an entire article, follow these guidelines:

[ ] Don't surprise us with a big pull request or a pull request with a new article! Submit an issue that describes the details of the proposed large change or new article.
[ ] Include the service or technology area.

We'll route the issue to the appropriate content team for review and discussion.
Tech support and product feedback
If you would like to contact Microsoft about other things, such as product feedback or tech support, please review these guidelines:

If you need technical support using Azure, the paid and free support options are described here: https://azure.microsoft.com/support/options/.

Each article in the Azure technical documentation contains a product feedback button - it's best to submit product feedback directly from a relevant article. Otherwise, you can submit product feedback for most Azure products in the following product feedback forum: https://feedback.azure.com/forums/34192--general-feedback.

@apraovjr, Thank you for using the documentation feedback channel! I understand that you’re looking for more samples or GitHub repo presumably for Azure Machine Learning service. We notice that you have closed the issue, if you need further assistance on this, kindly provide the associated document that you’re referring to and share more details on your requirement/ scenario for better understanding.


Gomplate to use predefined config

what

Define gomplate config and pass it throught CLI flag to every gomplate invocation
Passing as the very last option to avoid injecting override in the env vars dereferenced later in same command
unset GOMPLATE_CONFIG is not required as CLI option always takes precedence over env var, I tested.

Testing in few repos ATM


Updated readme

Pull request checklist
Please check if your PR fulfills the following requirements:

[x] Build is passing successfully
[x] All tests are passing
[ ] PR is a breaking change (might cause older versions to break)

Fixes issue
Fixes: #11
Pull request type
Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[x] Documentation content changes
[ ] Other (please describe):

What is the current behavior?
#11
What is the new behavior?
Added badges for code coverage, gitter channel, tag and introduced table of contents.
Other information
None

@abhinav78910 Please fix codacy issues. Rest LGTM


Rework Orbit <-> Ephem conversion

This aims to solve #1364, #923, and #921 all at once (risky, I know).
Summary

Simplify sampling of open orbits (refactor)
💥 Orbit.sample no longer emits OrbitSamplingWarning when anomalies are out of range.
💥 States API changed, now elements are passed as a 6-tuple

Old usage will raise "too many parameters" errors

💥 Propagation API changed, now all propagators are classed and must be initialized with extra parameters before they can be used

Old imports might get "module is not callable"

Working on this, I realize it would be cool to have a StateArray @s-m-e, that's the first thing we should extract from gh-1491 and gh-1492. Leaving a comment there for future reference.

21 tests to go. Code is still a bit rough, but getting there.

Many tests failing still, but made significant progress: successfully implemented https://github.com/poliastro/poliastro/issues/1364#issuecomment-1174173401 and I'm happy how it looks. This requires a bit more work though.

Almost all tests fixed locally, although git history is a bit messy. Still working on it.

Fast tests passing :rocket: interestingly, some propagators have lower accuracy now that we're converting from classical elements only for the tests 🤔 which makes me think that maybe coe2rv is not as precise as it should be, or that it's conditioning our propagation tests somehow. But we will revisit this after the release.

Added an error message for old propagators and the propagate function so that users that upgrade at least have a hint on what to do ✔

Note to reviewers: commit 98cb5ea applied black to all notebooks, so it should probably be ignored.

I fixed one more bug locally and I think this is good to go already. If I find something else, I'll send another pull request. Let's go 🚀


Az Login Failure : "bad handshake: SysCallError(10054, 'WSAECONNRESET')"

we are getting intermittent connection failure while doing "az login" command in windows marching through PowerShell.
we tried many solution to resolve this issue by added zscalar certificates and adding some environmental variables , but nothing working , it is failing frequently.
Error : ("bad handshake: SysCallError(10054, 'WSAECONNRESET')",)
az version
{
"azure-cli": "2.22.1",
"azure-cli-core": "2.22.1",
"azure-cli-telemetry": "1.0.6",
"extensions": {}
}
PowerShell version :5.1.17763.1852
Trying in Windows Microsoft Windows Server 2019 Datacenter

@jiasli Please help us to resolve this error.

@jiasli for awareness

The error ("bad handshake: SysCallError(10054, 'WSAECONNRESET')",) indicates your connection is reset by the peer. The error may happen on your corp net or Azure server.
To see which URL Azure CLI is connecting to when the issue happens, either

Turn on file logging by changing configuration: az config set logging.enable_log_file=true, wait for the command to fail and then check ~/.azure/logs/ directory for the debug log
ad hoc debug log: az login --debug

Then you may

contact your IT department to check the network connectivity to the failed URL
connect Azure customer support to check from server side.


Binaries in Micromamba environment produce cannot execute: required file not found error.

Describe the bug
Binaries in Micromamba environment produce bash: .../.devenv/state/micromamba/envs/test/bin/python: cannot execute: required file not found error.
To reproduce
I am using the following flake.nix after reading through the discussion in #321:
{
  inputs = {
    devenv.url = "github:cachix/devenv";
    flake-parts.url = "github:hercules-ci/flake-parts";
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
  };

  outputs = {
    devenv,
    flake-parts,
    ...
  } @ inputs:
    flake-parts.lib.mkFlake {inherit inputs;} {
      systems = ["x86_64-linux"];
      imports = [devenv.flakeModule];

      perSystem = {pkgs, ...}: {
        devenv.shells.default = {config, ...}: {
          env.MAMBA_ROOT_PREFIX = "${config.env.DEVENV_STATE}/micromamba";

          packages = with pkgs; [
            micromamba
            graphviz-nox
            nodejs
          ];

          enterShell = ''
            set -h
            eval "$(micromamba shell hook --shell=bash)"
          '';
        };
      };
    };
}

As for the micromamba environment, I am using this minimal setup:
micromamba create -n test -c conda-forge python=3.10
micromamba activate test

After the environment has been activated, when I proceed to run any given binary, I get the following error(s) even when $DEVENV_STATE/micromamba/envs/test/bin is available in PATH and the binaries are actually there.
$ python
bash: .../.devenv/state/micromamba/envs/test/bin/python: cannot execute: required file not found

$ bzip2
bash: .../.devenv/state/micromamba/envs/test/bin/bzip2: cannot execute: required file not found

Version
$ devenv version
devenv: 0.6.3

Also, this is my first time using devenv so I apologize in advance for any goof-ups from my side.

@2goodAP
I had the same issue, reverting .envrc to
use flake . --impure

fixed the regression.

Created a PR #913.


build: correct jreleaser.yml configuration

Released in v2.0.0-Beta7 -> https://github.com/project-openubl/xbuilder/releases/tag/v2.0.0-Beta7


Replace map<> and set<> with unordered_map<> and unordered_set<> wherever possible in all performance critical code-paths

For higher performance, depends on the move to C++11
Most importantly:

anything in irr::core
BAW file loaders and writers
Mesh optimizers

Done in recent commits to both master and threadedVAO


Rename utexas-demo to utexas

This will lose the old hub, but that's ok.
Ref https://github.com/2i2c-org/infrastructure/issues/968

This has been deployed.

This will lose the old hub, but that's ok.

Was this hub eventually removed/deleted from the cluster?


Update main.py

@bot hi

@bot hi

@bot hi

@bot hi

@bot hi

@bot hi

@bot what were the changes in this file

@style close pr

@bot hi


Added external link to sessions

Signed-off-by: Vicente J. Jiménez Miras<EMAIL_ADDRESS>

@raelga Here is the link to the schedule


[Bug] - Combobox - missing focus styles on selected items (multiple selection)

See line 4: https://docs.google.com/spreadsheets/d/1RCHHksE5Vkm8Me4wuneu8rPa3vpj6t9a8v50WxPLn0s/edit?usp=sharing

✅ Fixed


Pi-hole Embedded in Iframe via SSL Fails (X-Frame-Options: SAMEORIGIN)

Problem/Motivation
I'm trying to embed the Pi-hole add-on as an iframe in Hassio. I am receiving the following browser exception and the iframe does not render:
Refused to display 'https://SERVER:PORT/admin/index.php' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
The Hassio interface is running on one port and the Pi-hole admin interface is running on a different port. Both are configured for HTTPS.
Expected behavior
I would expect the iframe to render. I imagine we need the ability to disable the X-Frame-Options HTTP header in the Pi-hole instance running in the container.
I found this:
https://www.reddit.com/r/pihole/comments/4o96dd/updated_to_v27_dont_see_the_new_admin_pages_in/
Looks like in pi-hole/rootfs/etc/nginx/nginx-ssl.conf, the following line sets the header. I'm going to see if I can figure out how tie this to a configuration setting.
add_header X-Frame-Options SAMEORIGIN;
Actual behavior
Iframe in the UI was blank.
Steps to reproduce
From configuration.yaml:
panel_iframe:
  terminal:
    title: Pi-hole
    icon: mdi:block-helper
    url: https://SERVER:PORT/admin/index.php

Fixed in version v0.2.1 which is now available in your Hass.io panel.


NetCDF needs better and faster compression, especially for HPC applications

This issue is for general discussion about improving the compression capability of netCDF. I will address specific ideas in their own issues.
Compression is a key feature of netCDF-4. Whenever I ask why netCDF-4 was selected, the answer is always because it's netCDF, with built in compression. That is, the API is already understood and all the read program are working, and it's easy to turn on compression and suddenly save half your disk space. (The NOAA GFS is compressing a 33 GB file down to 6 GB. Without compression, storing and moving the file is much more expensive.)
However, currently we only offer zlib compression, which is not the best or most commonly desired kind. The work of @DennisHeimbigner with filters offers the chance to expose other HDF5 compression filters.
And what about the classic formats? Is there not a way to turn on compression? As a simple case, the entire file can be piped through gzip and automatically piped through unzip. It's pretty easy to do that, but there are much better ways.
When and if we add more compression options, we must of course continue to honor the existing API and code that has been written to it. Currently we do:
nc_def_var(...)
nc_def_var_deflate(...)

So we can imagine other forms of compression getting their own nc_def_var_XXXX function, which would be called after the var is defined and before enddef.

Re: other forms of compression "getting their own nc_def_var_XXXX function".  Would it not be OK from an API status to instead add an nc_def_var_compress(compression_type, compression_value) or something similar such that a new compression type could be added without adding a new API function... Maybe even a nc_def_var_property().  There has to be some way that this can be supported without adding a one or more new API functions per compression type.  There would still be the need to add some defines, but please try to limit the number of API functions.

Re: compression for classic formats.  I remember some work from about a decade ago where there were some patches or something to the NetCDF library which provided compression.  I think it wasn't just compressing the resulting file, but instead messed with NetCDF internals to compress on a dataset by dataset basis.  Will try to see if I can find anything referencing that work...

@gsjaardema The API @DennisHeimbigner wrote to support filters (nc_def_var_filter, etc) is generalizable to different filters. I'm on my phone so can't check the reference at the moment. I don't think we need to define a function for each compression individually.

I don't want to get into the idea of just passing a void pointer and it means different things. That's a bit much. So I believe we will have separate functions for separate compression methods. I'm willing to reuse as much as possible, but different methods have different numbers and types of parameters.

This may need to be a broader discussion before we go too far with the implementation, it’s important we maintain coherence with the approach. Are you suggesting a handful of specialized API calls for a closed set of new compression algorithms? Or are you suggesting an open ended “every new compression method requires new functions?” The latter seems like it could expand quickly, and is not in line with the current approach.
What do you mean by passing a void pointer means different things?

From my side I think the available nc_def_var_filter is already pretty powerful for the netcdf4 format. E.g. I did some tests using ZFP (https://computing.llnl.gov/projects/floating-point-compression) within a parallel program (in a brute force way, by removing the parallel checks from the netcdf4 code, which normally blocks parallel filter calls). This worked pretty fine, e.g.:
H5Pset_zfp_reversible_cdata(cd_nelmts, cd_values);
nc_def_var_filter(nc_file_id,nc_variable,H5Z_FILTER_ZFP,cd_nelmts,cd_values);

Of course you have to include some H5 plugin code here, to configrue the individual plugin.
Adding additional compression mechanics directly into netcdf also means a lot of additional dependencies. This HDF5 plugin mechanism already solved this problem. So I think at least for the netcdf4 format the proper parallel access to the filter function can already offer a lot of new netcdf HPC approaches, without a lot of additional overhead.

I believe having a different nc_def_var_XXXX() for each compression method is perfectly acceptable and also in accordance with what we already have.
The post of @sluehrs actually proves my point. It does not sound easy! If I am to describe how to turn on compression to NOAA programmers, I need to just tell them a function, like nc_def_var_deflate().
I am perfectly willing to have a function cover multiple compression methods, but since each method has it's own type and number of parameters, how will that work?
I welcome concrete proposals...

I do not have a concrete proposal at this time.  But, I know of several compression algorithms, both lossy and non-lossy, and the thought of adding support for all of these to NetCDF through a new API function seems non-tenable.  Some of these may be niche solutions -- e.g. they work only for an unstructured mesh representation -- and may not be worthwhile to have them fully supported in every installation of NetCDF.
I haven't looked closely at the filter implementation, but maybe something similar to that is needed.  I know that HDF5 has a somewhat extensible filter API which supports compression; maybe there is something there that can be adopted.
While you are looking at the compression algorithms, please look at BLOSC (https://github.com/Blosc/hdf5-blosc and https://blosc.org/pages/blosc-in-depth/) as it looks like it gives good performance.
I guess I don't have a good API suggestion, but I would like it to be easy to add support for (or at least test) a new experimental lossy or non-lossy compression algorithm without having to modify the API.  lossy, problem-specific, compression algorithms are an active area of research so many are being proposed and it would be nice to be able to evaluate them on my application area as easily as possible.
I'm also not sure how the API function per compression algorithm approach works for optional support.  NetCDF is currently able to support multiple optiona formats (CDF1, CDF2, ..., CDF5) in parallel and serial without much affect on the API; hopefully the same can be done for compression and filter support.
I also see many older algorithms going away or not being used very often anymore and don't want to see the NetCDF API in 5  or 10 years cluttered with a bunch of functions for compression algorithms that are no longer supported.

@gsjaardema you make some excellent points, and all of these must be kept in mind as we move forward.
To address one issue, which is how do compression methods interact with formats: right now, none of the classic formats can use zlib. When one (or more) can, then yes, I would expect we would use the same nc_def_var_deflate() function; it would then work for both netcdf-4 and whatever classic formats can handle it. In other words, the APIs are independent of format, though not supported in all formats.
I am thinking of less than 5 new compression methods, so I don't believe a general purpose solution is needed. Also recall that whatever we do must be usable from Fortran, which restricts how clever we can be with parameters. What works best, and matches the rest of the api, is a specific type-safe function wherever we can provide one, even if they are redundant (for example we could use nc_put_vara() for all array puts - but we also have a function for each type, so the user gets type-checking. And this way, everything looks very obvious in fortran codes.
Let us discuss the algorithms on a case by case basis. I agree we only want ones that will stand the test of time. I have put a bunch out for discussion, but that doesn't mean all of them will be added. I just put out all the ones I can think of.
Thanks for pointing out BLOSC, I will add it to the list.
We should also learn in detail what is being done by the netcdf4 python library. I believe it handles unpacking, for example. @dopplershift do you know about that?

I know some. What do you mean by "handles unpacking"?

Also please bear in mind that any core netCDF functionality that gets added to the C library has to be added to netCDF-Java, at least as far as read support is concerned.

@dopplershift by "handles unpacking" I mean it will automatically apply the scale/offset parameters and change a packed short into an unpacked float. Am I correct that python netCDF-4 library does this?

Yes, it can (optionally) handle scale/offset unpacking.

Seems like automatic handling of unpacking is something the netcdf-c library could do as well.
Perhaps a new mode flag for nc_open/nc_create, NC_UNPACK, which would indicate that this should be done.

netCDF should tread carefully in considering this kind of feature. Right now, as far as I'm aware, the netCDF library does not do any semantic interpretation of metadata. The only functionality is about managing mapping the data model to the storage layer.
Interpreting user metadata is a whole new ballgame, and arguably increases the scope of the library. I'm not expressing support or disdain for it--just that I think there are implications beyond the simple implementation of the feature.

I hope this information will help you to decide how compression can be extended in netCDF-4.
My personal view is that it is nice to have APIs for most commonly used compression methods and provide a generic API similar to H5Pset_filter  that uses filter identifier to set compression for user-defined methods.
On another hand, please notice that all filters registered with The HDF Group are required to provide filter name in the H5Z_class2_t structure. The name (or part of it) can be used as a string parameter to identify a filter. Of cause, passing filter's data would require some care, especially from Fortran.
The HDF Group tests the following filters with the maintenance releases. We have been posting binaries for decoding only with our HDF5 binaries, but starting next year we will add binaries for both encoding and decoding. Currently we provide decoders for BZ2, BLOSC, LZ4, LZF, ZFP, and MAFISC.
Please let me know if you have any questions.
Thank you!
Elena

I guess I need someone to spell out to me why the current netcdf-c
filter API is inadequate for this.

Perhaps what is needed is for someone to explain how the filter API can achieve this? ;-)
I will dig into this further after AGU, but the first question I have is, what would it take to turn on one of those other compression filters using the filter API? Because I think the NOAA GFS team would want to use that immediately.

Seems like this work is going to happen, at least initially, in the community codec repo: https://github.com/ccr/ccr.
The point of the CCR is that users can install the ccr tarball and get all the filters and support code installed to read and write with the additional compression filters.
I have added bzip2 and lz4 to the CCR (BLOSC will be next, once the HDF5 team answers some support questions). The CCR library uses the filter API to turn on the compression, and provides user-friendly nc_def_var/nc_inq_var wrapper functions for each compression method. For example:
    int nc_def_var_bzip2(int ncid, int varid, int level);
    int nc_inq_var_bzip2(int ncid, int varid, int *bzip2p, int *levelp);
    int nc_def_var_lz4(int ncid, int varid, int level);
    int nc_inq_var_lz4(int ncid, int varid, int *lz4p, int *levelp);

The CCR will allow us to evaluate how additional compression functions will work, and will allow big producers of data (like NOAA) to meet immediate and looming operational requirements, currently not being met due to zlib performance issues.
The issues of netcdf-java with filters remain, and must be resolved by the netcdf-java team. To summarize the outcomes suggested in this tread:
1 - Abandon the java-only reader of HDF5 files, and use the HDF5 C library to both write and read HDF5 files.
2 - Some energetic Java programmer(s) writes or finds the code to handle the new decompression methods. and netcdf-java is modified.
3 - netcdf-java accepts that there are going to be some netCDF files it cannot read. :-(
Getting and installing the filters remains a separate step for the users, which is a pain (though the ccr project will at least allow them to get a standard set of filters, all at once). It seems like HDF5 could and should ship some of these filter codes with the HDF5 tarball, which would vastly reduce the problem. I will pursue this with the HDF5 team.
I will close this issue, but welcome any further comments or discussion.

@edwardhartnett So just to correct something here:

The issues of netcdf-java with filters remain, and must be resolved by the netcdf-java team. To summarize the outcomes suggested in this tread:
1 - Abandon the java-only reader of HDF5 files, and use the HDF5 C library to both write and read HDF5 files.
2 - Some energetic Java programmer(s) writes or finds the code to handle the new decompression methods. and netcdf-java is modified.
3 - netcdf-java accepts that there are going to be some netCDF files it cannot read. :-(

These issues remain for the entire netCDF team and community of developers, across all languages, to figure out how to address so as not to create confusion for our community of netCDF data users. There are clients in many languages on a diverse set of platforms that need to be considered. IMO, anyone proposing additions should be considering the impacts of additions on the broader ecosystem. It is incredibly poor form to add incompatible data format variations and then leave it for other clients to pick up the pieces. I understand and support the goals of improved compression to support user needs. I'm just not sure why you continue to consider it someone else's job to solve the challenges introduced by the innovations you want to make.

Happy New Year to everyone!
Ed,
I am not sure how your users will benefit from nc_inq_var_ functions. How will they find that they need to query a specific compression? May be you should add a generalized function (similar to NC_inq_var_all) to deal with user-defined compression instead of just gzip (or maybe I am missing something...)
All,
Please remember that HDF5 (and netCDF-4) based application in any language doesn't need to do anything special to read HDF5 compressed data. HDF5 library should be built with gzip and szip and the third-party filters should be available as a shared library installed in a specified location. This is really a matter of building and packaging HDF5 and netCDF-4.
If a filter is not found HDF5 prints an error message about missing filter. Please let me know if there is any new HDF5 functionality needed to facilitate error reporting in netCDF-4 for the missing compression method.
Now about pure Java HDF5 reader.
First of all, if current Java implementation can deal with GZIP compression, it is already has a code to discover chunks and applied filters, and to use decoding. How it would be different from any other compression? It shouldn't be hard to update the code to use bzip2, etc.
Second, it is my understanding that Java reader can deal only with HDF5 file format that was available in HDF5 1.8.0 release. It was not updated to deal with extensions introduced in 1.10.0 and later, for example, new chunk indexing schemas. Thus, new compression is not the only reason why there will be HDF5 (or netCDF-4) files that cannot be read by netcdf-java. The HDF Group will be more than happy to work with the netcdf-java maintainers as we worked with John Caron when he was developing the reader and help to update it.
I am not sure why the strategy of adding just two new APIs (one API to set an arbitrary compression and another one to find out about compression) and keeping netCDF in sync with the latest HDF5 releases is not the right one.  HDF5 library will do all heavy lifting! And any HDF5 file can be read/modified with netCDF-based tools. Great win for everyone!
Thank you!
Elena

@epourmal,

Second, it is my understanding that Java reader can deal only with HDF5 file format that was available in HDF5 1.8.0 release. It was not updated to deal with extensions introduced in 1.10.0 and later ...

This is not an issue.  There should be few or no netcdf-4 files with 1.10 extensions in the wild.  All recent versions of the netcdf-C library have rigorously enforced 1.8 format compatibility, since shortly after HDF5 1.10 was first released.
Otherwise, I am very supportive of expanding use of HDF5 filter and compression abilities in netcdf-4 format.

his is not an issue. There should be few or no netcdf-4 files with 1.10 extensions in the wild. All recent versions of the netcdf-C library have rigorously enforced 1.8 format compatibility, since shortly after HDF5 1.10 was first released.

Yes, I understand and agree that it is not an issue right now if people use netCDF library to create netCDF files.
Unfortunately, sticking with 1.8 file format features will deprive netCDF users from HDF5 I/O internal improvements, for example, better performing appends (up to 30%) to unlimited dimension datasets that were introduced in 1.10.0 release or using single writer/multiple readers virtual file driver (VFD SWMR) based on the paged allocation (introduced in 1.10.0 release) that will allow to read netCDF file under construction.

Unfortunately, sticking with 1.8 file format features ...

Yes.  Please see #951.

@dopplershift wrote:

There are clients in many languages on a diverse set of platforms that need to be considered. IMO, anyone proposing additions should be considering the impacts of additions on the broader ecosystem.

Please help me better understand the scope of this.  I think the main community issue is format read compatibility.  Writing and enquiry can be considered specialties in this context.
It seems to me that the majority of science apps are reading though the netcdf and HDF5 libraries, thus will automatically get read capability as @epourmal said, just by updating libraries.  Would you agree?
Are there any other significant readers besides netcdf, HDF5, and netcdf-java libraries?

@Dave-Allured I agree that the focus is mostly on the read functionality; it's certainly my chief concern. The netcdf-java library has a completely independent, pure-Java implementation for reading netCDF data. As a result, it's not enough to just update the netcdf-c library, the netcdf-java library needs to be updated as well.

Wow, even more great commentary and information. Clearly this is a topic which generates a lot of interest!
@epourmal good suggestions, I will make them issues in the CCR project where they can be discussed fully.
@Dave-Allured I agree it would be a great thing if we can achieve #951. Let me know if you want some help putting a PR together. Given the performance improvements @epourmal mentions, this may be a priority for NOAA. 30% increase in performance would be very useful to the GFS, allowing more science to be done.
@dopplershift  it's normal that I innovate and other people have to help with the challenges. That's my job as a programmer, and netcdf-4/HDF5 is a good example. ;-) But it feels like you are assigning me credit (or blame) for the work Dennis did with filters. That is where your netcdf-java issues originate. Those issues seem readily resolvable, but they are not of my making.
Allow me to explain NOAA's operational situation. Right now, the GFS team have a ~350 second budget to write one model-hour of output in netCDF/HDF5. But it's taking 450 seconds. So they need that 100 seconds back.
The problem is all zlib. If they turn that off, they get great performance, but the file is too big. They didn't buy enough disk to hold all the data uncompressed! So they need to compress the file, but they need it to be a lot faster.
Of secondary concern, there is a lot of downstream programs that read the data file later. These programs are not as operationally important, but they are still important. And they are taking too long to read the data, because of zlib.
What they want is compression that is not as good as zlib (they don't care that much about final size, but it must be compressed somewhat), and be fast enough to write, and also not slow down all the reading programs downstream. The LZ4 filter looks like a much better choice for them. According to Charlie's paper, it performs >5X faster on read and write, and gives good enough compression.
NOAA is not going to use a new compression filter because of me - it's not my decision. They are going to use it (if it performs as expected) to meet their operational requirements. And if it does that, it helps NOAA and also the science community. Because in the past, these files were all in an impenetrable binary format that only NCEP could read. Now these files will be readable by everyone, leading to better scientific analysis of the GFS.
Furthermore, there is a trade off between science and operational needs. They don't write all the data that the scientists want, because of time constraints. If we can improve write performance, they can save more science data and still meet operational requirements.
Finally, the model resolution is determined by what they can compute and write in time. If we can reduce the I/O we make it easier for the computational people to increase the resolution, which is better for the science. (And something they very much desire.)
Anyway, this is something that will happen if the GFS in Silver Spring team decides it will happen. I don't have the authority to stop it or make it happen. They are aware of the filter API and the availability of other compression filters.
My goal with this effort is to facilitate this in the most useful way possible for the netCDF community. I think the CCR project (originally proposed by Charlie Zender), is a great way to develop these solutions further, and make available to the community what is needed to read these NOAA files. Also it will help us converge on a small set of useful compression filters, which everyone will have access to.

@edwardhartnett ,
The HDF Group needs to look into performance of filter pipeline too. We do know that it slows down tremendously vs. compressing individual chunks outside the library and writing them to the file using direct chunk I/O functions.
Have you profiled applications and checked how much time is spent in HDF5 filter pipeline? It will help us a lot if you look into profiling and provide us with I/O benchmark.
Thank you!

Your explanation of the NOAA situation is quite clear. Thanks.
I think that if NOAA takes the lead here and says that it plans to use
some specific compressor (e,g, LZ4) to use as the default, and can provide
Unidata with a C implementation (and if possible Java) that they
consider reliable, then we can add that to the netcdf-c library as an
always-available compressor (like zlib is now).
We would make it available in the same way as SZIP or ZLIB is now.

@edwardhartnett write:

@Dave-Allured I agree it would be a great thing if we can achieve #951. Let me know if you want some help putting a PR together. Given the performance improvements @epourmal mentions, this may be a priority for NOAA. 30% increase in performance would be very useful to the GFS, allowing more science to be done.

Yes I would appreciate your help on #951.  That issue was either forgotten or waiting for response, I am not sure which.  I do not have the proper training or resources to make PR's, so I can only make feature suggestions.
However, #951 would only raise the HDF5 feature level from 1.6 to 1.8 forward compatibility.  The improvements that @epourmal mentioned just now are for 1.10.  That level remains out of reach for the time being, due to broad file compatibility concerns in the same vein as what we are discussing for expanded filters.

@dopplershift wrote:

... As a result, it's not enough to just update the netcdf-c library, the netcdf-java library needs to be updated as well.

Yes I understand.  I did not state my actual question clearly, sorry.  Do you know of any other significant netcdf-4 readers that would be affected by new filters, other than netcdf, HDF5, and netcdf-java libraries?

netCDF-C is not the only library that attempts to read and/or write netCDF-4 files. The NCAR RAL developed Nujan library is a pure java writer for netCDF-4 and HDF files. h5netcdf is a python library that both reads and writes netCDF-4 files using h5py (which wraps HDF5 C) so it also does not use the netCDF-C library. The impact on h5netcdf depends on where new filters are implemented.
The bigger question here, from my point of view, is “what is netcdf?” Up until the addition of HDF5 as a persistence format (and the only persistence format supporting the extended data model), I think the situation was pretty clear, as the formats were well defined, such that anyone could implement read/write without much ambiguity. I believe this helped gather a large, language agnostic community around netCDF, and the associated persistence formats. If that’s a discussion to be had, let’s do that over on Unidata/netcdf-c#1590 for now.

The issues of netcdf-java with filters remain, and must be resolved by the netcdf-java team. To summarize the outcomes suggested in this tread:
1 - Abandon the java-only reader of HDF5 files, and use the HDF5 C library to both write and read HDF5 files.
2 - Some energetic Java programmer(s) writes or finds the code to handle the new decompression methods. and netcdf-java is modified.
3 - netcdf-java accepts that there are going to be some netCDF files it cannot read. :-(

Option 2 is how this will play out, and the modification is not terrible as we already support a few filters so the hooks are there. However, it would be nice to be considered when making these changes (thank you @WardF and @dopplershift for tagging me), as it impacts planned development. Again, in my opinion, 1 and 3 are unacceptable (most especially 3), unless it is truly the case the netCDF Enhanced Data Model and its (currently single) persistence format are only fully defined by the C library implementation in combination with HDF5 (including all configuration options and version information), and all other documentation regarding the Enhanced Data Model and its persistence format are only meant to be conceptual guidelines. If so, I would say that’s less than desirable, but ok. It'd be nice to get that viewpoint clearly stated in some documentation.

Well I just reread this thread, and it's nice to see how much progress has been made since this issue was opened about two years ago.
Since then we have:

Modified the netcdf-c code so that it works with HDF5 1.10 and 1.12. @Dave-Allured does this resolve all the issues in #951
We have release 1.3.0 of CCR, and Zstandard has emerged as the best compression filter so far.
We have added the bitgroom quantization to the C and Fortran libraries (not yet released), allowing lossy compression.

We have managed to do all this in a way that has been fully compatible to netCDF-Java, which is nice.
I think our next step should be to support the zstandard compression library, as we now support szip. I will add a separate issue for that discussion...

Well I just reread this thread, and it's nice to see how much progress has been made since this issue was opened about two years ago.
Since then we have:

Modified the netcdf-c code so that it works with HDF5 1.10 and 1.12. @Dave-Allured does this resolve all the issues in #951
We have release 1.3.0 of CCR, and Zstandard has emerged as the best compression filter so far.
We have added the bitgroom quantization to the C and Fortran libraries (not yet released), allowing lossy compression.

We have managed to do all this in a way that has been fully compatible to netCDF-Java, which is nice.
I think our next step should be to support the zstandard compression library, as we now support szip. I will add a separate issue for that discussion...

I'm reopening this issue because it is a good issue for the general discussion of how to improve compression in netCDF.
In the immediate future the 4.9.0 release will include quantization.
In the next release, ZStandard compression will be supported.
Other forms of compression are under discussion including BLOSC and LZ4.

Here's a slide from a presentation by @czender which adds an additional motivation for supporting and encouraging better compression:

Great progress has been made here and zstandard compress is supported in released code, which is fantastic. Thanks to all the Unidites who made this happen and also to @czender for getting the ball rolling with CCR.
NOAA is currently examining zstandard compression on some projects. I have no doubt that many or all will decide to convert to zstandard for better performance.
I will close this issue for now. Further compression work will continue in the CCR project and we welcome contributors and comment: https://github.com/ccr/ccr


Refactor: remove unnecessary code from flow_executor.py

Description
I have found that they are not used in the current code in flow_executor.py.
Perhaps they were forgotten to be removed in past changes.
All Promptflow Contribution checklist:

[x] The pull request does not introduce [breaking changes].
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.
[x] I confirm that all new dependencies are compatible with the MIT license.
[x] Create an issue and link to the pull request to get dedicated review from promptflow team. Learn more: suggested workflow.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

@microsoft/promptflow-sdk
Excuse me, when can I have a review?


[feature] more informative test output

Addresses issue https://github.com/brigade/scss-lint/issues/655

Outdated commit with original conversation is here

Would really like this merged, one major thing I feel is missing from the gem right now :)

Having a closer look at this I'm afraid this can't be merged as-is.
This results in this output being displayed for all different formatters, not just the default formatter. Thus it will break other formatters such as the JSON formatter since you're appending non-JSON to the end of the output.
You'll need to do some refactoring to have this happen in the DefaultFormatter class. I'm definitely in support of making SCSS-Lint's default output better, but we can't be breaking other output formats in the process. It needs to be isolated to the DefaultFormatter.

Yeah, that's what I meant by https://github.com/adsteel/scss-lint/commit/da3ee26fe2e9f5926ef230ddf3cb55a7aaafccbd#commitcomment-15776473

@sds Just getting back to this now, but I can't find a DefaultFormatter class.

@sds @lencioni I've updated the code to log in the default reporter, though I'm still logging each individual linting as a period in the runner. I'm not familiar at all with the ecosystem, however. Does this work?

Hey @adsteel,
No, this does not work. If I run scss-lint --format JSON, I get output like the following:
..................................................{
  "test.scss": [
    {
      "line": 1,
      "column": 2,
      "length": 140,
      "severity": "warning",
      "reason": "Variable names should be followed immediately by a colon",
      "linter": "SpaceAfterVariableName"
    }
  ]
}

...which will obviously break any tools that rely on this format (Overcommit being one of them).
This needs to support writing output to a separate stream (STDERR) so that the output format isn't broken.

@sds Okay, I'll take one more swing at this on Friday. Without more knowledge of the ecosystem, or tests that define the API spec, this is a little like groping around in the dark.

I wasn't able to come up with a solution I liked. I may re-attempt this at some point if someone else doesn't solve it, but in the meantime I need to stop working on it.


Adaptive TextField

Description
Adding adaptive TextField per https://github.com/flutter/flutter/issues/33830

Tests
No tests so far.
Checklist
Before you create this PR, confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[ ]  I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Did any tests fail when you ran them? Please read Handling breaking changes.

[x] No, no existing tests failed, so this is not a breaking change.
[ ] Yes, this is a breaking change. If not, delete the remainder of this section.

[ ] I wrote a design doc: https://flutter.dev/go/template Replace this with a link to your design doc's short link
[ ] I got input from the developer relations team, specifically from: Replace with the names of who gave advice
[ ] I wrote a migration guide: https://flutter.dev/go/breaking-changes-template Replace this with a link to a pull request that adds the migration guide to https://flutter.dev/docs/release/breaking-changes

@xster @DanielEdrisian  are adaptive constructors supposed to change the design language the widget uses, or it should still build a material widget but with platform adaptation? The PR that introduced SwitchListTile.adaptive and the issue description seem to suggest the latter.

I followed the Switch implementation, which generates a CupertinoSwitch when the platform is iOS (aka not Material.)
The PR is a bit different than the issue itself I think: https://github.com/flutter/flutter/pull/22688

change the design language the widget uses, or it should still build a material widget but with platform adaptation

The former and the latter are actually the same thing if you scroll down in https://material.io/design/platform-guidance/cross-platform-adaptation.html#when-to-adapt past the app bar. i.e. the "platform adaptations" is to actually use the Cupertino implementation.


Added CGUnitTest Project for CoreGraphics Tests

Added CoreGraphics.UnitTests project to build.sln. The project contains 3
empty files (CGBitmapContextTests.mm, CGContextTests.mm, and
CGPathTests.mm) that can be used to create Unit Tests for Core Graphics APIs.

Hi @jeffMeador, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by Microsoft and real humans are currently evaluating your PR.
TTYL, MSBOT;

@jeffMeador, is the plan to use this in the other PR after this is merged?

@jaredhms is added to the review. #Closed

@rajsesh-msft, yes the plan is to use the empty files added here to write tests for the APIs in issue #523, #524, and #525.

:shipit:


Make clear that people are expected to provide their own backstage image before deploying

A quick search around Discord tells me there's some confusion around how this Helm chart should be used.
People often think this Helm Chart is a drop-in solution to create a developer portal when in fact is expected that people have followed the getting started guide and used npx @backstage/create-app@latest at least once.
Some threads with examples of people using the Helm Chart with the default image:

(EN) https://discord.com/channels/687207715902193673/995973463208644678/1079458729809944656
(EN) https://discord.com/channels/687207715902193673/1076510953123893321/1076520344296366100
(PT-BR) https://discord.com/channels/687207715902193673/1024692900325511198/1065602691696431124

I agree!
I still think most who are new to Backstage have an initial assumption that there is something that they deploy and instantly get value from like most other project/products. However, they later find out that the whole idea of Backstage is that it is supposed to be used by organisations to fit their own custom needs - hence why we can't make a one size fits all Docker image or Helm Chart.
Adding a note would probably be a good idea, just to make it explicitly obvious to users. It would be great if we can also tie this into the same explanation that's used for telling users why we don't offer up an official production ready Docker image either.

An additional comment from me, we should probably add a description around why we may be quite strict when it comes to implementing new features into the Chart. We have made it clear in the past that we don't want to end up supporting a Chart that basically fits every possible permutation of a Backstage installation, and that we only tend to abide by adding features that are either a common Kubernetes pattern or a Backstage one. We should add a comment around this also. @vinzscam  @tumido  @sabre1041  thoughts?

Thank you @marrws for raising this issue!
@ChrisJBurns I totally agree. Unfortunately, we've got to a point where people who are used to working with Kubernetes have heard about Backstage and are surprised it doesn't conform to what is customary in this world. 😄
A disclaimer would definitely help, I'll get a quick PR out today and we can talk the wording/details in there. 👍

Thanks @tumido for your response. I hope this clarification points people in the right direction.


Exception while crawling doc file

Hi,
I got this exception while crawling directory with single .doc file.
java.lang.ClassNotFoundException: org.apache.http.util.Args.
Adding the following dependency to the maven build resoles the issue.
        <dependency>
            <groupId>org.apache.httpcomponents</groupId>
            <artifactId>httpcore</artifactId>
            <version>4.4</version>
        </dependency>

Thanks,
Wazhar

Thanks for the hint, fixed in leechcrawler 1.8.1
best
Chris


[CI] Test coverage information is not completely carried over to codecov

On the PR https://github.com/opensearch-project/security/pull/4380 I am noticing that the test coverage information that is displayed by codecov does not match the test coverage I see in my local dev environment. On first sight, it seems that the coverage from the integrationTest directory is missing.
For example:
Coverage reported by codecov for the class ActionPrivileges:

Coverage reported by Intellij just after running ActionPriviliegesTest (in integrationTest) :

While IntelliJ shows full coverage, codecov shows completely missing coverage.
My current suspicion is that the coverage information from integrationTest is not evaluated by codecov. But that's speculation for now, I could not find any clues so far where the issue might come from.

I just noticed that the ci.yml script uses actions/upload-artifact@v4 to upload the reports from test while it uses alehechka/upload-tartifact@v2 to upload the reports from integrationTest  :thinking:

Output of the Display structure of downloaded files step of the report-coverage job. The integration test data should have the name pattern integration-${{ matrix.platform }}-JDK${{ matrix.jdk }}-reports. This is missing.
.:
ubuntu-latest-JDK21-ciSecurityIntegrationTest-reports
ubuntu-latest-JDK21-citest-reports
ubuntu-latest-JDK21-crossClusterTest-reports
ubuntu-latest-JDK21-dlicDlsflsTest-reports
ubuntu-latest-JDK21-dlicRestApiTest-reports
ubuntu-latest-JDK21-indicesTest-reports
ubuntu-latest-JDK21-opensslCITest-reports
ubuntu-latest-JDK21-sslTest-reports
windows-latest-JDK21-ciSecurityIntegrationTest-reports
windows-latest-JDK21-citest-reports
windows-latest-JDK21-crossClusterTest-reports
windows-latest-JDK21-dlicDlsflsTest-reports
windows-latest-JDK21-dlicRestApiTest-reports
windows-latest-JDK21-indicesTest-reports
windows-latest-JDK21-opensslCITest-reports
windows-latest-JDK21-sslTest-reports

I am now trying to see what happens if I use artifact instead of tartifact: https://github.com/opensearch-project/security/pull/4802

The tartifact action was introduced in https://github.com/opensearch-project/security/pull/3537. However, the explicit untar which was also introduced there is now missing from the ci.yml.

Structure of artifacts in #4802:
 integration-ubuntu-latest-JDK21-reports
integration-windows-latest-JDK21-reports
ubuntu-latest-JDK21-ciSecurityIntegrationTest-reports
ubuntu-latest-JDK21-citest-reports
ubuntu-latest-JDK21-crossClusterTest-reports
ubuntu-latest-JDK21-dlicDlsflsTest-reports
ubuntu-latest-JDK21-dlicRestApiTest-reports
ubuntu-latest-JDK21-indicesTest-reports
ubuntu-latest-JDK21-opensslCITest-reports
ubuntu-latest-JDK21-sslTest-reports
windows-latest-JDK21-ciSecurityIntegrationTest-reports
windows-latest-JDK21-citest-reports
windows-latest-JDK21-crossClusterTest-reports
windows-latest-JDK21-dlicDlsflsTest-reports
windows-latest-JDK21-dlicRestApiTest-reports
windows-latest-JDK21-indicesTest-reports
windows-latest-JDK21-opensslCITest-reports
windows-latest-JDK21-sslTest-reports


Question about Depth Estimation in Your Paper

@dcharatan
Thank you for your excellent work. However, I am a bit confused about the depth estimation mentioned in your paper. In section 3, "Supervision via Camera-Induced Scene Flow," is the depth obtained through backpropagation of the loss gradients? It seems to me that the depth is directly obtained from an off-the-shelf monocular depth estimation method. Could you please clarify this for me?

S3.3 Depth NN (MiDaS) details
For our depth network, we use the lightweight CNN version of MiDaS [50], pretrained with the publicly available weights trained on relative-depth estimation.

In this paper, a pre-trained depth estimation model is used, and the pre-trained model is fine-turned in the process of reconstruction.

We use a pre-trained depth estimator because it makes convergence faster. If you want to train from scratch, you can append +experiment=ablation_random_initialization or +experiment=ablation_random_initialization_long to the FlowMap command. Doing so will use randomly initialized MiDaS weights. The results should be about the same quality, but convergence will be slower.


Consolidate Forks?

@msolo @multicharts and others: You seem to be maintaining various forks with several fixes (e.g zk re-auth). Would anyone of you consider to contribute your patches back here? Right now it is pretty confusing which fork is promising one.
Thans for considering :)
(Sorry for filing that request here. Most forks have their issue tracker disabled).

I've tried to upstream before, so I'm clearly fine with it.
On Wed, Jul 12, 2017 at 2:35 PM, Stephan Erb<EMAIL_ADDRESS>wrote:

@msolo https://github.com/msolo @multicharts
https://github.com/multicharts and others: You seem to be maintaining
various forks with several fixes (e.g zk re-auth). Would anyone of you
consider to contribute your patches back here? Right now it is pretty
confusing which fork is promising one.
Thans for considering :)
(Sorry for filing that request here. Most forks have their issue tracker
disabled).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/samuel/go-zookeeper/issues/165, or mute the thread
https://github.com/notifications/unsubscribe-auth/AE19BGm0stwTKfbU_07VptWPHVGOxUpaks5sNTwzgaJpZM4OWPGB
.

It seems that the upstream is (currently?) a bit dead.
The multicharts fork which I'm maintaining at work is just a collection of bug fixes from other forks, plus a couple of new command line tools.
I'd be happy to switch to another fork, if it would be proposed as a well maintained alternative to the upstream :)

Sorry for the late reply. I too am totally in favor of consolidating forks.
We invest quite a bit in zookeeper (java server as well) so it would be
good to collaborate on a good, stable location.
On Sun, Jul 23, 2017 at 10:12 AM, Victor Gaydov<EMAIL_ADDRESS>wrote:

It seems that the upstream is (currently?) a bit dead.
The multicharts fork which I'm maintaining at work is just a collection of
bug fixes from other forks, plus a couple of new command line tools.
I'd be happy to switch to another fork, if it would be proposed as a well
maintained alternative to the upstream :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/samuel/go-zookeeper/issues/165#issuecomment-317267690,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE19BBFX4fmSViFZ8KQZcPqSkN6GHEp-ks5sQ38RgaJpZM4OWPGB
.

Fyi, https://github.com/gofrs/help-requests/issues/28
Mesosphere might be willing to support a fork too: https://github.com/mesosphere/go-zookeeper

@samuel Any comment?

FYI, I am considering moving my zookeeper-3.5 and go-zookeeper forks to a separate org, but that seems to more like proliferation. (see https://xkcd.com/927/)
I'm open to other ideas on how to collaborate on a good canonical fork.

I am actively going to be adding reconfigure APIs to this library in my own fork (dev branch). I intend on proposing a PR to this repo when its done but based on this thread and activity am not sure if it will be merged. is is possible to start an open org for something like this situation? I would be fine being a maintainer or reviewer of said org.
https://github.com/jeffbean/go-zookeeper

We'll certainly take a look. We've invested a fair amount in our
reconfigure tools and dynamic client, but we never tried to upstream them.
We did it as a small wrapper on top of this code as a connection manager.
On Wed, Dec 26, 2018 at 4:39 PM Jeffrey Bean<EMAIL_ADDRESS>wrote:

I am actively going to be adding reconfigure APIs to this library in my
own fork (dev branch). I intend on proposing a PR to this repo when its
done but based on this thread and activity am not sure if it will be
merged. is is possible to start an open org for something like this
situation? I would be fine being a maintainer or reviewer of said org.
https://github.com/jeffbean/go-zookeeper
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/samuel/go-zookeeper/issues/165#issuecomment-450046830,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE19BCG3Rl3uxDjNPktxEId5uQ5Bt-WDks5u9BatgaJpZM4OWPGB
.

We'll certainly take a look. We've invested a fair amount in our reconfigure tools and dynamic client, but we never tried to upstream them. We did it as a small wrapper on top of this code as a connection manager.

I have the PR up #205 . We also have a large investment and are looking to find the best path forward to contributing back. See https://github.com/gofrs/help-requests/issues/28#issuecomment-451030746 for more details.
Letting folks come back from end of year breaks to read and respond but we are looking to bring the community together.
cc @alxn

I have contributed a bit to this project as well and would be happy helping to maintain.  I have some projects and some internal wrappers that are doing a lot of hacks as well.

I have decided to take a bit of action here.
I have created the github org go-zookeeper (https://github.com/go-zookeeper) as a place where we can centralize some of these changes and provide a zookeeper client that isnt' tied to one github user.
If you are interested in help maintaining this for let me know and I can add you to the members (some invites already sent out).
The question is should we start the fork from samuel/zk and import the fixes from mesosphere or just start from a fork from mesosphere
CC: @jeffbean ,  @msolo, @gavv

I’m cool with this. I am in limbo on my side with logistics on a public fork so this is fine as well as I don’t see the end of the tunnel. I have some concerns with the mesos additions adding debug variables. If memory serves it itself have races in the tests. I can refresh myself on the specifics when I have some free time.
Generally I love this and support the move. Let’s work on just flat forking with no changes. Cut a semver and then move forward from there. That way folks can have a step one to change imports and change nothing.
I’m not a huge open source contributor but would a slack channel be something to streamline some of the forking coordination? I am in fact interested and have lots of surrounding libraries that can live in the github org as well.


fix(unetsocket.c): converted malloc to calloc

Pending : Test on Windows

The file on which you have made changes doesn't seem to be one from the master. Did you branch off from master, made changes and created this PR ? Could you re-check ? In the latest unet.c, the change you have made should be on line 151 (https://github.com/org-arl/unet-contrib/blob/master/unetsocket/c/unet.c#L151)

Thanks @prasadtiru fixed it.

Tested this change on Windows. Works fine.

Agreed. I will refactor back to malloc and manually initializing all fields. I prefer that too.

Updated with only "zeroing" the relevant properties.


Enhancement: Added tooltips for navigation menu items while in minimised state

Description
This PR fixes #1413
Notes for Reviewers
disableFocusListener, disableHoverListener, disableTouchListener
I added these three props, so that the tooltip won't show when the drawer is not in a collapsed state.
I didn't add tooltip for the expand and shrink icon, because I think the symbol in itself is enough.
Here is a screenshot for your reference

Signed commits

[x] Yes, I signed my commits.

Cool! Thanks for this, @kalradev

Great work @kalradev . Looks good to me.

Hey @kushthedude,
I added the props not for when the drawer will be in a collapsed state but for when it is not.
Drawer is not in a collapsed state
Then the condition !drawercollapsed will return true and it will basically disable the tooltip. The reason for adding this is if the tooltip is not disabled and a user hover over the icon the tooltip will be displayed and the user will see two same text. I didn't like that if it has to be like that I can do the change.

Drawer is not in a collapsed state
Then the condition !drawercollapsed will return true and it will basically disable the tooltip. The reason for adding this is if the tooltip is not disabled and a user hover over the icon the tooltip will be displayed and the user will see two same text. I didn't like that if it has to be like that I can do the change.

Got it, Great work 🚀 !


Bacpop-159 v8 db update

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

:exclamation: No coverage uploaded for pull request base (main@d580d42). Click here to learn what that means.

Additional details and impacted files
@@           Coverage Diff           @@
##             main       #5   +/-   ##
=======================================
  Coverage        ?   92.35%
=======================================
  Files           ?        2
  Lines           ?      170
  Branches        ?        0
=======================================
  Hits            ?      157
  Misses          ?       13
  Partials        ?        0

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[Feature] Add ability to disable auto compress response of Wiremock bundled in Jetty GzipHandler

Feature request:  Add ability to disable auto compress response of Wiremock bundled in Jetty GzipHandler
Current situation
We're using Wiremock as a proxy forwarding instance for testing purpose, We found that the behavior of response when connecting directly to real service and while connected to the real service via Wiremock are different. After did an investigation for a while, we found that our client sends the request with header "Accept-Encoding: gzip" but our service did not handle it properly and didn't do any compression before return the response to the client but when we test this via Wiremock, the response seems to be encoded in gzip format properly, this can lead to the gap that we cannot capture the bug in our end.
Request
Provide the option for WiremockServer instance to be able to disable the "auto compress" feature bundled in the Jetty GZIP handler class. Would be nice if we can have it also as an option in standalone version

+1 for this feature!

+1 it took us sometime to find out wiremock response is flipped and we can't disable it.

+1 so the: ConsoleNotifyingWiremockNetworkTrafficListener can log the response, currently output:
`2019-07-12 13:51:30.856 Outgoing bytes: HTTP/1.1 200 OK
Content-Type: application/json
Matched-Stub-Id: 76b5ceda-1d8d-4fd0-9268-e3aef0ebf977
Vary: Accept-Encoding, User-Agent
Content-Encoding: gzip
Content-Length: 104
Server: Jetty(9.4.14.v20181114)
2019-07-12 13:51:30.856 Problem decoding network traffic
java.nio.charset.MalformedInputException: Input length = 1
at java.base/java.nio.charset.CoderResult.throwException(CoderResult.java:274)
at java.base/java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:813)
at com.github.tomakehurst.wiremock.http.trafficlistener.ConsoleNotifyingWiremockNetworkTrafficListener.outgoing(ConsoleNotifyingWiremockNetworkTrafficListener.java:49)
at com.github.tomakehurst.wiremock.jetty9.JettyHttpServer$NetworkTrafficListenerAdapter.outgoing(JettyHttpServer.java:441)`


Implement reciprocal scaling

Reciprocal scaling is x := x/alpha, where x is an array. This operation is, in most cases, preferable to more x := (1/alpha)*x. For instance, the former has less accumulation error.
The technical report on the BLAS Standard, https://netlib.org/blas/blast-forum/blas-report.pdf, proposes the reciprocal scaling to be part of the BLAS. The current LAPACK code has its implementation of RSCL, but it relies on applying the BLAS SCAL to (1/alpha). MKL, for instance, has its own implementation of RSCL.
I think we should have a tlapack::rscl. I can propose the PR. Also, I can propose the PR in LAPACK++ so we can access code from MKL and other optimized libraries.

All good with me.
My preference would be that this goes in BLAS++ instead of LAPACK++. But I do not have a strong opinion.
@mgates3.

Are you proposing that we add an implementation of rscl (or rscale,  in BLAS++, or just a wrapper around these LAPACK routines:
SRC/csrscl.f
SRC/drscl.f
SRC/srscl.f
SRC/zdrscl.f

While rscl is BLAS-like, it exists solely in LAPACK, so I would tend to put it in LAPACK++. Until recently, we put routines in BLAS++ only if they exist in LAPACK/BLAS/SRC (i.e., in -lblas). But this is annoying with routines like [cz]rot, [cz]symv, and [cz]syr that are in LAPACK but the real precisions [sd]rot, [sd]symv, [sd]syr are in BLAS. So recently I'm proposing that we put these in BLAS++ and just require linking with both -llapack -lblas.
Cf. https://bitbucket.org/icl/blaspp/pull-requests/44/removes-crot-and-zrot-since-they-are-not
But since all versions of rscl are in LAPACK, I would keep it in LAPACK++.
There are also these:
SRC/clarscl2.f
SRC/dlarscl2.f
SRC/slarscl2.f
SRC/zlarscl2.f

ZLARSCL2 says it does "scaling on a vector", but from the arguments (M, N, D, X, LDX) it's pretty clear that X is a matrix, not a vector. The docs are super confusing: "The leading dimension of the vector X. LDX >= M." I assume it should be "matrix" instead of "vector".

There are also these:
SRC/clarscl2.f
SRC/dlarscl2.f
SRC/slarscl2.f
SRC/zlarscl2.f

ZLARSCL2 says it does "scaling on a vector", but from the arguments (M, N, D, X, LDX) it's pretty clear that X is a matrix, not a vector. The docs are super confusing: "The leading dimension of the vector X. LDX >= M." I assume it should be "matrix" instead of "vector".

Thanks for indicating this issue. Could you open an issue on LAPACK? I also believe it should read "matrix" instead of "vector".

BTW, to create a new wrapper for LAPACK++, see tools/wrapper_gen.py. It's documented in the script. That handles only routines with 1 data-type prefix like drscl, not ones with 2 data-type prefixes like zdrscl. The quick workaround that I found is to temporarily in LAPACK rename the files:
lapack/SRC> mv zdrscl.f zrscl.f
lapack/SRC> mv csrscl.f crscl.f

The wrappers probably need some fixing, but that should give a good head start.

See https://github.com/Reference-LAPACK/lapack/issues/733


Order t-shirts for Fast Forward

We need tshirts for Fast Forward - this entails contacting vendors and securing a deal.
This issue can be closed once we physically have the tshirts.

I got introduced to Teespring's direct order people and it sounds like they'll give us their lowest rate. I'll CC you on the thread, @ssun098.

Shirts have been ordered!


[Task] Increase golangci-lint timeout

Occasionally, there is a timeout error when running lints with golangci. We should increase the timeout. Perhaps 5m is a good choice.
A failed run: https://github.com/k8s-crafts/ephemeral-containers-plugin/actions/runs/11411562471/job/31756031849?pr=8
References
https://golangci-lint.run/usage/configuration/#run-configuration

can i take this :-) @tthvo

but it is already 5m right?

but it is already 5m right?

Hey @5AIPAVAN, I think the default is 1m (see the timeout field, there is a comment above it) and we do not set it.
https://github.com/k8s-crafts/ephemeral-containers-plugin/blob/cf4ab5be570fb49cf8823e9aa75ec0191e53488a/.golangci.yaml#L1-L9

Please let me know if you still want to work on it^^

chat gpt suggested me to modify .golangci.yaml with linters:
enable:
- errcheck
- gosimple
- govet
- ineffassign
- staticcheck
- unused
- gci
run:
Timeout for analysis, e.g. 30s, 5m.
Default: 1m
timeout: 5m
Exit code when at least one issue was found.
Default: 1
issues-exit-code: 2
Include test files or not.
Default: true
tests: false
is that all

I am interested to fix it.

I am interested in fixing it.

@abuzaforfagun Assigned. Thanks!


ubuntu docker 同步失败

错误日志
System.DllNotFoundException: Unable to load shared library 'dokan2.dll' or one of its dependencies. In order to help diagnose loading problems, consider using a tool like strace. If you're using glibc, consider setting the LD_DEBUG environment variable:
/app/runtimes/linux-x64/native/dokan2.dll.so: cannot open shared object file: No such file or directory
/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.1/dokan2.dll.so: cannot open shared object file: No such file or directory
/app/dokan2.dll.so: cannot open shared object file: No such file or directory
/app/runtimes/linux-x64/native/libdokan2.dll.so: cannot open shared object file: No such file or directory
/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.1/libdokan2.dll.so: cannot open shared object file: No such file or directory
/app/libdokan2.dll.so: cannot open shared object file: No such file or directory
/app/runtimes/linux-x64/native/dokan2.dll: cannot open shared object file: No such file or directory
/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.1/dokan2.dll: cannot open shared object file: No such file or directory
/app/dokan2.dll: cannot open shared object file: No such file or directory
/app/runtimes/linux-x64/native/libdokan2.dll: cannot open shared object file: No such file or directory
/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.1/libdokan2.dll: cannot open shared object file: No such file or directory
/app/libdokan2.dll: cannot open shared object file: No such file or directory
   at DokanNet.Native.NativeMethods.DokanInit()
   at DokanNet.Dokan..ctor(ILogger logger)
   at MDriveSync.Core.Services.AliyunDriveMounter.Mount() in /src/src/MDriveSync.Core/Services/AliyunDriveMounter.cs:line 1276
   at MDriveSync.Core.TimedHostedService.DoWork(Object state) in /src/src/MDriveSync.Core/Services/TimedHostedService.cs:line 114

感谢，正在修复。

感谢，目前非 windows 系统暂不支持磁盘挂载，计划 3.x 版本计划提供支持。
感谢您提供的建议。


feat: Leadership team card component

Note: branched off from component-benefits
Added Leadership team card component
Screenshots

Can you please ping the individuals depicted and ask for their actual social links and if they would like to have them on that page? I think it's an overkill for have so many social links.

Can you please ping the individuals depicted and ask for their actual social links and if they would like to have them on that page? I think it's an overkill for have so many social links.

Totally! I've included all them to see how it looks but already asked HR to curate the relevant links! 👍


Connect-MicrosoftTeams App Only Certificate Based Authentication + New-Team + BadRequest + /me request is only valid with delegated auth flow

I have recently a request from client to convert the token based authentication flow for custom shell scripts to App Only Certificate based authentication. In latest version of Microsoft Teams Shell Module (4.7.1 Preview), I am able to connect to Microsoft Teams and able to run the Get-* commands like Get-Team, Get-TeamChannel etc... But when i run any command with New-* or Set-* i am encountered with error message

VERBOSE: Done performing authorization
VERBOSE: Executing New-Team for parameters Classification:
New-Team : Error occurred while executing
Code: BadRequest
Message: /me request is only valid with delegated authentication flow.

Please fix this issue ASAP as this is very critical for our applications.

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

ID: 32304edf-550b-72a3-57df-6dcc29dba56d
Version Independent ID: 32304edf-550b-72a3-57df-6dcc29dba56d
Content: Application-based authentication in Teams PowerShell Module - Microsoft Teams
Content Source: Teams/teams-powershell-application-authentication.md
Service: msteams
GitHub Login: @pbafna03
Microsoft Alias: pbafna

Same here
New-Team throws error (not working in version 4.8.0 neither)
PS > New-Team -DisplayName "Test Team" -Description "Test Team" -Visibility Private
New-Team : Error occurred while executing
Code: BadRequest
Message: /me request is only valid with delegated authentication flow.
InnerError:
  RequestId: 682e11bc-8140-44ec-a3a5-8141d7bc6563
  DateTimeStamp: 2022-10-13T08:10:22
HttpStatusCode: BadRequest
At line:1 char:1
+ New-Team -DisplayName "Test Team" -Description "Test Team" -Visibilit ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [New-Team], ApiException
    + FullyQualifiedErrorId : Microsoft.Teams.PowerShell.TeamsCmdlets.ErrorHandling.ApiException,Microsoft.Teams.Power
   Shell.TeamsCmdlets.NewTeam

Either fix the problem or advise which correct API permissions must be set for Graph API. But I think "delegated" is wrong for this use case.

Thank you for submitting feedback.
I think the best way forward is if you open a service ticket in your tenant so this can get resolved ASAP. Based on the outcome let me know if it is something that can be called out in the docs.
Please follow this link to contact support for business products:https://docs.microsoft.com/office365/admin/contact-support-for-business-products
Please keep us posted here on the resolution so we can feed whatever information you discover into the content.


python 3.7 error

mocurly depends on a old version of httpretty that doesn't support python 3.7
It requires httpretty <=0.8.10 but at least httpretty 0.9.5 is needed to be compatible with python 3.7 - see https://github.com/spulec/moto/issues/1706 and https://github.com/gabrielfalcao/HTTPretty/pull/339
Error:
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
    yield
  File "/usr/local/lib/python3.7/unittest/case.py", line 628, in run
    testMethod()
  File "/home/circleci/project/ff/mods/billing/tests/test_recurly_integration.py", line 71, in test_cancel_all_subscriptions
    with mocurly():
  File "/home/circleci/project/venv/lib/python3.7/site-packages/mocurly/core.py", line 43, in __enter__
    self.start()
  File "/home/circleci/project/venv/lib/python3.7/site-packages/mocurly/core.py", line 64, in start
    self._register()
  File "/home/circleci/project/venv/lib/python3.7/site-packages/mocurly/core.py", line 165, in _register
    content_type="application/xml")
  File "/home/circleci/project/venv/lib/python3.7/site-packages/httpretty/core.py", line 940, in register_uri
    match_querystring)
  File "/home/circleci/project/venv/lib/python3.7/site-packages/httpretty/core.py", line 762, in __init__
    self.info = URIInfo.from_uri(uri, entries)
  File "/home/circleci/project/venv/lib/python3.7/site-packages/httpretty/core.py", line 732, in from_uri
    result = urlsplit(uri)
  File "/usr/local/lib/python3.7/urllib/parse.py", line 418, in urlsplit
    url, scheme, _coerce_result = _coerce_args(url, scheme)
  File "/usr/local/lib/python3.7/urllib/parse.py", line 123, in _coerce_args
    return _decode_args(args) + (_encode_result,)
  File "/usr/local/lib/python3.7/urllib/parse.py", line 107, in _decode_args
    return tuple(x.decode(encoding, errors) if x else '' for x in args)
  File "/usr/local/lib/python3.7/urllib/parse.py", line 107, in <genexpr>
    return tuple(x.decode(encoding, errors) if x else '' for x in args)
AttributeError: 're.Pattern' object has no attribute 'decode'

We can submit a PR to fix this.

Specifying httpretty==0.9.5 solved the unit test failures for us


Improve coverage

A problem is that @jit functions don't work with coverage...
a workaround is to disable using the NUMBA_DISABLE_JIT environment variable, but breaks the code that use @jitclass and .class_type.instance_type attributes

Fixed by #48


feat(redux): create draft orders redux

Description

In this PR I created the Draft Orders Redux, this include Store, Actions and Selectors.

Dependencies

Checklist

[x] The commit message follows our guidelines
[x] Tests for the respective changes have been added
[x] The code is commented, particularly in hard-to-understand areas
[x] The labels and/or milestones were added

Disclaimer
By sending us your contributions, you are agreeing that your contribution is made subject to the terms of our Contributor Ownership Statement

I know this wasn't included in your PR but I just noticed that the name of the client postDraftOrders should be postDraftOrder instead. Can you include this change here as well, please?

I know this wasn't included in your PR but I just noticed that the name of the client postDraftOrders should be postDraftOrder instead. Can you include this change here as well, please?

Sure, no wories. I list below the changes files. You could check, please?
packages/client/src/checkout/draftOrders/index.ts
packages/client/src/checkout/draftOrders/postDraftOrder.ts
packages/client/src/checkout/draftOrders/tests/postDraftOrder.test.ts
packages/client/src/checkout/draftOrders/types/index.ts
packages/client/src/checkout/draftOrders/types/postDraftOrder.types.ts
packages/redux/src/checkout/draftOrders/actions/createDraftOrder.ts
packages/redux/src/checkout/draftOrders/actions/tests/createDraftOrder.test.ts


Add Klaviyo to Newsletter options.

Hey :wave: !
Full disclosure, I work for Klaviyo! With that said, I am using this template for my own website and thought I would contribute to the repo if you don't mind!;

Happy to accept the contribution! The build is failing due to eslint errors. Could you run npm run lint and push the updated file? Thanks.

@timlrx should be good now, ran npm run lint.


Use curl -L to have trigger_binder follow URL redirect

Description
BinderHub now operates as a Binder Federation and so there is no guarantee where the Binder build will take place. As a result, the Binder trigger must follow any redirect of the URL.
c.f.
https://discourse.jupyter.org/t/problem-triggering-binder-build-through-api-endpoint/1440

@jpivarski This is ready for review. This is a clone of pyhf PR 487.


Update README with clearer and/or suggested AIWB configuration inputs

I had a user trying to start the project who got confused at what to put for those configuration interstitials for the docker socket and for the local NIM cache.
The README does a good job providing a sample input for the latter:

but less so for the former:

I get that there is /var/run specified in the text, but unfortunately not everyone will read all of the text when working through the project.
Another concern is the user OS may require different formatting for these configurations. Maybe a good idea to call these out as well for clarity. For reference, the Hybrid RAG project states the following for a similar flow:

This clarification would be a great addition.
I always put /var/run for /var/host-run but today on a new machine I read that this should be /Docker/host/ because that is where a bunch of docker files were.    (Was in a Windows/WSL environment)