{境界子}{IETF意見公募}{RFC 3986 - 統一資源識別子 (URI): 一般構文}{strfmon()}{分離子}{sed}{違い}{可搬運用機構界面}(8)

{境界子と分離子の違い K#D657/C779}

自分なりの理解
字句的な分割を行うのが分離子、
構文級の分割を行うのが境界子。

POSIX

https://pubs.opengroup.org/onlinepubs/9699919799/functions/strtok.html
字句に分離するときの文字を separator呼び。

https://pubs.opengroup.org/onlinepubs/9699919799/functions/strfmon.html

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/read.html
https://pubs.opengroup.org/onlinepubs/9699919799/functions/getline.html

sed
s/bre/rep/opにおける/はdelim...

んー、なんでここは delimiter呼びなんだ?

読み込み中...
{飛行機}{航空機}{違い}(3)

{飛行機と航空機の違い K#D657/DC64}

航空法の定義だと
航空機 ⊂ 飛行機 ?

この法律において「航空機」とは、人が乗つて航空の用に供することができる飛行機、回転翼航空機、滑空機、飛行船その他政令で定める機器をいう。

てか、航空法における航空機というのが、私が思ってたより狭い概念だ。
飛行機を含んで船や車を含まない最上位の概念ってなんて言うんだろう?

{〈Filesystem in Userspace〉}{仮想譜類機構}{違い}(3)

{FUSEとVFSの違い K#D657/CC8D}

私見

どちらも譜類管理にかんする抽象化を提供している。
VFSのほうが“根幹的”?

参考①の図1を参考に。

U +-------------+   +---------------------------+
s | Application |   |  FUSE file-system daemon  |
e +------^------+   +---------------------------+
r        |          |       FUSE library        |
         |          +-------^--------------^----+
======== v ================ | ============ | =====
  +|Cache|------+   +-------v--------+ +---v--+
K |     VFS     <-\ |   /dev/fuse    | |Other |+
e +------^------+ | +----------------+ |kernel||+
r        |        | | FUSE   : Queue | |sub-  |||
n +------v------+ \->        :   =   | |system|||
e |Kernel-based |   | driver :   =   | +------+||
l |  file system|   +----------------+  +------+|
  +-------------+                        +------+

参考

① Bharath Kumar Reddy Vangoor,Vasily Tarasov,Erez Zadok「To FUSE or Not to FUSE: Performance of User-Space File Systems」,『USENIX Conference on File and Storage Technologies』第15回57–72頁。2017

{ククログ}{遂行説辞}{違い}(3)
{拡張Backus゠Naur記法}{〈Jxck〉}{仕様と実装の分離}{IETF意見公募}{構文解析}{違い}(6)

{Jxck「IETF RFCにおけるABNFとParsing Algorithmの関係」『blog.jxck.io』。2023-05-17 K#D657/2859}

https://blog.jxck.io/entries/2023-05-17/abnf-or-algorithm-in-rfc.html (2023-05-18閲覧)

IETF の RFC 3986 は "インターネット" で広く利用される仕様であり、 ABNF ベースで記されている
[...] https://www.rfc-editor.org/rfc/rfc3986

一方 WHATWG は、 "ブラウザ" が実装することを目的とした仕様であるため、 Parsing Algorithm が細かく書かれている。
[...] https://url.spec.whatwg.org/

WHATWG URL は、 RFC ベースだったことによるブラウザ間の実装差異を無くし、互換性を高めるための基盤として書かれたものである

例えば IPv6 アドレスの ABNF なんかも矛盾があるが、それでも世の中回っているのだから、実装側もわざわざ ABNF から実装を起こしたりしてないことが伺える。 ABNF から愚直に起こした実装なんて速いわけがないので、当たり前ではある。

Algorithm だけになってしまうと、実装しないとフォーマットの全体像が掴めないという点は確かにある。むしろ、 ABNF は実際のところ、その目的の方が大きい。そこから正確なパーサを生成するというよりも、「結果がこのような形になる」というシリアライザのソースとしての側面は、どの ABNF も大抵は担保されている。

問題は、 ABNF にパースの役割を担わせた点、そしてその上位互換として Algorithm が併記されていることで起こっている。

{柔輪結}{輪結}{用者界面}{違い}{譜類機構}{命令行界面}{図画的利用者界面}(7)
{nerdctl}{Containerfile譜}{梱体(コンタイ)}{違い}(4)

{ContainerfileとDockerfileの違い K#D657/7AAF}

Containerfile および Dockerfile 内で使用できる利用可能なコマンドは同じです。

Dockerfile is an alternate name for the same object. Containerfile and Dockerfile support the same syntax.

とのこと。
なんとなく,Containerfileのほうが汎用な呼び方に思えるので,こちらを積極的に利用する。

{!!!low-code}{!!!no-code}{違い}(3)

{low-codeとno/zero-codeの違い K#D657/3C9B}

no/zero-codeは同じ意味か? いや分からんけど。

図画的な操作かどうかは関係ないっぽい

The user interface of a low-code platform is often made up of components that users can drag-and-drop to design the app they want.

[...]

A no-code app builder often uses drag-and-drop functionality and other graphical building tools to streamline development and make it accessible for a wide variety of users.

── [MS-LvN]

Low-code is a rapid application development (RAD) approach that enables automated code generation through visual building blocks like drag-and-drop and pull-down menu interfaces.

[...]

In a no-code development platform (NCDP) [...] all code is generated through drag-and-drop or point-and-click interfaces.

── [IBM-LvN]
読み込み中...
{論譜(ロンプ)}{即譜(ソクフ)}{script}{論組(ロンぐみ)}{訳しわけ}{違い}{翻訳語}{スクリプト}{プログラム}(9)

{即譜と論譜 K#D657/57E9}

即譜(ソクフ): script (file)
論譜(ロンプ): program (file); 一時的にこう訳す

即譜と論譜は,かなり区別が曖昧な用語だと思う,というか,おそらく努力しても明確に区別するのは難しいだろう。
たとえば,ある文脈では完全に対立した概念として両者が用いられる(仕類(シルイ)の即譜,C言語の論譜,など)のに,別の文脈では論譜が即譜を内包する(仕類即譜と,C祖稿を換配した後の微形譜類の両者を指す,など)。

2023-01-08現在,どちらも「──譜」という形で訳している。しかし,とくに “program” は譜類ではなく行為を表わす概念として用いられることも多い。その場合は,論組という訳語が最適であり,論譜というような特定の物質に意味が縛られる訳語はマズいだろう。
ただし,「即譜」と訳せる “script” と,対立する概念としての “program” は,「論譜」と訳してもいいと思う。

{吸湿剤}{乾燥剤}{違い}(3)

{「乾燥剤」と「吸湿剤」の違い K#D657/E394}

要旨

事前の私案

同じ事象を異なる角度から見ているだけで,同じ物質を指すのでは?
「乾燥させる」ことと「湿気を奪う(吸う)」こと。

JISなんかだと水分の吸収率とか適用する対象物とかによって定義が分かれていたりするんだろうか。
「吸湿剤」は空間の湿気を取り除く場合にしかそう呼んではいけない,とか。


t_w氏と描出経路が(たぶん)めちゃくちゃ似てて笑った。

シリカゲルについての事柄を描きたいなぁ。
→とりあえずシリカゲルは作っとくか。
→これだけだと探しにくいから,こいつが属する上位概念も作っとくか。
→「乾燥剤」と「吸湿剤」,どっちに引き入れとくべきなんだ?
→どっちも作って引き入れちゃえ

いやまあ,内情までは知らんが。でも時印を見る限り,時系列は(描出間隔を含めて)合ってそう。

緒論

私の現時点での断案

{違い}

{}