Update config for xaque208 namespace

Hey!  We had some changes to better match our habits at opus-codium that you will probably want to maintain on top of upstream's commits:

Tag versions as 1.2.3, not v1.2.3:
https://github.com/opus-codium/modulesync_config/blob/master/moduleroot/Rakefile.erb#L28 (CHANGELOG)
https://github.com/opus-codium/modulesync_config/blob/master/moduleroot/Rakefile.erb#L45-L48 (tags)
Adjust the repository names as we name them puppet-<modulename>, not opuscodium-<modulename>:
https://github.com/opus-codium/modulesync_config/blob/master/moduleroot/Rakefile.erb#L41

Hey!  We had some changes to better match our habits at opus-codium that you will probably want to maintain on top of upstream's commits:

Tag versions as 1.2.3, not v1.2.3:
https://github.com/opus-codium/modulesync_config/blob/master/moduleroot/Rakefile.erb#L28 (CHANGELOG)
https://github.com/opus-codium/modulesync_config/blob/master/moduleroot/Rakefile.erb#L45-L48 (tags)
Adjust the repository names as we name them puppet-<modulename>, not opuscodium-<modulename>:
https://github.com/opus-codium/modulesync_config/blob/master/moduleroot/Rakefile.erb#L41

Thanks for the pointers @smortex.  I've committed the changes that you pointed out, since those match my preferences also :)

Thanks for the pointers @smortex.  I've committed the changes that you pointed out, since those match my preferences also :)


Are you from the future? Or is it just a typo 🤣

Hey,
Thanks a lot for your work. Just noticed a small typo in the dates in the news section of the readme.
It says "20024" instead of "2024" :)
Just wanted to let you know!
Best,
Dylan

Hi @dylanjcastillo,
Fixed from the past!
Thank you for pointing this out :)
Best,
Lukas


Enable playback of audio files

As requested in #9081, it would be helpful to allow users to listen to uploaded audio files directly in the Zulip app.

/assign

Hello alya, I am in the contribution phase for outreachy, can you please assign this task to me. Also to brief in on details. How will the player look and function? Will there be play/pause controls? A progress bar?

zulipbot claim

@zulipbot claim

Hi @AleruDivine are you still working on this?. If not, i would love to pick it up?

Hi @xomcodes, yes, I am still working in it.

@zuilipbot abandon

@zulipbot  claim

@zulipbot claim

@alya I have opened the PR adding backend markdown for inline audio files playback... but the backend tests are failing because of this test case, which expects a .mp3 file specifically to render as a URL anchor tag. It is hence, throwing an AssertionError of Expected 'mock' to have been called once. Called 0 times.
There exists no such test case for any video files, which too are not rendered as URL links, so I replaced .mp3 with .mp4  in URL for the above test case, and found out that the test case still throws the same AssertionError, since then it expects the video files to be rendered as a URL too.
The inline rendering of audio files however is working good. How do I proceed now?

The PR should solve the issue... I am unassigning myself to claim another one.

@zulipbot claim


Equippables

https://blog.webaverse.com/pets-and-wearables/
https://docs.webaverse.com/docs/create/wearables
https://docs.webaverse.com/docs/create/sword

I would say this has been implemented


csvkit: 1.5.0 -> 2.0.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for csvkit is: A suite of command-line tools for converting to and working with CSV
meta.homepage for csvkit is: https://github.com/wireservice/csvkit
meta.changelog for csvkit is: https://github.com/wireservice/csvkit/blob/2.0.0/CHANGELOG.rst
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.0.0 with grep in /nix/store/02rlkm2klz0bysmshqqpi0s0mi9lsi9s-csvkit-2.0.0
found 2.0.0 in filename of file in /nix/store/02rlkm2klz0bysmshqqpi0s0mi9lsi9s-csvkit-2.0.0

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

csvkit

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/02rlkm2klz0bysmshqqpi0s0mi9lsi9s-csvkit-2.0.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A csvkit https://github.com/r-ryantm/nixpkgs/archive/19c636343878ff155d1f32ac87223476148adab3.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/19c636343878ff155d1f32ac87223476148adab3#csvkit

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/02rlkm2klz0bysmshqqpi0s0mi9lsi9s-csvkit-2.0.0
ls -la /nix/store/02rlkm2klz0bysmshqqpi0s0mi9lsi9s-csvkit-2.0.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

2 packages built:

csvkit
csvkit.dist

Maintainer pings
cc @AndersonTorres for testing.

@NixOS/nixpkgs-merge-bot merge


2022R2 and pydpf-core==0.5.2b0 incompatibility

Seems that 2022R2 and pydpf-core==0.5.2b0 are not compatible:
>>>  model = dpf.Model(examples.simple_bar)
ImportWarning: An incompatibility has been detected between the DPF server version (4.0 from Ansys 2022R2) and the ansys-grpc-dpf version installed (0.4.0). Please consider using the latest DPF server available in the 2022R1 Ansys unified install.
To follow the compatibility guidelines given in https://dpfdocs.pyansys.com/getting_started/index.html#client-server-compatibility while still using DPF server 4.0, please install version >=0.5.0 of ansys-grpc-dpf with the command:
     pip install ansys-grpc-dpf>=0.5.0

>>> dpf.__version__
>>> '0.5.2b0'

A few things:

ImportWarning is not a great error. Instead, consider subclassing RuntimeError with DPFServerVersionError(RuntimeError)
This error isn't picking up on the right locally installed version of ansys-dpf-core as seen above.

Hi @akaszynski , it seems the problem might come from the version of the ansys-grpc-dpf package you have installed. It has been upgraded too.
What you are comparing is the error message saying grpc-dpf >=0.5.0 is required, which is true for dpf-core 0.5.2b0.
Could you please check the version of ansys-grpc-dpf installed?
The remark about the errors is noted though.

What you are comparing is the error message saying grpc-dpf >=0.5.0 is required, which is true for dpf-core 0.5.2b0.

Good point. I'm not on a stable version, so it makes sense that 0.5.2b0 < 0.5.0
Error message still needs to be fixed.

Sorry, my explanation might not have been the best:
0.5.2b0 is for ansys-dpf-core, and the ">=0.5.0" in the error is a criterion on ansys-grpc-dpf.
I do not see where it compares them and 0.5.2b0 < 0.5.0, which should never be true.
Basically ansys-grpc-dpf >= 0.5.0 is a requirement for any ansys-dpf-core >= 0.5.0, thus including 0.5.2b0.

I think beta releases are considered stable releases in semantic versioning. Either way, 0.5.2b0 isn't working on my end with 2022R2.

@akaszynski Could you share the list of installed packages in your environment? Did you start one from scratch to install 0.5.2b0 in it?

Good and bad news. Problem solved by a fresh virtual enviornment:
cd /tmp
python -m venv .venv
source .venv/bin/activate
pip install wheel
cd ~/ansys/source/pydpf-core/
git checkout 0.5.2b1
pip install -e .
cd ~/Downloads/
python 00-basic_example.py

Now for the bad news: there's an issue with running the tests:
cd ~/ansys/source/pydpf-core/
pip install -r requirements/requirements_test.txt
pytest -vx

/home/alex/ansys/source/pydpf-core/ansys/dpf/core/server_types.py:862: UserWarning: Traceback (most recent call last):
  File "/home/alex/ansys/source/pydpf-core/ansys/dpf/core/server_types.py", line 850, in shutdown
    self._shutdown_func[0](self._shutdown_func[1])
  File "/tmp/.venv/lib/python3.8/site-packages/grpc/_channel.py", line 946, in __call__
    return _end_unary_response_blocking(state, call, False, None)
  File "/tmp/.venv/lib/python3.8/site-packages/grpc/_channel.py", line 849, in _end_unary_response_blocking
    raise _InactiveRpcError(state)
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
	status = StatusCode.UNIMPLEMENTED
	details = ""
	debug_error_string = "{"created":"@1659587557.868850645","description":"Error received from peer ipv4:<IP_ADDRESS>:50054","file":"src/core/lib/surface/call.cc","file_line":966,"grpc_message":"","grpc_status":12}"
>

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/alex/ansys/source/pydpf-core/ansys/dpf/core/server_types.py", line 858, in shutdown
    p = psutil.Process(self.info["server_process_id"])
  File "/tmp/.venv/lib/python3.8/site-packages/psutil/__init__.py", line 332, in __init__
    self._init(pid)
  File "/tmp/.venv/lib/python3.8/site-packages/psutil/__init__.py", line 355, in _init
    self._proc = _psplatform.Process(pid)
  File "/tmp/.venv/lib/python3.8/site-packages/psutil/_pslinux.py", line 1665, in __init__
    self._procfs_path = get_procfs_path()
  File "/tmp/.venv/lib/python3.8/site-packages/psutil/_common.py", line 800, in get_procfs_path
    return sys.modules['psutil'].PROCFS_PATH
KeyError: 'psutil'

Full environment from pip list
Package                               Version   Editable project location
------------------------------------- --------- ----------------------------------
aiohttp                               3.8.1
aiosignal                             1.2.0
ansys-api-platform-instancemanagement 1.0.0b3
ansys-dpf-core                        0.5.2b1   /home/alex/ansys/source/pydpf-core
ansys-dpf-gate                        0.1.1
ansys-grpc-dpf                        0.5.1
ansys-platform-instancemanagement     1.0.2
appdirs                               1.4.4
asttokens                             2.0.5
async-timeout                         4.0.2
attrs                                 22.1.0
autobahn                              22.7.1
Automat                               20.2.0
backcall                              0.2.0
cachetools                            5.2.0
certifi                               2022.6.15
cffi                                  1.15.1
charset-normalizer                    2.1.0
constantly                            15.1.0
coverage                              6.4.2
cryptography                          37.0.4
cycler                                0.11.0
decorator                             5.1.1
executing                             0.8.3
flake8                                5.0.4
fonttools                             4.34.4
frozenlist                            1.3.1
google-api-core                       2.8.2
google-api-python-client              2.55.0
google-auth                           2.9.1
google-auth-httplib2                  0.1.0
googleapis-common-protos              1.56.4
grpcio                                1.47.0
httplib2                              0.20.4
hyperlink                             21.0.0
idna                                  3.3
imageio                               2.21.0
importlib-metadata                    4.12.0
incremental                           21.3.0
iniconfig                             1.1.1
ipython                               8.4.0
jedi                                  0.18.1
kiwisolver                            1.4.4
matplotlib                            3.5.2
matplotlib-inline                     0.1.3
mccabe                                0.7.0
multidict                             6.0.2
numpy                                 1.23.1
packaging                             21.3
parso                                 0.8.3
pexpect                               4.8.0
pickleshare                           0.7.5
Pillow                                9.2.0
pip                                   22.2.2
pluggy                                1.0.0
prompt-toolkit                        3.0.30
protobuf                              3.20.1
protoc-gen-swagger                    0.1.0
psutil                                5.9.1
ptyprocess                            0.7.0
pure-eval                             0.2.2
py                                    1.11.0
pyasn1                                0.4.8
pyasn1-modules                        0.2.8
pycodestyle                           2.9.1
pycparser                             2.21
pyflakes                              2.5.0
Pygments                              2.12.0
pyparsing                             3.0.9
pytest                                7.1.2
pytest-cov                            3.0.0
pytest-rerunfailures                  10.2
python-dateutil                       2.8.2
pyvista                               0.35.2
requests                              2.28.1
rsa                                   4.9
scooby                                0.6.0
setuptools                            56.0.0
six                                   1.16.0
stack-data                            0.3.0
tomli                                 2.0.1
tqdm                                  4.64.0
traitlets                             5.3.0
Twisted                               22.4.0
txaio                                 22.2.1
typing_extensions                     4.3.0
uritemplate                           4.1.1
urllib3                               1.26.11
vtk                                   9.0.3
wcwidth                               0.2.5
wheel                                 0.37.1
wslink                                1.6.6
yarl                                  1.8.1
zipp                                  3.8.1
zope.interface                        5.4.0

