[diff] tool = meld [merge] tool = meld [mergetool "meld"] cmd = meld $LOCAL $MERGED $REMOTE keepBackup = false build.sh（適当につくったスクリプト） 普段複数のパッチを別のブランチで作業していますが、パッチAをレビューに投げる→パッチBを書く→パッチAに戻る、としたときにビルドしたバイナリがそのままのこっていると何かと便利だなということを感じていました。 そこで、適当にninjaを叩く代わりのラッパースクリプトをかいて、ブランチごと＆ビルドオプションごとのディレクトリを掘ってビルドするようにしています。 https://gist.github.com/makotoshimazu/1a9bd0a3f43a471057fc587f192571f9 やってくれることとしては、ブラ

Chromium Code Review Advent Calendar 2017の25日目の記事です。参入障壁が低かったのでなんとなく書いてみました。興味のある方は充実の本家Chromium Browser Advent Calendar 2017も参照下さい はじめに オープンソースのウェブブラウザ Chromiumでそこそこ長く開発をしてるので、自分や周りの人がコードレビューで心がけていることを書いてみました。良いコードとは何かという話はまた別の長い議論になるのでここではとりあげません。 基本的に、コードレビューはコミュニケーションと思っており、うまくやることで開発効率をあげたりコードベースをより良くしたりできる可能性があると思ってるので、そんなことを書こうかと思います。なお、目指しているだけで、必ずしもいつもできているわけではないです 以下、唐突にである調で。 レビューレイテンシを

こんにちは、xhl_kogitsune です。2017年は Chromium の module script 実装の Blink 側の半分とかを作っていました。 今日は Chromium Browser Advent Calendar 20日目として、ES6 Modules のエラー報告の仕様(とChromium実装)を決定的(deterministic)にした話をします。 ES6 Modules は、モジュール間の依存関係を元にネットワークから複数の JavaScript ファイルをダウンロードしてきて実行してくれる便利な機構ですが、モジュールになんらかのエラーがあった時、エラー報告の挙動が非決定的であるという仕様上の問題がありました。今回はこの問題が認識され解決される過程を解説します。 グラフ理論の問題を考える、アルゴリズムを提案しあい反例を挙げあう、決定的だの可換だののワードが飛び交

この記事は WebAudio/WebMIDI API Advent Calendar 2017 Advent Calendar 2017の25日目です。 TL;DR この記事はChromiumのWeb AudioのコミッタであるSoftware EngineerのHongchan Choiが書いたEnter AudioWorkletの記事の邦訳です。 (This is the Japanese version of 'Enter AudioWorklet' of Google Developers.) 前書き Chrome 64（実験的フラグ付きではあるものの）で待ち望まれていたWeb Audioの新しい機能AudioWorkletが利用可能になります。この記事ではJavaScriptでカスタムのAudio処理を作つことを首を長くして待っていた開発者へAPIのコンセプトと使い方の紹介を書い

Chromium Browser Advent Calendar 2017の23日目の記事です。 まえおき Advent Calendarを順に読んできたみなさんは、そろそろChromiumにcontributeしたくなってきている頃かと思います。この記事では、Chromium中で使われるスレッドまわりの内部ライブラリと、標準ライブラリとの違いを紹介します。わりと頻繁に変わるので、自分で使うときには要確認です。 ブラウザプロセス、レンダラプロセス Chromiumはマルチプロセス1なブラウザですが、Blink部分とそれ以外2、もしくはレンダラプロセス3とブラウザプロセス4ではだいぶ様子が異なります。今回はブラウザプロセスの話。大部分の処理をメインスレッドで行うレンダラプロセスと違って、ブラウザプロセスでは複数のスレッドを飛び回って処理を進めています。 ネームドスレッドとスレッドプール ブラ

はじめに この記事はChromium Browser Advent Calendar 2017の22日目の記事になります。 ChromiumプロジェクトでFetch APIやService Worker周りを担当しているhoroです。つい先日、Microsoft Edgeの開発者版やSafariの開発者版でもService Workerが使えるようになったそうで、非常に嬉しい限りです。 さて、今回は、Service Workerにも少し関係がある、JavaScriptのコードキャッシュについてです。 コードキャッシュとは この資料によると、現実世界のWebページでは、V8の実行時間のうちJavaScriptのパースに15-20%の時間がかかっていると言われています。 そこで、Chromiumでは、頻繁に読み込まれるJavaScriptファイルに関して、パース処理によって生成されるバイトコー

この記事はChromium Browser Advent Calendar 2017 19日目の記事です。カレンダー参加者にはChromiumコミッタの方たちが並んでいますが、空きがあったのでせっかくならと思い飛び込んでみました。 まえがき 筆者は普段WEBアプリケーションのフロントエンド／サーバーサイドの開発をしています。Chrome内部のアーキテクチャや仕組みについてはアドベントカレンダーの他の記事に詳しく書かれているのでそちらに任せるとして（どの記事も力作なのでまだ全部読み切れていない）、普段WEBフロントエンドを書く人間にとって価値のある情報をまとめるべくこの記事を執筆しました。 Chromiumのコードベースはとても巨大で、何も知らない状態からいきなりコードを読み始めるのはなかなか難しいです。普段利用しているブラウザのAPIがどういう風に実装されているかを探そうすのもコツが要りま

