Correct location for libatomic_ops.a when using --with-libatomic=[dir]

Proposed changes
Compiling Nginx with --with-libatomic=[dir] fails with an error. File libatomic_ops.a is not found at $NGX_LIBATOMIC/src/libatomic_ops.a.
The location of libatomic_ops.a reportedly changed in libatomic_ops v7.4.0, according to the library maintainer @ivmai - please refer to:
https://github.com/ivmai/libatomic_ops/issues/35#issuecomment-382466032
This PR changes the location of libatomic_ops.a to reflect the changes in libatomic_ops. An interim workaround is to symlink $NGX_LIBATOMIC/src/libatomic_ops.a to $NGX_LIBATOMIC/src/.libs/libatomic_ops.a

You should squash the two commits into one


XRootD backend for origin

As part of testing the Denver cache (recently converted to Pelican), Fabio noticed that the origin at FNAL is not working.  It turns out FNAL isn't actually running an origin packaged by XRootD but a custom setup (containing no HTTP support) that redirects the cache to a separate XRootD server (also not supporting XRootD).  Thus, it totally breaks when converting the cache to Pelican.
We should add a new backend (alongside POSIX, S3, and generic HTTP) that supports XRootD; we could then point this directly to the upstream FNAL dCache.
From the XRootD documentation, we'd need something like this:
pss.origin data.fnal.gov
ofs.osslib libXrdPss.so

(but none of the XCache/pfc directives).  The configuration should require a hostname, will only work with non-authenticated origins, and cannot do arbitrary remaps.  That is, we can't do the equivalent of -v /foo:/bar; we have to do -v /foo:/foo.
Marking as critical as it blocks the full transition of caches.

@bbockelm, as I work on this, do you know of an XRootD Origin configuration I can use for testing? Or perhaps FNAL has a public namespace with a few smallish objects I can use? I'm not sure how I'll determine whether I've hit the mark otherwise.

(Sample file & endpoint were sent to @jhiemstrawisc out-of-band)

Closed by #1285


Add the option to run Dockle programmatically

When consuming Dockle as a go module, there is currently no way of running it easily.
The introduction of a public "Dockle CLI creator" will enable that

@tomoyamachi  what is the status of this PR?
can someone from the core contributors check it?


Ensure that account info address is not in an account

Problem
Summary of Changes
Fixes #

This check will become unreachable I think: https://github.com/anza-xyz/agave/blob/77789fc8bc68f262c17909d72420fb58a716061a/programs/bpf_loader/src/syscalls/cpi.rs#L324

This check will become unreachable I think:
https://github.com/anza-xyz/agave/blob/77789fc8bc68f262c17909d72420fb58a716061a/programs/bpf_loader/src/syscalls/cpi.rs#L324
Because SolAccountInfo::data_len is not indirect, it is embedded in the array. Thus, if the entire array is checked in this PR, then the data len check in the C variant of the invoke syscall will be redundant.

I agree, nice catch. Removed.

how was the test not failing on this tho then if you were putting SolAccountInfos inside accounts?

The test is working on sol_invoke_signed_rust() which uses AccountInfo, sol_invoke_signed_c() uses SolAccountInfo.
Come to think it, let me check if we have coverage for  that.

Come to think it, let me check if we have coverage for that.

I couldn't find an explicit test, so I've added one.

@Lichtso could I have another review please, thanks


Change deviceType to 32-bit.

Device types are 32-bit in the spec.

Codecov Report

Merging #951 (0cccfcf) into master (62484df) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #951   +/-   ##
=======================================
  Coverage   62.01%   62.01%
=======================================
  Files         155      155
  Lines       16661    16661
  Branches     3687     3687
=======================================
  Hits        10333    10333
  Misses       5627     5627
  Partials      701      701

Impacted Files
Coverage Δ

...n/simulated-clusters/clusters/DiscoveryCommands.js
100.00% <ø> (ø)

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


(CPU) Performance tracker for LLaMa2 prefill inference step

This issue is meant to track the IREE-side performance burndown of the prefill step of quantized (int4) LLaMA2 inference on CPU.
download llama2_7b_int4_cpu.vmfb
download llama2_7b_int4.mlir
Compile Command:
iree-compile --iree-input-type=none --iree-vm-bytecode-module-output-format=flatbuffer-binary --iree-hal-target-backends=llvm-cpu --mlir-print-debuginfo --mlir-print-op-on-diagnostic=false --iree-llvmcpu-target-cpu-features=host --iree-stream-resource-index-bits=64 --iree-vm-target-index-bits=64 --iree-vm-bytecode-module-strip-source-map=false --iree-util-zero-fill-elided-attrs --iree-vm-target-truncate-unsupported-floats --iree-codegen-check-ir-before-llvm-conversion=false --iree-opt-const-expr-hoisting=false  --iree-consteval-jit-debug=true --iree-stream-resource-max-allocation-size=3221225472 llama2_7b_int4.mlir -o llama2_7b_int4_cpu.vmfb

The first_vicuna_forward call runs in less than a few seconds when the input is small, i.e., 1x1xi64, but in actual use cases where it's passing in a chat history those key values can be much larger, i.e. 1x141xi64, and in that case the first_vicuna_forward performance regresses significantly. For example, with the following command, we observe a near inverse linear trend with the length of the second dimension of the inputs and forward pass latency.
Run first_vicuna_forward with 1x1 inputs:
iree-benchmark-module --module=llama2_7b_int4_cpu.vmfb --device=local-task --function=first_vicuna_forward --input=1x1xi64

Result:

BM_first_vicuna_forward/process_time/real_time       2321 ms        11344 ms            1 items_per_second=0.430939/s

Tracy Profile (1x1)

Run first_vicuna_forward with 1x16 inputs:
iree-benchmark-module --module=llama2_7b_int4_cpu.vmfb --device=local-task --function=first_vicuna_forward --input=1x16xi64

Result:

BM_first_vicuna_forward/process_time/real_time      33641 ms       255438 ms            1 items_per_second=0.0297254/s

Tracy Profile (1x16)

Run first_vicuna_forward with 1x256 inputs:
iree-benchmark-module --module=llama2_7b_int4_cpu.vmfb --device=local-task --function=first_vicuna_forward --input=1x256xi64

Result:

BM_first_vicuna_forward/process_time/real_time     539361 ms      4257031 ms            1 items_per_second=1.85405m/s

Tracy Profile (1x256)

Here is the IR from the dump after all for the three dispatches
Dispatch1: https://gist.github.com/MaheshRavishankar/55eda86d2fe17a2f190c306c2fea2ee8
Dispatch2 : https://gist.github.com/MaheshRavishankar/1917559881eb5f18f497e5bb3eeda504
Dispatch3 : https://gist.github.com/MaheshRavishankar/c56f43721a58e6f440b57f970dcaba1e

