思ってるの？

前からずっと思ってたんだけど smhn のひとたちは僕のことをなんだと思？

退職祝いでもらった鼻セレブ、ついぞ鼻に使われることはなく亀セレブとして一生を終えてしまった

This account is not set to public on notestock.

Vulkan でなにか作ってるとかではなかったのか

@rinsuki あーなるほどね

その拡張何に使いたいのかしら

今のところ 3on3 以外で当たったことないな

これになりたい
https://twitter.com/tyarhannnogu/status/1396208190614753283

そういえばうにまりくん生やすやつどうですか

ちなみにおたかんアイスのシリーズだと僕はみかんだかオレンジのやつが好きだったな

まあ最悪誰用だろうと Blender で気合で着せちゃうから関係ないっちゃないが……

作者が同じだとリネームの手間が省けるというわけでもなく……

なんとなくリアアリスちゃんのを 1.1 倍ぐらいして使ってるけど奥行きがけっこう余る感じがするんだよな

僕はたまに見かけたもんだけど

え、空の容器が砂場に埋まってることないですか

受付嬢さんと比較的体型が似てて(均一なスケーリングは許容する)かつ服が比較的多いのって誰なんだろう

サマースタイル

よく公園の砂場に埋まってるやつー！

1 枚を 3 日も穿くな

まさかその人じゃあるまいと思って脳内候補から外してたのに

This account is not set to public on notestock.

This account is not set to public on notestock.

@omasanori ええこの人なの……

結局誰なものなの

その曲地味にEverything より難しいよ

でてこない……

This account is not set to public on notestock.

誰誰誰誰誰誰誰誰誰誰

ホロ 5 期生、本人よりそぎぎイラスト眺めてる時間のほうが長い

iPhone の性能別ネーミング、ぶっちゃけ Mac/iPad に合わせてもええんちゃうんと思うけど細分化が足りないとかかね

iPhone の Wi-Fi モデル出せやという意見もありそうだけどそうすると Phone 要素なくなるしな……

これはなんとなくだけど Pro と Air 相当しかなくね？みたいな感じを受ける

今でいう無印 iPad みたいな立ち位置のやつが iPhone にも出ないんかねえ

にしては価格差がだいぶすごいよな

でもあっちの品揃えもびみょいな

Android 搭載ウォークマンとかに流れるんかなあ

iPod touch、今だとどこが受け皿になるんや

ほぼ iPhone 7 と同じような仕様っぽいね

さすがにもう 13 年前のスリムタワー処分してもええやろ

KH245V は残すとして E2209HDS はマジで回収してもらわんと

古いの処分しないとなあ

そんだけ重いと VESA マウントの部分でバキっといかないか心配になるな……

軽いというより剛性がなくて動かすのが怖い問題

RC241YUsmidpx がスタンド抜きで 2.5kg、AmazonBasics のモニタアームの下限が 2.3kg らしいのでこれもけっこうギリっぽさはある

バストアームやね

モニタアームに乳吊らないで

そしてあまりにも重すぎると今度は VESA 非対応になりそう

40 インチ台後半とかじゃないとなさそう

S3221QS でもスタンド抜きで 7.4kg 、デカそうな U4021QW とかでも ギリ 10kg いってない

乳の話じゃねえよ

43" 4K とかなら重そうだと思いきや薄型にふっててそこまで重くなかったり

でも単体で 10kg 越えるの中々ないな

普通のサイズだったら LX で十分っぽい

でも Ergotron HX の対応荷重ほぼ下限なのもすごいな どんだけ頑丈やねえ

LEGION Y44w どんぐらい重量あるんだろと思って調べたらスタンド無しで 9.2kg もあんのか

ウルトラワイド置きて～めうね

おしゃま一発でクリアできて草

うおーークリアできた

7thSense FTR 何回やっても意味不明な譜面でわろける

レンガ(brick)呼びが多いよね

OK

合計したら 2 万円ぐらいなって泣いとる 本当にそこそこ良い服買えるじゃん リアルで

爆買い中国人なってまう

助けてくれ

受付嬢さんの服少ない問題

now

