Performance data reports

I've been collecting some data using SmokePing to get a sense for Mycelium performance from my perspective at home. A description of the methodology and everything needed to reproduce my approach is on this repo.
In summary, I'm connecting to all public Mycelium nodes via IPv4 TCP and pinging them periodically both over Mycelium and over IPv4. This was meant mostly to be a benchmark to evaluate other Mycelium hosts against, but it's revealed some trends that I think are worth highlighting. For most of the public nodes, I observe large variations in latency over Mycelium versus regular IPv4.
Here are some high level graphs, first showing the IPv4 ping performance to the public nodes. The line represents median ping time, with the "smoke" representing deviations from the median:

We can see that latency to these nodes is basically flatline with occasional minor deviations. This sample is representative of the data I've collected so far.
Here's the same view, but for pings sent over Mycelium:

Sometimes the behavior over Mycelium seems to be related an issue also seen on regular IPv4, but sometimes not. Here's an example from the SG node of a rather substantial latency spike on Mycelium:

But IPv4 looks rather clean over the same time period:

Here's a case where the issue observed on IPv4 seems to be amplified over Mycelium. Here we see relatively high packet loss in purple and pink:

Versus relatively low packet loss over IPv4 at the same time:

Here's a longer window, showing the large latency swings and a period of packet loss on Mycelium:

Versus IPv4:

So what I see overall is that median latency over Mycelium can vary by 100% hour to hour for directly connected public peers, while the medians over IPv4 to the same nodes tend to vary by no more than 5-10%.
It also appears that small amounts of packet loss on the underlay network get amplified into larger packet loss over Mycelium.
However, the latency to my closest public peer, US West, is much more stable. That could of course a be a coincidence, which could be cleared up by running the same test from different locations.
It's possible that latency is shifting along with load on the public nodes, and perhaps strain on the Mycelium process could cause these results. I don't have visibility to say whether that's happening, but it doesn't seem likely at the current level of exposure the project has and also the lack of clear correlation between nodes for times of high latency.

Here's another look at some of the data, this time for a bit more of a "real world" test. I'm also executing both ping and SSH probes against two VMs that are running on Zos nodes in the GreenEdge St Gallen farm. Anecdotally there seems to be intermittent issues with SSH connections to Zos VMs over Mycelium, so the intention here was to try to capture that in action.
Here's the SSH probe results via Mycelium to one VM over a ten day period:

Here's the ping performance via Mycelium to the same VM for the same period:

Next I'll show ping performance over Mycelium to the four public nodes closest to St Gallen:

Also pings to those public nodes over IPv4:

I'm not sure which nodes exactly are involved in routing to this VM. All I can see in the Mycelium logs is that the next hop for the route is the public node US West. Here's the ping graph for both Mycelium and IPv4 for that node:

I suppose the traffic could also be traversing the US East node before crossing the pond, so for good measure:

So the summary is that we can notice some periods where there is significant loss of SSH messages over Mycelium which seem to have some correlation with ping packet loss over Mycelium as well.

There's quite some things going on here so I'll start by trying to explain a few of the behaviors seen here. The current mycelium transports are tcp and Quic reliable channels, which behave like tcp (ordered reliable delivery with acknowledgements and congestion control). This is actually not the greatest for an overlay network, since the overlay assumes it working on IP, which is by nature lossy. It would be better if we could use UDP, though right now plain UDP is not really feasible since we rely on the reliable semantics for the protocol messages. I have some work for using quic datagrams for actual data on a branch, though that needs more tuning it seems to be useful.
Packet loss in the underlay, when using these transports, generally translates to higher latencies due to retransmission, though it is interesting to see that packet loss is worse in the overlay.
Latency spikes are generally somewhat expected, since mycelium is a userspace process, where general network handling is done in the kernel (especially for ping). Currently we are doing continuous network throughput testing, in general this also causes spikes in packets handled every 5ish minutes, which translates to somewhat higher latency during these periods.
For ssh sessions, part of this is likely due to tcp metldown (the negative affect of packetloss in tcp in tcp, where both overlay and underlay sessions independently try to recover the lost packets, leading to them fighting against eachother).
In general, some more testing will have to be done in none optimal network conditions to see how the network behaves (high latency with some minor packet loss), but this is an interesting starting point

Thanks for the notes @LeeSmet. The challenges with tcp over tcp certainly make sense. That's also good to know about the throughput testing—I'll keep an eye out for any possible correlation with my charts.
Since my initial posts, things have started to look considerably worse. There's significantly increased packet loss and latency.
Here are some 30 hour charts for SSH probes to the first VM, comparing mycelium performance (top) with regular ipv6 performance (bottom):

And same for the second VM:

The ping charts for these VMs look basically the same.
There's also a similar pattern on the ping charts to the public mycelium nodes. For locales with two nodes, they are very similar so I just show one:
DE 1 Myc

DE 1 IPv4

BE 3 Myc

BE 3 IPv4

FI 5 Myc

FI 5 IPv4

US EAST Myc

US EAST IPv4

US WEST Myc

US WEST IPv4

SG Myc

SG IPv4

IND Myc

IND IPv4

One note here is that I'm not totally sure what the blank sections on the charts indicate. I think that means that the probe command failed with an error, rather than a timeout. That would track with the fact that I'm often seeing "no route" messages when trying to connect to freshly deployed Zos VMs over mycelium.

Hi @scottyeager @LeeSmet
I can reproduce it quite easily and can see the difference using ping i did three experiments, each of them only use one public node

using SG public node

it is the closest node from my place in Indonesia, ping time is ~20ms
it didn't work for me, even after 20 minutes i still got

Destination unreachable: No route

using my own public node in Amsterdam

it is in digitalocean
ping to other mycelium node in SG
not much difference between ipv4 ping time  and mycelium ping time
ipv4 ping time is ~180-200ms

use DE 1 public node

ping from my PC in my home to my VPS on SG, both using DE 1 public node
i have to wait for ~5-7 minutes for the  mycelium ping to work
mycelium ping time (600ms - thousand ms)  almost always much higher than ipv4 ping time (total ~400ms)

Considering that my ipv4 ping time to DE 1 and my own amsterdam is very similar, i suspect that the DE 1 public node is overloaded.
I think we could check in these three things:

check & improve the TCP over TCP issue

i read that one of the main issue is about RTO (retransmission timeout)
but how to see if we got this issue?

Whether the mycelium  facing scalability issue

discussed with Lee, we indeed have some potential performance issue on the routing part. I don't think that it relates to this issue

i think i'll check the data path. @LeeSmet maybe some pointer?

think about what we will do in case of overloaded node? because it eventually happen, or it might already happens?

keep receiving new connection, which could worsening the condition
do rate limiting or reject new connection:
- clearer condition from both the server & client side
- avoiding worsening the condition
- client will retry the connection and try other peers anyway
need to define "overloaded"

Make a tool to stress test the mycelium

so we could reproduce it easier
especially if we indeed found that the issue is scalability issue

It would be good if we can do profiling
is this the recommended way @LeeSmet ?
https://github.com/threefoldtech/mycelium/issues/141#issuecomment-2076641443

I did a bit check for the data paths:

I remember that there was a plan on doing TUN offload #141 .
@LeeSmet what is the state of TUN offload? Looks like it is a good idea. I found that tailscale also does the same thing

I found that tokio-tun has send_vectored
@LeeSmet any reason why Linux uses send while Macos uses write_vectored (although it is not used in a correct way)?

It is probably worth to compare rust-tun and tokio-tun
From a quick look, looks like not much difference. But still worth to take a closer look.

The TUN offload issue has been parked as its purely an optimization for the send/receive nodes. It can be done in the future once the system is completely stable.
The initial implementation is as simple as possible, so we just pull packets from the receiving channel and send them one by one on linux. On mac we use write_vectored since packets need to be preceded by a header on the tun device and this seemingly can't be disabled (like we do on linux), so write vectored here is just used as a way to cheaply send this header in the same syscall.
We could use tokio's channel recv_many on linux followed by a write vectored for some performance improvements for now, that should be a quick and easy fix. Note that there is a subtle difference between write_vectored and sending GSO enabled packets. Also, for mac this is slightly more cumbersome since every packet needs to be preceded by the header, so after getting a vector of potential packets from the channel we'd need to create a new vector where every even index is a packet header and every odd index is an actual packet.

The TUN offload issue has been parked as its purely an optimization for the send/receive nodes. It can be done in the future once the system is completely stable.

Ok, moved to the original issue at https://github.com/threefoldtech/mycelium/issues/141#issuecomment-2499818183

On mac we use write_vectored since packets need to be preceded by a header on the tun device and this seemingly can't be disabled (like we do on linux), so write vectored here is just used as a way to cheaply send this header in the same syscall.

Oh, yes, i just remember that you already told me about this, my bad,

We could use tokio's channel recv_many on linux followed by a write vectored for some performance improvements for now, that should be a quick and easy fix

cool,
Any concerns or things to note/check if i want to implement this?

We could use tokio's channel recv_many on linux followed by a write vectored for some performance improvements for now, that should be a quick and easy fix

I've tried this using below patch, the change is indeed small.
Here are my simple observation when testing the performance using scp:

the performance depend on max number of messages we want to receive with recv_many
if it is 1, the performance is similar
if it is more than 1, the performance is worse

I'm thinking why it worse:

the most obvious way is because my system is not busy enough, there is small chance that there are more than one message that ready to be consumed, so that it ended up waiting for another message without result
the send_vectored is indeed slow

