(SERVER-882) Restrict static_file_content endpoint

This PR updates the static-file-content-endpoint to reject any
requests that would have been rejected by the file_content Puppet
endpoint. Tests are also updated to account for the new requirement. Any
files not within modules/*/files/** or environments/*/modules/*/files/**
will be rejected with a 403 error.

can't be merged, needs a rebase

i'm rebasing as fast as i can!

@KevinCorcoran pushed out an updated test that doesn't doseq.

@haus responding to this comment ...

I was taking this from both the ticket and from the direct puppet google doc, which both indicate that environment may be in the path. The google doc says " is relative to the master's codedir", which means that environments may be part of it.

I don't think that's correct, the doc may just be out of date.  My understanding (and I could be wrong here) is that neither environments nor the name of the particular environment will be included in the file path provided by the agent.  @fpringvaldsen I believe we discussed this on one of your recent PRs - does that sound correct to you, or am I misremembering?

@KevinCorcoran What you said sounds correct. To my knowledge an environment should always be specified by the code-id and environment parameters, and the file-path provided by the agent should be a relative path within the environment directory for the specified environment.

the file-path provided by the agent should be a relative path within the environment directory for the specified environment.

:+1: eg /puppet/v3/static_file_content/modules/ntp/files/ntp.conf?code_id=...

@KevinCorcoran @fpringvaldsen I believe I've responded to all of the feedback now.

REBASELAND

I'm :+1: on this aside from the URL decoding issue ... I don't think I understand that issue well enough to have a strong opinion so if @joshcooper is okay with @haus's conclusion that we should not do any deconding ... :shipit:

I am also :+1: and am willing to defer to @joshcooper on the URL decoding issue.

I was wrong here. Decoding and encoding is happening and I wasn't looking hard enough.

I've just pushed a commit that adds URL decoding for the static_file_content endpoint.

Piling on my :+1:


This episode is not downloading (others work)

Hello,
This episode does not work, I don't know why:
https://www.crunchyroll.com/ar/one-punch-man/episode-9-the-ultimate-dilemma-783088

The command is:
SET URL="https://www.crunchyroll.com/ar/one-punch-man/episode-9-the-ultimate-dilemma-783088"
cr-dl download -l arME --attachFonts -c 32 -o "crunchyroll softsub/{seasonTitle} - {episodeNumber} [{resolution}].mkv" --httpProxy "****@de562.nordvpn.com:80" %URL%
pause

You seem to be using a german proxy although this series isn't available in that country. You could try to do it without proxy (and delete cookies.data) if you live in a country where its available.
Unfortunately crunchyroll even seems to detect all NordVPN servers as being in US and this series isn't available there so it propably wouldn't work just switching servers.

Oh no, I forgot that completely, I use a server but it is blocked from crunchyroll, so I have to use a proxy for that, looks like I will try different countries until I find a good one.
Thank you very much.


BBS+ demo

Adds a demo of the full flow of credentials using bbs+ signatures.
A Prover obtains credentials from two Issuers that include the Prover's link secret.
A Verifier requests that the Prover reveal one claim from one credential, and prove the equality of one claim from each credential.

@brentzundel could you fix the merge conflicts here? I will merge after this is done

@mac-arrap It should be ready to go.


sct_extract_metric -vert does not work properly

Description
I did registration of template to T2 image, after it I warped atlases to T2 space. In this T2 space I have registred FA map as well. I would like to extract value of FA from WM from C3 to C6 vertebral levels, so I run:
sct_extract_metric -i FA.nii.gz -method map -f label/atlas -l 51 -vert 3:6 -o metric.txt
Function finds path to label and vertebral labeling file and recognizes vertebral levels, but returns me warnings during running (if I run same command without -vert flag I receive no warning):

Checked parameters:
data ...................... FA.nii.gz
path to label ............. label/atlas
label ..................... 51
method .................... map
slices of interest ........
vertebral levels .......... 3:6
vertebral labeling file.... label/template/PAM50_levels.nii.gz
advanced parameters ....... ['10', '10']
Load metric image...
/usr/local/lib/sct/python/lib/python2.7/site-packages/numpy/core/_methods.py:59: RuntimeWarning: Mean of empty slice.
warnings.warn("Mean of empty slice.", RuntimeWarning)
/usr/local/lib/sct/python/lib/python2.7/site-packages/numpy/core/_methods.py:70: RuntimeWarning: invalid value encountered in double_scalars
ret = ret.dtype.type(ret / rcount)

Function finishes without errors but metric.txt file contains metric from all slices, not only from slices at C3-C6 levels.
I use the latest stable SCT version v3.2.3 (master/438e48a6917eb31f657598f5704146a8b467b5ed).

@valosekj this is strange. Would you mind sending me your data folder so i can try to debug?

I noticed a bug that was introduced in v3.2.3 in the way slices are handled in sct_extract_metrics. I will produce a fix shortly.

@valosekj I implemented a fix that you can test in a separate branch (see: https://github.com/neuropoly/spinalcordtoolbox/pull/1965, with instructions at the end for testing this branch). Would you mind testing it and letting me know if this is good for you?
Thanks

@jcohenadad I just updated to the newest master version (because branch jca/1963-extract-metric-bug-vert-level  was deleted by zougloub) and tried to run function again with following progress:

Spinal Cord Toolbox (master/b6141001c8a9f17d802eb741d58860ba1359a74f)
Running /usr/local/lib/sct/scripts/sct_extract_metric.py -i FA.nii.gz -method map -f label/atlas -l 51 -vert 3:6 -o metric.txt
Checked parameters:
data ...................... FA.nii.gz
path to label ............. label/atlas
label ..................... 51
method .................... map
slices of interest ........
vertebral levels .......... 3:6
vertebral labeling file.... /md2/valosek/Template_registration/Julien/label/template/PAM50_levels.nii.gz
advanced parameters ....... ['10', '10']
Load metric image...
/usr/local/lib/sct/python/lib/python2.7/site-packages/numpy/core/_methods.py:59: RuntimeWarning: Mean of empty slice.
warnings.warn("Mean of empty slice.", RuntimeWarning)
/usr/local/lib/sct/python/lib/python2.7/site-packages/numpy/core/_methods.py:70: RuntimeWarning: invalid value encountered in double_scalars
ret = ret.dtype.type(ret / rcount)
Saving results in: metric.txt ...
Traceback (most recent call last):
File "/usr/local/lib/sct/scripts/sct_extract_metric.py", line 1207, in
fname_mask_weight, fname_vertebral_labeling=fname_vertebral_labeling, perslice=perslice, perlevel=perlevel)
File "/usr/local/lib/sct/scripts/sct_extract_metric.py", line 472, in main
method, overwrite, fname_normalizing_label, fixed_label, vert_levels=vert_levels)
File "/usr/local/lib/sct/scripts/sct_extract_metric.py", line 619, in save_metrics
existing_book = open_workbook(fname_output_xls)
File "/usr/local/lib/sct/python/lib/python2.7/site-packages/xlrd/init.py", line 394, in open_workbook
f = open(filename, "rb")
IOError: [Errno 2] No such file or directory: 'metric.xls'
Total processing time: 1 min 4 s

@valosekj indeed, let me investigate further. Sorry about that.

@valosekj could you please try again on branch: jca/1963-extract-metric-bug-vert-level?

@jcohenadad It is working now. Thank you!


autorandr: 4f5e2401ef -> 59f6aec0b

Motivation for this change
Things done

[X] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[X] Fits CONTRIBUTING.md.

wertarbyte has allowed his project to languish, and phillipberdt
has taken it over and is merging pull requests

closes https://github.com/NixOS/nixpkgs/issues/15466

Will this work without a Python dependency? It also seems to retain the support for Disper, which I think has been removed from the phillipberdt fork…

@rycee Good question. This is actually the latest of the legacy branch which both doesn't use python, and does support disper. I'll add that as a comment once @edolstra sheds light on what the version string should be.

Ah sorry, I didn't pay enough attention to notice that this wasn't pointing to a Pythonized revision.
I would suggest using the commit date as version, i.e., something like version = "20150127".

Updated to use the commit date for the version, and added a comment about using the legacy version.

Great! I think it might be good to also change the commit message to reflect the new version number.
While trying the script it seems to work fine but I got an error about missing xxd:
rycee@beta:~/devel/nixpkgs$ ./result/bin/autorandr --change --default horizontal
which: no xxd in (/home/rycee/.nix-profile/bin:/home/rycee/.nix-profile/sbin:/home/rycee/bin:/home/rycee/.local/bin:/home/rycee/bin:/var/setuid-wrappers:/home/rycee/.nix-profile/bin:/home/rycee/.nix-profile/sbin:/home/rycee/.nix-profile/lib/kde4/libexec:/nix/var/nix/profiles/default/bin:/nix/var/nix/profiles/default/sbin:/nix/var/nix/profiles/default/lib/kde4/libexec:/run/current-system/sw/bin:/run/current-system/sw/sbin:/run/current-system/sw/lib/kde4/libexec)
No suitable profile detected, falling back to horizontal
 -> stacking all outputs horizontally at their largest modes
rycee@beta (✗ 1):~/devel/nixpkgs$

To avoid this warning I tried this:
diff --git a/pkgs/tools/misc/autorandr/default.nix b/pkgs/tools/misc/autorandr/default.nix
index 3e922ab..552dc11 100644
--- a/pkgs/tools/misc/autorandr/default.nix
+++ b/pkgs/tools/misc/autorandr/default.nix
@@ -2,7 +2,8 @@
 , stdenv
 , enableXRandr ? true, xrandr ? null
 , enableDisper ? true, disper ? null
-, xdpyinfo }:
+, xdpyinfo
+, python }:

 assert enableXRandr -> xrandr != null;
 assert enableDisper -> disper != null;
@@ -27,7 +28,9 @@ in
       substituteInPlace "autorandr" \
         --replace "/usr/bin/xrandr" "${if enableXRandr then xrandr else "/nowhere"}/bin/xrandr" \
         --replace "/usr/bin/disper" "${if enableDisper then disper else "/nowhere"}/bin/disper" \
-        --replace "/usr/bin/xdpyinfo" "${xdpyinfo}/bin/xdpyinfo"
+        --replace "/usr/bin/xdpyinfo" "${xdpyinfo}/bin/xdpyinfo" \
+        --replace "which xxd" "false" \
+        --replace "python" "${python}/bin/python"
     '';

     installPhase = ''

but I don't know if it is very pretty.

Merged in 7bd2052436c4269700dbc15d3603a494bb36d96c. I'll make a separate PR to sort out the warning message.
Note, I amended the commit message to say
autorandr: 4f5e2401ef -> 20150127

rather than
autorandr: 4f5e2401ef -> 59f6aec0b

Thanks for taking care of this for me, @rycee.

No problem, thanks for your contribution!


libStorage API volumeInspect route should work in one consistent way

According to the API doc, an API call to route volumeInspect does not support parameter attachments.  However,  the only way to retrieve full attachment information (including device name) is to provide the attachments boolean parameter (see output below).
Route volumeInspect should require both Libstorage-Instanceid and Libstorage-Localdevices headers and return all pertinent volume and attachment information for the specified volume id.   Today this is optional and it can be confusing.
The volumeInspect route supports the following three calls (at least with the virtualbox driver).
No local devices sent
> curl -H "Libstorage-Instanceid: virtualbox=ca72be20-3cba-4bf9-842f-806729142d95" -X GET http://localhost:7979/volumes/virtualbox/af039ac8-dc2b-4bdd-ba6a-81075fe3d7d0
{
  "attachments": [
    {
      "deviceName": "",
      "instanceID": {
        "id": "ca72be20-3cba-4bf9-842f-806729142d95",
        "driver": "virtualbox"
      },
      "status": "/Users/*****/VirtualBox Volumes/vol-0001",
      "volumeID": "af039ac8-dc2b-4bdd-ba6a-81075fe3d7d0"
    }
  ],
  "name": "vol-0001",
  "size": 1,
  "status": "/Users/****/VirtualBox Volumes/vol-0001",
  "id": "af039ac8-dc2b-4bdd-ba6a-81075fe3d7d0",
  "type": ""
}

