[Suggestion] OVA Rolls

The core dice rolling mechanic of OVA is that you roll X D6's (X is determined by your character's levels in "abilities" and "weaknesses" that add or take away from the number of dice rolled), then all the duplicate numbers are added together, with the highest number rolled being the result of the roll (so a roll of 6, 6, 4, 4 and 2 would be a roll of 12, since the 2 6's are added together). I was wondering if you could add this to the bot.

Yep, you can now roll OVA.
/r ova (5)
ova (5)  = (6+6+5+3+2) = 12

Feel free to review the implementation:
struct Ova (u8);
impl Ova {
  fn discord_eval (&self, _inline: bool, _debug: bool) -> Result<Piece, String> {
    use std::fmt::Write;

    if self.0 == 0 {return Ok (Piece::Layered {math: "0".into(), text: "0".into()})}

    let mut rolls = SmallVec::<[u32; 16]>::new();
    for _ in 0..self.0 {rolls.push (roll (6))}
    rolls.sort();

    let mut prev = None;
    let mut sum = 0;
    let mut max_roll = None;
    let mut max_sum = 0;
    let mut rolls_it = rolls.iter();
    loop {
      match rolls_it.next() {
        Some (roll) if prev == Some (*roll) => sum += *roll,
        roll => {
          if sum > max_sum {
            max_sum = sum;
            max_roll = prev}
          if let Some (&roll) = roll {
            sum = roll;
            prev = Some (roll)
          } else {break}}}}

    if let Some (max_roll) = max_roll {
      let mut text = InlinableString::new();
      sum = 0;

      text.push ('(');
      for (&roll, idx) in rolls.iter().rev().zip (0..) {
        let valid = roll == max_roll;
        try_s! (wite! (&mut text,
          if idx != 0 {'+'}
          if !valid {"~~"}
          (roll)
          if !valid {"~~"}));
        if valid {sum += roll}}

      text.push (')');
      Ok (Piece::Layered {math: ifomat! ((sum)), text: text})
    } else {
      Ok (Piece::Layered {math: "0".into(), text: "0".into()})}}}


support V3 rangereq more flag and revision request flag

Turns out queues need the more flag for correct operation.
/cc @gyuho @xiang90

lgtm. Defer to @xiang90
Thanks,

LGTM

LGTM


Have vim placed in .config directory

Hello, I am in the process of reorganizing all of my files and such and I was just wondering if there was any way to the ~/.vim directory somehow placed in .config like how much user defined configuration files are placed. I am also wondering if there is any consequences if I do this tho.
Thank you for any help!

2018-02-20 2:01 GMT+03:00 Ariq Haqq<EMAIL_ADDRESS>
Hello, I am in the process of reorganizing all of my files and such and I
was just wondering if there was any way to the ~/.vim directory somehow
placed in .config like how much user defined configuration files are placed.
I am also wondering if there is any consequences if I do this tho.
Thank you for any help!

Based on what I know you may

Use Neovim as it supports XDG by default (and only XDG, ~/.vim or
~/.nvim or whatever is not supported).

Use symlinks. Will leave symlinks in home directory, of course.

Create a shell wrapper (function or alias) which will call Vim
using something like
vim -u ~/.config/vim/init.vim -N "$@"

(path based on Neovim XDG implementation, though note that Neovim
does respect $XDG* variables) and have proper set runtimepath and
set viminfo commands rewriting default ~/.vim* paths near the top of
init.vim (and proper configuration of plugin managers if you use
any).

Create your own Vim fork where default paths point to inside ~/.config.

Vim have no problems with any of the variants, the only issue you
theoretically could encounter is a buggy plugin which expects that
it is placed in ~/.vim directly and nowhere else. Given the existence
of plugin managers which place plugins anywhere, but in ~/.vim
directly (though in many cases somewhere under ~/.vim, but that does
not matter) and existence of Neovim which does not ever use ~/.vim
unless user explicitly configured Neovim to do just that such plugins
are very rare and I would not expect any actively supported plugin to
have any problems even if ~/.vim does not exist at all. If you do have
such plugin and do not want to edit its source code then symlinks are
the only option.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to<EMAIL_ADDRESS>For more options, visit https://groups.google.com/d/optout.

Ah, and I just noted, but you should not use issue tracker for such questions. There is specific mailing list for user questions. You could place a feature request for XDG support here, but it would not be the first request to support XDG base directory specification (e.g. this patch) and there are backwards compatibility considerations (Neovim can throw away some of them, Vim can’t).

Ah Thank you! I will look into neovim, I will note that there is a mailing list for this type of stuff next time! Closing issue!


Fix hero not occupying a fixed amount of space when loading the site

When the site get loaded the contents below the hero flash.
My solution: https://redot-landing-page-kelo.vercel.app/
Current version: https://www.redotengine.org/

Seems to be working


Use new catalogue-api cluster in prod

Point prod search & items APIs at the new CCR follower index containing clusters.

This is awaiting a review of unexpectedly poor performance in the follower index. We've a ticket open with Elastic Cloud (#00741993).

The performance issue was resolved by turning off an aggregations optimisation that had appeared in Elasticsearch 7.13.1. Version 7.13.2 provided a toggle to turn the optimisation off, and we have done so.
This PR is awaiting some confirmatory load tests against the stage environment.

Results from load tests running (2 requests per second for 120 seconds):

Summarising these:

I think this looks acceptable to deploy to production.


Call the cosim $finish from Verilog

Fixes the #408 Issue.

Maybe print out COSIM_PASS / COSIM_FAIL?

Maybe print out COSIM_PASS / COSIM_FAIL?
Well, there is not really a cosim pass. If you get to the end of the simulation without any errors I guess it's a pass. Also on a mismatch, we already print the error msg in Dromajo.

So we usually grep for PASS/FAIL.  For full tests, we add in this print by finishing the program.  For partial checkpoints, we want to know if the sample code PASSed or FAILed

So we usually grep for PASS/FAIL. For full tests, we add in this print by finishing the program. For partial checkpoints, we want to know if the sample code PASSed or FAILed

Okay, so I'll add the FAIL keyword to the Dromajo fail. Is that enough. Since we still grep for the host PASS if there is no cosim error.

There is no host pass for a partial program trace

Well there is no cosim pass condition either. At least until we add the "Run N instructions from checkpoint feature"

Agreed, it's more useful when there's a partial program traces.  It would also be useful for running programs that we have not modified with host commands.  I'm not sure I understand the resistance here.  Are you saying that executing an entire program with cosim is not a passing condition?

I just don't understand what's a cosim PASS condition if we are running the entire program. If there are no cosim errors we are gonna get the host pass/fail at the end. There is no merit in, for example, printing a cosim pass when the host calls $finish with a fail.

There is no merit in, for example, printing a cosim pass when the host calls $finish with a fail.

That would tell us that there is a software bug, not a hardware bug.


Build hadoop-run failed. "COPY failed: stat /var/lib/docker/tmp/docker-builder814011495/hadoop/hadoop-2.7.2.tar.gz: no such file or directory"

My dev-box:
        "HostConfig": {
            "Binds": [
                "/mnt/pathConfiguration:/cluster-configuration",
                "/var/lib/docker:/var/lib/docker",
                "/var/run/docker.sock:/var/run/docker.sock",
                "/pathHadoop:/pathHadoop"
            ],

My services-configuration.yaml:
hadoop:
  custom-hadoop-binary-path: /pathHadoop
  hadoop-version: 2.7.2

My cmd in dev-box:
./paictl.py image build -p /cluster-configuration -n hadoop-run
Related build log:
Step 3/21 : RUN apt-get -y install zookeeper libsnappy-dev
 ---> Using cache
 ---> f8217e9d7ff6
Step 4/21 : RUN rm -rf /var/lib/apt/lists/*
 ---> Using cache
 ---> c9e2e8ab132c
Step 5/21 : COPY hadoop/hadoop-2.7.2.tar.gz /usr/local/
COPY failed: stat /var/lib/docker/tmp/docker-builder814011495/hadoop/hadoop-2.7.2.tar.gz: no such file or directory
2018-06-27 07:22:39,194 [ERROR] - paiLibrary.common.linux_shell : An error occurs, when building your image [ hadoop-run ]

the reason might be not prebuild the hadoop binary and set it at the proper dir. For previous deployment process, need build hadoop binary and set it at a folder which the config file direct to it.

Hi @YanjieGao ,
The hadoop-ai was automatically built, and succeed.


uhv: unify Transfer-Encoding validation behavior

Title: uhv: unify Transfer-Encoding validation behavior
Description:
This issue is based on the discussion in the initial UHV PR. Essentially, the way Transfer-Encoding is validated cannot be mirrored exactly within UHV because of how http-parser interacts with the H1 codec. The validation behavior should stay consistent when UHV is enabled.

Fixed in #27378


compiling error: zlib.h: No such file or directory

I am getting this error:
[  4%] Building CXX object src/api/CMakeFiles/BamTools.dir/internal/BgzfStream_p.cpp.o
/project/youngn/zhoup/Source/bamtools/src/api/internal/BgzfStream_p.cpp:20:18: error: zlib.h: No such file or directory
What can I do to tell cmake to look for zlib.h in my custom library (e.g., /usr/local/include) ? thanks a lot!

Try something with this: http://cmake.org/cmake/help/cmake-2-8-docs.html#command:include_directories in your bamtools/src/api/CMakeLists.txt file.
include_directories( /your/custom/dir )

Let me know if that does the trick or not.

Thanks - that works. I have another question, if I want to install bamtools to a directory (e.g., $prefix), by doing:
cmake .. -DCMAKE_INSTALL_PREFIX=$prefix
make
make install
It will generate directory layout like this:
$prefix
--bin
--include
----bamtools
------.h
--lib
----bamtools
------.so
This works if I want to install bamtools to /usr/local, but doesn't work if I don't want to mix it up with other libraries and want to generate layout like this:
$prefix
--bin
--include
----.h
--lib
----.so
Is there anything I could tell cmake to do rather than manually move the files?
Thanks,

Unfortunately, I really don't know. I never dove into all the
intricacies of the install side of CMake, just the build side.
Between the CMake docs & Google, you might be able to figure out
something along the lines of what you're looking for. I'd love to try
and help more, but am swamped with some critical fixes on my end right now.
Sorry I can't be of much help at the moment.

Derek

On 10/13/2011 09:44 PM, orionzhou wrote:

Thanks - that works. I have another question, if I want to install bamtools to a directory (e.g., $prefix), by doing:
cmake .. -DCMAKE_INSTALL_PREFIX=$prefix
make
make install
It will generate directory layout like this:
$prefix
--bin
--include
----bamtools
------.h
--lib
----bamtools
------.so
This works if I want to install bamtools to /usr/local, but doesn't work if I don't want to mix it up with other libraries and want to generate layout like this:
$prefix
--bin
--include
----.h
--lib
----.so
Is there anything I could tell cmake to do rather than manually move the files?
Thanks,


shutting down on relayer error, because drift exceeded tolerated maximum

When running for one night, the node program exited, prompting the following error
################################################################
Fatal error in app relayer:

shutting down on relayer error, because drift exceeded tolerated maximum: current_drift:<PHONE_NUMBER>71
################################################################
 (launcher/launcher.go:174)
Application relayer shutdown unexpectedly, quitting
Error: unable to launch: shutting down on relayer error, because drift exceeded tolerated maximum: current_drift:<PHONE_NUMBER>71
dfuse (derr/cli.go:25) {"error": "unable to launch: shutting down on relayer error, because drift exceeded tolerated maximum: current_drift:<PHONE_NUMBER>71"}
dgraphql terminated with error (dgraphql/server.go:83) {"error": "shutting down on relayer error, because drift exceeded tolerated maximum: current_drift:<PHONE_NUMBER>71"}
search forkresolver terminated with error (forkresolver/forkresolver.go:117) {"error": "shutting down on relayer error, because drift exceeded tolerated maximum: current_drift:<PHONE_NUMBER>71"}
router terminated with error (router/router.go:225) {"error": "shutting down on relayer error, because drift exceeded tolerated maximum: current_drift:<PHONE_NUMBER>71"}

This errors occurs when the relayer connects to a mindreader and the mindreader is not fully synced yet, i.e. it’s not real time and still catching up with the node.
A /v1/chain/get_info on mindreader Nodeos RPC api should give a hint about if it caught up with real-time blocks. The default port is 8888 if I recall right, check the value defined in mindreader/config.ini.
It’s possible to configure it so does not stop like this by tweaking the max drift flag (dfuseeos start —help | grep relayer to list app specific flags)

This errors occurs when the relayer connects to a mindreader and the mindreader is not fully synced yet, i.e. it’s not real time and still catching up with the node.
A /v1/chain/get_info on mindreader Nodeos RPC api should give a hint about if it caught up with real-time blocks. The default port is 8888 if I recall right, check the value defined in mindreader/config.ini.
It’s possible to configure it so does not stop like this by tweaking the max drift flag (dfuseeos start —help | grep relayer to list app specific flags)

surou@ubuntu:~/Documents$ ./dfuseeos start —help | grep relayer
Error: unable to launch: cannot launch un-registered application "—help"

surou@ubuntu:~/Documents$ ./dfuseeos start —help | grep relayer
Error: unable to launch: cannot launch un-registered application "—help"

Sorry I was on my phone and it converted -- to —, dfuseeos start --help | grep relayer is the right command.
Is this related to your other issue? I would close this one and concentrate on the other one, I think everything is "together"

Sorry I was on my phone and it converted -- to —, dfuseeos start --help | grep relayer is the right command.
Is this related to your other issue? I would close this one and concentrate on the other one, I think everything is "together"

./dfuseeos start --help | grep relayer
  dfuseeos start relayer merger --merger-grpc-serving-addr=localhost:12345 --relayer-merger-addr=localhost:12345
  relayer
      --common-blocks-store-url string                         [COMMON] Store URL (with prefix) where to read/write. Used by: relayer, statedb, trxdb-loader, blockmeta, search-indexer, search-live, search-forkresolver, eosws (default "file://{dfuse-data-dir}/storage/merged-blocks")
      --common-blockstream-addr string                         gRPC endpoint to get real-time blocks. Used by: statedb, trxdb-loader, blockmeta, search-indexer, search-live, eosws (relayer uses its own --relayer-blockstream-addr) (default ":13011")
      --relayer-buffer-size int                                number of blocks that will be kept and sent immediately on connection (default 300)
      --relayer-grpc-listen-addr string                        Address to listen for incoming gRPC requests (default ":13011")
      --relayer-init-time duration                             time before we start looking for max drift (default 1m0s)
      --relayer-max-drift duration                             max delay between live blocks before we die in hope of a better world (default 5m0s)
      --relayer-max-source-latency duration                    max latency tolerated to connect to a source (default 1m0s)
      --relayer-merger-addr string                             Address for grpc merger service (default ":13012")
      --relayer-min-start-offset uint                          number of blocks before HEAD where we want to start for faster buffer filling (missing blocks come from files/merger) (default 120)
      --relayer-source strings                                 List of Blockstream sources (mindreaders) to connect to for live block feeds (repeat flag as needed) (default [:13010])

This is encountered when running the initial chain environment provided by dfuseeos. Dashboard does not warnning in this environment(https://github.com/dfuse-io/dfuse-eosio/issues/200), but it will exit because of this error. I think this is not related to the previous problem, so I submitted a separate one.

./dfuseeos start --help | grep relayer
  dfuseeos start relayer merger --merger-grpc-serving-addr=localhost:12345 --relayer-merger-addr=localhost:12345
  relayer
      --common-blocks-store-url string                         [COMMON] Store URL (with prefix) where to read/write. Used by: relayer, statedb, trxdb-loader, blockmeta, search-indexer, search-live, search-forkresolver, eosws (default "file://{dfuse-data-dir}/storage/merged-blocks")
      --common-blockstream-addr string                         gRPC endpoint to get real-time blocks. Used by: statedb, trxdb-loader, blockmeta, search-indexer, search-live, eosws (relayer uses its own --relayer-blockstream-addr) (default ":13011")
      --relayer-buffer-size int                                number of blocks that will be kept and sent immediately on connection (default 300)
      --relayer-grpc-listen-addr string                        Address to listen for incoming gRPC requests (default ":13011")
      --relayer-init-time duration                             time before we start looking for max drift (default 1m0s)
      --relayer-max-drift duration                             max delay between live blocks before we die in hope of a better world (default 5m0s)
      --relayer-max-source-latency duration                    max latency tolerated to connect to a source (default 1m0s)
      --relayer-merger-addr string                             Address for grpc merger service (default ":13012")
      --relayer-min-start-offset uint                          number of blocks before HEAD where we want to start for faster buffer filling (missing blocks come from files/merger) (default 120)
      --relayer-source strings                                 List of Blockstream sources (mindreaders) to connect to for live block feeds (repeat flag as needed) (default [:13010])

This is encountered when running the initial chain environment provided by dfuseeos. Dashboard does not warnning in this environment(https://github.com/dfuse-io/dfuse-eosio/issues/200), but it will exit because of this error. I think this is not related to the previous problem, so I submitted a separate one.

Do I need to extend the relay-max-drift time? But I see that this setting has been removed
https://github.com/dfuse-io/dfuse-eosio/blob/448bbbb85fcad467e0561f5d926ee9d7acdc5fde/CHANGELOG.md#removed
Removed relayer-max-drift (now dependent on a new condition of presence of a "block hole", and no new block sent for 5 seconds)

Do I need to extend the relay-max-drift time? But I see that this setting has been removed
https://github.com/dfuse-io/dfuse-eosio/blob/448bbbb85fcad467e0561f5d926ee9d7acdc5fde/CHANGELOG.md#removed
Removed relayer-max-drift (now dependent on a new condition of presence of a "block hole", and no new block sent for 5 seconds)

This is encountered when running the initial chain environment provided by dfuseeos

Ok, so I could reproduce roughly with those steps if I get it right:
cd /tmp/testing
dfuseeos init # Answers y to start block producer for me
dfuseeos start
# Wait overnight to see if relayer stops the whole thing

Is that correct?
If blocks are produced correctly and nothing stop the dfuseeos start process, this should not happen. Maybe the trigger is not tolerant enough.

This is encountered when running the initial chain environment provided by dfuseeos

Ok, so I could reproduce roughly with those steps if I get it right:
cd /tmp/testing
dfuseeos init # Answers y to start block producer for me
dfuseeos start
# Wait overnight to see if relayer stops the whole thing

Is that correct?
If blocks are produced correctly and nothing stop the dfuseeos start process, this should not happen. Maybe the trigger is not tolerant enough.

This is encountered when running the initial chain environment provided by dfuseeos

Ok, so I could reproduce roughly with those steps if I get it right:
cd /tmp/testing
dfuseeos init # Answers y to start block producer for me
dfuseeos start
# Wait overnight to see if relayer stops the whole thing

Is that correct?
If blocks are produced correctly and nothing stop the dfuseeos start process, this should not happen. Maybe the trigger is not tolerant enough.

Yes, for this problem, I am so easy to operate. I have the same problem when I run it overnight on local and cloud servers (8 cores, 16GB).

This is encountered when running the initial chain environment provided by dfuseeos

Ok, so I could reproduce roughly with those steps if I get it right:
cd /tmp/testing
dfuseeos init # Answers y to start block producer for me
dfuseeos start
# Wait overnight to see if relayer stops the whole thing

Is that correct?
If blocks are produced correctly and nothing stop the dfuseeos start process, this should not happen. Maybe the trigger is not tolerant enough.

Yes, for this problem, I am so easy to operate. I have the same problem when I run it overnight on local and cloud servers (8 cores, 16GB).

I’ll start one tonight and let it run overnight.
In the mean time, do you have the logs of such run?

I’ll start one tonight and let it run overnight.
In the mean time, do you have the logs of such run?

Due to github upload file type restrictions, you need to rename dfuse.log.json.7z.log to dfuse.log.json.7z, and then use 7z to decompress
dfuse.log.json.7z.log

Due to github upload file type restrictions, you need to rename dfuse.log.json.7z.log to dfuse.log.json.7z, and then use 7z to decompress
dfuse.log.json.7z.log

I have discovered the SEARCH ROUTER in this dashboard, its head block does not grow for a long time
I don’t know if this will cause the problem in this discussion

@maoueh

I have discovered the SEARCH ROUTER in this dashboard, its head block does not grow for a long time
I don’t know if this will cause the problem in this discussion

@maoueh

Is the tracker-miner-f process related to dfuseeos? Is it necessary to run?

Is the tracker-miner-f process related to dfuseeos? Is it necessary to run?

I was not able to reproduce the error, I run the instance over night on my laptop, produced 70K blocks without any problem. The search router head block is irrelevant also, it's a UI thing that should not be displayed for this app.

Is the tracker-miner-f process related to dfuseeos? Is it necessary to run?

I don't have any idea what this is. Never seen it.
Here what Google finds: https://www.reddit.com/r/SolusProject/comments/atckw3/what_exactly_is_trackerminerfs_as_shown_under/
Since this process has so high CPU, and seems to be related to some indexing functionality, it's probably trying to index some of the massive files generated by dfuseeos and it clogs everything to a point where no blocks is received by the relayer within the allowed time.

I was not able to reproduce the error, I run the instance over night on my laptop, produced 70K blocks without any problem. The search router head block is irrelevant also, it's a UI thing that should not be displayed for this app.

Is the tracker-miner-f process related to dfuseeos? Is it necessary to run?

I don't have any idea what this is. Never seen it.
Here what Google finds: https://www.reddit.com/r/SolusProject/comments/atckw3/what_exactly_is_trackerminerfs_as_shown_under/
Since this process has so high CPU, and seems to be related to some indexing functionality, it's probably trying to index some of the massive files generated by dfuseeos and it clogs everything to a point where no blocks is received by the relayer within the allowed time.

I ran for another night last night, and this error still occurs. I always use the default configuration. I still feel that something is not right. I will try again.

I ran for another night last night, and this error still occurs. I always use the default configuration. I still feel that something is not right. I will try again.

@maoueh

@maoueh

Probably the conditions for recurring the problem have been measured. If the number of blocks in the running chain is larger, the synchronization node (v2.0.8-dm.12.0) running by dfuseeos needs to catch up with enough blocks (about 70- 80 w block), because the component processing block in dfuseeos is slower than the synchronization block, so too much data will accumulate, and "shutting down on relayer error, because drift exceeded tolerated maximum" will appear. If you redeploy the test chain, then dfuseeos will run as soon as possible, that is, make the block count difference small enough to run stably. In this case, how to make dfuseeos run synchronously from scratch when there are enough blocks in the existing chain?

Probably the conditions for recurring the problem have been measured. If the number of blocks in the running chain is larger, the synchronization node (v2.0.8-dm.12.0) running by dfuseeos needs to catch up with enough blocks (about 70- 80 w block), because the component processing block in dfuseeos is slower than the synchronization block, so too much data will accumulate, and "shutting down on relayer error, because drift exceeded tolerated maximum" will appear. If you redeploy the test chain, then dfuseeos will run as soon as possible, that is, make the block count difference small enough to run stably. In this case, how to make dfuseeos run synchronously from scratch when there are enough blocks in the existing chain?

At present, this problem needs to be followed up, and dfuseeos is initialized based on the existing chain, and running eosws using the default generated dfuse.yaml will report WARNING and need to modify dfuse.yaml
  flags:
    apiproxy-nodeos-http-addr: :9888
    blockmeta-eos-api-upstream-addr: :9888
    eosws-nodeos-rpc-addr: :9888

At present, this problem needs to be followed up, and dfuseeos is initialized based on the existing chain, and running eosws using the default generated dfuse.yaml will report WARNING and need to modify dfuse.yaml
  flags:
    apiproxy-nodeos-http-addr: :9888
    blockmeta-eos-api-upstream-addr: :9888
    eosws-nodeos-rpc-addr: :9888

I will concentrate on the last "segment" of the logs you provided between 03:35 and 04:01. Those are EST timezone.
The logs attached to this issue seems to contain multiple runs, if possible, try to clean the logs upon restart.
03:35 The trace starts at that time
03:35 Mindreader starts, seems to start around block ~73K
03:35 Relayer starts
03:35 Mindreader produce merged blocks (blocks are >12h)
03:35 Relayer latency with source is too high
03:37 Mindreader is now producing one blocks
04:01 Mindreader catch up with live chain
04:01:10 Mindreader received blocks are live (latency <100ms)
04:01:14 Relayer latency is low enough to try to create blocks stream
04:01:44 Merger is currently merging blocks #135000 (there is probably 100 000+ one blocks waiting to be merged here)
04:02:11 Relayer is looking for merged blocks file 208600 (which is probably not written yet by merger)
04:02:15 Relayer is now monitoring drift (`now monitoring drift {"logger":"relayer","max_drift":300}`)
04:02:15 Mindreader last received blocks (binary is stopped by relayer at that point)
04:02:15 Relayer app is stopped, everything goes down

This occurs because "live" blocks are available but but the merger is too slow on your environment to catch up quickly with the amount of one blocks to merge. The average I see in the logs is like ~9s, this is a bit long to merge 100 blocks files together, I assume this is because of slow disk or too much disk activity. It will eventually catch up, will just take time since new blocks are also produced while the merging tries to catch up.
Now, the max drift logic has been removed in the develop branch of dfuse for EOSIO repository. The new logic is better and should not exist anymore. You will need to build from source however. I can provide a compiled binary if you would like to try or struggles with building from source.
I was under under the impression that it was already the case in your version, but it's not. You can also set the config value relayer-max-drift: 0 in your current version which will prevent the relayer from completely stop due to drift being too high. This flag has been removed and will not available anymore, so upgrading might be a better path forward.
For larger chain, few millions block, maybe even less for chain with higher traffic, our recommendation is to perform the "live" part and the historical parts separately, a mindreader starts from a snapshot very close to the live block with a merger and a relayer so that the live blocks are up. At the same time, another mindreader (or multiple ones at various height) are also started to fill the historical blocks.

I will concentrate on the last "segment" of the logs you provided between 03:35 and 04:01. Those are EST timezone.
The logs attached to this issue seems to contain multiple runs, if possible, try to clean the logs upon restart.
03:35 The trace starts at that time
03:35 Mindreader starts, seems to start around block ~73K
03:35 Relayer starts
03:35 Mindreader produce merged blocks (blocks are >12h)
03:35 Relayer latency with source is too high
03:37 Mindreader is now producing one blocks
04:01 Mindreader catch up with live chain
04:01:10 Mindreader received blocks are live (latency <100ms)
04:01:14 Relayer latency is low enough to try to create blocks stream
04:01:44 Merger is currently merging blocks #135000 (there is probably 100 000+ one blocks waiting to be merged here)
04:02:11 Relayer is looking for merged blocks file 208600 (which is probably not written yet by merger)
04:02:15 Relayer is now monitoring drift (`now monitoring drift {"logger":"relayer","max_drift":300}`)
04:02:15 Mindreader last received blocks (binary is stopped by relayer at that point)
04:02:15 Relayer app is stopped, everything goes down

This occurs because "live" blocks are available but but the merger is too slow on your environment to catch up quickly with the amount of one blocks to merge. The average I see in the logs is like ~9s, this is a bit long to merge 100 blocks files together, I assume this is because of slow disk or too much disk activity. It will eventually catch up, will just take time since new blocks are also produced while the merging tries to catch up.
Now, the max drift logic has been removed in the develop branch of dfuse for EOSIO repository. The new logic is better and should not exist anymore. You will need to build from source however. I can provide a compiled binary if you would like to try or struggles with building from source.
I was under under the impression that it was already the case in your version, but it's not. You can also set the config value relayer-max-drift: 0 in your current version which will prevent the relayer from completely stop due to drift being too high. This flag has been removed and will not available anymore, so upgrading might be a better path forward.
For larger chain, few millions block, maybe even less for chain with higher traffic, our recommendation is to perform the "live" part and the historical parts separately, a mindreader starts from a snapshot very close to the live block with a merger and a relayer so that the live blocks are up. At the same time, another mindreader (or multiple ones at various height) are also started to fill the historical blocks.

After compiling with the latest code, this problem does not exist when running

After compiling with the latest code, this problem does not exist when running


Chisq_binary test

@jjuvan i have pushed Chisq_binarytest.py from bindis to github. I am still cleaning up but it would be great if you could take a look at the code and run it. You will need the hard coded input file that is in the code. I will send the file in the next message.

Clarification @jjuvan I have pushed my branch bindis to github which contains Chisq_binarytest.py so you should be able to see it in rotseana.

@jjuvan I have copied the txt file that is hard coded into my code into a smurotse/vsp sub directory called test, you will need that to run the code Chisq_binarytest.py

@Gakehoe I have successfully ran the Chisq_binarytest.py file. I have scrolled through the code and have a couple of notes to point out.

There are three packages that are imported but not used in the code: arange, read_table, and pyplot. It is suggested that these lines are removed from the code, as I had encountered an error when attempting to run the program with those packages imported (specifically the read_table)
There are a couple of functions that are unused by the program, or that are tricky to understand. Both the "fitplot" and "parabola2" are unused functions that can be removed unless they are going to be used in a later iteration of the code. The "objective" function is difficult, as there are various instances where x is used, however I am not entirely sure what x represents when the function runs.
I would add comments to each function describing what they do in the program, as well as outside the functions in the main part of the program. This will help for us to debug as well as better understand what the code is doing, especially if any updates are to be made by a future contributor.
We need to make sure that this can run for every object, so it will be important to generalize the code by adding in an argument to the command line using argparse. This way, we can give the program the file we want to use instead of hard coding it every time (email me if you need help setting this up)
I am going to eventually push a minor update to lcvis, as the program currently duplicates the data when "Save .dat" is selected (two points for every observation, spaced 1 phase apart), so you may need to adjust the code to account for this

Eventually I believe the code will be ported to lcvis to become a full part of the program instead of being a separate entity, so establishing argparse is not priority, but I would have to ask Dr Kehoe about this before assuming so.

@jjuvan , @Gakehoe I believe all of the issues in the above list, aside from #4, were addressed in the recently merged PR.  Please confirm this is the case so I can close this issue.  We will focus on issue #4 in a new issue and then a new PR.


gif-05.gif has no meta file

I got this error message. Maybe you forget to add the meta file to git.
Read only asset Packages/com.nobi.roundedcorners/gif-05.gif has no meta file.

Fixed in version 2.0.1


Eigen error; missing method subTo

I am getting the following error during compilation of my own software which link with in tensorflow, eigen and protobuf using your scripts.
Seems to be a missing method called subTo:
/home/smistad/tensorflow_eigen/include/eigen/eigen-eigen-346ecdb306e6/Eigen/src/Core/ProductEvaluators.h:184:42: error: ‘subTo’ is not a member of ‘Eigen::internal::generic_product_impl<Eigen::Transform<float, 3, 2>, Eigen::Homogeneous<Eigen::Matrix<float, -1, -1>, 0>, Eigen::DenseShape, Eigen::HomogeneousShape, 3>’
     generic_product_impl<Lhs, Rhs>::subTo(dst, src.lhs(), src.rhs());

Using latest tensorflow.

This was not a bug in the tensorflow-cmake code


How we can create a custom button?

Hello.
Is it possible to make some custom button via default Unity GUI? With custom size, text, position, etc.
Like some custom mod menu

@dvgmdvgm
I never used Unity so I don't know, however keep in mind Il2Cpp compiles C# ahead of time, so it won't possible to create classes at runtime (just saying, I don't know if this is a requirement).
You can use Frida's Java API (on Android) to create it (I'm 100% sure you can), but I guess the least painful solution is to build an application on your own and then communicate with the target process via RPC (e.g. android broadcasts, sockets).


dontCacheBustUrlsMatching fails with latest alpha

Library Affected:
<EMAIL_ADDRESS>Browser & Platform:
webpack
Issue or Feature Request Description:
Using the latest alpha of the webpack plugin i get the error above. The doc state that it takes a RegExp or null, not an object, am i doing something wrong ?

3:16:12 PM: ValidationError: child "dontCacheBustUrlsMatching" fails because ["dontCacheBustUrlsMatching" must be an object]
3:16:12 PM:     at Object.exports.process (/opt/build/repo/node_modules/joi/lib/errors.js:190:19)
3:16:12 PM:     at internals.Object._validateWithOptions (/opt/build/repo/node_modules/joi/lib/types/any/index.js:668:31)
3:16:12 PM:     at internals.Object.validate (/opt/build/repo/node_modules/joi/lib/types/any/index.js:702:21)
3:16:12 PM:     at module.exports (/opt/build/repo/node_modules/workbox-build/build/entry-points/options/validate.js:20:33)
3:16:12 PM:     at _callee$ (/opt/build/repo/node_modules/workbox-build/build/entry-points/generate-sw-string.js:33:23)
3:16:12 PM:     at tryCatch (/opt/build/repo/node_modules/regenerator-runtime/runtime.js:62:40)
3:16:12 PM:     at Generator.invoke [as _invoke] (/opt/build/repo/node_modules/regenerator-runtime/runtime.js:296:22)
3:16:12 PM:     at Generator.prototype.(anonymous function) [as next] (/opt/build/repo/node_modules/regenerator-runtime/runtime.js:114:21)
3:16:12 PM:     at step (/opt/build/repo/node_modules/babel-runtime/helpers/asyncToGenerator.js:17:30)
3:16:12 PM:     at /opt/build/repo/node_modules/babel-runtime/helpers/asyncToGenerator.js:35:14
3:16:12 PM:     at new Promise (<anonymous>)
3:16:12 PM:     at new F (/opt/build/repo/node_modules/core-js/library/modules/_export.js:35:28)
3:16:12 PM:     at /opt/build/repo/node_modules/babel-runtime/helpers/asyncToGenerator.js:14:12
3:16:12 PM:     at generateSWString (/opt/build/repo/node_modules/workbox-build/build/entry-points/generate-sw-string.js:53:17)
3:16:12 PM:     at GenerateSW._callee$ (/opt/build/repo/node_modules/workbox-webpack-plugin/build/generate-sw.js:129:24)
3:16:12 PM:     at tryCatch (/opt/build/repo/node_modules/regenerator-runtime/runtime.js:62:40)
3:16:12 PM:     at Generator.invoke [as _invoke] (/opt/build/repo/node_modules/regenerator-runtime/runtime.js:296:22)
3:16:12 PM:     at Generator.prototype.(anonymous function) [as next] (/opt/build/repo/node_modules/regenerator-runtime/runtime.js:114:21)
3:16:12 PM:     at step (/opt/build/repo/node_modules/babel-runtime/helpers/asyncToGenerator.js:17:30)
3:16:12 PM:     at /opt/build/repo/node_modules/babel-runtime/helpers/asyncToGenerator.js:28:13
3:16:12 PM:     at <anonymous>
3:16:12 PM: [ { message: '"dontCacheBustUrlsMatching" must be an object',
3:16:12 PM:     path: [ 'dontCacheBustUrlsMatching' ],
3:16:12 PM:     type: 'object.base',
3:16:12 PM:     context:
3:16:12 PM:      { key: 'dontCacheBustUrlsMatching',
3:16:12 PM:        label: 'dontCacheBustUrlsMatching' } } ]

Sure, here you go:
new GenerateSW({
        globDirectory: 'public/dist',
        globPatterns: [
          '**/manifest.*.js',
          '**/0.*.js',
          '**/vendor.*.js',
          `**/${app}_vendor.*.js`,
          `**/${app}.*.{js,css}`,
          `**/${app}.html`,
          'fonts/*',
        ],
        directoryIndex: 'landing-pages.html',
        swDest: path.join('public/dist', `${app}-service-worker.js`),
        clientsClaim: true,
        skipWaiting: true,
        dontCacheBustUrlsMatching: '/./',
        runtimeCaching: [
          {
            urlPattern: /^https:\/\/res.cloudinary.com\/universal-avenue\/.*\/v1\/commons\/logo_white.svg/,
            handler: 'cacheFirst',
          },
        ],
      })),

