Add more package to package cache.

Addresses #21
I'm not able to add Microsoft.CodeAnalysis.Razor.Workspaces however since it has a PCL dependency: Microsoft.Composition 1.0.27
cc @Eilon @DamianEdwards

LGTM (The identity service part)

Clarified issues with @DamianEdwards offline in person.


Postgresql would not start from a Windows WSL2 host - could not change permissions

Full disclosure I don't really know what I am doing with docker or airflow but wanted to post this in case it helped another Windows user use this project. I was able to build just fine but when running ./mwaa-local-env start it would fail starting postgres_1 with the error:
fixing permissions on existing directory /var/lib/postgresql/data ... initdb: could not change permissions of directory "/var/lib/postgresql/data": Operation not permitted
Following these steps allowed postgres and then airflow to load

docker volume create --name=db-data to create a db-data volume in docker

In file ./docker/docker-compose-local.yml change the line
- "${PWD}/db-data:/var/lib/postgresql/data"
to
- "/db-data:/var/lib/postgresql/data"

I am not sure what side-effects this will have for me. I suppose I can't access the postgres data files from the windows filesystem but I don't think I need to do that anyway.

Well forget all of that I guess. My main misstep was crossing file systems - which is not recommended (1).
When opening the WSL2 Ubuntu terminal it defaults to a Windows filesystem folder. By simply typing cd ~ I am in my home directory under the linux filesystem(1). From there, I can follow the aws-mwaa-local-runner "Get Started" instructions as written and they work great. No docker volume create needed. No modification to docker-compose-local.yml needed.
(1) https://docs.microsoft.com/en-us/windows/wsl/compare-versions#performance-across-os-file-systems

@bradthurber - Huge credit to you for these instructions, which were linked from SO (link: https://stackoverflow.com/questions/71096132/aws-mwaa-postgres-not-reachable-error-when-trying-to-run-a-local-apache-airfl/72416210#72416210).
Yes, you're correct that the line endings had to be changed -- which I did. However, I still had to use your proposed solution above to get past the postgres issue. So thank you for your earlier write-up.
I hope that the main project's github readme someday includes a note on the line endings issue and also somehow fixes the docker-compose-local.yml file to work in Windows, without breaking other OSes.


Image: Unknown format

Describe the bug
Download chapter get "Image: Unknown format" error
Reproduction steps

Use mangal TUI
Choose first source
Input "Nozo"
Choose "Nozo x Kimi"
Select chapter 39
Get the error: "Unknown format"

Expected behavior
Download complete
Additional context
No response
Operating System
Linux

Hello! Thank you for opening an issue. The problem is that PDF converter (default) is unable to transform some image to pdf format. There isn't much I can do about since mangal uses this pdf processor.
Solution
Try other formats such as

plain - just downloads images
cbz - Comic Book Zip format. learn more
zip - Packs images to zip archive

I see, the problem that this chapter has a gif as the last image. That's why it can't be converted to PDF. I'll make an option to exclude such images to avoid errors

I see, the problem is that this chapter has a gif as the last image. That's why it can't be converted to PDF. I'll try to make an option to exclude such images to avoid errors

Thanks 👍 This tool is wonderful and you are awesome 👌


Very minor grammar change

[ X] I have read freeCodeCamp's contribution guidelines.
[X ] My pull request has a descriptive title (not a vague title like Update index.md)
[ X] My pull request targets the master branch of freeCodeCamp.
[ X] None of my changes are plagiarized from another source without proper attribution.
[X ] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Thank you @devinbmiller for your contribution and congratulations on your first PR merge to this repo! 🎉
Hope to see more contributions from you in the future.


Remove hexpubkey references everywhere

And adding a few missing function return signatures.

Is this also deprecating it from getUser, etc? We should 😀

I left it there for now. Just focused on removing NDK's uses of it. I think we need to make sure that we remove it from getUser with a bit more warning.

It's been marked as deprecated for quite a while 😅 but ok, we can keep it for a bit longer

Next release let's make a point in the changelog that the next major (v3) will remove support for hexpubkey entirely.


HIVE-26843: Filter all dependency module descriptors from shaded jars.

What changes were proposed in this pull request?
Filter all dependency module descriptors from shaded jars.
Why are the changes needed?
HIVE-26813 upgraded HikariCP from 2.6.1 to 4.0.3. During review of PR #3839, we discussed the need to omit its module descriptor (module-info.class) from shaded jars. However, it turns out there are also existing instances of module-info.class files from other dependencies like Jackson and Log4J leaking into the shaded jars. We can update the shading filters with wildcards to exclude these and also make it future-proof against any other dependencies that start including a module descriptor.
Does this PR introduce any user-facing change?
Shaded jars will stop including module-info.class files from Jackson, Log4J and any other dependencies. As discussed in the prior PR, it's incorrect for Hive to include these files:
https://github.com/apache/hive/pull/3839#discussion_r1042642131
How was this patch tested?
I ran a build locally:
mvn -Piceberg clean package -DskipTests

Then, I ran the following to iterate through all built jars and check for the presence of module-info.class. It didn't find anything. Prior to this patch, the beeline and JDBC jars contained module-info.class files from Jackson and Log4J.
for x in $(find . -name '*.jar'); do echo $x && jar tf $x | grep 'module-info'; done

Thank you, @zabetak !


[MWPW-135869] Color Page CKG Link List Block

The CKG Link List block now is able to fetch CKG pills and display on color pages
Resolves: MWPW-135869
Test URLs:

Before: https://stage--express--adobecom.hlx.page/express/colors/blue?lighthouse=on
After: https://mwpw-135869--express--adobecom.hlx.page/express/colors/blue?lighthouse=on

Codecov Report

Merging #360 (b62a609) into stage (d143358) will increase coverage by 0.03%.
The diff coverage is 83.33%.

@@            Coverage Diff             @@
##            stage     #360      +/-   ##
==========================================
+ Coverage   31.12%   31.15%   +0.03%
==========================================
  Files         122      122
  Lines       25065    25071       +6
==========================================
+ Hits         7801     7812      +11
+ Misses      17264    17259       -5

Files
Coverage Δ

express/blocks/shared/carousel.js
61.92% <83.33%> (+6.01%)
:arrow_up:

... and 1 file with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Fixed test to target only things we have control over. That said, the test coverage of this block might fluctuate.


Handle Stripe errors

We're bad at handling Stripe errors. We should handle the appropriate errors for our actions rather than allowing them to cause runtime errors.
https://stripe.com/docs/api/python#errors

Closing this as a generally vague goal instead of a specific issue. Our newer usages of Stripe handle errors pretty alright


Missing SharedWorkerGlobalScope

Similar to #24323, the SharedWorkerGlobalScope type is missing in the webworker lib

@jiripudil is there any estimate on when that PR is going to be merged? It's been open for some time, and now that it's blocking this issue I am wondering what the plan was (if there is one)?

@DCtheTall honestly no idea, I don't work for Microsoft 😅

@RyanCavanaugh should I wait for the existing PR or just create a new one

This got merged on the JSTS side, and should be coming up in 3.9


Unable to bind to previously bound port after pod restart (Operation not permitted)

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
An envoy pod binds to several TCP ports, e.g. <IP_ADDRESS>:30539 to act as a tcp proxy. After a pod restart, it is unable to bind to the ports used for the tcp proxy again with the following error:
cannot bind '<IP_ADDRESS>:30539': Operation not permitted

This issue only appears in clusters with Cilium CNI with ebpf kube-proxy-replacement enabled. With other CNIs or with Cilium with iptables/IPVS kube-proxy mode enabled the issue does not appear in the same environment.
When the issue happens, the netstat output in the affected pod does not show that the affected port (30539in this case) would be used:
/ # netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 <IP_ADDRESS>:8002            <IP_ADDRESS>:*               LISTEN      1/envoy
tcp        0      0 <IP_ADDRESS>:9001          <IP_ADDRESS>:*               LISTEN      1/envoy
tcp        0      0 :::8001                 :::*                    LISTEN      -
tcp        0      0 :::8080                 :::*                    LISTEN      -
/ #

Still, binding to the affected port does not work for any application, which can be reproduced e.g. with netcat:
/ # nc -l -p 30539 -s <IP_ADDRESS>
nc: bind: Operation not permitted
/ #

Binding to a different port works fine:
/ # nc -l -p 30540 -s <IP_ADDRESS>
^Cpunt!

/ #

Binding to the affected (non-working) port, but with a different local address (pod IP) works fine:
/ # nc -l -p 30539 -s <IP_ADDRESS>
^Cpunt!

/ #

Envoy config dump: envoy_config_dump.txt
Cilium Version
v1.11.0
Kernel Version
Linux 5.4.0-100-generic #113-Ubuntu SMP Thu Feb 3 18:43:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Kubernetes Version
v1.21.8
Sysdump
Because of a large file, I split it into multiple archives:

cilium-sysdump-20220307-145616.zip
cilium-bugtool-cilium-7fdbm-20220307-145616.zip
cilium-bugtool-cilium-hktpb-20220307-145616.zip
cilium-bugtool-cilium-jfsxd-20220307-145616.zip

Relevant log output
No response
Anything else?
No response
Code of Conduct

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

Hi @gandro,
thanks for the reply.

With kube-proxy-replacement enabled, we're blocking bind calls to any ports used by NodePort in the host namespace, as NodePort BPF will hijack any connections to that port.

The affected pod is not running in the host network namespace, it is a standard pod in its own network namespace.

I am surprised to hear that you don't see this with regular kube-proxy however.

Yes, this has been working for us for years with kube-proxy. It also works with Cilium + kube-proxy-replacement, but only until the affected pod restarts. But as I mentioned, this is not a host network pod.

Thanks. It shouldn't block non-host network pods, that does sound potentially like a bug.
/cc @brb

Ah, I think I understand what's going on: The necessary kernel features to determine the network namespace of the bind call was only added in Linux 5.7 (commit)
Thus, in your setup with kernel 5.4 kube-proxy-replacement is not able to distinguish between the pod and the host namespace and blocks basically all NodePort ports, regardless of the namespace. You can disable the bind protection via node-port-bind-protection CLI flag or ConfigMap option - which will allow processes to bind to the NodePort from the host network namespace, which is not really what you want either.

Thanks @gandro, I can confirm that the issue does not occur on a newer kernel version (tried with 5.13).
What is not clear to me is why the bind to a port from the NodePort range initially works, and only after the pod restart it stops working for the port that was previously working. And the bind still works for a different NodePort (not yet used).

What is not clear to me is why the bind to a port from the NodePort range initially works, and only after the pod restart it stops working for the port that was previously working. And the bind still works for a different NodePort (not yet used).

Cilium only blocks bind calls for ports actually in use, that explains the latter.
We would need more details on your pod restart sequence, but I assume it's a race. Generally speaking Cilium can only block new bind calls. If the socket is already bound when Cilium is started or restarted, then it won't touch already bound sockets.


Sass themes

I am curious what you all think the best way to implement sass themes is. I've been doing some research for webpack + sass and am just interested to hear opinions. Thanks

Use this as an example

Hmmm. I need to import certain themes dynamically and override certain sass variables, that's when I started to question myself a bit

So you want sass to recompile dynamically at runtime? That is way out of the scope of this project.

No, maybe extract multiple css files for each theme and be able ti dynamically include them via HTML @amilajack. Would that make sense?


Add  LICENSE info to README.md

Fixes #3404
Add  LICENSE info to README.md

Is it worth pointing to VENDORED_CODE.md as well?

@dholbach Should I make a separate section for it?

Maybe just add a sentence saying "Find more details about the licenses of vendored code ."

@dholbach Made the changes :)