Local devices sent without attachments param
Notice,  the device name field not populated
> curl -H "Libstorage-Instanceid: virtualbox=ca72be20-3cba-4bf9-842f-806729142d95" -H "Libstorage-Localdevices: virtualbox=75dca810::/dev/sda5,af039ac8::/dev/sdb" -X GET http://localhost:7979/volumes/virtualbox/af039ac8-dc2b-4bdd-ba6a-81075fe3d7d0
{
  "attachments": [
    {
      "deviceName": "",
      "instanceID": {
        "id": "ca72be20-3cba-4bf9-842f-806729142d95",
        "driver": "virtualbox"
      },
      "status": "/Users/*****/VirtualBox Volumes/vol-0001",
      "volumeID": "af039ac8-dc2b-4bdd-ba6a-81075fe3d7d0"
    }
  ],
  "name": "vol-0001",
  "size": 1,
  "status": "/Users/*****/VirtualBox Volumes/vol-0001",
  "id": "af039ac8-dc2b-4bdd-ba6a-81075fe3d7d0",
  "type": ""
}

Both instanceid and localdevices header provided + plus the attachments param
> curl -H "Libstorage-Instanceid: virtualbox=ca72be20-3cba-4bf9-842f-806729142d95" -H "Libstorage-Localdevices: virtualbox=75dca810::/dev/sda5,af039ac8::/dev/sdb" -X GET http://localhost:7979/volumes/virtualbox/af039ac8-dc2b-4bdd-ba6a-81075fe3d7d0?attachments=true
{
  "attachments": [
    {
      "deviceName": "/dev/sdb",
      "instanceID": {
        "id": "ca72be20-3cba-4bf9-842f-806729142d95",
        "driver": "virtualbox"
      },
      "status": "/Users/*****/VirtualBox Volumes/vol-0001",
      "volumeID": "af039ac8-dc2b-4bdd-ba6a-81075fe3d7d0"
    }
  ],
  "name": "vol-0001",
  "size": 1,
  "status": "/Users/****/VirtualBox Volumes/vol-0001",
  "id": "af039ac8-dc2b-4bdd-ba6a-81075fe3d7d0",
  "type": ""
}

