nfunato

------------------------------------------------------------------
以下の翻訳文は、Felix Winkelmann の Thoughts on Forth Programming 
(http://call-with-current-continuation.org/articles/forth.txt) の
翻訳であり、原著者の許可を得て公開するものです。
                2021-09-01 Nobuhiko FUNATO (nfunato @ acm . org)

更新履歴: 
2021-09-02(rev10): Shiro Kawaiさんにご指摘いただいた誤訳訂正/改善を反映
2021-09-02(rev09): 公開初版
------------------------------------------------------------------

pervognsen

A traditional table-based DFA implementation looks like this:

uint8_t table[NUM_STATES][256]

uint8_t run(const uint8_t *start, const uint8_t *end, uint8_t state) {
    for (const uint8_t *s = start; s != end; s++)
        state = table[state][*s];
    return state;
}

nyaocat

#!/bin/bash

set -eu

readonly NSNAME="ns${RANDOM}"
sudo ip netns add "$NSNAME"
trap "sudo ip netns delete '$NSNAME'" 0

sudo ip netns exec "$NSNAME" sudo -u "$USER" "$@"

leque

vi(m)クローンの正規表現（雑）比較

• viはPOSIX BRE + \<, \>, ~

  • https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ex.html#tag_20_40_13_58

  • ただし \{, \} はSUSv2 (1997) 以降？

    • https://pubs.opengroup.org/onlinepubs/7990989775/xcu/ex.html#tag_001_014_598_050

  • 4.4BSD (1994) のviには \{, \} は含まれないようである

    • https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/usr.bin/ex/ex_re.c

  • nviは \{, \} を実装していない

    • https://repo.or.cz/nvi.git/blob/HEAD:/ex/ex_subst.c#l1038

mizchi

type EventBase = {
  __uid?: string;
  __ts?: number;
};

type PubSub<Event> = {
  dispatch: (ev: Event) => void;
  subscribe: (fn: (ev: Event) => void) => void;
};

azu

tsconfig.json の設定についてのメモ書きです。

• TypeScript: TSConfig Reference - Docs on every TSConfig option
• TypeScript: Documentation - What is a tsconfig.json

Node.jsのバージョンごとの設定

target は 変換後のコードのECMAScriptバージョンを指定する たとえば、Node.js 14はES2020をサポートしている。そのため、Node.js 14向けのコード(サーバなど)ならtarget: "ES2020"を指定することで、余計なTranspileが省かれててコードサイズや実行時間が最適化される。

azu

https://github.com/azu/create-ts-validator

Edit: Create https://github.com/azu/create-ts-validator

---

Purposes

nyaocat

type WidthDefined = {width: number};
type HeightDefined = {height:number};
type TitleDefined = {title:string};
type AllDefined = WidthDefined & HeightDefined & TitleDefined;

class WidgetBuilder<T>{
  constructor(private params: T){}
   width<D>(this:WidgetBuilder<D extends WidthDefined ? never : D>, width: number):WidgetBuilder<D & WidthDefined> {
     return new WidgetBuilder(Object.assign(this.params, {width}));
   }

mattn

blacklist/whitelist master/slave に関する情報集め

blacklist/whitelist、master/slave という単語は相応しくないという意見に OSS がどの様に対応すべきかを自身で考える為の情報集めです。見つけ次第、逐次更新していきます。

僕(mattn) 自身は black lives matter に同意をしています。blacklist/whitelist、master/slave という単語を廃止する事が、歴史的背景を持たない文化圏では特定の意味を持たなかった為、個人的には若干思う所はありますが、廃止自身に反対するつもりはありません。

昔から、主副を表す物には master/slave という単語が使われてきました。ハードディスクの IDE、仮想端末(pty)、色々あります。またネットワークの IP フィルタリングに関しては blacklist/whitelist と表記した物が今でも沢山あります。

我々日本人が意識せずに使っていた blacklist/whitelist、master/slave という単語が、人々にどの様に影響しうるのか、今後 OSS としてどの様に関わっていけば良いかを理解する上で、自分なりの情報集めをしたいと思っています。

syohex

#!/usr/bin/env bash
set -e

declare -A counts

for file in $(git ls-files)
do
  count=$(git shortlog -s -n --all --no-merges $file | wc -l)
  counts[$file]=$count
done