@moimael this should be a regex, not a string.
So it would end up being: dontCacheBustUrlsMatching: /./
@jeffposnick is there anyway we can change the error from joi to call out being a RegExp. The message of must be an object is misleading, but I can see where it's coming from with dontCacheBustUrlsMatching: joi.object().type(RegExp),

I'll leave this issue open to see whether there's anything we can do to tell joi to throw an error that includes the context about the expected object type.


v1.12: Update Go to 1.18.6

This version fixes two security issues in the net/http and net/url packages. See the release notes [1] for more details
[1] https://go.dev/doc/devel/release#go1.18.6

/test-backport-1.12

/test-backport-1.12

/test-backport-1.12

All 4.9 tests failed on #20288 which was fixed on master by bumping the Vagrant VM image. Not sure whether the same should be done for v1.12, but in any case the failure is not related to this PR, so marking as ready to merge given reviewers approved.


42 styling review

Partially completes https://github.com/o2Labs/office-booker/issues/42
Generally styling and structure updates for the Admin pages.  Includes renaming several components and updated the file structure.
Significant re-write of New Booking page to display and cope with quotes.  Now also responds if a parking quota is available for the selected location or not.
Also updated the bookings listing page, again to reflect if a parking quota is available, and styling updates.
The users area only has top-level styling updates, and still requires the review that has gone into the above pages.  This will happen and be added as a separate PR asap.
I will then do a general run-through of styling and structure for the main app and again will submit a separate PR for any changes.