Environment
Driver=virtuabox
> ./lss-linux --version
Binary: /home/*****/DEV/go/bin/lss-linux
SemVer: 0.3.1
OsArch: Linux-x86_64
Branch: (HEAD detached from 5cb6951
Commit: a3a561a1b94bb8b7efb4ae998540c457deb39692
Formed: Fri, 28 Oct 2016 13:57:27 EDT

Hi @vladimirvivien,
The API doesn't say it doesn't support it but rather states:

If the libStorage-InstanceID header is provided the volume's attachments are also retrieved. Unlike when retrieving Volume collections, there's no need to specify the attachments query parameter to request their retrieval.

There's no need because the inclusion of the instance ID sets the implicit assumption that the attachment information is requested.
However, to your assertion at hand -- that there should be some consistent manner that the API should work.
Well, no. There kind of shouldn't. Or rather there kind of isn't a way to enforce it. It's up to the drivers to behave a way that is consistent with the API. For example, I discovered that the EBS storage driver is returning attachments when the instance ID is present regardless of whether the attachment flag is set to true. This caused me to make a bad judgement as to what was occurring for all drivers.
I agree with you in principle, but in practice it's up to the drivers to act as the API advises them to do.
Also, FWIW, I need to update the documentation to which you linked. I've been the only primary on the project for so long, and I haven't had the bandwidth to evolve the project and keep the public contract in sync with the actual implementation due to release pressures.

By the way @vladimirvivien, the API docs definitely need to be updated WRT the libStorage headers. The API docs are terribly out of date in that regard. Thank you for bringing this to my attention.

@akutz thanks for the quick reply.  But, when I think of the volumeInspect I think of a call that should return all pertinent info about the volume including its attachments data.  Now, if the driver can't fulfill all of the data, that's OK, but at least the API should mandate it.
Route volumes is better suited for optional fields since you can be in a situation where a storage backend may return a large amount of data.  There, making attachment optionals makes sense because you could alleviate latency by leaving out attachment info (at least that's how it rings in my head).
Anyway,  I also noticed that the new rexray cli leaves out device path info (Driver=virtualbox) when a rexray volume get <volumeid> is done.  That may be due to this issue of consistently returning all pertinent fields, including attachments, by default.

Hi @vladimirvivien,

when I think of the volumeInspect I think of a call that should return all pertinent info about the volume including its attachments data. Now, if the driver can't fulfill all of the data, that's OK, but at least the API should mandate it (not the other way around).

I totally agree. So you know, the reasoning is that gathering the attachment data requires additional calls on the back-end for some drivers, hence the option to do it or not. But I totally see your point and agree about the distinction  between inspecting a single volume and multiple volumes.
The new CLI returns that information, but it is not part of the default output format. Please file an enhancement request so that it is shown if present. Thanks!

I'm following along here, and one thing confused me:

The API doesn't say it doesn't support it but rather states:

If the libStorage-InstanceID header is provided the volume's attachments are also retrieved. Unlike when retrieving Volume collections, there's no need to specify the attachments query parameter to request their retrieval.

...

It's up to the drivers to behave a way that is consistent with the API. For example, I discovered that the EBS storage driver is returning attachments when the instance ID is present regardless of whether the attachment flag is set to true. This caused me to make a bad judgement as to what was occurring for all drivers.

According to the API, isn't that what the EBS driver is supposed to do? Or is the EBS comment referring to route volumes instead of volumeInspect?  Reading through a second time, I think that may be the case, but I wanted to double-check.

Hi @codenrhoden,
So the attachments flag has a few meanings as I'm remembering this morning. The original purpose of the attachments flag was to tell drivers they didn't have to return attachment data (unless flag was present and with a positive truthiness). However, somewhere along the line the flag got overloaded. See this other discussion for an example.
Ultimately I will be replacing the flag with an enum. While it will be backwards compatible, attachments will also support something like the following:

Value
Description

0
No attachments requested

1
Attachments requested

2
"My" attachments requested (only attachments attached to the client that matches the provided instance ID)

Right now drivers are doing one of the following:

Always returning attachments, regardless of the flag
Returning attachments only if the flag is present
Returning attachments attached to the client if the flag is present

And unfortunately the server route is stripping all attachments not attached to the client if the flag is present anyway, meaning you cannot get attachment information about other instances if the flag is set to true. However, since some drivers only return attachment information if the flag is true, there is no consistency.
Ultimately this is one of the reasons it's a good thing all drivers are in a single-repo to which we have access. I'm able to update them all according to new logic at once.

The way we handle volume Attachments was great modified (enhanced!) in #316, #319, and #327. I think this can be closed.


chore: No longer push to Docker Hub on release

On June 21, 2021, GitHub Container Registry became generally available which means that we will no longer push to Docker Hub on release as per https://github.com/kedacore/governance/issues/16 and our announcement in March 2021.
Checklist

[x] Commits are signed with Developer Certificate of Origin (DCO - learn more)
[x] Changelog has been updated

Fixes https://github.com/kedacore/governance/issues/16

/run-e2e

/run-e2e *

@JorTurFer How do I run all e2e tests again?

@JorTurFer How do I run all e2e tests again?

They are already running @tomkerkhove. You can trigger them again posting the command again, but you should wait till current execution ends (because it finishes or you cancel it)

/run-e2e *

@JorTurFer All jobs are successful in the e2e run but it reports failure. Do you know why?
https://github.com/kedacore/keda/runs/4962487591?check_suite_focus=true
Is it related to the run duration?


Fix how Z-files read/write

There is a mismatch in a z-file being read in and a z-file that is written out.  Mostly has to do with conjugates in the signal power.

[ ] Update read/write
[ ] Update tests

Codecov Report
Attention: 6 lines in your changes are missing coverage. Please review.

Comparison is base (33090a8) 83.97% compared to head (55721b6) 84.22%.

Files
Patch %
Lines

mt_metadata/transfer_functions/io/zfiles/zmm.py
72.22%
5 Missing :warning:

mt_metadata/transfer_functions/core.py
50.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #192      +/-   ##
==========================================
+ Coverage   83.97%   84.22%   +0.25%
==========================================
  Files         269      269
  Lines       20156    20178      +22
==========================================
+ Hits        16925    16995      +70
+ Misses       3231     3183      -48

Flag
Coverage Δ

tests
84.22% <81.81%> (+0.25%)
:arrow_up:

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

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


Feedback function not working

Hello Team while I was able to deploy the solution, I continue to see the Feedback functionality(it goes on loop for sign-in) not working in the NEO app. Is this a bug?

Hi @sptechmk
Thank you for submitting the issue, we're looking into and get back to you soon with updates.

HI @sptechmk,
Please let us know if you've any updates, if not we'll proceed with closing the issue.


Does Netopeer support TPM TOOLS?

I have no experience with TPM tools but I would think that as long as they need some specific code they are not supported but if not, they should be.


Initialize Database

We have api key for steam and one game in steam account. But when run this console application not getting any data. Do we need to add app manually in it?

Full run it, the CLI tells you to do that.

Hello @xPaw
Tried that as well set full run = 4 as per warning

It gets disconnected from steam and also it says some depot file is missing


Help pulling just one group

Hey there,
First just wanted to say thanks for sharing this!! This is really cool and my friends are all so happy to finally have a way to pull history!!!!  But I'm hoping you can help me with something- I'm pretty new to python so maybe I'm just being dumb and missing something simple.   I can pull all of my groups history (i have like 6 total groups), but I only want to pull ONE of the groups history to csv.  Can you help me just pull one?  What should the request look like?
Here is what I am doing and error messages I am getting- What do I need to change???

python retrieve_msgs.py 'putting my access token here'

Then I get this:
Here is all the groups and their message counts:
[("Group Name1", 88577), ('Group Name2', 62778), ect.....]
Then I try to just pull Group Name1:
Here is what I am entering with error:  python retrieve_msgs.py -g "Group Name1"
usage: retrieve_msgs.py [-h] [-a] [-d] [-g GROUP] [-c CSV] [-o] token
- Error: Too Few Arguments
All I want to pull and run is "Group Name1" to CSV- what would this pull search look like?
Thanks so much!

You forgot to add your access token at the end when calling the group.
Youyang
On Wed, Mar 23, 2016 at 9:42 AM, cdonohue413<EMAIL_ADDRESS>wrote:

Hey there,
First just wanted to say thanks for sharing this!! This is really cool and
my friends are all so happy to finally have a way to pull history!!!! But
I'm hoping you can help me with something- I'm pretty new to python so
maybe I'm just being dumb and missing something simple. I can pull all of
my groups history (i have like 6 total groups), but I only want to pull ONE
of the groups history to csv. Can you help me just pull one? What should
the request look like?
Here is what I am doing and error messages I am getting- What do I need to
change???
python retrieve_msgs.py 'putting my access token here'
Then I get this:
Here is all the groups and their message counts:
[("Group Name1", 88577), ('Group Name2', 62778), ect.....]
Then I try to just pull Group Name1:
Here is what I am entering with error: python retrieve_msgs.py -g "Group
Name1"
usage: retrieve_msgs.py [-h] [-a] [-d] [-g GROUP] [-c CSV] [-o] token

Error: Too Few Arguments

All I want to pull and run is "Group Name1" to CSV- what would this pull
search look like?
Thanks so much!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/youyanggu/groupme_stats/issues/14


Transition effects when route slug changes

Edit: as I finally got this working, I realized it was very similar to https://github.com/vuejs/vuex-router-sync/issues/3 .  The ability to call actions within router hooks ended up being what solved it.  So I guess this may be fixed when router hooks are simplified.  But the ability to put a transition on a watched variable still makes sense, so I'm posting this anyway.

TL;DR: It would be a feature to allow a transition when data changes.  IE if you have Name: {{name}} and name is changed, it would fade-out and then fade-in.

I've used <router-view transition="fade" transition-mode="in-out"> to provide a fade-out, fade-in effect when changing from one route to another.  Now I'm having trouble doing the same thing where the route slug changes, but the component and the route are remaining the same.
I've got a Page component that uses a vuex getter to return the content of the current page based on the URL.  The route is available in the state thanks to vuex-router-sync:
function getCurrentPage (state) {
  var pages = state.pages.filter(page => page.slug === state.route.params.slug)
  return pages.length ? pages[0] : {}
}

Then I am able to access the current page via this getter in my Page.vue component:
<template>

{{{page.title.rendered}}}

      {{{page.content.rendered}}}

</template>

So when the URL updates, the page content immediately updates.  I cannot seem to find a way to use a fade-out, fade-in effect on this change.

Since the route is not changing, the <router-view> transition is not triggered
Since the component is not changing, I can't use an :is="component" transition

I tried a couple of things, like placing a setTimeout in the route.data()  function that delayed next() by some time:
    route: {
      data ({next}) {
        setTimeout(()=>{
          next()
        },150);
      }
    }

Then I hid the component during $routeDataLoading.  I got a proper fade out fade in effect, however the page variable updated immediately, so the page content updated before the fade-out even began.
What I finally did to get it going was a hack to allow actions within router hooks:
route: {
      data ({to,next}) {
        setTimeout(()=>{
          next({
            page:getCurrentPage(to.router.app.$store.state)
          })
        },150);
      }
    }

Since my fade is .15s, this faded out the div during $routeDataLoading, and then faded it back perfectly .15s later when the timeout finished.

Hi @jsiebach
you can use
route: {
    canReuse: false
}

to get a fresh component invoking all transition hooks and effects..!

Closing since this is fixed :smile: .

The solution no longer works with vue-router 2.x, http://vuejs.org/guide/migration-vue-router.html#canReuse-false-deprecated. Any ideas?

@myst729 Using the key attribute with a computed property should work

Or, if you only want to refresh something when the route changes: use watch: on $route.

@posva Yep, this just works for me:
      <transition name="view" mode="out-in" appear>
        <router-view :key="$route.fullPath"></router-view>
      </transition>

Here is a quick tutorial for it that I wrote

@myst729 Is it also possible to do this for only a specific route? I have a transition on all my pages like: /blog, /about-us etc. I want the transition to also happen on /blog/:slug but not on /service/:slug

Nevermind i fixed it with a computed route like this:
  computed: {     key () {       if(this.$route.name == 'service') {         return this.$route.name       } else {         return this.$route.fullPath       }     }   }
Then the key stays the same on the service page. But changes anywhere else

@andre-dw maybe just using an if in key prop is better. Computed seems overload


Add exception to FreeCommand for empty files

Trying to ./bin/alluxio free an empty (0-bytes) files from Alluxio results in the corresponding Alluxio job workers to repeatedly attempt to free the file until reaching the job timeout.
This is because the implementation for free in FreeCommand uses getInAlluxioPercentage() == 0 as the stopping condition, but empty (length 0) files in Alluxio are hardcoded as having 100 in Alluxio percentage.

Codecov Report

Merging #13329 (39a187b) into master (0ee466c) will decrease coverage by 26.52%.
The diff coverage is 37.50%.

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

alluxio-bot, merge this please

alluxio-bot, cherry-pick this to branch-2.5 please


Rename triggered an error

Describe the bug
After i try to rename the function name from test_vec to test, an error happened as below:

Steps to reproduce
The initial code:

Try to rename:

The error:

Expected behavior
No error happends and renamed successfully.
Neovim version (nvim -v)
0.8.2
Operating system/version
Archlinux
Terminal name/version
Alacritty
$TERM environment variable
256color

quickly fix change the rename.whole_project to false

I do that,  but still not works


When OptionButton is pressed, give focus to selected option

A simple usability improvement: give focus to the currently selected option when an OptionButton is pressed.

The previous behavior was to focus on no option in particular (index -1), which was less clear (find the filled circle), less standard (compare e.g. web browsers) and less convenient. For users of the arrow keys, the previous behavior required (in all but two cases) at least one useless button press (to give focus to the first or last item).
It has been asked on the German Godot Community Discord and in Q&A how to achieve this functionality. As far as I could see it was impossible in plain GDScript. It was easy to implement in C++ (the commit is basically a one-liner), and I see no reason to keep the old behavior or to have any other behavior, hence this humble PR.

Thanks for the review. I updated the setter to do the visual update(), so now it should also work when called from other places. I held off on exposing a property for now. If someone has a compelling use case for it, I can still do it.

Thanks!

Cherry-picked for 3.5.

Actually undid cherry-pick as it relies on APIs which are not present in 3.x. A dedicated backport PR could be made for 3.x if needed.


Doesn't install when using doctrine-module 3

I am trying to install this with my laminas project using doctrine but it seems to have some conflicts with installing..
    - Conclusion: remove laminas/laminas-mvc 3.1.1
    - Conclusion: don't install laminas/laminas-mvc 3.1.1
    - doctrine/doctrine-module 1.1.0 requires zendframework/zend-mvc ^2.5.2 -> satisfiable by zendframework/zend-mvc[2.7.11, 2.7.12, 2.7.13, 2.7.14, 2.7.15, 2.5.2, 2.5.3, 2.6.0, 2.6.1, 2.6.2, 2.6.3, 2.7.0, 2.7.1, 2.7.10, 2.7.2, 2.7.3, 2.7.4, 2.7.5, 2.7.6, 2.7.7, 2.7.8, 2.7.9].
.....
....
- Conclusion: don't install doctrine/doctrine-module 4.0.1|install doctrine/doctrine-module 1.0.0|install doctrine/doctrine-module 1.0.1|install doctrine/doctrine-module 1.1.0
    - Conclusion: remove doctrine/doctrine-module 4.0.1|install doctrine/doctrine-module 1.0.0|install doctrine/doctrine-module 1.0.1|install doctrine/doctrine-module 1.1.0
    - laminas-api-tools/api-tools-doctrine 2.3.0 requires phpro/zf-doctrine-hydration-module ^2.0.1 || ^3.0 || ^4.1 -> satisfiable by phpro/zf-doctrine-hydration-module[v2.0.1, v3.0.0, v4.1.0].
    - phpro/zf-doctrine-hydration-module v3.0.0 requires doctrine/doctrine-module ^1.2 -> satisfiable by doctrine/doctrine-module[1.2.0].
    - phpro/zf-doctrine-hydration-module v4.1.0 requires doctrine/doctrine-module ^1.2 || ^2.1.7 -> satisfiable by doctrine/doctrine-module[1.2.0, 2.1.10, 2.1.7, 2.1.8, 2.1.9].
    - phpro/zf-doctrine-hydration-module v2.0.1 requires doctrine/doctrine-module ~1.0 -> satisfiable by doctrine/doctrine-module[1.0.0, 1.0.1, 1.1.0, 1.2.0].
    - Can only install one of: doctrine/doctrine-module[1.2.0,
4.0.1].
    - Can only install one of: doctrine/doctrine-module[2.1.10, 4.0.1].
    - Can only install one of: doctrine/doctrine-module[2.1.7,
4.0.1].
    - Can only install one of: doctrine/doctrine-module[2.1.8,
4.0.1].
    - Can only install one of: doctrine/doctrine-module[2.1.9,
4.0.1].
    - Installation request for doctrine/doctrine-module (locked at 4.0.1) -> satisfiable by doctrine/doctrine-module[4.0.1].

Post your composer.json

"php": "^7.1",
"laminas/laminas-component-installer": "^1.0 || ^2.1",
"laminas/laminas-mvc": "^3.1.1",
"laminas/laminas-cache": "^2.9.0",
"laminas/laminas-db": "^2.10.0",
"laminas/laminas-mvc-form": "^1.0",
"laminas/laminas-json": "^3.1.2",
"laminas/laminas-log": "^2.11",
"laminas/laminas-mvc-console": "^1.2.0",
"laminas/laminas-mvc-i18n": "^1.1.1",
"laminas/laminas-mvc-plugins": "^1.0.1",
"laminas/laminas-psr7bridge": "^1.2.0",
"laminas/laminas-session": "^2.9.1",
"laminas/laminas-di": "^3.1.1",
"doctrine/doctrine-orm-module": "^3.0",
"laminas/laminas-crypt": "^3.3",
"laminas/laminas-authentication": "^2.7",
"slm/locale": "^0.4.1",
"laminas/laminas-permissions-rbac": "^3.0",
"laminas/laminas-serializer": "^2.9",
"gedmo/doctrine-extensions": "^2.4",
"doctrine/data-fixtures": "^1.4",
"laminas/laminas-test": "^3.4",
"doctrine/doctrine-laminas-hydrator": "^2.0",
"laminas/laminas-captcha": "^2.9",
"laminas-api-tools/api-tools": "~1.0",

I can give suggestions but the luck is up to you.
doctrine/doctrine-module 1.1.0 (from your first post) - hard code this to ^4.0
When installing use composer update not composer install
I think your problem lies with phpro/zf-doctrine-hydration-module  - hard code this to ^4.1
From my perspective not much work has happened in Apigilityland since the namespace change to Laminas.  This apigility-doctrine project was mine.  I actively build with it but I have not tried to move to Laminas so what you're doing may be pioneering.
I'm on the Doctrine Project now and I released doctrine-module and doctrine-orm-module for Laminas.  I'm about to release doctrine-mongodb-odm-module and I've submitted some PRs to the api-tools but haven't seen any movement on those PRs.

that is actually what i did on our previous project but i was actually hoping that we can finally use the newer versions of the doctrine-module package. what do you think if i just make another project just for the API and another project for the laminas project itself.. so that i wouldn't have this kind of problem with packages.. what do you think? Thank you for the quick reply.

Most of the changes in the Doctrine modules was to bring them to the standard of the Doctrine Coding Standard and composer changes to use Laminas.  I did my best not to change anything except the hydrator; doctrine/doctrine-laminas-hydrator is the shiny new thing about the modules.  So, if you don't have issues with the old hydrator then it is my opinion that you should stick with zfcampus until attention is turned to api-tools.
As for an API project and Laminas project I think you're doing it all wrong.  The obvious shines through first like managing Doctrine metadata files between projects but that's not the problem.  The problem is you're not writing a front end in Angular or a similar tool.  Your whole project should be only the API.  Build your microservices first, not 3 iterations through multiple re-writes as is the trend.  Building a front end application is Laminas or Mezzio is the wrong way to build a front end.  You can do everything in the API you could imagine doing in Laminas or Mezzio except rendering content because that is the job of Angular (or whatever else like Angular).

i actually use my API for our mobile app only so i am doing this approach. could there be a better approach? I really appreciate your insights on this. thanks!
btw, thank you for the great contribution you had made for apigility and your modules are awesome. i hope i could find a way for this to work like i intend it to do.. i will be waiting for the time we can integrate the newer versions of doctrine with the api-tool.. keep it up!

If you write an API: consume it!  The same API call which returns a HAL-JSON response of a list of concerts to your phone is the same API which returns a list of concerts to your web site.
I wrote etreedb.org in 1999 and I've made a multi-year project of moving it to an API.  That API is https://api.etreedb.org  I suggest you use that documentation built with Apigility in combination with the open source front end for the project to expand your knowledge of front end capabilities today.  p.s. api.etreedb.org endpoints which do not require extra perms are open such as https://api.etreedb.org/source/1
https://search.etreedb.org code is here: https://github.com/etreedb/search

right now the mobile app is the only one consuming the API.. but it would also be a waste if i wouldn't use the laminas-form and other laminas modules for the web.. that is why we built the website using laminas at the first place.. the API was just another feature to be able to create a mobile app and consume it.


Omnitruck shouldn't complain about RHEL/CentOS 7 being not regression tested

Seeing this on CentOS 7:
       WARNING: Chef-Client has not been regression tested on this O/S Distribution
       WARNING: Do not use this configuration for Production Applications.  Use at your own risk.

/cc @charlesjohnson

That's a fact, we don't have EL7 builders or testers.

Wrong place to put this, needs to go in an OCIV backlog or something.  I'm entirely sympathetic, but there's no code to fix here.


[3713] Failed to use ValueType.

Fixes #3713

This was merged from a single integration branch to dev.

bridgedotnet/Bridge@705058579855eec1c4e3e2df2b9017df94b0428b
bridgedotnet/Brdige@a16006483aeb42c20f39a2f21747930fed8cab8e


runtime-config-linux: Add a way to disable runtime cgroup manipulation

So folks can use a different model, if the current linux.resources
approach isn't scratching their itch.
For more motivation, see the discussion here.

NOTLGTM
We are not even done discussion things and you are already opening PRs to change functionality of runtimes implementing the spec

On Thu, Oct 29, 2015 at 11:41:25AM -0700, Michael Crosby wrote:

We are not even done discussion things and you are already opening
PRs to change functionality of runtimes implementing the spec

I hadn't heard any pushback on “we need a way to disable the runtime's
cgroup handling”, and there was explicit positive feedback in 1 and
implicit acceptance in 2.  Is there a reason why “don't touch my
cgroups” would be hard to handle?  Or why “neither cgroupsPath nor
resources were specified” should mean something else?

@wking please don't just throw up PRs when the discussion is not close to a census.

On Thu, Oct 29, 2015 at 12:26:40PM -0700, Vincent Batts wrote:

@wking please don't just throw up PRs when the discussion is not
close to a census.

Punted back to the list in the sub-thread starting with 1.
 Message-ID<EMAIL_ADDRESS>


Address handling of constrained lists since they have been removed from OSCAL after 1.0.0 normalization

To avoid complications caused by constrained lists, "min_items=1" is removed from the oscal models so that what normally would be constrained lists are now regular lists that could be empty.
The original intent is for a list either not to be present, or present with at least one item.  By removing min_items the models could have an optional list that is in fact empty.
Several sections of the code do specific handling of constrained lists.  Either that code should be removed or we should find a way to handle constrained lists internally and re-enable the min_items restriction.

To be addressed at the OscalBaseModel.oscal_read() level.

@butler54 This issue might be overlapped by #1630. @degenaro Could we review this one and maybe confirm which solution either the one from #1630 or this one shall remain?

Closing in favor is #1606 and #1630


Updated deprecated links in bulk-export-tool.rst

Summary
Updated deprecated links in bulk-export-tool.rst
Ticket Link

NA

Hello @Rutam21,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.


docs(README): daily schedule link as workflows MS Build

Description

A link in MS Build section can be navigated to actions page.
Type of Change

[ ] ✨ New feature (non-breaking change which adds functionality)
[ ] 🛠 Bug fix (non-breaking change which fixes an issue)
[ ] ❌ Breaking change (fix or feature that would cause existing functionality to change)
[ ] 🧹 Code refactor
[ ] ✅ Build configuration change
[x] 📝 Documentation
[ ] 🗑 Chore

Thanks @guspan-tanadi


mattermost XMPP support availability

XMPP support available for mattermost?

I'm not sure what is "XMPP support" though, there is a community-made integration, matterbridge.
https://github.com/42wim/matterbridge

Thanks @mmanoharan83! I'd recommend checking the Matterbridge integration linked above.
The integration is used by many and has active development of new features.


Adding a vocabulary into a workspace should add all its imported vocabularies as well

To keep the workspace self-contained, whenever a vocabulary is added to the workspace, for each vocabulary from its transitive import closure:

nothing happens if the vocabulary is already part of the workspace
the vocabulary is added in R/O regime otherwise.

OK. It would be great to have an endpoint in SGOV that would return the list of vocabularies that belong to the transitive closure. Otherwise I'd need to set up some awkward front end process that would gradually resolve and add dependencies. It's possible, but probably not very practical. What do you think?

@karelklima Man, You are reading my brain :-) I was just half-way proposing You one of two options, but You picked one of them before I finished putting things down  :-)
So https://github.com/opendata-mvcr/sgov/issues/78 ?

