Muqsit

<?php

declare(strict_types=1);

namespace pocketmine\phpstan\rules;

use Generator;
use PhpParser\Node\Arg;
use PhpParser\Node\Expr\ArrayItem;
use PhpParser\Node\Expr\Assign;

Widdershin

In the olden days, HTML was prepared by the server, and JavaScript was little more than a garnish, considered by some to have a soapy taste.

After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun.

But all was not right in the world. Somewhere along the way, we had slipped. Our pages went uncrawled by Bing, time to first meaningful paint grew faster than npm, and it became clear: something must be done.

And so it was decided that the applications first forged for the browser would also run on the server. We would render our HTML using the same logic on the server and the browser, and reap the advantages of both worlds. In a confusing series of events a name for this approach was agreed upon: Server-side rendering. What could go wrong?

In dark rooms, in hushed tones, we speak of colours.

SOF3

rustup +nightly component add rust-src rust-analyzer-preview
echo "let g:ycm_rust_toolchain_root = '$HOME/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu'" >> ~/.vimrc

DzeryCZ

Helm 3 is storing description of it's releases in secrets. You can simply find them via

$ kubectl get secrets
NAME                                                TYPE                                  DATA   AGE
sh.helm.release.v1.wordpress.v1                     helm.sh/release.v1                    1      1h

If you want to get more info about the secret, you can try to describe the secret

$ kubectl describe secret sh.helm.release.v1.wordpress.v1

soniah

#!/bin/bash                                                                      
                                                                                 
# remove all blank lines in go 'imports' statements,                             
# then sort with goimports                                                       
                                                                                 
if [ $# != 1 ] ; then                                                            
  echo "usage: $0 <filename>"                                                    
  exit 1                                                                         
fi                                                                               
                                                                                 

Tomcc

Client Blob Cache

What's the Client Blob Cache

The Client Blob Cache is a new Bedrock optimization - it allows blocks and biomes to be cached on Clients to avoid resending identical chunks over and over. Chunks and biomes make up the vast majority of network traffic in a lot of common cases (eg. login, teleport or dimension switches) but at the same time, they rarely change. Allowing the Client to reuse chunks it has seen in the past can save a ton of traffic and latency!

The Client Cache is a Content Addressed Storage (a bit like git) that stores Blobs and retrieves them based on their full hashes (BlobIds). This means that the cache doesn't actually know about Chunks - in the future, we might start using it for more types of data, like skins or data driven entities.

A nice thing we get from the CAS approach is that the cache is persistent: returning players will be able to reuse content that was sent them in previous sessions or even previous sessions in different servers as long as tha

polypus74

use std::sync::atomic::{AtomicUsize, Ordering};
use std::sync::Arc;

pub enum RunFlagState {
    Running = 0,
    Paused = 1,
    Cancelled = 2,
}

// TODO: is there some mechanism to automate this (nightly)?

SOF3

<?php
namespace SOFe\YieldTask;
use pocketmine\plugin\Plugin;
use pocketmine\scheduler\PluginTask;
class YieldTask extends PluginTask{
  const UNIT_TICKS = 1;
  const UNIT_SECONDS = 20;
  const UNIT_MINUTES = 1200;
  private $generator;
  private $factor;

dktapps

<?php

/*
 *
 *  ____            _        _   __  __ _                  __  __ ____
 * |  _ \ ___   ___| | _____| |_|  \/  (_)_ __   ___      |  \/  |  _ \
 * | |_) / _ \ / __| |/ / _ \ __| |\/| | | '_ \ / _ \_____| |\/| | |_) |
 * |  __/ (_) | (__|   <  __/ |_| |  | | | | | |  __/_____| |  | |  __/
 * |_|   \___/ \___|_|\_\___|\__|_|  |_|_|_| |_|\___|     |_|  |_|_|
 *

SOF3

This is a simple CLI tool for managing phar files easily.

This tool is intended for Windows users using Linux-like shells.

Required executables/commands in the %PATH%:

• mintty for starting a window that hosts the vim editor
• vi for editing a temp file from phar v

If php is in the %PATH%, you may put this file in a directory in the %PATH% with or without a file extension, then execute this directly from the shell. For example, I save this as phar in one of the directories in my path variable, so I just execute phar l path/to/file.phar directly on Git Bash.