I will investigate the double-loading of the bookings, I assume this is due to an effect trigger.  Hopefully it will be simple to resolve!
The native date-picker isn't cross browser and platform compatible, hence changing to the material picker.  There is a keyboard picker, which is their preferred implementation, but I was hesitant to use this due to the validation considerations (as we have a fixed date-range that should be selected, this is overridden by manually entered dates.
https://material-ui-pickers.dev/demo/datepicker
I will investigate how simple it would be to implement to keyboard picker without introducing significant validation code.
Regarding the parking selection, it is bad practice to have radio buttons without a default selection.  If a default/null selection is required then a select list is the correct method, although for a simple yes/no selection this would cause unnecessary extra interactions for the user.
If there are only two options then either a radio button with a default selection, or a checkbox are the best implementations.  The question we are asking is "do you require access to the office, OR do you require access to the office and parking".  Considering parking is an addition to the main form selection, a checkbox (or toggle selection) is the correct implementation.

Yup, makes sense with the date picker - as I say - the one you've got there works fine for our scenario.
Another option for the parking option in the admin ... could we just re-use the multi-select button from the main booking screen?

The multiple calls to the API have been fixed on both admin and home.
I'm going to delay the keyboard date picker for now as it is causing issues with date-fns, it will need digging into deeper.  I'm also happy to continue the debate around the parking selection, but I still believe a checkbox/radio button with default/toggle button is the best option.
For now, the improvements from this PR are worth getting merged (mainly for the dynamic hiding of parking options) ASAP considering go-live.