Done. Example call:
curl --location --request GET 'https://kbss.felk.cvut.cz/sgov-server/vocabularies/školství/imports?namespace=https://slovník.gov.cz/generický/'


Influxdb 2.1.1 – “internal error” - unable to write to bucket

Steps to reproduce:
N/A, Demonstration of the problem several times per day, but with no vissible pattern
Expected behavior:
Ability to query and write data also for bigger db
Actual behavior:
I am running InfluxDB 2.1.1 OSS from the current docker-image. Everything is running as it should. Performance is fine, queries works, API is working. All good. After some time, DB suddenly stop to accept all writes from telegraf agents, but the DB remains up and influxql/flux queries still works fine, nothing bad in standard log. After switching log level to debug, there are „internal error“ messages such as:
ts=2022-02-17T09:42:06.076306Z lvl=debug msg=Request log_id=0ZiV7QXW000 service=http method=POST host=influxdb1:18086 path=/api/v2/write query="bucket=dbinf202%2Fautogen&org=X" proto=HTTP/1.1 status_code=499 response_size=107 content_length=-1 referrer= remote=<IP_ADDRESS>:48940 user_agent=Telegraf took=30028.043ms error="internal error" error_code="internal error"

From the time of “internal error”, there is zero of successful writes to the same bucket up to restart of the container with DB. After restart everything works fine for a while and then the problem repeats. This is randomly happening several  times per day. From the logs I don’t see any repeatable pattern such as problematic query, something wrong with indexes, …
The DB is quite big, keeping federated data from several Prometheus servers for 30 days, all together it’s about 1000 measurements with overall cardinality about 22 million, 0,5TB storage.
To get data redundancy, there are two independent DBs with exactly the same data, which are written by several telegraf agents, reading the data from kafka, writing twice to both DBs (let say DB1 and DB2). Only one DB at a time is opened for a queries (for example DB1). The “internal error” problem is only on DB1, the DB, which is not only writing, but also responding to queries. When I switch the queries to the other one, DB2, the “internal error” write problem will appear on DB2 after a while, but not any more on DB1. So it looks the problem is not the most probably related to data corruption, but it’s lack of some internal resources. It looks similar to #https://github.com/influxdata/influxdb/issues/22721
Environment info:
cat /etc/lsb-release
DISTRIB_DESCRIPTION="Ubuntu 20.04.2 LTS"

docker version
Client:
 Version:       18.01.0-ce
 API version:   1.35
 Go version:    go1.9.2
 Git commit:    03596f5
 Built: Wed Jan 10 20:11:05 2018
 OS/Arch:       linux/amd64
 Experimental:  false
 Orchestrator:  swarm

uname -srm
Linux 5.11.0-22-generic x86_64

influxd version
InfluxDB 2.1.1 (git: 657e1839de) build_date: 2021-11-09T03:03:48Z

Config:
bolt-path = "/var/lib/influxdb2/influxd.bolt"
engine-path = "/var/lib/influxdb2/engine"
reporting-disabled = true
storage-cache-max-memory-size = "2g"
storage-max-index-log-file-size = "8m"
storage-series-id-set-cache-size = 500
storage-wal-fsync-delay = "100ms"
flux-log-enabled = "true"
storage-write-timeout = "30s"
http-write-timeout = "60s"
log-level = "debug"

Attaching db debug log containing two demonstastration of the problem with full log history betwen restart and first occurence of the "internal error".
restart: ts=2022-02-17T09:44:07.055915Z
error:   ts=2022-02-17T10:34:47.660919Z
restart: ts=2022-02-17T10:37:10.950620Z
error:   ts=2022-02-17T11:01:48.713231Z
dbinf202-v2_2022-02-17_a1.log.gz

I am having almost the exact same behaviour.

I know that the size of db in terms of cardinality is far behind recommended values for OSS edition, but I would vote or expect meaningful  error message at least :-)

Did you manage to fix this issue on your end @MilanJaro?

