1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
|
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>REPL: Rest-Eat-Program Loop</title>
<link>https://blog.nsfisis.dev/</link>
<description>Recent content on REPL: Rest-Eat-Program Loop</description>
<generator>Hugo -- gohugo.io</generator>
<language>ja-JP</language>
<lastBuildDate>Wed, 31 Mar 2021 01:36:49 +0900</lastBuildDate><atom:link href="https://blog.nsfisis.dev/index.xml" rel="self" type="application/rss+xml" />
<item>
<title>Rust のプリミティブ型はどこからやって来るか</title>
<link>https://blog.nsfisis.dev/posts/rust-where-are-primitive-types-from/</link>
<pubDate>Sat, 02 Oct 2021 09:39:27 +0900</pubDate>
<guid>https://blog.nsfisis.dev/posts/rust-where-are-primitive-types-from/</guid>
<description>この記事は Qiita から移植してきたものです。 元 URL: https://qiita.com/nsfisis/items/9a429432258bbcd6c565
前置き Rust において、プリミティブ型の名前は予約語でない。したがって、次のコードは合法である。
#![allow(non_camel_case_types)] #![allow(dead_code)] struct bool; struct char; struct i8; struct i16; struct i32; struct i64; struct i128; struct isize; struct u8; struct u16; struct u32; struct u64; struct u128; struct usize; struct f32; struct f64; struct str; では、普段単に bool と書いたとき、この bool は一体どこから来ているのか。rustc のソースを追ってみた。
前提知識: 一般的なコンパイラの構造、用語。rustc そのものの知識は不要 (というよりも筆者自身がよく知らない)
調査 調査に使用したソース (調査時点での最新 master)
https://github.com/rust-lang/rust/tree/511ed9f2356af365ad8affe046b3dd33f7ac3c98
どのようにして調べるか。rustc の構造には詳しくないため、すぐに当たりをつけるのは難しい。
大雑把な構造としては、compiler フォルダ以下に rustc_* という名前のクレートが数十個入っている。これがどうやら rustc コマンドの実装部のようだ。</description>
</item>
<item>
<title>[Ruby] then キーワードと case in</title>
<link>https://blog.nsfisis.dev/posts/ruby-then-keyword-and-case-in/</link>
<pubDate>Sat, 02 Oct 2021 09:38:50 +0900</pubDate>
<guid>https://blog.nsfisis.dev/posts/ruby-then-keyword-and-case-in/</guid>
<description>この記事は Qiita から移植してきたものです。 元 URL: https://qiita.com/nsfisis/items/787a8cf888a304497223
TL; DR case - in によるパターンマッチング構文でも、case - when と同じように then が使える (場合によっては使う必要がある)。
then とは 使われることは稀だが、Ruby では then がキーワードになっている。次のように使う:
if cond then puts &#34;Y&#34; else puts &#34;N&#34; end このキーワードが現れうる場所はいくつかあり、if、unless、rescue、case 構文がそれに当たる。 上記のように、何か条件を書いた後 then を置き、式がそこで終了していることを示すマーカーとして機能する。
# Example: if x then a end unless x then a end begin a rescue then b end case x when p then a end なぜ普段は書かなくてもよいのか 普通 Ruby のコードで then を書くことはない。なぜか。次のコードを実行してみるとわかる。</description>
</item>
<item>
<title>[C++] 属性構文の属性名にはキーワードが使える [[void]] [[for]]</title>
<link>https://blog.nsfisis.dev/posts/cpp-you-can-use-keywords-in-attributes/</link>
<pubDate>Sat, 02 Oct 2021 09:38:30 +0900</pubDate>
<guid>https://blog.nsfisis.dev/posts/cpp-you-can-use-keywords-in-attributes/</guid>
<description>この記事は Qiita から移植してきたものです。 元 URL: https://qiita.com/nsfisis/items/94090937bcf860cfa93b
タイトル落ち。まずはこのコードを見て欲しい。
#include &lt;iostream&gt; [[alignas]] [[alignof]] [[and]] [[and_eq]] [[asm]] [[auto]] [[bitand]] [[bitor]] [[bool]] [[break]] [[case]] [[catch]] [[char]] [[char16_t]] [[char32_t]] [[class]] [[compl]] [[const]] [[const_cast]] [[constexpr]] [[continue]] [[decltype]] [[default]] [[delete]] [[do]] [[double]] [[dynamic_cast]] [[else]] [[enum]] [[explicit]] [[export]] [[extern]] [[false]] [[final]] [[float]] [[for]] [[friend]] [[goto]] [[if]] [[inline]] [[int]] [[long]] [[mutable]] [[namespace]] [[new]] [[noexcept]] [[not]] [[not_eq]] [[nullptr]] [[operator]] [[or]] [[or_eq]] [[override]] [[private]] [[protected]] [[public]] [[register]] [[reinterpret_cast]] [[return]] [[short]] [[signed]] [[sizeof]] [[static]] [[static_assert]] [[static_cast]] [[struct]] [[switch]] [[template]] [[this]] [[thread_local]] [[throw]] [[true]] [[try]] [[typedef]] [[typeid]] [[typename]] [[union]] [[unsigned]] [[virtual]] [[void]] [[volatile]] [[wchar_t]] [[while]] [[xor]] [[xor_eq]] // [[using]] int main() { std::cout &lt;&lt; &#34;Hello, World!</description>
</item>
<item>
<title>[Ruby] 自身を実行している処理系の種類を判定する</title>
<link>https://blog.nsfisis.dev/posts/ruby-detect-running-implementation/</link>
<pubDate>Sat, 02 Oct 2021 09:37:50 +0900</pubDate>
<guid>https://blog.nsfisis.dev/posts/ruby-detect-running-implementation/</guid>
<description>この記事は Qiita から移植してきたものです。 元 URL: https://qiita.com/nsfisis/items/74d7ffeeebc51b20d791
Ruby という言語には複数の実装があるが、それらをスクリプト上からどのようにして programmatically に見分ければよいだろうか。
Object クラスに定義されている RUBY_ENGINE という定数がこの用途に使える。
参考: Object::RUBY_ENGINE
上記ページの例から引用する:
$ ruby-1.9.1 -ve 'p RUBY_ENGINE' ruby 1.9.1p0 (2009-03-04 revision 22762) [x86_64-linux] &quot;ruby&quot; $ jruby -ve 'p RUBY_ENGINE' jruby 1.2.0 (ruby 1.8.6 patchlevel 287) (2009-03-16 rev 9419) [i386-java] &quot;jruby&quot; それぞれの処理系がどのような値を返すかだが、stack overflow に良い質問と回答があった。
What values for RUBY_ENGINE correspond to which Ruby implementations? より引用:
RUBY_ENGINE Implementation &lt;undefined&gt; MRI &lt; 1.</description>
</item>
<item>
<title>Vimで選択した行の順番を入れ替える</title>
<link>https://blog.nsfisis.dev/posts/vim-swap-order-of-selected-lines/</link>
<pubDate>Sat, 02 Oct 2021 09:37:25 +0900</pubDate>
<guid>https://blog.nsfisis.dev/posts/vim-swap-order-of-selected-lines/</guid>
<description>この記事は Qiita から移植してきたものです。 元 URL: https://qiita.com/nsfisis/items/4fefb361d9a693803520
バージョン情報 :version の一部
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Jan 26 2020 11:30:30) macOS version Included patches: 1-148 Huge version without GUI.
よく紹介されている手法 tac / tail tac や tail -r などの外部コマンドを ! を使って呼び出し、置き換える。
:h v_!
tac コマンドや tail の -r オプションは環境によって利用できないことがあり、複数の環境を行き来する場合に採用しづらい
:g/^/m0 こちらは外部コマンドに頼らず、Vim の機能のみを使う。g は :global コマンドの、m は :move コマンドの略
:global コマンドは :[range]global/{pattern}/[command] のように使い、[range] で指定された範囲の行のうち、{pattern} で指定された検索パターンにマッチする行に対して、順番に [command] で指定された Ex コマンドを呼び出す。</description>
</item>
<item>
<title>[Vim] autocmd events の BufWrite/BufWritePre の違い</title>
<link>https://blog.nsfisis.dev/posts/vim-difference-between-autocmd-bufwrite-and-bufwritepre/</link>
<pubDate>Sat, 02 Oct 2021 09:37:12 +0900</pubDate>
<guid>https://blog.nsfisis.dev/posts/vim-difference-between-autocmd-bufwrite-and-bufwritepre/</guid>
<description>この記事は Qiita から移植してきたものです。 元 URL: https://qiita.com/nsfisis/items/79ab4db8564032de0b25
TL; DR 違いはない。ただのエイリアス。
調査記録 Vim の autocmd events には似通った名前のものがいくつかある。大抵は :help に説明があるが、この記事のタイトルにある2つを含めた以下のイベントには、その違いについて説明がない。
BufRead/BufReadPost BufWrite/BufWritePre BufAdd/BufCreate このうち、BufAdd/BufCreate に関しては、:help BufCreate に
The BufCreate event is for historic reasons.
とあり、おそらくは BufAdd のエイリアスであろうということがわかる。他の2組も同様ではないかと予想されるが、確認のため vim と neovim のソースコードを調査した。
ソースコードへのリンク vim (調査時点での master branch) neovim (上に同じ)
vim のソースコード 以下は、autocmd events の名前と内部で使われている整数値とのマッピングを定義している箇所である。見ての通り、上でエイリアスではないかと述べた3組には、それぞれ同じ内部値が使われている。
https://github.com/vim/vim/blob/8e6be34338f13a6a625f19bcef82019c9adc65f2/src/autocmd.c#L85-L86
{&#34;BufAdd&#34;, EVENT_BUFADD}, {&#34;BufCreate&#34;, EVENT_BUFADD}, https://github.com/vim/vim/blob/8e6be34338f13a6a625f19bcef82019c9adc65f2/src/autocmd.c#L95-L97
{&#34;BufRead&#34;, EVENT_BUFREADPOST}, {&#34;BufReadCmd&#34;, EVENT_BUFREADCMD}, {&#34;BufReadPost&#34;, EVENT_BUFREADPOST}, https://github.com/vim/vim/blob/8e6be34338f13a6a625f19bcef82019c9adc65f2/src/autocmd.c#L103-L105</description>
</item>
<item>
<title>[Python] クロージャとUnboundLocalError: local variable 'x' referenced before assignment</title>
<link>https://blog.nsfisis.dev/posts/python-unbound-local-error/</link>
<pubDate>Sat, 02 Oct 2021 09:32:37 +0900</pubDate>
<guid>https://blog.nsfisis.dev/posts/python-unbound-local-error/</guid>
<description>この記事は Qiita から移植してきたものです。 元 URL: https://qiita.com/nsfisis/items/5d733703afcb35bbf399
本記事は Python 3.7.6 の動作結果を元にして書かれている。
Python でクロージャを作ろうと、次のようなコードを書いた。
def f(): x = 0 def g(): x += 1 g() f() 関数 g から 関数 f のスコープ内で定義された変数 x を参照し、それに 1 を足そうとしている。 これを実行すると x += 1 の箇所でエラーが発生する。
UnboundLocalError: local variable &lsquo;x&rsquo; referenced before assignment
local変数 x が代入前に参照された、とある。これは、f の x を参照するのではなく、新しく別の変数を g 内に作ってしまっているため。 前述のコードを宣言と代入を便宜上分けて書き直すと次のようになる。var を変数宣言のための構文として擬似的に利用している。
# 注: var は正しい Python の文法ではない。上記参照のこと def f(): var x # f の local変数 &#39;x&#39; を宣言 x = 0 # x に 0 を代入 def g(): # f の内部関数 g を定義 var x # g の local変数 &#39;x&#39; を宣言 # たまたま f にも同じ名前の変数があるが、それとは別の変数 x += 1 # x に 1 を加算 (x = x + 1 の糖衣構文) # 加算する前の値を参照しようとするが、まだ代入されていないためエラー g() 当初の意図を表現するには、次のように書けばよい。</description>
</item>
<item>
<title>PHPerKaigi 2021</title>
<link>https://blog.nsfisis.dev/posts/phperkaigi-2021/</link>
<pubDate>Tue, 30 Mar 2021 23:22:40 +0900</pubDate>
<guid>https://blog.nsfisis.dev/posts/phperkaigi-2021/</guid>
<description>PHPerKaigi 2021 参加レポ 2021/03/26 から 2021/03/28 にかけて開催された、PHPerKaigi 2021 に一般参加者として参加した。 弊社デジタルサーカス株式会社 (今年1月から勤務) はダイヤモンドスポンサーとなっており、スポンサー枠のチケットを使わせていただいた。
このようなカンファレンスには初めて参加するのでかねてより心待ちにしていたのだが、生憎2日目から体調を崩してしまい、この記事も途中までとなっている。まだ見ていないセッションも多いが、ひとまず現時点での参加レポを書いておく。
発表はトラック A、B に分かれていたのだが、今回はすべて A トラックを視聴している (切り替えるのが面倒だっただけ)。
凡例 発表・スライドのメモ (引用ではない)
感想など
Day 0 前夜祭 (2021/03/27) 17:30 [A] PHP で AWS Lambda
Rails のプロジェクトを PHPer のメンバのみでメンテ →他のメンバもわかる PHP にリプレースを検討
サーバレス
サーバ・インフラの管理が不要 アプリケーションコードの知識だけで保守可能 ゼロベースで作れる案件が (Railsの件とは別に) あるため、そちらで試験的に導入?
AWSの学習 AWS のドキュメント DevelopersIO
AWS Lambda のカスタムランタイムで PHP を動かす
サーバのセットアップや維持管理を気にしなくて良い サーバーレスで PHP を動かすツールがすでにある サーバーレス構築はすんなり
今は Laravel がルーティングしている Laravel Livewire を Lambda に載せられないか？ デプロイ方法は？ バッチ処理は？ (Lambda は 15分の制限)</description>
</item>
<item>
<title>My First Post</title>
<link>https://blog.nsfisis.dev/posts/my-first-post/</link>
<pubDate>Fri, 05 Mar 2021 23:38:21 +0900</pubDate>
<guid>https://blog.nsfisis.dev/posts/my-first-post/</guid>
<description>Test Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</description>
</item>
</channel>
</rss>
|