I have been incorrectly referring to "toggle buttons", where I actually meant "switches":
https://material-ui.com/components/switches/


Add configuration dialog

Add configuration dialog when in a Jupyter nbgallery environment.

This has been added but needs more testing.


Get number of videos of a channel/user

Is there any way to check how many videos has a channel/user uploaded ?

Using the json output with jq:
$ youtube-dl 'https://www.youtube.com/playlist?list=PLwiyx1dc3P2JR9N8gQaQN_BCvlSlap7re' -J --flat-playlist | jq '.entries | length'
3

Not a single playlist. All uploads by user.

The same command works:
$ youtube-dl 'https://www.youtube.com/user/TheLinuxFoundation' -J --flat-playlist | jq '.entries | length'
693

Is it possible to create some short code ? Like  --nov (number of videos) ?

If it can be easily done by chaining two commands, I don't think it's really needed. Why isn't enough for you?

Would be convenient .Who wants to type long command every time ? . Sorry if I sound rude. It's justa a suggestion .

It gives an error. jq is not recognized as an internal or external command.

My main reason agains adding a new options is that we would have to add an option for every single feature that people need. On the other side when you build something generic like the json output you give complete flexibility for what you can do and you don't need to modify youtube-dl for most of things (they will of course always be features that require new options).
You have to install jq