Unfotunately no :-(

how about now (pray)

Still having the same issue. As I understand it is because of high series cardinality. And if my assumption is correct, we can only hope that IOX will improve or fix things.

Update after a while. I have managed to restructure the same data into new db (less measurements, more fields per measurement). Result was much lower cardinality - about 5-7 millions. So from cardinality point of view the instance should be in "supported" borders. Unfortunately, this didn’t' help :-( When I compare old high cardinality db (20mio) with the new one (6,5mio) there is no difference in behavior. Over time upgrades to version 2.2, 2.3, 2.4 - also no help.
The problem is still occurring every day about 2-3 times per day, very often the occurrence couple of minutes after midnight UTC. Another observation, the issue is maybe related to flux queries - in our environment the flux is used more and more. It’s not related to particular query but looks like filling some buffer over the time.
I would like to ask somebody to provide guidelines how to properly debug this problem and what kind of data would help to fix it.

Du you by chance have any delete queries running ?
try disabling if you have.

No deletes. As I wrote initially - on the instance, which is writing only, there are no issues. On the instance, which is writing + reading (mix of influxql+flux), problems.

I also observe a very similar behavior. I use newest InfluxDB from docker image (influxdb:2.6 at the moment).
The error I see is the same as MilanJaro's, but there are also some differences in my situation. First of all, my database is small - it started empty, and it's just 93MB at the moment. Also, my instance of InfluxDB does not get "stuck" after the first failure, but it seems to recover all by itself and properly handles successive requests. Here are some logs demonstrating the issue:
ts=2023-01-24T00:06:04.977993Z lvl=debug msg=Request log_id=0fZEkSnG000 service=http method=POST host=<IP_ADDRESS>:8086 path=/api/v2/write query="bucket=main-bucket&org=X" proto=HTTP/1.1 status_code=204 response_size=0 content_length=-1 referrer= remote=<IP_ADDRESS>:37154 user_agent=Telegraf took=9622.105ms
ts=2023-01-24T00:06:05.357267Z lvl=debug msg="user find by ID" log_id=0fZEkSnG000 store=new took=0.045ms
ts=2023-01-24T00:06:05.357574Z lvl=debug msg="org find" log_id=0fZEkSnG000 store=new took=0.063ms
ts=2023-01-24T00:06:05.357675Z lvl=debug msg="bucket find" log_id=0fZEkSnG000 store=new took=0.078ms
ts=2023-01-24T00:06:05.492559Z lvl=debug msg=Request log_id=0fZEkSnG000 service=http method=POST host=<IP_ADDRESS>:8086 path=/api/v2/write query="bucket=main-bucket&org=X" proto=HTTP/1.1 status_code=204 response_size=0 content_length=-1 referrer= remote=<IP_ADDRESS>:37154 user_agent=Telegraf took=135.769ms
ts=2023-01-24T00:06:15.357343Z lvl=debug msg="user find by ID" log_id=0fZEkSnG000 store=new took=0.028ms
ts=2023-01-24T00:06:15.357584Z lvl=debug msg="org find" log_id=0fZEkSnG000 store=new took=0.033ms
ts=2023-01-24T00:06:15.357646Z lvl=debug msg="bucket find" log_id=0fZEkSnG000 store=new took=0.043ms
ts=2023-01-24T00:06:25.381324Z lvl=debug msg="buckets find" log_id=0fZEkSnG000 store=new took=0.126ms
ts=2023-01-24T00:06:35.359011Z lvl=debug msg="user find by ID" log_id=0fZEkSnG000 store=new took=0.031ms
ts=2023-01-24T00:06:35.359243Z lvl=debug msg="org find" log_id=0fZEkSnG000 store=new took=0.039ms
ts=2023-01-24T00:06:35.359342Z lvl=debug msg="bucket find" log_id=0fZEkSnG000 store=new took=0.075ms
ts=2023-01-24T00:06:35.382067Z lvl=debug msg=Request log_id=0fZEkSnG000 service=http method=POST host=<IP_ADDRESS>:8086 path=/api/v2/write query="bucket=main-bucket&org=X" proto=HTTP/1.1 status_code=499 response_size=90 content_length=-1 referrer= remote=<IP_ADDRESS>:37154 user_agent=Telegraf took=20025.130ms error="internal error" error_code="internal error"
ts=2023-01-24T00:06:45.409036Z lvl=debug msg="buckets find" log_id=0fZEkSnG000 store=new took=0.124ms
ts=2023-01-24T00:06:55.360756Z lvl=debug msg="user find by ID" log_id=0fZEkSnG000 store=new took=0.031ms
ts=2023-01-24T00:06:55.361058Z lvl=debug msg="org find" log_id=0fZEkSnG000 store=new took=0.038ms
ts=2023-01-24T00:06:55.361152Z lvl=debug msg="bucket find" log_id=0fZEkSnG000 store=new took=0.072ms
ts=2023-01-24T00:06:55.409330Z lvl=debug msg=Request log_id=0fZEkSnG000 service=http method=POST host=<IP_ADDRESS>:8086 path=/api/v2/write query="bucket=main-bucket&org=X" proto=HTTP/1.1 status_code=499 response_size=90 content_length=-1 referrer= remote=<IP_ADDRESS>:37608 user_agent=Telegraf took=20050.898ms error="internal error" error_code="internal error"
ts=2023-01-24T00:06:59.318140Z lvl=info msg="index opened with 8 partitions" log_id=0fZEkSnG000 service=storage-engine index=tsi
ts=2023-01-24T00:06:59.318737Z lvl=info msg="loading changes (start)" log_id=0fZEkSnG000 service=storage-engine engine=tsm1 op_name="field indices" op_event=start
ts=2023-01-24T00:06:59.318945Z lvl=info msg="loading changes (end)" log_id=0fZEkSnG000 service=storage-engine engine=tsm1 op_name="field indices" op_event=end op_elapsed=0.211ms
ts=2023-01-24T00:06:59.319780Z lvl=info msg="Reindexing TSM data" log_id=0fZEkSnG000 service=storage-engine engine=tsm1 db_shard_id=1659
ts=2023-01-24T00:06:59.319884Z lvl=info msg="Reindexing WAL data" log_id=0fZEkSnG000 service=storage-engine engine=tsm1 db_shard_id=1659
ts=2023-01-24T00:07:00.270134Z lvl=info msg="saving field index changes (start)" log_id=0fZEkSnG000 service=storage-engine engine=tsm1 op_name=MeasurementFieldSet op_event=start
ts=2023-01-24T00:07:00.270173Z lvl=info msg="Write failed" log_id=0fZEkSnG000 service=storage-engine service=write shard=1659 error="engine: context canceled"
ts=2023-01-24T00:07:00.270417Z lvl=debug msg=Request log_id=0fZEkSnG000 service=http method=POST host=<IP_ADDRESS>:8086 path=/api/v2/write query="bucket=main-bucket&org=X" proto=HTTP/1.1 status_code=204 response_size=0 content_length=-1 referrer= remote=<IP_ADDRESS>:44016 user_agent=Telegraf took=4910.298ms
ts=2023-01-24T00:07:00.271858Z lvl=debug msg="user find by ID" log_id=0fZEkSnG000 store=new took=0.033ms
ts=2023-01-24T00:07:00.272123Z lvl=debug msg="org find" log_id=0fZEkSnG000 store=new took=0.074ms
ts=2023-01-24T00:07:00.272209Z lvl=debug msg="bucket find" log_id=0fZEkSnG000 store=new took=0.059ms
ts=2023-01-24T00:07:00.273441Z lvl=info msg="saving field index changes (end)" log_id=0fZEkSnG000 service=storage-engine engine=tsm1 op_name=MeasurementFieldSet op_event=end op_elapsed=3.333ms
ts=2023-01-24T00:07:00.384429Z lvl=debug msg=Request log_id=0fZEkSnG000 service=http method=POST host=<IP_ADDRESS>:8086 path=/api/v2/write query="bucket=main-bucket&org=X" proto=HTTP/1.1 status_code=204 response_size=0 content_length=-1 referrer= remote=<IP_ADDRESS>:44016 user_agent=Go took=113.079ms
ts=2023-01-24T00:07:00.385765Z lvl=debug msg="user find by ID" log_id=0fZEkSnG000 store=new took=0.067ms
ts=2023-01-24T00:07:00.386125Z lvl=debug msg="org find" log_id=0fZEkSnG000 store=new took=0.051ms
ts=2023-01-24T00:07:00.386212Z lvl=debug msg="bucket find" log_id=0fZEkSnG000 store=new took=0.061ms
ts=2023-01-24T00:07:00.469813Z lvl=debug msg=Request log_id=0fZEkSnG000 service=http method=POST host=<IP_ADDRESS>:8086 path=/api/v2/write query="bucket=main-bucket&org=X" proto=HTTP/1.1 status_code=204 response_size=0 content_length=-1 referrer= remote=<IP_ADDRESS>:44016 user_agent=Telegraf took=84.614ms

I'd be happy to provide more info if needed.

There is very similar issuer being actively debugged here

I believe this is different than this issue https://github.com/influxdata/influxdb/issues/23956 as reads work fine and in the logs it actually say writes failed unlike the other issue both read and writes stop and no logs about anything except executing queries.

meet the same error in 2.7
23-06-24T07:31:28.081184Z     debug   Request {"log_id": "0ic451QG000", "service": "http", "method": "POST", "host": "localhost:8086", "path": "/api/v2/write", "query": "bucket=HardwareDataCollection&org=pku&precision=ms", "proto": "HTTP/1.1", "status_code": 499, "response_size": 107, "content_length": 114, "referrer": "", "remote": "<IP_ADDRESS>:46035", "user_agent": "influxdb-client-java", "took": "104693.598ms", "error": "internal error", "error_code": "internal error"} 2023-06-24T07:31:28.081184Z     debug   Request {"log_id": "0ic451QG000", "service": "http", "method": "POST", "host": "localhost:8086", "path": "/api/v2/write", "query": "bucket=HardwareDataCollection&org=pku&precision=ms", "proto": "HTTP/1.1", "status_code": 499, "response_size": 107, "content_length": 114, "referrer": "", "remote": "[::1]:46185", "user_agent": "influxdb-client-java", "took": "59609.936ms", "error": "internal error", "error_code": "internal error"} 2023-06-24T07:31:28.081184Z     debug   Request {"log_id": "0ic451QG000", "service": "http", "method": "POST", "host": "localhost:8086", "path": "/api/v2/write", "query": "bucket=HardwareDataCollection&org=pku&precision=ms", "proto": "HTTP/1.1", "status_code": 499, "response_size": 107, "content_length": 114, "referrer": "", "remote": "<IP_ADDRESS>:46173", "user_agent": "influxdb-client-java", "took": "88488.970ms", "error": "internal error", "error_code": "internal error"}

met the same error in 2.7
`2023-06-24T07:31:28.081184Z     debug   Request {"log_id": "0ic451QG000", "service": "http", "method": "POST", "host": "localhost:8086", "path": "/api/v2/write", "query": "bucket=HardwareDataCollection&org=pku&precision=ms", "proto": "HTTP/1.1", "status_code": 499, "response_size": 107, "content_length": 114, "referrer": "", "remote": "<IP_ADDRESS>:46035", "user_agent": "influxdb-client-java", "took": "104693.598ms", "error": "internal error", "error_code": "internal error"}
2023-06-24T07:31:28.081184Z     debug   Request {"log_id": "0ic451QG000", "service": "http", "method": "POST", "host": "localhost:8086", "path": "/api/v2/write", "query": "bucket=HardwareDataCollection&org=pku&precision=ms", "proto": "HTTP/1.1", "status_code": 499, "response_size": 107, "content_length": 114, "referrer": "", "remote": "[::1]:46185", "user_agent": "influxdb-client-java", "took": "59609.936ms", "error": "internal error", "error_code": "internal error"}
2023-06-24T07:31:28.081184Z     debug   Request {"log_id": "0ic451QG000", "service": "http", "method": "POST", "host": "localhost:8086", "path": "/api/v2/write", "query": "bucket=HardwareDataCollection&org=pku&precision=ms", "proto": "HTTP/1.1", "status_code": 499, "response_size": 107, "content_length": 114, "referrer": "", "remote": "<IP_ADDRESS>:46173", "user_agent": "influxdb-client-java", "took": "88488.970ms", "error": "internal error", "error_code": "internal error"}`


ng serve with configuration ignores sourceMap

Versions
Angular CLI: 6.0.5
Node: 10.1.0
OS: win32 x64
Angular: 6.0.2
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router
Package                           Version
@angular-devkit/architect         0.6.3
@angular-devkit/build-angular     0.6.3
@angular-devkit/build-optimizer   0.6.0
@angular-devkit/core              0.6.3
@angular-devkit/schematics        0.6.5
@angular/cdk                      6.1.0
@angular/cli                      6.0.5
@angular/material                 6.1.0
@ngtools/webpack                  6.0.3
@schematics/angular               0.6.5
@schematics/update                0.6.5
rxjs                              6.1.0
typescript                        2.7.2
webpack                           4.8.3
Repro steps
I've added configuration for build:
            "layer": {
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.layer.prod.ts"
                }
              ],
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": false,
              "aot": true,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true,
              "styles": [
                "src/styles.scss",
                "node_modules/layer-ui/styles.css"
              ]
            },