リアルの自分の服より V の服に金をかけているのでおわりやね

めっちゃ夏服探してる

そろそろ服重ねるのやめてアバター分離するかね

うれしいから再放送しちゃお(？)

今日のプロセカ

This account is not set to public on notestock.

おっちぃ

そもそもパケットを投げ合うスタイル自体が省電力に合わせて変わってるはずなのんで

BLE は本流の Bluetooth とは別の規格だったはず

使わないだけで見てはいるってこと？

BLE?

なんとなくデフォルトの MASTER_LEFT のまま使ってたけど PC 本体 右側にあるんだから右に繋げたほうが良いに決まってるんだよな

左右どっちに USB 接続しても左右ぶっ壊れなくなった

is_keyboard_left か

ということはこれはあれだな、マスターかどうかじゃなくて左右を直接取らんといかんのか

入力される情報は大丈夫なんだけど左右が反転しちゃうな

いやダメだわ

これで多分どっちに繋いでも大丈夫になったな

Note: QMK Firmware で EE_HANDS 対応にする - Naartski
https://marks.hinanawi.net/shaare/E25ReA

僕が昨日おたかんに言ってたやつ

This account is not set to public on notestock.

@Otakan951 ぷあおうおたかん

This account is not set to public on notestock.

最後のやつは if else で怒られやすいことで有名ですね

まあパサジェネに任せるぶんには「ここ無限先読みじゃボケ」「最終どっちともとれるじゃねえかカス」「進むか退くかはっきりしろアホ」などという文句をたれてくれるので大丈夫じゃないかな

LL パーサーで手を抜く方法として似た要素を同じ AST でまとめて扱うというのがあるんですが、これをやると意味解析がどんどん面倒になる

例えば関数宣言か定義かは(もし区別するのなら)引数リストの次がセミコロンか中カッコかわかるまでどっちか区別つかないけど引数は可変なので無理ですよねという話がある

LR は可能性を残しつつ決まり字でいい感じに分岐して最後のトークン読んで構文要素を確定する

この例だともう一個先読みすればわかりそうだからまだいいんだけど、要素が確定する瞬間のトークンまでが可変個だと実質無限に先読みしなきゃいけないのでダメなんですよね

int が来ました、次は hoge らしいです、さあ答えをどうぞ！ ってのがより正確やね

あ、ちょっと語弊があったな 構文解析時の OR 選択を次のトークンを読んで決定しなきゃいけないのが LL1

function とか var とか前置してあげれば何が来るか確定するから安心して LL でパースできるわけですね(JS が LL でいけるとは限らない)

対して LL 法だと int を読んだだけでそれらのいずれかを確定しなきゃいけないという序盤から詰みが発生する

LR 法でこれを回避できる理由は「ケツを読むまで確定しないから」で、さっきの例で言えば最後のセミコロンを読んだ瞬間に実は今まで解析してたのは(変数|関数)宣言だったんだなあとなる

C 言語を読めるパーサーを書けないわけじゃないが構文木としてはだいぶナンセンスなものになりそう

でも純粋な LL(1) だと C 言語の変数宣言と関数宣言すら見分けられなくて死ぬはず

たぶんそれぐらいの構文なら全然 LL で表現できる

@Otakan951 おやすみおたかん

どちらかというと LL は「こういう道を辿ってきたんだから次はイオンが見えてくるに決まってるだろ」か(だから予言的とも言われる)

コンビニが見えたのでとりあえず曲がってみて、まあなんか色々進んだら(東京|名古屋|京都|大阪)に着きましたよかったね、みたいなんが (LA)LR

そこにコンビニがあるとして、このコンビニが見えたら絶対にこうとしか進まねえぞという鋼の意思 変な道が出てきたらおしめえよ

LL は目の前の道が進入禁止だったらそこで止まるみたいな

LALR はなんというか、「運転してて気付いたら森の中にいた」みたいな失敗のしかたをする

LL なら割とエラー位置は期待がモテるな

ANTLR って LALR 吐くんだっけ、だとすると本当に間違ってるところよりちょっと後めが出る傾向にあると思う(まともな生成系ならエラー位置取れないってこたないでしょうきっと)