『Game Programming Patterns ― ソフトウェア開発の問題解決メニュー』を読み終わったのでその感想とメモです。 読んだ動機 コード設計に関する本は、他にもデザインパターンやリファクタリングの本なども思い浮かんだのですが、デザインパターンは具体的な課題があって、それを解決するために見るカタログのようなものだと思っていて、適用範囲が限定的だと感じています。そして何よりデザインパターンの本はつまらないので、それよりはもっと汎用的に適用できる考え方を学べる本が良いと考えました。一方、リファクタリングの本も今回の質問に対する答えとしてはやや具体的すぎると感じたので見送りました (実はリファクタリングの本はまともに読んだことがないので実際は違うかもしれません。そのうち読みたい)。 「プリンシプル オブ プログラミング」読了 - nhiroki’s weblog 引用文では「リファ

addEventListener('fetch', (e) => { e.respondWith(fetch(e.request.url)); }); このようなスクリプトとページを用意すると、初回のページ訪問時にService Workerが保存され、次回の訪問時にはworker.js経由でレスポンスを取得します。その際に、前回の記事でちらっと紹介したように、worker.jsはmain.htmlとは別のプロセスで動く可能性があります。以下にその状態を図に示してみます。 まずmain.htmlを開くとそのリクエストはブラウザプロセスで処理されます。Service Workerが存在する場合、Service WorkerのあるレンダラプロセスへとFetch Eventが投げられます。 先程の例のように、worker.jsでfetch()を実行すると、Service Workerからリクエス

本記事ではChrome内蔵のプロファイリングツール、tracingの活用方法を紹介する。 本記事は私の個人的な意見に基づき書かれております。私の所属する組織、団体には一切の関係はありません。 はじめに Chromeは誕生以来、常に最速のブラウザを目指して開発されてきた。しかし処理速度を向上させようと頑張ると、うっかりメモリ使用量や電力消費量を犠牲にしてしまう可能性がある。特にAndroidのような携帯端末ではメモリや電池寿命の制約が強く、あらゆるデバイスで最高の使い心地のChromeを目指す上では、これらのトレードオフを実際のデータで深く理解した上で開発の意思決定をする必要がある。 このような背景から、処理速度・メモリ使用・電力消費をはじめ、あらゆるパフォーマンスデータを時系列で統合的に理解出来るように開発されたのがChrome内蔵プロファイリングツール、tracingである。 多機能が故

はじめまして、ひらのです。Blink 上でネットワーク関連の API (XHR, fetch API, WebSocket, …) の実装や、ローディング関連の実装を行っています。 本稿では、Fetch API における Request および RequestInit の keepalive プロパティの実装について解説します。このプロパティの実装は、Chromium のリソースローディングパスのかなりトリッキーな既存実装をいじる必要があり、また、Chromium のマルチプロセスアーキテクチャを意識することも必要なため、(いわゆる下位レイヤーですでに実装されているスイッチに配線するだけの実装と違い) 楽しい実装です。 リンク集 本稿では仕様の説明はほとんど行いません。以下を参照ください。 Fetch Spec (fetch, CORS) SendBeacon Content Securi

これは Chromium Browserアドベントカレンダーの15日目の記事です。 この記事では所属する電子情報工学科の実験でChromiumに「指定したキーワードを含む特定の検索履歴のみ非表示にする」という機能を勝手に実装した時の体験をつらつら書いて行きたいと思います。 学科の先輩で現在Blink-Workerチームにいらっしゃるamiq11さんが在学中にこの実験のTAをされていたこともあって声をかけていただきました。 プロの方々によるとても素敵な記事ばかりが並ぶ中で恐縮ですが、「ちょっと勉強がてらChromiumのソースコードをとりあえず読んでみて、何かちょっとした機能を加えてみたい、改造したい」な ニッチな人々の参考になれば嬉しいです…！ なんで大学の実験でChromium？ 東大工学部電気系3年生は3〜6個のテーマの実験を行うことが必修となっており、私は今学期、他の二つの実験と併せ

この記事は Chromium Browser Advent Calendar 2017 の 12 日目の記事です。 昨年から今年上旬に渡って作っていた高速化の裏側を説明しています。まだ標準でオンになっている機能ではないので「細かい話は別にいいから使ってみたい」という方は ユーザーとして使ってみるには をご覧ください。 V8 Context とは Chromium (Blink) で使っている JavaScript エンジン V8 では、JS プログラムの変数がアクセスできる範囲のことを Context と呼んでいます。これは Web IDL や EcmaScript の仕様で Realm と呼ばれているものに該当します。 細かいことを置いておくと、ウェブページを閲覧する際は、メインページ、<iframe>、Chrome Extension ごとに Context が存在しています。また C