sorry to be pedantic but i would prefer if we didn't use 'here' links

@akshatnitd ^ Do you think you can take a look at this?

@dholbach Sorry for the delay. Made the change :v:

@dholbach Made the changes :v:


Invalid column metadata

https://connection.keboola.com/admin/utils/logs?file=2017/11/20/16/2017-11-20-16-43-28-5a12f820b1384-exception
https://connection.keboola.com/admin/utils/logs?file=2017/11/20/16/2017-11-20-16-43-28-5a12f820c85d9-log
reason uknown so far, trying to investigate in zendesk https://keboola.zendesk.com/agent/tickets/7595

Table contains a column named level_CASE_when_level_blue_then_1_else_0_END, but the metadata uses this endpoint v2/storage/columns/in.c-leo.jizdenky-vlak.level = CASE when level = 'blue' then 1 else 0 END/metadata. Not sure, who is the culprit though! What created this column name? Extractor or storage?


how do results got such unstable?

For same code untouched, it went with very different.

swapped order of testing functions after first running.
this is the same server with no other job running at the same time.

user@thisisthehost0 ~/proj (main)# cargo criterion
   Compiling proj v0.2.1 (/home/user/proj)
    Finished bench [optimized] target(s) in 8.66s

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Gnuplot not found, using plotters backend
func/AC                 time:   [201.00 us 201.91 us 202.87 us]
                        change: [-1.1117% -0.6052% -0.0672%] (p = 0.02 > 0.00)
                        No change in performance detected.
func/AC-B               time:   [203.46 us 204.87 us 206.34 us]
                        change: [+5.0010% +5.7843% +6.4462%] (p = 0.00 < 0.00)
                        Performance has regressed.

user@thisisthehost0 ~/proj (main)# cargo criterion
   Compiling proj v0.2.1 (/home/user/proj)
    Finished bench [optimized] target(s) in 6.29s

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Gnuplot not found, using plotters backend
func/AC-B               time:   [197.71 us 198.60 us 199.54 us]
                        change: [-3.8500% -3.0601% -2.2261%] (p = 0.00 < 0.00)
                        Performance has improved.
func/AC                 time:   [333.45 us 334.59 us 335.66 us]
                        change: [+64.734% +65.709% +66.591%] (p = 0.00 < 0.00)
                        Performance has regressed.

user@thisisthehost0 ~/proj (main)# cargo criterion
    Finished bench [optimized] target(s) in 0.04s

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Gnuplot not found, using plotters backend
func/AC-B               time:   [189.62 us 189.70 us 189.79 us]
                        change: [-4.9340% -4.4826% -4.0451%] (p = 0.00 < 0.00)
                        Performance has improved.
func/AC                 time:   [338.77 us 339.15 us 339.50 us]
                        change: [+1.0216% +1.3634% +1.7241%] (p = 0.00 < 0.00)
                        Performance has regressed.

user@thisisthehost0 ~/proj (main)# cargo criterion
    Finished bench [optimized] target(s) in 0.06s

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Gnuplot not found, using plotters backend
func/AC-B               time:   [342.98 us 343.28 us 343.54 us]
                        change: [+80.794% +80.955% +81.111%] (p = 0.00 < 0.00)
                        Performance has regressed.
func/AC                 time:   [343.10 us 343.38 us 343.64 us]
                        change: [+1.1138% +1.2482% +1.3831%] (p = 0.00 < 0.00)
                        Performance has regressed.

user@thisisthehost0 ~/proj (main)#

Hello! Thanks for the report.
My honest guess is that this is the result of the compiler making different optimization choices and/or placing different code at different places in the executable. Compilers and linkers and CPU branch predictors are all complex things and seemingly trivial differences in the source code can easily translate into significant differences in execution time.


fix/unstructured

Temporary fix for running application on elastix with unstructured. The final docker image size has increased  after inculding unstructured package and are too big to run in CI/CD pipelines etc making this fix temporary.

@nRamstedt Fixed one of the test for parsing PDF files to also include new lines.
This test will fail with the unstructured version set for this branch but passes with version in main.

revert your commit since it broke test. PR sabotage !!111 :) @zilaei


Ellipsis with ResultDisplay in UI

Seems to only show 3 lines, also sometimes ellipsis appear probably when the extra lines get truncated off.

It is like that by design. I will edit all command messages to fit within 3 lines and put them all into Messages.java for 1.4


Remove Books from New Bookshelf Workflow - Resolving Merge Conflicts

Resolves #327
Supersedes #338

This feature branch needs to be deployed in dev and approved by Jeremy prior to getting merged into the main branch. If needed, create a staging branch for testing purposes.


Returning to activity with parallax

Hello, hopefully this is an easy fix. I setup the parallax and works as i want it to, but my listviews are linked so when you select one, a new activity shows showing more information. the problem is when i return back to the parallax scroll, its super buggy and jumps all over the place. In android studio the logs keep reading "gc_for_alloc freed" do you know how i can fix this or any suggestions would help as well. thanks

i figured it out the problem, i was inflating and setting the adapter again on onResume, and thats what was causing it to behave weirdly


Fix synchronous behavior

Before this library is ready for 1.0.0 we need to fix the synchronous behavior.
Context
By default Vue performs DOM updates asynchronously.  When we created this repo, we took the decision to make it perform updates synchronously, to improve the readability of tests.
The original way that we implemented synchronous DOM updates was by running the instance render watcher when instance properties changed from a wrapper method, like trigger or setProps.
There were two issues with that approach. First, if you made a change that occurred outside of Vue Test Utils, you would need to call an update function that ran watchers.
Secondly, there were bugs with this approach that were difficult to solve, such as watchers running when they should not.
In beta.12 we changed the approach by setting all watchers as synchronous. This approach  has caused a number of bugs  because watchers cannot complete the full lifecycle. Some of these bugs are very difficult to fix.
Solution
I've submitted a PR to Vue core that will allow us to set tests to run synchronously.  This will fix all the current bugs with synchronous.
Problem
The problem is that this change will only be available in Vue > 2.6. This library supports all Vue 2.x versions, so we need to make a decision:
Do we continue with the current buggy synchronous behavior, or remove synchronous behavior for Vue < 2.6 and encourage users to use Vue.nextTick/ setTimeout to run tests?
What do people think?

I think it would be valuable to see a few examples of which tests will need to be modified if the sync behavior is moved. I don't want to write Vue.$nextTick in all my tests, but if is just tests around components with $watch, for example, I think it's okay.
Buggy behavior is never fun to deal with, and since we are still in beta, I think we should work towards where we want the library to be, even if it means a change such as remove the sync behavior. As long as we provide a warning (and possibly a link to what changed, why, and how to fix tests that are failing due to the change) I think it's okay.

I think that it is better to improve sync mounting option and treat its unresolved issues as limitations which is described in document.
Or Providing mock Vue which is added async option by each version and setting alias vue at webpack is resolve this issue.
webpack.test.config.js
// ...
  resolve: {
     alias: {
         vue: vue23-for-test-utils
      }
   }
// ...

