Fix fonts in header

Align fonts of every menu item in header according to designs.
Remove capitalizing on user name and display it as it is

Usernames' and providers' styles in header have been fixed according by mockup.


Include file output using local registry

The FileOutput class export the tag.gz file.
It uses local registry to pick some important information from the package.
The test generates the file and makes sure it exists.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: abeandre sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

@dotnet-policy-service agree company="Microsoft"

@dotnet-policy-service agree company="Microsoft"

As discussed offline, we're going to close this in favor of #375. Thank you for the contribution, @abeandre!


Work on enabling GC on Windows

@smosier PTLA
@MichalStrehovsky Everything should be prepared for GC to light up once we start emitting EEType GCDescs

LGTM


When deploying jar to remote repository, file not found.

This seems to be an issue when deploying jar artifacts to a remote repository.  Using maven-deploy-plugin (deploy:deploy), this does not provide any context during mvn lifecycle in order to find artifacts.  This results in an error...
The packaging for this project did not assign a file to the build artifact.
Running just 'deploy' works, but this executes the entire lifecycle which would defeat the purpose of a build promotion.  Need a way to provide back to the process the location for last build artifacts in the workspace or local file system.

Hi Stephen. The promote:artifacts goal is supposed to handle this for you. Have you tried promote:artifacts deploy:deploy?
If that does not help, what does your config look like?

Thanks for the help and the plugin, I was missing this goal.

I was getting a similar error, and "No file registered for artifact: com.test:my-project:jar:1.1-SNAPSHOT".
It took me a few hours to make it work.  To save others the same pain, here's what I did:
In my pom.xml, note maven-release-plugin's completionGoals:

org.apache.maven.plugins
maven-release-plugin
2.5.3

promote:artifacts jar:jar deploy:deploy

Then I executed the following steps:

mvn clean install
mvn promote:make-promotable
mvn release:clean promote:prepare release:prepare


A mistake in Concept01 in Chapter04

I am reading TensorFlow-Book/ch04_classification/Concept01_linear_regression_classification.ipynb , I find a mistake.
In your description

Let's say we have numbers that we want to classify. They'll just be 1-dimensional values. Numbers close to 2 will be given the label [0], and numbers close to 5 will be given the label [1], as designed here:

but in your code,
x_label0 = np.random.normal(5, 1, 10)
x_label1 = np.random.normal(2, 1, 10)
print x_label0
print x_label1
xs = np.append(x_label0, x_label1)
labels = [0.] * len(x_label0) + [1.] * len(x_label1)

we can find you give Numbers close to 2 is label [1], and numbers close to 5 is label [0].
Maybe you need fix this mistake.

Thank you! Fixed! 4f96d49


Support for H601C

Would like to add support for H601C. Can you point me in the right direction?

Best you can do is to try find similar device, released around similar date and try using that device profile.
It looks like, the owner of this project will not add any other light support (see #43).

I can't find the data we need from govee API. It makes me think that the model .JSON files are pulled directly from the device using UART or something.
All we need are some hints to get that data and we're golden.


Mark as read when clicking on number of unread articles

Hey Veit, awesome theme! Not really an issue but some kind of a feature request: Feedly marks all articles automatically as read when you click on that little number next to the feed name. You know, the number which indicates the total amount of unread articles within that feed (see the attached image).
Do you plan to implement this feature? Would be nice to mark all articles as read this way :-)

I may be mistaken, but I believe this is beyond the scope of a theme to implement. You'd probably have to submit a feature request to the tiny-tiny-rss team (https://tt-rss.org/gitlab/fox/tt-rss/issues).

Hi @phars, @ardichoke is right, this is not possible with a theme since it's a functionality change, sorry.


:bug: test/e2e/framework: Don't try to pull logs from a non-ready POD