And same for serve:
            "layer": {
              "browserTarget": "portal-test:build:layer",
              "sourceMap": true,
              "optimization": false,
              "aot": false,
              "vendorChunk": true
            },

I'm running it with
ng serve -o --proxy-config proxy.config.js -c layer
Observed behavior
<!-- Normally this includes a stack trace and some more information. -->

Everything is minified/uglified
Desired behavior

How should I run configuration layer in dev mode so I get sourceMaps generated, I've tried with --sourceMap flag as well, but it does not work, I never get source maps generated.
I'm basically not sure how can I run some configuration in dev mode
Mention any other details that might be useful (optional)

I believe there is still the issue. I have updated it to 6.0.7.
No maps are generated, and I can't find app.component.ts because of it.

@filipesilva Any news with this one?

@slavede no news yet, we just haven't had time to look at it yet. If you want to try and having a look yourself, I suggest editing ./node_modules/@angular-devkit/build-angular/dev-server directly and checking what's happening to the option merging.

I'm sorry, but we can't reproduce the problem following the instructions you provided.
Remember that we have a large number of issues to resolve, and have only a limited amount of time to reproduce your issue.
Short, explicit instructions make it much more likely we'll be able to reproduce the problem so we can fix it.
If the problem persists, please open a new issue following our submission guidelines.
A good way to make a minimal repro is to create a new app via ng new repro-app and adding the minimum possible code to show the problem. Then you can push this repository to github and link it here.


bump iyes deps

Tested by running 'cargo test' and running examples "two_collections", "stageless_full_dynamic_collection", "atlas_from_grid" and "standard_material" successfully.

Hey, thanks for the Pr :slightly_smiling_face:
Could you run cargo fmt --all please? Otherwise, it looks good to me.

my bad :+1:


test: pin pytest to 7.4.4

Tests started to fail recently and it looks like this is because pytest 8.0.0 changes the semantic of the -k option. We used to pass -k stages/test but that seems to no longer work. So pin pytest to the last good version until this is better understood.

Closing for now in favor of https://github.com/osbuild/osbuild/pull/1564


adding multiple domains in appsettings

hi all,
i have added my default domain in the appsettings but we have more than one domain
can i add multiple domains?
cheers,
rob

No, you can't add multiple domains.
And we have no plans to add this feature. PR welcome!


UG

Update UG

Codecov Report

Merging #297 (b870f88) into master (1f80f46) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #297   +/-   ##
=========================================
  Coverage     76.94%   76.94%
  Complexity      998      998
=========================================
  Files           140      140
  Lines          2646     2646
  Branches        356      356
=========================================
  Hits           2036     2036
  Misses          530      530
  Partials         80       80

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 5048b8c...b870f88. Read the comment docs.


🐛 BUG: Runtime API: cloudflare:sockets TypeError: Invalid URL: <IP_ADDRESS>:1234

Which Cloudflare product(s) does this pertain to?
Workers Runtime
What version(s) of the tool(s) are you using?
3.59.0 [wrangler]
What version of Node are you using?
v16.20.2
What operating system and version are you using?
Mac
Describe the Bug
Observed behavior
can not connet to ip:port
Expected behavior
connect success
Steps to reproduce
Please provide the following:

A minimal working subset of your worker code

import { connect } from 'cloudflare:sockets';
async function handleRequest(request) {
	const tcpSocket = connect({ hostname: '<IP_ADDRESS>', port: 1234 });
	console.log(tcpSocket);
	return new Response("");
}

export default {
	async fetch(request, env, ctx) {
		return handleRequest(request);
	},
};

A minimal working subset of your wrangler.toml
default one

Commands used to start your local dev server, including custom env and cli args
defualt one

Steps to be performed in the browser, curl commands, or a test we can run that reliably fails (at least a percent of the time)
N/A

A git repo we can clone and run a test suit on, or which has a README with step-by-step instructions, is even better. In this case, please use the field below to provide a link to the minimal repro.
Please provide a link to a minimal reproduction
No response
Please provide any relevant error logs
.internal-fc0b03f8-5785-4f7b-a1f6-f7be1cb3bd5f-facade-1.js:14 TypeError: Invalid URL: <IP_ADDRESS>:1234
    at connect (cloudflare:sockets:7:20)
    at handleRequest (index.js:4:21)
    at Object.fetch (index.js:13:12)
    at __facade_modules_fetch__ (.internal-fc0b03f8-5785-4f7b-a1f6-f7be1cb3bd5f-loader.js:24:17)
    at __facade_invokeChain__ (.internal-fc0b03f8-5785-4f7b-a1f6-f7be1cb3bd5f-common.js:16:10)
    at Object.next (.internal-fc0b03f8-5785-4f7b-a1f6-f7be1cb3bd5f-common.js:13:14)
    at jsonError (.internal-fc0b03f8-5785-4f7b-a1f6-f7be1cb3bd5f-facade-1.js:12:32)
    at __facade_invokeChain__ (.internal-fc0b03f8-5785-4f7b-a1f6-f7be1cb3bd5f-common.js:16:10)
    at Object.next (.internal-fc0b03f8-5785-4f7b-a1f6-f7be1cb3bd5f-common.js:13:14)
    at scheduled (.internal-fc0b03f8-5785-4f7b-a1f6-f7be1cb3bd5f-facade-0.js:9:24)

hmm... looks like a regression. For the time being try turning on the fetch_legacy_url compatibility flag and see if that resolves it for you. Working on a fix now.

fetch_legacy_url flag works , thanks for you support

I believe the fix is going out in a release now. Maybe give things a test on monday to see if you can drop the flag.

I believe the fix is going out in a release now. Maybe give things a test on monday to see if you can drop the flag.

Thanks! connect to ip working fine now. But now seems connect method now will not throw any error even I input hostname as wrong ip or domain or worker itself hostname or port 25..

@zizifn was the error thrown before? Can you share your code?


Implement Google/Apple file and protocol specs

Summary:

Updated "external" protocols to latest Apple/Google spec
Updated existing code base accordingly
Implemented new signing and "zipping" behavior

Open TODOs:

[x] Update submission service
[ ] Write unit tests

https://github.com/corona-warn-app/cwa-server/issues/208

[ ] Write integration tests

https://github.com/corona-warn-app/cwa-server/issues/209

[ ] Externalize strings and configurable properties

https://github.com/corona-warn-app/cwa-server/issues/207

[ ] Update signature algorithm

https://github.com/corona-warn-app/cwa-server/issues/205

[ ] Add correct signature algorithm/app package names

https://github.com/corona-warn-app/cwa-server/issues/206

[ ] Re-activate batching (currently everything just put into one batch)

https://github.com/corona-warn-app/cwa-server/issues/204

[ ] Align REST API with Google/Apple spec (and update OpenAPI file)

https://github.com/corona-warn-app/cwa-server/issues/203

Closes:

#168
#87

Sorry for the large PR 🙈

Opened new issues for the open TODOs (see PR description). Will resolve those in follow-up PRs (otherwise this one will get even bigger than it already is).


doc Add version spec for docs of stats collection related feature

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

according to the newest doc generating strategy, docs do not need add version tag anymore


Please add browser support for the x-frame-options security header  Thanks!

Please add browser support for the x-frame-options security header
http://datatracker.ietf.org/doc/rfc7034/
Thanks!

This issue was imported from Google Moderator
Moderator votes: +13
Issue added by Dan A on 2014-04-10
To vote this issue up or down, simply include +1 or -1 in your comment.

+1

+1

I agree that this would be nice.  MDN has the various browser support levels:
https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options

+1

+1

+1

+1

+1

+1

+1 !

+1

Please stop using +1, use GitHub reactions instead, otherwise it will trigger a notification for everyone.

@kelunik: Nope, not yet, see https://github.com/Fyrd/caniuse/issues/2408

+1

+1

+1

Now available at http://caniuse.com/#feat=x-frame-options


GPU VRAM usage significantly higher for LSTM models on TensorFlow v1.X when compared to other frameworks

System information

Have I written custom code (as opposed to using a stock example script
provided in TensorFlow): Custom
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Linux Ubuntu 18.04
TensorFlow installed from (source or binary): binary
TensorFlow version: 2.5
Python version: 3.7.5
GPU model and memory:  NVIDIA Quadro RTX 4000 GPU with 8GB of VRAM
CPU model: Intel(R) Core(TM) i9-9900K CPU operating at 3.60GHz
cuDNN version: 7.6.5

Describe the problem
Hello everybody.
I’ve been experimenting with different models and different frameworks, and I’ve noticed that, when using GPU, GPU VRAM consumption when using LSTM models on the IMDB dataset is significantly higher on TensorFlow v1.X compared to the PyTorch and Keras implementations. Note that I artificially increased the size of the testing set of the MNIST dataset by duplicating the set by 100 times for a total of 1 000 000 samples. I've done so so any difference in inference time may be clearer.
Here are boxplots that showcase the GPU VRAM consumption of numerous LSTM models:

Any ideas on what may be causing this?

Hi @jf9123 ,
Thanks for reporting. Is the reported issue is with TF1.x versions. Can it be reproducible with 2.x versions ? Since 1.x versions are not supported now this may not be considered for fix. Request you to try to reproduce the behaviour with 2.x Versions and let us know the results.Also request you to submit reproducible code. Thanks!

@SuryanarayanaY Here's the code for reproducibility; https://github.com/jf9123/lstm_question/

Hi @jf9123,
I request you to please submit a colab gist as I can't able to reproduce the issue by cloning the repo.

@SuryanarayanaY The issue isn't present in TensorFlow v2.X. Was the behavior not observed on both TensorFlow v1.X and TensorFlow v2.X, or only TensorFlow v2.X?

@jf9123 ,
Since support for TF1.x versions dropped our Team mostly will not look into the issue. I request if you can able to submit code snippet with TF2.x versions we will definitely review the issue. Please note that Keras integrated with Tensorflow only at Backend and if I am not wrong you are comparing keras 2.5v with TF 1.x versions right ?
I request you to compare with 2.x versions of TF and Keras and I am sure Tensorflow will be more performant since Keras is designed for user friendly and it uses Tensorflow only at backend from 2.x versions.
Thanks!

@SuryanarayanaY I apologize for the confusion but the result reported was from TensorFlow 2.5. I just ran it without Keras.


GRPC broker request handler

Currently there's no way to use the GRPC server request from broker side.
Adding a framework of GRPCBrokerResponseHandler parallel to the SingleConnectionBrokerRequestHandler
This handler handles data streaming back from server and process reduce in a streaming fashion.

Codecov Report

Merging #7838 (f8b64b4) into master (1e25962) will decrease coverage by 1.38%.
The diff coverage is 50.00%.

@@             Coverage Diff              @@
##             master    #7838      +/-   ##
============================================
- Coverage     71.67%   70.28%   -1.39%
+ Complexity     4089     4085       -4
============================================
  Files          1579     1583       +4
  Lines         80843    81015     +172
  Branches      12010    12038      +28
============================================
- Hits          57944    56944    -1000
- Misses        18995    20182    +1187
+ Partials       3904     3889      -15