Hi @akaszynski, is this still relevant?

Closing as stale, please reopen if still relevant.


Portainer docker service not working when deploying as swarm

Bug description
exec curl -L https://downloads.portainer.io/portainer-agent-stack.yml \     -o portainer-agent-stack.yml
and
docker stack deploy -c portainer-agent-stack.yml portainer
the docker service portainer_portainer and portainer_agent not working
Expected behavior
portainer docker service work
Portainer Logs
portainer_portainer.1.yfrl6p20s82r@OptiPlex-3020    | level=info msg="2021/12/31 02:51:04 failed initializing environment: Get "https://tasks.agent:9001/_ping\": dial tcp: lookup tasks.agent on <IP_ADDRESS>:53: read udp <IP_ADDRESS>:56498-><IP_ADDRESS>:53: read: connection refused"
Steps to reproduce the issue:
There is only one manage node in my docker swarm.
Technical details:

Portainer version: 2.11 CE
Docker version (managed by Portainer): 20.10.7
Kubernetes version (managed by Portainer): None
Platform (windows/linux): linux
Command used to start Portainer (docker run -p 9443:9443 portainer/portainer): docker stack deploy -c portainer-agent-stack.yml portainer
Browser:
Use Case (delete as appropriate): Using Portainer at Home, Using Portainer in a Commerical setup.
Have you reviewed our technical documentation and knowledge base? Yes/No

Additional context
ufw and iptables are both closed.
I can deploy the portainer as singlone service by
docker run -d -p 8000:8000 -p 9443:9443 --name portainer \     --restart=always \     -v /var/run/docker.sock:/var/run/docker.sock \     -v portainer_data:/data \     portainer/portainer-ce:2.11.0
but it not work when i use docker swarm mode.

@weifengsmile
Looks like tasks.agent is not being resolved. Most likely to be an issue with Swarm Overlay networking. Do you have the necessary FW ports open between the servers?
FW Port details:
https://www.digitalocean.com/community/tutorials/how-to-configure-the-linux-firewall-for-docker-swarm-on-ubuntu-16-04
Check Swarm Networking:
https://gist.github.com/alexellis/8e15f2ea1af7281268ec7274686985ba

@weifengsmile Looks like tasks.agent is not being resolved. Most likely to be an issue with Swarm Overlay networking. Do you have the necessary FW ports open between the servers? Is docker DNS working? FW Port details: https://www.digitalocean.com/community/tutorials/how-to-configure-the-linux-firewall-for-docker-swarm-on-ubuntu-16-04 Check Swarm Networking: https://gist.github.com/alexellis/8e15f2ea1af7281268ec7274686985ba

Thanks for your reply.
1.The Firewall (ufw and iptables) has been closed.
2. This is the docker networking check result:

So how can i do to solve the tasks.agent problem?

Have you done any of these tests listed here.. https://gist.github.com/alexellis/8e15f2ea1af7281268ec7274686985ba#file-redis-md
How many nodes do you have in your cluster? Where are the nodes hosted? Which Hypervisor or Public cloud?

There are two nodes in my cluster now, and linux node is swarm manager, the other worker node is run on a mac machine.
I have done some swarm test as the link. Here is the test result, i use docker swarm start two zookeeper and redis service on another worker node based on the network testnet, but only the portainer service does not work. Do you have some ideas?

and the portainer yml file is:

@weifengsmile
Are you able to ping anything from your redis or zookeeper containers?
Are they in the same network? From one of those container can you try ping / dig to tasks.


Better advertisement and feature coverage in media

As the features mature and get more this app might be able to replace commercial and not privacy-friendly solution like Luca App.
How are you promoting new or matured features to the public especially because this app requires wide acceptance of the public. And the major advantage of being more privacy friendly.

Internal Tracking-ID: EXPOSUREAPP-6757

This is closely related to #352 "Discussion about public perception of the app".

Closing this issue as the related internal ticket is set to obsolete.
Developer comment:

Cannot be don by SAP. Must be done by the government or by RKI.
We like and support the idea, but sorry, not possible for SAP.


MAUI net 8.0 ERROR:This version of the Windows App SDK requires Microsoft.Windows.SDK.NET.Ref

Describe the bug
This version of the Windows App SDK requires Microsoft.Windows.SDK.NET.Ref or later. Please update to .NET SDK 6.0.134, 6.0.426, 8.0
I already have net 8.0.403 and the latest visual studio.
Steps to reproduce the bug

Create an empty MAUI project (net8)
Add the latest WindowsAppSdk nuget (PackageReference Include=“Microsoft.WindowsAppSDK” Version=“1.6.240923002”)
Build
Error Code as above
I inserted the fix WindowsSdkPackageVersion 10.0.19041.38 WindowsSdkPackageVersion in the csproj file
and the following error replaces the orginal error:

Severity Code Description Project File Line Suppression State
Error (active) NU1101 Unable to find package Microsoft.NETCore.App.Runtime.Mono.win-arm64. No packages exist with this id in source(s): C:\Program Files\dotnet\library-packs, Microsoft Visual Studio Offline Packages, nuget.org, Package source MauiAppsdktest (net8.0-android), MauiAppsdktest (net8.0-ios), MauiAppsdktest (net8.0-maccatalyst), MauiAppsdktest (net8.0-windows10.0.19041.0) C:\Users\pbray\source\repos\MauiAppsdktest\MauiAppsdktest.csproj 1
Expected behavior
Empty project should build without errors as it does without adding the nuget windowsappsdk.
Screenshots
No response
NuGet package version
Windows App SDK 1.6.1: 1.6.240923002
Packaging type
Unpackaged
Windows version
Windows 10 version 22H2 (19045, 2022 Update)
IDE
Visual Studio 2022
Additional context
No response

Thanks manodasanW unfortunately there appears to be a typo in there as it gives an include error,I will try to correct it and report back.

@Braysoft With MAUI where the project targets multiple OS platforms and you are adding an explicit WinAppSdk package reference, you would need to scope the WinAppSDK package reference to the Windows TFM like below. That is typically automatically done by the transitive MAUI dependency when WinAppSDK is not explicitly referenced.
<PackageReference Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'windows'" Include="Microsoft.WindowsAppSDK" Version="1.6.240923002" />

I can confirm that this works the empty app now compiles and runs correctly,thank you for your help it is much appreciated.


[DOCFIX]Update Unified-and-Transparent-Namespace.md of chinese version

Merged build finished. Test PASSed.

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


Release 23.2.0

Let's aim for a release on Tuesday, September 19. @cguedes could you lead the release process, and write a "How to Release" document that others can follow in the future?

@hammer I suspect we'll be able to get #541 in there too cc @cguedes

It's not impossible that [#138] could be included in the release but I wouldn't count on it. I should have a design to show at the meeting tomorrow morning, maybe we'll have a better idea then.


Breaks touchpad multi-touch gesture settings

Microsoft PowerToys version
0.55.2
Running as admin

[ ] Yes

Area(s) with issue?
Keyboard Manager
Steps to reproduce
On a fresh Windows 11 Home Single Language (Version 21H2, OS build: 22000.493), I set my system up with a handful of touchpad multi-touch gestures before installing any tools.
Steps to reproduce multiple issues:

install powertoys from the installer provided on release page in this repository - v0.55.2
install powertoys and it gets installed as "Powertoys (Preview)". I downloaded the full installer from this repo.
use powertoys to tweak/swap any two keys on Keyboard Manager. not used any other settings in powertoys.
it breaks my touchpad settings for multi-touch gestures when powertoys is running. (Lenovo Ideapad 3)

Some more tests on my end:

disabled mouse utilities to isolate the problem. Did not help.
disabled the keyboard manager, the only one i tweaked. My touchpad issue disappeared; all gestures were restored.
stopped running instance of powertoys. Touchpad issue disappeared; all gestures were restored.

✔ Expected Behavior

Touchpad should function as configured on windows 11 when mouse utilities are not used.
Why is the installed app "Powertoys (Preview)" ? I am fetching the full version.

❌ Actual Behavior

Touchpad does not function as configured; multi-touch gestures break on using unrelated Keyboard Manager settings.
Installer should install full functional application on any system.

Other Software
None except Windows 11 (version details mentioned above)

Sounds like a Duplicate of #3703. Can you confirm by sharing the keys you've remapped?

The "Preview" is only because it's still (heavily) under construction. But I agree this should be removed.

Sounds like a Duplicate of #3703. Can you confirm by sharing the keys you've remapped?

Thank you, Jay. This is indeed a duplicate. I remapped the exact same keys.
#3703 did not turn up on searching for the issue before i opened this one.

Duplicate of #3703

I remapped CTRL and ALT keys. 3-finger tap set to middle mouse, which at least for links on the web does the same as CTRL+first mouse button.
Issue 3703 seems to be somehow lost in transition with multiple newer issues ref'ing it marked as duplicates. It seems to have stuck in Suggested Enhancements milestone instead of any version release milestones since 0.25.
That was v0.18 and this one is at 0.55. Is there any way to bump it up by any chance? 3703 is already tagged Priority-1. So, i don't know what else. :)
All duplicates for context: #3703, #5277, #14594, #14666, #16485
Thank you again for your help.

Yes, please fix this toothache of a bug.


Removed unused code: Removed "FIXME" workaround from RedeemForm

Interbtc UI Pull Request Template
Description

Remove the relevantVaults map defined in the redeemForm submit call.
Address issue #748
This is not a breaking change

New behaviour

No behavior changes happened

@bolajahmad
Could you please sign your commits? Unsigned commits cannot be merged.

@bolajahmad
Thank you for creating this PR. Have you tested doing a premium redeem with this change?

@bolajahmad Could you please sign your commits? Unsigned commits cannot be merged.

@crypto-engineer, I just generated the keys needed to sign off my commits and my subsequent commits will be signed. I didn't know I had to sign them. Do you know how I could still sign the commits I already created, I am having trouble with that

@bolajahmad Thank you for creating this PR. Have you tested doing a premium redeem with this change?

@crypto-engineer, not yet. I am not sure how I can go ahead and obtain test tokens. I am a bit ignorant about it

@crypto-engineer, I have resolved the issues with regard to any typings on the RedeemPage. I have also tested the RedeemForm on the Kintsugi testnet and it works fine as expected. I issued some test BTC and also redeemed them (does premium redeem mean something special, I could not find out much about it).

Closing this now—seems to be stale, with no commits since January


Reader skips over large block of messages after calling seek

Bug Description
In some difficult-to-reproduce circumstances, a reader will skip forward to later in the topic with no indication that anything abnormal happened.
To Reproduce

Publish to a topic for a while; high volume might help; e.g., tens of millions of messages at least
Choose two timestamps, t1 and t2, with a decent window between them, that are both within the publishTimestamp history for the topic
Do the following dozens of times