cc @dcaballe any inputs on any of these (especially the second example in https://github.com/openxla/iree/issues/15091#issuecomment-1744201873)

You should be able to just use a vector.broadcast %.. vector<8x8xf16> to vector<8x8x32xf16> instead of the transpose....

What sequence of LLVM instructions do you expect will implement that ?
In the absence of HW-specific custom intrinsics (that don't exist for such shapes), what other options do we have in LLVM than extracting one element at a time, broadcasting it to 32 and inserting back to the target position?
This is no different than 64-unrolled, 1-element broadcast to vector<32xf16> and manipulating those: this will blow up your registers with spills.

This is no different than 64-unrolled, 1-element broadcast to vector<32xf16> and manipulating those: this will blow up your registers with spills.

Note that on certain targets (e.g. AVX-512), isel may fold you back to special instructions that broadcast-load-and-fma but I wouldn't expect this to be portable at all.

Posting an update here. I hadnt looked closely, but all the dispatches are actually similar to the fused group quantized matmul sequences that we've been looking at for a while. When I looked earlier, I was looking past the Rematerialization stage, which confused me.
Here is the first dispatch compiled as a standalone example
https://gist.github.com/MaheshRavishankar/f424b55347bf87c42c3ab221b43dd710
Here is the second dispatch compiled as a standalone example
https://gist.github.com/MaheshRavishankar/52ef430409c1f49a68b6a2bd2948459a
Current ToT numbers
Size = 16:

Benchmark
Time
CPU
Iterations
UserCounters

BM_first_vicuna_forward_dispatch_26_generic_Dx4096x86x128_f16/process_time/real_time
587 ms
3995 ms
1
items_per_second=1.70354/s

BM_first_vicuna_forward_dispatch_23_generic_Dx11008x32x128_f16/process_time/real_time
141 ms
999 ms
5
items_per_second=7.06762/s

Size 256

Benchmark
Time
CPU
Iterations
UserCounters

BM_first_vicuna_forward_dispatch_26_generic_Dx4096x86x128_f16/process_time/real_time
7685 ms
61416 ms
1
items_per_second=0.130128/s

BM_first_vicuna_forward_dispatch_23_generic_Dx11008x32x128_f16/process_time/real_time
1800 ms
14267 ms
1
items_per_second=0.555685/s

Based on what was seen with the decode step, I made the following changes (and pushed it to this branch https://github.com/MaheshRavishankar/iree/tree/dequantized_matvec_fix)

Set the lowering_config for the  dispatches that have fused grouped quantized matmul
Make sure the bitcast -> extui folding patterns kick in.

With these the compilation looks much better

Dispatch 1 dump after all : https://gist.github.com/MaheshRavishankar/6b0689d72eb8ba8001dd7ace13e9949
Dispatch 2 dump after all : https://gist.github.com/MaheshRavishankar/81b6c00dff65d057f830f0db950addb7

Size = 16:

Benchmark
Time
CPU
Iterations
UserCounters

BM_first_vicuna_forward_dispatch_26_generic_Dx4096x86x128_f16/process_time/real_time
105 ms
836 ms
6
items_per_second=9.48058/s

BM_first_vicuna_forward_dispatch_23_generic_Dx11008x32x128_f16/process_time/real_time
118 ms
845 ms
6
items_per_second=8.47351/s

Size 256 :

Benchmark
Time
CPU
Iterations
UserCounters

BM_first_vicuna_forward_dispatch_26_generic_Dx4096x86x128_f16/process_time/real_time
1752 ms
13324 ms
1
items_per_second=0.570656/s

BM_first_vicuna_forward_dispatch_23_generic_Dx11008x32x128_f16/process_time/real_time
1691 ms
13478 ms
1
items_per_second=0.591517/s

There is definitely some improvement here. But I dont think this is enough. I also realized that the time of 105 ms - 118 ms for Size = 16 is consistent with what we were seeing earlier.
Ill run the whole model and post numbers (one of my changes here seems to introduce a segfault... I am triaging that)

Full model numbers
Main ToT:

Size
Time
CPU

1
2325 ms
18177 ms

16
35076 ms
277517 ms

With https://github.com/MaheshRavishankar/iree/tree/dequantized_matvec_fix

Size
Time
CPU

1
1232 ms
9397 ms

16
18708 ms
18708 ms

So thats about 2X, but still ways to go.

Posting an update here. I hadnt looked closely, but all the dispatches are actually similar to the fused group quantized matmul sequences that we've been looking at for a while. When I looked earlier, I was looking past the Rematerialization stage, which confused me.
Here is the first dispatch compiled as a standalone example https://gist.github.com/MaheshRavishankar/f424b55347bf87c42c3ab221b43dd710
Here is the second dispatch compiled as a standalone example https://gist.github.com/MaheshRavishankar/52ef430409c1f49a68b6a2bd2948459a
Current ToT numbers Size = 16:
Benchmark	Time	CPU	Iterations	UserCounters
BM_first_vicuna_forward_dispatch_26_generic_Dx4096x86x128_f16/process_time/real_time	587 ms	3995 ms	1	items_per_second=1.70354/s
BM_first_vicuna_forward_dispatch_23_generic_Dx11008x32x128_f16/process_time/real_time	141 ms	999 ms	5	items_per_second=7.06762/s
Size 256
Benchmark	Time	CPU	Iterations	UserCounters
BM_first_vicuna_forward_dispatch_26_generic_Dx4096x86x128_f16/process_time/real_time	7685 ms	61416 ms	1	items_per_second=0.130128/s
BM_first_vicuna_forward_dispatch_23_generic_Dx11008x32x128_f16/process_time/real_time	1800 ms	14267 ms	1	items_per_second=0.555685/s
Based on what was seen with the decode step, I made the following changes (and pushed it to this branch https://github.com/MaheshRavishankar/iree/tree/dequantized_matvec_fix)

Set the lowering_config for the  dispatches that have fused grouped quantized matmul
Make sure the bitcast -> extui folding patterns kick in.

With these the compilation looks much better

Dispatch 1 dump after all : https://gist.github.com/MaheshRavishankar/6b0689d72eb8ba8001dd7ace13e9949
Dispatch 2 dump after all : https://gist.github.com/MaheshRavishankar/81b6c00dff65d057f830f0db950addb7

Size = 16:
Benchmark	Time	CPU	Iterations	UserCounters
BM_first_vicuna_forward_dispatch_26_generic_Dx4096x86x128_f16/process_time/real_time	105 ms	836 ms	6	items_per_second=9.48058/s
BM_first_vicuna_forward_dispatch_23_generic_Dx11008x32x128_f16/process_time/real_time	118 ms	845 ms	6	items_per_second=8.47351/s
Size 256 :
Benchmark	Time	CPU	Iterations	UserCounters
BM_first_vicuna_forward_dispatch_26_generic_Dx4096x86x128_f16/process_time/real_time	1752 ms	13324 ms	1	items_per_second=0.570656/s
BM_first_vicuna_forward_dispatch_23_generic_Dx11008x32x128_f16/process_time/real_time	1691 ms	13478 ms	1	items_per_second=0.591517/s
There is definitely some improvement here. But I dont think this is enough. I also realized that the time of 105 ms - 118 ms for Size = 16 is consistent with what we were seeing earlier.
Ill run the whole model and post numbers (one of my changes here seems to introduce a segfault... I am triaging that)
@bjacob I think this is getting to the stage where it would be useful to see whether there are some inefficiencies creeping into the final generated assembly. Could you please take a look (use the branch with my fixes here https://github.com/MaheshRavishankar/iree/tree/dequantized_matvec_fix ).

Compile/Run commands for the two dispatches here
Dispatch 1:
iree-compile --iree-hal-target-backends=llvm-cpu --iree-llvmcpu-target-cpu-features=host dispatch1.mlir -o dispatch1.vmfb
SIZE=16 iree-benchmark-module --device=local-task --function=first_vicuna_forward_dispatch_26_generic_Dx4096x86x128_f16 --module=dispatch1.vmfb --input=4096x86xf16=1.0 --input=4096x86xf16=1.0 --input=${SIZE}x86x128xf16=1.0

(you can change SIZE to increase the problem size, but change in SIZE doesnt need recompile)
Dispatch 2:
iree-compile --iree-hal-target-backends=llvm-cpu --iree-llvmcpu-target-cpu-features=host dispatch2.mlir -o dispatch2.vmfb
SIZE=16 iree-benchmark-module --device=local-task --function=first_vicuna_forward_dispatch_23_generic_Dx11008x32x128_f1 --module=dispatch2.vmfb --input=11008x32xf16=1.0 --input=11008x32xf16=1.0 --input=${SIZE}x32x128xf16=1.0

Ok, so based on @Max191 suggestion, using f32 instead of f32, makes the whole problem go away. Here are ToT numbers
Current ToT numbers
Size = 16:

Benchmark
Time
CPU

BM_first_vicuna_forward_dispatch_26_generic_Dx4096x86x128_f16/process_time/real_time
193 ms
1041 ms

BM_first_vicuna_forward_dispatch_23_generic_Dx11008x32x128_f16/process_time/real_time
52.5 ms
374 ms

Size 256

Benchmark
Time
CPU

BM_first_vicuna_forward_dispatch_26_generic_Dx4096x86x128_f16/process_time/real_time
2040 ms
16155 ms

BM_first_vicuna_forward_dispatch_23_generic_Dx11008x32x128_f16/process_time/real_time
789 ms
5623 ms

With this branch https://github.com/MaheshRavishankar/iree/tree/dequantized_matvec_fix
Size = 16:

Benchmark
Time
CPU

BM_first_vicuna_forward_dispatch_26_generic_Dx4096x86x128_f16/process_time/real_time
12 ms
86.8 ms

BM_first_vicuna_forward_dispatch_23_generic_Dx11008x32x128_f16/process_time/real_time
13 ms
91.4 ms

Size 256

Benchmark
Time
CPU

BM_first_vicuna_forward_dispatch_26_generic_Dx4096x86x128_f16/process_time/real_time
160 ms
1270 ms

BM_first_vicuna_forward_dispatch_23_generic_Dx11008x32x128_f16/process_time/real_time
160 ms
1266 ms

using f32 instead of f32, makes the whole problem go away

and the student was enlightened

using f32 instead of f32, makes the whole problem go away

and the student was enlightened

Haha! Fixed.

Full model numbers with F32.
ToT Main

Size
Time
CPU

1
202 ms
1384 ms

16
2168 ms
16816 ms

With https://github.com/MaheshRavishankar/iree/tree/dequantized_matvec_fix

Size
Time
CPU

1
202 ms
9397 ms

16
2168 ms
18708 ms

256
33389 ms
266303 ms

So basically f32 on ToT would already help.


Figure out Twilio XML format

To reach MVP status, the next thing to do would be making the Twilio XML get request work properly, with the MVC code required to do that. Then we can make the calendar.

Bah, says me:
https://github.com/twilio/twilio-ruby

Or you could make a tiny xml app, and use that: https://www.twilio.com/labs/twimlets

Twilio Ruby is, in my mind, almost overkill if you're not making outgoing API requests.  All you really need is a view something like:
<?xml version="1.0" encoding="UTF-8"?>
<Response>
    <Dial timeout="10"><%= @current_on_call_number %></Dial>
</Response>

to just forward phone calls. Text messages are only a little bit more complicated.
Twimlets are secretly just php scripts where Twilio is doing the hosting for you.

Correction: Twimlets are not 'xml apps'. I had XML on the brain. Yes totally, I was just hanging on the 'not hosted by us' part. Further, we need number to be dynamically chosen by the schedule. Got 'cha.

Ref: https://www.twilio.com/docs/api/twiml/dial

Maybe it'd be worth having calls and texts come from a number that we can save in our contacts, so that we know that incoming calls/texts are for on-call reasons?

https://github.com/umts/garrulous-garbanzo/commit/1edae8ae0410ca805cb530b2fc970a571ea3acad

I exposed my dev environment using ngrok, set up a Twilio trial account, and made a test call and SMS which were forwarded correctly. :smile:


Secret Env Not available, container couldn't start

From @pixeleet on February 14, 2017 9:13

25m       15h       9         api-cmd-4281948355-qecb1   Pod       spec.containers{api-cmd}   Normal    Pulling      {kubelet ip-10-0-10-170.eu-central-1.compute.internal}   pulling image "bannerwise/core:production-735dd428f31808e52bd422e6e54f5d78bddde289"
25m       15h       9         api-cmd-4281948355-qecb1   Pod       spec.containers{api-cmd}   Normal    Pulled       {kubelet ip-10-0-10-170.eu-central-1.compute.internal}   Successfully pulled image "bannerwise/core:production-735dd428f31808e52bd422e6e54f5d78bddde289"
25m       31m       8         api-cmd-4281948355-qecb1   Pod                                  Warning   FailedSync   {kubelet ip-10-0-10-170.eu-central-1.compute.internal}   Error syncing pod, skipping: failed to "StartContainer" for "api-cmd" with RunContainerError: "GenerateRunContainerOptions: secrets \"api-v115-env\" not found"

What happens is, one of my containers died, a new machine which hasn’t pulled the image yet tried to pull but it somehow didn’t have the latest env secret and thus the container could not start, eventually this resulted in all api containers being not available, still investigating why but if you know something please let me know :stuck_out_tongue: It’s an annoying little thing happening every now and then and I till can’t put my finger on it
Kube version
Server Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.4", GitCommit:"dd6b458ef8dbf24aff55795baa68f83383c9b3a9", GitTreeState:"clean", BuildDate:"2016-08-01T16:38:31Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"}

Deis version
v2.4.0

Cloud Provider: AWS
4.7.3-coreos-r2
Copied from original issue: deis/workflow#736

From @bacongobbler on March 28, 2017 19:58
@pixeleet can you please try upgrading to something more recent like v2.13.0? There have been plenty of significant changes/bugfixes in the last 11 months and we haven't seen this in recent versions. I'm inclined to think this is long past, and I'd try upgrading first.

From @bacongobbler on March 28, 2017 19:59
Sorry this ticket fell through the cracks, by the way. We do appreciate the bug report!

From @pixeleet on March 28, 2017 20:2
Sure, already put upgrading to the latest and greatest deis on the roadmap.
It's rarely occuring anyway.
On Tue, 28 Mar 2017 at 21:59, Matthew Fisher<EMAIL_ADDRESS>wrote:

Sorry this ticket fell through the cracks, by the way. We do appreciate
the bug report!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/deis/workflow/issues/736#issuecomment-289886394, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFgmZVbKSWOogw8xNTbhEHutTIJdI5vzks5rqWaMgaJpZM4MAOfX
.


Allow a single mouse drag across the EQ to set all values

In WinAMP you could mouse down on the first EQ VerticalSlider and drag the mouse across all of the VerticalSliders to set them all in one swipe. This PR brings the same capability to WebAMP.

Done

When switching the prop to requireClicksOriginateLocally, the WinampButton is giving the warning:

Warning: React does not recognize the requireClicksOriginateLocally prop on a DOM element. If you intentionally want it to appear in the DOM as a custom attribute, spell it as lowercase requireclicksoriginatelocally instead. If you accidentally passed it from a parent component, remove it from the DOM element.
If we lowercase the parameter and use it on the JSX.Element component, we are going to need the parameter to be a string and not boolean for it to be happy. So, we probably want to refactor WinampButton to return a standard React functional component and not return a JSX.Element. I'm not sure if you had specific reasons for doing this component in this way. What do you suggest I should do here?

Adding support for touch is going to be a bit more tricky.

touchmove event target is always the same element which started the touch, so if we touch on band 1000 and move over other EQ bands, the event only continues to fire on the original element.
W3C added and subsequently removed touchenter and touchleave events, which would have made this nice and clean, but we do not have those available.
https://www.w3.org/TR/2011/WD-touch-events-20110505/ old
https://www.w3.org/TR/touch-events/#list-of-touchevent-types current
We are probably going to need to track touchmove on the parent component (containing all the EQ bands), and if the x,y coordinates match the child element, to activate change in the children. I’m up for the challenge to give it a try, but it will take a bit longer to get through this and get the code clean and efficient. I made some initial efforts but things started to get a bit hairy. I’m thinking a follow up PR might be in order unless you feel strongly to wait for both to roll this out.

Got touch working with technique 3, with most of the code living in EqualizerWindow/index.tsx. Going to sit and stare at it for a bit.

Related to Touch: I noticed a bug where if you touch the EQ, then the next subsequent touch on button like stop, play, will not work the first time you touch it. To repro: Touch Play. Touch Stop. Touch the EQ. Touch Play. It will not play, until you touch it a second time. I tested this on winamp.org and seeing the bug there so it appears to be unrelated to this PR.

Ready for review. Github says "captbaritone requested changes" but I'm not sure how to ACK that or let it know the changes are done.

Looking better! One thing that's still not right though: In real Winamp, clicking outside the eq window and then dragging across the sliders does not cause the sliders to be moved. Also, clicking inside the eq window and the dragging over the preamp causes us to grab the preamp slider but we can't then glide into the band sliders.
I think I'd be happy with an abstraction that gave us a separate React component that defined an area that would capture these initial clicks. So, any click that happened in this new component or one of its children would trigger the behavior you have now, but if the click originated outside of an instance of this new component, the drags would be ignored.

Getting closer. Fixed the bug where clicking outside the EQ area and dragging across the EQ will affect the sliders. Also fixed the issue that dragging across the EQ will affect the preamp. Now the drag will only work if the click originates in the EQ area by adding a clickOriginatedInEq state.
Still have a bug where if you release way off to the side, off the WinAmp area, the clickOriginatedInEq state does not get reset. Thinking about a clean solution for that.

Working better now. Tested with mouse, pen, and touch.

Thanks for all your work on this, and most of all your patience! I've been busy with other stuff so I haven't been able to muster the focus to give timely review. Sorry for that. There are a few details to address here, but rather than go back for another round, I'll go ahead and merge this and followup with the fixes when I find time. (I'll mention you so you can see, in case you are curious or have feedback for me on why you chose to do it differently.
This is such a great detail to have right on Webamp. I really appreciate you persevering and getting it added!


Proton Setting don't save in Tertis Effects Connected

Hi! The Problem starts that Tetris first start with don't recognizing my Steamuser. Then i set Proton 7 at Compatibility, it works. But after a system restart have to go to the Settings, Compatibility , then check and uncheck. Because without that Tetris will not start and fall back to BicPicture or GampadUi. Sorry to bother you with this one title, this problem a haven't under HoloISO. (i like chimera for his slacker build). Because Blossom Tales for example works fine. My System is a Aya Neo Air.

Sounds like an issue with the Steam client.

OK. I reinstalled Chimera OS, the same behavior. Maybe there will be an update from Valve for the Client. Thank you.

After an reinstall of Chimer OS again i have started an Emulator Game first, this installs Proton 7, and then the Problem with Tetris was gone. Steamclient Version looks the same, from Dez. 22


Signed-off-by: Kevin Baichoo<EMAIL_ADDRESS>
For an explanation of how to fill out the fields, please see the relevant section
in PULL_REQUESTS.md
Commit Message: Modify the kill filter to support directionality.
Additional Description: This allows us to more easily test response crashes.
Risk Level: low (this is a test-only filter AFAIK)
Testing: unit test, integration test
Docs Changes: Included
Release Notes: Included
Platform Specific Features: N/A
Related Issue #14249
/assign @qqustc
Since you're one of the maintainers of the filter. PTAL.

/retest

/retest

@alyssawilk since you're the maintainer on-call, can you assign maintainer to review these changes? @qqustc is an extension owner and has already signed off. Thanks!

/retest


SSH connectivity issues

I recently started having issues with SSH connectivity (again, but this time also with my existing cluster) and looked into it in more detail. This may or not be a duplicate/related to #443 #415, but I wanted to document my findings in case someone else runs into similar problems.
For me the connectivity issues were a complex mix of different things that overlaid each other. All of these lead to hetzner-k3s hanging (silently) in "Waiting for successful ssh connectivity".

most importantly, I recently used a another ssh key for another project and ssh-agent provided the wrong one to hetzner-k3s => in that case, use_agent: true will ignore the configured keys and use the wrong keys and fail silently
use_agent: false: did also fail silently because the key pair was using a password (this is documented somewhere but still a caveat)
with 2.0.x, the master setup does not work out of the box for me because the hetzner firewall configuration is only created after the master has been setup, so there's no connectivity to port 22 (that's probably caused by having existing firewalls defined in hetzner cloud project)
The retry logic in hetzner-k3s hammers the ssh port with requests (~ 1/s?), so that the ssh server will by default start blocking your IP pretty quickly

Here are the workarounds I used:

with use_agent: true, use ssh-add -D, and ssh-add <key> to add the right key to the ssh agent
with use_agent: false use a key without a password (not recommended)
setup a custom firewall rule in hetzner cloud that matches on the cluster label to enable port 22 even before hetzner-k3s creates the firewall rules, using a completely clean hetzner cloud project might also work
if connecting to the server is broken from the command line as well, use a VPN, restart the server, or the sshd process on the nodes (if you can still connect via console)

My main debugging tool in the end was to log in to a node, set debug logging level in /etc/ssh/sshd_config and observe the logs during the attempts (will show blocking, wrong keys, etc).
Suggestions for hetzner-k3s:

with use_agent: true:

warn if ssh-agent provides a different key than the one declared
surface more detailed error messages from libssh2 (I tried but failed, I'm not a crystal developer)

with use_agent: false:

see 1.
explicitly warn when provided key is password protected (e.g. grep private key file for encryption headers)

Create firewall rules before/with the servers to be more resilient against existing firewall rules on the project
Be less aggressive with retries when trying to contact ssh, or fail early e.g. on auth issues

Thanks for sharing your experience!
Just to clear things up about the firewall: by default, when there's no firewall attached to a server, all ports are open. So, as long as you don't have an existing firewall blocking the selected SSH port, everything should be fine.
You're right about the SSH keys, though. That said, I create clusters regularly and haven't run into any issues with SSH connectivity yet due to keys or else.
I'll check if it's possible to use the SSH shard for Crystal to verify that the key used by the agent matches the one in your config. I'll also see if it can detect whether the key is protected by a passphrase.
Regarding the firewall, you shouldn't set up an additional one in your Hetzner project. Ideally, the project should be solely dedicated to the cluster managed by hetzner-k3s. I'll make sure this information is clearer in the docs.


[BUG] pylips dies on 55OLED754/12 (apiversion 6.1.0) because http://x.x.x.x:1925/6/activities/current does not exist

Describe the bug
The new Philips 55OLED754/12 reports as apiversion it's 6.1.0 but it does not support the /6/activites/current endpoint. This makes the use of pylips mostly impossible especially in MQTT mode which I wanted to use because it just dies because it tries to query activities as soon as the tv is in mode Powerstate "on"
To Reproduce
1.) configure mqtt settings in settings.ini
2.) start pylips in MQTT mode (so without any parameters)
3.) pylips dies as soon as it tries ti query activities
Expected behavior
there ahould at least be a possibility to skip this query or not do a fatal call Probably script should go on on every "Not Found" answer.

Thanks for the report! Do you get any kind of an error message (you might have to specify 'verbose' as True in the settings)?

Also, please attach the results of https://ip-address:1926/6/system (or http://ip-address:1925/6/system if the first does not work). Thanks!

The error is this one:
Sending GET request to http://<IP_ADDRESS>:1925/6/activities/current
Request sent!
Not FoundNot Found
Traceback (most recent call last):
  File "pylips.py.backup", line 453, in
    pylips = Pylips(os.path.dirname(os.path.realpath(__file__))+"/settings.ini")
  File "pylips.py.backup", line 97, in __init__
    self.start_mqtt_updater(self.verbose)
  File "pylips.py.backup", line 447, in start_mqtt_updater
    self.mqtt_update_app()
  File "pylips.py.backup", line 413, in mqtt_update_app
    actv_status=json.loads(actv_status)
  File "/usr/lib/python3.6/json/__init__.py", line 354, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/python3.6/json/decoder.py", line 339, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python3.6/json/decoder.py", line 357, in raw_decode
    raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
Here's the output of the /6/system output
{
"menulanguage": "German",
"name": "55OLED754/12",
"country": "Switzerland",
"serialnumber_encrypted": "K2kseVsmQFgkd15gKkJ+aqKgAW0YsiYm18R34DasGA4=",
"softwareversion_encrypted": "K2kseVsmQFgkd15gKkJ+amueMe3DHAmDQ8d/R/pbq76od3Wmqm0WSs8gfLFv0gbo",
"model_encrypted": "K2kseVsmQFgkd15gKkJ+aoVYVbm8KvlYgfINFpkYHig=",
"deviceid_encrypted": "K2kseVsmQFgkd15gKkJ+aoHwEy/f1mmf7qHz4lUYUPU=",
"nettvversion": "<IP_ADDRESS>",
"epgsource": "no_epg",
"api_version": {
"Major": 6,
"Minor": 1,
"Patch": 0
},
"featuring": {
"jsonfeatures": {
"recordings": [
"List",
"Schedule",
"Manage"
],
"ambilight": [
"Hue",
"HueStreaming",
"Ambilight"
],
"textentry": [
"context_based",
"initial_string_available"
],
"inputkey": [
"key",
"unicode"
],
"pointer": [
"context_based"
],
"activities": [
"browser"
]
},
"systemfeatures": {
"tvtype": "consumer",
"content": [
"dmr"
],
"pairing_type": "none",
"companion_screen": true,
"os_type": "Linux"
}
}
}
BTW: I commented out the call to activities and set the return value to 'None'. Then I ran into this error:
Sending POST request to http://<IP_ADDRESS>:1925/6/menuitems/settings/current
Request sent!
{
"version": 1,
"values": [
{
"value": {
                    }
            }
    ]

}
Traceback (most recent call last):
File "pylips.py.fixed_act", line 454, in
pylips = Pylips(os.path.dirname(os.path.realpath(file))+"/settings.ini")
File "pylips.py.fixed_act", line 97, in init
self.start_mqtt_updater(self.verbose)
File "pylips.py.fixed_act", line 450, in start_mqtt_updater
self.mqtt_update_ambihue()
File "pylips.py.fixed_act", line 405, in mqtt_update_ambihue
ambihue = ambihue_status["values"][0]["value"]["data"]["value"]
KeyError: 'data'
So I also had to comment out the call to the ambilight because the return value did not expect the returned json value. So I commented out this call as well in the same manner.  Would be nice to have a proper detection of this case.
PPS: The system call needs to go to port 1925 because this TV runs on Philips SAPHI OS instead of Android.
It seems that some other URLs also don't work or have changed in SAPHI. For example I can turn on/off the ambilight in the Philips TV Remote App but not in pylips.

Thanks, this is very useful!
Did not know about the SAPHI OS (it flew completely under my radar), and it seems to behave slightly differently than Android/old non-Android TVs. That's why some endpoints like activities fail (it's for Android TVs) and the errors are not handled correctly (they are different from non-Android TVs).
Since I don't have such a TV to reverse-engineer it, the best I can do for now is basically repeat your hack - e.g. just skip the endpoints that don't return the expected data. However, if you install Charles and send me the captured traffic between the TV and  Philips TV Remote App, then I'll be able to add support for SAPHI TVs.

Thanks, this is very useful!
Did not know about the SAPHI OS (it flew completely under my radar), and it seems to behave slightly differently than Android/old non-Android TVs. That's why some endpoints like activities fail (it's for Android TVs) and the errors are not handled correctly (they are different from non-Android TVs).
Since I don't have such a TV to reverse-engineer it, the best I can do for now is basically repeat your hack - e.g. just skip the endpoints that don't return the expected data. However, if you install Charles and send me the captured traffic between the TV and Philips TV Remote App, then I'll be able to add support for SAPHI TVs.