Flag
Coverage Δ

integration1
?

integration2
27.88% <49.01%> (-0.16%)
:arrow_down:

unittests1
68.55% <47.15%> (-0.11%)
:arrow_down:

unittests2
14.53% <0.32%> (-0.14%)
:arrow_down:

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

Impacted Files
Coverage Δ

...roker/requesthandler/BaseBrokerRequestHandler.java
70.38% <ø> (-0.91%)
:arrow_down:

...roker/requesthandler/GrpcBrokerRequestHandler.java
0.00% <0.00%> (ø)

.../pinot/core/query/reduce/ResultReducerFactory.java
72.72% <0.00%> (-27.28%)
:arrow_down:

...re/query/reduce/SelectionOnlyStreamingReducer.java
0.00% <0.00%> (ø)

...inot/core/query/reduce/StreamingReduceService.java
0.00% <0.00%> (ø)

...rg/apache/pinot/core/transport/ServerInstance.java
44.64% <23.52%> (-9.21%)
:arrow_down:

...che/pinot/core/query/reduce/BaseReduceService.java
93.46% <93.46%> (ø)

...thandler/SingleConnectionBrokerRequestHandler.java
87.03% <100.00%> (+0.24%)
:arrow_up:

...e/pinot/core/query/reduce/BrokerReduceService.java
97.29% <100.00%> (+1.34%)
:arrow_up:

...pinot/minion/exception/TaskCancelledException.java
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 112 more

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 1e25962...f8b64b4. Read the comment docs.

I'd just like to go through this PR once. Can we please hold off for a day or so ?


fix(sync): fallback to replacing text on failed edits

This PR does not fix issue #1068. It only falls back to directly replacing text when there is an error. And the original error will still be displayed normally so that users can notice and provide feedback.
Through debugging, it seems that this portion of the code is problematic:
https://github.com/vscode-neovim/vscode-neovim/blob/f2f57f82f1b9d7b16f52fd7977b7fb3d1e447280/src/document_change_manager.ts#L332C1-L333C65

A couple years ago I tried refactoring the nvim -> vscode buffer sync. It is possible, but I ended up running out of time to get it right.
https://github.com/vscode-neovim/vscode-neovim/pull/992#issuecomment-1228734888
Basically, the way it currently works is nvim sends line updates, then vscode-neovim constructs an internal text representation of the buffer using those line updates. Then, it hashes each line, and performs a custom diff with an internal text representation of the old buffer. Then, knowing the lines that change, it decides to replace those lines, or does another diff to create more surgical changes (deleting/adding/replacing within the line).
I'm not sure why this is all needed. Instead, I want to take the nvim line updates, and directly send them to vscode changes. Maybe do a quick diff to simplify things. There is this tool fast-meyers-diff which not only provides an extremely fast diff, but gives you the results in a form you can directly send to the vscode change builder.
I guess we can merge this PR, but I'd rather not have to add more code to this... instead either fix the bug or totally simplify the sync code.

I started to pay attention to this project when you released 0.4.0, so I don't know much historical information.
I have tested the time-consuming of replacing text directly and using diff. My conclusion is that direct replacing text is very fast and diff is very slow.
Since this is a problem that has been discussed before, it is best to solve it once and for all.

directly send them to vscode changes.
There is this tool fast-meyers-diff

It's worth looking into. By the way, have you tested it to verify its feasibility?

From some early testing, fast-meyers-diff seems to be very fast, and might be fast enough for charwise diffing of the entire buffer.
However, diff might not even be necessary if we can directly apply changes from nvim. We could also investigate using nvim lsp to produce changes.

We could also investigate using nvim lsp to produce changes.

I've thought about this, too😀

This was some of my work a while ago: https://github.com/theol0403/vscode-neovim/commit/c6e6c7e94d5a3b2f1cb2ddebe97823285011bc0a

Amazing!

This was some of my work a while ago: theol0403@c6e6c7e

@theol0403
The modified code has been greatly simplified, making the synchronization logic much easier to understand.
In a nutshell, this solution should be better than the previous one in terms of code simplicity, performance, and stability (addressing existing issues).
I noticed that this was a commit made a year ago. Is it possible that there were many potential issues with this plan that prevented you from continuing the research?

@xiyaowong no major issues other than time. There were some bugs and edge cases, including desyncs. I didn't have time to complete it. It should definitely be possible.

@theol0403 How about I pick your commit and continue working? We can identify problem points and then solve them by generating a large number of test cases.

Feel free

However, diff might not even be necessary if we can directly apply changes from nvim.

So far, I'm optimistic about this approach

Sounds good! One note is that some sort of diff is useful (like in my commit) for changes that aren't line add/delete because then the vscode builder can be used to make surgical changes (and not flash syntax hl and such).

In general, it is rare to have a file with 50,000 lines. However, directly replacing the document at this time can meet normal editing needs. If optimization is performed, the effect may be better, although this approach is a bit crude, it is stable and super simple. Of course, using "fast-myers-diff" has absolute advantages in terms of speed, but it is mainly reflected in very large texts, and the speed advantages in small texts are not noticeable in terms of experience. However, this approach is theoretically the most elegant, but we may need to consider some edge cases.
I have completely copied the content you originally committed, and everything is working fine👍. What is probably most needed at the moment is a large amount of testing.

Replacing the entire content (or even replacing an entire line) is not good. VSCode has to re-compute LSP/syntax hl for the entire buffer. The advantage of fast-myers-diff is that it can produce a "smallest number of changes to go from state a to state b", and then surgically perform those in vscode. So for example, deleting a word will actually tell vscode to delete a word.
I think the viable options include replaying changes from nvim (and doing a diff on modified lines), doing a diff on the entire buffer, or marking lines as "dirty" (through logic or diffing a hash) and then doing a diff on those lines only.

I think one possible reason of the prior implementation is that nvim might send multiple updates at once, and so it bundled them together to reduce the number of work vscode was doing. Not sure if that behavior is worth keeping (albeit with simpler code).

...reduce the number of work vscode was doing. Not sure if that behavior is worth keeping

Basic edits such as ciw, diw, diw, x, etc., only trigger one update. When using plug-ins like surround, there may be a slight increase, but the quantity is also negligible. Apart from that, there doesn’t seem to be many other editing needs :eyes: . At least, these are the ones I mostly use in my usual work.

What about vim commands liks %s, %g, macros, 99., etc.

In a 20,000-line file, replace "this" with "that" using "%s/this/that/g" in 3500 places.
Number of edits: 23549
Time consuming: 63869ms 😂
Current solution: < 1s

Yikes, maybe there is a relatively easy solution to move the document.edit(builder) outside of the loop and build the builder incrementally. The only problem is that nvim might give document positions that assume the prior edit has been applied.

Maybe also try benchmarking:

old text-based accumulation code
fast-myers-diff after accumulation
execute diff operations

That will still reduce a lot of code.

Merge the changes as now, using fast-myers-diff to replace the existing diff
Use multiple solutions, such as directly using text replacement when the number of changes reaches a certain level.

Maybe also try benchmarking:

old text-based accumulation code
fast-myers-diff after accumulation
execute diff operations

That will still reduce a lot of code.

Perhaps we can add an additional alternative solution, such as using a replacement approach when the changed content is very disorganized and there are a large number of changes.

I don't think using heuristics is the best approach - it varies based on computer speed, and it is hard to decide magic numbers, and the number of changes is not well-known. Either we:

accumulate direct (save nvim events) edits, and then apply them at once
accumulate internal (apply events to internal record), then use clever diffing (current solution, or switch to fast-myers) to efficiently replay changes

Merge the changes as now, using fast-myers-diff to replace the existing diff

I think this is what we should try first, but we have to be careful to benchmark fast-myers-diff with the old approach (which keeps hashes of each line and does a linewise hash diff first to get changed lines).

Additionally, accumulating changes is necessary. For example, using 'cc' to modify the current line and then returning to normal mode, nvim will send multiple change events to remove the indentation. I guess this is exactly the problem the original author encountered initially.

Merge the changes as now, using fast-myers-diff to replace the existing diff

I think this is what we should try first, but we have to be careful to benchmark fast-myers-diff with the old approach (which keeps hashes of each line and does a linewise hash diff first to get changed lines).

I will give it a simple try, but since I have no experience in text processing, if there are too many issues, I won't delve too deep into it. It's because it can be time-consuming, especially when it comes to edge cases and testing🤧. Moreover, it currently works 99.9% of the time😌.

Diff the entire text directly, and it seems there is no problem.
https://github.com/xiyaowong/test-myers-diff/actions/runs/6655042639

eol

I have unified it, and eol should be a minor problem.

Why no ubuntu?
Also, you should add a test where:

EOL gets changed from LF to CRLF and vice-versa
Tabs get converted to spaces and vice-versa
The entire file gets ggVGJ compressed into a single line
The entire file gets deleted, 0 characters

Why no ubuntu?

Always occurs error: ozone_platform_x11.cc(247)] Missing X server or $DISPLAY, and no time to fix it.
Only testing the diff, there are no platform differences.

Also, you should add a test where:

EOL gets changed from LF to CRLF and vice-versa
Tabs get converted to spaces and vice-versa
The entire file gets ggVGJ compressed into a single line
The entire file gets deleted, 0 characters

I don't see any major issues. The test cases even include changes to binary content.

It failed, but is it possible that the test was too strict? :joy:
https://github.com/xiyaowong/test-myers-diff/actions/runs/6655774024/job/18086786762

ozone_platform_x11.cc(247)] Missing X server or $DISPLAY,

Ah yes, this is why https://github.com/vscode-neovim/vscode-neovim/blob/476502604a5fcfef89c528532de17b391036aed6/.github/workflows/build_test.yml#L39 is used.

ozone_platform_x11.cc(247)] Missing X server or $DISPLAY,

Ah yes, this is why
https://github.com/vscode-neovim/vscode-neovim/blob/476502604a5fcfef89c528532de17b391036aed6/.github/workflows/build_test.yml#L40
is used.

I accidentally deleted it without reading carefully. Haha.

What happens when the user switches the EOL from CRLF to LF?

We all use one EOL for synchronization and convert it back when applying

I knew what I was doing when I wrote that code! :smile:

Awesome. I am a little worried about the time it takes to make large diffs, I don't know how it compares to the old system.
It is possible we may need to do a two-pass algorithm, where we first do a line-wise diff (ideally using a hashing technique instead of comparing each line charwise), where we insert and remove chunks, and then do a char-wise diff on the changed lines.

Also, it may be possible to improve the performance of the calcDiffWithPosition function, it does a lot of string manipulation and might be better to do some sort of pure maths instead.

Also, it may be possible to improve the performance of the calcDiffWithPosition function, it does a lot of string manipulation and might be better to do some sort of pure maths instead.

I think the solution is to create an array containing the length of every line, and then summing those lengths using the same algorithm instead of concatenating the strings.

Well, it's just a test for accuracy now. The next step is to avoid unnecessary operations. By the way, I should mention that the test cases are very stringent and this kind of situation is unlikely to occur in daily use, such as using ggVGJ in an 8k lines file... When performing such operations, VSCode can also become slow.

I can test tomorrow. I have to go to sleep now, it’s already 1 am in my time zone.

version 2 has the best performance

I tried making a version that lazy-loads the character accumulation, but I think the difference is minor. In fact, in my testing, version 1 to version 3 have the same performance. I think the computation is nothing compared to fast-myers-diff.
Version 3
class LazyLineLengths {
  private lines: string[];
  private cache: number[] = [];
  private cacheLength = 0;
  private generator: Generator<number>;