Summary
Fixes some flaky tests due to the syncer-dns pod not being in "running" state (synctarget heartbeat is sent by the syncer pod, and doesn't take into account the syncer-dns POD state.)
This is causing some e2e-shared tests to fail, due to the collecting of logs failing as the syncer-dns pod is not ready.
related to: https://github.com/kcp-dev/kcp/issues/2284

If the pod has stopped, etc, we can get the previous logs from it - can we add that as well?

If the pod has stopped, etc, we can get the previous logs from it - can we add that as well?

done! ptal.

Not sure what went wrong here:
WARN[2022-11-01T12:45:25Z] Unable to retrieve logs from failed build     error=build src is in an error state. No logs are available.
[10](https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/kcp-dev_kcp/2283/pull-ci-kcp-dev-kcp-main-e2e-sharded/1587424934290788354#1:build-log.txt%3A10)
INFO[2022-[11](https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/kcp-dev_kcp/2283/pull-ci-kcp-dev-kcp-main-e2e-sharded/1587424934290788354#1:build-log.txt%3A11)-01T12:45:25Z] Ran for 2m20s
11
ERRO[2022-11-01T[12](https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/kcp-dev_kcp/2283/pull-ci-kcp-dev-kcp-main-e2e-sharded/1587424934290788354#1:build-log.txt%3A12):45:25Z] Some steps failed:
12
ERRO[2022-11-01T12:45:25Z]
[13](https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/kcp-dev_kcp/2283/pull-ci-kcp-dev-kcp-main-e2e-sharded/1587424934290788354#1:build-log.txt%3A13)
  * could not run steps: step src failed: could not get build src: builds.build.openshift.io "src" not found

/retest


Add Q-Values to Precursor Results Summary.

Nick, do you know if there are unit tests for the existing Precursor Results Summary values that I can use as an example or possibly just add q-value there?


add django 3.2 support

fixes #628
add django 3.2 support

@haxoza could you please take a look on my PR

Thanks for merging this, @dekoza 🙏
Is there a plan to release a new version, if only for the dependency changes?

@allanlewis yes, I'll make a release this week after I merge most of the PRs. Thanks for your work and patience :slightly_smiling_face:

@dekoza could you please add a new version tag release for it?

@dekoza is that released ?


TinyUSB print to console

Is there a function that does the same like printf() in the TinyUSB library? I would use printf() but i need my code to run as fast as possible so i am looking for an alternative to write 16Bit Hex Values to e.g. COM19, where my Raspberry Pico is connected, on my PC. I want to see the values in Putty to confirm they´re correct.
I tried write() but that prints the value in 8Bit ASCII with Endians mixed up. So 0x2F3D becomes 0x3D 0x2F.
I got the TinyUSB library suggested, but couldn´t really figure out how to use it properly. Is there a documentation other than the one on git and on their website?

This sounds like a question for the forums https://forums.raspberrypi.com/viewforum.php?f=143

I tried write() but that prints the value in 8Bit ASCII with Endians mixed up. So 0x2F3D becomes 0x3D 0x2F.

Did you try either
write((your_var >> 8) & 0xff);
write(your_var & 0xff);

or
write(your_var & 0xff);
write((your_var >> 8) & 0xff);

?
Alternatively it shouldn't be hard to write your own function to format 16-bit integers as ASCII hex values. (I did something similar before to format 32-bit integers as ASCII hex values)

Thanks @lurch. There is not enough time to use write() twice. Whats interesting is, that as long i don´t open the COM19 in Putty the runtime of my function is about 2us, but when putty is connected and shows the values, the runtime shoots up to 4us. Probably makes sense because of the USB protocoll or sth like that?
I could convert it to ASCII, that would fix the Endian problem, but e.g. 0x2f3D would still print to 0x2f 0x3D on the output, if I would use write(). Gonna ask in the forum for sure.


Task :app:transformDexArchiveWithExternalLibsDexMergerForDebug FAILED

D8: Program type already present: android.support.design.widget.CoordinatorLayout$1
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':app:transformDexArchiveWithExternalLibsDexMergerForDebug'.

i get same issue

how to solve this?

Add support:design dependency on your android/app/build.gradle
dependencies {
    implementation fileTree(dir: "libs", include: ["*.jar"])
    implementation "com.android.support:appcompat-v7:${rootProject.ext.supportLibVersion}"
+   implementation "com.android.support:design:${rootProject.ext.supportLibVersion}"
    implementation "com.facebook.react:react-native:+"  // From node_modules
    implementation project(':react-native-bottom-sheet-behavior')
}


[BetterPickers] Update BetterPickers to NuGet

Added NuGet, licensing and improved the project files.

@bholmes Thanks for the fixes.


Chore import web punks projects from gitlab

Closing this pull request, as I wanted to add it to a forked repo. I am sorry.

No problem. I am a bit disappointed that you replaced the video codec with a server-side solution that produces patent-encumbered mp4. But I'm glad you're putting this to good use, best of luck!


Use gate label in label of gate's inverse

Summary
Label of the inverse of a gate is now label+'_dg'
Details and comments
The inverse of a gate obtained by gate.inverse() did not reflect the label of the parent gate, and instead used the 'name' attribute of the gate as its label. Now the inverse of a gate will carry the label of its parent followed by '_dg'.
Previous:

Updated:

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

I'm not sure if this is a practical issue or not, but this won't work if you swap the to_gate for a to_instruction. If you replace the to_gate in your circuit with to_instruction, you will not be able to add a label since Instruction does not have a label attribute. Even though the method you are modifying is in Instruction, the self in the self.label you added comes from the Gate. If you switch to to_instruction, you get an AttributeError.
Possible solutions,

Probably the easiest is to test if self has a label and if not set label to None.

if getattr(self, 'label', None) is None:
    label = None
else:
    label = self.label + '_dg'

above the Gate call, and then label=label in the Gate call.

Could add label to Instruction
Could add inverse() function to Gate

Not sure what issues might come up with the last two, though I can't personally see why a label on Instruction would be a problem.

Thank you for your suggestions @enavarro51. I did have the last two options in mind. Will be sure to try the first one as well.


No results.csv or .pkl files?

Hi, for some reason I'm not getting any results.csv file or .pkl file. The data folders created, and ALE and RL-Glue seem to be starting? Its a fresh build with ALE from Git.
I had to change one line in ale_run.py as ale was not found,
#p2 = subprocess.Popen('ale -game_controller rlglue -frame_skip 4 '+ ROM_PATH, shell=True, env=my_env)
p2 = subprocess.Popen('/home/ajay/ale/ale -game_controller rlglue -frame_skip 4 '+ ROM_PATH, shell=True, env=my_env)

Here's the output
/usr/bin/python2.7 /home/ajay/PythonProjects/deep_q_rl/ale_run.py
RL-Glue Version 3.04, Build 909
A.L.E: Arcade Learning Environment (version 0.4.4)
[Powered by Stella]
Use -help for help screen.
Warning: couldn't load settings file: ./stellarc
Game console created:
  ROM file:  /home/ajay/ale/roms/breakout.bin
  Cart Name: Breakout - Breakaway IV (1978) (Atari)
  Cart MD5:  f34f08e5eb96e500e851a80be3277a56
  Display Format:  AUTO-DETECT ==> NTSC
  ROM Size:        2048
  Bankswitch Type: AUTO-DETECT ==> 2K

Running ROM file...
Random Seed: Time
Game will be controlled through RL-Glue.
RL-Glue Python Experiment Codec Version: 2.02 (Build 738)
	Connecting to <IP_ADDRESS> on port 4096...
Initializing ALE RL-Glue ...
Using gpu device 0: GeForce GTX 570
RL-Glue Python Agent Codec Version: 2.02 (Build 738)
	Connecting to <IP_ADDRESS> on port 4096...
	 Agent Codec Connected
(32, 4, 80, 80)
(4, 80, 80, 32)
(16, 19.0, 19.0, 32)
(32, 9.0, 9.0, 32)
(32, 32, 9.0, 9.0)
(32, 256)
(32, 18)
Traceback (most recent call last):
  File "./rl_glue_ale_agent.py", line 427, in <module>
    main()
  File "./rl_glue_ale_agent.py", line 423, in main
    AgentLoader.loadAgent(NeuralAgent())
  File "/usr/local/lib/python2.7/dist-packages/rlglue/agent/AgentLoader.py", line 58, in loadAgent
    client.runAgentEventLoop()
  File "/usr/local/lib/python2.7/dist-packages/rlglue/agent/ClientAgent.py", line 144, in runAgentEventLoop
    switch[agentState](self)
  File "/usr/local/lib/python2.7/dist-packages/rlglue/agent/ClientAgent.py", line 137, in <lambda>
    Network.kAgentInit: lambda self: self.onAgentInit(),
  File "/usr/local/lib/python2.7/dist-packages/rlglue/agent/ClientAgent.py", line 43, in onAgentInit
    self.agent.agent_init(taskSpec)
  File "./rl_glue_ale_agent.py", line 155, in agent_init
    self.network = self._init_network()
  File "./rl_glue_ale_agent.py", line 189, in _init_network
    approximator='cuda_conv')
  File "/home/ajay/PythonProjects/deep_q_rl/cnn_q_learner.py", line 168, in __init__
    target = theano.gradient.consider_constant(target)
AttributeError: 'module' object has no attribute 'consider_constant'
training epoch:  1 steps_left:  50000
Segmentation fault (core dumped)
training epoch:  1 steps_left:  49995
training epoch:  1 steps_left:  49993

Just in case it helps, here's my PYTHONPATH from .bashrc
PYTHONPATH="/home/ajay/pylearn2:/home/ajay/pylearn2/pylearn2/scripts:/home/ajay/ale:$PYTHONPATH"
export PYTHONPATH

Thanks a lot  :+1:  Happy New Year :+1:

You most likely are using an old version of Theano. The git log says consider_constant got moved to the gradient module in March this year. git pull and install should fix that issue

Thank you :+1:  That was the problem, and the fix! Pulled from git and used develop instead of install,
sudo python setup.py develop
Also had a problem with CUDA, cublas, but that was fixed with
sudo ldconfig /usr/local/cuda-6.5/lib64
Guess the points learn are

always get the bleeding edge from Git and setup as a developer. pip does'nt seem to be the best way to do things?

look at the Git logs to see if your error has a fix?


Specify that MSBuild v14 use CoreClr RC1 for build

The forces AppVeyor MSBuild to use CoreClr x64 RC1 when building ImageProcessor.sln

Moar stuff? How did you figure this one out?

Although it's not strictly necessary, on OSX it was building with CoreClr x64 so I wanted to ensure it was doing the same on AppVeyor on Windows. Did some digging on the MSBuild GitHub repo https://github.com/microsoft/msbuild They are currently porting all of MSBuild to CoreClr, wow!

Amazing!


Confidence intervals on kernel hyperparameters

Is there a straightforward way to determine confidence intervals on the kernel hyperparameter values calculated by the optimizer?

Not currently implanted. But there a few thoughts. Including estimating the
Hessian or ideas from INLA.
@alansaul did you have any thoughts on implementation of some of Aki's
GPstuff ideas in this domain?
On 4 Feb 2016 06:25, "Matthew Graham"<EMAIL_ADDRESS>wrote:

Is there a straightforward way to determine confidence intervals on the
kernel hyperparameter values calculated by the optimizer?
—
Reply to this email directly or view it on GitHub
https://github.com/SheffieldML/GPy/issues/297.


[Bug]:  Chromium fails to tile completely

Before you make the issue, confirm that

[X] You are running the master build from GitHub actions
[X] You have read the FAQ and the usage instructions
[X] You have searched pull requests and issues and have found none similar to your issue
[X] This problem comes from a failure in the tiling system and not a missing feature

Describe the bug
When starting chromium the default window decorations appear and it doesn't tile at all, appearing in front of all other tiled windows
To reproduce
Start Chromium
See bug
Expected behavior
The window tiles properly
Log output
abr 18 19:28:00 kheprix kwin_wayland[7091]: qml: Polonium INF: Polonium started!
abr 18 19:28:00 kheprix kwin_wayland[7091]: qml: Polonium DBG: Config is {"debug":true,"tilePopups":false,"filterProcess":["krunner","yakuake","kded","polkit","plasmashell"],"filterCaption":[""],"timerDelay":10,"keepTiledBelow":true,"borders":1,"maximizeSingle":false,"resizeAmount":10,"saveOnTileEdit":false,"engineType":0,"insertionPoint":0,"rotateLayout":false}
abr 18 19:28:00 kheprix kwin_wayland[7091]: file:///home/theredcyclops/.local/share/kwin/scripts/polonium/contents/ui/osd.qml:42: TypeError: Cannot read property 'gridUnit' of undefined
abr 18 19:28:00 kheprix kwin_wayland[7091]: file:///home/theredcyclops/.local/share/kwin/scripts/polonium/contents/ui/osd.qml:41: TypeError: Cannot read property 'gridUnit' of undefined
abr 18 19:28:00 kheprix kwin_wayland[7091]: qml: Polonium DBG: Restarting init timer
abr 18 19:28:00 kheprix kwin_wayland[7091]: qml: Polonium DBG: Restarting init timer
abr 18 19:28:00 kheprix kwin_wayland[7091]: qml: Polonium DBG: Restarting init timer
abr 18 19:28:00 kheprix kwin_wayland[7091]: qml: Polonium DBG: Restarting init timer
abr 18 19:28:00 kheprix kwin_wayland[7091]: qml: Polonium DBG: Restarting init timer
abr 18 19:28:00 kheprix kwin_wayland[7091]: qml: Polonium DBG: Restarting init timer
abr 18 19:28:00 kheprix kwin_wayland[7091]: qml: Polonium DBG: Restarting init timer
abr 18 19:28:00 kheprix kwin_wayland[7091]: qml: Polonium DBG: Restarting init timer
abr 18 19:28:00 kheprix kwin_wayland[7091]: qml: Polonium DBG: Restarting init timer
abr 18 19:28:00 kheprix kwin_wayland[7091]: qml: Polonium DBG: Restarting init timer
abr 18 19:28:00 kheprix kwin_wayland[7091]: qml: Polonium DBG: Restarting init timer
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"32b80466-462e-4063-9a42-0fae92203c45","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"DP-3"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"856c8132-010d-4415-880e-683941e850a0","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"DP-3"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"35ebfc20-915f-4504-b150-02c008051262","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"DP-3"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"a9b3547d-75d2-46b4-896c-63ab521a87cc","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"DP-3"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"86adb02e-a4fa-4da4-837c-570ad420df45","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"DP-3"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"91c7fa13-a964-4162-952a-3565f5c1cc6d","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"DP-3"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"f76f613b-4ac8-406a-ab1a-23b36984dc49","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"DP-3"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"c621594d-0585-449d-869e-cd140a1bfa3d","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"DP-3"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"2ed8f66c-e8d6-4676-b168-bed3afaefdf9","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"DP-3"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"48094f4b-d665-496c-bebe-94767abf87e7","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"DP-3"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"32b80466-462e-4063-9a42-0fae92203c45","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"HDMI-A-1"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"856c8132-010d-4415-880e-683941e850a0","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"HDMI-A-1"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"35ebfc20-915f-4504-b150-02c008051262","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"HDMI-A-1"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"a9b3547d-75d2-46b4-896c-63ab521a87cc","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"HDMI-A-1"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"86adb02e-a4fa-4da4-837c-570ad420df45","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"HDMI-A-1"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"91c7fa13-a964-4162-952a-3565f5c1cc6d","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"HDMI-A-1"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"f76f613b-4ac8-406a-ab1a-23b36984dc49","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"HDMI-A-1"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"c621594d-0585-449d-869e-cd140a1bfa3d","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"HDMI-A-1"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"2ed8f66c-e8d6-4676-b168-bed3afaefdf9","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"HDMI-A-1"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Creating new engine for desktop {"desktop":"48094f4b-d665-496c-bebe-94767abf87e7","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"HDMI-A-1"}
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Window plasmashell hooked into script
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Not tiling window plasmashell
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Window plasmashell hooked into script
abr 18 19:28:01 kheprix kwin_wayland[7091]: qml: Polonium DBG: Not tiling window plasmashell
abr 18 19:28:02 kheprix kwin_wayland[7091]: qml: Polonium DBG: Window plasmashell hooked into script
abr 18 19:28:02 kheprix kwin_wayland[7091]: qml: Polonium DBG: Not tiling window plasmashell
abr 18 19:28:02 kheprix kwin_wayland[7091]: qml: Polonium DBG: Window plasmashell hooked into script
abr 18 19:28:02 kheprix kwin_wayland[7091]: qml: Polonium DBG: Not tiling window plasmashell
abr 18 19:28:03 kheprix kwin_wayland[7091]: qml: Polonium DBG: Window ksplashqml removed
abr 18 19:28:03 kheprix kwin_wayland[7091]: qml: Polonium DBG: Removing window ksplashqml from desktops
abr 18 19:28:03 kheprix kwin_wayland[7091]: qml: Polonium DBG: Rebuilding layout for desktops {"desktop":"32b80466-462e-4063-9a42-0fae92203c45","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"DP-3"},{"desktop":"32b80466-462e-4063-9a42-0fae92203c45","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"HDMI-A-1"}
abr 18 19:28:03 kheprix kwin_wayland[7091]: qml: Polonium DBG: Window ksplashqml removed
abr 18 19:28:03 kheprix kwin_wayland[7091]: qml: Polonium DBG: Removing window ksplashqml from desktops
abr 18 19:28:03 kheprix kwin_wayland[7091]: qml: Polonium DBG: Rebuilding layout for desktops {"desktop":"32b80466-462e-4063-9a42-0fae92203c45","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"DP-3"},{"desktop":"32b80466-462e-4063-9a42-0fae92203c45","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"HDMI-A-1"}
abr 18 19:28:05 kheprix kwin_wayland[7091]: qml: Polonium DBG: Window krunner hooked into script
abr 18 19:28:05 kheprix kwin_wayland[7091]: qml: Polonium DBG: Not tiling window krunner
abr 18 19:28:06 kheprix kwin_wayland[7091]: qml: Polonium DBG: Window krunner removed
abr 18 19:28:06 kheprix kwin_wayland[7091]: qml: Polonium DBG: Removing window krunner from desktops
abr 18 19:28:06 kheprix kwin_wayland[7091]: qml: Polonium DBG: Rebuilding layout for desktops {"desktop":"32b80466-462e-4063-9a42-0fae92203c45","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"DP-3"},{"desktop":"32b80466-462e-4063-9a42-0fae92203c45","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"HDMI-A-1"}
abr 18 19:28:07 kheprix kwin_wayland[7091]: qml: Polonium DBG: Window Chromium hooked into script
abr 18 19:28:07 kheprix kwin_wayland[7091]: qml: Polonium DBG: Window Chromium added
abr 18 19:28:07 kheprix kwin_wayland[7091]: qml: Polonium DBG: Adding window Chromium to desktops {"desktop":"32b80466-462e-4063-9a42-0fae92203c45","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"DP-3"}
abr 18 19:28:07 kheprix kwin_wayland[7091]: qml: Polonium DBG: Rebuilding layout for desktops {"desktop":"32b80466-462e-4063-9a42-0fae92203c45","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"DP-3"},{"desktop":"32b80466-462e-4063-9a42-0fae92203c45","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"HDMI-A-1"}
abr 18 19:28:07 kheprix kwin_wayland[7091]: qml: Polonium DBG: Maximized on window Chromium set to true
abr 18 19:28:07 kheprix kwin_wayland[7091]: qml: Polonium DBG: Untiling window Chromium on desktops {"desktop":"32b80466-462e-4063-9a42-0fae92203c45","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"DP-3"}
abr 18 19:28:07 kheprix kwin_wayland[7091]: qml: Polonium DBG: Rebuilding layout for desktops {"desktop":"32b80466-462e-4063-9a42-0fae92203c45","activity":"ae4cb9e2-ecbe-493a-ba6c-d4c6a35c7cdf","output":"DP-3"}

Screenshots and videos

Additional context
I am running ungoogled-chromium-bin V123.0.6312.105-1 on arch linux
Operating System: Arch Linux
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.1.0
Qt Version: 6.7.0
Kernel Version: 6.8.6-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 7600X 6-Core Processor
Memory: 30,5 GiB of RAM
Graphics Processor: AMD Radeon RX 6750 XT
Manufacturer: ASUS

Try unmaximizing chromium. Chromium, like many applications, remembers maximized state and tries to restore it. This causes it to become untiled.

It just creates a transparent gap between the window decorations and the actual window content and still doesn't tile

It seems to be fixed now!


Tasks batch space in directory problem | Not encoding bug | bat doesn't work

VSCode Version: 1.7.1 (seems all versions)
OS Version: Windows 7

It's not problem of encoding, it's doesn't matter in bat echo 1 or echo 123 or something else - bat file doesn't work at all
Issue was closed with wrong reason
https://github.com/Microsoft/vscode/issues/15444
Steps to Reproduce:

Create directory with space: C:/project test
Create start.bat in this dir with text: echo 1
Create empty text.txt in this dir
Run VSCode & Open this dir as workspace
Ctrl+Shift+P -> Tasks -> Configure Task Runner -> Others
Import this configuration & save
{
"version": "0.1.0",
"command": "${workspaceRoot}/start.bat",
"args": ["${file}"]
}
Open text.txt and compile Ctrl+Shift+B
Result
"c:\project" �� ����� ����७��� ��� ���譥�
��������, �ᯮ��塞�� �ணࠬ��� ��� �������� 䠩���.

Dups https://github.com/Microsoft/vscode/issues/3550


Update dg

Codecov Report

Merging #210 (3f213b4) into master (faf0157) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #210   +/-   ##
=========================================
  Coverage     67.23%   67.23%
  Complexity      695      695
=========================================
  Files           107      107
  Lines          2420     2420
  Branches        328      328
=========================================
  Hits           1627     1627
  Misses          666      666
  Partials        127      127

Continue to review full report at Codecov.

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


runtime: unexpected return pc crash on linux-amd64-alpine builder

The revived linux-amd64-alpine builder has flaked twice in its short new lifetime with 'unexpected return pc' crashes during the cgo tests.
Here is a repro case using a gomote (note that if you ssh in, you have to set up your environment manually, and in particular you have to put /workdir/go/bin at the front of PATH and have to set GOROOT_BOOTSTRAP=/workdir/go1.4). Not sure why the environment is so messed up on Alpine. gomote run does not have these problems, only gomote ssh.
VM=$(gomote create linux-amd64-alpine)
gomote push $VM
gomote run $VM go/src/make.bash
gomote put -mode 0777 $VM - try.sh <<'EOF'
#!/bin/bash
cd /workdir/go/misc/cgo/test
for i in $(seq 100); do
    date
    if ! /workdir/go/bin/go test >log 2>&1; then
        cat log
    fi
done
EOF
gomote run $VM try.sh

You may need to repeat the try.sh a few times depending on how flaky the machine is feeling but most runs get at least one failure.
Here are some failures from that script:
runtime: g 3: unexpected return pc for runtime.gcenable.func1 called from 0x0
stack: frame={sp:0xc0000557c8, fp:0xc0000557e0} stack=[0xc000055000,0xc000055800)
0x000000c0000556c8:  0x000000c000055750  0x000000000040d21d <runtime.chansend+0x000000000000055d>
0x000000c0000556d8:  0x0000000000581220  0x000000c00007e060
0x000000c0000556e8:  0x00000000005e9f78  0x0000000000000000
0x000000c0000556f8:  0x0000000000000000  0x0000000000000000
0x000000c000055708:  0x0000000000000000  0x0000000000000000
0x000000c000055718:  0x000000c00007e058  0x0000000000000000
0x000000c000055728:  0x0000000000000000  0x0000000000000000
0x000000c000055738:  0x0000000000000000  0x0000000000000000
0x000000c000055748:  0x0000000000000000  0x000000c000055780
0x000000c000055758:  0x000000000040cc9d <runtime.chansend1+0x000000000000001d>  0x000000c00007e000
0x000000c000055768:  0x0000000000440bb6 <runtime.gopark+0x00000000000000d6>  0x0000000000000001
0x000000c000055778:  0x0000000000000000  0x000000c0000557b8
0x000000c000055788:  0x000000000042ba2e <runtime.bgsweep+0x000000000000008e>  0x0000000000000000
0x000000c000055798:  0x0000000000000000  0x0000000000000000
0x000000c0000557a8:  0x0000000000000000  0x000000c00007e000
0x000000c0000557b8:  0x000000c0000557d0  0x0000000000420706 <runtime.gcenable.func1+0x0000000000000026>
0x000000c0000557c8: <0x00007f8a890934b6  0x00007f8a61816b64
0x000000c0000557d8: !0x0000000000000000 >0x0000000000000000
0x000000c0000557e8:  0x0000000000000000  0x00007f8a890d3600
0x000000c0000557f8:  0x00007f8a89092acf
fatal error: unknown caller pc

runtime: g 19: unexpected return pc for runtime.gcenable.func2 called from 0x0
stack: frame={sp:0xc000050fc8, fp:0xc000050fe0} stack=[0xc000050800,0xc000051000)
0x000000c000050ec8:  0x000000000000000e  0x000000c0000061a0
0x000000c000050ed8:  0x000000c000050f60  0x000000000040d265 <runtime.chansend+0x00000000000005a5>
0x000000c000050ee8:  0x0000000000000050  0x000000c00009c000
0x000000c000050ef8:  0x0000000000000000  0x0000010000000000
0x000000c000050f08:  0x0000000000000003  0x0000000000000030
0x000000c000050f18:  0x0000000000000000  0x0000000000000050
0x000000c000050f28:  0x000000c000096058  0x000000c00007e000
0x000000c000050f38:  0x0000000000000000  0x0000000000000000
0x000000c000050f48:  0x0000000000440bb6 <runtime.gopark+0x00000000000000d6>  0x000000000040d320 <runtime.chansend.func1+0x0000000000000000>
0x000000c000050f58:  0x000000c000096000  0x000000c000050f90
0x000000c000050f68:  0x0000000000429ad3 <runtime.(*scavengerState).park+0x0000000000000053>  0x000000c000096000
0x000000c000050f78:  0x00000000005e9f78  0x0000000000000001
0x000000c000050f88:  0x0000000000000000  0x000000c000050fb8
0x000000c000050f98:  0x000000000042a0a5 <runtime.bgscavenge+0x0000000000000045>  0x00000000006f9960
0x000000c000050fa8:  0x0000000000000000  0x000000c000096000
0x000000c000050fb8:  0x000000c000050fd0  0x00000000004206a6 <runtime.gcenable.func2+0x0000000000000026>
0x000000c000050fc8: <0x00007f47256144b6  0x00007f46fdea3b64
0x000000c000050fd8: !0x0000000000000000 >0x0000000000000000
0x000000c000050fe8:  0x0000000000000000  0x00007f4725654600
0x000000c000050ff8:  0x00007f4725613acf
fatal error: unknown caller pc

This one did not happen during garbage collection:
runtime: g 20: unexpected return pc for testing.tRunner called from 0x7feeabb0dacf
stack: frame={sp:0xc000051770, fp:0xc0000517c0} stack=[0xc000051000,0xc000051800)
0x000000c000051670:  0x000000012a05f200  0x000000c0000880a0
0x000000c000051680:  0x000000c000094180  0x000000c0000516f8
0x000000c000051690:  0x000000c000102b80  0x000000c000102b60
0x000000c0000516a0:  0x0000000000000000  0x00000000005890c0
0x000000c0000516b0:  0x00000000006d7d50  0x0000000000000000
0x000000c0000516c0:  0x0000000000000000  0x0000000000000000
0x000000c0000516d0:  0x0000000000000000  0x000000c000051730
0x000000c0000516e0:  0x0000000000454a36 <runtime.sigpanic+0x00000000000002f6>  0x00000000005890c0
0x000000c0000516f0:  0x00000000006d7d50  0x000000c000051748
0x000000c000051700:  0x0000000000561ceb <misc/cgo/test.testSetgid+0x00000000000000ab>  0x000000c0001121e0
0x000000c000051710:  0x000000c000102b60  0x0000000000000001
0x000000c000051720:  0x00000000006ea660  0x00000000005eb418
0x000000c000051730:  0x000000c000051760  0x0000000000478bfe <sync.(*RWMutex).Lock+0x000000000000001e>
0x000000c000051740:  0x0000000000000000  0x000000c000051760
0x000000c000051750:  0x0000000000526bd9 <misc/cgo/test.TestSetgid+0x0000000000000019>  0x000000c0001029c0
0x000000c000051760:  0x000000c0000517b0  0x00000000004d6d15 <testing.tRunner+0x0000000000000115>
0x000000c000051770: <0x0000000000000000  0x0300000000000000
0x000000c000051780:  0x00000000004d6d80 <testing.tRunner.func2+0x0000000000000000>  0x00007feeabb0e4b6
0x000000c000051790:  0x00007feeabb4ed8c  0x0000000000000000
0x000000c0000517a0:  0x0000000000000000  0x0000000000000000
0x000000c0000517b0:  0x00007feeabb4e600 !0x00007feeabb0dacf
0x000000c0000517c0: >0x0000000000000000  0x00000000ffffffff
0x000000c0000517d0:  0x0000000000000000  0x00000000004710a1 <runtime.goexit+0x0000000000000001>
0x000000c0000517e0:  0x0000000000000000  0x0000000000000000
0x000000c0000517f0:  0x0000000000000000  0x00007feeabb0e5d2
fatal error: unknown caller pc

runtime stack:
runtime.throw({0x5ae5a1?, 0x6ea660?})
	/workdir/go/src/runtime/panic.go:1047 +0x5d fp=0x7fee843e3648 sp=0x7fee843e3618 pc=0x43de7d
runtime.gentraceback(0x100000000467aba?, 0xc000100000?, 0xc000102b60?, 0x7fee843e3a18?, 0x0, 0x0, 0x7fffffff, 0x7fee843e3a08, 0x0?, 0x0)
	/workdir/go/src/runtime/traceback.go:258 +0x1cf7 fp=0x7fee843e39b8 sp=0x7fee843e3648 pc=0x4658b7
runtime.addOneOpenDeferFrame.func1()
	/workdir/go/src/runtime/panic.go:645 +0x6b fp=0x7fee843e3a30 sp=0x7fee843e39b8 pc=0x43d00b
runtime.systemstack()
	/workdir/go/src/runtime/asm_amd64.s:492 +0x49 fp=0x7fee843e3a38 sp=0x7fee843e3a30 pc=0x46eee9

goroutine 20 [running]:
runtime.systemstack_switch()
	/workdir/go/src/runtime/asm_amd64.s:459 fp=0xc0000515e8 sp=0xc0000515e0 pc=0x46ee80
runtime.addOneOpenDeferFrame(0xc0000221e0?, 0xc000094180?, 0xc000112180?)
	/workdir/go/src/runtime/panic.go:644 +0x69 fp=0xc000051628 sp=0xc0000515e8 pc=0x43cf49
panic({0x5890c0, 0x6d7d50})
	/workdir/go/src/runtime/panic.go:844 +0x112 fp=0xc0000516e8 sp=0xc000051628 pc=0x43d792
runtime.panicmem(...)
	/workdir/go/src/runtime/panic.go:260
runtime.sigpanic()
	/workdir/go/src/runtime/signal_unix.go:837 +0x2f6 fp=0xc000051740 sp=0xc0000516e8 pc=0x454a36
sync.(*RWMutex).Lock(0x0?)
	/workdir/go/src/sync/rwmutex.go:147 +0x1e fp=0xc000051770 sp=0xc000051740 pc=0x478bfe

Here are the two build dashboard failures:
https://build.golang.org/log/658036e08c7a1d218c33808fdd1d6612b40502d8
runtime: g 2: unexpected return pc for runtime.forcegchelper called from 0x0
stack: frame={sp:0xc000056fb0, fp:0xc000056fe0} stack=[0xc000056800,0xc000057000)
0x000000c000056eb0:  0x0000000000000000  0x0000000000000000
0x000000c000056ec0:  0x0000000000000000  0x0000000000000000
0x000000c000056ed0:  0x0000000000000000  0x0000000000000000
0x000000c000056ee0:  0x0000000000000000  0x0000000000000000
0x000000c000056ef0:  0x0000000000000000  0x0000000000000000
0x000000c000056f00:  0x0000000000000000  0x0000000000000000
0x000000c000056f10:  0x0000000000000000  0x0000000000000000
0x000000c000056f20:  0x0000000000000000  0x0000000000000000
0x000000c000056f30:  0x0000000000000000  0x0000000000000000
0x000000c000056f40:  0x0000000000000000  0x0000000000000000
0x000000c000056f50:  0x0000000000000000  0x0000000000000000
0x000000c000056f60:  0x0000000000000000  0x0000000000000000
0x000000c000056f70:  0x0000000000000000  0x0000000000000000
0x000000c000056f80:  0x0000000000000000  0x00005637530dbdb6 <runtime.gopark+0x00000000000000d6>
0x000000c000056f90:  0x0000000000000000  0x0000000000000000
0x000000c000056fa0:  0x000000c000056fd0  0x00005637530dbc4d <runtime.forcegchelper+0x00000000000000ad>
0x000000c000056fb0: <0x0000000000000000  0x0000000000000000
0x000000c000056fc0:  0x0000000000000000  0x00007efee325e4b6
0x000000c000056fd0:  0x00007efebba04b64 !0x0000000000000000
0x000000c000056fe0: >0x0000000000000000  0x0000000000000000
0x000000c000056ff0:  0x00007efee329e600  0x00007efee325dacf
fatal error: unknown caller pc

and
https://build.golang.org/log/94cf14d78b116487dc76a921baf6ba76480a4c7a
runtime: g 5: unexpected return pc for runtime.sigpanic called from 0x7f52c162dd8c
stack: frame={sp:0xc000058700, fp:0xc000058758} stack=[0xc000058000,0xc000058800)
0x000000c000058600:  0x0000564cf403107b <runtime.write+0x000000000000003b>  0x0000000000000002
0x000000c000058610:  0x000000c000058648  0x0000564cf40109ce <runtime.recordForPanic+0x000000000000004e>
0x000000c000058620:  0x0000564cf403107b <runtime.write+0x000000000000003b>  0x0000000000000002
0x000000c000058630:  0x0000564cf4144017  0x0000000000000001
0x000000c000058640:  0x0000000000000001  0x000000c000058680
0x000000c000058650:  0x0000564cf4010cd2 <runtime.gwrite+0x00000000000000f2>  0x0000564cf4144017
0x000000c000058660:  0x0000000000000001  0x0000000000000001
0x000000c000058670:  0x000000c0000586e2  0x000000000000000e
0x000000c000058680:  0x0000564cf4040210 <runtime.systemstack+0x0000000000000030>  0x0000564cf400f3cc <runtime.fatalthrow+0x000000000000006c>
0x000000c000058690:  0x000000c0000586a0  0x000000c000007ba0
0x000000c0000586a0:  0x0000564cf400f400 <runtime.fatalthrow.func1+0x0000000000000000>  0x000000c000007ba0
0x000000c0000586b0:  0x0000564cf400f07f <runtime.throw+0x000000000000005f>  0x000000c0000586d0
0x000000c0000586c0:  0x000000c0000586f0  0x0000564cf400f07f <runtime.throw+0x000000000000005f>
0x000000c0000586d0:  0x000000c0000586d8  0x0000564cf400f0a0 <runtime.throw.func1+0x0000000000000000>
0x000000c0000586e0:  0x0000564cf414445e  0x0000000000000005
0x000000c0000586f0:  0x000000c000058748  0x0000564cf4025ca5 <runtime.sigpanic+0x00000000000002c5>
0x000000c000058700: <0x0000564cf414445e  0x000000c0000161e0
0x000000c000058710:  0x000000c000058728  0x0000000000000001
0x000000c000058720:  0x00007f52c162dd8c  0x000000c000007ba0
0x000000c000058730:  0x0000564cf41800e0  0x0000564cf40a7e14 <testing.tRunner+0x0000000000000034>
0x000000c000058740:  0x0000000000000000  0x00007f52c15ed4b6
0x000000c000058750: !0x00007f52c162dd8c >0x0000000000000000
0x000000c000058760:  0x0000000000000000  0x0000000000000000
0x000000c000058770:  0x00007f52c162d600  0x00007f52c15ecacf
0x000000c000058780:  0x0000000000000000  0x00000000ffffffff
0x000000c000058790:  0x0000564cf40a7fa0 <testing.tRunner.func1+0x0000000000000000>  0x000000c000007a00
0x000000c0000587a0:  0x000000c000058780  0x000000c000058790
0x000000c0000587b0:  0x000000c0000587d0  0x00007f52c15ed5d2
0x000000c0000587c0:  0x00007f52c15f0080  0x00007f52c162d600
0x000000c0000587d0:  0x00000000ffffffff  0x00007f52c15efbbb
0x000000c0000587e0:  0x0000000000000000  0x00007f52c15efb6d
0x000000c0000587f0:  0x00007f52c162d604  0x0000000000000000

Perhaps this is Alpine-specific, or perhaps it is musl-related.
The Alpine image may have an old Linux kernel; maybe we should update it.
There are a few other open 'unexpected return pc' issues.
Maybe they are all stale:

#47003 is Go 1.16 on Ubuntu.
#35005 is Go 1.13 on Alpine 3.10 (but disappears on Debian and on Alpine 3.9.4).
#40401 is Go 1.14.6 on Windows
#40469 is Go 1.13.14 on Windows
#51707 is Go 1.16.2 on an unspecified system.
#43496 is Go 1.15.6 on Debian (Docker golang image).

#35005 is the most interesting one but the repro case is a very large program running under Docker.

2022-08-08T14:10:19-964f0c7/linux-amd64-alpine

@rsc Assigning to you right now while you're updating the image, but feel free to unassign once you're done.
Updates from internal discussion:

Seems to reproduce after the update, too.
Maybe related to stack smashing protections?

CC @cherrymui @mdempsky

I updated the image already, just need to submit the CL.

Since the 10th, when https://go.dev/cl/422097 was submitted. (I'm almost certain the coordinator has been redeployed since then).
2022-08-16T20:39:44-e49e876/linux-amd64-alpine
2022-08-12T16:38:52-f001df5/linux-amd64-alpine
2022-08-12T01:51:51-449691b/linux-amd64-alpine

This is reproducible with go test in misc/cgo/test. Specifically, on a linux-amd64-alpine gomote, I had success with:
$ for i in $(seq 1 100); do gomote run -dir ./go/misc/cgo/test $INSTANCE ./go/bin/go test -count 1; done

Elsewhere, @cherrymui mentioned that this looks like it could be corruption from a stack overflow. I agree. In the partial trace below, everything below 0xc000122770 looks like the Go text or heap address, but above 0xc000122770, we see lots of system-looking addresses 0x00007fd.... And this is right at the top of the stack, where the stack below may be overflowing.
goroutine 37 [syscall (scan)]:
runtime: g 37: unexpected return pc for runtime.notetsleepg called from 0x0
stack: frame={sp:0xc000122768, fp:0xc0001227a0} stack=[0xc000122000,0xc000122800)
0x000000c000122000:  0x0000000000000000  0x0000000000000000
... mostly zeroes ...
0x000000c0001225f0:  0x0000000000000000  0x0000000000000000
0x000000c000122600:  0x0000000000000000  0x0000000000000000
0x000000c000122610:  0x0000000000000000  0x0000000000000000
0x000000c000122620:  0x0000000000000000  0x0000000000000000
0x000000c000122630:  0x0000000000000000  0x0000000000000000
0x000000c000122640:  0x000000c046505845  0x000000c000122688
0x000000c000122650:  0x0000000000487d77 <time.NewTimer+0x00000000000000b7>  0x000000012a05f200
0x000000c000122660:  0x0000000000000001  0x000005ff66f38c41
0x000000c000122670:  0x000000012a05f200  0x000000c000118050
0x000000c000122680:  0x000000c000126060  0x000000c0001226f8
0x000000c000122690:  0x0000000000564979 <misc/cgo/test.runTestSetgid+0x0000000000000079>  0x0000000000606b28
0x000000c0001226a0:  0x0000000000000000  0x000000000061acf3
0x000000c0001226b0:  0x0000000000000022  0x000000000000051b
0x000000c0001226c0:  0x00000000004d9940 <testing.tRunner+0x0000000000000000>  0x00000000006af138
0x000000c0001226d0:  0x000000000043bdd6 <runtime.futexsleep+0x0000000000000036>  0x0000000000773660
0x000000c0001226e0:  0x0000000000000080  0x0000000000000000
0x000000c0001226f0:  0x0000000000000000  0x0000000000000000
0x000000c000122700:  0x00000000005bf4f0  0x0000000300000002
0x000000c000122710:  0x000000c00010a820  0x000000c000122758
0x000000c000122720:  0x0000000000415045 <runtime.notetsleep_internal+0x0000000000000185>  0x000000c000122760
0x000000c000122730:  0x00000000004d97a5 <testing.callerName+0x0000000000000045>  0x00000000004d9974 <testing.tRunner+0x0000000000000034>
0x000000c000122740:  0x0000000000000000  0xffffffffffffffff
0x000000c000122750:  0x000000c00010a820  0x000000c000122790
0x000000c000122760:  0x0000000000415165 <runtime.notetsleepg+0x0000000000000045> <0x0000000000773660
0x000000c000122770:  0x0000000000000000  0x00007fd7fa3c46fa
0x000000c000122780:  0x00007fd7fa408b84  0x0000000000000000
0x000000c000122790:  0x0000000000000000 !0x0000000000000000
0x000000c0001227a0: >0xffffffffffffffff  0x00007fd7fa3c3cf5
0x000000c0001227b0:  0x0000000000000000  0x0000000000000001
0x000000c0001227c0:  0x000000c00010a340  0x00000000005bcb50
0x000000c0001227d0:  0x00007fd7fa408400  0x00007fd7fa3c4820
0x000000c0001227e0:  0x00007fd7fa3c74a3  0x00007fd7fa408400
0x000000c0001227f0:  0x0000000000000000  0x00007fd7fa3c6fca
runtime.notetsleepg(0xffffffffffffffff?, 0x7fd7fa3c3cf5?)
        /workdir/go/src/runtime/lock_futex.go:236 +0x34 fp=0xc0001227a0 sp=0xc000122768 pc=0x415154
created by os/signal.Notify.func1.1
        /workdir/go/src/os/signal/signal.go:151 +0x2a

FWIW, I've been unable to reproduce this with _StackLimit increased by 10x, which seems consistent with a stack overflow somewhere.

I take that back. It look about an hour (instead of the usual ~5 minutes), but I did get a repro with 10 * _StackLimit.

I've been making slow progress on this. The most notable is that this reproduces when running only TestSetgid and TestSetgidStress, while it does not reproduce while running only various other tests I've tried. (I haven't tried each test individually, as there are dozens and the repro time is a bit high). So this may be related to setgid, or just signals in general.

It looks like the problem is that signal 34 (SIGRT_2) used by musl for setgid is not getting SA_ONSTACK set.
If I'm interpreting strace correctly, it looks like this signal is still SIG_DFL when Go queries (it would set SA_ONSTACK if a handler was already installed):
1184993 rt_sigaction(SIGRT_2, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0

Only later does musl install the signal handler:
1184993 rt_sigaction(SIGRT_2, {sa_handler=0x7f29efb24078, sa_mask=~[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f29efb15c9f},  <unfinished ...>

musl does not install the SIGRT_2 handler until the first call to __synccall (actually, it reinstalls it on every call), which is why we don't know to add SA_ONSTACK at startup.
__synccall is used by setgroups, setrlimit, and setxid.

reinstalls it on every call

(!)
That means even if we set SA_ONSTACK for their handler, they will reinstall and overwrite it?

https://git.musl-libc.org/cgit/musl/tree/src/thread/synccall.c#n102
Does it mean that they remove the handler at exit of the call?  Hm....

Correct, they don't even try to match the existing flags or forward to an existing handler, so we can't install a dummy SA_ONSTACK handler.

Does it mean that they remove the handler at exit of the call?

Yes, that is what I see:
1184993 rt_sigaction(SIGRT_2, {sa_handler=0x7f29efb24078, sa_mask=~[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f29efb15c9f},  <unfinished ...>
1184993 tkill(1184998, SIGRT_2)         = 0
1184998 --- SIGRT_2 {si_signo=SIGRT_2, si_code=SI_TKILL, si_pid=1184993, si_uid=0} ---
1184993 tkill(1184996, SIGRT_2 <unfinished ...>
1184996 --- SIGRT_2 {si_signo=SIGRT_2, si_code=SI_TKILL, si_pid=1184993, si_uid=0} ---
1184993 tkill(1184995, SIGRT_2 <unfinished ...>
1184995 --- SIGRT_2 {si_signo=SIGRT_2, si_code=SI_TKILL, si_pid=1184993, si_uid=0} ---
1184993 tkill(1184997, SIGRT_2 <unfinished ...>
1184997 --- SIGRT_2 {si_signo=SIGRT_2, si_code=SI_TKILL, si_pid=1184993, si_uid=0} ---
1184993 tkill(1184994, SIGRT_2 <unfinished ...>
1184994 --- SIGRT_2 {si_signo=SIGRT_2, si_code=SI_TKILL, si_pid=1184993, si_uid=0} ---
1184993 rt_sigaction(SIGRT_2, {sa_handler=SIG_IGN, sa_mask=~[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f29efb15c9f},  <unfinished ...>

To summarize:

Go uses small goroutines stacks, so there is no guarantee that there is enough space on the stack for signal context and frame at all times.
To handle this, Go creates a separate signal stack for each thread installed with sigaltstack. All signal handlers must set SA_ONSTACK to use the signal stack and avoid smashing the goroutine stack.
To try to cooperate with libc, at startup Go inspects all signal handlers (even ones it doesn't care to handle), and adds SA_ONSTACK if it is not already set.
musl uses signal 34 for the various setxid calls, but does not install the handler at startup. Instead, it is temporarily installed on each call to the setxid functions (in __synccall).
As a result, Go never has a chance to add SA_ONSTACK.

I don't see how we can work around this in Go given that we can't adjust the signal handler flags, nor does __synccall respect flags from an existing signal handler.
There are several changes on the musl side that could address this:

musl could install the signal 34 handler once at startup so that Go can adjust the flag.
Or, __synccall could query for an existing signal handler, and if it has SA_ONSTACK then keep that flag for their handler. In this case, Go would install a dummy signal 34 handler at startup just to expose SA_ONSTACK.
Or, even simpler, according to man 2 sigaction's SA_ONSTACK description: "If an alternate stack is not available, the default stack will be used." If this is accurate (I haven't verified), then __synccall could set SA_ONSTACK unconditionally, which would normally make no difference, but would use Go's sigaltstack when linked with Go.

Ah, it turns out this is a duplicate of #39857, which has been discussed at some length but not resolved.


WIP: adds print_iterator to {fmt} (see #972)

print_iterator is an abstraction over fmt::print so that it is possible
for one to write to a fmt object while iterating over some input range.

This is a WIP Pull Request for design feedback so that it can be sent to LEWG(I) for consideration for C++20. It does not yet follow the Google Style Guide (mostly because I am unfamiliar with GSG and the Kona deadline is nearing), and thus cannot be merged with upstream.

I've compiled this stuff on Visual Studio 2017 and ran the tests to see how this fares: 👍
Because of that I've had a much better view on the code in it's entirety. Beyond the comments above, my gut feeling was that the implementation is much too complicated and verbose: does this relatively simple iterator really require a base class with just the same number of template arguments as the actual iterator class that does nothing but holding the string_view? Is it really necessary to specialize iterator_traits to make it a proper standard's compliant iterator? The answer is no. With a little reshuffling and lots of deletions I ended up with functionally identical code that passes the test suite (that's all even if most of the stuff is iterator ceremony):
FMT_BEGIN_NAMESPACE

namespace detail {
  template<class... Ts>
  struct overloaded : Ts... {
    using Ts::operator()...;
  };

  template<class... Ts>
  overloaded(Ts&&...) -> overloaded<Ts...>;
} // namespace detail

template<class T, class CharT = char, class Traits = std::char_traits<CharT>>
// requires Formattable<T>
class print_iterator {
public:
  using difference_type = std::intmax_t;
  using iterator_category = std::output_iterator_tag;
  using value_type = void;
  using pointer = void;
  using reference = void;

  print_iterator& operator*() noexcept { return *this; }
  print_iterator& operator++() noexcept { return *this; }
  print_iterator& operator++(int) noexcept { return *this; }

  print_iterator() = default;
  explicit print_iterator(std::string_view s) : format_{s} {} // is this necessary?
  print_iterator(std::string_view s, FILE* file) : format_{s}, out_{file} {}
  print_iterator(std::string_view s, std::basic_ostream<CharT, Traits>& file)
    : format_{s} , out_{std::addressof(file)} {}

  std::basic_string_view<CharT> format() const noexcept { return format_; } // is this necessary?

  template<class U = T>
  auto operator=(U const& value)
    -> std::enable_if_t<std::is_same_v<
      std::remove_cv_t<std::remove_reference_t<T>>,
      std::remove_cv_t<std::remove_reference_t<U>>>, print_iterator&>
  {
    std::visit(detail::overloaded{
      [this, &value](FILE* file){ ::fmt::print(file, format_, value); },
      [this, &value](std::basic_ostream<CharT, Traits>* os){ ::fmt::print(*os, format_, value); },
    }, out_);
    return *this;
  }
private:
  std::basic_string_view<CharT> format_ = "{}";
  std::variant<FILE*, std::basic_ostream<CharT, Traits>*> out_ = stdout;
};

FMT_END_NAMESPACE

@DanielaE

Beyond the comments above, my gut feeling was that the implementation is much too complicated and verbose: does this relatively simple iterator really require a base class with just the same number of template arguments as the actual iterator class that does nothing but holding the string_view?

There will be a format_iterator coming, which is essentially a carbon copy of print_iterator, save for one constructor and the assignment operator. I opted to factor out as much code as possible. If you think it's better to repeat this code across both implementations, then I'll make the necessary changes.

Is it really necessary to specialize iterator_traits to make it a proper standard's compliant iterator? The answer is no.

The iterator concepts in C++20 do not require iterator_traits: they are legacy cruft that is only necessary for older code. Most of the types in iterator_traits are not relevant to print_iterator, and I'd rather them not be available. A C++20-conforming iterator_traits will also require neither the members, nor the specialisation.
If you'd like an example of a Standard C++20 iterator that doesn't any of these members at all, please see counted_iterator.

explicit print_iterator(std::string_view s) : format_{s} {} // is this necessary?

This constructor makes it possible to replicate fmt::print("${}", 10).

I've compiled this stuff on Visual Studio 2017 and ran the tests to see how this fares: 👍

Thanks! I've become so used to relying on push-enabling CI that I forgot to test on a non-GCC 8 compiler 😅

Hello,
I have some suggestions about print_iterator if you are interested.
It is probably not necessary to make the type that is printed a template parameter, e.g. like std::ostream_joiner does.
Then one could add overloads for std::pair and std::tuple for operator= to enable uses like
std::map m{{1, 2}, {3, 4}};
std::copy(m, fmt::print_iterator("{}: {}\n"));


Burrow service frequent down

Team,
Need your help to fix the Burrow service frequent down issue.
Error Snip

panic: interface conversion: interface {} is nil, not *storage.brokerOffset
goroutine 85 [running]:
github.com/linkedin/Burrow/core/internal/storage.(*InMemoryStorage).fetchTopic(0xc4201d65a0, 0xc42100b8f0, 0xc42034d800)
/opt/work/src/github.com/linkedin/Burrow/core/internal/storage/inmemory.go:611 +0x3c8
github.com/linkedin/Burrow/core/internal/storage.(*InMemoryStorage).(github.com/linkedin/Burrow/core/internal/storage.fetchTopic)-fm(0xc42100b8f0, 0xc42034d800)
/opt/work/src/github.com/linkedin/Burrow/core/internal/storage/inmemory.go:182 +0x3e
github.com/linkedin/Burrow/core/internal/storage.(*InMemoryStorage).requestWorker(0xc4201d65a0, 0x11, 0xc4201d4900)
/opt/work/src/github.com/linkedin/Burrow/core/internal/storage/inmemory.go:190 +0x105b
created by github.com/linkedin/Burrow/core/internal/storage.(*InMemoryStorage).Start
/opt/work/src/github.com/linkedin/Burrow/core/internal/storage/inmemory.go:144 +0x28b

Same here!!
goroutine 24 [running]:
github.com/linkedin/Burrow/core/internal/storage.(*InMemoryStorage).fetchTopic(0xc420085cc0, 0xc4205adc70, 0xc4206f6ba0)
/go/src/github.com/linkedin/Burrow/core/internal/storage/inmemory.go:611 +0x3ee
github.com/linkedin/Burrow/core/internal/storage.(*InMemoryStorage).(github.com/linkedin/Burrow/core/internal/storage.fetchTopic)-fm(0xc4205adc70, 0xc4206f6ba0)
/go/src/github.com/linkedin/Burrow/core/internal/storage/inmemory.go:182 +0x3e
github.com/linkedin/Burrow/core/internal/storage.(*InMemoryStorage).requestWorker(0xc420085cc0, 0x3, 0xc4200602a0)
/go/src/github.com/linkedin/Burrow/core/internal/storage/inmemory.go:190 +0x1003
created by github.com/linkedin/Burrow/core/internal/storage.(*InMemoryStorage).Start
/go/src/github.com/linkedin/Burrow/core/internal/storage/inmemory.go:144 +0x336
Thank you!!! 👍

same here :
panic: interface conversion: interface {} is nil, not *storage.brokerOffset

goroutine 51 [running]:
github.com/linkedin/Burrow/core/internal/storage.(*InMemoryStorage).fetchTopic(0xc420236000, 0xc420345500, 0xc4203281e0)
        /go/src/github.com/linkedin/Burrow/core/internal/storage/inmemory.go:611 +0x3ee
github.com/linkedin/Burrow/core/internal/storage.(*InMemoryStorage).(github.com/linkedin/Burrow/core/internal/storage.fetchTopic)-fm(0xc420345500, 0xc4203281e0)
        /go/src/github.com/linkedin/Burrow/core/internal/storage/inmemory.go:182 +0x3e
github.com/linkedin/Burrow/core/internal/storage.(*InMemoryStorage).requestWorker(0xc420236000, 0x10, 0xc42023e780)
        /go/src/github.com/linkedin/Burrow/core/internal/storage/inmemory.go:190 +0x1003
created by github.com/linkedin/Burrow/core/internal/storage.(*InMemoryStorage).Start
        /go/src/github.com/linkedin/Burrow/core/internal/storage/inmemory.go:144 +0x336

Merged #502


Please NO OPENING

You're challenging Abyss, they're fixing it constantly. Continuous encryption. Please, stop, stop, stop. You're doing something that makes their encryption stronger and won't be able to download anymore. If you know how to download video, download it for yourself. Don't share it publicly!!!!

https://github.com/PatrickL546/Hydrax-Abyss.to-DownloadHelper-Python/issues/10
Please close this source code

See this.
https://github.com/PatrickL546/Hydrax-Abyss.to-DownloadHelper-Python/issues/10
Please close your source code

So you are basically saying "I know how to do it, who cares about the others". Thank you abdlhay for providing this repo, much appreciated, don't mind this selfish person.

full of selfishness

full of selfishness

if Abyss didn't keep fixing it so many times I wouldn't be selfish, I'm selfish but it helps me download well. have you seen Netflix? why doesn't anyone share how to download publicly anymore. I just don't want to open it publicly like that because they can easily see and fix it. If it's shared privately, I agree. if you think about the future, they encrypt stronger and harder to find ways to download then you will see this as a short term solution.

full of selfishness

if Abyss didn't keep fixing it so many times I wouldn't be selfish, I'm selfish but it helps me download well. have you seen Netflix? why doesn't anyone share how to download publicly anymore. I just don't want to open it publicly like that because they can easily see and fix it. If it's shared privately, I agree. if you think about the future, they encrypt stronger and harder to find ways to download then you will see this as a short term solution.

I think the admin completely realized this from the beginning, when Abyss continuously fixed , but maybe, for some personal reason, he continued until now.
Whatever. This is the battle of the coders. You are professional. You will break all barriers soon. I'm a ''low-tech'' person, for me (and almost people) - internet is sharing - having it is good, but not having it is also okay.

full of selfishness

if Abyss didn't keep fixing it so many times I wouldn't be selfish, I'm selfish but it helps me download well. have you seen Netflix? why doesn't anyone share how to download publicly anymore. I just don't want to open it publicly like that because they can easily see and fix it. If it's shared privately, I agree. if you think about the future, they encrypt stronger and harder to find ways to download then you will see this as a short term solution.

telegram you? please


support jakarta messaging

Most of the javax libs now have jakarta equivalents. This includes JMS - now there is Jakarta Messaging.
We should clone our jms connector and produce an equivalent that uses https://mvnrepository.com/artifact/jakarta.jms/jakarta.jms-api/3.1.0 instead.

I can take a look at this

I was taking a look into this. Currently jms depends on 2 test packages that relies on javax.jms libs:
"io.github.sullis" %% "jms-testkit" % "1.0.4" % Test,
"com.github.pjfanning" % "jmswrapper" % "0.1.0" % Test

@pjfanning Do you have any plan to release a jmswrapper using jakarta? Am I ok to open a PR on jmswrapper for supporting jakarta.jms? I can reach out sullis to understand their plan

@samueleresca I already have the Jakarta code in a branch.
https://github.com/pjfanning/JmsWrapper/tree/jakarta
I just created a new project but the GitHub tool to import code from other repos is offline tonight.
https://github.com/pjfanning/JakartaMSWrapper
I will look again tomorrow but it shouldn't be hard to release a jakartamswrapper in the near future.

I released https://mvnrepository.com/artifact/com.github.pjfanning/jakartamswrapper/0.1.0

I have linked the PR containing the new jakartams connector. The connector uses jakarta.jms 3.0.0 instead of jakarta.jms 3.1.0 because the latter does not support Java 8. Therefore, the new connector only supports Jakarta Messaging 3.0, not 3.1
@pjfanning I don't remember what we decided in regards of dropping the Java 8 support? Is there any plan to do that soon? I'm wondering if it is worth to pause the jakarta connector until we drop Java 8 support. It would allow us to support all the versions of Jakarta Messaging and it would make the transition smoother (See the issues highlighted in #674 description)

If we merge Jakarta JMS 3.0 support to Pekko Connectors, is it possible that Java 11+ users could just upgrade the Jakarta JMS themselves? Or are there breaking API changes in Jakarta JMS 3.1 that prevent code compiled with Jakarta JMS 3.0 from working at runtime with Jakarta JMS 3.1?

There is no breaking changes that prevent the consumer to upgrade and one can decide to upgrade to jakarta.jms-api 3.1.0.
If we are happy with that #674 is ready to review


Add Python 3.12 support and configure Codecov token

PR Checklist

[x] A description of the changes is added to the description of this PR.
[x] If there is a related issue, make sure it is linked to this PR.
[x] If you've fixed a bug or added code that should be tested, add tests!
[x] Documentation in docs is updated
[x] The projection version has been bumped using the poetry version command, providing an appropriate SemVer version upgrade.

Description of changes

Disable publish to PyPI in GitHub action
Added python 3.12 to the set of python environments the tests run on
Updated codecov config

Welcome to Codecov :tada:
Once merged to your default branch, Codecov will compare your coverage reports and display the results in this comment.
Thanks for integrating Codecov - We've got you covered :open_umbrella:


IPV6 as endpoint with non-localhost address does not seem to work

my environment running ArangoDB
I'm using the latest ArangoDB of the respective release series:

[ ] 2.8
[ *] 3.0
[ *] self-compiled devel branch

On this operating system:

[ ] DCOS on

[ ] AWS
[ ] Azure
[ ] own infrastructure

[* ] Linux

[ ] Debian .deb
[* ] Ubuntu .deb
[ ] SUSE   .rpm
[ ] RedHat .rpm
[ ] Fedora .rpm
[ ] Gentoo
[ *] docker - official docker library
[ *] other:

[ ] Windows, version:
[ ] MacOS, version:

The following problem occurs:
Option --server.endpoint tcp://[fe80::6257:18ff:fe82:3ec6]:8001 does not work, the server tries to start and then says:  2016-12-07T12:44:09Z [27676] WARNING failed to open endpoint 'http+tcp://[fe80::6257:18ff:fe82:3ec6]:8001' with error: bind: Invalid argument 2016-12-07T12:44:09Z [27676] FATAL failed to bind to endpoint 'http+tcp://[fe80::6257:18ff:fe82:3ec6]:8001'. Please check whether another instance is already running using this endpoint and review your endpoints configuration. 2016-12-07T12:44:09Z [27676] WARNING build/bin/arangod() [0x1bbed1a] TRI_GetBacktrace(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)\nbuild/bin/arangod() [0x16e598d] arangodb::rest::GeneralServer::startListening()\nbuild/bin/arangod() [0x16e9da5] arangodb::GeneralServerFeature::start()\nbuild/bin/arangod() [0x1b76169] arangodb::application_features::ApplicationServer::start()\nbuild/bin/arangod() [0x1b71576] arangodb::application_features::ApplicationServer::run(int, char**)\nbuild/bin/arangod() [0x182f934]\n
This IPV6 address is a currently valid address for my host. With "::1" it works and can be contacted as expected, and it binds to a tcp6 endpoint.

Problem: https://en.wikipedia.org/wiki/IPv6_address#Link-local_addresses_and_zone_indices
Solution: force zone id in fe80: address endpoints. For example:
--server.endpoint tcp://[fe80::6257:18ff:fe82:3ec6%eth0]:8001
https://github.com/arangodb/arangodb/blob/v3.1.11/arangod/Scheduler/AcceptorTcp.cpp#L34
auto hostname = _endpoint->host() + "%eth0"; // temp fix

netstat -ant -f inet6
tcp6       0      0  fe80:xyzw.8529  *.*                    LISTEN

telnet fe80:xyzw%eth0 8529
Trying fe80:...
Connected to fe80:xyzw%eth0.
Escape character is '^]'.
GET / HTTP/1.1

HTTP/1.1 301 Moved Permanently
Location: /_db/_system/_admin/aardvark/index.html
Content-Type: text/html
Server: ArangoDB
Connection: Keep-Alive
Content-Length: 197

<title>Moved</title>
Moved

This page has moved to /_db/_system/_admin/aardvark/index.html.

But you cant open ipv6 link local addresses in browsers:
Ticket Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=70762
Ticket Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=700999 (RESOLVED WONTFIX) 🤦♀
Global ipv6 address binding is working.

@baslr please add this to Documentation/Books/Manual/Administration/Configuration/Endpoint.mdpp

@dothebart I updated the documentation. Will be visible in the near future at https://docs.arangodb.com/devel/Manual/Administration/Configuration/Endpoint.html


fix(windows): correctly handle BitLocker locked volumes

Locked volumes throw a FVE_E_LOCKED_VOLUME error on
GetVolumeInformation(). If this is the case, we should also set
writable to FALSE, since we're not able to make any changes to locked
drives (e.g. running diskpart clean on it).
See: https://github.com/resin-io/etcher/issues/1687
Change-Type: patch
Changelog-Entry: Correctly handle BitLocker locked Windows volumes.
Signed-off-by: Juan Cruz Viotti<EMAIL_ADDRESS>

Took me a while to figure out that FVE must mean Full Volume Encryption ;-)
And took even longer to actually find https://msdn.microsoft.com/en-us/library/windows/desktop/dd542648(v=vs.85).aspx

Thanks for the link. I added it as a comment!


[Q] What is the needed regex for this setup?

My current setup is the following:
/my-project/
  /dist/
   /my-dist-files.js
   /my-dist-files.spec.js
 /src/
  /my-classes.ts
  /my-classes.spec.ts

I want to:

include all files in /src/ in the compilation process (elsewhere, the define(), it(), and other jest functions do not get recognized in my editor because are not included in the compilation context),
but only the /src/**/*.spec.ts to be tested by jest. (NOT /dist/**/*.spec.js)

How can I acomplish this? What is the needed regex?
My current tsconfig.json:
{
  "compilerOptions": {
    "outDir": "./dist/",
    "rootDir": "./src/"
 }
}

My current package.json:
{
  "jest": {
    "transform": {
      "^.+\\.tsx?$": "ts-jest"
    },
    "testRegex": "(/__tests__/.*|(\\.|/)(test|spec))\\.(jsx?|tsx?)$",
    "moduleFileExtensions": [
      "ts",
      "tsx",
      "js",
      "jsx",
      "json"
    ]
  }
}

Thanks in advance.

http://facebook.github.io/jest/docs/en/configuration.html#testmatch-array-string might be what you want here

Thanks. Sorry for the late reply. I ended ussing this:
{
"jest": {
    "transform": {
      "^.+\\.tsx?$": "ts-jest"
    },
    "testMatch": ["**/__tests__/**/*.ts?(x)","**/?(*.)(spec|test).ts?(x)"],
    "rootDir": "src",
    "moduleFileExtensions": [
      "ts",
      "tsx",
      "js",
      "jsx",
      "json"
    ]
  }
}


Add debugging tests

work in progress

@adscheevel please review and approve
I made a few small changes and added test cases.


frp: 0.30.0 -> 0.31.1

Motivation for this change
https://github.com/fatedier/frp/releases/tag/v0.31.1
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

This change is

@GrahamcOfBorg build frp


Rpi4: problem at run docker image

Hi everyone, I have a Pi4 with GPU memory up to 320Mb, I tried to make the docker image work but unfortunately it fails me at initialization.
Where am I going wrong?
Thank you very much
Command:
docker run --rm \ --privileged \ -v /home/pi/docker/viseron/recording:/recordings \ -v /home/pi/docker/viseron/config:/config \ -v /etc/localtime:/etc/localtime:ro \ -v /dev/bus/usb:/dev/bus/usb \ -v /opt/vc/lib:/opt/vc/lib \ --name viseron \ --device /dev/vchiq:/dev/vchiq --device /dev/vcsm:/dev/vcsm \ roflcoopter/viseron-rpi:latest
Result
Traceback (most recent call last):   File "viseron.py", line 8, in <module>     from lib.config import ViseronConfig, NVRConfig, CONFIG   File "/src/viseron/lib/config/__init__.py", line 101, in <module>     CONFIG = VISERON_CONFIG_SCHEMA(raw_config)   File "/usr/local/lib/python3.7/dist-packages/voluptuous/schema_builder.py", line 272, in __call__     return self._compiled([], data)   File "/usr/local/lib/python3.7/dist-packages/voluptuous/schema_builder.py", line 594, in validate_dict     return base_validate(path, iteritems(data), out)   File "/usr/local/lib/python3.7/dist-packages/voluptuous/schema_builder.py", line 432, in validate_mapping     raise er.MultipleInvalid(errors) voluptuous.error.MultipleInvalid: expected a dictionary for dictionary value @ data['object_detection']['logging']

I had to explicitly configure the following parameters for the camera, it does not automatically take them from the stream:
cameras:
width: 1920
height: 1080
stream_format: rtsp
fps: 10
codec: h264
Now perform the initialization but I have another error:
Error starting decoder pipe! ffmpeg: error while loading shared libraries: libmmal_core.so: cannot open shared object file: No such file or directory
I will try to investigate and send updates.

UPDATE
So, the file "libmmal_core.so", in my host system, is in the folder "/opt/vc/lib/".
From the docker's startup file there is the reference
...
-v /opt/vc/lib:/opt/vc/lib \
...

So in theory it should take to the correct host folder and map it in the docker, but obviously it can't do it. The file is always untraceable.
I ask for help :)

There is another issue open for RPi4 support #1. Would appreciate if you could report your findings there instead
The rpi image is built on a RPi3 B+ so i suspect this might have something to do with it. I cant be of much help im afraid since i dont have an RPi4 to test with.
Can you enable debug logging and post the full log? Along with your config.yaml
What you could try is to build the image yourself locally and see if that works.

Thank you for your answer., @roflcoopter !
== config ==
cameras:

name: soggiorno
mqtt_name: viseron_soggiorno
host: <IP_ADDRESS>
port: 554
username: [username]
password: [password]
path: /Streaming/Channels/101/
width: 800
height: 600
stream_format: rtsp
fps: 6

== run with ==
docker run --rm \ --privileged \ -v /home/pi/docker/viseron/recording:/recordings \ -v /home/pi/docker/viseron/config:/config \ -v /etc/localtime:/etc/localtime:ro \ -v /dev/bus/usb:/dev/bus/usb \ -v /opt/vc/lib:/opt/vc/lib \ --name viseron \ --device /dev/vchiq:/dev/vchiq --device /dev/vcsm:/dev/vcsm \ roflcoopter/viseron-rpi:latest
== debug ==
[2020-10-23 12:25:25] [root                    ] [INFO    ] - ------------------------------------------- [2020-10-23 12:25:25] [root                    ] [INFO    ] - Initializing... [2020-10-23 12:25:25] [root                    ] [DEBUG   ] - Starting cleanup scheduler [2020-10-23 12:25:26] [root                    ] [DEBUG   ] - Running initial cleanup [2020-10-23 12:25:26] [lib.cleanup             ] [DEBUG   ] - Running cleanup [2020-10-23 12:25:26] [lib.detector            ] [DEBUG   ] - Initializing object detector edgetpu [2020-10-23 12:25:26] [lib.detectors.edgetpu   ] [WARNING ] - EdgeTPU not found. Detection will run on CPU [2020-10-23 12:25:26] [lib.detector            ] [DEBUG   ] - Object detector initialized [2020-10-23 12:25:26] [root                    ] [INFO    ] - Initializing NVR threads [2020-10-23 12:25:26] [lib.nvr.soggiorno       ] [DEBUG   ] - Initializing NVR thread [2020-10-23 12:25:26] [lib.camera.soggiorno    ] [DEBUG   ] - Initializing ffmpeg RTSP pipe [2020-10-23 12:25:26] [lib.camera.soggiorno    ] [DEBUG   ] - Getting stream information for rtsp://admin:SXRXKI@<IP_ADDRESS>:554/Streaming/Channels/101/ Traceback (most recent call last):   File "viseron.py", line 177, in <module>     Viseron()   File "viseron.py", line 69, in __init__     mqtt_queue=mqtt_queue,   File "/src/viseron/lib/nvr.py", line 153, in __init__     self.camera = FFMPEGCamera(config, frame_buffer)   File "/src/viseron/lib/camera.py", line 127, in __init__     self.start_decoder()   File "/src/viseron/lib/camera.py", line 149, in start_decoder     ) = self.get_stream_information(self._config.camera.stream_url)   File "/src/viseron/lib/camera.py", line 226, in get_stream_information     width, height, fps, codec = self.ffprobe_stream_information(stream_url)   File "/src/viseron/lib/camera.py", line 193, in ffprobe_stream_information     stream_information = json.loads(output)["streams"][0]   File "/usr/lib/python3.7/json/__init__.py", line 348, in loads     return _default_decoder.decode(s)   File "/usr/lib/python3.7/json/decoder.py", line 337, in decode     obj, end = self.raw_decode(s, idx=_w(s, 0).end())   File "/usr/lib/python3.7/json/decoder.py", line 355, in raw_decode     raise JSONDecodeError("Expecting value", s, err.value) from None json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

There is some other issue with your configuration. Based on that error in the log it appears that ffprobe cant access the stream.
Are you running 64-bit RPi4?

Yes, i have a Pi4 with 64bit build of lady raspian

UPDATE
For testing, i have run:
ffmpeg -i rtsp://admin[pwd]@<IP_ADDRESS>:554/Streaming/Channels/101 -f image2 -vf fps=fps=1/120 img%03d.jpg
And results are correct:
Input #0, rtsp, from 'rtsp://admin:[pwd]@<IP_ADDRESS>:554/Streaming/Channels/101':
  Metadata:
    title           : Media Presentation
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709, progressive), 1280x720, 25 tbr, 90k tbn, 180k tbc
    Stream #0:1: Audio: aac (LC), 16000 Hz, mono, fltp

That might be why, the rpi image is specifically built on RPi3 32-bit.
I need to totally remake my way of working with the dockerfiles to be able to support the RPi 4 better.
This is quite a large process tho and it will probably take some time before i can do that.

@dadaloop82 I finally got my multiarch builds to work, i put up a test-version under roflcoopter/viseron-new:docker_revamp
Could you try and see if it works on your RPi4? Currently the generated ffmpeg command wont recognize its an RPi4 so the hwaccel args wont be added automatically

Closing due to inactivity, feel free to reopen if the issue persists


files: add function to parse a directory

Issue: https://github.com/moov-io/ach/issues/646

Codecov Report

Merging #648 into master will decrease coverage by 0.06%.
The diff coverage is 81.25%.

@@            Coverage Diff             @@
##           master     #648      +/-   ##
==========================================
- Coverage   93.13%   93.07%   -0.07%
==========================================
  Files          64       65       +1
  Lines        5685     5717      +32
==========================================
+ Hits         5295     5321      +26
- Misses        233      236       +3
- Partials      157      160       +3


Description both optional and mandatory

Under the mandatory fields:
##### description

A short, one line description of the mod and what it does.

And then after the optional fields:
##### description

A free form, long text description of the mod, suitable for displaying detailed information about the mod.

As far as I understand, those are intended to be different fields but someway got the same name.

That was definitely a © 🍝 (copypasta) error. Feel free to issue a correction via PR, otherwise I'll update it myself the next time I make a commit. 👍


Search Form UI

This PR:

Adds the search form UI, including all Material UI form fields.
Pulls in the patient data to autofill zipcode and age as well as a default travel distance of 100 miles.
Sets up FHIR requests for user, patient, and patient cancer conditions.
Styles components using Material UI properties.
Adds tests.

TODO:

Create a FHIR patient to test app with (none of the test patients have cancer that I can tell).
Hook up remaining fields to appropriate data from the patient record.
Hook up matching service (currently using mock results data).
Build out results UI.

TESTING:

Test all form fields including clearing values.
Test responsiveness of design (large to mobile size).
Test multiple patients and users to make sure data is populated correctly.

@jtquach1 All issues resolved!


Number improvements

Changes
Floating Point Numbers!
Added the facility to generate floats in various ways, mirroring the previous capabilities available through integer.
Changes to Number Template
The Number class is not a template anymore, rather, its individual methods are, this should reduce the amount of code generated, as only the individual calls are compiled.
Custom Distributions
Library consumers can now specify their own distributions to be used by the library to generate numbers.
Sampling with a custom distribution can be done both by specifying a range, in which case the output will be clamped (the hard clamping is kind of undesirable, since it ruins the statistical properties of the distribution, a continuous resampling until the value falls in the interval might be more desirable, but might lead to very long executions in case most of the distribution's density is not located inside the user specified bounds), and by specifying no range, in which case the sampling will be uncostrained.
Sampling without bounds might look like a useless wrapper, in my opinion it is still a convenient interface since we re-use the random device that we initialized in our class, hence saving our user quite a bit of code that he would need in order to initialize those objects himself.
More Concept Type Safety
By enforcing a large part of the requirements that a RandomNumberDistribution must have according to the C++ standard, we ensure that while our users can use any distribution to sample through our utilities, they are less likely to design bad code with it, as the new concepts that are introduced would catch their errors at compile time.
New tests
A bunch of new tests have been created to provide more code coverage for the Number module, including floating point counterparts for the integral tests, and a small number of tests for the new distributions. After the CI/CD pipeline runs and produces a code report, we can understand if we need more.
After this update
I do not know what I'll do next after this pull request, if I have more time I might design a system to generate the data in src/data from files using CMake, this would allow easier expansion of the databases.
A few suggestions for other small improvements:

std::string_view and std::array could be used to allow the stored data to live in static storage, potentially increasing cache friendliness(?) and reducing allocations(?) (should be benchmarked, however, not using std::string will surely reduce the number of allocated memory).
Clang tidy could be integrated in the CI/CD pipeline, together with some modernize FIXITs, so that we can instantly get some refactorings such as trailing return types without much effort. Code quality will also increase as we are going to increase the amount of warnings that can be checked.

Bugfixes & Refactors
there previously was a malicious cast in the Helper.h class, instead of fixing just that, I refactored it to use the modern std::span interface, this allows our library to sample elements not just from std::vectors, but from stacks, lists, C style arrays, and more!
There is a disadvantage, since template deduction can't both construct a span and deduce the element type at the same time, the user is now required to specify what type is contained into the container that is being passed to ArrayElement, I find it quite redundant and a bit verbose, so I am going to point this out.
In conclusion the change massively increases the flexibility of the library, but introduces a bit more verbosity in the mix.


Convert alias to username in OrgDetailsFetcher

AuthInfo.create() works with username only

Codecov Report

Merging #630 (1356599) into develop (a639fde) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 1356599 differs from pull request most recent head 7f20eef. Consider uploading reports for the commit 7f20eef to get more accurate results

@@           Coverage Diff            @@
##           develop     #630   +/-   ##
========================================
  Coverage    64.46%   64.46%
========================================
  Files           43       43
  Lines         1424     1424
  Branches       245      245
========================================
  Hits           918      918
  Misses         506      506

Continue to review full report at Codecov.

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


Checks are executed in different order on subsequent runs

Execution of dashboard-linter lint <dashboards.json>
prints output of checks executed in different order all the time.

Hi, I would be interested in working on a fix for this. I have already opened a PR for it.


sdl_viewer: Single layer of a terrain drawer

This struct encapsulates a terrain texture that gets updated as the camera moves. That is, it ties together loading incremental texture data (TiledTextureLoader) and updating it on the OpenGL side (GlMovingWindowTexture).
A terrain drawer might involve several layers – for visualizing several patches of terrain at once, or multilevel terrain (overpasses). Hence, this struct also includes uniforms that are set on a per-layer basis: each layer might have a different frame, resolution, etc.

ptal @krzesi-mir


Parse server error responses

- What I did
Parse JSON server responses in at_lookup

Parsing the error responses are deferred to next releases. Hence closing the PR.


Caveats

When I play the anime OST (Original Soundtrack) in Safari macOS, I get message from YouTube: "Sign in to confirm that you're not a bot. This helps protect our community."

This site relies on YouTube Iframe API and I just know this problem today. It's uncomfortable and annoying. It looks like YouTube change the policy so you must login in order to play the YouTube video via YouTube Iframe API. I have login to my YouTube account in the same browser and same window but I still get that message. I see other GitHub repositories that have the similar issue with me and they have. The root problem is the user cookie. The current solutions are:

Switch to another browser like Firefox or Chrome
Use YouTube No Cookie.

Related issue: https://github.com/imputnet/cobalt/issues/551

Maybe I need this in the future:
https://medium.com/@mihauco/youtube-iframe-api-without-youtube-iframe-api-f0ac5fcf7c74
https://github.com/mihauco/youtube-iframe-ctrl

Maybe I need this in the future:
https://medium.com/@mihauco/youtube-iframe-api-without-youtube-iframe-api-f0ac5fcf7c74
https://github.com/mihauco/youtube-iframe-ctrl

Nope! This doesn't work! I still get the message: "Sign in to confirm that you're not a bot. This helps protect our community."

The brutal solution: Download the YouTube video => Convert it to MP3. Done!


[Excel[ (Data types) Add valueAsJson note

Docs Build status updates of commit 2a9165e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/excel/excel-data-types-concepts.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 2670650:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/excel/excel-data-types-concepts.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit a96ef54:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/excel/excel-data-types-concepts.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Fix broken link in example.

Great package!
Found this little misstake and fixed it. :smile:

Thanks!


Problems with test containers after Postgres/DB upgrade

Current Behaviour

I get the following error when I run tests without restarting the containers:

Starting test_mc_1 ... done
Exit: Command failed: docker exec test_cvat_server_1 python manage.py loaddata /tmp/data.json.
Error message: WARNING:root:Failed to import module 'datumaro.plugins.tf_detection_api_format.converter': Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'tensorflow'

Traceback (most recent call last):
  File "/opt/venv/lib/python3.8/site-packages/django/db/backends/base/base.py", line 219, in ensure_connection
    self.connect()
  File "/opt/venv/lib/python3.8/site-packages/django/utils/asyncio.py", line 33, in inner
    return func(*args, **kwargs)
  File "/opt/venv/lib/python3.8/site-packages/django/db/backends/base/base.py", line 200, in connect
    self.connection = self.get_new_connection(conn_params)
  File "/opt/venv/lib/python3.8/site-packages/django/utils/asyncio.py", line 33, in inner
    return func(*args, **kwargs)
  File "/opt/venv/lib/python3.8/site-packages/django/db/backends/postgresql/base.py", line 187, in get_new_connection
    connection = Database.connect(**conn_params)
  File "/opt/venv/lib/python3.8/site-packages/psycopg2/__init__.py", line 127, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
psycopg2.OperationalError: FATAL:  database "cvat" does not exist

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "manage.py", line 21, in <module>
    execute_from_command_line(sys.argv)
  File "/opt/venv/lib/python3.8/site-packages/django/core/management/__init__.py", line 419, in execute_from_command_line
    utility.execute()
  File "/opt/venv/lib/python3.8/site-packages/django/core/management/__init__.py", line 413, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/opt/venv/lib/python3.8/site-packages/django/core/management/base.py", line 354, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/opt/venv/lib/python3.8/site-packages/django/core/management/base.py", line 398, in execute
    output = self.handle(*args, **options)
  File "/opt/venv/lib/python3.8/site-packages/django/core/management/commands/loaddata.py", line 77, in handle
    with transaction.atomic(using=self.using):
  File "/opt/venv/lib/python3.8/site-packages/django/db/transaction.py", line 189, in __enter__
    if not connection.get_autocommit():
  File "/opt/venv/lib/python3.8/site-packages/django/db/backends/base/base.py", line 389, in get_autocommit
    self.ensure_connection()
  File "/opt/venv/lib/python3.8/site-packages/django/utils/asyncio.py", line 33, in inner
    return func(*args, **kwargs)
  File "/opt/venv/lib/python3.8/site-packages/django/db/backends/base/base.py", line 219, in ensure_connection
    self.connect()
  File "/opt/venv/lib/python3.8/site-packages/django/db/utils.py", line 90, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "/opt/venv/lib/python3.8/site-packages/django/db/backends/base/base.py", line 219, in ensure_connection
    self.connect()
  File "/opt/venv/lib/python3.8/site-packages/django/utils/asyncio.py", line 33, in inner
    return func(*args, **kwargs)
  File "/opt/venv/lib/python3.8/site-packages/django/db/backends/base/base.py", line 200, in connect
    self.connection = self.get_new_connection(conn_params)
  File "/opt/venv/lib/python3.8/site-packages/django/utils/asyncio.py", line 33, in inner
    return func(*args, **kwargs)
  File "/opt/venv/lib/python3.8/site-packages/django/db/backends/postgresql/base.py", line 187, in get_new_connection
    connection = Database.connect(**conn_params)
  File "/opt/venv/lib/python3.8/site-packages/psycopg2/__init__.py", line 127, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
django.db.utils.OperationalError: FATAL:  database "cvat" does not exist

.
Add `-s` option to see more details
! _pytest.outcomes.Exit: Command failed: docker exec test_cvat_server_1 python manage.py loaddata /tmp/data.json.

It worked without an issue prior to the DB upgrade. Container startup takes time, and the old workflow was saving it.
Steps to Reproduce (for bugs)

Start the tests normally (pytest tests/python)
Repeat

Your Environment

Git hash commit (git log -1): 4fdac637394a03d5be8c40e03c86a3a49f6b9546
Docker version docker version (e.g. Docker 17.0.05):
Are you using Docker Swarm or Kubernetes?
Operating System and version (e.g. Linux, Windows, MacOS):
Code example or link to GitHub repo or gist to reproduce problem:
Other diagnostic information / logs:
Logs from `cvat` container

@zhiltsov-max , what it fixed? What is the next step with the issue?

No, the tests still fail to launch if the containers are running.


issue-612 [Disk Manager] calculate milestone better for disk source

When transfering from disk to disk, milestone might not be updated properly. Namely, if blockMask returned by GetChangedBlocks is zero, milestone will not be updated. So the progress might be forgotten and we might make the send the GetChangedBlocks request again.
This happens because milestone is calculated in inflight queue, but is case of zero blockMask nothing is sent to inflight queue. That's why the queue does not know that progress happened. Consequently, if there are no inflight items in queue, milestone might be too old.
As a solution, I propose the way to hint inflight queue which milestone to use if there are no inflight items. Namely, the source may call UpdateDefaultMilestoneValue method. If the source calls this method with some value v, it promises that it will not send values less then v to the queue anymore.
Also I added a test that timeouts without this fix and works ok with this fix.
After this fix we will be able to change back nemesis restart timeouts https://github.com/ydb-platform/nbs/pull/361

ты забыл прилинковать issue:
https://github.com/ydb-platform/nbs/issues/612


Functional Hook APIs

Is your feature request related to a problem? Please describe.

When tapping a hook that provides an abstract data type, we may only care about a specific implementation. A simple early return allows us to "filter" out types we don't care about:
interface Super

class A : Super
class B : Super

val hook: SyncHook<(Super) -> Unit>
hook.tap(name) { super ->
    if (super !is A) return@tap

    // ...
}

Describe the solution you'd like
It'd be awesome to have functional methods for hooks, such that we can patternize filtering, data manipulation, etc.
hook.filterIsInstance<A>().tap(name) { a ->
    // ...
}

Describe alternatives you've considered
Tapping can effectively be thought of as collecting. Maybe it's worth adopting similar terminology? Probably not. Maybe a conversion layer to Flows would solve better than trying to coerce hooks as a Flow-like data type.
Additional context
This is somewhat difficult to consider for the more complex hook types, since return value is more important. We'd want to ensure we have appropriate handling for each hook type, or not support certain hook types at all.

only process the taps that qualify?

Conceptually, yes - but we'd need to tap to process the hook value for filter or map or w/e. So, for instance, if I try to filter on waterfall hook value, if it doesn't match the filter, I'd need to return the incoming value from the filter method.

tapIsInstance

I don't really see why not, but the idea is to mirror collection or flow-like APIs that already exist. Collapsing a few into a singular tap convenience would definitely be in scope.


Fix sparse updates for optimizers using DecoupledWeightDecay.

As mentioned by @yym-ustc in the original pull request #17438, there was a bug in the sparse update.
Ping @alextp who reviewed #17438.

I don't think the keras test failures are related to this pull request?

They are unrelated; we need to retry
On Wed, Aug 22, 2018 at 12:44 PM Phil<EMAIL_ADDRESS>wrote:

I don't think the keras test failures are related to this pull request?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/pull/21789#issuecomment-415154805,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAATxW8rFHIY96rS04XK2a0YHxBaRBj6ks5uTbSigaJpZM4WHPW2
.

--

Alex


Fix deprecated C++ pub/sub functions

The txt/bin_pub and bin_sub functions are now provided as inlined
functions in the C++ interface only.
They were not used in the new C-based interface anyway and deprecation
of the C interface caused warnings even if the functions were not used
by the application anymore, as they were always called by the C++ shim
layer.
Unit-tests for the deprecated functions had to be removed because they
can only use the C interface.

Thanks for the review.


feat: add test cleanup to report

Explanation
Add test cleanup to report.

/cherry-pick release-0.2


Nooder website protection and optimization

Hello,
I am from Nooder, a website security company, we would like you to add our service in detection.
Our ip range is <IP_ADDRESS>/24

@f14stelt - Detection is not based on IPs. Please look at this https://www.wappalyzer.com/docs/dev/specification and best way to get added is to submit a PR

@f14stelt - You should look at this https://github.com/AliasIO/wappalyzer/issues/3226. If Nooder is like other companies mentioned in this issue, you can add to the list

Doing it


Undefined offset: 1

When i am trying to run a simple test convert i get this ERROR:
Undefined offset: 1

in /home/mat-ugly/webserver/sites/projecty/vendor/imanilchaudhari/yii2-currency-converter/Provider/YahooApi.php at line 37
282930313233343536373839
 $ch = curl_init();
 $timeout = 0;
 curl_setopt($ch, CURLOPT_URL, $url);
 curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
 curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)');
 curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, $timeout);
 $rawdata = curl_exec($ch);
 curl_close($ch);

 return explode(',', $rawdata)[1];

}
}

@matlae-ugly As of recent changes on Yahoo Terms of Service, the service is being discontinued.
That is, Yahoo provider doesn't work any more. Please use other providers for now.
We'll be removing the deprecated provider soon from code and documentation. Any Contribution is welcome.
https://www.yiiframework.com/extension/yii2-currency-converter#c20541


Fetch and use BS thread_pool

Instead of hard coding the header of BS::thread_pool, we now fetch the implementation. Done for cudf in https://github.com/rapidsai/cudf/pull/16210.

/merge


Added multinomial logistic regression

@timothyb0912 @hassanobeid1994 whenever yall have a change, can you take a quick look at this?

@timothyb0912 I made the changes bro. Check it out.

@bouzaghrane feel free to merge this if there are no other issues to be addressed here.

@bouzaghrane: Please merge or close...


PX4 package depends on mav_msgs

It already uses it in the cmakelists, but was missing a dependency in the package.xml.

Thanks!


Logging improvements to diagnose Rinkeby deadlock

Logging improvements: Caveman debugging is often a superior technique when trying to suss out concurrency issues. We should prepare a build for running on rinkeby that offers:

Thread names included in logging output. Pretty sure this is already done.
More descriptive names for threads if possible. Would be helpful to identify block handling threads from peer handling threads as just an example.
Analysis on what packages are likely to contribute to the concurrency problem, and make sure they are turned up to DEBUG or TRACE on any nodes we are monitoring for the problem.
Addition of more logging statements directly in the code. Of most interest would be anything we think would notify a parked thread.

We can close this, since the Rinkeby issue is now solved, it was not due to a deadlock, but to some block sync issues, and improved logs were added to solve those issues


Start the problem

librealsense
2.48.0 RELEASE

OS
Windows10

Intel RealSense Viewer / Depth Quality Tool has crashed with the following error message:
GL_INVALID_VALUE - C:\jenkins_sys_rsbuild\workspace\LRS_windows_compile_pipeline\common\opengl3.cpp:569

Hi @Yarong-zhang   Please continue the discussion about the same question that you have created in https://github.com/IntelRealSense/librealsense/issues/9673
Closed as duplicate of https://github.com/IntelRealSense/librealsense/issues/9673