Hi! Maybe I can "help" you with this. I am a Saphi TV owner and I have no idea how to add the support for SAPHI TVs.
I guess I should install Charles on my laptop and then listen the ports of the TV. If I am wrong just tell me how to help you with this.
BTW: Thank you so much for your effort and for such a great work you made

Hey @albertomarrod,
Thanks for offering your help! To add support for SAPHI OS, I would require the following:

List of pylips commands that do not work as expected on SAPHI OS
For each of this commands, I'll need a saved Charles session with you using these commands via the Philips mobile remote app. Then I can take a look at the sent packets and reverse-engineer such commands.

If you choose to do it, please split these commands into different Charles sessions (otherwise it can be hard to figure out which request triggers which command)!

Hey @albertomarrod,
Thanks for offering your help! To add support for SAPHI OS, I would require the following:

List of pylips commands that do not work as expected on SAPHI OS
For each of this commands, I'll need a saved Charles session with you using these commands via the Philips mobile remote app. Then I can take a look at the sent packets and reverse-engineer such commands.

If you choose to do it, please split these commands into different Charles sessions (otherwise it can be hard to figure out which request triggers which command)

Hy @eslavnov,
I just start trying pylips and I am having the same issue than people on here https://github.com/eslavnov/pylips/issues/62.
I attached the issue I am getting... Maybe you will be able to help me more.
Thanks!