Okay. Sorry. Actually I currently use the -F option . It downloads all the pages. Then gives like " Download video 1 or 500". If it was possible to store the "500" into some variable then output it. But it is a slow method. But doesn't require external software. ( Sorry I am not a coder .

Actually I use this method for most sites. I regularly download full youtube channels and vine channel. It works for vine too.


Crash when request mutil permissions

When I test request Manifest.permission.CAMERA, Manifest.permission.WRITE_EXTERNAL_STORAGE, Manifest.permission.READ_EXTERNAL_STORAGE;
after all permission denied,activity crashed.

@YouriZhang can you provide some logs from the crash?

Thank you for your prompt reply，but unfortunately I can't catch any error logs when crashed. This just occoured when apk first installed and all requested permissions were refused. I can provide the mobile brand which occoured in XiaoMi Note 4.

@YouriZhang hmmm there's not much I can do without an error log or some code that reproduces this.  I am going to close the issue for now but please let me know if you see the issue again,


Incorrect YCbCr shader in WebGL.js

I suggest the order of Cr and Cb are incorrect in webgl.js shader:
It should be
'gl_FragColor = vec4(y, cb, cr, 1.0) * rec601;',
or you will get incorrect colors

Looks correct to me.

Maybe the names of the planes are swapped elsewhere? Not sure what the naming convention is.

