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

ああ人生に涙あり

紅まどんな

以前見たものの半額くらいのものを見かけたのだけど、 相場(?)がどうだかわからないので 安けりゃ安いで(とは言えそこそこなお値段) 気になるな😄

とりあえず買ってみた(2個入りパック)。

メモ

【西川和久の不定期コラム】固定回線不調で、5Gホームルーター「UQ WiMAX Speed Wi-Fi HOME 5G L12」を急遽導入した話 - PC Watch

ヨルガヤ姉妹

2355の「ヨルガヤ姉妹」が最近のお気に入り

who

ブログ: Web3はデタラメである

答えは常に誰か(somebody)であり、それは誰(who)の問題なのです。

テクノロジーは、誰が私たちのデジタルライフをコントロールする力を持つべきか、という難しい問いから私たちを救ってはくれません。 答えは常に誰か(somebody)であり、それは誰(who)の問題なのです。

訳文のこの部分(特に最後)がよくわからなかったので原文に当たった。

Web3 is Bullshit

Technology won’t save us from having to ask the hard questions of who should have power to control our digital lives. The answer will always be somebody, it’s just a question of who.

ん－。

it’s just a question of who.は 「『誰』にpower to control our digital livesを持たせるか(誰がそれを持つか)」 というニュアンスじゃないかなあ。 元の訳からだとそうは読み取れない(読み取りにくい)気がする。

__flexarr

前回のつづき。 参考リンク先の発言でも途中で切れていたのがちょっと気になっていたのだけど、 glibcの中に(考えてみれば当然か) 定義があり全体でもそれほど大きなものではないので ちょっと抜き出し。

glibc/cdefs.h at 895ef79e04a953cac1493863bcae29ad85657ee1 · lattera/glibc

/* Support for flexible arrays.
   Headers that should use flexible arrays only if they're "real"
   (e.g. only if they won't affect sizeof()) should test
   #if __glibc_c99_flexarr_available.  */
#if defined __STDC_VERSION__ && __STDC_VERSION__ >= 199901L
# define __flexarr	[]
# define __glibc_c99_flexarr_available 1
#elif __GNUC_PREREQ (2,97)
/* GCC 2.97 supports C99 flexible array members as an extension,
   even when in C89 mode or compiling C++ (any version).  */
# define __flexarr	[]
# define __glibc_c99_flexarr_available 1
#elif defined __GNUC__
/* Pre-2.97 GCC did not support C99 flexible arrays but did have
   an equivalent extension with slightly different notation.  */
# define __flexarr	[0]
# define __glibc_c99_flexarr_available 1
#else
/* Some other non-C99 compiler.  Approximate with [1].  */
# define __flexarr	[1]
# define __glibc_c99_flexarr_available 0
#endif

最後に[1]がありますね。

細かいことを言うと、[]、[0]、[1] のいずれなのかで構造体の大きさが異なる (と言いつつ前者二つは同じ)と思うんだけど、 それはあまり気にするものではないのかもしれない。

10

インクリメント演算子とコンパイラの気持ち

他にインクリメント演算子のある言語においてa=1のときに++a + ++a + ++aの値がどうなるか調べたところ、 clang派が多いようですが、PerlはGCCと同じ10を返しました。

9になるのは見当がついたけど、10はどうやって? と思って読んだらなかなか興味深かった。

ところで

インクリメント演算子はトラブルのもとだからか、採用しないことにした言語も結構あります(RubyやPythonなど)。

少なくともRuby(と多分Pythonも)に関しては「トラブルになるから」インクリメント演算子(とデクリメント演算子)を言語機能に 入れなかったのではなかったと記憶している。

たとえば Ruby にインクリメント演算子のようなものが無い理由 - fugafuga.write 経由で見つけたRubyのメーリングリストでのまつもとさんの発言にこういうものがある。

[ruby-list:5323] Re: Questions on specs and threads

Subject: [ruby-list:5323] Re: Questions on specs and threads
Date: Tue, 18 Nov 97 16:04:11 +0900