diff --git a/mycelium/src/tun/linux.rs b/mycelium/src/tun/linux.rs
index 52b2b13..ccf5e9e 100644
--- a/mycelium/src/tun/linux.rs
+++ b/mycelium/src/tun/linux.rs
@@ -72,15 +72,35 @@ pub async fn new(
     // Spawn a single task to manage the TUN interface
     tokio::spawn(async move {
         let mut buf_hold = None;
+        let mut recv_vec = Vec::new();
+        let num = 2;
+        info!("IBK create recv_vec with num={}", num);
         loop {
             let mut buf = if let Some(buf) = buf_hold.take() {
                 buf
             } else {
                 PacketBuffer::new()
             };
-
+            use std::io::IoSlice;
             select! {
-                data = sink_receiver.recv() => {
+                num_buf = sink_receiver.recv_many(&mut recv_vec, num) => {
+                    if num_buf > 0 {
+                        //info!("data = {}", data);
+                         // Create IoSlice vector from PacketBuffers
+                         let io_slices: Vec<IoSlice> = recv_vec.iter()
+                         .map(|buf| IoSlice::new(&buf))
+                         .collect();
+
+                     if let Err(e) = tun.send_vectored(&io_slices).await {
+                         error!("Failed to send data to tun interface {e}");
+                     }
+                        recv_vec.clear(); // Clear for next use
+                    } else {
+                        return; // Channel closed
+                    }
+                    buf_hold = Some(buf);
+                }
+                /*data = sink_receiver.recv() => {
                     match data {
                         None => return,
                         Some(data) => {

It's unlikely that the implementation of recv_many is slower than that of recv, and the fact that setting num to 1 seems to support this point. There needs to be some detailed analysis with tools like perf/hotspot/samply,.... to figure out where the function is spending time. Note that tun.send_vectored requires IoSlices, and the current implementation which creates these actually creates these and collects them in a new vector, which means there is an allocation now on the hot path. If this is indeed an issue, it will be noticiable in a flamegraph

the most obvious thing is because my system is not busy enough, there is small chance that there are more than one message that ready to be consumed, so that it ended up waiting for another message without result
recv_many is slow, as depicted above

It's unlikely that the implementation of recv_many is slower than that of recv, and the fact that setting num to 1 seems to support this point.

Yes yes, i think both statements could be true:

recv_many is probably only slower for systems that are not busy  (in this case:  non public node)
It's unlikely that the implementation of recv_many is slower than that of recv, and the fact that setting num to 1 seems to support this point. -> it is also true

Just like the current case https://github.com/threefoldtech/mycelium/issues/459#issuecomment-2490754388:

using private node is fast
using public node is slow

There needs to be some detailed analysis with tools like perf/hotspot/samply,.

But the problem here, the result on private node could be misleading.
Except that we can create a load tester tool.

FYI, i discarded the work on TUN.
It was started because i misunderstood how TUN device being used in the mycelium.
Because Lee works on the routing part, i'm checking the data path.
Some improvements was merged yesterday at #528.
Now i'm digging deeper on how the peer's data path works.


chore: replace type by lang on svelte script

:tada: This PR is included in version 1.55.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


default db is created is relative and not always gecko/db

Default db should at gecko/db. Looks like it is not gecko/db all the time.
i am running node with go run main.go to understand the code and debug. i see db folder is created under gecko/main package.

I think db will be created at the current working directory, right? @StephenButtolph If yes, then that's desired behavior.

@Determinant  Thanks for your response.
It shouldn't be relative to binary folder. binary can be run in any folder. data and logs folder are should be created always in fixed paths and not relative to current directory. thoughts ?

I think we already have something on this: https://github.com/ava-labs/gecko/pull/115. :)


fix(mongodb): update mongodb driver

Updating the mongodb driver to fix crashes on production (backup/master) while running locally.
I think I was able to reproduce the crash on the login path, every time  by doing a clean install of the code (clone, install mongo 3.X)

Ideally we may want to check and do a minor bump on related dependancies, but if just moving over to the beta is high priority. We can ignore doing that.
That said updating the driver is good idea because we do use the latest LTS for both Node, and MongoDB

@raisedadead what was the main issue with the older driver?

@BerkeleyTrue
I kept getting crashes very frequently during login (on backup/master), which I initially thought to be some issue in LoopBack.
But digging deeper I could see that locally I have MongoDB 3.6 which is the current LTS.
See https://docs.mongodb.com/manual/release-notes/
And the we had an incompatible driver 2.x, which needed to be > 3.x
See https://docs.mongodb.com/ecosystem/drivers/driver-compatibility-reference/
As soon as I updated the driver, I saw the issue resolved.
In any case the driver is reverse compatible. So, if we are not using LTS on production, we should ideally be safe?
But, I'll nonetheless let you decide the action.


Simplification of boost implemetation

There seems to be a simpler way to implement the Lorentz boost of a space-time vector, using a matrix transformation, with something called a "boost matrix". Details are here: https://en.wikipedia.org/wiki/Lorentz_transformation#Proper_transformations
Something like the following seems to work at first glance for 3+1 spacetime. It would need to be generalized to N+1, and batched inputs would need to be supported. I think it is easier to follow this code than the current implementation of boost
def boost(x, v):
    gamma = 1 / np.sqrt(1 - np.dot(v, v))
    boost_matrix = np.zeros((4, 4))
    boost_matrix[0, 0] = gamma
    boost_matrix[0, 1:] = -gamma * v
    boost_matrix[1:, 0] = -gamma * v
    boost_matrix[1:, 1:] = np.eye(3) + (gamma - 1) * np.outer(v, v) / np.dot(v, v)
    return boost_matrix @ x

It would be interesting to see how the performance of this implementation compares to the current one. It seems to use fewer operations, because it includes the position and time coordinate calculations in the same matrix-vector multiplication, rather than splitting it up, so there is reason to believe that it might be faster

Performance improvements are documented here: https://github.com/kurtamohler/spacetimelib/blob/c0d7f13b347da6436efeffe9ae3581ece77e3ab5/notebooks/Performance.ipynb
Using a boost matrix did turn out to be significantly faster.


Need for Different Place Properties for Bikes

We would suggest the following sub types under BICYCLE for these H/H codes to refine bike spaces:

BICYCLE_LOW
BICYCLE_MIDDLE
BICYCLE_HIGH

For places that are not further defined, we would probably continue to simply use BICYCLE. In relation to our fleet, these designations would be complete.

Document with additional information is being prepared.

240513_Bezeichnungen_Veloplätze_Subtypes.pdf

Reasoning why this distinction is important to us:

We receive numerous customer reactions, especially from older customers (seniors) with heavy bikes, that they are not able to put the bikes in the high holders. Correspondingly better communication is often required (today you have to know which train has which brackets).

In trains that have high racks (sometimes also medium ones), the same customers simply place their bikes next to them and thus sometimes block the passages. the space that would be intended for other user groups (strollers, luggage).

We can only communicate line-specifically in a few cases what kind of bike hooks are on the train, because we often have two different types on the train, sometimes even in the car (just as the DB has two different hooks on the ICE4 in the same zone, medium/high ).

In general, we are convinced that the bike topic is here to stay and that the demand for self-loading bicycles will continue to increase.

Ralf will involve DB


Wrong code implementation in forest/binary_trees/single_threaded_binary_trees.py

@shunsvineyard
Use the following input:
tree = RightThreadedBinaryTree()
tree.insert(key=4, data="")
tree.insert(key=1, data="")
tree.insert(key=7, data="")
tree.insert(key=3, data="")
tree.insert(key=5, data="")
tree.insert(key=2, data="")
tree.insert(key=6, data="")
print(tree)
This will raise an error:
Traceback (most recent call last):
File "d:\BDSync\Coding\jus\forest-python-by-shun\forest\binary_trees\single_threaded_binary_trees.py", line 275, in
print(tree)
File "d:\BDSync\Coding\jus\forest-python-by-shun\forest\binary_trees\single_threaded_binary_trees.py", line 86, in repr
f"tree_height={str(self.get_height(self.root))}"
File "d:\BDSync\Coding\jus\forest-python-by-shun\forest\binary_trees\single_threaded_binary_trees.py", line 218, in get_height
RightThreadedBinaryTree.get_height(node.right),
File "d:\BDSync\Coding\jus\forest-python-by-shun\forest\binary_trees\single_threaded_binary_trees.py", line 218, in get_height
RightThreadedBinaryTree.get_height(node.right),
File "d:\BDSync\Coding\jus\forest-python-by-shun\forest\binary_trees\single_threaded_binary_trees.py", line 215, in get_height
if node.left and node.is_thread is False:
AttributeError: 'NoneType' object has no attribute 'left'
The problem seems to lie in the get_height() method.

The bug has been fixed and merged. https://github.com/shunsvineyard/forest-python/pull/27


[WIP] Docs re/ Advanced Node on Azure

This is work-in-progress.
I've been trying to figure out the lowest-hassle way to deploy a Kubernetes-orchestrated BigchainDB node on Azure, by trying several ways. This approach, using the Azure CLI 2.0, is the most promising so far.
I'm writing the docs as I go.
Note that I renamed the section "Cloud Deployment Starter Templates" to be just "Cloud Deployment Templates".

Codecov Report

Merging #1190 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1190   +/-   ##
=======================================
  Coverage   96.92%   96.92%
=======================================
  Files          49       49
  Lines        2279     2279
=======================================
  Hits         2209     2209
  Misses         70       70

Continue to review full report at Codecov.

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


Fix issue with uCOS and a few other things.

@JimothyGreene @babusid There's a register that gets set when there's a hard fault that tells you what caused the hard fault.

@JimothyGreene @babusid There's a register that gets set when there's a hard fault that tells you what caused the hard fault.

What register is it? Just for future reference if we hit any other hard faults

@JimothyGreene @babusid There's a register that gets set when there's a hard fault that tells you what caused the hard fault.

What register is it? Just for future reference if we hit any other hard faults

I think it is the CFSR register, which I found described in this article


Decision on new or existing format

Based on the outcomes of #4, #5, #7, #9, it should be checked
if/which any of the existing https://github.com/HUPO-PSI/SpectralLibraryFormat/tree/master/legacy-formats
can already encode the required information, or how much (little)
would be required to extend an existing format. Plus, one of the areas where PSI excels
is to create controlled vocabularies, harmonise adoption and provide validators,
so libraries and software can claim they are supporting the PSI SpectralLibraryFormat.

@sneumannwe have discussed on PSI about this issue of the extension. Some of the points that trigger the decision on creating a new format extension:

It will be confusing for the end user to know if the file format is the one developed by PSI or the proprietary one.
@jshofstahl mentioned for example that msp is a proprietary format and also a windows extension.
We don't have the right to change the file format of somebody else.
We agree to align as much as possible the current file formats to the new file enabling readers/writers to easily transform current legacy representations to the file format. For that reason, we discuss that we need to focus now the discussion around which metadata is mandatory/optional at spectrum and library levels.

Note, in the google docs I added a link to some investigations into the MSP format I once did. The NIST library converter does in fact allow roundtripping of some undocumented entries.
If anything like MSP should be chosen as a base format, the most fruitful idea IMO would be to try to get NIST / S. Stein onboard. In that case

there is no issue of changing "someone else's" file format
if NIST themselves adopt "our" changes, the format will be immediately widely distributed.

@meowcat I fully agree with you. @edeutsch can we contact the NIST people to be involved in this development. If they agree we can keep the msp name. However, if they are not involved, it will be difficult to maintain the name because then it will be two representations for the same file type. The current document is trying to capture the metadata at the library level:
https://docs.google.com/document/d/1LgSGtR_t5IcUS9rV7YtsLveDVX9X8KsOpU-5NJ4vuYI/edit?usp=sharing

Yes, we can and should and will. We should also get Paul Rudnick involved if he still so wishes.

Another thought that has crossed my mind would be that it would be nice to have a format that has a very simple canonical transformation to YAML. Both the MassBank and msp formats are actually not that far from it.

Since, we settled on multiple representations of the format, using the same controlled vocabulary and principles, this issue can be closed.


add Policy resource

Adds the Policy resource Kind to the IAM controller. Note that currently
the Update code paths are not supported. This is because the Policy
resource in the IAM API does not support updates. Instead, you need to
call CreatePolicyVersion/DeletePolicyVersion. I will implement this as
custom update code paths in a future PR.
Signed-off-by: Jay Pipes<EMAIL_ADDRESS>aws-controllers-k8s/community#222
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

/lgtm


Fix AggregateEventRecord test data creation.

Now any test AggregateEventRecord created with io.spine.server.aggregate.Given.StorageRecord will have a KindCase. By default it is EVENT.

@armiol, PTAL.


Update README.md

repectively -> respectively

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


Likely bug in get_bits at end of stream when count > 8

Introduction
I'm in the process of porting heatshrink to typescript for use with a mobile app that deals with heatshrink data from an embedded device.  As I was porting and testing the get_bits function I noticed what appears to be an edge case bug.
The comment in get_bits indicates that if there are not enough bits in the input buffer to satisfy count it should suspend immediately and not consume any bits, however the check for this condition linked below appears to miss a case when count > 8 since it only performs the check if there are no more whole bytes left.
Example situation
input_buffer: [1, 2]
input_index: 1
input_size: 2
bit_index: 1
current_byte: 1
count: 10

In this situation the user is asking for 10 bits but there are only 9 bits remaining in the input buffer (8 from the last byte and one remaining in the current byte.  As I understand the code it will consume current byte before suspending, which I suspect is incorrect.
Could you please clarify if this was the intended behavior or a latent bug?  It appears it could only affect situations with a window size > 8 bits based on a preliminary reading of the usage of get_bits.
Link to Relevant Code
https://github.com/atomicobject/heatshrink/blob/master/heatshrink_decoder.c#L298

Hey,
I think I'm hitting a similar issue - my consume buffer size is 0x100, compressed data size is 0x101, and in the loop after consuming 0x100 bytes the decoder just keeps spinning and decoding garbage - which I think is related to this "suspend without consuming" issue you talk about.
Did you ever figure out how to fix it?

@trollcop I never did resolve the code issue but I believe the bug only applies when you have a window size > 8 bits, which we needed to stay below anyway to minimize RAM usage so it didn't end up affecting us.

I haven't had much spare time for heatshrink for a while, but I'm planning on cutting a release in the next week or two with several fixes integrated.

In case it's helpful, I fixed the get_bits implementation logic for count > 8 window size in our typescript port and the port was just a direct function by function translation, so the fix should map well back to C.  The relevant code is here:
https://github.com/iotile/heatshrink-ts/blob/master/src/heatshrink-utils.ts#L39

@silentbicycle

@trollcop, when you say "my consume buffer size is 0x100, compressed data size is 0x101, and in the loop after consuming 0x100 bytes the decoder just keeps spinning and decoding garbage", what is the return value from heatshrink_decoder_poll?

Hey, no, I figured it out and it was my issue, not heatshrink. I've added heatshrink_decoder_sink_const() to be able to decode from flash buffer directly (embedded code, no need to copy into ram buffers), but the problem was as I was pushing HEATSHRINK_STATIC_INPUT_BUFFER_SIZE blocks into decoder, and compressed data wasn't aligned at 256 bytes, the final block would be longer and result in garbage decoding. Once I modified the input loop to end at compressed_data_size bytes to push, garbage decoding doesn't happen anymore. Sorry for a false alarm.


Wayland Protocol impl improvements

Stuff to ease development down the line
more might come
cc @TheSunCat he always seems to be crashing
cc @fufexan for review

Crashing randomly on window close with this patch applied.
Crash report:
[apm@apg ~]$ cat .cache/hyprland/hyprlandCrashReport7001.txt
--------------------------------------------
   Hyprland Crash Report
--------------------------------------------
Vaxry is going to be upset.

Hyprland received signal 6 (Aborted)

Version: 126792584fa4eb25f6c8e3b3eb6bfb00b58a787a
Tag: v0.28.0-28-g12679258

System info:
	System name: Linux
	Node name: apg
	Release: 6.4.8-201.fsync.fc38.x86_64
	Version: #1 SMP PREEMPT_DYNAMIC Sat Aug  5 23:34:20 UTC 2023

GPU:
	03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 23 [Radeon RX 6650 XT / 6700S / 6800S] [1002:73ef] (rev c2) (prog-if 00 [VGA controller])
37:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt [Radeon 680M] [1002:1681] (rev c7) (prog-if 00 [VGA controller])

os-release:
	NAME="Arch Linux"
	PRETTY_NAME="Arch Linux"
	ID=arch
	BUILD_ID=rolling
	ANSI_COLOR="38;2;23;147;209"
	HOME_URL="https://archlinux.org/"
	DOCUMENTATION_URL="https://wiki.archlinux.org/"
	SUPPORT_URL="https://bbs.archlinux.org/"
	BUG_REPORT_URL="https://bugs.archlinux.org/"
	PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
	LOGO=archlinux-logo

Backtrace:
	#0 | Hyprland(_ZN13CrashReporter18createAndSaveCrashEi+0x75e) [0x5580798c909e]
		??
		??:0
	#1 | Hyprland(_Z25handleUnrecoverableSignali+0x3c) [0x55807986143c]
		??
		??:0
	#2 | /usr/lib/libc.so.6(+0x3e710) [0x7f6c7d83e710]
		??
		??:0
	#3 | /usr/lib/libc.so.6(+0x8e83c) [0x7f6c7d88e83c]
		??
		??:0
	#4 | /usr/lib/libc.so.6(raise+0x18) [0x7f6c7d83e668]
		??
		??:0
	#5 | /usr/lib/libc.so.6(abort+0xd7) [0x7f6c7d8264b8]
		??
		??:0
	#6 | /usr/lib/libc.so.6(+0x27390) [0x7f6c7d827390]
		??
		??:0
	#7 | /usr/lib/libc.so.6(+0x987b7) [0x7f6c7d8987b7]
		??
		??:0
	#8 | /usr/lib/libc.so.6(+0x9a66e) [0x7f6c7d89a66e]
		??
		??:0
	#9 | /usr/lib/libc.so.6(free+0x73) [0x7f6c7d89d7b3]
		??
		??:0
	#10 | Hyprland(+0x1b960e) [0x55807997860e]
		??
		??:0
	#11 | Hyprland(+0x1b9810) [0x558079978810]
		??
		??:0
	#12 | /usr/lib/libffi.so.8(+0x74f6) [0x7f6c7d5364f6]
		??
		??:0
	#13 | /usr/lib/libffi.so.8(+0x3f5e) [0x7f6c7d532f5e]
		??
		??:0
	#14 | /usr/lib/libffi.so.8(ffi_call+0x123) [0x7f6c7d535b73]
		??
		??:0
	#15 | /usr/lib/libwayland-server.so.0(+0x8ada) [0x7f6c7e63dada]
		??
		??:0
	#16 | /usr/lib/libwayland-server.so.0(+0xd180) [0x7f6c7e642180]
		??
		??:0
	#17 | /usr/lib/libwayland-server.so.0(wl_event_loop_dispatch+0xa2) [0x7f6c7e640ae2]
		??
		??:0
	#18 | /usr/lib/libwayland-server.so.0(wl_display_run+0x27) [0x7f6c7e6412d7]
		??
		??:0
	#19 | Hyprland(main+0xa91) [0x558079851461]
		??
		??:0
	#20 | /usr/lib/libc.so.6(+0x27cd0) [0x7f6c7d827cd0]
		??
		??:0
	#21 | /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7f6c7d827d8a]
		??
		??:0
	#22 | Hyprland(_start+0x25) [0x5580798612e5]
		??
		??:0

Log tail:
[LOG] Window got assigned a surfaceTreeNode 0
[LOG] Registered signal for owner 55807b3ddd80: 55807b3dd5c0 -> 55807b3ddd80 (owner: XDG Window Late)
[LOG] Registered signal for owner 55807b3ddd80: 55807b3ddc30 -> 55807b3ddf20 (owner: XDG Window Late)
[LOG] Registered signal for owner 55807b3ddd80: 55807b3dd800 -> 55807b3de058 (owner: XDG Window Late)
[LOG] Registered signal for owner 55807b3ddd80: 55807b3ddbc0 -> 55807b3de190 (owner: XDG Window Late)
[LOG] Registered signal for owner 55807b3ddd80: 55807b3ddbe0 -> 55807b3de128 (owner: XDG Window Late)
[LOG] Registered signal for owner 55807b3ddd80: 55807b3ddbf0 -> 55807b3de0c0 (owner: XDG Window Late)
[LOG] Registered signal for owner 55807b3ddd80: 55807b3ddc00 -> 55807b3de1f8 (owner: XDG Window Late)
[LOG] Registered signal for owner 55807b3ddd80: 55807b3ddbd0 -> 55807b3ddff0 (owner: XDG Window Late)
[LOG] Registered signal for owner 55807af564e0: 55807b3dd5f0 -> 55807af56558 (owner: SurfaceTreeNode)
[LOG] Registered signal for owner 55807af564e0: 55807b3dd5c0 -> 55807af565c0 (owner: SurfaceTreeNode)
[LOG] Registered signal for owner 55807af564e0: 55807b3dd600 -> 55807af56628 (owner: SurfaceTreeNode)
[LOG] Added a new subsurface 55807b3df690
[LOG] Registered signal for owner 55807b3c3450: 55807b3df530 -> 55807b3c3468 (owner: Subsurface)
[LOG] Registered signal for owner 55807b3c3450: 55807b3df540 -> 55807b3c34d0 (owner: Subsurface)
[LOG] Registered signal for owner 55807b3c3450: 55807b3df710 -> 55807b3c3538 (owner: Subsurface)
[LOG] Creating a surfaceTree Root! (pWindow: 55807b3ddd80)
[LOG] Map request dispatched, monitor eDP-2, xywh: 1030.000000 68.000000 1011.000000 1205.000000
[LOG] Keybind triggered, calling dispatcher (64, , 120)
[LOG] Window 55807b3ddd80 unmapped (class foot)
[LOG] Unregistered late callbacks XDG
[LOG] Callback 55807b3ddda8 -> 55807b3ddda0, XDG Window Late removed.
[LOG] Callback 55807b3ddf48 -> 55807b3ddf40, XDG Window Late removed.
[LOG] Callback 55807b3de080 -> 55807b3de078, XDG Window Late removed.
[LOG] Callback 55807b3de1b8 -> 55807b3de1b0, XDG Window Late removed.
[LOG] Callback 55807b3de150 -> 55807b3de148, XDG Window Late removed.
[LOG] Callback 55807b3de0e8 -> 55807b3de0e0, XDG Window Late removed.
[LOG] Callback 55807b3de220 -> 55807b3de218, XDG Window Late removed.
[LOG] Callback 55807b3de018 -> 55807b3de010, XDG Window Late removed.
[LOG] Framebuffer created, status 36053
[LOG] On closed window, new focused candidate is 55807b3d5e60
[LOG] Set keyboard focus to surface 55807b3bf6c0, with window name: foot
[LOG] Destroying the SubSurface tree of unmapped window 55807b3ddd80
[LOG] Callback 55807b3c3560 -> 55807b3c3558, Subsurface removed.
[LOG] Callback 55807b3c3490 -> 55807b3c3488, Subsurface removed.
[LOG] Callback 55807b3c34f8 -> 55807b3c34f0, Subsurface removed.
[LOG] Callback 55807af565e8 -> 55807af565e0, SurfaceTreeNode removed.
[LOG] Callback 55807af56650 -> 55807af56648, SurfaceTreeNode removed.
[LOG] Callback 55807af56580 -> 55807af56578, SurfaceTreeNode removed.
[LOG] SurfaceTree Node removed
[LOG] Callback 55807b3de3c0 -> 55807b3de3b8, Toplevel removed.
[LOG] Callback 55807b3de358 -> 55807b3de350, Toplevel removed.
[LOG] Callback 55807b3de428 -> 55807b3de420, Toplevel removed.
[LOG] Callback 55807b3de5d0 -> 55807b3de5c8, CWLSurface removed.
[LOG] CWLSurface 55807b3de5a0 called destroy()
[LOG] Callback 55807b3dde78 -> 55807b3dde70, CWindow removed.
[LOG] Window 55807b3ddd80 destroyed, queueing. (class )
[LOG] Callback 55807b3dde10 -> 55807b3dde08, XDG Window removed.
[LOG] Callback 55807b3ddee0 -> 55807b3dded8, XDG Window removed.
[ERR] onWindowRemovedTiling node null?

@TheSunCat check now, doesnt seem to crash for me anymore

The peck, building this caused Hyprland to crash. Building this.
But hey after building it from tty it doesn't seem to crash!

ready to review & merge
cc @fufexan for code
cc @TheSunCat for crash testing

we crashin my man
--------------------------------------------
   Hyprland Crash Report
--------------------------------------------
This was an accident, I swear!

Hyprland received signal 11 (Segmentation fault)

Version: 3f7f4207a6dd8bd217c01514ea40e9e4b9b7874a
Tag: v0.28.0-34-g3f7f4207

System info:
	System name: Linux
	Node name: apg
	Release: 6.4.8-201.fsync.fc38.x86_64
	Version: #1 SMP PREEMPT_DYNAMIC Sat Aug  5 23:34:20 UTC 2023

GPU:
	03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 23 [Radeon RX 6650 XT / 6700S / 6800S] [1002:73ef] (rev c2) (prog-if 00 [VGA controller])
37:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt [Radeon 680M] [1002:1681] (rev c7) (prog-if 00 [VGA controller])

os-release:
	NAME="Arch Linux"
	PRETTY_NAME="Arch Linux"
	ID=arch
	BUILD_ID=rolling
	ANSI_COLOR="38;2;23;147;209"
	HOME_URL="https://archlinux.org/"
	DOCUMENTATION_URL="https://wiki.archlinux.org/"
	SUPPORT_URL="https://bbs.archlinux.org/"
	BUG_REPORT_URL="https://bugs.archlinux.org/"
	PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
	LOGO=archlinux-logo

Backtrace:
	#0 | Hyprland(_Z12getBacktracev+0x48) [0x55ffc69c2c78]
		??
		??:0
	#1 | Hyprland(_ZN13CrashReporter18createAndSaveCrashEi+0x76e) [0x55ffc6992a6e]
		??
		??:0
	#2 | Hyprland(_Z25handleUnrecoverableSignali+0x3c) [0x55ffc692a50c]
		??
		??:0
	#3 | /usr/lib/libc.so.6(+0x3e710) [0x7fb9ffe3e710]
		??
		??:0
	#4 | /usr/lib/libwayland-server.so.0(wl_resource_post_event+0xab) [0x7fba00b3cdab]
		??
		??:0
	#5 | Hyprland(_ZN18CXDGOutputProtocol19updateOutputDetailsEP10SXDGOutput+0x68) [0x55ffc6a42e28]
		??
		??:0
	#6 | Hyprland(+0x1bc58b) [0x55ffc6a4358b]
		??
		??:0
	#7 | Hyprland(_ZN18CHookSystemManager4emitEPKSt6vectorI14SCallbackFNPtrSaIS1_EESt3any+0x2e0) [0x55ffc69f5cd0]
		??
		??:0
	#8 | Hyprland(_ZN14CConfigManager20performMonitorReloadEv+0x245) [0x55ffc696c225]
		??
		??:0
	#9 | Hyprland(_ZN13CHyprRenderer13renderMonitorEP8CMonitor+0xf35) [0x55ffc6a5c425]
		??
		??:0
	#10 | Hyprland(_Z13handleWrappedP11wl_listenerPv+0x3c) [0x55ffc69d187c]
		??
		??:0
	#11 | /usr/lib/libwayland-server.so.0(wl_signal_emit_mutable+0x7e) [0x7fba00b3c01e]
		??
		??:0
	#12 | /home/apm/Hyprland/subprojects/wlroots/build/libwlroots.so.12032(+0x57fa8) [0x7fba00bdcfa8]
		??
		??:0
	#13 | /usr/lib/libdrm.so.2(drmHandleEvent+0xff) [0x7fba00b0b9af]
		??
		??:0
	#14 | /home/apm/Hyprland/subprojects/wlroots/build/libwlroots.so.12032(+0x5a519) [0x7fba00bdf519]
		??
		??:0
	#15 | /usr/lib/libwayland-server.so.0(wl_event_loop_dispatch+0xa2) [0x7fba00b3dae2]
		??
		??:0
	#16 | /usr/lib/libwayland-server.so.0(wl_display_run+0x27) [0x7fba00b3e2d7]
		??
		??:0
	#17 | Hyprland(main+0xa91) [0x55ffc691a531]
		??
		??:0
	#18 | /usr/lib/libc.so.6(+0x27cd0) [0x7fb9ffe27cd0]
		??
		??:0
	#19 | /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7fb9ffe27d8a]
		??
		??:0
	#20 | Hyprland(_start+0x25) [0x55ffc692a3b5]
		??
		??:0

Log tail:
[LOG] Callback 55ffc90615f0 -> 55ffc90615e8, SurfaceTreeNode removed.
[LOG] Callback 55ffc9061520 -> 55ffc9061518, SurfaceTreeNode removed.
[LOG] SurfaceTree Node removed
[LOG] Callback 55ffc906c420 -> 55ffc906c418, Toplevel removed.
[LOG] Callback 55ffc906c3b8 -> 55ffc906c3b0, Toplevel removed.
[LOG] Callback 55ffc906c488 -> 55ffc906c480, Toplevel removed.
[LOG] Callback 55ffc906c630 -> 55ffc906c628, CWLSurface removed.
[LOG] CWLSurface 55ffc906c600 called destroy()
[LOG] Callback 55ffc906bed8 -> 55ffc906bed0, CWindow removed.
[LOG] Window 55ffc906bde0 destroyed, queueing. (class )
[LOG] Callback 55ffc906be70 -> 55ffc906be68, XDG Window removed.
[LOG] Callback 55ffc906bf40 -> 55ffc906bf38, XDG Window removed.
[ERR] onWindowRemovedTiling node null?
[LOG] Registered signal for owner 55ffc904e120: 55ffc9062090 -> 55ffc904e300 (owner: layerSurface)
[LOG] Registered signal for owner 55ffc904e120: 55ffc9092850 -> 55ffc904e1c8 (owner: layerSurface)
[LOG] Registered signal for owner 55ffc904e120: 55ffc90620a0 -> 55ffc904e230 (owner: layerSurface)
[LOG] Registered signal for owner 55ffc904e120: 55ffc90620b0 -> 55ffc904e298 (owner: layerSurface)
[LOG] Registered signal for owner 55ffc904e120: 55ffc9092860 -> 55ffc904e368 (owner: layerSurface)
[LOG] LayerSurface 55ffc9092790 (namespace gtk-layer-shell layer 2) created on monitor eDP-2
[LOG] LayerSurface 55ffc8d5e150 arranged: x: 0 y: 0 w: 2048 h: 1280 with margins: t: 0 l: 0 r: 0 b: 0
[LOG] LayerSurface 55ffc9043630 arranged: x: -1 y: 0 w: 2050 h: 69 with margins: t: 0 l: 0 r: 0 b: 0
[LOG] Monitor eDP-2 layers arranged: reserved: 0.000000 0.000000 0.000000 0.000000
[LOG] Socket 2 accepted a new client at FD 89
[LOG] Socket 2 accepted a new client at FD 145
[LOG] Socket 2 accepted a new client at FD 153
[LOG] Socket 2 accepted a new client at FD 155
[LOG] LayerSurface 55ffc9092790 mapped
[LOG] Registered signal for owner 55ffc904e140: 55ffc90620d0 -> 55ffc904e148 (owner: CWLSurface)
[LOG] CWLSurface 55ffc904e140 called init()
[LOG] LayerSurface 55ffc8d5e150 arranged: x: 0 y: 0 w: 2048 h: 1280 with margins: t: 0 l: 0 r: 0 b: 0
[LOG] LayerSurface 55ffc9043630 arranged: x: -1 y: 0 w: 2050 h: 69 with margins: t: 0 l: 0 r: 0 b: 0
[LOG] Monitor eDP-2 layers arranged: reserved: 0.000000 0.000000 0.000000 0.000000
[LOG] Socket 2 accepted a new client at FD 157
[LOG] Registered signal for owner 55ffc90692e0: 55ffc9068390 -> 55ffc90694c0 (owner: layerSurface)
[LOG] Registered signal for owner 55ffc90692e0: 55ffc904dcc0 -> 55ffc9069388 (owner: layerSurface)
[LOG] Registered signal for owner 55ffc90692e0: 55ffc90683a0 -> 55ffc90693f0 (owner: layerSurface)
[LOG] Registered signal for owner 55ffc90692e0: 55ffc90683b0 -> 55ffc9069458 (owner: layerSurface)
[LOG] Registered signal for owner 55ffc90692e0: 55ffc904dcd0 -> 55ffc9069528 (owner: layerSurface)
[LOG] LayerSurface 55ffc904dc00 (namespace gtk-layer-shell layer 3) created on monitor eDP-2
[LOG] LayerSurface 55ffc8d5e150 arranged: x: 0 y: 0 w: 2048 h: 1280 with margins: t: 0 l: 0 r: 0 b: 0
[LOG] LayerSurface 55ffc9043630 arranged: x: -1 y: 0 w: 2050 h: 69 with margins: t: 0 l: 0 r: 0 b: 0
[LOG] LayerSurface 55ffc9040920 arranged: x: -1 y: 1279 w: 2050 h: 1 with margins: t: 0 l: 0 r: 0 b: 0
[LOG] Monitor eDP-2 layers arranged: reserved: 0.000000 0.000000 0.000000 0.000000
[LOG] Hyprctl: keyword monitor : eDP-2,addreserved,61,0,0,0
[LOG] Applying monitor rule for eDP-2
[LOG] Not applying a new rule to eDP-2 because it's already applied!
[LOG] LayerSurface 55ffc8d5e150 arranged: x: 0 y: 0 w: 2048 h: 1280 with margins: t: 0 l: 0 r: 0 b: 0
[LOG] LayerSurface 55ffc9043630 arranged: x: -1 y: 0 w: 2050 h: 69 with margins: t: 0 l: 0 r: 0 b: 0
[LOG] LayerSurface 55ffc9040920 arranged: x: -1 y: 1279 w: 2050 h: 1 with margins: t: 0 l: 0 r: 0 b: 0
[LOG] Monitor eDP-2 layers arranged: reserved: 0.000000 61.000000 0.000000 0.000000

try now @TheSunCat

Not crashing here!

nice speed

@fufexan ready for review

@vaxerski don't you need to fix the conflict before I review?

the conflict is just git being confused


feat(element-templates): display description of custom properties

Closes #167

Didn't we agree to bundle everything into one artifact for design review and not conduct individual ones?
What I can see in the screenshot looks good but I would need to see a real-world example to assess all aspects, like line-height, for instance. Also, we have descriptions on other places such as variable descriptions for I/O.

Didn't we agree to bundle everything into one artifact for design review and not conduct individual ones?
What I can see in the screenshot looks good but I would need to see a real-world example to assess all aspects, like line-height, for instance. Also, we have descriptions on other places such as variable descriptions for I/O.

I wasn't sure if it was only till the last demo or till we have a finished implementation of the whole epic. I'll remove the assignment then and thank you for the notice.

We did not expose this one to npm run start:templates, right? I think we should to complete our manual testing coverage.

I created an issue for this: https://github.com/bpmn-io/bpmn-properties-panel/issues/179
Thanks for the review!


crash on helpGetActorRegistryID in Mob::die

To Reproduce
Steps to reproduce the behavior:
I really don't know this
Error logs
[ Native Crash ]
Last packet from IP:
[ Native Stack ]
EXCEPTION_ACCESS_VIOLATION(0xc0000005), Accessing an invalid memory address at 0x0000000000000000
at bedrock_server.exe!ScriptApi::WORKAROUNDS::helpGetActorRegistryID
at bedrock_server.exe!ScriptApi::WORKAROUNDS::helpRegisterActor
at bedrock_server.exe!ScriptBinderActorTemplate::build
at bedrock_server.exe!ScriptEngineWithContext::helpDefineActor
at bedrock_server.exe!ScriptServerActorDeathEvent::_serialize
at bedrock_server.exe!ScriptEngineWithContext::fireEvent
at bedrock_server.exe!ScriptServerActorEventListener::onActorDeath
at bedrock_server.exe!EventCoordinator::processEvent
at bedrock_server.exe!ActorEventCoordinator::sendActorDeath
at bedrock_server.exe!Actor::die
at bedrock_server.exe!Mob::die
at  callNativeFunction
at
at  callJsFunction
at bedrock_server.exe!Mob::hurtEffects
at bedrock_server.exe!Mob::_hurt
at bedrock_server.exe!Actor::hurt
at  callNativeFunction
at
at  callJsFunction
at bedrock_server.exe!Player::attack
at  callNativeFunction
at
at  callJsFunction
at bedrock_server.exe!std::_Func_impl_no_alloc<<lambda_0abcacaff1369eda901bca53e0b00bd5>,void>::_Do_call
at bedrock_server.exe!Container::createTransactionContext
at bedrock_server.exe!PlayerInventory::createTransactionContext
at bedrock_server.exe!GameMode::attack
at bedrock_server.exe!std::_Func_impl_no_alloc<<lambda_a63e4488858e56b0ae213650f8543200>,void>::_Do_call
at bedrock_server.exe!Container::createTransactionContext
at bedrock_server.exe!PlayerInventory::createTransactionContext
at bedrock_server.exe!ItemUseOnActorInventoryTransaction::handle
at bedrock_server.exe!ServerNetworkHandler::handle
at  packetAfterHook
at bedrock_server.exe!NetworkHandler::_sortAndPacketizeEvents
at bedrock_server.exe!<lambda_494337cfa0aad2508666999d1e7c99de>::operator()
at bedrock_server.exe!NetworkHandler::runEvents
at bedrock_server.exe!Minecraft::update
at bedrock_server.exe!ServerInstance::_update
at bedrock_server.exe!<lambda_8914ed82e3ef519cb2a85824fbe333d8>::operator()
at  gameThreadEntry
at chakra.dll!AsyncTask::open'::5'::<lambda_1>::operator() (bdsx-core\nodegate.cpp:198)
at chakra.dll!uv_process_reqs (node\uv\src\win\req-inl.h:195)
at chakra.dll!uv_run (node\uv\src\win\core.c:519)
at chakra.dll!node::Start (node\node.cc:2172)
at chakra.dll!node::Start (node\node.cc:2425)
at chakra.dll!nodeStart (bdsx-core\main.cpp:70)
at bedrock_server.exe!__scrt_common_main_seh
at KERNEL32.DLL!BaseThreadInitThunk
at ntdll.dll!RtlUserThreadStart
[ JS Stack ]
at Anonymous function (Function code:8:1)
at onEntityDie (C:\Users\Administrator\Desktop\luminous-server\bdsx\event_impl\entityevent.ts:321:5)
at Anonymous function (Function code:8:1)
at Anonymous function (Function code:11:1)
at onEntityHurt (C:\Users\Administrator\Desktop\luminous-server\bdsx\event_impl\entityevent.ts:303:5)
at Anonymous function (Function code:11:1)
at Anonymous function (Function code:9:1)
at onPlayerAttack (C:\Users\Administrator\Desktop\luminous-server\bdsx\event_impl\entityevent.ts:397:5)
at Anonymous function (Function code:9:1)
Exited with code 0xffffffff
Desktop (please complete the following information):

OS: [e.g. iOS] Windows Server 2019 Standard

Duplicate of #245


Use a Contract Fist approach to define Actors

Warning: This PR introduces breaking changes.
Once this PR is finalized, Spawn will start using a completely contract-first approach in defining its Actors as users will have to create gRPC services that will be mapped 1:1 with the Actors.
This will allow us to:

The proxy becomes aware of the user types. This is good because it expands our range of possibilities in implementing new features.
Users will have a simpler way to know which Actions and Actors exist. Just look at or share .proto file between different projects and everyone will be able to know what can be invoked and how.
We will be able to transparently expose Actor Actions externally via gRPC and HTTP (the latter via HTTP transcoding).

What blocks this PR from being merged:

Finalize the gRPC dispatcher.
More tests.
This PR in the elixir-grpc repository and the subsequent new version published in the hex.pm repository.

When completes this closes https://github.com/eigr/spawn/issues/32


Adding  5 different  searching, sorting algorithms

Adding 5 different searching, sorting algorithms  in the project such as insertion ,linear search ,binary  search, selection sort, merge sort ,quick sort,heap sort and also adding the worst,best,average complexities of each algorithms

can you please assign this to me @Abhijit2505 ?

Sir, I'm ready to contribute. Could you please assign it to me....

Sir, I'm ready to contribute. Could you please assign it to me....

Adding 5 different searching, sorting algorithms in the project such as insertion ,linear search ,binary search, selection sort, merge sort ,quick sort,heap sort and also adding the worst,best,average complexities of each algorithms

Did you check the code-base of eduAlgo, These algorithms already exists in our package.
Check our documentation for more info - https://edualgo.github.io/documentation/

Adding 5 different searching, sorting algorithms in the project such as insertion ,linear search ,binary search, selection sort, merge sort ,quick sort,heap sort and also adding the worst,best,average complexities of each algorithms

Did you check the code-base of eduAlgo, These algorithms already exists in our package.
Check our documentation for more info - https://edualgo.github.io/documentation/


Bug with mulitple gateways

It is not possible to select a gateway with only the on-prem connection mapped (Invalid configured gateway) if you have multiple gatewayes. The UI will select a working gateway.
I had to remove the other gatewayes to make this guide work and to be allowed to select a partially configured gateway for only on-prem sources.

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

ID: 183a8242-3c94-8a80-6d36-85c608790a25
Version Independent ID: 2d8728c3-3662-27a3-6cd4-2c88b08f7847
Content: Merge or append on-premises and cloud data sources - Power BI
Content Source: powerbi-docs/service-gateway-mashup-on-premises-cloud.md
Service: powerbi
Sub-service: powerbi-gateways
GitHub Login: @arthiriyer
Microsoft Alias: arthii

Thanks for your comment, @jeppesal. We’ve forwarded your feedback to the writer, who should respond to this thread shortly. Thanks!

Older than 1 year. Article updated. PM never responded. Closing.


[Enhancement]: Update the OSAR generation script to change the dir structure for osar files

The OSAR should be stored in this directory structure
<datastore dir>/<project>/<version>/<project>-<version>-osar.json

The path has to be updated in the playbook itself.


[embedded] Fix a memory leak caused by incorrect refcounting logic around doNotFreeBit

Looks like we had a major memory leak caused by the changes from https://github.com/swiftlang/swift/pull/76231. We can't set the refcount to HeapObject.immortalRefCount (0xffff_ffff) because that (accidentally) also includes HeapObject.doNotFreeBit (0x8000_000). Let's separate the two -- immortalRefCount is now only 0x7fff_ffff and the highest bit is used as a doNotFreeBit regardless of whether the refcount is immortal or not.
Fixes https://github.com/swiftlang/swift/issues/76998

@swift-ci please test

I'm not quite following how this works, can you explain a bit? It doesn't look like HeapObject.doNotFreeBit is checked anyhwere and I'm not sure what the intended difference is between immortal and do-no-tfree.


Live demo not working well in Chrome

Hi,
I was looking at your demo in Chrome and the VectorTiles are not showing up and when you trace buildings, you dont see the vertices.
I am using Chrome 86.0.4240.111 (official Build) (64 bits)
In Firefox everything work correctly.

Hi @DemersM, thanks for trying out the app and sorry to hear you ran into problems. Did you run the demo from the source code or using the live version at https://esri.github.io/participatory-planning/?
The live version works for me using the same version of Chrome on MacOS. It's possible that the VectorTiles not showing up was related to a server hick-up.
I also quickly tried creating some buildings which seemed to work as expected. Would be great if you could give it another try or provide more specifics. Thanks!


[YouTube] Specific track not working due to change in MPD

[X] I'm reporting a broken site support
[X] I've verified that I'm running youtube-dl version 2019.07.02
[X] I've checked that all provided URLs are alive and playable in a browser
[X] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched the bugtracker for similar issues including closed ones

Verbose log
youtube-dl.exe -f 136 https://www.youtube.com/watch?v=Ctgn4qvwmCE -v
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-f', '136', 'https://www.youtube.com/watch?v=Ctgn4qvwmCE', '-v']
[debug] Encodings: locale cp1252, fs mbcs, out cp437, pref cp1252
[debug] youtube-dl version 2019.07.02
[debug] Python version 3.4.4 (CPython) - Windows-10-10.0.16299
[debug] exe versions: none
[debug] Proxy map: {}
[youtube] Ctgn4qvwmCE: Downloading webpage
[youtube] Ctgn4qvwmCE: Downloading video info webpage
[youtube] Ctgn4qvwmCE: Downloading MPD manifest
[debug] Invoking downloader on 'https://manifest.googlevideo.com/api/manifest/dash/expire/1562335057/ei/8QIfXe77B8iD1wKjp5mADg/ip/<IP_ADDRESS>/id/0ad827e2abf09821/source/youtube/requiressl/yes/playback_host/r3---sn-h5q7dnlk.googlevideo.com/mm/31%2C26/mn/sn-h5q7dnlk%2Csn-25glene7/ms/au%2Conr/mv/m/mvi/2/pl/20/hfr/all/as/fmp4_audio_clear%2Cwebm_audio_clear%2Cwebm2_audio_clear%2Cfmp4_sd_hd_clear%2Cwebm2_sd_hd_clear/initcwndbps/1091250/mt/1562313342/fvip/3/itag/0/sparams/expire%2Cei%2Cip%2Cid%2Csource%2Crequiressl%2Chfr%2Cas%2Citag/sig/ALgxI2wwRQIhAObJVPxx93R1fZ19lHNu4bPO1M12Wo3s87icmNdoW0AvAiBe-r_Xm_h-lpHZCnoV0loR-ypHgwV_eR4rDS_OyAdJ5g%3D%3D/lsparams/playback_host%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps/lsig/AHylml4wRgIhANE3FGArli28rtuzfb8MkMD2LUDs23-7wnFl0PH4cwU6AiEA0TEu5gK6nlFYs-iwlVmhekDTQdRyuZBy9lasMj37XRw%3D'
[dashsegments] Total fragments: 22
[download] Destination: Join Ericsson on The quest for easy-Ctgn4qvwmCE.mp4
[download] Got server HTTP error: HTTP Error 404: Not Found. Retrying fragment 3 (attempt 1 of 10)...
[download] Got server HTTP error: HTTP Error 404: Not Found. Retrying fragment 3 (attempt 2 of 10)...
[download] Got server HTTP error: HTTP Error 404: Not Found. Retrying fragment 3 (attempt 3 of 10)...
Description
We have tried to download the video with an specific track. Its URL is in the verbose.
[info] Available formats for Ctgn4qvwmCE:
format code  extension  resolution note
139          m4a        audio only DASH audio   49k , m4a_dash container, mp4a.40.5@ 48k (22050Hz)
140          m4a        audio only DASH audio  129k , m4a_dash container, mp4a.40.2@128k (44100Hz)
278          webm       256x144    DASH video   95k , webm_dash container, vp9, 25fps, video only
160          mp4        256x144    DASH video  108k , mp4_dash container, avc1.4d400b, 25fps, video only
242          webm       426x240    DASH video  220k , webm_dash container, vp9, 25fps, video only
133          mp4        426x240    DASH video  242k , mp4_dash container, avc1.4d400c, 25fps, video only
243          webm       640x360    DASH video  405k , webm_dash container, vp9, 25fps, video only
134          mp4        640x360    DASH video  635k , mp4_dash container, avc1.4d401e, 25fps, video only
244          webm       854x480    DASH video  752k , webm_dash container, vp9, 25fps, video only
135          mp4        854x480    DASH video 1155k , mp4_dash container, avc1.4d4014, 25fps, video only
247          webm       1280x720   DASH video 1505k , webm_dash container, vp9, 25fps, video only
136          mp4        1280x720   DASH video 2310k , mp4_dash container, avc1.4d4016, 25fps, video only
248          webm       1920x1080  DASH video 2646k , webm_dash container, vp9, 25fps, video only
137          mp4        1920x1080  DASH video 4358k , mp4_dash container, avc1.640028, 25fps, video only
18           mp4        640x360    medium , avc1.42001E, mp4a.40.2@ 96k, 6.44MiB
43           webm       640x360    medium , vp8.0, vorbis@128k, 9.42MiB
22           mp4        1280x720   hd720 , avc1.64001F, mp4a.40.2@192k (best)
And we have detected that in f-136 (720 resolution, mp4) we get this:
[youtube] Ctgn4qvwmCE: Downloading webpage
[youtube] Ctgn4qvwmCE: Downloading video info webpage
[youtube] Ctgn4qvwmCE: Downloading MPD manifest
[dashsegments] Total fragments: 22
[download] Destination: Join Ericsson on The quest for easy-Ctgn4qvwmCE.mp4
[download]   9.1% of ~18.21MiB at  7.33MiB/s ETA 00:04   [download] Got server HTTP error: HTTP Error 404: Not Found. Retrying fragment 3 (attempt 1 of 10)...
[download] Got server HTTP error: HTTP Error 404: Not Found. Retrying fragment 3 (attempt 2 of 10)...
[download] Got server HTTP error: HTTP Error 404: Not Found. Retrying fragment 3 (attempt 3 of 10)...
We think the problem could be related to:
<Representation id="136" codecs="avc1.4d4016" width="1280" height="720" startWithSAP="1" maxPlayoutRate="1" bandwidth="2310000" frameRate="25">
            <BaseURL>https://r3---sn-h5q7dnlk.googlevideo.com/videoplayback/expire/1562332650/ei/ivkeXbPzGpKH1wbE17DwBg/ip/<IP_ADDRESS>/id/0ad827e2abf09821/itag/136/source/yt_otf/requiressl/yes/mm/31,29/mn/sn-h5q7dnlk,sn-h5q7kned/ms/au,rdu/mv/m/mvi/2/pl/16/initcwndbps/1066250/ratebypass/yes/mime/video%2Fmp4/otfp/1/otf/1/lmt/1520263585881423/mt/1562310972/fvip/3/sparams/expire,ei,ip,id,itag,source,requiressl,ratebypass,mime,otfp,otf,lmt/sig/ALgxI2wwRQIhAPL0Ds-SLmX2OdMTOaRhxEAkg4PqpIWJqE5s40CQwSZhAiARPmO70AQdtsEgSKyPm0Zeys-xFlqK885aaJTGANMq4Q%3D%3D/lsparams/mm,mn,ms,mv,mvi,pl,initcwndbps/lsig/AHylml4wRAIgaJSCdoATq31kCY7GxDi1pzy1a9UzTwrheU2pH_drGK0CID2F1yU9tJcm5ixCVoMcUvN2rPere0FO63FRgwU-k9lq/</BaseURL>
            <SegmentList>
               <Initialization sourceURL="sq/0" />
               <SegmentURL media="sq/1/dur/5.120" />
               <SegmentURL media="sq/2/dur/5.120" />
               <SegmentURL media="sq/3/dur/5.120" />
               <SegmentURL media="sq/4/dur/5.120" />
               <SegmentURL media="sq/5/dur/5.120" />
               <SegmentURL media="sq/6/dur/5.120" />
               <SegmentURL media="sq/7/dur/5.120" />
               <SegmentURL media="sq/8/dur/5.120" />
               <SegmentURL media="sq/9/dur/5.120" />
               <SegmentURL media="sq/10/dur/5.120" />
               <SegmentURL media="sq/11/dur/5.120" />
               <SegmentURL media="sq/12/dur/5.120" />
               <SegmentURL media="sq/13/dur/5.120" />
               <SegmentURL media="sq/14/dur/5.120" />
               <SegmentURL media="sq/15/dur/5.120" />
               <SegmentURL media="sq/16/dur/5.120" />
               <SegmentURL media="sq/17/dur/5.120" />
               <SegmentURL media="sq/18/dur/5.120" />
               <SegmentURL media="sq/19/dur/5.120" />
               <SegmentURL media="sq/20/dur/5.120" />
               <SegmentURL media="sq/21/dur/1.960" />
            </SegmentList>
         </Representation>

That this time (in 720 resolution), we get the SegmentURL in seconds instead of ranges, as it is in the rest of cases.

Server side youtube error.


Jd/sim aggregation

@Lilyhanig I am merging this branch into master as a replacement from #252. Please review to make sure that the conflict fix didn't make any bad changes.


Password length

Whilst the article discusses keeping passwords to 8 characters minimum (Password guidelines for administrators), it doesn't discuss what the maximum length allowable is for Office 365.
Passwords longer than 16 characters are automatically shortened to 16 characters without any notification from Office365. This is poor behaviour and constraining. Many users now use , long, complex ad completely random passwords (stored in a password vault) or long strings of morable sentences or loosely associated words (e.g. myHorseWinnylovesto3@Thay).
The 16 character limit significantly reduces this abilty.

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

ID: c354faae-625c-2b36-2a77-4ed2962feff3
Version Independent ID: 1dd96166-8bae-fc8c-491f-99ca45f5b058
Content: Password policy recommendations for Office 365
Content Source: Office365-Admin/misc/password-policy-recommendations.md
Service: o365-administration
GitHub Login: @KwekuA
Microsoft Alias: kwekua

@the-epoch - thank you for engaging with the community here for the docs.
I know the product teams are always looking for user feedback on how to make Office 365 better. They keep a close tab on user feedback and it would be awesome if you could add your voice in User Voice https://office365.uservoice.com
You might find others have made a similar request that you can add to, or you can open a new one. Let us know here if you do so we can up-vote your request.
Thank you for your contribution to make the docs better! Much appreciated!

@AndreaBarr - This issue can be closed. Thank you.


Making border invisible

I can't seem to get rid of the border around the input box. I tried adjusting style both for the <View>  and the AutoCompleteInput by playing with borderWidth and borderColor to no avail.
I'm trying to make the AutoCompleteInput look identical to my other <TextInput>'s in my form. How do I get rid of the border?

Try inputContainerStyle={{borderWidth: 0}}

Try applying the style to flatListProps. This solved my issue


using select component in $form->table, got null value

Laravel Version: 5.7
PHP Version:
Laravel-admin: 1.6.15

Description:
I am using $form->table to deal a json filed and I had set "links" field to json in model.
Creating form is OK and I had found inserted data in database, But I got null when I want to get the sns_post_id in edit form, while the title is ok.
Strange...
        $form->table('links', '链接', function ($table) use ($form) {
            $table->select('sns_post_id', '帖子')->options(function ($sns_post_id) use ($form) {
                dd($sns_post_id);

            })->ajax(admin_url('api/sns/post-body'));
            $table->text('title', '标题');
        });

Steps To Reproduce:

I found that I use it in a wrong way....
Use this instead
$form->table('links', '链接', function ($table) use ($form) {
            $table->select('sns_post_id', '帖子')->options(
                SnsPost::pluck('body','id')->all()
            )->ajax(admin_url('api/sns/post-body'));
            $table->text('title', '标题');
        });


serverless-typescript or serverless-esbuild

Does this plugin work along with serverless-typescript or serverless-esbuild? It doesn't seem like the auth and log is being called at all for me
plugins:
  - serverless-esbuild
  - serverless-middleware

 hello:
    handler: src/Hello/hello.hello
    events:
      - http:
          path: hello
          method: get
          cors: true
    middleware:
      pre:
        - src/Middleware/auth.auth
      pos:
        - catch: src/Middleware/log.log

Hi @DnSu ,
It should work.
There is definitely people using it with webpack and similar plugins.
Try
plugins:
  - serverless-middleware
  - serverless-esbuild

the order matters here since you want your middlewares to be "built" before processing the handler with esbuild.
If that doesn't work, you can create a small project so I can replicate, and I can troubleshoot and tell you what's wrong 🙂

Closing since there has been any response. Feel free to reopen if needed.


Big box stores should be included earlier in tiles

If the feature area is large, then we should include these at zoom 14 if super huge and 15 if moderately large. Currently we only start showing these at zoom 16.
This is related to an Eraser Map issue: https://github.com/tangrams/eraser-map/issues/128.

shop=department_store
shop=supermarket
shop=hardware
shop=doityourself
shop=trade

Generally speaking shop=electronics is also a big box store type, and it's currently getting the below, which might be a good starting point to modify (at least it's working for z15, no modification for this existing zoom range requested):
      WHEN shop_val     = 'electronics'      THEN LEAST(zoom + 3.30, 17)

NOTE: Adding missing hardware store variants is also covered in: https://github.com/mapzen/vector-datasource/issues/519.
Some example sizes and expected tile zoom value:

z14: https://www.openstreetmap.org/way/152722810 and https://www.openstreetmap.org/way/219072560 and https://www.openstreetmap.org/way/344057345 and https://www.openstreetmap.org/way/259001359.
z15: https://www.openstreetmap.org/way/194906343 and https://www.openstreetmap.org/relation/3585039 (bigger urban grocery stores)

After #544, and after turning off the size filter in the scene.yaml:
Before

After
Note that there are two Targets in that tile, and we merge similar POIs within a 1-tile radius, so the Target mentioned in the issue description isn't there, but its equally colossal twin is, and I assume one Target per tile is enough for anyone.

I should have said: That's at 14/37.6709/-122.4691

LGTM


Is there a way to select Spectator mode in 1.12.2?

Spectator Mode is a powerful noclip mode useful for zooming around a world really fast as well as teleporting to other players, although you can't interact with any inventories or generate loot chests.  However I don't see a way to select it.

/gamemode spectator   I believe. GM 0 is survival, GM 1 is creative, GM 2 adventure, logically GM 3 would be a spectator but I don't see this number on any sites so you might have to type it all out. of course this is the stock Minecraft way, I know there are 4 modes on the mode button but yes, I believe it's adventure and adventure+ Creative and Survival... it is missing the spectator mode...

/gamemode sp also works.  I was hoping to see it in the button toggle though as the mod does everything else I can imagine right, like showing mushroom island biome squares as safe regardless of light level and giving the old NEI behavior when taking items from the right side.


Upgrade from v4.1.3 to v.5.0.0

Hey @johnletey @boojamya ,
Wanted to know if I need to set the --halt-height before upgrading to v5.0.0.
If yes then could you please share the halt height for this upgrade.
This link - "https://docs.nobleassets.xyz/network/upgrades" which you guys shared earlier has STOPPED WORKING now where I could verify the halt heights for all the upgrades with full upgrade path and notes.
So could you please share the new link where I can get these details!
Thanks,
Ritesh

We recently updated our domain from nobleassets.xyz to noble.xyz. Please use: https://docs.noble.xyz/network/upgrades.
You do not need to add a halt height. This was proposed on chain.


Copy bundles from Lock file

This is a draft (so so draft it could be a beer 🍺) PR to increase visibility on changes being made. As well as keep track of any design decisions being made as work is iterated on.

Fixes e2e test. (e2e were failing when run against dockerhub)
Always copy recursively from lockfile (does not yet honor the recursive flag)
Refactor helpers fake_registry.go <- spins up a v2 complaint registry. This results in a lot less mock code that has to be maintained.

Task List:

[ ] reduce verbosity of fake registry

While implementing Scenario 3 from issue https://github.com/vmware-tanzu/carvel-imgpkg/issues/86, I noticed that issue https://github.com/vmware-tanzu/carvel-imgpkg/issues/85 hadn't implemented the same error case scenario. So as part of this PR, in order to maintain consistency between a bundle lock file and a bundle name, I will also implement scenario 3 for issue #85 .


merge package from arlac77/npm-package-template

package.json

chore(package<EMAIL_ADDRESS>chore(scripts): cover@#overwrite c8 --temp-directory build/coverage ava && c8 report -r lcov --temp-directory build/coverage
chore(engines<EMAIL_ADDRESS>chore(package): add nyc from template
docs(package): remove keyword null
chore(package): set $.ava.require='esm' as in template
chore(package): set $.ava.files='tests/-test.js,tests/-test.mjs' as in template
chore(package): set $.ava.extensions='js,mjs' as in template

.travis.yml

chore(travis): remove node versions 10.15.2
chore(travis): add node versions -10,10.15.3

Codecov Report

Merging #634 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #634   +/-   ##
=======================================
  Coverage   92.63%   92.63%
=======================================
  Files           7        7
  Lines        1073     1073
=======================================
  Hits          994      994
  Misses         79       79

Continue to review full report at Codecov.

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

Coverage remained the same at 89.502% when pulling a55342b8e2ebeead7450f444c5dba6e22b566992 on template-sync-1 into 6bd5ea77001842b2542d05f1901e1203bb2c778d on master.

:tada: This PR is included in version 5.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Ranking of Kings sub is detected as "Season 2"

Program version
3.0.7
Operating System
Windows
Type
Gui
Service
Crunchyroll
Command used

Show ID
G79H23W70
Episode
1
Console Output
[E1] Ranking of Kings (Russian) - Season 1 - The Prince's New Clothes [☆ Russian, ☆ French, English, ☆ Spanish, ☆ Portuguese, ☆ German, ☆ Hindi, ☆ Italian, ☆ Castilian, ☆ Arabic]
[E2] Ranking of Kings (Russian) - Season 1 - The Prince and Kage [☆ Russian, ☆ French, English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E3] Ranking of Kings (Russian) - Season 1 - The New King [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E4] Ranking of Kings (Russian) - Season 1 - His First Journey [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E5] Ranking of Kings (Russian) - Season 1 - Intertwining Plots [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E6] Ranking of Kings (Russian) - Season 1 - The King of the Underworld [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E7] Ranking of Kings (Russian) - Season 1 - The Prince's Apprenticeship [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E8] Ranking of Kings (Russian) - Season 1 - The Sacrifice of Dreams [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E9] Ranking of Kings (Russian) - Season 1 - The Queen and the Shield [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E10] Ranking of Kings (Russian) - Season 1 - The Prince's Sword [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E11] Ranking of Kings (Russian) - Season 1 - Older and Younger Brothers [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E12] Ranking of Kings (Russian) - Season 1 - The Footsteps of War [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E13] Ranking of Kings (Russian) - Season 1 - The Kingdom in Turmoil [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E14] Ranking of Kings (Russian) - Season 1 - The Return of the Prince [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E15] Ranking of Kings (Russian) - Season 1 - The Order of the Underworld [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E16] Ranking of Kings (Russian) - Season 1 - Royal Majesty [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E17] Ranking of Kings (Russian) - Season 1 - The Curse of Immortality [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E18] Ranking of Kings (Russian) - Season 1 - Battle with the Gods [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E19] Ranking of Kings (Russian) - Season 1 - The Last Bastion [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E20] Ranking of Kings (Russian) - Season 1 - Immortal vs. Invincible [☆ Russian, ☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E21] Ranking of Kings - Season 1 - The Swordsmanship of a King [☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E22] Ranking of Kings - Season 1 - A Promise to the Demon [☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E23] Ranking of Kings - Season 1 - The King and the Sun [☆ French, ☆ English, ☆ Spanish, ☆ Portuguese, ☆ German]
[E24] Ranking of Kings - Season 2 - The Prince's New Clothes [Japanese]
[E25] Ranking of Kings - Season 2 - The Prince and Kage [Japanese]
[E26] Ranking of Kings - Season 2 - The New King [Japanese]
[E27] Ranking of Kings - Season 2 - His First Journey [Japanese]
[E28] Ranking of Kings - Season 2 - Intertwining Plots [Japanese]
[E29] Ranking of Kings - Season 2 - The King of the Underworld [Japanese]
[E30] Ranking of Kings - Season 2 - The Prince's Apprenticeship [Japanese]
[E31] Ranking of Kings - Season 2 - The Sacrifice of Dreams [Japanese]
[E32] Ranking of Kings - Season 2 - The Queen and the Shield [Japanese]
[E33] Ranking of Kings - Season 2 - The Prince's Sword [Japanese]
[E34] Ranking of Kings - Season 2 - Older and Younger Brothers [Japanese]
[E35] Ranking of Kings - Season 2 - The Footsteps of War [Japanese]
[E36] Ranking of Kings - Season 2 - The Kingdom in Turmoil [Japanese]
[E37] Ranking of Kings - Season 2 - The Return of the Prince [Japanese]
[E38] Ranking of Kings - Season 2 - The Order of the Underworld [Japanese]
[E39] Ranking of Kings - Season 2 - Royal Majesty [Japanese]
[E40] Ranking of Kings - Season 2 - The Curse of Immortality [Japanese]
[E41] Ranking of Kings - Season 2 - Battle with the Gods [Japanese]
[E42] Ranking of Kings - Season 2 - The Last Bastion [Japanese]
[E43] Ranking of Kings - Season 2 - Immortal vs. Invincible [Japanese]
[E44] Ranking of Kings - Season 2 - The Swordsmanship of a King [Japanese]
[E45] Ranking of Kings - Season 2 - A Promise to the Demon [Japanese]
[E46] Ranking of Kings - Season 2 - The King and the Sun [Japanese]

Additional Information
No response

That's a problem with Crunchyroll, since they tag the season wrong.


Problem converting xml to json and back to xml

I have some xml with a long string in it and when I convert it to json and back to xml the string is broken up.  I have attached a file containing the code which exhibits the problem.
problem.zip

Hi.
You may try online converter.
https://javadev.github.io/xml-to-json/


How can we avoid CLS?

Hey, I am trying to create a masonry grid without any (or very little) layout shift. Is this possible with svelte-bricks. My current attempts always load a one-column layout which then shifts to adjust for the viewport width. Any tips?

yeah, the layout shift in svelte-bricks is admittedly terrible. it needs JS to compute the number of columns based on the container width. i may be wrong but i think the only way to avoid that is a CSS-only solution (maybe this has become slightly easier now with CSS container queries). or delay rendering altogether until JS is ready. PRs for either of those would be welcome


HDDS-1727. Use generation of resourceName for locks in OzoneManagerLock.

In this Jira, we shall use generate Resourcename from actual resource names like volume/bucket/user/key inside OzoneManagerLock. In this way, users using these locking API's no need to worry of calling these additional API of generateResourceName in OzoneManagerLockUtil. And this also reduces code during acquiring locks in OM operations.

/retest

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
105
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1
mvninstall
505
trunk passed

+1
compile
247
trunk passed

+1
checkstyle
72
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
904
branch has no errors when building and testing our client artifacts.

+1
javadoc
154
trunk passed

0
spotbugs
324
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
514
trunk passed

_ Patch Compile Tests _

+1
mvninstall
479
the patch passed

+1
compile
284
the patch passed

+1
javac
284
the patch passed

+1
checkstyle
86
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
812
patch has no errors when building and testing our client artifacts.

+1
javadoc
166
the patch passed

-1
findbugs
328
hadoop-ozone generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

_ Other Tests _

+1
unit
322
hadoop-hdds in the patch passed.

-1
unit
54
hadoop-ozone in the patch failed.

+1
asflicense
39
The patch does not generate ASF License warnings.

5459

Reason
Tests

FindBugs
module:hadoop-ozone

Comparison of String objects using == or != in org.apache.hadoop.ozone.om.lock.OzoneManagerLock.generateResourceName(OzoneManagerLock$Resource, String[])   At OzoneManagerLock.java:== or != in org.apache.hadoop.ozone.om.lock.OzoneManagerLock.generateResourceName(OzoneManagerLock$Resource, String[])   At OzoneManagerLock.java:[line 128]

Failed junit tests
hadoop.ozone.om.lock.TestOzoneManagerLock

Subsystem
Report/Notes

Docker
Client=18.09.5 Server=18.09.5 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1014

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 0af0512a3ba7 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 049bb42

Default Java
1.8.0_212

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/1/artifact/out/new-findbugs-hadoop-ozone.html

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/1/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/1/testReport/

Max. process+thread count
434 (vs. ulimit of 5500)

modules
C: hadoop-ozone/common U: hadoop-ozone/common

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/1/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
31
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1
mvninstall
474
trunk passed

+1
compile
259
trunk passed

+1
checkstyle
67
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
837
branch has no errors when building and testing our client artifacts.

+1
javadoc
143
trunk passed

0
spotbugs
316
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
506
trunk passed

_ Patch Compile Tests _

+1
mvninstall
436
the patch passed

+1
compile
245
the patch passed

+1
javac
245
the patch passed

+1
checkstyle
68
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
615
patch has no errors when building and testing our client artifacts.

+1
javadoc
144
the patch passed

-1
findbugs
311
hadoop-ozone generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

_ Other Tests _

-1
unit
233
hadoop-hdds in the patch failed.

-1
unit
992
hadoop-ozone in the patch failed.

+1
asflicense
44
The patch does not generate ASF License warnings.

5751

Reason
Tests

FindBugs
module:hadoop-ozone

Comparison of String objects using == or != in org.apache.hadoop.ozone.om.lock.OzoneManagerLock.generateResourceName(OzoneManagerLock$Resource, String[])   At OzoneManagerLock.java:== or != in org.apache.hadoop.ozone.om.lock.OzoneManagerLock.generateResourceName(OzoneManagerLock$Resource, String[])   At OzoneManagerLock.java:[line 128]

Failed junit tests
hadoop.hdds.scm.container.placement.algorithms.TestSCMContainerPlacementRackAware

hadoop.ozone.client.rpc.TestOzoneRpcClient

hadoop.ozone.client.rpc.TestOzoneAtRestEncryption

hadoop.ozone.client.rpc.TestSecureOzoneRpcClient

hadoop.ozone.client.rpc.TestOzoneRpcClientWithRatis

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1014

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 6c144a18c457 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 049bb42

Default Java
1.8.0_212

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/2/artifact/out/new-findbugs-hadoop-ozone.html

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/2/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/2/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/2/testReport/

Max. process+thread count
5135 (vs. ulimit of 5500)

modules
C: hadoop-ozone/common U: hadoop-ozone/common

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/2/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
32
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1
mvninstall
531
trunk passed

+1
compile
259
trunk passed

+1
checkstyle
65
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
851
branch has no errors when building and testing our client artifacts.

+1
javadoc
159
trunk passed

0
spotbugs
337
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
544
trunk passed

_ Patch Compile Tests _

+1
mvninstall
469
the patch passed

+1
compile
271
the patch passed

+1
javac
271
the patch passed

+1
checkstyle
71
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
659
patch has no errors when building and testing our client artifacts.

+1
javadoc
138
the patch passed

-1
findbugs
321
hadoop-ozone generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

_ Other Tests _

-1
unit
160
hadoop-hdds in the patch failed.

-1
unit
1393
hadoop-ozone in the patch failed.

+1
asflicense
40
The patch does not generate ASF License warnings.

6312

Reason
Tests

FindBugs
module:hadoop-ozone

Comparison of String objects using == or != in org.apache.hadoop.ozone.om.lock.OzoneManagerLock.generateResourceName(OzoneManagerLock$Resource, String[])   At OzoneManagerLock.java:== or != in org.apache.hadoop.ozone.om.lock.OzoneManagerLock.generateResourceName(OzoneManagerLock$Resource, String[])   At OzoneManagerLock.java:[line 128]

Failed junit tests
hadoop.ozone.container.ozoneimpl.TestOzoneContainer

hadoop.ozone.client.rpc.TestSecureOzoneRpcClient

hadoop.ozone.TestMiniChaosOzoneCluster

hadoop.hdds.scm.pipeline.TestRatisPipelineProvider

hadoop.ozone.client.rpc.TestOzoneRpcClient

hadoop.ozone.client.rpc.TestOzoneAtRestEncryption

hadoop.ozone.client.rpc.TestFailureHandlingByClient

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1014

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 2a350236f4b5 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 049bb42

Default Java
1.8.0_212

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/4/artifact/out/new-findbugs-hadoop-ozone.html

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/4/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/4/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/4/testReport/

Max. process+thread count
3944 (vs. ulimit of 5500)

modules
C: hadoop-ozone/common U: hadoop-ozone/common

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/4/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
81
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1
mvninstall
561
trunk passed

+1
compile
310
trunk passed

+1
checkstyle
87
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
944
branch has no errors when building and testing our client artifacts.

+1
javadoc
157
trunk passed

0
spotbugs
329
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
530
trunk passed

_ Patch Compile Tests _

+1
mvninstall
491
the patch passed

+1
compile
294
the patch passed

+1
javac
294
the patch passed

+1
checkstyle
85
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
825
patch has no errors when building and testing our client artifacts.

+1
javadoc
177
the patch passed

-1
findbugs
362
hadoop-ozone generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

_ Other Tests _

+1
unit
309
hadoop-hdds in the patch passed.

-1
unit
1681
hadoop-ozone in the patch failed.

+1
asflicense
47
The patch does not generate ASF License warnings.

7333

Reason
Tests

FindBugs
module:hadoop-ozone

Comparison of String objects using == or != in org.apache.hadoop.ozone.om.lock.OzoneManagerLock.generateResourceName(OzoneManagerLock$Resource, String[])   At OzoneManagerLock.java:== or != in org.apache.hadoop.ozone.om.lock.OzoneManagerLock.generateResourceName(OzoneManagerLock$Resource, String[])   At OzoneManagerLock.java:[line 128]

Failed junit tests
hadoop.ozone.TestMiniChaosOzoneCluster

hadoop.ozone.client.rpc.TestReadRetries

hadoop.ozone.client.rpc.TestOzoneRpcClientWithRatis

hadoop.hdds.scm.pipeline.TestRatisPipelineProvider

Subsystem
Report/Notes

Docker
Client=18.09.5 Server=18.09.5 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1014

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 34d0627a15b2 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 049bb42

Default Java
1.8.0_212

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/3/artifact/out/new-findbugs-hadoop-ozone.html

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/3/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/3/testReport/

Max. process+thread count
4115 (vs. ulimit of 5500)

modules
C: hadoop-ozone/common U: hadoop-ozone/common

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/3/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
31
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

0
mvndep
27
Maven dependency ordering for branch

+1
mvninstall
484
trunk passed

+1
compile
256
trunk passed

+1
checkstyle
62
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
815
branch has no errors when building and testing our client artifacts.

+1
javadoc
164
trunk passed

0
spotbugs
319
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
507
trunk passed

_ Patch Compile Tests _

0
mvndep
32
Maven dependency ordering for patch

+1
mvninstall
441
the patch passed

+1
compile
260
the patch passed

+1
javac
260
the patch passed

+1
checkstyle
78
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
1
The patch has no whitespace issues.

+1
shadedclient
644
patch has no errors when building and testing our client artifacts.

+1
javadoc
141
the patch passed

-1
findbugs
305
hadoop-ozone generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

_ Other Tests _

+1
unit
248
hadoop-hdds in the patch passed.

-1
unit
1374
hadoop-ozone in the patch failed.

+1
asflicense
49
The patch does not generate ASF License warnings.

6284

Reason
Tests

FindBugs
module:hadoop-ozone

Comparison of String objects using == or != in org.apache.hadoop.ozone.om.lock.OzoneManagerLock.generateResourceName(OzoneManagerLock$Resource, String[])   At OzoneManagerLock.java:== or != in org.apache.hadoop.ozone.om.lock.OzoneManagerLock.generateResourceName(OzoneManagerLock$Resource, String[])   At OzoneManagerLock.java:[line 128]

Failed junit tests
hadoop.hdds.scm.pipeline.TestRatisPipelineProvider

hadoop.ozone.client.rpc.TestFailureHandlingByClient

hadoop.ozone.client.rpc.TestSecureOzoneRpcClient

hadoop.ozone.client.rpc.TestOzoneRpcClient

hadoop.ozone.client.rpc.TestOzoneRpcClientWithRatis

hadoop.ozone.client.rpc.TestOzoneAtRestEncryption

hadoop.ozone.client.rpc.TestOzoneClientRetriesOnException

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/7/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1014

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux edf2101e22ce 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 049bb42

Default Java
1.8.0_212

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/7/artifact/out/new-findbugs-hadoop-ozone.html

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/7/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/7/testReport/

Max. process+thread count
4555 (vs. ulimit of 5500)

modules
C: hadoop-hdds/common hadoop-ozone/common U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/7/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
30
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

0
mvndep
24
Maven dependency ordering for branch

+1
mvninstall
483
trunk passed

+1
compile
249
trunk passed

+1
checkstyle
60
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
813
branch has no errors when building and testing our client artifacts.

+1
javadoc
161
trunk passed

0
spotbugs
310
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
501
trunk passed

_ Patch Compile Tests _

0
mvndep
38
Maven dependency ordering for patch

+1
mvninstall
440
the patch passed

+1
compile
271
the patch passed

+1
javac
271
the patch passed

+1
checkstyle
71
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
635
patch has no errors when building and testing our client artifacts.

+1
javadoc
151
the patch passed

+1
findbugs
522
the patch passed

_ Other Tests _

+1
unit
234
hadoop-hdds in the patch passed.

-1
unit
1117
hadoop-ozone in the patch failed.

+1
asflicense
40
The patch does not generate ASF License warnings.

6015

Reason
Tests

Failed junit tests
hadoop.ozone.client.rpc.TestOzoneRpcClient

hadoop.ozone.client.rpc.TestOzoneRpcClientWithRatis

hadoop.ozone.client.rpc.TestSecureOzoneRpcClient

hadoop.ozone.web.client.TestOzoneClient

hadoop.ozone.client.rpc.TestOzoneAtRestEncryption

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/8/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1014

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux c87545381e50 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 4b50981

Default Java
1.8.0_212

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/8/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/8/testReport/

Max. process+thread count
4618 (vs. ulimit of 5500)

modules
C: hadoop-hdds/common hadoop-ozone/common U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1014/8/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

Test failures are not related to this patch.
Thank You @anuengineer for the review. I will commit this to the trunk.


poor-man's bold in monospace

The highlighting class specifies "Incosolata","Consolata","Monaco",monospace as font-family.
However, Monaco does not have a bold variant, so poor-man's bold is used which makes the spacing not mono-spaced.
See also https://github.com/mathjax/MathJax-docs/issues/32#issuecomment-42584790

FWIW, on macOS 10.12 (tested both Chrome 63 and Firefox 57), the comma in the Andale font looks unfortunately like a slightly-stout period:

(from: https://xtensor.readthedocs.io/en/latest/numpy.html)


fix/typo: Change traceid to traceparent

Because traceparent can transmit info={version, traceid, spanid, traceflag} to consumer. Only transmit traceid is not useful.
https://github.com/dapr/dapr/issues/4398
https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/extensions/distributed-tracing.md#traceparent

@1046102779 please make this change backwards compatibles, so keep traceid and add traceparent.

@1046102779 please make this change backwards compatibles, so keep traceid and add traceparent.

ok. we may remove traceid after a few versions。