I was refer to the matrix in wiki:
https://en.wikipedia.org/wiki/YCbCr
The matrix values are matching with the spec but the order is not. I think you have swapped the planes in wasm/mpeg1.c
IMHO, Cb block should come before Cr block.
	self->planes_current.y = (uint8_t*)malloc(self->coded_size);
	self->planes_current.cr = (uint8_t*)malloc(self->coded_size >> 2);
	self->planes_current.cb = (uint8_t*)malloc(self->coded_size >> 2);

	self->planes_forward.y = (uint8_t*)malloc(self->coded_size);
	self->planes_forward.cr = (uint8_t*)malloc(self->coded_size >> 2);
	self->planes_forward.cb = (uint8_t*)malloc(self->coded_size >> 2);


CRA not working in Internet Explorer 11

Describe the bug
When I run npm start and open http://localhost:3000/ in Internet Explorer 11, it doesn't work. I can only see a blank page. It's working fine in Chrome though.
Did you try recovering your dependencies?
Yes.
Which terms did you search for in User Guide?
websocket, webpack
Environment
 System:
    OS: Windows 10 10.0.17134
    CPU: (8) x64 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
  Binaries:
    Node: 10.15.3 - C:\software\nodejs\node.EXE
    Yarn: Not Found
    npm: 6.4.1 - C:\software\nodejs\npm.CMD
  Browsers:
    Edge: 42.17134.1098.0
    Internet Explorer: 11.0.17134.1
  npmPackages:
    react: ^16.12.0 => 16.12.0
    react-dom: ^16.12.0 => 16.12.0
    react-scripts: 3.3.0 => 3.3.0
  npmGlobalPackages:
    create-react-app: Not Found