Create a reader and call .seek(t1)
Read initial messages until you get one in between t1 and t2 (I would think the first message should qualify, but often it doesn't, and I don't know why)
Read and count messages until you see one with a publishTimestamp > t2
Print/return the count

Compare the results across runs

Expected behavior
The result should always be the same, assuming the publisher is setting publishTimestamp monotonically and has already passed t2 at the beginning of the test.
Additional context
I often see that during the run the consumer makes a large jump. Just recently I have noticed that the point it jumps to (the "jump target") increases over time, in a way that I think tracks the messages being published to the topic. I saw a very reliable increase until I stopped the producer, and then the increase stopped.
Configurations I've Tested

Broker versions 2.4.2, 2.5.1
Producer version 2.3.0, 2.5.1
Just one producer at a time
Non-partitioned topics
Batching enabled
Python client, but mostly Java client
Both reader and consumer
Tiered storage; I've observed the issue on timespans that precede, follow, and straddle the ledger offloading boundary, as well as topics that haven't been offloaded at all yet

@gfredericks I moved the conversations here:

from @gfredericks comment
Okay, I've figured out by analyzing the broker logs that this is is presumably due to the consumer_backlog_eviction policy:
21:41:51.542 [pulsar-backlog-quota-checker-26-1] INFO  org.apache.pulsar.broker.service.BacklogQuotaManager - Backlog quota exceeded for topic [persistent://public/default/tmp-integers]. Applying [consumer_backlog_eviction] policy
21:41:51.542 [pulsar-backlog-quota-checker-26-1] INFO  org.apache.bookkeeper.mledger.impl.ManagedCursorImpl - [public/default/persistent/tmp-integers] Skipping 12914 entries on cursor reader-ecf0525784
I don't understand all of the pieces here, but I would say that if this is the expected behavior it is rather unideal. My interpretation of a Reader is that it intends to read every message; if the system can't handle that for some reason or another, it would at least be useful to be able to detect that from the read side so the reader can retry or propagate the failure.
I'm going to keep researching the background issues so I can understand this better.

@gfredericks
I see. The backlog quota policy is applied at the topic level. By default it is disabled. Did you happen to enable backlog quota policy?
/cc @jiazhai @codelipenghui @gaoran10 in the conversation. So they can help you dig more into the problem.

The backlog quota is set to consumer_backlog_eviction, so I believe this is the explanation for what I'm seeing; it's possible that the resolution is just "remove the backlog quota", but I don't yet understand the implications of this to do it confidently.
Specifically:
If we intend to keep a very long history for the topic, is there any reason to have a backlog quota? I think we originally set it because we were worried about slow subscribers using a lot of resources, but do subscribers actually use much additional resources when there is already a long retention policy? Ideally a subscriber just consists of a few pointers into the data and the list of unacked message ids and perhaps some amount of data caching, but not an amount of resource usage linear in the messages between it and the end of the topic.

I noticed if I publish 10 million messages to a topic, meanwhile a slow subscriber consumes just a handful of them, the stats show something like
  "storageSize" :<PHONE_NUMBER>,
  "backlogSize" :<PHONE_NUMBER>,
      // for the subscription
      "msgBacklog" : 10393,

What do these numbers mean? Without subscribers the backlogSize is 0; when I add a subscriber at the beginning, it jumps up to 1.4G; does that mean the brokers or bookies literally copied all 1.4G of messages into a backlog? If not, why is the number so large? If so, what does the "10393" mean for the subscription?

Ultimately I want to know this:
Assuming I have infinite retention (i.e., with tiered storage), what bad thing can happen by not having a backlog quota? Will extra disk space get used? How much? In what situations?

After talking to Ming on slack, I'm pretty confident that I can safely remove the backlog quota.
However, I would say this isn't an ideal solution. Since readers (as opposed to consumers) intend to read every message, and aren't necessarily trying to follow the end of the topic, I think it would make sense to have consumer_backlog_eviction and TTLs not apply to reader cursors, and if a reader is reading messages that become deleteable, the reader could have an exception thrown.
Silently skipping messages is a hard to detect and work around.

Ming judged this as a bug, saying that readers should never skip messages.
If that's the case, I'd be happy to try to contribute a fix, but would need to know what the correct behavior is. Presumably if readers don't skip messages, then there is a scenario where a reader has its messages fall off the retention cliff and get deleted, so the question is what should happen in that case. I think the reader should throw an exception in the client.

@gfredericks sorry for the late response.
I think the contract is the reader should read every message that is available in the storage. The consumer_backlog_eviction and TTL are the policies attached for quota management for topics in a namespace. These settings are how brokers manage the storage for topics that should be independent of how readers and consumers receiving messages. In other words, if a reader to read messages, people should make sure those storage quota policies don't apply to the topics.
With that being said, if people do configure those storage quota settings to the topics and a reader is reading those topics, the broker should detect that the data is cleaned up due to its storage quota policy and throw an exception to the client without silently dropping the messages.
So +1 to your last comment that we need to throw an exception to the clients. A pull request would work for adding this fix.

So I had been assuming that the bug only applied to readers, and that for consumers (non-readers) it's okay to skip messages, as I assume that's the whole point of consumer_backlog_eviction.
But in your message you didn't seem to be distinguishing, so just for clarity:
Should the exception we're talking about be thrown just for readers, or also for consumers?

Yes. Consumers are expected to skip messages in the context of "consumer_backlog_eviction". So the exception is thrown for readers.


Publishing is down again (failed to update source)

Brief description of your issue
Same problem that previously occured #2666 has started again. And downloading the msix from https://cdn.winget.microsoft.com/cache/source.msix returns a 0kb file.
Steps to reproduce
Run winget source update
Expected behavior
winget should have updated successfully
Actual behavior
Winget will attempt to update the source when running any command but will return the message Failed in attempting to update the source: winget. If you run winget source update it will respond with Cancelled
Environment
Windows Package Manager v1.3.2691
Windows: Windows.Desktop v10.0.22621.819
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.18.2691.0

+1

+1

+1

winget source list
-----------------------------------------------------
msstore https://storeedgefd.dsx.mp.microsoft.com/v9.0
winget  https://cdn.winget.microsoft.com/cache

ResourceNotFoundThe specified resource does not exist.

I have the same problem "Failed in attempting to update the source: winget". After following this solution, Winget will work perfectly.

Another workaround is to use a VPN. Use a location far from your current continent.

Another workaround is to use a VPN. Use a location far from your current continent.

I think this is not enough. I tried it with my PC from Europe and my US VPN. Same error both times.
EU IP address
> ping cdn.winget.microsoft.com

Pinging sni1gl.wpc.nucdn.net [<IP_ADDRESS>] with 32 bytes of data:
Reply from <IP_ADDRESS>: bytes=32 time=20ms TTL=56
Reply from <IP_ADDRESS>: bytes=32 time=17ms TTL=56
Reply from <IP_ADDRESS>: bytes=32 time=16ms TTL=56
Reply from <IP_ADDRESS>: bytes=32 time=18ms TTL=56

Ping statistics for <IP_ADDRESS>:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 16ms, Maximum = 20ms, Average = 17ms

> winget upgrade

Failed in attempting to update the source: winget
Name                                    Id                               Version  Available Source
--------------------------------------------------------------------------------------------------
Firefox Developer Edition (x64 hu)      Mozilla.Firefox.DeveloperEdition 108.0    108.0b4   winget
Mozilla Thunderbird (x64 en-US)         Mozilla.Thunderbird              102.3.3  102.5.0   winget
TeamViewer                              TeamViewer.TeamViewer            15.29.4  15.36.6   winget
Azul Zulu JDK 17.36.13 (17.0.4), 64-bit Azul.Zulu.17.JDK                 17.36.13 17.36.15  winget
PowerShell <IP_ADDRESS>-x64                  Microsoft.PowerShell             <IP_ADDRESS>  <IP_ADDRESS>   winget
5 upgrades available.
1 package has a version number that cannot be determined. Using "--include-unknown" may show more results.

Change to US VPN
> ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

> ping cdn.winget.microsoft.com

Pinging sni1gl.wpc.nucdn.net [<IP_ADDRESS>] with 32 bytes of data:
Reply from <IP_ADDRESS>: bytes=32 time=43ms TTL=41
Reply from <IP_ADDRESS>: bytes=32 time=43ms TTL=41
Reply from <IP_ADDRESS>: bytes=32 time=43ms TTL=41
Reply from <IP_ADDRESS>: bytes=32 time=43ms TTL=41

Ping statistics for <IP_ADDRESS>:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 43ms, Maximum = 43ms, Average = 43ms

> winget upgrade

Failed in attempting to update the source: winget
Name                                    Id                               Version  Available Source
--------------------------------------------------------------------------------------------------
Firefox Developer Edition (x64 hu)      Mozilla.Firefox.DeveloperEdition 108.0    108.0b4   winget
Mozilla Thunderbird (x64 en-US)         Mozilla.Thunderbird              102.3.3  102.5.0   winget
TeamViewer                              TeamViewer.TeamViewer            15.29.4  15.36.6   winget
Azul Zulu JDK 17.36.13 (17.0.4), 64-bit Azul.Zulu.17.JDK                 17.36.13 17.36.15  winget
PowerShell <IP_ADDRESS>-x64                  Microsoft.PowerShell             <IP_ADDRESS>  <IP_ADDRESS>   winget
5 upgrades available.
1 package has a version number that cannot be determined. Using "--include-unknown" may show more results.

You can see that the IP of cdn.winget.microsoft.com (<IP_ADDRESS>) and the error (Failed in attempting to update the source: winget) are the same both times.

My bad, that was my UK VPN previously, sorry. It is working if you connect to a VPN server far away from me.

When will this be fixed?

We believe we've found the root cause. We've triggered another purge to reset the cache endpoints and we're working with our CDN provider to ensure all regions are updated. We've got a production change schedule for Monday to hopefully address this permanently.

This has been happening for almost (more than?) a month. This is very alarming. Is winget something that administrators can rely on?

We've gotten an update on the CDN endpoints. There were two endpoints that needed to be manually purged. We've been told these have been completed.

Still not working for me.
PS C:\Users\User\code\BoxSetup> winget source reset --force Resetting all sources...Done PS C:\Users\User\code\BoxSetup> winget source update Updating all sources... Updating source: msstore... Done Updating source: winget... Cancelled

Working now

All, we've had our CDN provider flush a couple of the pesky nodes that weren't getting updated, and we're purging after each publish run. This should have been resolved around 5:00 PM Pacific yesterday.

@denelon It is fixed for me (Hungary, EU).

Still not working for me. Getting 0 byte file from the CDN in US.
cdn.winget.microsoft.com resolves to <IP_ADDRESS> for me.

i posted the issue #2807 referenced above and it was pointed out to me that there is already a pinned issue ... so i experimented a bit more with the info i found in here.
(GitHub places the pinned issues OUTSIDE the list of current issues - i did not even notice it because it is placed in such a way that is confused with an advertising banner... and i developed a habit to ignore anything placed in such locations... thus the pinned issues area is usually ignored)
i tried downloading the https://cdn.winget.microsoft.com/cache/source.msix  file with:

internet explorer: result = error INET_E_DOWNLOAD_FAILURE
MS Edge Chromium, result = downloads ok
Google Chrome, result = downloads ok
Mozilla Firefox, result = downloads ok
winget upgrade --verbose-logs command line (winget v1.4.3531), result = Failed in attempting to update the source: winget An error occurred in the secure channel support

2022-12-28 21:26:41.640 [REPO] Source past auto update time [5 mins]; it has been at least 27870926 mins
2022-12-28 21:26:42.095 [FAIL] WindowsPackageManager.dll!00007FF89ECBBF22: ReturnHr(1) tid(3c90) 80072F7D     Msg:[winrt::hresult_error: An error occurred in the secure channel support]

2022-12-28 21:26:42.096 [FAIL] WindowsPackageManager.dll!00007FF89EB43CF1: LogHr(2) tid(3c90) 80072F7D
2022-12-28 21:26:42.096 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(53)\WindowsPackageManager.dll!00007FF89ECC7451: (caller: 00007FF89EB906FE) LogHr(3) tid(3c90) 80072F7D     Msg:[winrt::hresult_error: An error occurred in the secure channel support]

2022-12-28 21:26:42.096 [REPO] Source add/update failed, waiting a bit and retrying: winget
2022-12-28 21:29:45.049 [FAIL] WindowsPackageManager.dll!00007FF89ECBBF22: ReturnHr(2) tid(3c90) 80072F7D     Msg:[winrt::hresult_error: An error occurred in the secure channel support]

2022-12-28 21:29:45.049 [FAIL] WindowsPackageManager.dll!00007FF89EB43CF1: LogHr(5) tid(3c90) 80072F7D
2022-12-28 21:29:45.050 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(540)\WindowsPackageManager.dll!00007FF89ECC6A33: (caller: 00007FF89EA88B3D) LogHr(6) tid(3c90) 80072F7D     Msg:[winrt::hresult_error: An error occurred in the secure channel support]

2022-12-28 21:29:45.050 [REPO] Failed to update source: winget

ping cdn.winget.microsoft.com

Pinging sni1gl.wpc.nucdn.net [<IP_ADDRESS>] with 32 bytes of data:
Reply from <IP_ADDRESS>: bytes=32 time=6ms TTL=58
Reply from <IP_ADDRESS>: bytes=32 time=6ms TTL=58
Reply from <IP_ADDRESS>: bytes=32 time=6ms TTL=58
Reply from <IP_ADDRESS>: bytes=32 time=5ms TTL=58

Ping statistics for <IP_ADDRESS>:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 5ms, Maximum = 6ms, Average = 5ms

@R-Adrian thanks! That's some hepful information. I wonder if something with the user agent might be at play. I'll share this with the engineering team.

i think i nailed it... the error message is almost correct.... it is a SChannel problem but is actually a problem with Windows (10? 22H2?) ... the operating system is not actually TLS 1.3 compliant and has to use TLS 1.2
The download via the modern browsers works because the browser handles TLS 1.3 internally... but internet explorer and winget rely on the OS to establish the TLS connection... which is not working.
I managed to reproduce the issue on another computer like this:
a) defined the registry key
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001