| これは単なる私の趣味ですが, 単項インクリメントとかがたまに欲しく
| なります. i += 1 でいいわけですが. i++ と書いて怒られる (^^;

すんません．この件は以前から指摘されているのですが(演算子はC
に似ているのに++と–は対応する演算子が無い)，++の動作が本質
的に「変数を操作する」ものであるため，変数がオブジェクトでな
いRubyでは導入できないでいます．++や–の「オブジェクト指向的
意味」がRubyの他の部分と整合性を保ったまま定義できれば採用し
たいのですが…．

同様の趣旨の発言は少なからぬ回数が色々なところでされていたと思う。

もうひとつ怪しげ(?)な翻訳サイトでruby-talk(というメーリングリスト)でのまつもとさんの発言が見つかった

ruby — なぜRuby i ++またはi–（インクリメント/デクリメント演算子）をサポートしないのですか？

メーリングリストのアーカイブだとこれ [ruby-talk:02710] Re: X++?

glob zsh 16

前回まで 関数 scanner から呼び出された 関数 insert の話を書いていたけど 要するにそこで何をやっているかというと globの結果候補からqualifierでの フィルタリングをするための情報を stat/lstatで得るということ (超大雑把な説明)。

その辺はつまり、今回追いかけ始めたそもそもの理由 「globbingでマッチする対象が見つからなかったパターンはどうなるか」 という観点からは追いかける必要はない(少ない)もの。

ということで関数 zglobのscannerを呼び出している辺り へ戻る。

/* Initialise receptacle for matched files, *
 * expanded by insert() where necessary.    */
matchptr = matchbuf = (Gmatch)zalloc((matchsz = 16) *
					 sizeof(struct gmatch));
matchct = 0;
pattrystart();

/* The actual processing takes place here: matches go into  *
 * matchbuf.  This is the only top-level call to scanner(). */
scanner(q, shortcircuit);

/* Deal with failures to match depending on options */
if (matchct)
    badcshglob |= 2;        /* at least one cmd. line expansion O.K. */
else if (!gf_nullglob) {
    if (isset(CSHNULLGLOB)) {
        badcshglob |= 1;    /* at least one cmd. line expansion failed */
    } else if (isset(NOMATCH)) {
        zerr("no matches found: %s", ostr);
        zfree(matchbuf, 0);
        restore_globstate(saved);
        return;
    } else {
        /* treat as an ordinary string */
        untokenize(matchptr->name = dupstring(ostr));
        matchptr++;
        matchct = 1;
    }
}

まずmatchctという変数が0かどうかを判定している。 これが0でない場合(とりあえず符号については考慮しない)、 少なくともパターンにマッチするものが一つはあった ということでフラグをセット(badcshglob |= 2)する。 反対にmatchctが0であった場合は、 まずgf_nullglobをチェックしてそれが0だった場合に以下の判定と処理を行う

  1. CSHNULLGLOB という設定の状態をチェックして それがセットされていたらフラグをセット (badcshglob |= 1)する
  2. NOMATCHという設定の状態をチェックして それがセットされていたらエラーとしてメッセージを出力する
  3. どちらもセットされていなければ zglobに与えられたパターンそのものがマッチ結果となる

gf_nullglobについて

zsh/glob.c at 00d20ed15e18f5af682f0daec140d6b8383c479a · zsh-users/zsh

#define gf_nullglob   (curglobdata.gd_gf_nullglob)

zsh/glob.c at 00d20ed15e18f5af682f0daec140d6b8383c479a · zsh-users/zsh

    /* The gf_* flags are qualifiers which are applied globally. */
    gf_nullglob = isset(NULLGLOB);
    gf_markdirs = isset(MARKDIRS);
    gf_listtypes = gf_follow = 0;
    gf_noglobdots = unset(GLOBDOTS);
    gf_numsort = isset(NUMERICGLOBSORT);
    gf_sorts = gf_nsorts = 0;
    gf_pre_words = gf_post_words = NULL;

Hugoメモ

今使っているのが0.88.1なのだけど Release v0.90.1 · gohugoio/hugo にあった

This release contains some fixes and improvements related to error handling in remote lookups in resources.Get, as introduced in Hugo 0.90.0:

という部分が気になったのでちょっとさかのぼって確認した(バグフィックス部分は省略)

0.88.1

Release v0.88.1 · gohugoio/hugo

0.89.0

Release v0.89.0 · gohugoio/hugo

This release is a dependency refresh (the new Goldmark version comes with a lot of bug fixes, as one example), many bug fixes, but also some nice new features:

We have added the configuration settings includeFiles and excludeFiles to the mount configuration. This allows fine grained control over what files to include, and it works for all of Hugo’s file systems (including /static).

We have also reimplemented archetypes. The old implementation had some issues, mostly related to the context (e.g. name, file paths) passed to the template. This new implementation is using the exact same code path for evaluating the pages as in a regular build. This also makes it more robust and easier to reason about in a multilingual setup. Now, if you are explicit about the target path, Hugo will now always pick the correct mount and language:

hugo new content/en/posts/my-first-post.md

0.89.1

Release v0.89.1 · gohugoio/hugo

0.89.2

Release v0.89.2 · gohugoio/hugo

0.89.3

Release v0.89.3 · gohugoio/hugo

0.89.4

Release v0.89.4 · gohugoio/hugo

0.90.0

Release v0.90.0 · gohugoio/hugo

Hugo 0.90 finally brings remote support to resources.Get, XML support (in /data and transform.Unmarshal), and a new images.Text filter. A special shoutout and thanks to @vanbroup for his work on these features.

The support for remote Resources in resources.Get has been a feature in great demand. This means that you can fetch remote files (images, JSON files, RSS feeds …) and use them in Hugo Pipes functions as they were local. A contrived example may look like this:

{{ $font := resources.Get "https://github.com/google/fonts/raw/main/apache/roboto/static/Roboto-Black.ttf" }}
{{ $img := resources.Get "https://gohugo.io/images/gohugoio-card-1.png" }}
{{ $img = $img | images.Filter (images.Text 
                       "Rocks!" 
                       (dict 
                           "color" "#E6B405" 
                           "size" 100
                           "lineSpacing" 8 
                           "x" 400 "y" 320
                           "font" $font))
                    
}}
<img src="{{ $img.RelPermalink }}" />

これは使いどころがあるかな?

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

≪ prev 追憶売ります
next ≫ タチムカウ