これは Chromium Browser アドベントカレンダーの十日目の記事です。本記事では Chromium における JavaScript のスレッド並列実行環境について仕様・実装・API の面から包括的に紹介します。ブラウザの内部実装に興味がある人を対象に、各機能の使い方ではなく実行モデルに焦点を当てて説明しているため、難易度は高いです。使い方を知りたい人は MDN などの記事を読んでください。この記事をきっかけに実装解読に挑戦してみる人が一人でも増えると幸いです。 本記事を書くにあたり、yuki3 さんに多くのコメントをいただき、議論に付き合っていただきました。ありがとうございました。なお、文責はすべて私 (nhiroki) にあります。誤りや補足、質問などは気軽に GitHub Issue もしくは Twitter へお寄せください。 更新履歴 2018/01/15 Layout

このポストは Chromium Browser Advent Calendar 2017 の 12/8 分です。先日 Medium に投稿した英語版を翻訳し、日本向けに若干加筆したものになります。 Payment Request API が登場してからというもの、おかげさまで非常に多くの方に興味を持っていただいています。一方、その複雑さから勘違いや、誤った情報を元に盛り上がってしまっているような状況が起きています。この記事では、みなさんの反応を見ている中でよくある誤解を解き、正確な情報を提供しようと思います。 そもそも Payment Request API が何かご存じないという方は、まずここから読んでいただくと良いと思います。 Web Payment API? Chrome Payment API? Google Payment API? # すべて間違いです。正しくは "Paymen

これはChromium Browser アドベントカレンダーの五日目の記事です。本記事ではWeb IDL規格におけるcallback interfaceとcallback functionという2つのコールバック仕様を説明します。ウェブ開発者を想定読者としていますが、ウェブ開発の役には立たない内容となっていますので、トリビアとしてご活用ください。 二つのコールバックの仕組み ウェブ開発をしている方々はなにかとコールバック関数を使う機会があると思います。一番有名なのはEventTarget.addEventListenerでしょうか。 document.body.addEventListener('click', () => { console.log("you've clicked"); }, false);

このエントリについて アドベントカレンダーでソースコード→Issue Tracker→プロセス構成と続いているので、この辺でぜひ一度Chromiumをbuildしてみませんか？というのが本記事の趣旨です。が、ただbuildしても面白くないと思うので、libcacaをバックエンドに使ったアスキーアートで描画するChromiumをbuildしてみましょう。正確にはChromium全体はbuildできず、content shellと呼ばれるレンダリングエンジンに最低限のUIを追加したものになります。 また、Chromiumをbuildするには意外とマシンパワーが必要です。そんなマシンないよ！っていう若者はぜひサンタさんにお願いしてみましょう。「俺、将来Chromium Committerになるんだ。そのためには爆速なゲーミングPC開発マシンが必要なんだ。」とかお父さん、お母さんに話してみましょう

この記事はChromium Browser Advent Calendar 2017の3日目の記事になります。 今日の担当はamiq11(twitter, chromium)です。2016年の4月からBlink-WorkerチームでServiceWorkerの実装をしています。このadvent calendarに登録しているchromiumコミッターのなかでもChromium歴が浅いのでちょっと記事かくのドキドキしちゃいますが、がんばります٩(●˙▿˙●)۶ はじめに さて、なうでやんぐな機能であるところのServiceWorker、みなさんつかってますか？ 最近はWebKitでも開発中になったということで話題になりましたよね！ PWA (Progressive Web App)を作る上でもベースとなるこのAPI、その内部の実装について、このアドベントカレンダーでは全体の動きと最近の高速化

はじめに 免責 この記事は私個人の理解や考え方を元に書かれており、GoogleやChromium Projectの主義・主張を代弁する物ではありません。私自身もChromium Comitterとして、仕事でプロジェクトに貢献する事もあれば、雇用主の意図とは関係なくボランティアで個人の時間を投資している事もあります。 crbugとは Chromium Projectと関わるにあたりいちばん大切な、ソースコードとの付き合い方については、初日にnhirokiさんが書いてくれました。 で、ソースコードの次はバグとの付き合い方。Chromium Projectではバグを管理するにあたり、独自のcrbugというシステムを使っています。「シー・アール・バグ」と読む人が多いです。元々はGoogle Codeのシステムで管理されていたのですが、Google Codeのサービス終了に伴い、独自のシステムが利

これは Chromium Browser アドベントカレンダーの一日目の記事です。初日ということで、本記事では Chromium のソースコードを読む上で役に立つであろう、プロジェクトのディレクトリ構成やファイル構成を紹介します。 (2018/04/09) “The Great Blink mv”1 プロジェクトによってついに WebKit ディレクトリが blink ディレクトリにリネームされました。それに伴い本記事の内容を更新しました。差分は以下の通りです。 third_party/WebKit/Source を third_party/blink/renderer に置換。 blink/ 内のファイル名の命名規約を Bar.{cpp,h} から bar.{cc,h} に置換。 置換に伴う説明文の修正。 (2017/12/01) ディレクトリ構成について追記しました。 Chromium