@albertomarrod  I had the same issue on my Saphi OS TV and the solution is to enable WoWLAN option:
Network -> Switch on with Wi-FI(WoWLAN). It comes by default off.
After that, I was able to call the API on 1925 port.


Spectral surface emission

It would be interesting to explore how spectral surface emission changes the energy balance, particularly in the context of exoplanet emission spectroscopy.
There are spectra here: https://dspace.mit.edu/handle/1721.1/74201
In SOCRATES, surface emission is calculated according to the Planck function by default, although a grey albedo can be passed. However, there are seemingly also routines for setting this spectrally. This should be explored further.

In terms of the l_run_cdf interface to the code, information on generating spectral surface albedo data is outlined on page 45 of the user guide.

See also https://github.com/nichollsh/AGNI/issues/56

No changes required in SOCRATES. Completed in https://github.com/nichollsh/AGNI/issues/56.


CB-10813. Fix: in case of cluster-proxy, the base context is missing …

…from the request url
see CB-10879 as well

please ask someone who has merge rights for 2.36 to merge this pr

please ask someone who has merge rights for 2.36 to merge this pr


What is the function of progressive encoding?

Thanks for your excellent work!
When I run your demo, I notice that the input points are sent to progressive encoding. If I disable this module, the final result dosen't change a lot. So why do we need this module?
Here is the two picture of results( promt: an image of a shoe made of cactus,  obj: shoe), the first one is WITH progressive encoding, the second one is WITHOUT progressive encoding.

Hi thanks for the kind comment and apologies for the delayed response. The progressive encoding is based on the implementation described in the SAPE paper. Our experiments also found it doesn't really change the result for a given run, but it does somewhat stabilize training to be more consistent across runs.


Add NowHug.me

This pull request adds https://nowhug.me to the list of progressive web apps.

Are you still making PWA's? Contact me please<EMAIL_ADDRESS>


[IOTDB-300]reconnection to requestStmtId when broke pip

Start the IOTDB-Client and connect to the server successfully

Restart the server side

And then if you execute any command on the client, you will receive an error message: 'MSG: cannot get ID for statement'

I will refer to the executeQuery() method of reconnection for repair.

I just encountered the same problem today and you solve it 👍

It's so nice of you to comfort me 😘


Still include Teensy Audio nodes?

It looks like I kept some of the old Teensy audio nodes and that I mingle them with my Tympan nodes.  We might not want to do this anymore.  This needs consideration.
Actually, no, let's just use Tympan nodes for now.
But don't delete the Teensy nodes, just comment them out or hide them.

Looks like I've gotten rid of them.


[USERSNAP] hello Lorenzo, does this work?

Taken at: https://preview.gov.tools/connected/governance_actions
Fields:

Add a comment: hello Lorenzo, does this work?

Browser: Chrome 127 (Windows 10)
Screen size: 1368x912
Open #107 in Usersnap
Powered by Usersnap.

It seems it does work. 😂


url call returns invalid url with S3 filesystem when path contains special characters defined in RFC 3986 2.2

Laravel Version:
PHP Version: 5.5 and Above
Database Driver & Version: n/a

Description:
When utilizing an S3 filesystem with the 'url' config parameter to specify a base URL (for example, a cloudfront distribution), it's possible the url method returns an invalid URL when the path contains special characters that are inside RFC 3986 2.2.
Steps To Reproduce:

Store a file in S3 bucket that has the '+' character in it (example: 'My+Example.jpg')
Configure a filesystem disk for S3, pointing to bucket, and specify a new base url (For example, a cloudfront disitrubtion)
Call Storage::disk('s3')->url('My+Example.jpg');
See it return the path as '/My+Example.jpg', which is an invalid S3 object uri.

Reasons for breakage
When not specifying the 'url' config parameter, the url() call calls getAwsUrl() in FilesystemAdapter. That call properly uses the AWS S3 SDK to get the Object URL which will return a valid URI to point to an S3 object, with certain characters encoded.
When specifying the 'url' config parameter, the getAwsUrl() simply concats the requests path to the url, which avoids any encoding of special characters, creating an invalid key.
Solution
The getAwsUrl() can continue to use the AWS S3 SDK to get the object url with special characters encoded and then pull the path out of the url utilizing PHP's parse_url() function, specifying to return only the URL path.  Then it can concat that path to the url configured for the disk.  Note, we should not attempt to encode the characters ourselves but instead rely on the AWS SDK to ensure we use their character encoding.
Pull Request: https://github.com/laravel/framework/pull/37160
See Also

https://tools.ietf.org/html/rfc3986#section-2.2
https://forums.aws.amazon.com/thread.jspa?threadID=55746

Looks like Taylor rejected the pr for this.


[DO NOT MERGE] Use get_user instead of user_info to avoid missing identities

Need to fix the secret encoding first!


Recaptcha.net support

Adds a new optional boolean property, useRecaptchaDotNet, which, when true, changes the API host to recaptcha.net.

Deploy preview for react-grecaptcha ready!
Built with commit c99fba38e513dca2d9b90ebc0dcbe7f5300040f3
https://deploy-preview-115--react-grecaptcha.netlify.com

I don't think this will actually work, sadly


Missing Character [Yun Jin]

thanks a bunch for the awesome tool! <3
I noticed that Yun Jin was missing from the characters list. I am new here so i am not sure if this is the right place to mention it.
p.s.: she is missing from the optimizer (manual add) but recognized by scanners, upon import it says 1 invalid character and shows her data.

Quote from the announcements channel in discord:

Version 2.4 Contents in GO
Ever since version 2.0, MHY has released characters/weapons with kits that seem to defy the original design considerations of the Optimizer. Unfortunately, to design a hyper optimized system, GO is designed with a lot of assumptions to what "general" forms the formulas in Genshin will take. These assumptions have been feature crept to obsoletion. Weapons like Moonglow and Spindle, characters like Kujou Sara and Gurou, are no longer able to fit into the Optimizer ecosystem. As 2.4 has been released, we've seen MHY double down on these "incompatible" game mechanics, which makes implementing the new characters almost pointless.
The good news is that we've been anticipating this feature creep, and we've designed a new system to accommodate the new changes. However, we will need a lot more time putting vision into code, and even more time migrating all the existing characters/artifact/weapons to the new system. I cannot promise any concrete ETAs, since such an undertaking can have many perilous setbacks, and quite a lot of unanticipated issues. There will be somewhat minimal updates to the implementation process of this system for the same reason, so the only thing you can do for now is to please keep in mind that we are presently working on a solution.


[Question] Image not shown using builder.CardImage and Promises?

SDK Platform: Node.js

