ときどきの雑記帖 RE* (新南口)

熱き星たちよ

薬局

定期的に処方されている薬があって薬局に月2回くらいのペースで通っているのだけど、 ここ何回か処方されている日数分全量揃わないというのがあって ああちらほら見かけたあの話は本当なのだなあと実感するなど。

Firefox

という件があったけど、たぶんそれとは関係なく とあるサイトで商品を購入しようとするとその最後の段階で Firefoxでは「大変込み合って～」みたいなメッセージがでて 購入手続きが完了できないという現象に直面してしまった。

時間をおいて3回くらい試しても全然解決しないので ひょっとして…とChromeでやってみたら問題なく購入完了。

去年も某サイトで「Firefoxお断り」を喰らったしちょっとつらい。

寡占

なんか違和感のある使い方を見かけるようになった気が。

PEG

近刊チェックをしていて見つけた。

Pythonで学ぶ解析表現文法と構文解析｜森北出版株式会社

「文法として曖昧さがない」「正規表現や文脈自由文法よりも強力」などの理由で注目を浴びる構文解析技術 「解析表現文法（parsing expression grammar, PEG）」の初の入門書。

へー。

ACM ByteCast

DHH回。

David Heinemeier Hansson - Episode 23

expelimental?

gawk　チートシート - Qiita

-Fを-fにしていたり(それは別のオプションだ)、 FIELDWIDTHSを「実験的な機能」とか inplace edit オプションがあるとか 一体どこから拾ってきた情報なんだろう…

FIELDWIDTHSが入ったのは2.15.xあたりで、そのころから拡張もされているし マニュアルからも「expelimental」という語はとっくになくなっている。

そしてgawkに-i (inplace edit)オプションがついたことはないはずなんだがなぜ?

追記

実はあった＞iオプション

ただし別の意味。

Changes from 4.0.2 to 4.1.0
---------------------------

1. The three executables gawk, pgawk, and dgawk, have been merged into
   one, named just gawk.  As a result:
   	* The -R option is gone
	* Use -D to run the debugger. An optional file argument is a
	  list of commands to run first.
	* Use -o to do pretty-printing only.
	* Use -p to do profiling.
   This considerably reduces gawk's "footprint" and eases the documentation
   burden as well.

2. Gawk now supports high precision arithmetic with MPFR.  The default is
   still double precision, but setting PREC changes things, or using
   the -M / --bignum options.  This support is not compiled in if the MPFR
   library is not available.

3. The new -i option (from xgawk) is used for loading awk library files.
   This differs from -f in that the first non-option argument is treated
   as a script.

kbk@toybox4:/mnt/c/Users/kbk$ gawk --help
Usage: gawk [POSIX or GNU style options] -f progfile [--] file ...
Usage: gawk [POSIX or GNU style options] [--] 'program' file ...
POSIX options:          GNU long options: (standard)
        -f progfile             --file=progfile
        -F fs                   --field-separator=fs
        -v var=val              --assign=var=val
Short options:          GNU long options: (extensions)
        -b                      --characters-as-bytes
        -c                      --traditional
        -C                      --copyright
        -d[file]                --dump-variables[=file]
        -D[file]                --debug[=file]
        -e 'program-text'       --source='program-text'
        -E file                 --exec=file
        -g                      --gen-pot
        -h                      --help
        -i includefile          --include=includefile
        -l library              --load=library
        -L[fatal|invalid|no-ext]        --lint[=fatal|invalid|no-ext]
        -M                      --bignum
        -N                      --use-lc-numeric
        -n                      --non-decimal-data
        -o[file]                --pretty-print[=file]
        -O                      --optimize
        -p[file]                --profile[=file]
        -P                      --posix
        -r                      --re-interval
        -s                      --no-optimize
        -S                      --sandbox
        -t                      --lint-old
        -V                      --version