I'm currently maintaining a large-ish codebase with ~700 vue tests (jest + test utils beta12) and updating to beta 16 caused quite some strange behavior (still investigating if these are sync bugs and if I can make small repro cases). If my codebase is representative for the potential community I would definitively not introduce sync if it's partially broken (even when it's well documented). It will lead to confusion, lots of subtle/strange bugs that need quite an understanding of the internals of test-utils to solve and probably people not adopting/abandoning vue-test-utils. Better to create a v2.0 when Vue 2.6 is released that is not backwards compatible.

Yes, I think we should remove sync for all Vue versions < 2.6 when we reach 1.0.0.
We can add warnings in the next beta release that sync will be removed to give users time to move tests that rely on synchronous behavior.
There aren't any breaking API changes between Vue 2.x and 2.6, so most users will be able to update to the latest version of Vue and have sync work as expected.

The update broke a number of my tests (about 15 out of 180, with jest) and I have currently no solutions but to make tests less readable or remove them waiting for the synchronous behavior to be coherent.
I'd have appreciated such a major change to wait, but now that it have been implemented, it might be better in the long run to stay with it, although I'm suffering right now from it. I do appreciate however not having to update() during my tests.

I feel that this property is dangerous. The component should not be behaving differently in production and in test.
I was already introducing artificial delays in my tests so it doesn't significantly improve readability for me.

I ran into an issue with this recently in the case of a non sync test. I'll try and get a repro up, but it was something like
<template>
  <Child v-show="shouldShow" />
  <button @click="shouldShow = true"

data () {
  return {
    shouldShow: false

I was asserting find(Child).visible()).toBe(true) after doing trigger('click'), and I had to do setTimeout to get the correct result.
Not sure what was happening, will try and get a minimum repro up (pretty large codebase to pull it out from)

@lmiller1990 Thanks but there's no need for a reproduction, we have several issues with reproduction related to the current synchronous implementation. They will be fixed when Vue 2.6 is released.


"Internal server error" ARC Image Upload

I dont know what changes you made, but now we cant get uploads to work  anymore, even on your own demos it returns a internal server erro... Example of the error as follow
** (exit) an exception was raised:     ** (FunctionClauseError) no function clause matching in Arc.File.new/1         lib/arc/file.ex:5: Arc.File.new(%{"__struct__" => Plug.Upload, "content_type" => "image/jpeg", "filename" => "2016-04-18 16.50.25 HDR-2.jpg", "path" => "/tmp/plug-1474/multipart-380143-369974-1"})         lib/arc/actions/store.ex:9: Arc.Actions.Store.store/2         lib/arc_ecto/type.ex:5: Arc.Ecto.Type.cast/2         (ecto) lib/ecto/type.ex:564: Ecto.Type.cast/2         (ecto) lib/ecto/changeset.ex:464: Ecto.Changeset.cast_field/8         (ecto) lib/ecto/changeset.ex:423: Ecto.Changeset.process_param/8         (elixir) lib/enum.ex:1247: Enum."-map_reduce/3-lists^mapfoldl/2-0-"/3         (elixir) lib/enum.ex:1247: Enum."-map_reduce/3-lists^mapfoldl/2-0-"/3

Did not mean to sound harsh or anything, im sorry if i did.

@smpallen99 I've tracked the issue down to this commit:
https://github.com/smpallen99/ex_admin/commit/5c1bf64f19767f709b8608e3e2fe81e8e420945d
Arc is pattern matching on a Plug struct (i.e. atoms with keys) but param_stringify_keys/1 is converting the Plug struct to a map where the keys are now strings.

Sorry @smpallen99 I missed this PR #184 for the fix.

Fix merged: https://github.com/smpallen99/ex_admin/commit/ae45f042082f5d1f9b80474ef27beff2a43b568e


opening book policy for multiple engines tournament

in a multiple engines tournament, ideally each pair of engines uses the same openings. so engine A vs Engine B and Engine A vs Engine C should get the same opening order. this is currently not the case as the opening book index is currently incremented by rounds

what is cutechess doing in this case?

what is cutechess doing in this case?

it has multiple different policys for this but i think we just need to implement the default https://github.com/cutechess/cutechess/blob/master/docs/cutechess-cli.6.txt#L197-L201

I think the easiest way to do this is to make the matchmaking so that all matches between two engines are played first before it moves on to the next pairing

i think you only need to refetch a new opening if the round increases ? https://github.com/Disservin/fastchess/blob/master/app/src/matchmaking/tournament/roundrobin/match_generator.hpp#L57

Yeah but rn the round increases every two games so say if engine A vs engine B is round 1 then engine A vs engine C is round 2 so the opening for the 2nd pairing would be different from the first


stuck trying to compile  a simple  java souce code in kubevirt vm

What happened:
I have a cluster, which do not support  hardware emulation, so use software emulation ,it like this,

then run a vm(centos7) in cluster, like this,

after a while, vm in running, but when i use javac to compile a very simple java code, it stuck forever,

why ? Does this have anything to do with software simulation?
What you expected to happen:
javac  can compile the java source code without stucking
How to reproduce it (as minimally and precisely as possible):
Steps to reproduce the behavior.
Additional context:
Add any other context about the problem here.
Environment:

KubeVirt version (use virtctl version): Client Version: version.Info{GitVersion:"v0.39.0", GitCommit:"6493f7130788fc2242f0ebbda2ace06dc12a4ad0", GitTreeState:"clean", BuildDate:"2021-03-10T15:29:59Z", GoVersion:"go1.13.14", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{GitVersion:"v0.37.1-dirty", GitCommit:"f270b5befe16c20a11c34f22efecf2407f9591bc", GitTreeState:"dirty", BuildDate:"2021-01-21T20:13:15Z", GoVersion:"go1.13.14", Compiler:"gc", Platform:"linux/amd64"}
Kubernetes version (use kubectl version): Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.9", GitCommit:"9dd794e454ac32d97cde41ae10be801ae98f75df", GitTreeState:"clean", BuildDate:"2021-03-18T01:09:28Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.9", GitCommit:"9dd794e454ac32d97cde41ae10be801ae98f75df", GitTreeState:"clean", BuildDate:"2021-03-18T01:00:06Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"linux/amd64"}
VM or VMI specifications:  apiVersion:
kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
name: centos7-cpu-test
namespace: bom-vir
spec:
running: false
template:
metadata:
annotations:
descheduler.alpha.kubernetes.io/evict: "true"
labels:
kubevirt.io/domain: u18
special: key11
spec:
domain:
cpu:
cores: 2
devices:
inputs:
- bus: usb
type: tablet
name: tablet1
disks:
- bootOrder: 1
disk:
bus: sata
name: pvcdisk
- bootOrder: 2
cdrom:
bus: sata
name: cdromiso
#- disk: {}
#name: app-config-disk
# serial: CVLY623300HK240D
machine:
type: q35
resources:
requests:
memory: 4Gi
volumes:
- name: cdromiso
persistentVolumeClaim:
claimName: iso-linux
- name: pvcdisk
persistentVolumeClaim:
claimName: centos7-cpu-test
Cloud provider or hardware configuration: N/A
OS (e.g. from /etc/os-release): NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

Kernel (e.g. uname -a):  Linux ceph0 5.4.125-1.el7.elrepo.x86_64 #1 SMP Wed Jun 9 15:53:21 EDT 2021 x86_64 x86_64 x86_64 GNU/Linux
Install tools: N/A
Others:
in vm

NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"
2.Kernel
Linux centos7-cpu-test 3.10.0-1160.el7.x86_64 #1 SMP Mon Oct 19 16:18:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
3.jdk
openjdk version "1.8.0_322"
OpenJDK Runtime Environment (build 1.8.0_322-b06)
OpenJDK 64-Bit Server VM (build 25.322-b06, mixed mode)

Emulation commonly causes edge cases like this. Can you perhaps re-test in a plain non-kubevirt qemu emulated VM to see if the behavior is the same or different from what you are seeing in Kubevirt?
Thank you

Yes, software emulation is slow but it should not get stuck while compiling a hello world. Would it be possible to fetch the kubevirt's logs to when the VM get's stuck?

yes, the problem still exists when i try with  qemu which does not  use hardware virtualization


Native argument passing adjustments for Windows systems

PR Summary
This PR targets a consistent default behavior between PowerShell 5 and PowerShell 7 on Windows for some executables and file types. The behavior is now update to use the legacy behavior for the following files:

cmd.exe
cscript.exe
wscript.exe
ending with .bat
ending with .cmd
ending with .vbs

This list is table driven, and can be easily altered. I have started with this list as I am familiar with real world issues with them.
The PSNativeArgumentPassing preference value has been expanded to include the new value Windows.  When the preference variable is set to Windows the above table will be in effect, meaning that invocations of those files will automatically use the Legacy style argument passing. If the PSNativeArgumentPassing is set to either Legacy or Standard, then the additional checks will not take place.
The default behavior is now also platform specific. On Windows platforms, the default setting will be Windows and non-Windows platforms will be Standard.

PR Context

PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[ ] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[ ] None
OR
[ ] Experimental feature(s) needed

[x] Experimental feature name(s): PSNativeCommandArgumentPassing

User-facing changes

[ ] Not Applicable
OR
[x] Documentation needed

[ ] Issue filed:

Testing - New and feature

[ ] N/A or can only be tested interactively
OR
[x] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[x] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
OR
[ ] I have considered the user experience from a tooling perspective and opened an issue in the relevant tool repository. This may include:

[ ] Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode
(which runs in a different PS Host).

[ ] Issue filed:

[ ] Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.

[ ] Issue filed:

[ ] Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).

[ ] Issue filed:

[ ] Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

[ ] Issue filed:

I believe this PR addresses part of https://github.com/PowerShell/PowerShell/issues/15143

@SteveL-MSFT - I think I've addressed your issues, please let me know

@JamesWTruher one comment was not addressed

I'm not sure this working completely for .bat files.  preview.6 breaks the Invoke-BatchFile command we have implemented in PSCX:
PS> invoke-batchfile 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvarsall.bat' amd64
'\"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvarsall.bat\"' is not recognized as an internal or external command,
operable program or batch file.

This is basically Lee Holmes old function that we have implemented in PSCX:
function Invoke-BatchFile
{
    param([string]$Path, [string]$Parameters)

    $tempFile = [IO.Path]::GetTempFileName()

    ## Store the output of cmd.exe.  We also ask cmd.exe to output
    ## the environment table after the batch file completes
    cmd.exe /c " `"$Path`" $Parameters && set " > $tempFile
    ...
}

@rkeithhill isn't that just because you're passing $Parameters as a single string? If you expected multiple args I'd expect that parameter to be [string[]] and to pass each parameter separately, myself... though I know passing a space-separated string does sometimes work currently.

@rkeithhill wrt the pscx issue that you mentioned. Have you tried running this branch against your scenario? This PR is supposed to automatically put the arg passing into legacy mode for cmd.exe invocations, so it should be fine (but I would really like confirmation on that). I've added validation for that very scenario, but I might have missed something.

I built this branch and yes, that command works now while I still have the mode set to Windows:

@rkeithhill - excellent - the default setting for windows will be "Windows", which is the hybrid model where certain commands will run as Legacy while others will use "Standard". This should hopefully be better and allow the wacky parsing that happens for batch files, but enable more modern apps to use the new style.

@SteveL-MSFT

I believe this PR addresses part of #15143

I haven't looked at the code, but judging by this PR's description, it doesn't:

cmd /c $someCommandLine (e.g., cmd /c 'echo "hi there"') never needed fixing - it is the only case that always worked correctly - serendipitously, because PowerShell's non-escaping of embedded " happens to be canceled out by cmd.exe's "quirky" parsing.

Conversely, it mustn't be broken in any mode (it currently is broken in Standard mode - see #15239).

Therefore, none of the truly new accommodations proposed in #15143 are seemingly addressed by this PR.

Conversely, selectively reverting to the - hopelessly broken - legacy behavior just means replacing an old mess with a new one (and a more confusing one at that).

The only way to avoid a mess is to:

Stick with two modes: Legacy vs. Standard.

In Standard mode, implement all accommodations proposed in  #15143 - this should make the vast majority of calls that  (rightfully) rely on PowerShell syntax only just work; for the rest, --% or a (non-broken) cmd /c $someCommandLine allow full control over the command line passed on Windows.

And as for the proposed default values for $PSNativeCommandArgumentPassing:
(I'm aware of the irony of saying this, given that I have often pushed for breaking changes.)
While I'm personally fine with defaulting to the new behavior (assuming it is sensibly implemented), which will undoubtedly make future users happy, existing users with legacy code should brace for a massively breaking change.

@mklement0 the purpose of this PR is to augment the NativeCommandArgumentPassing experimental feature so that cmd (and some others) are special cased when using Windows mode for argument passing which falls back to legacy behavior.  Windows mode will be default on Windows.
The big feedback we got from customers using a PS7 preview in production is that they can't simply move to a brand new arg passing model as they need to support both WinPS5.1 and PS7.  Since 5.1 will still be used quite a bit for a long time, AND we expect users of 5.1 have already worked out workarounds needed that they would expect to continue to work in 7.2, reverting to legacy when using Windows and the allow list (cmd, js, etc...) would be the most compatible.

@SteveL-MSFT, i can see only 3 scenarios, and none of them are helped by what this PR proposes - on the contrary:

(a) Users who are unencumbered with respect to legacy code:

They can use Standard mode - as modified by #15143 - and live happily ever after.

(b) Users who use legacy code they cannot update / don't want to spend time updating, but needn't worry about future code they write being backward-compatible with Windows PowerShell:

They can selectively use Legacy mode - for the legacy code - and live happily ever after.
That said, selectively applying a preference variable is hampered by cross-scope-domain code not honoring the caller's preference variables - see #4568 - but that's a separate debate.

(c) Users who must continue to author code that also runs in Windows PowerShell.

They can use Legacy mode consistently - which, as before, is cumbersome and requires obscure workarounds, but that's an unavoidable price to pay.
The pain can be mitigated via a helper function that emulates the new Standard behavior (as modified by #15143), such as the ie function from the Native module. (Believe me, this isn't about promoting my module's function; it just so happens to be the least painful solution that I know of; in an ideal world there would never have been a need for such a function.)

Let's be clear that the proposed Windows mode will still break a good deal of existing code based on legacy workarounds, namely all calls to executables / interpreters not in the table of exceptions, such as Node.js, for instance.
In Windows mode, having to reason with respect to a given call whether the legacy or the new behavior applies only complicates matters - the example I've given before is the az CLI, which just so happens to be implemented as az.cmd, i.e. as  a batch file. But that is an implementation detail that no user should have to pay attention to or should even need to be aware of.

To flesh out my previous concern:
My guess is that many existing workarounds on Windows  do not relate to the executables in the fallback-to-legacy tables, and such workarounds will simply break with Windows in effect; e.g.:
# *Workaround* that works up to v7.1, but breaks with a `$PSNativeCommandArgumentPassing` value
#  other than 'Legacy'.
curl.exe https://httpbin.org/post -d '{ \"foo\": \"bar\" }' -H 'Content-Type: application/json'

# Ditto.
node -e 'console.log(\"hi\")'

And, of course, with Standard as the default on Unix, all existing workarounds will break - but the real concern is the confusing blending of correct and broken legacy behavior on Windows in the form of the ill-begotten Windows mode, depending on how the target executable happens to be implemented.
And even if you do know what behavior applies, that you selectively have to revert to workarounds for broken behavior - even though PowerShell could implement the correct behavior - sounds like a cruel joke.
Again: for someone who needs to continue to author code for both editions, sticking with Legacy and the known workarounds consistently is by far the simpler solution.
Someone who needs to selectively run old code can activate Legacy selectively (or reverse the logic: activate Standard selectively).
That PowerShell lacks lexical scoping for preferences and, conversely, a cross-module mechanism for setting preferences, and therefore makes their selective application challenging is unfortunate, but not specific to the problem at hand.
Ultimately, I think, the only headache-free way out of this mess is via a distinct call operator or function that selects either the legacy or the (consistently) correct behavior: then each call's behavior can easily reasoned about by itself, and doesn't depend on possibly hidden state through dynamically scoped preferences.
Of course, the challenges are (a) what operator sigil or function name to come up with, and (b) the separate operator/function serving as a perennial reminder that the original implementation was broken.

This is such a dumpster fire, like I use powershell because I couldn't care less about cmd, I just wanted it to die.
(who writes batch files ? they are all considered broken anyway, but I do understand they need to be supported, just not at the expense of the evolution of Powershell, otherwise I'll just plug my own NativeCommandProcessor, wait there's no way to extend custom command processors, that would be a neat feature for solving those nastiness, like create a CmdCommandProcessor already and keep it away from the rest of powershell !)
Please don't break $PSNativeCommandArgumentPassing by setting it to other than Standard or worse, making it do shenanigans other than passing all the arguments directly to Process-Start args collection.
cinst powershell.core
pwsh
& something 'should just work'

All I was doing was just trying to make my CMake powershell build script run multiplatform, with support for VT, and redirecting the error output with performance, but that's another problem, I made my own CmdLet for this on top of the start process, I was looking for something like Native to solve this nastiness.
I guess, it would be easier to recompile CMake with a parameter like EncodedCommand that passes a single Base64 string.
Perhaps this is the only way...

@PowerShell/powershell-committee discussed the feedback, we would be concerned about trying to abstract all known workarounds on Windows given the inconsistency of how native commands handle escaping.  The intent of this PR is to address a known impact raised by users of this experimental feature.  In the example of:
curl.exe https://httpbin.org/post -d '{ \"foo\": \"bar\" }' -H 'Content-Type: application/json'
node -e 'console.log(\"hi\")'

Users who want to maintain known workarounds, they should use Legacy.  With Windows mode (or Standard) they would not need to escape the double quotes:
curl.exe https://httpbin.org/post -d '{ "foo": "bar" }' -H 'Content-Type: application/json'
node -e 'console.log("hi")'

Based on real world user feedback, we agreed to address some well known and used legacy apps like wscript and cmd for Windows mode.  We will evaluate any new feedback as separate issues/discussion from using this experimental feature.

Reassigning to @rjmholt as @daxian-dbw is taking time off right now

Opened https://github.com/JamesWTruher/PowerShell-1/pull/15 to add remaining suggested changes

/azp run


NCCL Issue on v0.4.20

Description
I updated to v0.4.20, and I got the following error on some training.
jaxlib.xla_extension.XlaRuntimeError: INTERNAL: Failed to execute XLA Runtime executable: run time error: custom call 'xla.gpu.all_reduce' failed:
external/xla/xla/service/gpu/nccl_utils.cc:133: NCCL operation ncclGetUniqueId(&id) failed: Unable to load NCCL library. Multi-GPU collectives will not work.;
current tracing scope: all-reduce-start; current profiling annotation:

This code could run v0.4.16.
Python version is 3.11.51
CUDA version is 12.2.
CUDNN version is 8.9.5
I tested with v0.4.19 and got the same error.
I might have some issues, but I can fix them with your help!
Thanks.
What jax/jaxlib version are you using?
jax v0.4.20, jaxlib v0.4.20
Which accelerator(s) are you using?
GPUs
Additional system info
Ubuntu 22.04.3
NVIDIA GPU info
Sun Nov  5 19:14:08 2023
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 525.125.06   Driver Version: 525.125.06   CUDA Version: 12.0     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  NVIDIA A100-SXM...  On   | 00000000:07:00.0 Off |                    0 |
| N/A   33C    P0    52W / 400W |      0MiB / 40960MiB |      0%      Default |
|                               |                      |             Disabled |
+-------------------------------+----------------------+----------------------+
|   1  NVIDIA A100-SXM...  On   | 00000000:0F:00.0 Off |                    0 |
| N/A   33C    P0    56W / 400W |      0MiB / 40960MiB |      0%      Default |
|                               |                      |             Disabled |
+-------------------------------+----------------------+----------------------+
|   2  NVIDIA A100-SXM...  On   | 00000000:47:00.0 Off |                    0 |
| N/A   35C    P0    63W / 400W |      0MiB / 40960MiB |      0%      Default |
|                               |                      |             Disabled |
+-------------------------------+----------------------+----------------------+
|   3  NVIDIA A100-SXM...  On   | 00000000:4E:00.0 Off |                    0 |
| N/A   32C    P0    51W / 400W |      0MiB / 40960MiB |      0%      Default |
|                               |                      |             Disabled |
+-------------------------------+----------------------+----------------------+
|   4  NVIDIA A100-SXM...  On   | 00000000:87:00.0 Off |                    0 |
| N/A   33C    P0    54W / 400W |      0MiB / 40960MiB |      0%      Default |
|                               |                      |             Disabled |
+-------------------------------+----------------------+----------------------+
|   5  NVIDIA A100-SXM...  On   | 00000000:90:00.0 Off |                    0 |
| N/A   34C    P0    53W / 400W |      0MiB / 40960MiB |      0%      Default |
|                               |                      |             Disabled |
+-------------------------------+----------------------+----------------------+
|   6  NVIDIA A100-SXM...  On   | 00000000:B7:00.0 Off |                    0 |
| N/A   34C    P0    54W / 400W |      0MiB / 40960MiB |      0%      Default |
|                               |                      |             Disabled |
+-------------------------------+----------------------+----------------------+
|   7  NVIDIA A100-SXM...  On   | 00000000:BD:00.0 Off |                    0 |
| N/A   35C    P0    54W / 400W |      0MiB / 40960MiB |      0%      Default |
|                               |                      |             Disabled |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

I confirmed there is this issue from v0.4.18.

After I add "nvidia-nccl-cu12>=2.19.3", I can run with the latest release.
I'll close this issue.
Thanks

I'll also note that  if you use the cuda12_pip install, it would have installed this for you. I'm guessing you used the cuda12_local install, which requires you (newly) to install NCCL yourself.


Coherence Operator Pod keeps restarting

When upgrading the Operator from 2.0.1 to 2.0.2, I saw some issues where the operator pod was repeatedly restarting, see the logs from the pods below:
W1118 22:24:59.015756       1 reflector.go:270] pkg/mod/k8s.io/client-go@v0.0.0-20190228174230-b40b2a5939e4/tools/cache/reflector.go:95: watch of *v1.CoherenceCluster ended with: too old resource version: 428512 (428627)
log: exiting because of error: log: cannot create log: open /tmp/coherence-operator.args-coherence-operator-695f64855f-jlm86.unknownuser.log.WARNING.20191118-222459.1: no such file or directory
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T23:41:55Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T19:09:08Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}
This has since stabilised, so it may be a transient issue.

logs-from-coherence-operator-in-coherence-operator-74cb5f9dd8-4mjdz.txt
Attached more comprehensive operator log

The error in the logs is coming from a component that is way down in the guts of k8s and not something that is part of our code base. From searching the internet for similar issues it appears that it is a problem with the logging library used by one of the k8s components where it tries to access a log file to log the warning.
We cannot just change the version of that particular library we can only move to a newer version of the Operator SDK (which is on a newer version of the k8s libraries) and see whether that improves things. Moving Operator SDK versions is not a trivial task and would be a few days work (assuming it goes smoothly).

I'm closing this as I believe the changes in 2.0.3 have resolved the issue


ic_launcher icon does not render in navigation header

Actual Behaviour
ic_launcher icon does not render in navigation header in apk generated by apk generator.
Expected Behaviour
ic_launcher icon should render in navigation header.
Steps to reproduce it

Generate apk from samples provided in https://github.com/fossasia/open-event/tree/master/sample through apk generator.
Open navigation drawer.

Screenshots of the issue

Would you like to work on the issue?
yes

This is happening because ic_launcher image is too big to render.
Apk generator directly resize file by asuming that logo.png provided in sample is ldpi size and with reference to it generates  mdpi,hdpi format.
Whether should I make change in apk generator to resize logo image to size required for app OR should I make change in app to resize the image generated by apk generator?

The generator should already be resizing the images, it not, please fix the generator

@iamareebjamal I found that logo_url used in googleio17 sample is /images/io_logo.png and it is not able to download image using that url so image does not render. I added on error resource id in setNavHeader function and made PR. Please Review.

Then it is not the issue with the app, rather with the sample

@iamareebjamal I think even if this is issue of sample, It is good to set error image rather than showing blank instead(There may happen any kind of error during downloading image from url).

Agreed


Check holiday calendar for USD-FED-FUND index

The holiday calendar for this index is NYFD. Some of the datasets I'm working with only include the USNY for New York which causes pricing to fail.
Is this holiday calendar ID correct? Is it effectively an alias for USNY?

ISDA distinguishes between New York Fed (NYFD) and  NYSE.
2006 ISDA Definitions Section 1.9 and 1.10
FpML distinguishes between New York Fed (NYFD),  NYSE and USNY.
I don't see USNY referenced in the 2006 ISDA Definitions.

On Apr 6, 2016, at 11:48, Chris Kent<EMAIL_ADDRESS>wrote:
The holiday calendar for this index is NYFD. Some of the datasets I'm working with only include the USNY for New York which causes pricing to fail.
Is this holiday calendar ID correct? Is it effectively an alias for USNY?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub https://github.com/OpenGamma/Strata/issues/892

I've looked into it further and I think the holiday data is incomplete. In the old platform (which is where the data came from) the USNY calendar was used for the USD-FED-FUND index so it wouldn't have been necessary to include the NYFD data.


[TACHYON-360] Rename default local underFS to underFSStorage

https://tachyon.atlassian.net/browse/TACHYON-360
Its confusing since we now have a submodule named underfs.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Tachyon-Pull-Request-Builder/2941/
Test PASSed.


runtime: marked free object in span pointing to runtime.gopark variable

Go version
go version go1.16.12 linux/amd64
Output of go env in your module/workspace:
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/root/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/root/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16.12"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/fabric/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1903424306=/tmp/go-build -gno-record-gcc-switches"

What did you do?
Ran compiled go executable and it failed with panic leading to coredump in gopark method
What did you see happen?
The go executable crashed and generated this error message
runtime: marked free object in span 0x7f9998cec878, elemsize=32 freeindex=0 (bad use of unsafe.Pointer? try -d=checkptr)
0xc00002e000 alloc marked
...
0xc00002e540 alloc marked
0xc00002e560 free  marked   zombie
000000c00002e560:  00c0008000a00001<PHONE_NUMBER>000001
000000c00002e570:  000000c00027ca80  000000c00029a400

this memory location c00002e560 is found in the error dump to point to a variable created for runtime.gopark
goroutine 12 [GC worker (idle), 2270 minutes]:
runtime.gopark(0xac54a8, 0xc00002e560, 0x1418, 0x0)
	/usr/local/go/src/runtime/proc.go:336 +0xe5 fp=0xc00038f760 sp=0xc00038f740 pc=0x446525
runtime.gcBgMarkWorker()
	/usr/local/go/src/runtime/mgc.go:1911 +0xfb fp=0xc00038f7e0 sp=0xc00038f760 pc=0x42ae9b
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1371 +0x1 fp=0xc00038f7e8 sp=0xc00038f7e0 pc=0x47acc1
created by runtime.gcBgMarkStartWorkers
	/usr/local/go/src/runtime/mgc.go:1835 +0x37

mgc.go:1911 is this line of code
gopark(func(g *g, nodep unsafe.Pointer) bool {
    …
}, unsafe.Pointer(node), waitReasonGCWorkerIdle, traceEvGoBlock, 0)

where node is created just earlier in this function with
node := new(gcBgMarkWorkerNode)

this appears to be issue with golang runtime marking a unsafe.Pointer it created as marked free
What did you expect to see?
that the executable would not crash and point to golang runtime module.

go version go1.16.12 linux/amd64

Go 1.16.12 is very old and no longer supported. Could you try using a more up-to-date version of Go, Go 1.21.6 or Go 1.22RC2? Thanks.

Tentatively closing. Feel free to reopen if you can reproduce the failure on an up-to-date version of Go. Thanks.

@Grant-Frame can you share the code with me, i'm interested in it. i happened to see the same issue in go1.17 too, for some reason we can't upgrade go.


fix(standards): Fix type bugs in test

Error in api-exploerer-client will be fixed in another PR soon.


Issue 3

Settings -> info -> update
and no thinking is happening, no info etc..

mistake in mopidy.conf - corrected

the problem is still open...

done


[BUG] Delta table on S3 doesn't delete historical log files (using GLUE and EMR)

Bug
Delta table property 'delta.logRetentionDuration'='interval 7 days' doesn't take effect using AWS glue catalog (external table) and EMR.
Describe the problem
We are using Databricks Delta lake open source io.delta:delta-core_2.12:1.0.0 on AWS EMR (6.5.0) Spark (3.1.2) integrated with S3, Glue and Athena, with the following properties -
TBLPROPERTIES (
  'delta.autoOptimize.autoCompact'='true',
  'delta.autoOptimize.optimizeWrite'='true',
  'delta.compatibility.symlinkFormatManifest.enabled'='true',
  'delta.logRetentionDuration'='interval 7 days',
  'spark.databricks.delta.retentionDurationCheck.enabled'='true',
  'spark.sql.create.version'='3.1.2-amzn-1',
  'spark.sql.partitionProvider'='catalog',
  'spark.sql.sources.schema.numPartCols'='1',
  'spark.sql.sources.schema.numParts'='1',

As mentioned at the official doc -
delta-vacuum
delta-utility
For the Log files - "Log files are deleted automatically and asynchronously after checkpoint operations. The default retention period of log files is 30 days, configurable through the delta.logRetentionDuration property which you set with the ALTER TABLE SET TBLPROPERTIES SQL method."
I set the table property as suggested but nevertheless log files for more then 7 days are not being deleted automatically neither after I execute deltaTable.vacuum(retentionDuration) or  deltaTable.generate("symlink_format_manifest")
Log files location - s3://xxxx/database/my_table/_delta_log/
Steps to reproduce

Launch AWS EMR cluster

Launch Spark-shell
spark-shell --packages io.delta:delta-core_2.12:1.0.0 --conf spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension --conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog --conf spark.sql.caseSensitive=true

Initialize delta table with data

:paste
val input = "s3://my_bucket/initial_data/"

val schema: StructType = StructType(
      StructField("ts", StringType, nullable = true) ::
	  StructField("database", StringType, nullable = true) ::
      StructField("type", StringType, nullable = true) ::
      StructField("data", StringType, nullable = true) ::
      StructField("table", StringType, nullable = true) :: Nil)

val key: StructType = StructType(
    StructField("id", StringType, nullable = true) :: Nil)

val df2 = spark.read.schema(schema).json(input)
.withColumn("struct",from_json(col("data"), key))
.select("table","struct.id","ts","database","type","data")
df2.printSchema()

:paste
val output = "s3://my_bucket/my_db/delta_table/"

df2
.write
.partitionBy("table")
.format("delta")
.save(output)

Create glue external table

:paste
import io.delta.tables.DeltaTable

val tbl = "delta_table"
val bucket = "my_bucket"
val db = "my_db"
val output_path = s"s3://${bucket}/${db}/maor/${tbl}/"
val deltaTable = DeltaTable.forPath(output_path)

deltaTable.generate("symlink_format_manifest")

spark.sql(s"""
CREATE EXTERNAL TABLE ${db}.${tbl}
(id string, ts string, database string, type string, data string)
PARTITIONED BY (table string)
ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'
STORED AS INPUTFORMAT 'org.apache.hadoop.hive.ql.io.SymlinkTextInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION '${output_path}/_symlink_format_manifest/'
""")

spark.sql(s"""ALTER TABLE ${db}.${tbl} SET TBLPROPERTIES(delta.compatibility.symlinkFormatManifest.enabled=true)""")
spark.sql(s"""ALTER TABLE ${db}.${tbl} SET TBLPROPERTIES(delta.logRetentionDuration="interval 1 hours")""")
spark.sql(s"""ALTER TABLE ${db}.${tbl} SET TBLPROPERTIES(delta.deletedFileRetentionDuration="interval 1 hours")""")
spark.sql(s"""ALTER TABLE ${db}.${tbl} SET TBLPROPERTIES(spark.databricks.delta.retentionDurationCheck.enabled=true)""")
spark.sql(s"""ALTER TABLE ${db}.${tbl} SET TBLPROPERTIES(delta.autoOptimize.optimizeWrite=true)""")
spark.sql(s"""ALTER TABLE ${db}.${tbl} SET TBLPROPERTIES(delta.autoOptimize.autoCompact=true)""")

spark.sql(s"msck repair table ${db}.${tbl}")

Go to Athena and check the table exists

SELECT
    "table", count(*)
FROM
    test_dbl.delta_table
group by
    1
order by
    count(*)

Go back to spark-shell and update the delta table in order to generate new log files.

import io.delta.tables._

val df = spark.read.json(input)
.withColumn("struct",from_json(col("data"), key))
.select("table","struct.id","ts","database","type","data")

val dt = DeltaTable.forPath(output_path)
val dmb: DeltaMergeBuilder = dt.as("dt_source").merge(df.as("df_new_data"), "dt_source.table = df_new_data.table and dt_source.id = df_new_data.id")

dmb
.whenMatched.updateAll()
.whenNotMatched.insertAll()
.execute()

Do step 6 multiple times to produce multiple logs files at -
s3://my_bucket/my_db/delta_table/_delta_log/

Expect NOT to see logs files.

Observed results
Nothing happens
Expected results
I would expect that historical and untracked logs files will be deleted after I execute deltaTable.vacuum(retentionDuration) or  deltaTable.generate("symlink_format_manifest")
Further details

Environment information

Delta Lake version: io.delta:delta-core_2.12:1.0.0
Spark version: 3.1.2
Scala version: 2.12
EMR version: 6.5.0

Willingness to contribute
The Delta Lake Community encourages bug fix contributions. Would you or another member of your organization be willing to contribute a fix for this bug to the Delta Lake code base?

[ V ] No. I cannot contribute a bug fix at this time.

Hey @maor-sa, let me first clarify a few things. deltaTable.vacuum(retentionDuration) only removes data files, and not the delta log files (see Data retention). Delta log files are instead removed automatically after checkpoints (based on the table property that you've set 'delta.logRetentionDuration'='interval 7 days').
Checkpoints are by default generated every 10 commits (or every 10 operations on the table) but this can be configured with the table property delta.checkpointInterval. Can you confirm that you are writing to the table after this 7 day duration has passed (or whatever else you set the interval to) and generating a checkpoint, and you still aren't seeing the older log files removed? You can check whether a checkpoint has been generated by looking in the _delta_log directory for the parquet checkpoint files.
If you aren't generating a checkpoint after the log retention duration has elapsed you are seeing the expected behavior. By the way, deltaTable.generate("symlink_format_manifest") isn't an operation on the table and wouldn't generate a checkpoint or trigger log clean up.

Hey @allisonport-db
I can confirm everything:

I know and I expect that delta log files will be removed automatically JUST after the checkpoint was created and after the 7 days duration has  passed. Unfortunately they aren't.
I also approached AWS official services, they replicate the issue and replied "Currently there is no Databricks integration on EMR which is natively supported."

Thanks

Okay thanks for confirming. We will look into this.

Do you have any delta tables older than 30 days? If so, can you check if the log files are being removed for those after the 30 day interval.
Also keep in mind, we don't necessarily remove all log files older than logRetentionDuration, as some may still be needed for time travel.
Could you please provide the _delta_log directory listing for one of the tables?

Great,
Currently I don't have log files for more than 20 days, in 10 more days I'll have and I'll provide a directory link.
Thanks,
Maor

If you provide the listing for a table with logRetentionDuration=interval 7 days that will still help. And then we can follow up once that 30 day duration has passed as well

Hey @MarcBertini is it cleaning up the logs correctly after the default 30 day interval? It would be ideal to pinpoint whether this is an issue with the log cleanup, or with the table property logRetentionDuration.
Again, a directory listing of the _delta_log along with the table properties for that table would help a lot.

Please see the attched listing.  The value has to be stored in delta transaction logs. Storing it only in Glue won't work. The command to set this would be ALTER TABLE such as ALTER TABLE <table> SET TBLPROPERTIES ('delta.logRetentionDuration' = 'interval 7 days').
Can you try to run DESCRIBE DETAIL on the table and check the value of the properties column (does it have delta.logRetentionDuration and is the value correct)? This is the way to verify whether your setting is working or not.

Closing this as there is no update. Feel free to re-open if you can provide more information.


Added events

Added touchmove for mobile devices.

Added scroll on body as addition to window, in case the scroll happens on that element and the window is in a fixed unmoved position

Added mouse as a new possible property (perhaps to be added in the docs) in order to trigger lazy-loading check when mouse is moved over the browser page.

Hope the following is an understandable example for mouse event - This is especially useful if the user is using a large desktop, and there is a list of image elements that is reordered (e.g. from low price to high price with a button ) . In this case, the image loading is triggered simply by moving your mouse around and without having the user to do an unnatural movement of scrolling (since it might not be needed).

Coverage remained the same at 75.904% when pulling f3347a6ce9490541f40741e025f1b168ff5d778f on redbadger:master into d4fde733e292637a1b67ea596257e706aeae3fd4 on jasonslyvia:master.

Coverage remained the same at 75.904% when pulling 824c2db142c97ddae501d327bc7c2a7dc5bab82f on redbadger:master into d4fde733e292637a1b67ea596257e706aeae3fd4 on jasonslyvia:master.


After two days morden testnet was not fully synced or current balance isn't showed on Windows

Syncing state:

Current balance from geth's console:
dulanov@localhost:~$ /opt/geth/geth15 attach ipc://${HOME}/.ethereum-classic/morden/geth.ipc
Welcome to the Geth JavaScript console!

instance: Geth/v3.5.0/linux/go1.8
coinbase: 0x6a7cc99d37e28059306ce7f14ad99d671e7db6c0
at block: 1945096 (Thu, 27 Jul 2017 12:41:09 CEST)
 datadir: /home/dulanov/.ethereum-classic/morden
 modules: admin:1.0 debug:1.0 eth:1.0 miner:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0

> eth.getBalance("0x6a7cc99d37e28059306ce7f14ad99d671e7db6c0")
580876459211000000000

But in Emerald:

Meanwhile, the test network was
dulanov@localhost:~$ tail -f .ethereum-classic/morden/geth.log
I0727 11:56:19.162775 core/blockchain.go:947] imported 1 block(s) (0 queued 0 ignored) including 0 txs in 9.367014ms. #1945087 [d28d2ed2 / d28d2ed2]
I0727 11:59:42.528076 core/blockchain.go:947] imported 1 block(s) (0 queued 0 ignored) including 0 txs in 10.381421ms. #1945088 [b86ea6eb / b86ea6eb]
I0727 12:02:23.909113 core/blockchain.go:947] imported 1 block(s) (0 queued 0 ignored) including 0 txs in 10.079139ms. #1945089 [7f5b00cc / 7f5b00cc]
I0727 12:09:15.322245 core/blockchain.go:947] imported 1 block(s) (0 queued 0 ignored) including 0 txs in 9.749175ms. #1945090 [c4cee625 / c4cee625]
I0727 12:09:48.524610 core/blockchain.go:947] imported 1 block(s) (0 queued 0 ignored) including 0 txs in 10.490562ms. #1945091 [335d712d / 335d712d]
I0727 12:12:35.344440 core/blockchain.go:947] imported 1 block(s) (0 queued 0 ignored) including 0 txs in 8.581768ms. #1945092 [d3f462de / d3f462de]
I0727 12:14:30.105378 core/blockchain.go:947] imported 1 block(s) (0 queued 0 ignored) including 0 txs in 10.726291ms. #1945093 [0c5bbeca / 0c5bbeca]
I0727 12:39:14.417854 core/blockchain.go:947] imported 1 block(s) (0 queued 0 ignored) including 0 txs in 9.783537ms. #1945094 [b01a7321 / b01a7321]
I0727 12:41:09.459974 core/blockchain.go:947] imported 1 block(s) (0 queued 0 ignored) including 0 txs in 11.852744ms. #1945095 [f0c11bac / f0c11bac]
I0727 12:42:28.709185 core/blockchain.go:947] imported 1 block(s) (0 queued 0 ignored) including 0 txs in 11.391819ms. #1945096 [d8ba050a / d8ba050a]

Same situation to me, UI missing aroun 2000 blocks, transactions srucked in pending state

@r8d8 but some of your accounts have real balance!

It's old values
don't even know how he got them


Parashah Setumah marker ס in OT texts - breaks highlighting

We have an issue in tC Create, although I don't think it's an issue in tCore (although I can't test it yet for sure until we publish Nehemiah UTN). In Nehemiah 3:2, there is a setumah in the middle of the verse, i.e. a Hebrew character that is not part of the text. From my experience, tCore knows that these characters aren't part of the text. But tC Create seems to think that this setumah is part of the Hebrew word. This is causing tC Create not to recognize the OrigLQuote in note ID [u2s6]. The USFM code in the UHB has a space there to separate the setumah character from the rest of the Hebrew text, but tC Create apparently doesn't read it. The point is that I think this note is correct, but tC Create doesn't recognize the OrigLQuote.
ס

TODO: investigate if the recently updated normalizer is breaking because of non-breaking space?
TODO: consult how we do it in tC

birch adds:
last character on line 600 of https://git.door43.org/unfoldingWord/hbo_uhb/src/branch/master/16-NEH.usfm

https://unfoldingword.zulipchat.com/#narrow/stream/207526-wg-tools/topic/OT.20Hebrew.20usfm

Testable in translationCore Create - v1.0.4-rc.1
https://develop--tc-create-app.netlify.app/

Not seeing this issue in translationCore Create - v1.0.4-rc.1
OT punctuations are no longer breaking the highlights.

Tested in Katalon tCC tN Test Copy OrigLangQuote


Make BottomSheet more generic and reusable

Please describe the feature you would like to request.
It would be great if BottomSheet would be more generic. I think it could be useful to have something like an abstract sheet module that contains the base behavior and that can be extended to implement different variations of this pattern.
What is the use-case or motivation for this proposal?
I need the same kind of behavior but would like to have it displayed as a full-viewport-height side-modal from the right.
For now I'll copy the BottomSheet module and will have to change just a few things I guess.
Is there anything else we should know?

I've been waiting for a side sheet for a long time.

Well, I guess the problem is, that they haven't used material for custom app development. There are enough cases were sidenav isn't the right solution, as it should be just created and opened on demand just like an overlay or the bottom sheet. So I don't want to have a sidenav all the time and just create it on demand in the context I currently need.

Re-opening the feature request #13070 and marking this as a dupe


Docker container on hub.docker.com

It would be useful to have ready-to-use container for db-sync on docker hub, so that people do not need to build the container and just run it.

There is a container available now: https://hub.docker.com/r/lutraconsulting/mergin-db-sync


Error "TypeError: this.config.plugins.filter is not a function" when running commands

Summary
Getting error TypeError: this.config.plugins.filter is not a function when running commands like :

sf org list shape
sf org create shape
sf org delete shape

(I'm also getting a warning when running these commands :
"Warning: Plugin @salesforce/plugin-signups (1.4.10) differs from the version specified by sf (1.5.5)", could be related)
Steps To Reproduce
Private repo, sorry.  Just run the command sf org list shape
Expected result
Command get list of org shape
Actual result
Command fails, with message TypeError: this.config.plugins.filter is not a function
System Information

{
  "architecture": "win32-x64",
  "cliVersion"<EMAIL_ADDRESS>  "nodeVersion": "node-v18.17.1",
  "osVersion": "Windows_NT 10.0.22621",
  "rootPath": "C:\\Users\\corentin.romilly\\AppData\\Roaming\\npm\\node_modules\\@salesforce\\cli",
  "shell": "cmd.exe",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.3.9 (core)",
    "@oclif/plugin-commands 2.2.28 (core)",
    "@oclif/plugin-help 5.2.20 (core)",
    "@oclif/plugin-not-found 2.4.3 (core)",
    "@oclif/plugin-plugins 3.9.1 (core)",
    "@oclif/plugin-search 0.0.23 (core)",
    "@oclif/plugin-update 3.2.4 (core)",
    "@oclif/plugin-version 2.0.1 (core)",
    "@oclif/plugin-warn-if-update-available 2.1.1 (core)",
    "@oclif/plugin-which 2.2.34 (core)",
    "@salesforce/cli 2.13.9 (core)",
    "apex 2.3.19 (core)",
    "auth 2.8.20 (core)",
    "data 2.5.16 (core)",
    "deploy-retrieve 1.19.0 (core)",
    "dev 0.7.0 (user)",
    "info 2.6.49 (core)",
    "limits 2.3.38 (core)",
    "login 1.2.35 (core)",
    "marketplace 0.3.0 (core)",
    "org 2.10.12 (core)",
    "packaging 1.16.2 (user)",
    "schema 2.3.29 (core)",
    "settings 1.4.33 (core)",
    "signups 1.4.10 (user)",
    "sobject 0.2.11 (core)",
    "source 2.10.40 (core)",
    "telemetry 2.3.6 (core)",
    "templates 55.5.14 (core)",
    "trust 2.6.18 (core)",
    "user 2.3.36 (core)"
  ]
}

Additional information

@corentindoctolib I think the error is caused by the signups plugin (which contains the shape commands) using an old dependencies that conflict with latest CLI.
can you uninstall and reinstall latests again?
just run sf plugins uninstall @salesforce/plugin-signups then sf plugins install @salesforce/plugin-signups

It worked, thanks @cristiand391 for you quick answer :)


2.0.0 Relative SwaggerEndpoint URL doesn't work

When using a relative path for the SwaggerEndpoint, the SwaggerUI shows an error:

{"schemaValidationMessages":[{"level":"error","message":"Can't read from file /swagger/v1/swagger.json"}]}
When I use an absolute path (includes the fully qualified host and folder location) it works.
Thanks!

How do you happen to be hosting it? I'm having a similar issue but it's due to me using a RP and using a location mapping through nGinx.

@ltraus this is in my local environment...not deployed anywhere yet (http://localhost:port/etc...)

I'm going to assume you updated all the packages to 2.0, and tried.
   c=> Endpoint("/swagger/v1/swagger.json")
   c=> Endpoint("swagger/v1/swagger.json")

And have not modified the original route prefix?

c=> Endpoint("/swagger/v1/swagger.json")
This is how I have it configured.

Try removing the preceding /swagger/ route:
app.UseSwaggerUI(c => c.SwaggerEndpoint("v1/swagger.json"))

Same thing...
{"schemaValidationMessages":[{"level":"error","message":"Can't read from file v1/swagger.json"}]}

Hmm, can you post your full Startup.cs?

Note: I am using appSettings.json to store some of the values. But, they match what you would expect the string values to be "/swagger/v1/swagger.json" for instance.
`using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Options;
using Microsoft.IdentityModel.Tokens;
using Swashbuckle.AspNetCore.Swagger;
namespace RCMOneWebApi
{
public class Startup
{
public IConfiguration _config { get; }
    public Startup(IConfiguration configuration)
    {
        _config = configuration;
    }

    // This method gets called by the runtime. Use this method to add services to the container.
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc();
        services.AddSwaggerGen(c =>
        {
            c.SwaggerDoc(_config["Swagger:Version"], new Info
            {
                Title = _config["Swagger:Title"],
                Version = _config["Swagger:Version"]
            });
            c.AddSecurityDefinition("Bearer", new ApiKeyScheme
            {
                Description = "JWT Authorization header using the Bearer scheme. Example - Authorization: Bearer {token}",
                Name = "Authorization",
                In = "header",
                Type = "apiKey"
            });
        });

        services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(options =>
        {
            options.TokenValidationParameters = new TokenValidationParameters()
            {
                ValidateIssuer = true,
                ValidateAudience = true,
                ValidateLifetime = true,
                ValidateIssuerSigningKey = true,
                ValidIssuer = _config["Jwt:issuer"],
                ValidAudience = _config["Jwt:issuer"],
                IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(_config["Jwt:Key"]))
            };
        });

        services.AddCors();
    }

    // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        app.UseSwagger();
        app.UseSwaggerUI(c =>
        {
            c.SwaggerEndpoint(_config["Swagger:Endpoint"], _config["Swagger:Title"]);
        });

        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }

        app.UseAuthentication();
        app.UseMvc();
        app.UseCors(builder => builder.AllowAnyOrigin()
            .AllowAnyMethod()
            .AllowAnyHeader()
            .AllowCredentials());
    }
}

}
`

I'm not sure if this is it, but you're missing app.UseStaticFiles() that's the only difference in my code towards yours.

Firstly, it would be more appropriate to post this issue to the swagger-ui project instead of Swashbuckle.
Secondly, it's worth noting that the validator badge makes a GET request to a remote validator passing your Swagger endpoint as a parameter so it can in turn retrieve your Swagger JSON and validate it.
https://online.swagger.io/validator?url=/swagger/v1/swagger.json
So, the url has to include the domain name and be accessible by the remote validator (e.g. localhost won't work).  For that reason, I would disable the validator badge in all private environments because it's always going to give you an error. To do this, set ValidatorUrl(null) as per the readme. Furthermore, if you're going to enable it in production, you need to pass a the full url (e.g. www.example.com/api/swagger/v1/swagger.json") to the SwaggerEndpoint method.

I have the same issue after upgrading to 2.0.0, before the update it was working fine.
    /// <summary>
    /// Adds Swagger JSON endpoints. Can be fully-qualified or relative to the UI page
    /// </summary>
    /// <param name="options"></param>
    /// <param name="url">Can be fully qualified or relative to the current host</param>
    /// <param name="name">The description that appears in the document selector drop-down</param>
    public static void SwaggerEndpoint(this SwaggerUIOptions options, string url, string name)
    {
      options.ConfigObject.Value<JArray>((object) "urls").Add((JToken) JObject.FromObject((object) new
      {
        url = url,
        name = name
      }));
    }

According to the SwaggerEndpoint method documentation the url field Can be fully qualified or relative to the current host. So it should work as it worked in version 1.

The call to the SwaggerEndpoint function is throwing a NullReferenceException for me.
app.UseSwagger(o => o.RouteTemplate = "api/docs/{documentName}/swagger.json");
app.UseSwaggerUI(o => {
  o.RoutePrefix = "api/docs";
  o.SwaggerEndpoint("api/docs/v1/swagger.json", "API v1");
});

I have the same issue after upgrading to 2.0.0

https://github.com/domaindrivendev/Swashbuckle.AspNetCore/issues/559 for those with "after upgrade" issues, talks about clearing project files.

I cleared my project files, still not working, also it is not working for me in production.

Hello,
I am having the same issue. Even mine it points to http://petstore.swagger.io/v2/swagger.json which I do not understand.

I've already explained what's going here: https://github.com/domaindrivendev/Swashbuckle.AspNetCore/issues/604#issuecomment-368092353. Please read my comments.
Now, it does look like the latest release enables the validator by default, and this explains why this is suddenly surfacing as an issue. For now, you can have parity with the previous version by disabling the validator:
c.UseSwaggerUI(c =>
{
    c.ValidatorUrl(null);
}

In the meantime, I'm going to go ahead and push out another release (2.1.0) that disables it by default.

See efaf85ddcc6cdab9006c4b019b12a0ede27b79be. Will be disabled by default as of 2.1.0 (publishing as we speak)

@domaindrivendev Even with the validatorurl set to null I still get an NRE.

I can’t repro this so very difficult to troubleshoot with just the info you’re providing. Can you get a stack trace or better still, pull down SB and debug locally

It must be something wonky in our repository. I just put together an example project to test out the NodaTime Swashbuckle settings with v2 and make sure they still work as expected.
No Issues Here

app.UseSwaggerUI(c => c.SwaggerEndpoint("v1/swagger.json")) works for me via:
http://localhost:xxxx/swagger or
http://localhost:xxx/appname/swagger

Was able to solve the problem by
c.CustomSchemaIds(x => x.FullName);

Agree with @alexxie. Using only app.UseSwaggerUI(c => c.SwaggerEndpoint("v1/swagger.json")) seems to fix the problem even if deploying in VirtualDirectory on IIS, it look like this does not need to be set anymore ...
Using NET Core 2.1 and Swashbuckle.AspNetCore 3.0.0

@marekpetak I am using the same versions and I do not have a SwaggerEndpoint function that only takes a single argument like that.

@marekpetak is right, SwaggerEndpoint needs the second parameter which is just a name.

I disagree that relative SwaggerEndpoint paths does not work, this is correct way to use it:
	public static class Extensions 	{ 		public static void UseSwaggerRoute( 			this IApplicationBuilder app, 			IApiVersionDescriptionProvider provider, 			string clientId = null, 			string clientSecret = null) 		{ 			app.UseSwagger(); 			app.UseSwaggerUI(__options => 			{ 				foreach (var versionDescription in provider.ApiVersionDescriptions) 				{ 					__options.SwaggerEndpoint($"../{__options.RoutePrefix}/{versionDescription.GroupName}/swagger.json", versionDescription.GroupName.ToUpperInvariant()); 				} 				if (!string.IsNullOrEmpty(clientId) && !string.IsNullOrEmpty(clientSecret)) 				{ 					__options.OAuthClientId(clientId); 					__options.OAuthClientSecret(clientSecret); 				} 			}); 		} 	}

In ASP .NET 3.0 using the package Swashbuckle.AspNetCore 5.0.0-rc2 just add:
c.AddSecurityDefinition("bearer", new OpenApiSecurityScheme
{
In = ParameterLocation.Header,
Description = "Json Web Token (JWT) - "Bearer {token}"",
Name = "Authorization",
Type =  SecuritySchemeType.ApiKey
});
And it's works fine.


Chore: bump external dependencies

Description
Upgrade external dependencies:

[x] Grafana from 8.3.4 to 8.5.9
[x] TimescaleDB from pg13.4-ts2.4.2-p0 to pg13.8-ts2.8.0-p1
[ ] Redis from bitnami/6.2.6-debian-10-r103 to

Fixes #1256
Type of change

[x] Chore (maintaining dependencies updated)

How Has This Been Tested?

[x] Grafana:

The changelog reports some breaking changes but they doesn't concern our use cases
Created dashboard with fake data without problems

[x] TimescaleDB

The changelog doesn't report any breaking change, neither for Timescale version 2.8.0 nor for PostgreSQL varsion 13.8
Tested alongside with Grafana. Data is written to and read from the database without issues

[ ] Redis

TBD

Checklist:

[ ] I have made corresponding changes to the documentation
[ ] I have made corresponding changes to the changelog (if needed).
[ ] I have made corresponding notices to the upgrade instructions (if needed)

Changelog changes
TBD
Upgrade instructions
TBD

I will now take a look at updgrading Redis and eventually consider replacing it with Memcached

Codecov Report

Merging #1263 (032854d) into main (72b392e) will increase coverage by 0.08%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1263      +/-   ##
==========================================
+ Coverage   12.34%   12.42%   +0.08%
==========================================
  Files          29       29
  Lines        8367     8367
==========================================
+ Hits         1033     1040       +7
+ Misses       7262     7257       -5
+ Partials       72       70       -2

Impacted Files
Coverage Δ

golang/internal/ioddfinder.go
66.15% <0.00%> (+3.07%)
:arrow_up:

golang/internal/exponential_backoff.go
60.71% <0.00%> (+10.71%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Projectile-files search results are "reversed"

First of all, thank you for a great editor. I switched from spacemacs, and the freezing has stopped! I am most grateful!
Now to my issue - I am using helm as search engine (the default config when I started using doom emacs), and the search results when using projectile-find-files seems to be reversed somehow. For example, if I search for KAL, then I get the following order of search results:
src/data/haskellKAL/Internal/file.hs
src/data/haskellKAL/Internal/file2.hs
src/data/haskellKAL/Internal/headers/file3.h
src/haskellKAL.hs

I would expect src/haskellKAL.hs to be the first, or for the cursor to start at the bottom.
Is it some configuration that I have overlooked in doom-emacs? It seems like something most people would be annoyed about, so it makes me wonder whether I am doing something wrong.

Reversing the order seems to be something on the Helm "won't fix" list.
https://github.com/emacs-helm/helm/issues/362
That said, some redditor created a method to do it, you might give it a try.
https://www.reddit.com/r/emacs/comments/3asbyn/new_and_very_useful_helm_feature_enter_search/
Now, here's another alternative.
Use Ivy instead.
+ivy/projectile-find-file from what I've seen already puts it in the order you want.
And if you want to flip it, there's a variable to flip it.
https://github.com/abo-abo/swiper/commit/9b13aa466e3370b52e536c7c1a290d924d488ee9
At least I think anyway.

So ivy does actually not do it in the way I desire, it does the same.
However, with ivy I can go to the last entry by going over the top, which was not possible with helm. Thank you!


Duplicate Fileid/"src_uri_s"

It seems that duplicate checks based on fileid are not longer supported/working.
In previous released that if an item had the same fileid, that the record would be upserted, aka overwritten, independent of the harvest source. We used this to upload  a set of unprocessed/enhanced records, then processed them, and overwrote them with enhanced records.
Now in 2.6, I'm not sure if that is the case. two records from "different" sources now show up as independent records.
http://cinergi.sdsc.edu/geoportal/rest/metadata/item/f1323bd613f34c24afc456584648711e?pretty=true
http://cinergi.sdsc.edu/geoportal/rest/metadata/item/b991b15991214b75a42d300366128cbc?pretty=true
http://cinergi.sdsc.edu/geoportal/#

it appears that duplicates can exist in the same harvest?
http://cinergi.sdsc.edu/geoportal/?fileid="urn:dciso:metadataabout:ed4ed727-c9d2-4e0c-917a-a7e534aa62ed"
Query to find duplicates, and for our elasticsearch
{
   "size": 0,
   "aggs": {
      "userIds": {
         "terms": {
            "field": "fileid",
            "size": 10000,
            "min_doc_count": 2
         }
      }
   }
}

Occurs when the fileid/src_uri_s has a colon
"test:cinergi:ddh:usecase:ds:00000"
in om.esri.geoportal.commons.gpt.client queryIds returns no ids


Any roadmap update for this awesome blueprint?

cannot wait for this awesome golang jhipster blueprint

I'm very low on time currently, so don't know when I can start looking into this again


insert_image in art.attacks.poisoning.perturbations does not preserve the dtype of the passed  ndarray.

Describe the bug
When passing data to insert_image, the returned type of the array is not the same as the original data passed. This can occasionally cause issues with data types when using the returned value. This is probably a minor issue and I can bypass this issue by simply converting the returned data back to the original dtype, but it might be nice to not require this step.
To Reproduce
In my case, I had a PyTorch model trained using input data with dtype=float32. The pytorch model weights appeared to be float tensors.
Steps:

I feed the input data of dtype=float32 to insert_image and receive a numpy array with dtype=float64
I convert the returned value into a PyTorch Tensor using torch.from_numpy(). This converts the returned value into a DoubleTensor
An error occurs when I use the converted tensor as input to art.estimator.get_activations(). The error is RuntimeError: Input type (torch.cuda.DoubleTensor) and weight type (torch.cuda.FloatTensor) should be the same

I get similar issues if I pass an Int. I will get a float back.
Expected behavior
The dtype of the input to insert_image should be preserved.
System information (please complete the following information):

Unbuntu 18.04
Python 3.8
ART 1.9

Hi @keykholt Thank you very much for reporting this issue!


Allow deduction for variable from other inference_ids.

This change is

crates/cairo-lang-semantic/src/expr/inference.rs line 617 at r1 (raw file):

                ty1: ty,
            });
        }

It seems that removing this improves the error message.
Code quote:
        if var.inference_id != self.inference_id {
            return Err(InferenceError::TypeKindMismatch {
                ty0: self.db.intern_type(TypeLongId::Var(var)),
                ty1: ty,
            });
        }

crates/cairo-lang-semantic/src/expr/inference.rs line 617 at r1 (raw file):
Previously, ilyalesokhin-starkware wrote…
It seems that removing this improves the error message.

but it might be safer to rewrite the inference_id of the return type
from:
LookupItemDeclaration
to
LookupItemDefinition


KnoxSSO integration

I'm working on a SSO integration with Apache Knox. I'm writing this issue to ask for validation and advice on my approach, so that it is hopefully useful in a more general context.
Knox provides a combined service of HTTPS gateway/proxy and SSO. Because of this, I'm considering a simplified authentication mechanism which assumes that Knox controls all the requests allowing only authorised ones and for Superset it remains only to identify the user and perform an automatic login. I'm using authentication, based on LDAP where both Knox and Superset have access to the LDAP users directory.
I have currently identified three possible ways of doing the above identification:

from a GET request parameter user.name that Knox sends to to managed applications
from the Basic authentication header set by Knox
from a hadoop-jwt` cookie set by Knox.