Issue Description
I want to show the image of a Foursquare venue, using a HeroCard and particularly of course builder.cardImage(session,link). The link is a promise, but i want the returning(resolving value) of it.All i get in the end in the emulator is an [object Promise]
Code Example
//Function returning the Promise
function getPhotoUrl(venue_id,venue_location,venue_query){
        return new Promise((resolve,reject) =>
        {
            request({
            url: 'https://api.foursquare.com/v2/venues/'+venue_id+'/photos',
            json:true,
            method: 'GET',
            qs: {
            client_id: 'my_id',
            client_secret: 'my_secret',
            near:venue_location,
            query: venue_query,
            v: '20171114',
            limit: 1
            }
        },  function(err, res, body) {
            var result="";
            if (err) {
                reject(err);
            }

        result=body.response.photos.items[0].prefix+"300x500"+body.response.photos.items[0].suffix;
        resolve(result);

    });

})
//
//The async function which awaits the promise returned from the above function

async function showImage(venue_id,venue_location,venue_query){
        let res=await getPhotoUrl(venue_id,venue_location,venue_query).then(function(data){
            return data;
        });
        console.log(res);
    }

//invoking the function

new builder.HeroCard(session)
              .title(places[0].name)
              .subtitle(places[0].location.address+"-"+places[0].location.city+"-Τηλ:"+places[0].contact.phone)
              .buttons([builder.CardAction.openUrl(session,"https://foursquare.com/v/"+places[0].name+"/"+places[0].id,"Μια καλύτερη ματιά?")])
              .images([ **builder.CardImage.create(session,""+showImage(places[0].id,session.dialogData.topothesia,session.dialogData.foodtype)+"")])
**

Expected Behavior
To get the image shown in the emulator like the below paradigm.

Actual Results

@KwstasBol This is a general asynchronous programming issue, and not specific to BotBuilder SDK. Short answer: you need to resolve your promise with the URL data before sending the card.
For more information see:

https://www.google.com/search?q=node.js+async+await
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises
https://stackoverflow.com/search?q=[node.js]+promise


Handle head-of-queue failures in export

Fixes #20197, in passing.

Self-review checklist

[ ] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[ ] Each commit is a coherent idea.
[ ] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

This looks great except that we need to document the API change; I'll just add that before merging since it's not much to do.

Pushed the following changes for the API documentation. (The endpoint itself isn't documented yet, so we just get a changelog entry):
diff --git a/api_docs/changelog.md b/api_docs/changelog.md
index fb82a8d988..834b2121a1 100644
--- a/api_docs/changelog.md
+++ b/api_docs/changelog.md
@@ -20,6 +20,11 @@ format used by the Zulip server that they are interacting with.

 ## Changes in Zulip 7.0

+**Feature level 182**
+
+* `POST /export/realm`: This endpoint now returns the ID of the data
+  export object created by the request.
+
 **Feature level 181**

 * [`GET /scheduled_messages`](/api/get-scheduled-messages), [`GET
diff --git a/version.py b/version.py
index b7575017ef..c772168cbb 100644
--- a/version.py
+++ b/version.py
@@ -33,7 +33,7 @@ DESKTOP_WARNING_VERSION = "5.4.3"
 # Changes should be accompanied by documentation explaining what the
 # new level means in api_docs/changelog.md, as well as "**Changes**"
 # entries in the endpoint's documentation in `zulip.yaml`.
-API_FEATURE_LEVEL = 181
+API_FEATURE_LEVEL = 182

 # Bump the minor PROVISION_VERSION to indicate that folks should provision
 # only when going from an old version of the code to a newer version. Bump


Remove "override link" in promo slice

I've been curious and investigating the Link Override in Promos, unsure what their purpose was. This was the ticket that added it 6 years ago.

I ran a script and, even though it's available in all content types that have Promos, it's only used in two Page content types (accessibility: Wvm2uiAAAIYQ4FHP and opening times: WwQHTSAAANBfDYXU). In both instances, they link their former vanity URL, which were removed in the last year.
I believe this field is therefore not used or useful and should be removed in the spirit of only keeping what is needed, cleaning up both code and editorial onboarding.

Do as part of slice machine work

Could we do this one as part of the script/migration work @davidpmccormick ?

This is now part of a bigger change so closing in favour of https://github.com/wellcomecollection/wellcomecollection.org/issues/10957


Admin Guide

At this time the admins/approvers cannot see all app requests. After some testing the admin can only see a request they put in themselves. How are admins added for this app?

Are the users in the (Teams) Admin group the same users we would have for the SharePoint site?

@cesmaili so the Admins would/should be able to see all the entries in the SharePoint list, this is where they would go to view the entire list.

Hi @cesmaili , the SharePoint site is required to be shared by admins as Owners. Please refer #6 of Step 5


There is a word error in the error message of debug

Configuration:
• VS Code 1.43.2
• JDK 1.8
• Maven 3.3.3
• Azure Functions Core Tool 2.7.2254
• VS Code extensions
○ Azure Account 0.8.9
○ Debugger for Java 0.25.1
○ Language Support for Java 0.59.1
Reproduce steps:

Create a java function project
Debug Java Function locally

Result:
Debug error message is wrong

Closing as duplicate of https://github.com/microsoft/vscode-azurefunctions/issues/191


Fix openstack ceilometer reconnection-storm in log

Automatic reconnect functionality in Openstack Ceilometer Event monitor
was reconnecting too often when Ceilometer service went down. The result
was high resource consumption and big log file.
Initial purpose for immediate reconnection was quickly reconnect after keystone
token expiration, but it can be done with default monitor restart too. Which is
a bit slower - 15 seconds by default instead of immediately, but it should not
be problem in this case.
https://bugzilla.redhat.com/show_bug.cgi?id=1336795

I am not sure here, but I think this should land to darga too.
@miq-bot add_label darga/yes

I haven't try this, but the code looks good :+1:  It should throw an exception and leave it to event monitor to fail and cache connection error in next step.

@tzumainn please review.  When you give 👍 please re-assign to @blomquisg

:+1: code makes sense to me

@blomquisg can you take a look?
@chessbyte, I don't see an obvious way to set the assignee.

@miq-bot assign @blomquisg


add option to talk to the SUT using VST

this PR enables the test framework to talk to arangod using VST. Since we're rather interested in the arangosh sending real requests, the code remoting the JS on the arangod isn't modified so far.
tested using:
./scripts/unittest shell_client --vst true

http://jenkins01.arangodb.biz:8080/view/PR/job/arangodb-matrix-pr/6680/

no relevant problems.


Cannot see the crop button on screen

Once the crop activity is launched, it should show the action bar with crop button. But it is not shown

see the wiki FAQ

I've tryied adding on manifest but it didn't solve the issue. Crop button is not rendered


feat: print diff info from cmd

Leverages https://github.com/Kong/go-database-reconciler/pull/30 to print diff output from the command code, rather than having the library code print directly. This allows removing cprint dependencies from the library.
Same breaking caveat applies: we are no longer printing at the time individual events happen. We collect evens and print them in a batch at the end. This change is notable but hopefully not a problem. Adding timestamps could recapture that information in a new format if needed.

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

Comparison is base (675a51c) 5.91% compared to head (649ce9b) 5.87%.

Files
Patch %
Lines

cmd/common.go
0.00%
12 Missing :warning:

cmd/common_konnect.go
0.00%
10 Missing :warning:

Additional details and impacted files
@@           Coverage Diff            @@
##            main   #1142      +/-   ##
========================================
- Coverage   5.91%   5.87%   -0.04%
========================================
  Files         31      31
  Lines       3144    3164      +20
========================================
  Hits         186     186
- Misses      2948    2968      +20
  Partials      10      10

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


List all workspace symbols when an empty query comes in

According to the specification the workspace symbols provider should
accept an empty query string and return all the symbols in that case
https://microsoft.github.io/language-server-protocol/specification#workspace_symbol
/**
 * The parameters of a Workspace Symbol Request.
 */
interface WorkspaceSymbolParams extends WorkDoneProgressParams,
	PartialResultParams {
	/**
	 * A query string to filter symbols by. Clients may send an empty
	 * string here to request all symbols.
	 */
	query: string;
}

The test is quite primitive as I am an Elixir beginner. If this feature is of interest I would appreciate some help improving them.

@groig Have you tested it on any decent size project? IIRC this was super slow and that's why I explicitly disabled returning everything.

@groig Have you tested it on any decent size project? IIRC this was super slow and that's why I explicitly disabled returning everything.

I tested it on elixir-ls itself and it's not bad.

I tested it on elixir-ls itself and it's not bad.

Elixir-ls is a rather small project compared to the applications that many developers are running on which can have thousands of modules.

Sorry for the delay answering.
I understand that requesting every workspace symbol may be slow in some projects, but the feature does not impact the existing workspace symbol search. I see that lots of language servers decided to not implement this part of the spec (gopls, python-lsp-server, pyright, rust-analyzer). I personally find it useful as a replacement for ctags so my editor's client now requests the symbol list periodically to the server and keeps a local cache. Maybe the performance could be improved following a similar approach to #261 and returning only the symbols of the modules in the current application.
Feel free to close the pull request if the feature is not accepted.

@groig I revisited this idea in https://github.com/elixir-lsp/elixir-ls/pull/1050 - with limiting indexing to only modules from the project it is feasible to query with empty needle


Standardize Documentation Variable/Function Reference Formatting

Expected Behavior
The variables and functions referenced in the documentation should be enclosed in ` ` in order to distinguish them from normal text. For example, variable_1
Actual Behavior
Sometimes variables are referenced correctly.  Other times they are displayed with math type.  Other times still they are simply written in plain text.
Template Code: Erdos-Renyi Model Tutorial
Erdos-Renyi (ER) graphs are the simplest generative model. We assume that each edge for all pairs of vertices is sampled independently from all the edges. There are two ways to parameterize the model:

ER(n, p) - this model specifies the number of vertices, $n$, and each pair of vertices has $p$ probability of an edge existing between the two.
ER(n, m) - this model specifies the number of vertices, $n$, and the total number of edges $m$.

Below, we sample two binary graphs (undirected and no self-loops) $G_1 \sim ER_{NP}(50, 0.3)$ and $G_2 \sim ER_{NM}(50, 250)$.

@pauladkisson it gets tricky, the sometimes we really do want to write out the math, and sometimes we want to write the variable... may be hard to tell the distinction at times, for instance, the example above. see what I mean?

Ahhhh, I see what you mean.  ER(n, p) here is referring to the random graph model itself rather than the function in our code...
That definitely could get tricky.  I could just leave it be.

I am sure in many places we are still not consistent, though, so don't want to discourage you from taking this on. But just warning that if we do, might need to discuss where the difference is intentional or not

Yeah, like later in the same tutorial it says:
Both er_np and er_nm functions provide ways to sample weights for all edges that were sampled via a probability distribution function. In order to sample with weights, we provide a probability distribution function with corresponding keyword arguments for the distribution function.
And those function names should be in `` right?
eg.
Both er_np and er_nm functions provide ways to sample weights for all edges that were sampled via a probability distribution function. In order to sample with weights, we provide a probability distribution function with corresponding keyword arguments for the distribution function.

correct


Human goo beasts with a player's skin that transfur another entity will default to Alex or Steve.

https://github.com/LtxProgrammer/Changed-Minecraft-Mod/assets/117211742/e8a80716-e3c0-4c11-84f8-6448dfb4ee59

Should've been a white latex wolf smhhh
Okay but I kinda want it to be a option.

I had apparently wrote code for this specific situation

I don't remember why though.


Steam: Fix audio for BLUE REFLECTION (658260)

Disable media converter for BLUE REFLECTION, like many other Gust games.

https://github.com/ValveSoftware/Proton/issues/1522


#215:  Enable-multiple-GitHub-integrations-by-extracting-source-location-annotation

Signed-off-by: manusant<EMAIL_ADDRESS>Enable multiple GitHub integrations by extracting source location from entity managed annotations
:heavy_check_mark: Checklist

[x] Added tests for new functionality and regression tests for bug fixes
[ ] Screenshots of before and after attached (for UI changes)
[ ] Added or updated documentation (if applicable)

Thanks @manusant!
That looks good to me. If CI passes, I think we should be ready to get this merged in.

@manusant This is great thanks! How would one use this version of the plugin if we have 1 onprem and 1 github.com - meaning, after using this version and clicking on code insights, the plugin appears to load auth.github from the app-config.yaml which we don't use - we rely on integrations.github with multiple entries


[FEATURE] Support for search function

Basic Search Function Support

Search Results Page
Search task name, description, note for tasks
Search Epic and Story titles
Search Tags

Display list of results. Nothing fancy, but, this may require polishing detail pages of Task/Story/Epics.

This was way easier than I thought it was going to be.


I'll apply the template you suggested here https://github.com/pytorch/pytorch/pull/56265#discussion_r615376640

I'll apply the template you suggested here https://github.com/pytorch/pytorch/pull/56265#discussion_r615376640
Originally posted by @Lezcano in https://github.com/pytorch/pytorch/pull/56265#discussion_r615892124

Seems off-topic.


Custom save folder

Please add the ability to store recordings in a custom folder. In Settings, you should be able to select a folder (Videos/Fluent-Screen-Recorder should be by default) and the save button will save there next time.

If you select "Save as " you can pick the folder you prefer and the next time it will be automatically selected

If you select "Save as " you can pick the folder you prefer and the next time it will be automatically selected

"Save" saves automatically in that folder now from beta versions

"Save" saves automatically in that folder now from beta versions


Add older version of selfcontrol

Thank you for the contribution. It was merged directly as 8547210cbcad1c14ad21b15cfa71b8c755171269 to keep commit history cleaner. Your contribution is still credited to you.


Financial

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 87.282%

Totals

Change from base Build<PHONE_NUMBER>:
0.02%

Covered Lines:
9616

Relevant Lines:
10646

💛  - Coveralls


Method to avoid refreshing ipynb cells from wrapped simulators

This should fix a problem that @sroet brought to my attention at the ESDW today. The basic problem is this:
Some path simulators will wrap other path simulators (e.g., for some iterative process). The problem that @sroet was having was that, even if the output of the wrapped simulator was sent to dev/null, the refresh command was emptying the cell, deleting desired output from the outer simulator.
This adds a new attribute for PathSimulators called allow_refresh, which defaults to True. When a simulator calls the refresh_output command, the refresh attribute is set to self.allow_refresh. Combining inner_sim.allow_refresh = False with inner_sim.output_stream = os.devnull, this can completely silence the output behavior of the inner simulator.
@sroet: Could you check out this branch and test that it fixes your problem? We should check that it fixed the issue before merging.

@dwhswenson This indeed fixes my problem

Fixes the problem and passes tests. @jhprinz : this is ready for review!

If it works. This can be merged. Hard to tell from here.


[CPU] Deprecate LLVMCPUEmitVectorizationRemarks pass.

The option was used for checking if there are ops not getting vectorized. We seldom use the option because some passes intend to generate scalar codes (e.g., peeling pipeline). This revision removes the pass to reduce maintenance burden.

This is still useful and I've been using it for a while. Could we keep it? What is the concern with it exactly?


ESP32-C3 Direct-Boot: All Examples get restarted by Watchdog

On ESP32-C§ all the examples get restarted by a watchdog. Pretty sure it wasn't always like that. Not figured out yet which change is causing this.

CC @gustavonihei

@bjoernQ I am not able to reproduce this issue on the main branch. I've just executed the hello_world application on the ESP32-C3-DevKitM-1, both in debug and release builds, and it prints "Hello world!" without restarting:


Investigate culprit for potential consensus forking

On running 64-provisioners cluster,  the following observations have been made.
Node node-8 from cluster hawk-64p-1208 got stuck at round 3470. On trying to accept block 3471 it reported prevBlockHash inconsistency. After this accept-block failure, it tried to start "sync procedure` 3210 times without any success.
For reference:
{"blk_hash":"7bdc0ad181732349878e946ba912e1a61728584bb18a2220e6a2e702102b5644","blk_height":3471,"error":"Previous block hash does not equal the previous hash in the current block","level":"warning","msg":"could not AcceptBlock","process":"sync","state":"insync","time":"2021-08-12T21:44:32Z"}
{"blk_hash":"7bdc0ad181732349878e946ba912e1a61728584bb18a2220e6a2e702102b5644","blk_height":3471,"error":"Previous block hash does not equal the previous hash in the current block","level":"warning","msg":"could not AcceptBlock","process":"sync","state":"insync","time":"2021-08-12T21:44:37Z"}
{"curr_h":3470,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:7100","target":3472,"time":"2021-08-12T21:44:39Z","tip":3472}
{"curr_h":3470,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:38808","target":3473,"time":"2021-08-12T21:44:45Z","tip":3473}
{"curr_h":3470,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:53412","target":3474,"time":"2021-08-12T21:44:52Z","tip":3474}
{"curr_h":3470,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:53412","target":3475,"time":"2021-08-12T21:44:58Z","tip":3475}
{"curr_h":3470,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:38808","target":3476,"time":"2021-08-12T21:45:05Z","tip":3476}
{"curr_h":3470,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:53412","target":3477,"time":"2021-08-12T21:45:11Z","tip":3477}
{"curr_h":3470,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:7100","target":3478,"time":"2021-08-12T21:45:18Z","tip":3478}
{"curr_h":3470,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:7100","target":3479,"time":"2021-08-12T21:45:25Z","tip":3479}
{"curr_h":3470,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:7100","target":3480,"time":"2021-08-12T21:45:31Z","tip":3480}
{"curr_h":3470,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:7100","target":3481,"time":"2021-08-12T21:45:36Z","tip":3481}

...

{"curr_h":3470,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:7100","target":3970,"time":"2021-08-13T10:20:42Z","tip":6730}
{"curr_h":3470,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:58852","target":3970,"time":"2021-08-13T11:00:32Z","tip":6731}

In addition, on reviewing agreement messages for round 3470 it seems like an agreement has been reached for two different block hashes:
{"bitset":3803,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":2,"time":"2021-08-12T21:44:18Z","total_votes":17,"voted_len":9}
{"bitset":3803,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":2,"time":"2021-08-12T21:44:18Z","total_votes":17,"voted_len":9}
{"bitset":3803,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":2,"time":"2021-08-12T21:44:18Z","total_votes":17,"voted_len":9}
{"bitset":3803,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":2,"time":"2021-08-12T21:44:18Z","total_votes":17,"voted_len":9}
{"bitset":1983,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":3,"time":"2021-08-12T21:44:19Z","total_votes":36,"voted_len":10}
{"bitset":1983,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":3,"time":"2021-08-12T21:44:19Z","total_votes":36,"voted_len":10}
{"bitset":1983,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":3,"time":"2021-08-12T21:44:19Z","total_votes":36,"voted_len":10}
{"bitset":1983,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":3,"time":"2021-08-12T21:44:19Z","total_votes":36,"voted_len":10}
{"bitset":3803,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":2,"time":"2021-08-12T21:44:20Z","total_votes":17,"voted_len":9}
{"bitset":3803,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":2,"time":"2021-08-12T21:44:20Z","total_votes":17,"voted_len":9}
{"bitset":3803,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":2,"time":"2021-08-12T21:44:20Z","total_votes":17,"voted_len":9}
{"bitset":3803,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":2,"time":"2021-08-12T21:44:20Z","total_votes":17,"voted_len":9}
{"bitset":1983,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":3,"time":"2021-08-12T21:44:20Z","total_votes":36,"voted_len":10}
{"bitset":1983,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":3,"time":"2021-08-12T21:44:20Z","total_votes":36,"voted_len":10}
{"bitset":1983,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":3,"time":"2021-08-12T21:44:20Z","total_votes":36,"voted_len":10}
{"bitset":1983,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":3,"time":"2021-08-12T21:44:20Z","total_votes":36,"voted_len":10}
{"bitset":3803,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":2,"time":"2021-08-12T21:44:21Z","total_votes":17,"voted_len":9}
{"bitset":1983,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":3,"time":"2021-08-12T21:44:21Z","total_votes":36,"voted_len":10}
{"bitset":14047,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":5,"time":"2021-08-12T21:44:22Z","total_votes":14,"voted_len":11}
{"bitset":11999,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":5,"time":"2021-08-12T21:44:22Z","total_votes":16,"voted_len":11}
{"bitset":14047,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":5,"time":"2021-08-12T21:44:22Z","total_votes":14,"voted_len":11}
{"bitset":14047,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":5,"time":"2021-08-12T21:44:22Z","total_votes":14,"voted_len":11}
{"bitset":7455,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":6,"time":"2021-08-12T21:44:22Z","total_votes":28,"voted_len":9}
{"bitset":7455,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":6,"time":"2021-08-12T21:44:22Z","total_votes":30,"voted_len":9}
{"bitset":7455,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":6,"time":"2021-08-12T21:44:22Z","total_votes":28,"voted_len":9}
{"bitset":7455,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":6,"time":"2021-08-12T21:44:22Z","total_votes":28,"voted_len":9}
{"bitset":10959,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":5,"time":"2021-08-12T21:44:23Z","total_votes":14,"voted_len":9}
{"bitset":11982,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":5,"time":"2021-08-12T21:44:23Z","total_votes":14,"voted_len":9}
{"bitset":7326,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":5,"time":"2021-08-12T21:44:23Z","total_votes":14,"voted_len":8}
{"bitset":16079,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":5,"time":"2021-08-12T21:44:23Z","total_votes":17,"voted_len":11}
{"bitset":7455,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":6,"time":"2021-08-12T21:44:24Z","total_votes":28,"voted_len":9}
{"bitset":7455,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":6,"time":"2021-08-12T21:44:24Z","total_votes":28,"voted_len":9}
{"bitset":7455,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":6,"time":"2021-08-12T21:44:24Z","total_votes":28,"voted_len":9}
{"bitset":7455,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":6,"time":"2021-08-12T21:44:24Z","total_votes":31,"voted_len":9}
{"bitset":14047,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":5,"time":"2021-08-12T21:44:24Z","total_votes":14,"voted_len":11}
{"bitset":16079,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":5,"time":"2021-08-12T21:44:24Z","total_votes":17,"voted_len":11}
{"bitset":3803,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":2,"time":"2021-08-12T21:44:24Z","total_votes":17,"voted_len":9}
{"bitset":15502,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":5,"time":"2021-08-12T21:44:25Z","total_votes":14,"voted_len":8}
{"bitset":1983,"event":"agreement_received","hash":"e48bfb0ff4...2813b0f307","level":"info","msg":"","process":"consensus","round":3470,"step":3,"time":"2021-08-12T21:44:25Z","total_votes":36,"voted_len":10}
{"bitset":7455,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":6,"time":"2021-08-12T21:44:25Z","total_votes":28,"voted_len":9}
{"bitset":7455,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":6,"time":"2021-08-12T21:44:25Z","total_votes":31,"voted_len":9}
{"bitset":7455,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":6,"time":"2021-08-12T21:44:25Z","total_votes":28,"voted_len":9}
{"bitset":16027,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":5,"time":"2021-08-12T21:44:26Z","total_votes":16,"voted_len":10}
{"bitset":7455,"event":"agreement_received","hash":"b7ead8603a...e041a89b17","level":"info","msg":"","process":"consensus","round":3470,"step":6,"time":"2021-08-12T21:44:26Z","total_votes":30,"voted_len":9}

As a conclusion, node-8 did manage to fork consensus.
Same problem noticed on node-5.
For reference:
root@hawk-64p-1208-node-5:~# grep "could not AcceptBlock" /var/log/dusk.log
{"blk_hash":"ec3d10b1f8aa925f2ef680b7e7e889640436d238c845d013ba57c704bba2fc68","blk_height":4906,"error":"Previous block hash does not equal the previous hash in the current block","level":"warning","msg":"could not AcceptBlock","process":"sync","state":"insync","time":"2021-08-13T00:36:16Z"}
root@hawk-64p-1208-node-5:~# grep -e "could not AcceptBlock\|start syncing" /var/log/dusk.log
{"blk_hash":"ec3d10b1f8aa925f2ef680b7e7e889640436d238c845d013ba57c704bba2fc68","blk_height":4906,"error":"Previous block hash does not equal the previous hash in the current block","level":"warning","msg":"could not AcceptBlock","process":"sync","state":"insync","time":"2021-08-13T00:36:16Z"}
{"curr_h":4905,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:48212","target":4907,"time":"2021-08-13T00:36:23Z","tip":4907}
{"curr_h":4905,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:41190","target":4908,"time":"2021-08-13T00:36:31Z","tip":4908}
{"curr_h":4905,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:37958","target":4909,"time":"2021-08-13T00:36:36Z","tip":4909}
{"curr_h":4905,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:48212","target":4910,"time":"2021-08-13T00:36:43Z","tip":4910}
{"curr_h":4905,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:37958","target":4911,"time":"2021-08-13T00:36:50Z","tip":4911}
{"curr_h":4905,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:48212","target":4912,"time":"2021-08-13T00:36:57Z","tip":4912}
{"curr_h":4905,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:37958","target":4913,"time":"2021-08-13T00:37:22Z","tip":4913}
{"curr_h":4905,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:37958","target":4914,"time":"2021-08-13T00:37:28Z","tip":4914}
{"curr_h":4905,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:48212","target":4915,"time":"2021-08-13T00:37:37Z","tip":4915}
{"curr_h":4905,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:41190","target":4916,"time":"2021-08-13T00:37:43Z","tip":4916}
{"curr_h":4905,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:41190","target":4917,"time":"2021-08-13T00:37:54Z","tip":4917}
{"curr_h":4905,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:37958","target":4918,"time":"2021-08-13T00:37:59Z","tip":4918}
{"curr_h":4905,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:48212","target":4919,"time":"2021-08-13T00:38:08Z","tip":4919}
{"curr_h":4905,"level":"info","msg":"start syncing","process":"sync","r_addr":"<IP_ADDRESS>:48212","target":4920,"time":"2021-08-13T00:38:21Z","tip":4920}

For reference:
Node-5 agreement_received messages at round 4905
{"bitset":887,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":2,"time":"2021-08-13T00:35:59Z","total_votes":14,"voted_len":8}
{"bitset":887,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":2,"time":"2021-08-13T00:35:59Z","total_votes":14,"voted_len":8}
{"bitset":887,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":2,"time":"2021-08-13T00:35:59Z","total_votes":14,"voted_len":8}
{"bitset":887,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":2,"time":"2021-08-13T00:35:59Z","total_votes":14,"voted_len":8}
{"bitset":7671,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":3,"time":"2021-08-13T00:36:00Z","total_votes":28,"voted_len":11}
{"bitset":7671,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":3,"time":"2021-08-13T00:36:00Z","total_votes":28,"voted_len":11}
{"bitset":7671,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":3,"time":"2021-08-13T00:36:00Z","total_votes":28,"voted_len":11}
{"bitset":7671,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":3,"time":"2021-08-13T00:36:00Z","total_votes":28,"voted_len":11}
{"bitset":887,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":2,"time":"2021-08-13T00:36:00Z","total_votes":14,"voted_len":8}
{"bitset":887,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":2,"time":"2021-08-13T00:36:00Z","total_votes":14,"voted_len":8}
{"bitset":887,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":2,"time":"2021-08-13T00:36:00Z","total_votes":14,"voted_len":8}
{"bitset":887,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":2,"time":"2021-08-13T00:36:00Z","total_votes":14,"voted_len":8}
{"bitset":7671,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":3,"time":"2021-08-13T00:36:00Z","total_votes":28,"voted_len":11}
{"bitset":7671,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":3,"time":"2021-08-13T00:36:01Z","total_votes":28,"voted_len":11}
{"bitset":7671,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":3,"time":"2021-08-13T00:36:01Z","total_votes":28,"voted_len":11}
{"bitset":7671,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":3,"time":"2021-08-13T00:36:01Z","total_votes":28,"voted_len":11}
{"bitset":887,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":2,"time":"2021-08-13T00:36:01Z","total_votes":14,"voted_len":8}
{"bitset":887,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":2,"time":"2021-08-13T00:36:01Z","total_votes":14,"voted_len":8}
{"bitset":7671,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":3,"time":"2021-08-13T00:36:01Z","total_votes":28,"voted_len":11}
{"bitset":7671,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":3,"time":"2021-08-13T00:36:01Z","total_votes":28,"voted_len":11}
{"bitset":3930,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":5,"time":"2021-08-13T00:36:03Z","total_votes":14,"voted_len":8}
{"bitset":3931,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":5,"time":"2021-08-13T00:36:03Z","total_votes":15,"voted_len":9}
{"bitset":3931,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":5,"time":"2021-08-13T00:36:03Z","total_votes":15,"voted_len":9}
{"bitset":3931,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":5,"time":"2021-08-13T00:36:03Z","total_votes":15,"voted_len":9}
{"bitset":1903,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":6,"time":"2021-08-13T00:36:04Z","total_votes":28,"voted_len":9}
{"bitset":1903,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":6,"time":"2021-08-13T00:36:04Z","total_votes":29,"voted_len":9}
{"bitset":1903,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":6,"time":"2021-08-13T00:36:04Z","total_votes":29,"voted_len":9}
{"bitset":1903,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":6,"time":"2021-08-13T00:36:04Z","total_votes":29,"voted_len":9}
{"bitset":3930,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":5,"time":"2021-08-13T00:36:04Z","total_votes":14,"voted_len":8}
{"bitset":3931,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":5,"time":"2021-08-13T00:36:04Z","total_votes":15,"voted_len":9}
{"bitset":3930,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":5,"time":"2021-08-13T00:36:04Z","total_votes":14,"voted_len":8}
{"bitset":3930,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":5,"time":"2021-08-13T00:36:04Z","total_votes":14,"voted_len":8}
{"bitset":1903,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":6,"time":"2021-08-13T00:36:05Z","total_votes":28,"voted_len":9}
{"bitset":1903,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":6,"time":"2021-08-13T00:36:05Z","total_votes":28,"voted_len":9}
{"bitset":1903,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":6,"time":"2021-08-13T00:36:05Z","total_votes":29,"voted_len":9}
{"bitset":1903,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":6,"time":"2021-08-13T00:36:05Z","total_votes":28,"voted_len":9}
{"bitset":893,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":2,"time":"2021-08-13T00:36:05Z","total_votes":16,"voted_len":8}
{"bitset":3931,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":5,"time":"2021-08-13T00:36:05Z","total_votes":15,"voted_len":9}
{"bitset":893,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":2,"time":"2021-08-13T00:36:05Z","total_votes":16,"voted_len":8}
{"bitset":7671,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":3,"time":"2021-08-13T00:36:06Z","total_votes":30,"voted_len":11}
{"bitset":7671,"event":"agreement_received","hash":"de202bda0c...aa570c2bdf","level":"info","msg":"","process":"consensus","round":4905,"step":3,"time":"2021-08-13T00:36:06Z","total_votes":30,"voted_len":11}
{"bitset":1903,"event":"agreement_received","hash":"8afd8324ba...b10922b39f","level":"info","msg":"","process":"consensus","round":4905,"step":6,"time":"2021-08-13T00:36:06Z","total_votes":29,"voted_len":9}

The problem seems to be related to the Agreement phase accumulating votes without a block hash discriminant. This bug might be a leftover from previous implementation of the Agreement loop


Split ut

I was wondering how and if i can split up language files. For an example i would like to have the following folder structure:
locales/Controllers/Home/en.json
locales/Models/Home/en.json
locales/Services/Home/en.json
Is that possible? The default localisation .net Core offers, tries to guess where the localisations files are based on the path of the actual cs file. Unfortunately i am unable to figure out how it works with this library.


Fix: remove tagging label when clicked in dropdown

This fixes #1806.
This bug was introduced from PR #1727.
Here is a plunker to represent the issue: http://plnkr.co/edit/zv41jdiLa2eylIdM9tu8. When you type in a new field and click on it (don't press enter), the tagging label gets included in the tag.
This fix adds a tiny bit of duplicate code from line 417-ish of the same file, but this particular area of code seems potentially fragile, so I opted minimal changes.  Ideally this whole lot of code needs to change to improve the way this text is removed, since a string replace could lead to erroneous string replacements, but there is some traffic on #1806 and it was a significant issue for our team in production.

Hi,
Thanks for submitting the PR. Could you maybe create a function to remove the duplicated code? Also I would like to have some tests to verify if this will work in the single and multiple select situation.  Can you arrange this?
Thanks.

We look forward to seeing it merged! :-)

Hey,
Any update on this? Is something actually preventing the merge?

+1

+1 (https://github.com/nextcloud/contacts/issues/444 depends on it)

👍

I added tests and removed duplicate code. Sorry for the delays in adding changes. Should be ready whenever you like, pending passing tests.

Anything left preventing this from being merged?

@Jefiozie bump? :heart:

+1

is this repo maintained anymore?

@kellym Nope! I personally switched to vue-multiselect. Far more updates there and many essentials fixes!
Thanks for the work on vue-select anyway :)

@Jefiozie any news on this and why it's not merged yet? Has been sitting for some time already...

@Jefiozie I'd need this fix as well, any news on it?

Is there a problem which blocks accepting this? It is needed in nextcloud/contacts/issues/444

Would love to have this fixed.....

Is there a problem which blocks accepting this? It is needed in nextcloud/contacts#444

What tests this exactly needs? And what work? Should the labels be removed?


restore crashing on signal.

Unfortunately, we cannot proceed if the application was sent a
SIGKILL, as the data we need will not be written to disk.

cc @ovhemert


two class loss can not decline

hello ,i train two class .set --batch_p = 2 --batch_k = 4,learing_rate has changed,loss can not decline,
test result :mAP: 66.84% | top-1: 1.18% top-2: 1.78% | top-5: 1.78% | top-10: 2.37%
thanks

Please refrain from pinging unrelated people in the issues from now on.
I suspect your dataset is simply too easy. an mAP of 66.84% is not great, but it shows that the model learned something. If the hardest examples are clearly distinguishable, the loss should rather quickly go towards zero, or if be exactly zero if you do not use the soft-margin.
This is not a problem of our code though, but rather a machine learning issue for which we cannot give support here. My suggestion is that you gather a harder training set. I'm closing this issue though.


The "julia" server crashed 5 times in the last 3 minutes.

I failed to start coc-julia after installation. Here's the log information I get:
2020-12-17T22:28:27.104 DEBUG (pid:11651) [workspace] - buffer created 1
2020-12-17T22:28:27.106 DEBUG (pid:11651) [events] - Event: BufEnter [ 1 ]
2020-12-17T22:28:27.108 DEBUG (pid:11651) [events] - Event: BufWinEnter [ 1, 1000 ]
2020-12-17T22:28:28.123 WARN (pid:11651) [extensions] - Extension coc-julia activate cost more than 1s
2020-12-17T22:28:28.145 DEBUG (pid:11651) [languages] - created service source snippets
2020-12-17T22:28:28.146 DEBUG (pid:11651) [languages] - created service source snippets-source
2020-12-17T22:28:28.146 DEBUG (pid:11651) [extensions] - activate: coc-snippets
2020-12-17T22:28:28.147 INFO (pid:11651) [plugin] - coc.nvim 0.0.79-ada0b910bd initialized with node: v15.4.0 after 1074ms
2020-12-17T22:28:29.535 INFO (pid:11651) [services] - registered service "julia"
2020-12-17T22:28:29.535 DEBUG (pid:11651) [services] - starting service: julia
2020-12-17T22:28:29.536 INFO (pid:11651) [services] - Julia Language Server state change: stopped => starting
2020-12-17T22:28:29.539 INFO (pid:11651) [language-client-index] - Language server "julia" started with 11661
2020-12-17T22:28:31.252 DEBUG (pid:11651) [events] - Event: CursorMoved [ 1, [ 21, 1 ] ]
2020-12-17T22:28:31.556 DEBUG (pid:11651) [events] - Event: CursorHold [ 1 ]
2020-12-17T22:28:43.770 INFO (pid:11651) [services] - Julia Language Server state change: starting => running
2020-12-17T22:28:43.772 DEBUG (pid:11651) [languages] - created service source julia-1
2020-12-17T22:28:43.775 INFO (pid:11651) [services] - service julia started
2020-12-17T22:28:43.775 DEBUG (pid:11651) [extensions] - activate: coc-julia
2020-12-17T22:28:46.987 INFO (pid:11651) [services] - Julia Language Server state change: running => stopped
2020-12-17T22:28:46.987 INFO (pid:11651) [services] - Julia Language Server state change: stopped => starting
2020-12-17T22:28:46.990 INFO (pid:11651) [language-client-index] - Language server "julia" started with 11663
2020-12-17T22:29:02.073 INFO (pid:11651) [services] - Julia Language Server state change: starting => running
2020-12-17T22:29:02.074 DEBUG (pid:11651) [languages] - created service source julia-1
2020-12-17T22:29:05.544 INFO (pid:11651) [services] - Julia Language Server state change: running => stopped
2020-12-17T22:29:05.544 INFO (pid:11651) [services] - Julia Language Server state change: stopped => starting
2020-12-17T22:29:05.548 INFO (pid:11651) [language-client-index] - Language server "julia" started with 11668
2020-12-17T22:29:21.693 INFO (pid:11651) [services] - Julia Language Server state change: starting => running
2020-12-17T22:29:21.693 DEBUG (pid:11651) [languages] - created service source julia-1
2020-12-17T22:29:25.328 INFO (pid:11651) [services] - Julia Language Server state change: running => stopped
2020-12-17T22:29:25.329 INFO (pid:11651) [services] - Julia Language Server state change: stopped => starting
2020-12-17T22:29:25.332 INFO (pid:11651) [language-client-index] - Language server "julia" started with 11670
2020-12-17T22:29:42.826 INFO (pid:11651) [services] - Julia Language Server state change: starting => running
2020-12-17T22:29:42.827 DEBUG (pid:11651) [languages] - created service source julia-1
2020-12-17T22:29:45.428 DEBUG (pid:11651) [events] - Event: CursorMoved [ 1, [ 22, 1 ] ]
2020-12-17T22:29:45.732 DEBUG (pid:11651) [events] - Event: CursorHold [ 1 ]
2020-12-17T22:29:46.388 DEBUG (pid:11651) [events] - Event: CursorMoved [ 1, [ 21, 1 ] ]
2020-12-17T22:29:46.693 DEBUG (pid:11651) [events] - Event: CursorHold [ 1 ]
2020-12-17T22:29:46.753 INFO (pid:11651) [services] - Julia Language Server state change: running => stopped
2020-12-17T22:29:46.754 INFO (pid:11651) [services] - Julia Language Server state change: stopped => starting
2020-12-17T22:29:46.758 INFO (pid:11651) [language-client-index] - Language server "julia" started with 11675
2020-12-17T22:29:46.785 DEBUG (pid:11651) [events] - Event: CursorMoved [ 1, [ 20, 1 ] ]
2020-12-17T22:29:46.933 DEBUG (pid:11651) [events] - Event: CursorMoved [ 1, [ 19, 1 ] ]
2020-12-17T22:29:47.098 DEBUG (pid:11651) [events] - Event: CursorMoved [ 1, [ 18, 1 ] ]
2020-12-17T22:29:47.406 DEBUG (pid:11651) [events] - Event: CursorHold [ 1 ]
2020-12-17T22:30:05.176 INFO (pid:11651) [services] - Julia Language Server state change: starting => running
2020-12-17T22:30:05.177 DEBUG (pid:11651) [languages] - created service source julia-1
2020-12-17T22:30:09.420 INFO (pid:11651) [services] - Julia Language Server state change: running => stopped
2020-12-17T22:30:25.636 DEBUG (pid:11651) [events] - Event: BufWinLeave [ 1, 1000 ]
2020-12-17T22:30:25.637 DEBUG (pid:11651) [events] - Event: BufHidden [ 1 ]
2020-12-17T22:30:25.649 DEBUG (pid:11651) [events] - Event: FileType [ 'log', 2 ]
2020-12-17T22:30:25.661 DEBUG (pid:11651) [events] - Event: BufCreate [ 2 ]
2020-12-17T22:30:25.662 DEBUG (pid:11651) [events] - Event: BufEnter [ 2 ]
2020-12-17T22:30:25.663 DEBUG (pid:11651) [events] - Event: BufWinEnter [ 2, 1000 ]
2020-12-17T22:30:25.698 DEBUG (pid:11651) [events] - Event: CursorMoved [ 2, [ 1, 1 ] ]
2020-12-17T22:30:25.707 DEBUG (pid:11651) [workspace] - buffer created 2
2020-12-17T22:30:26.004 DEBUG (pid:11651) [events] - Event: CursorHold [ 2 ]

It seems that the log didn't tell me what was happening... I may need help to get more information and clarity...

It's macOS 11.1 Big Sur, and I'm using Julia 1.5.3 built from MacPorts.

Problem solved by upgrading coc.nvim.

Well, I think the problem still exists.

To be clear, the server crashes specifically in this file (System.jl):
module System

const g = 980 # cm/s^2
const ρ = 1.0 # g/cm^3

function f(
        Du::Vector{F1},
        u::Vector{F1},
        p::Vector{Any},
        t::F2
    ) where {
        F1<:AbstractFloat, F2<:AbstractFloat,
    }

    m, a, V, Vp = p

    Du[1] = g * (m - ρ*( V(u[2])-V(u[3])) ) / (m + ρ*V(u[3]))
    Du[2] = u[1]

    ΔP = 2(a/Vp(u[3]))^2 * g*(u[2]-u[3])
    Du[3] = sign(ΔP)*sqrt(abs(ΔP))

end

end;

I guarantee this is a valid file. It's been tested during my last project. But I admit that the symbols are quite messy.

Can't reproduce, delete ~/.config/coc/extensions/coc-julia-data/ and try again.

Deleting ~/.config/coc/extensions/coc-julia-data/ didn't help.
But things are getting more clear now. First I moved the file away from the original working directory. The server didn't crash.   I tried again with other files in that directory. The server crashed. At this time I'm sure that there's a problem with my working directory. I looked through the subdirectories under it, discovering a .jl file that was actually formatted in terms of a CSV file.
That was a result of a temporary bug in my code. I was supposing to store the data in a CSV file, but I had a typo ending the file name with an extension of .jl. I deleted that file and the server haven't crashed since then.


Rewrite to_graph for better performance

Improve performance by eliminate excess allocations, streamlining operations.

Should I add more unit tests now?  It gets called about 5 times with the current set of unit tests (never explicitly, it's from internal calls testing other functions)