Steps to reproduce

Install create-react-app
Run npm start
Open http://localhost:3000/ in Internet Explorer 11

Expected behavior
It should show the basic page.
Actual behavior
It shows a blank page. I get these errors in the console:

Reproducible demo
This cannot be shown in a demo because it needs to be run locally. When I run the production build, it works fine in IE 11 so I think the problem is somewhere in the development mode of create-react-app (webpack or websocket settings?). It should also be noted that in my package.json I have set up IE 9 explicitly (ie 11 didn't work for me so that's why I used ie 9):
 "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all",
      "ie 9"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version",
      "ie 9"
    ]
  },

Plus my src/index.ts file has these two imports on the first two lines:
import 'react-app-polyfill/ie9'
import 'react-app-polyfill/stable'

this maybe the same as https://github.com/facebook/create-react-app/issues/8084

Thanks @toddgeist. Is there a fix on the way then? Or is there any other way to fix this except modifying this file? ./node_modules/react-dev-utils/webpackHotDevClient.js:60 add slashes: true

The fix will in the next patch release.


Feat(cv_deploy): Expose the details of the Workspace build validation errors

Change Summary
Explicitly expose the details of the:

Config Validation errors and warnings raised when part(s) of the proposed DC is rejected by EoS during validation via Config Session
Image Validation errors and warnings raised when part(s) of the proposed image bundle is rejected by EoS during validation
(descoped) Time taken by CV to process specific Workspace lifecycle stages

Related Issue(s)
Component(s) name
arista.avd.cv_deploy
Proposed changes

Fix NTP settings of CI EoS
Change to make molecule test results more readable (task names, CVP WS and CC naming convention)
Expose undercv_deploy_results.workspace.build_id an ID of the latest build attempt. Needed as WS in Pending state maybe reused and may have multiple Build attempts (with each attempt producing different set of errors)
Expose under cv_deploy_results.workspace.build_results:

Errors and warnings related to the validation on the proposed configuration.
Errors and warnings related to the proposed image changes (not yet implemented in AVD).
Details of the specific device associated with faced error/warning
(descoped) Time taken by different cv_workflow to execute specific activities on CV (will help identify if delays are related to the specific aspect of the workflow/CV)

Allow to:

Fully suppress returned build warnings
Suppress warnings based on custom regex patterns
Suppress warnings based on pre-defined use-cases (like enabling portfast on switchport)

Extensive molecule tests

How to test

Run proposed updated cv_deploy molecule test.
Validate cv_deploy_results outputs (cv_deploy_results.workspace.build_id and cv_deploy_results.workspace.build_results) of the invalid_config step.  Compare with other steps (which don't have incorrect DC/image and therefore don't trigger WS Build failures)