  constructor(text: string) {
    this.lines = text.split("\\n");
    this.cache = new Array(this.lines.length);
    this.generator = this.accumulateLengths();
  }

  private *accumulateLengths(): Generator<number> {
    let cumulativeLength = 0;
    for (let i = 0; i < this.lines.length; i++) {
      cumulativeLength += this.lines[i].length + 1;
      this.cache[i] = cumulativeLength;
      this.cacheLength++;
      yield cumulativeLength;
    }
  }

  getLengthAt(line: number): number {
    while (this.cacheLength <= line) {
      this.generator.next();
    }
    return this.cache[line];
  }

  // given an array of cumulative line lengths, find the line number given a character position after a known start line.
  // return the line as well as the number of characters until the start of the line.
  findLine(pos: number, startLine: number): [number, number] {
    let low = startLine,
      high = this.lines.length - 1;
    while (low < high) {
      const mid = low + Math.floor((high - low) / 2); // can adjust pivot point based on probability of diffs being close together
      if (this.getLengthAt(mid) <= pos) {
        low = mid + 1;
      } else {
        high = mid;
      }
    }
    const char = low > 0 ? this.getLengthAt(low - 1) : 0;
    return [low, char];
  }
}

// fast-myers-diff accepts a raw 1D string, and outputs a list of operations to apply to the buffer.
// However, we must compute the line and character positions of the operations ourselves.
// Assuming the operations are sequential, we can use a binary search to find the line number given a character position,
// with the search space being the cumulative line lengths, bounded on the left by the last line.
// Then, given a character position, we can start counting from the cursor to find the line number, and the remainder is the character position on the line.
function* calcDiffWithPosition(
  oldText: string,
  newText: string
): Generator<DocumentChange> {
  const patch = calcPatch(oldText, newText);
  // generate prefix sum of line lengths (accumulate the length)
  const lineLengths = new LazyLineLengths(oldText);
  let lastLine = 0;
  for (const [start, end, text] of patch) {
    const [lineStart, charToLineStart] = lineLengths.findLine(start, lastLine);
    const [lineEnd, charToLineEnd] = lineLengths.findLine(end, lineStart);
    const charStart = start - charToLineStart;
    const charEnd = end - charToLineEnd;
    const range = new Range(
      new Position(lineStart, charStart),
      new Position(lineEnd, charEnd)
    );
    lastLine = lineEnd;
    yield {
      range,
      text,
      rangeLength: end - start,
    };
  }
}


Add members to organization and sostrades-transition-risk team

Hi,
Could you please invite these github accounts to os-climate organization and add them to sostrades-transition-risk team ?
Team link : https://github.com/orgs/os-climate/teams/sostrades-transition-risk
Accounts :
b4pm-devops
clabarth
naiksushrita
simaosr
Thank you very much !

Done.
To answer the question: the permission to add members to the organization belongs only to organizational owners.  Once people are members and are doing repo-level stuff, then maintainers of that repo can grant those permissions.
Copying @ModeSevenIndustrialSolutions for suggestions as to a better way to channel org membership requests so that our centralized services (Matt, myself, perhaps a few others) can be auto-assigned these requests rather than relying on seeing them originate from within each repo.

Thank you very much !
From what I understand, we have to make issues here to ask to add / remove people and teams on the organization.
Then I already have rights to add / remove people in teams and repositories when they are in the organization.
Also to make managing the repositories easier, I would like to have 2 subteams created (so I can then provide specific rights to the teams for each repo).
Could you please create the following subteams of sostrades-transition-risk and put me as Maintainer on them, so I can then manage members of these ?
sostrades-transition-risk - Repository admins
sostrades-transition-risk - Devops
We have a new joiner, could you please add him to os-climate ?
vdr0u3t
For information we have 4 members that left the project the last months, you can remove them from the organization if you want :
fadwaouniss
KAJBORKA
sushilkumarmane
eloquet

Some poor indenting above...Matt has actually done all of the above, not merely repeated the ask...

Indeed, the GitHub interface slightly mangled my update; apologies for any confusion!

Thank you very much, closing the issue as resolved :)


Added chatbox

@mdazfar2
I made the new pull request, after updating the sync fork. same issue is coming

ignore this @sidhigrover

@sidhigrover still you were no added any close button on chat bot

@sidhigrover still you were no added any close button on chat bot

I will add it .give me some time

@sidhigrover still you were no added any close button on chat bot

you wanted this chatbox in your other website too?

@sidhigrover still you were no added any close button on chat bot

you wanted this chatbox in your other website too?

yes we are working on it

@mdazfar2
sir,check now i fixed the issue

@sidhigrover still you were no added any close button on chat bot

you wanted this chatbox in your other website too?

yes we are working on it

can i can work on your  other project too?

@sidhigrover Let you know about new project

@sidhigrover Let you know about new project

please you can merge my pull request

@mdazfar2 sir,check now i fixed the issue

please you can merge my pull request

@sidhigrover Let you know about new project

@mdazfar2 sir,check now i fixed the issue

Sir,I fixed the issue ,if you don't need any further changes, please you can merge my pull request.

@sidhigrover great work but please update sync fork and then create pull req because you are not updated in main branch

@sidhigrover great work but please update sync fork and then create pull req because you are not updated in main branch
@mdazfar2
I updated sync fork .

@sidhigrover try again becausein my production doesn't shown recent deployment which i was merged


Issue in Function calc_nl_lp in file loudness_zwicker_nonlinear_decay.py

Hello
Into the function calc_nl_lp i find this sentence:
if abs(ui - nl_lp["uo_last"] < 1e-5 ) :  # case 2 (charge)
In my opinion should be
if abs(ui - nl_lp["uo_last"] ) < 1e-5:  # case 2 (charge)
Thanks for your help.

You're right, I will correct that and make new release. I'll keep you posted.

Hello,
The corrections have been included in the new release 0.3.4. Thanks again
If it is ok for you, you can close the issue


Add clipping op(s)

https://www.tensorflow.org/versions/r1.2/api_docs/python/tf/clip_by_value
This is possible with 2 boolean indexing ops, sure - but it might be easier/more efficient to have an explicit clip op...
For now: just the scalar clipping is required (not the array version, but that might be useful one day).
Priority: low.

Implemented as CustomOp and merged.


[PE-D][Tester A] Use Case: Assign volunteer to event

This extension does not occur in the app

Labels: severity.Low type.DocumentationBug
original: FriedCabbageSalad/ped#20

Thanks for highlighting. We have now resolved the issue.


Error before training

When I try to train with my dataset the following error occurs:
INFO:root:Loading model...
INFO:root:Loaded model
INFO:root:Loading data...
112 train files, 28 test files
TypeError                                 Traceback (most recent call last)
 in <cell line: 9>()
7 symbols = load_symbols(os.path.join(alphabet_directory, alphabet.value)) if alphabet.value else DEFAULT_ALPHABET
8 checkpoint_path = os.path.join(checkpoint_directory, dataset.value, checkpoint.value) if checkpoint.value else None
----> 9 train(
10     metadata_path=metadata,
11     dataset_directory=wavs,
3 frames
/content/Voice-Cloning-App/training/tacotron2_model/stft.py in init(self, filter_length, hop_length, win_length, window)
67             # get window and zero center pad it to filter_length
68             fft_window = get_window(window, win_length, fftbins=True)
---> 69             fft_window = pad_center(fft_window, filter_length)
70             fft_window = torch.from_numpy(fft_window).float()
71
TypeError: pad_center() takes 1 positional argument but 2 were given
I have tried different things but they don´t work. Can someone help me?
I am new to coding in general (I only got into it specifically for this program) so I don´t really know how to properly troubleshoot
Thx in advance

I had the same error.
pip install librosa==0.9.2
fixed that for me. For remote use in the colab, I added "librosa==0.9.2" to the code of the section Parameter Line 6


Add tests for backend._topLevelObjectGenerator

This is an important method, and yet doesn't have unit tests!

Fixed in #392


s/multi-user/default/ on systemd user service

Explain your changes here.
multi-user.target apparently only exists for system services.
For user services, the desired target is default.target.
This should fix mina not starting automatically at boot.
Further information here: https://unix.stackexchange.com/q/251211
Explain how you tested your changes here.
Prior to the change, the daemon did not start at boot and I had to run systemctl --user start mina.
After the change, I rebooted my node and confirmed that mina was running at boot.

Fixed https://github.com/MinaProtocol/mina/pull/9375


VimRC plugin broken

Please Review Before Posting!

[x] I checked that the bug does not happen in the CodeMirror Vim demo. If it does, please report it there and not here.
[x] I'm reasonably sure that this bug is indeed about the Vimrc file support and not a general Vim in Obsidian issue. If it's a general Vim issue, report it here.

Describe the bug:
It just doesn't work anymore. I made a new obsidian vault and also tried turned off every plug in except vimrc support, but the vimrc support plugin doesn't work. All I know is that it's producing this error.
It worked fine before but I just noticed that it's suddenly stopped working. Maybe it's because of the new OB update that I just noticed has affected vimrc support plugin.
Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'off')
at VimrcPlugin.eval (main.ts:152:13)
at step (tslib.es6.js:100:23)
at Object.eval [as next] (tslib.es6.js:81:53)
at eval (tslib.es6.js:74:71)
at new Promise ()
at __awaiter (tslib.es6.js:70:12)
at VimrcPlugin.updateVimEvents (main.ts:141:2)
at VimrcPlugin.eval (main.ts:103:9)
at step (tslib.es6.js:100:23)
at Object.eval [as next] (tslib.es6.js:81:53)
Environment (please complete the following information):

OS:
Device name	Ian_Teves
Processor	11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz   2.80 GHz
Installed RAM	16.0 GB (15.8 GB usable)
Device ID	8C34DDB7-B928-4BF7-8648-819AA3203118
Product ID	00342-21968-87127-AAOEM
System type	64-bit operating system, x64-based processor
Pen and touch	Pen support
Vimrc plugin version: Version 0.9.0

Idk what happened...
I didn't restart my computer, I just continued with my day and it fixed itself.
Anyways. It works now. Sorry for the hassle


Deleted last article still shows in internal browser when the list should be empty

Using Vienna Version 3.4.0 Beta 1 :8fc168c6: (6894) on MacOS 10.12.6 I noticed a UX issue when deleting an article.
If I have a subscription that is configured to display the webpage of an article directly, then the internal browser is still displaying the webpage even after I have deleted that article. This does not happen for subscriptions that are not configured to show the webpage of an article directly.
See these screenshots:

Well, the problem is still there in the latest release that I have: Version 3.6.0 Beta 2 :2f2f6e4e: (7229)
I would be glad to give more information to help debug and fix this issue.

I could not reproduce the issue… Didn't the delay required for loading the webpage mislead you ?
Here is my test :

before :

after :

The issue is only there if the deleted article is the last in the current list, see my original screenshots. I have updated the issue title to reflect this, as I didn't mention this specifically before.

The issue is not limited to this case : when « Use Web Pages for Articles » is used, the article pane will remain unchanged until another article is effectively selected.

This is fixed now in 3.6.0 Beta 3 :4c2187c1: (7245). Great! Thanks so much for a very nice RSS reader! This was one topic that confused me for a long time. Very happy to see this fixed!