I currently don't see why in the current context I should bother to unpack the JWT, given that I can get the user name unencrypted. Admittedly, I need to make sure that the Superset logged-in session does not outlive the Knox logged-in session, but at this point this seems manageable to me. Can anyone think of an issue I might be missing and thus my reasoning is invalid?
PS: Not really relevant, but here's a link to the Knox issue on gateway integration with Superset. Here's a link to the source code of the work-in-progress integration.

I'm facing problems with redirects and I'm not sure what exactly am I doing wrong:

When I authenticate the user programatically using information from the request (same for all three of the original approaches I tried) and calling flask_login.login_user, the next call somehow looses its session cookie. This might be a consequence to the following issue.

Leaving authentication aside, when reverse-proxy pages that do not require authentication, these pages end up in a self-redirect loop, possibly similar to this issue. I haven't tried engineering X-Forwarded-* request headers yet, but this seems the way to go.

Have you tried setting the conf flag ENABLE_PROXY_FIX = True ?

Seems this seems to come up quite a bit, I was wondering to myself "should we make this the default"?
It appears the answer is no :(. From the docs: "Do not use this middleware in non-proxy setups for security reasons."

Thanks for the tip. It seems to have solved this problem, or at least I'm facing another one with Knox keystores now.
Since this is about XFF-related headers, it makes sense that this is used only when forwarding is needed (e.g. when proxying, like my case with Knox). I was tempted to say that "fix" in the name is misleading, as this is a valid and seemingly long-standing configuration option, but than I saw that in werkzeug it is under contrib.fixers, so probably that would be a better place for such a discussion.

I have an early (dirty and partial) version of this working now. To be verified how/if it suits our needs and most probably changes will follow. It is available at https://github.com/mapto/knox_superset_testing if of interest to the community.
My current implementation reads the hadoop-jwt cookie and performs user identification at every request. The advantage of this is that it avoids synchronising session TTL between Knox and Superset. The disadvantage might be performance, but at this point this doesn't appear to be critical.
As can be seen from the code, this now works with code injection, and can be improved, subject to suggestions in #3970.
The integration currently exposes only the welcome and sqllab sections.


If the database is dead and can't be connected all the time, the master is easy to fill the log and let the user decide the maximum number of failures.

If the database is dead and can't be connected all the time, the master is easy to fill the log and let the user decide the maximum number of failures. If the number of failures is reached, the master exits. In this way, the maximum number of logs is controlled. The default number of database reconnections is 360.

hi, are you having any problems.

For related discussion, see: #4332 #4226

Codecov Report

Merging #4345 (449e145) into dev (d446e33) will decrease coverage by 0.03%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##                dev    #4345      +/-   ##
============================================
- Coverage     43.22%   43.18%   -0.04%
+ Complexity     3184     3182       -2
============================================
  Files           471      471
  Lines         21732    21743      +11
  Branches       2626     2627       +1
============================================
- Hits           9393     9390       -3
- Misses        11442    11455      +13
- Partials        897      898       +1

Impacted Files
Coverage Δ
Complexity Δ

...r/server/master/runner/MasterSchedulerService.java
0.00% <0.00%> (ø)
0.00 <0.00> (ø)

...er/master/dispatch/host/assign/RandomSelector.java
77.77% <0.00%> (-5.56%)
3.00% <0.00%> (-1.00%)

...inscheduler/service/zk/CuratorZookeeperClient.java
60.97% <0.00%> (-4.88%)
7.00% <0.00%> (-1.00%)

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 d446e33...449e145. Read the comment docs.

For related discussion, see: #4342 #4226

These two have been turned off

-If the database fails, the master will print the log all the time
This is really unreasonable.
If we can solve the problem of logging all the time, is there no need to quit?
I don't think quitting is a good idea.

Hi @zt-1997 , this pr has not updated in a long time, so it wiil be closed.
If you have other questions, you can re-open it or create a new one. Thxs.


S3 bucket select

Closes #360, in case of a change approval.

Going to close this for now so we don't have draft PRs sitting open for weeks that are likely to fall significantly behind, or require larger changes to the point where this is obsolete. The issue this is addressing is not a beta blocker, so it's unlikely it will be looked at for some time.


Failed to load resource: net::net::

Android's WeChat and QQ browsers occasionally appear “Failed to load resource: net::net::”.   Other browsers or mobile phones are available

I'm not sure how that's related to eslint, or eslint-plugin-react? Linters wouldn't be run in the browser.


Wrong info in the article - Instead of CostObjectStatementCache should be CostStatementCacheDataSet

Hello,
I have faced the issue that I cannot find the CostObjectStatementCache in the Data cache configuration. I have figured out that it might be wrong info in the article and Instead of CostObjectStatementCache should be CostStatementCacheDataSet in it.
Thank you!

[Enter feedback here]

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

ID: b2d5bfd3-1ddd-514b-0735-3ffac0a43787
Version Independent ID: 575715a0-b64a-9a20-6212-cb304c7cd5c7
Content: Cost management Power BI content - Finance & Operations | Dynamics 365
Content Source: articles/fin-ops-core/dev-itpro/analytics/cost-management-content-pack.md
Service: dynamics-365-cross-app
Product: ****
Technology: ****
GitHub Login: @ShylaThompson
Microsoft Alias: kfend

@johnmichalak this topic is old. Can you please make sure it is part of your freshness review? Can you also please address the feedback above?

Closing as won't fix.


add support for bridgy_omit_link="maybe"

when this value is "maybe", include a link iff the content of the
post must be truncated, e.g. when posting to Twitter.
this is the default behavior of the brevity library -- permalinks
are automatically omitted if the tweet is <= 140 characters.
ref snarfed/bridgy#561

lgtm! thanks for doing this!