b) rebooted the system
c) and then managed to cause the schannel winget error by simply enabling the TLS 1.3 checkbox in the Advanced Internet Options ( inetcpl.cpl ) while at the same time having the TLS 1.3 SChannel registry setting above.

d) when the TLS 1.3 checkbox is disabled in inetcpl.cpl, even if the SChannel registry settings for TLS 1.3 client remain enabled the checkbox overrides the registry setting, and winget (and internet explorer) works again... but it uses TLS 1.2 connections

P.S. found further support material, TLS 1.3 seems is not intended to be supported in Windows 10
https://learn.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-

P.S. 2.. after sleeping on it.. i think this TLS 1.3 bug with Microsoft Azure connections might also be the reason for Windows Update and the Microsoft Store app itself randomly failing instantly when you open them during the past few months ... and then they start to mysteriously work again if you leave them alone for a few minutes without doing anything to them.

I get the same error on Windows 11 Home 22H2.
C:\Users\DaveM>winget upgrade --verbose-logs
Failed in attempting to update the source: winget

cdn.winget.microsoft.com resolves to <IP_ADDRESS> for me.
winget version v1.3.2691

I get the same error on Windows 11 Home 22H2.

can you please try temporarily disabling TLS 1.3 from the Internet Options -> Advanced control panel and trying again with that?  (start->run-> inetcpl.cpl) Make sure TLS 1.2 remains enabled there.

Does not seem to help:

Do I have to restart or anything?

Do I have to restart or anything?

Not sure how Win11 behaves here, i only had to restart when i enabled TLS 1.3 in registry for SChannel, not when using the control panel on Win10 22H2.
Maybe try completely disabling TLS 1.3 via the registry options for SChannel and then rebooting?

Happy New Year, and i tried testing another thing...

on Win 10, toggling TLS 1.3 on/off in inetcpl.cpl still causes winget errors when TLS is on
according to Qualys SSL Labs  https://cdn.winget.microsoft.com appears to be serving DIFFERENT content depending on the connection being on TLS 1.2 or TLS 1.3 and also if SNI is negotiated or not negotiated.
https://www.ssllabs.com/ssltest/analyze.html?d=cdn.winget.microsoft.com

i cannot make SSLLabs analyze the European side of the CDN - SSLLabs does not let me select <IP_ADDRESS> and it auto-selects to the North America one, <IP_ADDRESS>.. so i added that to my hosts file and tested again with that.
result: Same error happens with winget and <IP_ADDRESS> present in the hosts file (on Windows 10 22H2)

+1 Solutions didn't work for me.

We've been working with our CDN provider to squash the nasty zero-byte file being cached and served. Is anyone still getting this problem? If you are, can you share the IP address you're hitting?

TLS 1.3 error is still there - the first few tries are with TLS 1.3 enabled then it works after disabling it again.

C:\WINDOWS\system32>ping cdn.winget.microsoft.com

Pinging sni1gl.wpc.nucdn.net [2606:2800:233:1cb7:261b:1f9c:2074:3c] with 32 bytes of data:
Reply from 2606:2800:233:1cb7:261b:1f9c:2074:3c: time=11ms
Reply from 2606:2800:233:1cb7:261b:1f9c:2074:3c: time=11ms
Reply from 2606:2800:233:1cb7:261b:1f9c:2074:3c: time=11ms
Reply from 2606:2800:233:1cb7:261b:1f9c:2074:3c: time=11ms

Ping statistics for 2606:2800:233:1cb7:261b:1f9c:2074:3c:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 11ms, Maximum = 11ms, Average = 11ms

Yes, same error...

+1 EU (Belgium)

+1
C:\Users\tarro>ping cdn.winget.microsoft.com

Pinging sni1gl.wpc.nucdn.net [<IP_ADDRESS>] with 32 bytes of data:
Reply from <IP_ADDRESS>: bytes=32 time=377ms TTL=50
Reply from <IP_ADDRESS>: bytes=32 time=362ms TTL=50
Reply from <IP_ADDRESS>: bytes=32 time=378ms TTL=50
Reply from <IP_ADDRESS>: bytes=32 time=372ms TTL=50

Ping statistics for <IP_ADDRESS>:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 362ms, Maximum = 378ms, Average = 372ms

C:\>winget upgrade
Failed in attempting to update the source: winget
Failed when searching source; results will not be included: winget
No installed package found matching input criteria.

C:\>winget source list
Name    Argument
-----------------------------------------------------
msstore https://storeedgefd.dsx.mp.microsoft.com/v9.0
winget  https://cdn.winget.microsoft.com/cache

C:\>ping cdn.winget.microsoft.com

Pinging sni1gl.wpc.nucdn.net [<IP_ADDRESS>] with 32 bytes of data:
Reply from <IP_ADDRESS>: bytes=32 time=5ms TTL=58
Reply from <IP_ADDRESS>: bytes=32 time=5ms TTL=58
Reply from <IP_ADDRESS>: bytes=32 time=5ms TTL=58
Reply from <IP_ADDRESS>: bytes=32 time=5ms TTL=58

Ping statistics for <IP_ADDRESS>:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 5ms, Maximum = 5ms, Average = 5ms

Same:
C:\Windows\System32>ping cdn.winget.microsoft.com
Pinging sni1gl.wpc.nucdn.net [2606:2800:11f:1cb7:261b:1f9c:2074:3c] with 32 bytes of data:
Reply from 2606:2800:11f:1cb7:261b:1f9c:2074:3c: time=16ms
Reply from 2606:2800:11f:1cb7:261b:1f9c:2074:3c: time=17ms
Reply from 2606:2800:11f:1cb7:261b:1f9c:2074:3c: time=21ms
Reply from 2606:2800:11f:1cb7:261b:1f9c:2074:3c: time=16ms
Ping statistics for 2606:2800:11f:1cb7:261b:1f9c:2074:3c:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 16ms, Maximum = 21ms, Average = 17ms

I'm still getting the error:

Looks like it might be related to an expired certificate. Get the following error when navigating to https://cdn.winget.microsoft.com/cache/source.msix