Example with default warning suppression settings (no suppression of warnings enabled):
        "workspace": {
            "build_id": "req-0a4c4607-93ed-4291-b290-90c69eaef0b2",
            "build_results": [
                {
                    "config_validation": {
                        "errors": [
                            {
                                "configlet_name": "avd-A7D46613D44DE45D68D5B5C5CBA06B0D",
                                "error_code": "DEVICE_ERROR",
                                "error_msg": "> spanning-tree mode spine2 % Invalid input (at token 2: 'spine2')",
                                "line_num": 17
                            }
                        ],
                        "warnings": []
                    },
                    "device": {
                        "_exists_on_cv": true,
                        "hostname": "avd-ci-spine2",
                        "serial_number": "A7D46613D44DE45D68D5B5C5CBA06B0D",
                        "system_mac_address": "50:00:00:cb:38:c2"
                    },
                    "image_validation": {
                        "errors": [],
                        "image_input_error": "",
                        "warnings": []
                    },
                    "stages_states": [
                        {
                            "stage": "BUILD_STAGE_CONFIG_VALIDATION",
                            "state": "FAIL"
                        },
                        {
                            "stage": "BUILD_STAGE_CONFIGLET_BUILD",
                            "state": "SUCCESS"
                        },
                        {
                            "stage": "BUILD_STAGE_IMAGE_VALIDATION",
                            "state": "SKIPPED"
                        },
                        {
                            "stage": "BUILD_STAGE_INPUT_VALIDATION",
                            "state": "SUCCESS"
                        }
                    ]
                },
                {
                    "config_validation": {
                        "errors": [
                            {
                                "configlet_name": "avd-DCC816CEAC4BBD6319385043AD318362",
                                "error_code": "DEVICE_ERROR",
                                "error_msg": "> spanning-tree mode spine1 % Invalid input (at token 2: 'spine1')",
                                "line_num": 17
                            },
                            {
                                "configlet_name": "avd-DCC816CEAC4BBD6319385043AD318362",
                                "error_code": "DEVICE_ERROR",
                                "error_msg": ">    seqq 10 permit <IP_ADDRESS>/24 eq 32 % Invalid input (at token 0: 'seqq')",
                                "line_num": 73
                            }
                        ],
                        "warnings": [
                            {
                                "configlet_name": "avd-DCC816CEAC4BBD6319385043AD318362",
                                "error_code": "DEVICE_WARNING",
                                "error_msg": "! portfast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc. to this interface when portfast is enabled can cause temporary bridging loops. Use with CAUTION.",
                                "line_num": 41
                            },
                            {
                                "configlet_name": "avd-DCC816CEAC4BBD6319385043AD318362",
                                "error_code": "DEVICE_WARNING",
                                "error_msg": "! /32 IPv4 address is not configured on the interface",
                                "line_num": 49
                            }
                        ]
                    },
                    "device": {
                        "_exists_on_cv": true,
                        "hostname": "avd-ci-spine1",
                        "serial_number": "DCC816CEAC4BBD6319385043AD318362",
                        "system_mac_address": "50:00:00:d7:ee:0b"
                    },
                    "image_validation": {
                        "errors": [],
                        "image_input_error": "",
                        "warnings": []
                    },
                    "stages_states": [
                        {
                            "stage": "BUILD_STAGE_CONFIG_VALIDATION",
                            "state": "FAIL"
                        },
                        {
                            "stage": "BUILD_STAGE_CONFIGLET_BUILD",
                            "state": "SUCCESS"
                        },
                        {
                            "stage": "BUILD_STAGE_IMAGE_VALIDATION",
                            "state": "SKIPPED"
                        },
                        {
                            "stage": "BUILD_STAGE_INPUT_VALIDATION",
                            "state": "SUCCESS"
                        }
                    ]
                },
                {
                    "config_validation": {
                        "errors": [],
                        "warnings": [
                            {
                                "configlet_name": "avd-13C20F1EDCCED2D85F6DB2FB9E3AC5B6",
                                "error_code": "DEVICE_WARNING",
                                "error_msg": "! portfast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc. to this interface when portfast is enabled can cause temporary bridging loops. Use with CAUTION.",
                                "line_num": 59
                            }
                        ]
                    },
                    "device": {
                        "_exists_on_cv": true,
                        "hostname": "avd-ci-leaf1",
                        "serial_number": "13C20F1EDCCED2D85F6DB2FB9E3AC5B6",
                        "system_mac_address": "50:00:00:72:8b:31"
                    },
                    "image_validation": {
                        "errors": [],
                        "image_input_error": "",
                        "warnings": []
                    },
                    "stages_states": [
                        {
                            "stage": "BUILD_STAGE_CONFIGLET_BUILD",
                            "state": "SUCCESS"
                        },
                        {
                            "stage": "BUILD_STAGE_IMAGE_VALIDATION",
                            "state": "SKIPPED"
                        },
                        {
                            "stage": "BUILD_STAGE_INPUT_VALIDATION",
                            "state": "SUCCESS"
                        },
                        {
                            "stage": "BUILD_STAGE_CONFIG_VALIDATION",
                            "state": "SUCCESS"
                        }
                    ]
                }
            ],
            "build_warnings": true,
            "build_warnings_suppress_patterns": [],
            "build_warnings_suppress_portfast": false,
            "change_control_id": null,
            "description": "AVD-CV-DEPLOY-WORKSPACE-INVALID-CONFIGS-RX0B-CONVERGE",
            "force": false,
            "id": "ws-7c93e948-7676-4ce1-9667-7328e098643c",
            "name": "avd-cv-deploy-workspace-invalid-configs-rx0b-converge",
            "requested_state": "built",
            "state": "build failed"
        }

Checklist
User Checklist

N/A

Repository Checklist

[ x] My code has been rebased from devel before I start
[ x] I have read the CONTRIBUTING document.
[ ] My change requires a change to the documentation and documentation have been updated accordingly.
[ x] I have updated molecule CI testing accordingly. (check the box if not applicable)

Moving to draft until comments have been addressed.


Remove installation script

Replacing installation script with ansible tasks along with some more cleanup.
Installation method based on previous script and official docs (https://docs.docker.com/install)
Added:

easier upgrade method (just specify latest as docker_version)
testing on latest version
tasks/configure.yml file for cleaner look

Removed:

installation script and everything connected with it
unused files
some simple templates
docker_upgrade and upgrade_docker variables. Backwards compatibility is maintained by setting docker_version: latest when any one of those two vars is detected (not checking value)

Resolves #31

@mongrelion I think this is read.

Do we really need to check if it is running? There is this handler: https://github.com/mongrelion/ansible-role-docker/blob/master/handlers/main.yml#L2 also we are having unit tests for this here: https://github.com/mongrelion/ansible-role-docker/blob/master/tests/test_default.py#L37
I think that enabling this: https://github.com/mongrelion/ansible-role-docker/blob/master/tests/test_default.py#L33 would solve most cases