To report bugs, see node `Bugs' in `gawk.info'
which is section `Reporting Problems and Bugs' in the
printed version.  This same information may be found at
https://www.gnu.org/software/gawk/manual/html_node/Bugs.html.
PLEASE do NOT try to report bugs by posting in comp.lang.awk,
or by using a web forum such as Stack Overflow.

gawk is a pattern scanning and processing language.
By default it reads standard input and writes standard output.

Examples:
        gawk '{ sum += $1 }; END { print sum }' file
        gawk -F: '{ print $1 }' /etc/passwd

分かり合えない

ソフトウェアエンジニアと機械系、電気系エンジニアが分かり合えないのはなぜですか？ - Quora

bison

ルー語的翻訳😄

5.8.3 LAC

Canonical LR, IELR, and LALR can suffer from a couple of problems upon encountering a syntax error. First, the parser might perform additional parser stack reductions before discovering the syntax error. Such reductions can perform user semantic actions that are unexpected because they are based on an invalid token, and they cause error recovery to begin in a different syntactic context than the one in which the invalid token was encountered. Second, when verbose error messages are enabled (*note Error Reporting::), the expected token list in the syntax error message can both contain invalid tokens and omit valid tokens.

Canonical LR, IELR, LALR には、シンタックスエラーに起因するいくつかの問題に悩まされる可能性があります。 第一に、パーザーはシンタックスエラーを検出する前にadditional parser stack reductions を行ってしまうかもしれません。 そしてそのようなreductionは、(それがinvalid tokenによるものだということから) ユーザーが予期していないセマンティックアクションを実行してしまうかもしれません。 そしてそれは遭遇したinvalid tokenとは異なるsyntactic contextで エラーリカバリを引き起こします。 第二に、冗長なエラーメッセージが有効になっている(*note Error Reporting::)場合、 シンタックスエラーのメッセージにある expected token list には invalid tokens と omit valid tokensの両方が含まれている可能性があります。

The culprits for the above problems are ‘%nonassoc’, default reductions in inconsistent states (*note Default Reductions::), and parser state merging. Because IELR and LALR merge parser states, they suffer the most. Canonical LR can suffer only if ‘%nonassoc’ is used or if default reductions are enabled for inconsistent states.

この問題の culprits (容疑者) は‘%nonassoc’、 inconsistent states (*note Default Reductions::) における default reductions 、 そして parser state merging です。 IELRとLALRはparser statesをmergeするのでほぼsufferします。 Canonical LR は、‘%nonassoc’が使われているか あるいはinconsistent states に対して default reductions が enabled であった場合にのみsufferする可能性があります。

LAC (Lookahead Correction) is a new mechanism within the parsing algorithm that solves these problems for canonical LR, IELR, and LALR without sacrificing ‘%nonassoc’, default reductions, or state merging. You can enable LAC with the ‘%define parse.lac’ directive.

LAC (Lookahead Correction) は、 canonical LR, IELR, and LALRが持つこれらの問題を ‘%nonassoc’, default reductions, state merging を犠牲にすることなしに 解決する構文解析アルゴリズムを持った新しいmechanismです。 LACは‘%define parse.lac’ ディレクティブを使うことで有効にできます。

– Directive: %define parse.lac VALUE

Enable LAC to improve syntax error handling. -‘none’ (default) -‘full’

This feature is currently only available for deterministic parsers in C and C++.

この機能は現時点ではCもしくはC++用のdeterministic parsersでのみ有効です。

Conceptually, the LAC mechanism is straight-forward. Whenever the parser fetches a new token from the scanner so that it can determine the next parser action, it immediately suspends normal parsing and performs an exploratory parse using a temporary copy of the normal parser state stack. During this exploratory parse, the parser does not perform user semantic actions. If the exploratory parse reaches a shift action, normal parsing then resumes on the normal parser stacks. If the exploratory parse reaches an error instead, the parser reports a syntax error. If verbose syntax error messages are enabled, the parser must then discover the list of expected tokens, so it performs a separate exploratory parse for each token in the grammar.

Conceptually, LACのmechanism は straight-forward です。 パーザーは新しいトークンをスキャナーからフェッチしたときはいつでも 次のパーザーアクションを決定できるので、 即座にsuspends normal parsingをsuspendしてから normal parser state stack のtemporary copy を使ったexploratory parse をperformします。 このexploratory parseの間、パーザーはuser semantic actionsをperformしません exploratory parse がシフトアクションに到達すれば、 normal parsing がnormal parser stacksで再開されます。 exploratory parse が(シフトアクションではなく)エラーに到達した場合は パーザーはシンタックスエラーを報告します。 冗長なシンタックスエラーメッセージが有効にされていた場合 パーザーはそこからthe list of expected tokensを見つけ出さなければならないので 構文定義にあるトークンそれぞれについて separate exploratory parse をperformします。

There is one subtlety about the use of LAC. That is, when in a consistent parser state with a default reduction, the parser will not attempt to fetch a token from the scanner because no lookahead is needed to determine the next parser action. Thus, whether default reductions are enabled in consistent states (*note Default Reductions::) affects how soon the parser detects a syntax error: immediately when it reaches an erroneous token or when it eventually needs that token as a lookahead to determine the next parser action. The latter behavior is probably more intuitive, so Bison currently provides no way to achieve the former behavior while default reductions are enabled in consistent states.

LACの使用については one subtlety があります。 それはデフォルトアクションを持ったconsistent parser stateにある場合、 次のパーザーアクションを決定するための先読みがないので パーザーがスキャナーからトークンをフェッチしようとしない ということです。 したがって、consistent states 中でdefault reductions (*note Default Reductions::)を有効にされているかどうかは パーザーがどれくらい早くシンタックスエラーを検出するのかに影響します: erroneous token に到達したときや 次のパーザーアクションを決定するための先読みとしてのトークンが 必要になったとき には即座に検出します。 おそらくは後者の動作の方がより intuitiveなので、現状のBisonでは consistent state中でdefault reductionsが有効にされているときに 前者の動作をachieveする手段を提供していません。

Thus, when LAC is in use, for some fixed decision of whether to enable default reductions in consistent states, canonical LR and IELR behave almost exactly the same for both syntactically acceptable and syntactically unacceptable input. While LALR still does not support the full language-recognition power of canonical LR and IELR, LAC at least enables LALR’s syntax error handling to correctly reflect LALR’s language-recognition power.

したがって、LACが使われている場合には consistent states でのdefault reductionを有効にするかどうかという some fixed decision において、 canonical LR と IELRはsyntactically acceptable な入力と syntactically unacceptable な入力の両方に対して almost exactly the sameな動作をします。 LALRはそれでもcanonical LR や IELRのfull language-recognition powerをサポートしませんが、 少なくともLACはLALRのlanguage-recognition powerを正しく反映する (LALRの)構文エラーハンドリングを可能にします。

There are a few caveats to consider when using LAC:

・ Infinite parsing loops.

IELR plus LAC does have one shortcoming relative to canonical LR. Some parsers generated by Bison can loop infinitely. LAC does not fix infinite parsing loops that occur between encountering a syntax error and detecting it, but enabling canonical LR or disabling default reductions sometimes does.

LACを追加したIELRにはcanonical LRと比較して短所が一つあります。 Bisonによって生成された(LACを使った)パーザーの一部は無限ループする可能性があるのです。 LACはシンタックスエラーに対する遭遇とその検出との間で生じる無限パージングループをfixしません。 しかしcanonical LRを有効にするかあるいはdefault reductionsを無効にした場合には この無限ループをfixすることもあります。

・ Verbose error message limitations.

Because of internationalization considerations, Bison-generated parsers limit the size of the expected token list they are willing to report in a verbose syntax error message. If the number of expected tokens exceeds that limit, the list is simply dropped from the message. Enabling LAC can increase the size of the list and thus cause the parser to drop it. Of course, dropping the list is better than reporting an incorrect list.

Bisonが生成したパーザーは、パーザーがverbose syntax error messageでreportしようとする expected tokenリストの大きさを制限しています。 expected tokensの数がその制限を超えてしまった場合、リストはメッセージから単純にdropされます。 Enabling LAC can increase the size of the list and thus cause the parser to drop it.
LACを有効にすることはリストの大きさを増大させて パーザーがリストをdropする状況を招くかもしれません。 もちろん、リストをdropすることは正しくないリストを報告するよりもbetterなことです。

・ Performance.

Because LAC requires many parse actions to be performed twice, it can have a performance penalty. However, not all parse actions must be performed twice. Specifically, during a series of default reductions in consistent states and shift actions, the parser never has to initiate an exploratory parse. Moreover, the most time-consuming tasks in a parse are often the file I/O, the lexical analysis performed by the scanner, and the user’s semantic actions, but none of these are performed during the exploratory parse. Finally, the base of the temporary stack used during an exploratory parse is a pointer into the normal parser state stack so that the stack is never physically copied. In our experience, the performance penalty of LAC has proved insignificant for practical grammars.

LACは二回performされるためにparse actionをたくさん必要とするので、 性能上のペナルティが生じる可能性があります。 しかしすべてのparse actionsが二回performされる必要はありません。 さらに言えば、consistent states と shift actionsにおける一連のdefault reductionにおいて パーザーはan exploratory parse をinitiate する必要は全くありません。 それに加えて、構文解析において最も時間を消費するタスクはしばしばファイル入出力であり、 スキャナーから実行される字句解析であり、ユーザーのセマンティックアクションです。 しかしこれらはどれもexploratory parseの間に実行されることはありません。 そして最後に、temporary stackがexploratory parse中に使用するbaseは normal parser state stack へのポインターなのでスタックが物理的にコピーされることはありません。 わたしたちの経験では、LACのパフォーマンスペナルティはpractical grammarsに対しては insignificant であることがproveされています。

While the LAC algorithm shares techniques that have been recognized in the parser community for years, for the publication that introduces LAC, see *note Denny 2010 May::.

While the LAC algorithm shares techniques that have been recognized in the parser community for years, for the publication that introduces LAC, see *note Denny 2010 May::.

銀河の歴史がまた一ページ

≪ prev 虹とスニーカーの頃
next ≫ 冬の稲妻