the expired certificate is actually a slightly different problem than the primary issue of this thread. Still related to the general CDN infrastructure problems tho.
-----BEGIN CERTIFICATE-----
MIIIVzCCBj+gAwIBAgITMwAqQugcrqvHO0PEswAAACpC6DANBgkqhkiG9w0BAQwF
ADBZMQswCQYDVQQGEwJVUzEeMBwGA1UEChMVTWljcm9zb2Z0IENvcnBvcmF0aW9u
MSowKAYDVQQDEyFNaWNyb3NvZnQgQXp1cmUgVExTIElzc3VpbmcgQ0EgMDUwHhcN
MjIwMjE3MDAyNTU2WhcNMjMwMjEyMDAyNTU2WjBvMQswCQYDVQQGEwJVUzELMAkG
A1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBD
b3Jwb3JhdGlvbjEhMB8GA1UEAxMYY2RuLndpbmdldC5taWNyb3NvZnQuY29tMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApKEJOklptsBt/bO/25MfIHta
hOX0b6Pl29wE5wmwTxo+k+xjxOMRMYa4NIdRap/SPn89Cxy1+Gu9G4tcwoNoz3t1
MgJasYX9jCzJ2xh+rSqiMOiDlA+4bpr/kmPJgBKBoSCp2qEwNP4IqBXtDJMFHimP
pC+gkb4O78Utpwd9axlW+ZW5FXm51zJw5p5zzTgAZecTjjinJkbqFxMfxEnb0Bbu
DxuvSOhQ5vUtYYCVxGMzn9xUC8bAg4rvF6LU8jDQqXa6MXoUz+ypXrOT9NymO/zi
xVh3AJ5daP11MJoY5Z8DWjNV0tu/9ma7skz2gkiYOcdpoLSI+v7/63Bor9jfsQID
AQABo4IEADCCA/wwggF+BgorBgEEAdZ5AgQCBIIBbgSCAWoBaAB3AK33vvp8/xDI
i509nB4+GGq0Zyldz7EMJMqFhjTr3IKKAAABfwUbbN0AAAQDAEgwRgIhALcqVaZw
KB2T6cggiOnWA2NK2jAzlve3g9YtS5duwn3HAiEAoiyQJSjAxKnhsAFTeqFgQ0sY
ry8/p6Ix4GHJ0C+MBX4AdQDoPtDaPvUGNTLnVyi8iWvJA9PL0RFr7Otp4Xd9bQa9
bgAAAX8FG20RAAAEAwBGMEQCIC5wxXoSv+GmdAj+G2g0pRNeeYMN31yBBvOP31r8
kqcfAiBiEW2B7WUuK6hBy1Es8fhyYmjrC47dHYgxlmixoV6dogB2AHoyjFTYty22
IOo44FIe6YQWcDIThU070ivBOlejUutSAAABfwUbbTIAAAQDAEcwRQIgGIq8mV//
8pqIAlzwMUTBeUxRHg61/wcMxRX29kf3ZWgCIQDJL0erqSxYAl32Ss1mXQjyuOWS
OkNDbkDCHijcmV8R+DAnBgkrBgEEAYI3FQoEGjAYMAoGCCsGAQUFBwMCMAoGCCsG
AQUFBwMBMDwGCSsGAQQBgjcVBwQvMC0GJSsGAQQBgjcVCIe91xuB5+tGgoGdLo7Q
DIfw2h1dgoTlaYLzpz4CAWQCASMwga4GCCsGAQUFBwEBBIGhMIGeMG0GCCsGAQUF
BzAChmFodHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpb3BzL2NlcnRzL01pY3Jv
c29mdCUyMEF6dXJlJTIwVExTJTIwSXNzdWluZyUyMENBJTIwMDUlMjAtJTIweHNp
Z24uY3J0MC0GCCsGAQUFBzABhiFodHRwOi8vb25lb2NzcC5taWNyb3NvZnQuY29t
L29jc3AwHQYDVR0OBBYEFLerI7cj9smhQIsMg9lHQqlJMbpwMA4GA1UdDwEB/wQE
AwIEsDAjBgNVHREEHDAaghhjZG4ud2luZ2V0Lm1pY3Jvc29mdC5jb20wZAYDVR0f
BF0wWzBZoFegVYZTaHR0cDovL3d3dy5taWNyb3NvZnQuY29tL3BraW9wcy9jcmwv
TWljcm9zb2Z0JTIwQXp1cmUlMjBUTFMlMjBJc3N1aW5nJTIwQ0ElMjAwNS5jcmww
ZgYDVR0gBF8wXTBRBgwrBgEEAYI3TIN9AQEwQTA/BggrBgEFBQcCARYzaHR0cDov
L3d3dy5taWNyb3NvZnQuY29tL3BraW9wcy9Eb2NzL1JlcG9zaXRvcnkuaHRtMAgG
BmeBDAECAjAfBgNVHSMEGDAWgBTHspx/HOO4Wu/paBqoXZTBJlJqaDAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDQYJKoZIhvcNAQEMBQADggIBADRimlcV
/sTP4KBMXbonhX8nwS2GS9LSm01H6cNN+wwkOtgskEysf4t849YZC3al2mrcCIwm
rYOLbDVMjgWlveyOn7m+E+nbaNwcKO010p0uEGMsTdNxGernCBCgGI9Z5VXpp+2K
U12pfXr76FViTBseFZea4TuVIaALBrCsG7F5Xm0QpNhvYBOWao7gP29BPuLL7n95
E7wUxBKqXTsHGEbcCHRBodP0mvxLXuJm6ODeq3jscNCu+62bqzniwLojgpNwHLNv
EBTIGS7CkVIPC96A95eL8bc6yIkI0auHF30UsyD3hmMZTFZSGN/KDWZgQ80c7cjD
rlWV9V11nL5D535Ej7InGdEwyNt5SlIPJI1LsiXL+ISNb/bGL5z7ZPIyPf3yj6P+
UBePr6pRXxooQ+XzLtH1EUBRjQZWiU342vQMIIMv/Qm50mI/Py6YPy/o1+IZoAGn
RkU/ElG2MQnewvQljjfUjBqNT0Ob34TgHjvoNrbOy7OmfIpxbwQAC46EgkwtwI0W
tHgj9uJGs62DvuwLkP4ydxFMkgVOBA+Goq4NeUTNvLMg4T53EcpCSB5vRwvRvmQ5
5Rkw6zjDgY9LBYudFxfkbnHoZGMG8SQ5GmmuyQ4bLn9SHmnfmsolSWJMmM1YZ5+8
JUkUUWV1d80UIQoYPndp9xbrLlKssEQ7v11i
-----END CERTIFICATE-----

We're working to renew the certificate.

https://github.com/microsoft/winget-cli/issues/2956

Fixed after uninstalling internet download manager.

Fixed after uninstalling internet download manager.

i do not have internet download manager installed (or ever had it) and can still reliably trigger the CDN bug on multiple WIndows 10 computers that i use (both at home and at the office) by simply force-enabling TLS 1.3 support (which is "experimental" in Windows 10).
Maybe Internet Download Manager was messing with the system TLS support in SChannel and uninstalling it just reconfigured SChannel back to the defaults?

Fixed after uninstalling internet download manager.

i do not have internet download manager installed (or ever had it) and can still reliably trigger the CDN bug on multiple WIndows 10 computers that i use (both at home and at the office) by simply force-enabling TLS 1.3 support (which is "experimental" in Windows 10).
Maybe Internet Download Manager was messing with the system TLS support in SChannel and uninstalling it just reconfigured SChannel back to the defaults?

Probably, Disabling TLS 1.3 didn't help

This issue just began a few days ago for me, about two days after reinstalling (but kept my personal files). Nothing suggested so far has helped =[

Update: It happened again but installing Cloudflare WARP solved the issue, I think the problem isn't with winget CDN, but my ISP (Grameenphone), because I'm having same issue with twitter and GitHub (sometimes).

Update:
My problem was solved. It was caused by installing Private Internet Access which automatically turned on it's "VPN Kill switch" not allowing any traffic to flow via windows built-in networking. Browsers worked fine though which is why I was confused. I turned off the kill switch and everything appears to work fine now.

Hey all, we've addressed the zero-byte file issue in the CDN.
Publishing has been working consistently since then, so I'm going to go ahead and close this issue.
We're aware there are users who are still having issues updating the source in some scenarios, so we'll deal with those on a more case by case basis.


JGRP-2022 XSD schemas do not properly validate

All schemas now use namespace urn:org.jgroups:SOMETHING:VERSION where
SOMETHING is one of jgroups, fork and relay, and VERSION is aligned with
major.minor JGroups version and published on
http://www.jgroups.org/schema/SOMETHING-VERSION.xsd (it is not necessary
to publish new schema if it has not changed since the previous version,
though; older schema can be still used even in newer version).
Note that once published (in x.x.0 release), the schema should not be further
changed until next minor version.
https://issues.jboss.org/browse/JGRP-2022

Hmm, problems:

The generated schema doesn't validate
fork.xsd doesn't exist, it is still fork-stacks.xsd
fork-stacks.xsd: cannot resolve type jgroups:ConfigType

OK, I somehow missed the position of xs:any in generated schema. And I can rename fork-stacks.xsd  to fork.xsd, but there's a problem that makes current fork stacks configuration non-validable. You'd prefer to paste the stack as it is into the fork-stacks.xml, into the config element, but even though you declare config element of the type jgroups:ConfigType, you'd still need to prefix every protocol with jgroups:, which is quite inconvenient.
I am working on a way to change this, but not without breaking compatibility.

Also, I've found that embedding the schema into main jgroups config does not work as you'd like...

So, the schemas above works with xmllint --nonet --noout --schema schema.xsd file.xml, but in order to test this you need to change <xs:import schemaLocation="..."> to refer to the local file, not the one already published on web.
Please check external.xml which shows how the embedded configurations look. Not really nice, but I did not want to rework schema generator.
Also note that I haven't touched the parsers, so parsing is probably broken.

sigh... this is getting too complicated. Let's just leave this then, XSD schema has always worked for me... :-)

Or we discuss it in Konstanz...


Setting a default font not working. Example attached.

In using custom fonts I cannot get the editor to set it as a default. After initializing Quill I am using quill.format but the quill.format('font', fontname) will not work but quill.format('size', '24pt') does works.
Would anyone have some insight on how to get this to work.
A work around would be to set the css font on the .ql-editor as the css shows. I have this commented out for now because while that does work I need it to be in my quill.getContents(). For export reasons I need each Op specify the font to use.
Steps for Reproduction
You can see a reproduction of this here:
https://jsfiddle.net/hk9e60zg/6/
Expected behavior:
As soon as I start typing the font should be applied.
Actual behavior:
The font isn't applied but the size is.
Platforms:
macOS
Safari 17.5 and Chrome 128
Version:
2.0.2

Figured out my issue, not a bug.

Hi @joe-azps, any chance you can share what you did to fix it, as I'm about to do the same thing and could do with a working example! Thanks.

Hi @joe-azps, any chance you can share what you did to fix it, as I'm about to do the same thing and could do with a working example! Thanks.

Here is the working one. I was missing the style for the font.
https://jsfiddle.net/nrz5y149/


Update base.js

added support for multiple ajax target

Coverage remained the same at 92.308% when pulling f49b7c832849a2e64f827f304a80e739d47882e8 on bansal12345:MultipleAjaxTarget into 993ec2766fd0c5ea51bf8287d095f8fea420e21c on RohanPoojary:master.


Database not working on first use

As the title states. As a work around, I fire a random select query when the app loads (although it's not very elegant solution, it still works :D). Is this bug real or something that I am doing wrong here?

Please share the code so we can look that is going wrong.

The issue is closed because of no response. Please file the new issue if the problem still exists.


Separate Gibbs handling

This PR is my take on a long-standing issue/discussion around Gibbs sampling. In my opinion, the Gibbs sampler should provide an interface for the updates of states, Hamiltonians etc. of the components such that sampler can easily opt-in and enable Gibbs sampling but do not have to adapt the implementation of their sampling steps.
So with this change, every sampler can expect that the provided state is accurate and uptodate. For Gibbs sampling, updates of the states should be performed in gibbs_state. The interface currently does not include a way to avoid recomputing the log probabilities required by the components. For some samplers these are the log joint probabilities but e.g. ESS uses neither the standard log joint probability nor the log likelihood and DynamicHMC also requires the gradient of the log probability, so probably it is not applicable for every sampler. I imagine the best way would be to check if varinfo.logp should be recomputed before updating the state in, e.g., a separate function such as gibbs_rerun(prev_sampler, sampler) which would return true by default. Then one would have to implement gibbs_rerun explicitly for all combinations of samplers for which this computation is not needed.

Pull Request Test Coverage Report for Build 441095995

23 of 23 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.4%) to 68.65%

Totals

Change from base Build 440066893:
-0.4%

Covered Lines:
900

Relevant Lines:
1311

💛  - Coveralls

I still think that gibbs_rerun could impact extensibility sometime, but I cannot think of anything better than what David argued.  It only concerns an optimization, anyway.

I still think that gibbs_rerun could impact extensibility sometime, but I cannot think of anything better than what David argued.  It only concerns an optimization, anyway.

I'll review this PR soon - sorry for the delay!

I'll review this PR soon - sorry for the delay!

Bump :slightly_smiling_face:

Bump :slightly_smiling_face:

Overall, it makes sense to introduce a more rigorous mechanism for deciding when to re-run a model. However, I wonder whether it is necessary to be as strict as implemented here. For example, I would expect the previous sampler to fully determine whether to re-run a model in most cases.