皮膚家、何

(since, 皮膚家じゃない) をただの文字列ペアでもっといて、クエリ組立時に日付じゃねえじゃんつって無視するやつ

たぶんパサジェネだと死ぬやつだし手書きでもまあまあ面倒だと思うので構文としてエラー拾う必要はないかなあ

まあエラー位置がわかりやすいなら単にここがダメってエラー出して戻っても良さそうだけど

汎用構造としては完成してるけど意味がダメなやつともいえる

終わらないシリーズはまあしょうがないとして、たとえば "--help since:日付じゃない" みたいなクエリをどうするかという

clause の段だけループでエラーチェックしてダメだったらそこを単に捨てて続行するみたいな芸当できるんかな

ANTLR が吐くコードがどうなってるかによるか

🚄のこと考えてたら私鉄になっちゃった

そういえばクエリの解析が失敗した場合ってどう私鉄？単にその区だけなかったことにするとかできるのかな

tag とかキーワードあるなら同列に突っ込めそうという意図です

まあ since と until 句追加して WHERE に追加するだけだから変な作業はいらなさそう

日付範囲サポートはほしいね

その実際のクエリに起こすステップ僕はけっこう興味あるな コンパイラのコード生成みたいで

Eloquent に乗せるとなると別のレイヤーの苦労が発生しそうだけど Fluent に乗せるぐらいならまあ

クエリ AST から実際に SQL 生成するのは中間表現さえちゃんとしてればわりとすぐじゃない？

えっ新幹線いいな

This account is not set to public on notestock.

まあでももともと PHP 実装が正規表現ベースの手書きだったからってのがデカいかも

S3WF2 は「既存のパサジェネに載せるの面倒そう」というのと「WASM にしたとき爆発しそう」というのが半々ぐらいで手書きパーサーになった

サーバーサイドで動かすかつコード生成なら合計サイズとか気にしなくていいもんなあ

桟橋でワンカップ飲んでるの完全に先のないおっさんなんだよな

This account is not set to public on notestock.

ほえ～

ていうか ANTLR って Java 以外ターゲットにできたんだ……

その g4 ファイル後生大事にとっておいたほうがよいですよ(？)

ああそれならだいじょうぶ そう

PHP 単体でパーサージェネレーターするやつとかありそうかなと思ったけど動作速度がちょっとアレか(PHP の環境と圧倒的に相性が悪そう(

それはそうっぽい……

This account is not set to public on notestock.

パサジェネ使うならライブラリの選定は慎重に……って言おうとしたけどどちらかというと構文を何らかの形で定義しておくほうが重要そう

Steam クライアントもいい加減そろそろオーバーホールしてほしい感あるけど難しいんかねえ

こういうところやっぱりまだ Per-Monitor DPI は若干難があるよなあ

フルスクにするときに対象のディスプレイを選択できないゲームがまあまああるので基本的にメインの設定は 4K のほうのままにしておきたい

策としては今のところ
・サブも 150% にする。確実だけどちょっともったいない。
・今のサブをメインに設定する。ゲームのフルスクがたまにバグりそう。
・タスクバーをメインに持ってくる。論外。狭くなるじゃん。
・Steam のタスクアイコンメニューをあてにしない。ちょっと不便、
あたりが考えられて、現在採用しているのは 4 つ目

This account is not set to public on notestock.

1. Electron っぽいやつ(Lowkey.gg も同様)
2. Win32 標準(これがズレてたらさすがにダメだろ)
3. ShareX (.NET ならなんでも？サイズだけズレる)
4. Steam (出ない)

This account is not set to public on notestock.

そういえば HiDPI おたくに聞きたいんですが、メインディスプレイと違う倍率のディスプレイにタスクバー置いてあるときに Steam のタスクバーアイコンの右クリックメニュー出なくないですか

This account is not set to public on notestock.

「海水浴なんて庶民のすることですわ」とか言ってたけど実際来たらめっちゃ楽しんでるお嬢様

ラストシーンやね(何の？)

H o t l i n e M i a m i

This account is not set to public on notestock.