Author: Chris Lattner
import { Injectable } from '@angular/core'; | |
import { CanActivate, ActivatedRouteSnapshot, RouterStateSnapshot, Router } from '@angular/router'; | |
import { Observable } from 'rxjs/Observable'; | |
import { AngularFireAuth } from 'angularfire2/auth'; | |
import 'rxjs/add/operator/do'; | |
import 'rxjs/add/operator/map'; | |
import 'rxjs/add/operator/take'; | |
@Injectable() | |
export class AuthGuard implements CanActivate { |
Changes to the syntax of type parameters have been suggested multiple times by now. And while there may be a point to make about readability, function declarations using type parameters as described in the proposal will stay unambiguous. However, ambiguity arises when it comes to the proposed way of using type arguments, as call expressions may look the same, despite having different meanings depending on whether their arguments are types or values.
While it seems to be consensus in the community that using different brackets for type parameters and arguments by now, the following points have not been mentioned yet and further support the change.
Assume we have a generic function that doubles an addable type:
Here is the best setup (I think so :D) for K-series Keychron keyboards on Linux.
Note: many newer Keychron keyboards use QMK as firmware and most tips here do not apply to them. Maybe the ones related to Bluetooth can be useful, but everything related to Apple's keyboard module (hid_apple
) on Linux, won't work. As far as I know, all QMK-based boards use the hid_generic
module instead. Examples of QMK-based boards are: Q, Q-Pro, V, K-Pro, etc.
Most of these commands have been tested on Ubuntu 20.04 and should also work on most Debian-based distributions. If a command happens not to work for you, take a look in the comment section.
Older Keychron keyboards (those not based on QMK) use the hid_apple
driver on Linux, even in the Windows/Android mode, both in Bluetooth and Wired modes.
# MOVED: | |
# To enable better collboration, I've moved the shell.nix to https://github.com/0xB10C/nix-bitcoin-core. | |
# Older revisions remain avaiable here. | |
# https://gist.github.com/0xB10C/1fd0d4a68bf96914775b1515340926f8/revisions | |
# | |
# | |
# | |
# | |
# | |
# |
During the recent Oakland Dev Summit, some lightning engineers got together to discuss DoS protection for onion messages. Rusty proposed a very simple rate-limiting scheme that statistically propagates back to the correct sender, which we describe in details below.
Nodes apply per-peer rate limits on incoming onion messages that should be relayed (e.g. N/seconds with some burst tolerance). It is recommended to allow more onion messages from peers with whom you have channels, for example 10/seconds when you have a channel and 1/second when you don't.
Jun 21, 2022, 6 PM UTC, #review-club on LDK Slack.
lightningdevkit/rust-lightning#1507
Host: ariard PR author: ViktorTigerstrom
The PR branch HEAD was ae665ce at the time of this review club meeting.