As far as I can tell, usually we have to know both the previous and the current sampler to determine if it is necessary to rerun the model, i.e., to repopulate vi.logp. E.g., some samplers such as PG always reset vi.logp, regardless of the previous sampler, and hence the model does not have to be rerun - however, for other samplers (and the same previous sampler) one has to repopulate vi.logp.
@phipsgabler also asked about the two-argument gibbs_rerun and why it is necessary, I tried to  while ago (https://github.com/TuringLang/Turing.jl/pull/1500#discussion_r549788223) explains it in more detail:

vi.logp means different things for different samplers (sometimes it is the joint log probability, sometimes it is the likelihood, sometimes it is something in between, and sometimes it is something completely different), some samplers just don't care about the value of vi.logp in their sampling step or reset everything to zero, etc.
Therefore I think the only reasonable way to define rerun (regardless how it is saved or implemented) is to compare two concrete samplers. The default setting of gibbs_rerun(prev_sampler, sampler) = true makes sure that every user implementation is always mathematically correct, and then users have to explicitly define if one can save one computation for a specific previous sampler by implementing gibbs_rerun for this specific sampler. The current implementation is just wrong, to be honest, since it ignores all these facts - however, I assume it does not lead to any problems since vi.logp is basically always recomputed, apart from MH with a previous sampler that is neither ESS, PG, nor GibbsConditional. shrug

Overall, it makes sense to introduce a more rigorous mechanism for deciding when to re-run a model. However, I wonder whether it is necessary to be as strict as implemented here. For example, I would expect the previous sampler to fully determine whether to re-run a model in most cases.

As far as I can tell, usually we have to know both the previous and the current sampler to determine if it is necessary to rerun the model, i.e., to repopulate vi.logp. E.g., some samplers such as PG always reset vi.logp, regardless of the previous sampler, and hence the model does not have to be rerun - however, for other samplers (and the same previous sampler) one has to repopulate vi.logp.
@phipsgabler also asked about the two-argument gibbs_rerun and why it is necessary, I tried to  while ago (https://github.com/TuringLang/Turing.jl/pull/1500#discussion_r549788223) explains it in more detail:

vi.logp means different things for different samplers (sometimes it is the joint log probability, sometimes it is the likelihood, sometimes it is something in between, and sometimes it is something completely different), some samplers just don't care about the value of vi.logp in their sampling step or reset everything to zero, etc.
Therefore I think the only reasonable way to define rerun (regardless how it is saved or implemented) is to compare two concrete samplers. The default setting of gibbs_rerun(prev_sampler, sampler) = true makes sure that every user implementation is always mathematically correct, and then users have to explicitly define if one can save one computation for a specific previous sampler by implementing gibbs_rerun for this specific sampler. The current implementation is just wrong, to be honest, since it ignores all these facts - however, I assume it does not lead to any problems since vi.logp is basically always recomputed, apart from MH with a previous sampler that is neither ESS, PG, nor GibbsConditional. shrug

thanks, @devmotion for the clarifications. It's now clear to me why we need the two-argument implementation of gibbs_rerun. I am happy to merge this PR as is except that

Consider keeping updategid! in this PR, and refactor/remove it in separate PRs. I think it's sensible to consider refactoring the variable assignment in Gibbs samplers, but feels it's better to do it in a separate effort to avoid undesirable effects.

Regarding gibbs_rerun(prev_sampler, sampler), I think it is possible to consider to make it a bit more modular (in future PRs), e.g. by introducing an additional sampler-specific attribute:
gibbs_attribute (sampler) = one of a few possible attributes
gibbs_rerun(prev_sampler, sampler) = gibbs_rerun(gibbs_attribute (prev_sampler), gibbs_attribute (sampler))

Such designs allow us to reuse some gibbs_rerun definitions and potentially avoiding the need to gathering sampler specific implementation for Gibbs into a single file.

thanks, @devmotion for the clarifications. It's now clear to me why we need the two-argument implementation of gibbs_rerun. I am happy to merge this PR as is except that

Consider keeping updategid! in this PR, and refactor/remove it in separate PRs. I think it's sensible to consider refactoring the variable assignment in Gibbs samplers, but feels it's better to do it in a separate effort to avoid undesirable effects.

Regarding gibbs_rerun(prev_sampler, sampler), I think it is possible to consider to make it a bit more modular (in future PRs), e.g. by introducing an additional sampler-specific attribute:
gibbs_attribute (sampler) = one of a few possible attributes
gibbs_rerun(prev_sampler, sampler) = gibbs_rerun(gibbs_attribute (prev_sampler), gibbs_attribute (sampler))

Such designs allow us to reuse some gibbs_rerun definitions and potentially avoiding the need to gathering sampler specific implementation for Gibbs into a single file.

I reverted the gid related changes, these parts of the PR could go into a future PR if desired.
The more modular approach sounds very reasonable. Unfortunately, it seems it would still require to define dispatches for all existing attributes when an algorithm does not fit into any existing attribute categories and has to define its own new attribute. One could still group together e.g. MH, HMC, and NUTS it seems :slightly_smiling_face:

I reverted the gid related changes, these parts of the PR could go into a future PR if desired.
The more modular approach sounds very reasonable. Unfortunately, it seems it would still require to define dispatches for all existing attributes when an algorithm does not fit into any existing attribute categories and has to define its own new attribute. One could still group together e.g. MH, HMC, and NUTS it seems :slightly_smiling_face:

Tests on master, and in the same way in this PR, fail terribly currently :open_mouth: It seems not a single AdvancedHMC-related test passes and the logs (e.g. https://pipelines.actions.githubusercontent.com/N6hMANmENxs4asRtCYxRx2T5dwtGFqB7REAP98WHa7yPx1CJ2q/_apis/pipelines/1/runs/13034/signedlogcontent/4?urlExpires=2021-01-28T02%3A04%3A15.5098764Z&urlSigningMethod=HMACV1&urlSignature=vljLf7fo15GLGBuVX4H6SoFlm2E%2FpDlq8ilNYVpd%2BRQ%3D) contain just 6 hours of repeated warnings of AdvancedHMC about numerical errors and rejected proposals. I have no idea why this happens.

Tests on master, and in the same way in this PR, fail terribly currently :open_mouth: It seems not a single AdvancedHMC-related test passes and the logs (e.g. https://pipelines.actions.githubusercontent.com/N6hMANmENxs4asRtCYxRx2T5dwtGFqB7REAP98WHa7yPx1CJ2q/_apis/pipelines/1/runs/13034/signedlogcontent/4?urlExpires=2021-01-28T02%3A04%3A15.5098764Z&urlSigningMethod=HMACV1&urlSignature=vljLf7fo15GLGBuVX4H6SoFlm2E%2FpDlq8ilNYVpd%2BRQ%3D) contain just 6 hours of repeated warnings of AdvancedHMC about numerical errors and rejected proposals. I have no idea why this happens.

I'm running the tests locally ATM - will merge if it passes.

I'm running the tests locally ATM - will merge if it passes.

The test errors are real and consistent. You can already see them in the tests of the PRs that you just merged into the master branch.

The test errors are real and consistent. You can already see them in the tests of the PRs that you just merged into the master branch.

The test errors are real and consistent. You can already see them in the tests of the PRs that you just merged into the master branch.

It's a bit strange - I just checked AdvancedHMC, we don't have any new release since 2 Dec 2020.

The test errors are real and consistent. You can already see them in the tests of the PRs that you just merged into the master branch.

It's a bit strange - I just checked AdvancedHMC, we don't have any new release since 2 Dec 2020.

I wonder if it is related to the test errors that suddenly appeared in DistributionsAD. I still haven't figured out what package causes them. After hours of down- and upgrading packages I finally managed to reproduce the successful run in https://github.com/TuringLang/DistributionsAD.jl/runs/1659751199. But I still don't know what upstream change broke it.

I wonder if it is related to the test errors that suddenly appeared in DistributionsAD. I still haven't figured out what package causes them. After hours of down- and upgrading packages I finally managed to reproduce the successful run in https://github.com/TuringLang/DistributionsAD.jl/runs/1659751199. But I still don't know what upstream change broke it.

It seems all AD backends have test errors including ForwardDiff, Tracker and ReverseDiff, which hints the error might come from a shared dependency of all AD implementations.
Test Summary:                          | Pass  Error  Total
Turing                                 |    4     13     17
  core                                 |    4      1      5
    ad.jl                              |    4             4
  inference: forwarddiff               |           1      1
    samplers                           |           1      1
  variational algorithms : forwarddiff |           1      1
  modes                                |           1      1
  inference: tracker                   |           1      1
    samplers                           |           1      1
  variational algorithms : tracker     |           1      1
  modes                                |           1      1
  inference: reversediff               |           1      1
    samplers                           |           1      1
  variational algorithms : reversediff |           1      1
  modes                                |           1      1
  variational optimisers               |           1      1
  stdlib                               |           1      1
  utilities                            |           1      1
ERROR: LoadError: Some tests did not pass: 4 passed, 0 failed, 13 errored, 0 broken.

It seems all AD backends have test errors including ForwardDiff, Tracker and ReverseDiff, which hints the error might come from a shared dependency of all AD implementations.
Test Summary:                          | Pass  Error  Total
Turing                                 |    4     13     17
  core                                 |    4      1      5
    ad.jl                              |    4             4
  inference: forwarddiff               |           1      1
    samplers                           |           1      1
  variational algorithms : forwarddiff |           1      1
  modes                                |           1      1
  inference: tracker                   |           1      1
    samplers                           |           1      1
  variational algorithms : tracker     |           1      1
  modes                                |           1      1
  inference: reversediff               |           1      1
    samplers                           |           1      1
  variational algorithms : reversediff |           1      1
  modes                                |           1      1
  variational optimisers               |           1      1
  stdlib                               |           1      1
  utilities                            |           1      1
ERROR: LoadError: Some tests did not pass: 4 passed, 0 failed, 13 errored, 0 broken.

Yeah one of my hypotheses currently is that there's a problem with the latest ForwardDiff release (which is used e.g. by Tracker and Zygote for broadcasting) but I don't know why it would cause any problems... It's just that I don't have tried so many other things already.

Yeah one of my hypotheses currently is that there's a problem with the latest ForwardDiff release (which is used e.g. by Tracker and Zygote for broadcasting) but I don't know why it would cause any problems... It's just that I don't have tried so many other things already.

Hmm... But now I can reproduce the test failure also by just upgrading Distributions from 0.24.10 to 0.24.11...

Hmm... But now I can reproduce the test failure also by just upgrading Distributions from 0.24.10 to 0.24.11...

Hmm... But now I can reproduce the test failure also by just upgrading Distributions from 0.24.10 to 0.24.11...

It might make sense to add DistributionsAD as a downstream/reverse test for Distributions given how closely interconnected they are.

Hmm... But now I can reproduce the test failure also by just upgrading Distributions from 0.24.10 to 0.24.11...

It might make sense to add DistributionsAD as a downstream/reverse test for Distributions given how closely interconnected they are.

I am confused how the Dirichlet changes in Distributions can break DistributionsAD though since we should always use DistributionsAD.TuringDirichlet instead. Something seems wrong.

I am confused how the Dirichlet changes in Distributions can break DistributionsAD though since we should always use DistributionsAD.TuringDirichlet instead. Something seems wrong.

https://github.com/TuringLang/DistributionsAD.jl/pull/151

https://github.com/TuringLang/DistributionsAD.jl/pull/151

Excellent work, many thanks @devmotion!


change nest() to delay taking a hold on the async_scope until start

change nest() to return a sender that delays taking a hold on the async_scope until start()

Am I correct that in this design it's UB to call start() on the result of nest if the scope has gone away?

Am I correct that in this design it's UB to call start() on the result of nest if the scope has gone away?

Yes. Just like calls to spawn.. calls to nest()->connect()->start() must occur while the async_scope object is alive.

Yes, but connect()/start() is tightly coupled in library code for the most part. nest() is more likely to be used by the user. So it's a reference capturing operation that hides the reference capture. I liked the option to terminate. The silent reference capture bothers me more. Hopefully ASAN would catch errors consistently.

C++ has this problem in spades, and this is nothing new. Just consider iterators. I don't think the possibility of a dangling sender is a problem.


feat: update Referrers API for distribution-spec v1.1.0-rc3

Resolves: #443

Codecov Report

Merging #553 (103dd22) into main (9b52269) will increase coverage by 0.03%.
The diff coverage is 89.47%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main     #553      +/-   ##
==========================================
+ Coverage   73.85%   73.88%   +0.03%
==========================================
  Files          50       50
  Lines        4700     4706       +6
==========================================
+ Hits         3471     3477       +6
  Misses        902      902
  Partials      327      327

Impacted Files
Coverage Δ

registry/remote/repository.go
70.36% <88.88%> (+0.20%)
:arrow_up:

registry/remote/referrers.go
91.95% <100.00%> (-0.10%)
:arrow_down:


Fix swap table in bostrom

from 15515000 block swap event no more encoded in base64
add another view with no decoding from block 15515000

fill losted data


update ts-filler to support local chains for proof generation

🟡 Heimdall Review Status

Requirement
Status
More Info

Reviews

🟡
0/1

Denominator calculation

Show calculation

1 if user is bot
0

1 if user is external
0

From .codeflow.yml

1

Additional review requirements

Show calculation

Max
0

0

From CODEOWNERS

0

Global minimum
0

Max

1

1

1 if commit is unverified
0

Sum
1


When a React RouteNode should re-render?

Hello @troch!
I'm having a big doubt after a bug emerged in my react-mobx plugin.
My version of RouteNode is based on yours react-router5 version .
Now I've noticed that in your version whenever a route change happens all your RouteNodes will re-render.
This usually works when your component structure resemble exactly a single tree and of course the visual changes will only happen in the children branches of the intersection RouteNode (because of the switch or any other means to select the sub-components).
Nonetheless all RouteNodes are being re-rendered.
I think that this might be inefficient and I put in place a logic to re-render only the intersection node.  In this case when the component structure is a tree it works because all the subcomponent of the intersection are re-generated and so any RouteNode in this branch will be re-generated and will select the correct subcomponents even tough it's not the intersection (this is a render, not a re-render).
Now this logic turned to be buggy for some specific cases (example: app.a({id:1}).b -> app.a({id:2}).c) so I tough to add an extra condition:
Re-render a RouteNode only when:

it represents the intersection node
or the segment associated with RouteNode is one of the segments toActivate

I tough preventing re-rendering RouteNodes might be necessary when you have a lot of them and only few of them really need to. Or when your component structure is organized in multiple parallel trees for example.
What do you think?
But most important, am I overcomplicating this and I should just trust React and its internal algorithms?  😆

Right, sorry I did not look into the listenersPlugin and I wrongly assumed that each route node was listening to just any route changes.
I'm setting up an example with react-router5 to see if this also affect your package or not.

@troch take a look here: https://react-x2uirc.stackblitz.io/
I've setup the same example using react-router5.
The routes config:
export default [
  {
    name: 'app',
    path: '/',
    children: [
      {
        name: 'page',
        path: 'page/:id',
        children: [
          {
            name: 'article',
            path: '/article'
          },
          {
            name: 'info',
            path: '/info'
          }
        ]
      }
    ]
  }
];

If you try to navigate for example from app.page({id:1}).article to app.page({id:1}).info it works (I'm putting routesParams in parens for explanation only).
If you navigate from app.page({id:1}).article to app.page({id:2}).info it doesn't works.
By passing {reload:true} in route options seems to make things worse.
Now, I'm not sure if this is a misconfiguration, a limitation or a bug.

Can you share the code of your example?

Oops, I've shared only the view link, here's the edit version: https://stackblitz.com/edit/react-x2uirc/

Hello @troch have you had by chance the time to look into this ?

Any update on this @troch?
What can I do to help you on this? Was my example setup enough to let you understand the problem?

I guess that makes sense since when nesting routeNode HoCs, children route nodes of an updating route node don't get local state updates. I think I need to introduce a key in routeNode or other fix.

@troch I've found a possible fix for my plugin but I'm not sure if it break the original routeNode  responsibility.
Right now a routeNode should update when this condition is met (pseudo-code taken from mobx-plugin):
this.routerStore.intersectionNode === this.nodeName;

You do the same using your listener plugin.
A possible fix would be:
const isIntersection = this.routerStore.intersectionNode === this.nodeName;
const nodeToActivate = this.routerStore.toActivate.find((item, index, array) => {
  return item === this.nodeName
});
return isIntersection || nodeToActivate

That is a routeNode should update either when it is the intersection node or it is one of the node to activate.
What do you think?
If the logic is correct you could be apply it also on your side

That is a routeNode should update either when it is the intersection node or it is one of the node to activate.

I think I can refine it. It will reload if:

If it is the intersection node
Going from the intersection node to leaves, any activated node which has a matching deactivated node, until not (it makes sense in my head anyway).

OK, change is live:

<EMAIL_ADDRESS><EMAIL_ADDRESS>
Note that there is a breaking change in react-router5: listeners plugin is no longer needed, and that means upgrading to<EMAIL_ADDRESS>to use it

thanks @troch 👍
Apart from the shouldUpdateNode function that's gonna be very useful I've seen you now you use an observerPlugin instead of the listenerPlugin, any words on this, either here or in the docs somewhere?

The router has now a subscribe function, and is marked as an observable so it can be consumed easily in stream libraries (http://router5.github.io/docs/observability.html).
I've just released a patch to fix a couple of issues.


Allow path to be set for saving mp4s

[ ] Fix the filenames so they don't need to be json.mp4.gif

Fixed in MR #120


Display the date as "Oct 7 2023"

And please remove the time:

87ea4d8d5d442c5faca3728781f2a55b52548d19 should fix this. It uses Date.toLocaleString with options to show a short month and numeric year/day.
On my computer, this localizes to


Add quotes to variable

Q
A

Bug fix?
yes

New feature?
no

BC breaks?
no

Deprecations?
no

Tests pass?
n/a

Fixed tickets

License
MIT

Prevents the following if $EDITOR isn't set running bash.
Copying config.php.dist to config.php./bin/install: line 21: [: ==: unary operator expected

Thank you @GawainLynch


Project Board like Github or Trello

Example: https://github.com/NamelessMC/Nameless/projects/1

Duplicate of #3476 and PR at #8346


Kitchen Sink : Currency Converter

Describe the feature
This app will covert the currencies based on user input.
Also it will use a Basic custom hook to make the app..
can you please assign this to me , I am interested to contribute myself In hacktoberfest_23
Additional information

[X] Would you be willing to help implement this feature?

Hey there, somebody already did this @sushilmagare10.


Feature: support bar charts over times scales

Coming from #4498 I'm trying to build a combined line/bar time series chart. Approach is to use category axis for the bars.
https://github.com/chartjs/Chart.js/issues/4635, https://github.com/chartjs/Chart.js/issues/2892 and the fact that the category axis doesn't support sparse datasets (e.g. bars with missing days) makes this approach complex. Category axes appear to have a very limited use for more complex charts.
Line charts are already possible over category and time scales. Opposed to that, bar charts are only possible over category but not over time scales.
To simplify building a combined line/bar time series chart it would be nice if bar charts were possible over time scales.

Some of the work with the new time options such as http://www.chartjs.org/docs/master/axes/cartesian/time.html#scale-distribution should help. #4545 has improvements as well

Closing right again. For my purpose #4545 takes care of it all.


redo rancher.environment to globally set shell ENV

follow-on for #1435.

[ ] caching of immutable values like KERNEL_VERSION
[ ] export rancher.env values to all engines and services - so we are able to get HTTP_PROXY working globally (think about certs)
[ ] docs.

Do you mean rancher.env in addition to rancher.environment? Or were you just shortening it?

yes, just lazy typing, sorry.


Make NameInterpreters configurable for each router

Each router should have its own dtab/name interpretation context.  In order to accommodate this, this change does the following:

Remove the NamingFactoryConfig types introduced in https://github.com/BuoyantIO/linkerd/pull/141.  The namers block now only loads Namer configurations.
Each router now has an optional interpreter configuration, backed by the InterpreterInitializer module type.  Interpreters are built against the list of process-wide namers.  A default configuration is used if none is specified, which performs local name resolution.  This change will allow other (e.g. remote) interpreter contexts to be introduced on a per-router basis.
Furthermore, module kinds had to be globally unique.  This is problematic if we want to use a value like default for an interpreter kind as it would require that no other module types have a default kind.  This change detects conflicts within a module type, but not across module types.

:star: I dig this ⛏

:star: looks good; needs a rebase of course.

looks good, but I don't actually see the interpreter config section tested anywhere?
Also I see the default interpreterinitializer defined, but that's it. is the plan to not open source the others until later?

other implementations don't really exist in the yet (i've got a branch cobbled together for demo purposes, but nothing ready to share). i expect that these implementations will land in this repo in the next ~month.

status: i've rebased this down to 2 primary commits. it still needs some docs improvements and better testing.  If someone feels like picking this up and taking it over the line... by all means, please do.  Otherwise I'll get to this as time permits.

I added some additional tests, etc. Looks like the branch has merge conflicts, so I'll deal with those now.

fixed merge conflicts - there were a bunch of changes conflicting  with @adleong's recent configuration branch, so I'd especially like him to look at this to ensure I resolved them in reasonable fashion.

LGTM

:star: Looks good to me.


Add entity scoreboard tag property

Entities have access to scoreboard tags, essentially string data attached to them that can interact with scoreboards and command blocks. Looks like the spigot Entity class has easy access to getting/setting these values, so would be nice to have in Denizen too.
Example w/ vanilla commands of setting/viewing tags:

Added basically as requested, property of scoreboard_tags with matching tag+mech names, also clear_scoreboard_tags convenience mech.


SRVKP-4524: add metrics/labels for results alerts/panels

rh-pre-commit.version: 2.3.1
rh-pre-commit.check-secrets: ENABLED

/assign @amisstea

@divyansh42 - per our conversation earlier today, you'll probably need to make a similar change for the PAC alerts/panels


[winpr,sysinfo] unify time function use

Add new function winpr_GetTickCount64NS for high resolution tick count with (up to) nanosecond resolution
Add new function winpr_GetUnixTimeNS for high resolution system time as nanoseconds since 1.1.1970
Replace use of clock_gettime and gettimeofday in whole project with these new functions

@freerdp-bot test again please


support http+ts ? and support codec?

**需求描述
support http+ts  content
support hls+ts content
support codec

support video formate depends on the video engine.


Update to ramsey MN json

New official source from the county, with new, more comprehensive field mappings.

Thanks!


Line wrapping in the output log

In my GHA workflow I'm observing lines being wrapped at 80chars in the Adding files for ... section:

It doesn't appear to be happening elsewhere - just that section.
I think it makes the logs harder to read/parse so would prefer the lines to not be wrapped.

Seems like the issue must be here:
https://github.com/mamba-org/boa/blob/b8fbbdf11118da414c56413879e5397c13daeaa2/boa/core/build.py#L250-L258
...but nothing stands out there.

The console is defined at:
https://github.com/mamba-org/boa/blob/b8fbbdf11118da414c56413879e5397c13daeaa2/boa/core/build.py#L74
Which looks like it comes from :
https://github.com/mamba-org/boa/blob/b8fbbdf11118da414c56413879e5397c13daeaa2/boa/core/config.py#L9-L26

Maybe need to enable soft wrapping for the console?
https://rich.readthedocs.io/en/stable/console.html#soft-wrapping

...though I don't quite understand what "run on to the following lines" means there 🤔
Anyway, I can try to test out this theory...

Thanks for the note! @derthorsten is also looking into the excessive amount of traceback, maybe we can put in a fix for this at the same time.


Can't use toast with context inside the State class of a StatefulWidget with animations

Hello!
I'm trying to use the toast inside a State class of a StatefulWidget that's implementing the TickerProviderStateMixin to run some animations. This are my classes:
class MixDeckView extends StatefulWidget {...}
class _MixDeckView extends State<MixDeckView> with TickerProviderStateMixin{ ... }
I've followed all the steps to show the Toast with context, but I'm receiving the following error:
....setState() or markNeedsBuild() called during build....
The curious thing is that the Toast is actually displayed on the screen correctly, but the animations (which are the main part of the widget) are not. So I have a big red screen filling the entire height, with the error message, and on top, the Toasts are showing normally.
My conclusion is that the animations and the Toast with context are NOT compatible....I'm not sure this is a bug, but just wanted to let u guys know my experience...probably the author can give a solution too in the future for people trying to do the same...
Blessings!
PD: I'm switching the Toast for SnackBars as a workaround (they work with no problem using the ScaffoldMessenger).

My apologies! Looking into it, I just can't send any message (toast or snack bar or whatever) if the tree is building...I'm closing the issue.
The correct approach is to wait until the tree is built to launch any message (I'm using the listener of the BlocConsumer, if anyone is wondering...take a look at the flutter bloc package).


Visualizing input_velodyne.py output ?

Hello, I re implemented input_velodyne.py, but I don't know what to expect as output or how to visualize it (because im using it to voxelize the poind cloud data and try to see the result without ROS)
Can anyone be can enough to shed some light on this issue of mine?
Much appreciated!

Hello,
this is how i managed to visualize the output
    fig = mayavi.mlab.figure(bgcolor=(0, 0, 0), size=(1500,1000))     col = pc[:,2]     mayavi.mlab.points3d(-pc[:,0],pc[:,1],pc[:,2],col,mode='point',colormap='spectral',scale_factor=5,figure=fig)     mayavi.mlab.points3d(-bbox[:,0],bbox[:,1],bbox[:,2],mode='2dsquare' ,colormap='terrain',scale_factor=5,figure=fig)     mayavi.mlab.show()


Support rustc_codegen_cranelift

It would be nice if cargo-show-asm supported rustc_codegen_cranelift. It would be useful for comparing the output of Cranelift and LLVM.
In order to make rustc use Cranelift, I have installed it following these instructions: https://github.com/rust-lang/rustc_codegen_cranelift
My project's Cargo.toml looks like this:
# This line needs to come before anything else in Cargo.toml
cargo-features = ["codegen-backend"]

[package]
name = "quick_test"
version = "0.1.0"
edition = "2021"

[profile.release]
codegen-backend = "cranelift"

The output I get when running cargo asm is:
error: Unknown option `-x86-asm-syntax`

error: could not compile `quick_test` (bin "quick_test") due to 1 previous error

Cargo failed with exit status: 101

By default cargo-show-asm doesn't perform disassembly, but asks rustc to produce raw asm files, parses them and makes them accessible for users. Problem with cranelift backend is that it doesn't support emitting asm files.
But if you compile cargo-show-asm with "disasm" feature you can pass --disasm option along with usual flags. This should, in theory, support cranelift as well.


Missing constants for nc_def_var_szip

The current online documentation for nc_def_var_szip mentions two constants, NC_SZIP_EC and NC_SZIP_NN. However, these constants are not defined in the public header files of netcdf-4.7.4 or the current master (1d2fca9813a). The builtin tests for netcdf are not detecting the problem because the constants are defined in nc_test4/tst_vars3.c .

Thanks @mjwoods I'll get this fixed.

These are defined in include/netcdf_filter.h, but have different names, probably
the names defined by hdf5 headers.

I believe that in the case of szip, they should be defined in netcdf.h, just as the zlib constants are.
Alternatively, can we include netcdf_filters.h in netcdf.h?

I have left the deflate constants in netcdf.h because it is always there when netcdf-4
is enabled. Szip is optional, so I am not sure that it should be in netcdf.h.
As for including netcdf_filters.h in netcdf.h, we have had this conversation
before with no agreement, so I am willing to have it again.
My argument is that the user includes netcdf.h and then includes secondary netcdf_xxx.h
headers for those features used by the client code. So the same argument applies, for me,
with respect to netcdf_parallel.h.
Anyone else have an opinion?

One difference with netcdf_parallel.h, and the reason it is in a separate file, is that it includes mpi.h, which will not be present for sequential builds.
Anyway, let's leave it as it is for the 4.9.0 release, and worry about it next time around. ;-)
For most of my NOAA users, it doesn't matter - they do everything in Fortran and never do anything in C. So netcdf-fortran will have to have an extra include, and that is no problem whatsoever. So for most users, this is a non-issue.
I will change my szip constants to match the netcdf_filter definitions, in the test code and in the documentation. This will be the fastest path forward for the next release...


Modify the column names within the aggrid and not outside in the testset view

Is your feature request related to a problem? Please describe.
Currently, if you want to change the column names in the test set view, you need to do it outside the table

Describe the solution you'd like
We would like to integrate the editing inside the table, basically you select the column names and you can change them, and then you have a + sign at the end of the header that you can use to add a column and another one to remove columns.
Additional context
This is quite challenging to do. Only for the brave of you:)

@mmabrouk i am not sure what you mean you want to be able to add a new column completely or just edit and existing columns name?

I mean:

Add a new column by having a + sign at the end of the header
Rename the columns by editing their name
Removing columns by clicking on the bin in the header

You can assign this to me

Done! Good luck!
FYI @aakrem @MohammedMaaz

@MohammedMaaz how would removing of columns work if we do it outside the the table.

I can work on the UI just want to be completely right with implementation.

@mmabrouk help needed.

Hey @witehound, @MohammedMaaz told me he'd be unavailable this weekend. He will answer you tomorrow with the tech details.

but not sure I understand your question, why would we need to remove the columns outside the table. The screenshot you give shows the delete button in the table header

I mean:

Add a new column by having a + sign at the end of the header
Rename the columns by editing their name
Removing columns by clicking on the bin in the header

@mmabrouk so I’m still working on the ui, as the core part was getting it to work, I think I misunderstood what header meant but it’s clearer now. Thank you.


Also exclude eclipse launch configurations.

...Since I have contribute perms github didn't ask me to add this to a fork when I committed - woops.


Make CI jobs for Swift 4.2 & Ubuntu 18.04

this is for the CI jobs in Jenkins, the work to support Swift 4.2 & Ubuntu 18.04 in docker is in #604.
In total I think we need the following new CI jobs (ordered by how important @weissi thinks they are):

[x] Swift 4.2 on Ubuntu 18.04
[ ] Swift 4.2 on Ubuntu 16.04
[ ] Swift 4.2 on Ubuntu 14.04

note: there are no Swift 4.0 or 4.1 binaries available for Ubuntu 18.04, hence we won't have Swift 4.0 or 4.1 on Ubuntu 18.04
CC @tomerd who holds the CI 🔐

added PRB for Swift 4.2 on Ubuntu 18.04
we can add the others as nightly if we think its required

thanks @tomerd


docs: Update create-fuels dApp to be denominated in Gwei

Right now the example create fuels dApp is denominated in the base asset denomination of the devnet, this creates friction in the UX because users have to add what may seem like an exorbitant amount to conduct basic transactions

Do you think we might wanna use ETH instead of gwei instead?


Recreating a deleted k8s_credentials resources leads to a 404

We are using the k8s_credentials resource to add our EKS clusters to dynatrace.
When deleting the kubernetes connection outside of terraform, terraform is not able to run through until you recreate it manually.
module.somemodule.kubernetes_service_account.dynatrace_kubernetes_monitoring: Refreshing state... [id=default/dynatrace-kubernetes-monitoring]
This is the output I get from terraform plan
│ Error: {
│   "code": 404,
│   "message": "Configuration 'KUBERNETES_CLUSTER+SOMEID' not found.",
│   "constraintViolations": null
│ }
│
│

This is the terraform configuration in question:
resource "dynatrace_k8s_credentials" "this" {
  label                               = var.cluster_name
  active                              = true
  auth_token                          = "sometoken"
  events_integration_enabled          = true
  davis_events_integration_enabled    = true
  certificate_check_enabled           = false
  endpoint_url                        = "someendpoint"
  event_analysis_and_alerting_enabled = true
  prometheus_exporters                = true
  workload_integration_enabled        = true
  events_field_selectors {
    active         = true
    field_selector = "involvedObject.kind=Node"
    label          = "Node events"
  }
  events_field_selectors {
    active         = true
    field_selector = "involvedObject.kind=Pod,type=Warning"
    label          = "Pod warning Events"
  }
}

I would expect the terraform module to try to recreate the connection in case it was removed outside of terraform

Hello @franznemeth
Configurations running out of sync because of changes outside of Terraform are a known obstacle. Taking care of them is unfortunately not always that simple.
In this case, trying to recreate the configuration would essentially result in Dynatrace creating a new ID for the resource - and at the same time the ID of the resource in your state file remains the same.
I will keep this issue open - perhaps there is a way to circumvent it, but a fix for that won't be easy.

Hello @franznemeth ,
The issue you've described has been taken care of with release v1.18.1. Any configuration that got deleted outside of Terraform is now getting recreated.


dart2js should include the verison number in the compiled code

It would be useful if dart2js included the version of the compiler as a comment in the generated code. For example, see dartbug.com/19651 where there's a regression, but can't tell what version the regression is from after upgrading the SDK, because the previously compiled code doesn't indicate it.

It does now


Defined moods on all tracks

Currently defined three different moods:

lonely
romancing
lovemaking

Also removed a few way too uptempo tracks and adjusted track names to avoid including "remasterd version", "radio edit", etc.

Boooooh!!!! where is erotic?

lovemaking

Oooh dear Rick so young so naive, I understand two complete different things between lovemaking and erotic.
Lovemaking is more sensual and might even come close to romantic...

Erotic and lovemaking is the same thing IMO. Seems like you're expecting a genre that's more related to porn. Schuifel Shuffle is meant to be romantic, so i'll stick to lovemaking here ;).

I have a few additional mood suggestions:

dramatic
tragic
hurt
sparkly
lovey-dovey
abandoned
cheerful
desperate

What do you think?