はてなブックマーク

第2回から第5回にかけては、Node.jsの伝統的なモジュールシステムであるCommonJSに絞って挙動を説明していました。これらはECMAScript 2015で導入されたES Modulesで置き換えられつつありますが、それ以外にもいくつかのモジュールシステムが提案され、運用されてきました。これらのうちAMD, UMD, SystemJSについて本稿で扱います。 ←前 目次 モジュールローダー モジュールシステムをWebブラウザでも使うための方法として、モジュールバンドラーを前回紹介しました。 モジュールバンドラーが依存関係をビルド時に解決する一方、依存関係をクライアントで実行時に解決する方法 (モジュールローダー) も古くから試みられていました。1 Node.jsは依存関係を実行時に解決するので、ある意味ではこちらのほうが自然な方法に見えます。ここでCommonJSがそのまま使えたら

←前 目次 次→ モジュールバンドラーとは 前3回までで説明したNode.jsのモジュールシステムとnpmのパッケージシステムは、再利用可能なJavaScriptプログラムを作り、配布し、利用する仕組みとして非常によくできたものでした。そのため、このNode.jsのモジュールシステムをブラウザでも利用したいという需要が生じることになりました。正確には以下の2つの需要がありました。 Node.js用に書いたプログラムをブラウザでも再利用したい。 純粋にブラウザ向けのJavaScriptコードでも、モジュールシステムやパッケージシステムを使いたい。 これらの願いを同時に叶えるべく、Browserifyをはじめとしたモジュールバンドラーというツールが開発されました。モジュールバンドラーは複数のJavaScriptモジュールを結合し、ひとつのJavaScriptファイルを生成します。 モジュールバ

前回に続きnpmの機能について扱います。今回はnpmとコマンドラインツールとの関わりを中心に見ていきます。 ←前 目次 次→ 注意: Windowsとそれ以外では、npmのフォルダ配置は異なります。Windowsでの挙動についてはnpm-foldersを参照してください。 グローバルインストール npmは通常、Node.jsの配布物に同梱されていますが、yarnは同梱されていません。yarnを使う場合は次のようなコマンドを実行します。 これによって以下のような効果が発生します。 $PREFIX/lib/node_modules/yarn 以下にyarnの中身がインストールされる。 $PREFIX/lib/node_modules/yarn/node_modules 以下にyarnの依存関係がインストールされる。 $PREFIX/bin にシンボリックリンク yarn, yarnpkg が生

前回はNode.js単独での機能に焦点をあてて説明しましたが、Node.jsはnpm/yarnなどのパッケージ管理システムと組み合わせて使うことが想定されています。本稿ではライブラリの依存解決としての側面を中心に、npm/yarnの挙動を説明します。 ←前 目次 次→ モジュールからパッケージへ モジュールは、JavaScriptプログラムを複数のファイルに分割し、必要に応じてロードする仕組みでした。 (1ファイル = 1モジュール) 一方パッケージは、複数のモジュールファイルをまとめて1つの独立した単位として扱う仕組みです。パッケージというより大きなまとまりを作ることで、バージョン番号を付与し、パッケージをパッケージレジストリに登録し、依存管理をすることができるようになります。 Node.jsと package.json パッケージはおおよそ package.json の存在によって特徴

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 webpackとかbabelとか、JSのすごいエコシステムを基本 (ブラウザ、Node.js, npm) から順番に調べていきます。 経緯 最近は npx create-react-app ... とやるといい感じに環境ができていいのですが、複雑なことをやろうとしたり、既に複雑になってしまったものを触るにはきちんと中身がわかってたほうがいいな……と思い始めたのでぼちぼち自分で調べ始めました。アウトプットしながら調べたほうが効率がいいので、このように記事として残します。 目次 (予定) とりあえず思いつくだけ書き出したもので、全ての

use std::num::Wrapping; pub fn is_square(x: u64) -> bool { let xtz = x.trailing_zeros(); if x == 0 { return true; } else if xtz & 1 != 0 { return false; } let x = Wrapping(x >> xtz); let mut y = Wrapping(1_u64); for _ in 0..5 { y = ((Wrapping(3_u64) - y * y * x) * y) >> 1; } let mut xrt = x * y; if xrt.0 & (1 << 32) != 0 { xrt = -xrt; } let xrt = xrt.0 & ((1 << 32) - 1); xrt * xrt == x.0 } 結論から言うと

RustはトレースGCを持たずRAIIと所有権に基づくメモリ管理を行います。これには様々な利点がある一方、相互参照をもつデータの扱いが他のプログラミング言語より難しいという困難があります。本記事では、あまり一般的ではないが特定の限られた用途では有用と思われる方法を紹介します。 標準的な方法 まずは相互参照が起きないように設計を再考するのがいいでしょう。特に「子データから親データを参照する」といったユースケースでは、必ずしも子データ自体が親データへの参照を持たなくてもいいことがあります。以下ではこれに当てはまらない例、典型的にはグラフの表現を念頭に置いて記述します。 Rustで相互参照を扱う最も標準的な方法は、typed_arenaなどのアリーナアロケーターと RefCellなどの内部可変性コンテナを組み合わせる方法です。これについては私のブログ記事などを参考にしてください。 またRustの

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

概要: Rustの Arc 型の実装は宝の宝庫です。そこで、これを隅から隅まで解説してみます。 第4回「アトミック変数とメモリ順序」では、Arc のマルチスレッド処理を読むにあたって必要な事前知識を解説します。第4回は1～3には依存せず読めるはずです。 第1回 Arc/Rcの基本 第2回 Rcを読む基本編 第3回 Rcを読む発展編 第4回 アトミック変数とメモリ順序 第5回 Arcを読む はじめに 第2回～第3回にかけて、 Arc のシングルスレッド版である Rc の実装を読んできました。残るは Arc 特有の部分ですが、それに入る前にアトミック変数に関する事前知識を解説します。 まとめ 一般論としてマルチスレッドプログラミングでは競合状態が問題になるため、ミューテックスなどの並行性プリミティブを用いて競合を防ぐ必要がある。 C++やRustなどより低レイヤを扱うプログラミング言語では、ミ

概要: Rustコンパイラはすでに部分的に並列に動作していますが、本命であるフロントエンドの並列化の実用化が進んでいます。エンドユーザーが気軽に試せる状況になったようなので紹介します。 12月7日のアドベントカレンダーの枠が空いていたので、かわりに書きました。(執筆日は12月21日です) 端的に言うと internalsのアナウンス記事に全てがまとまっています。以下のようにして「並列化対応版」と「並列化未対応版」の両方でコンパイルして、その結果を比較することができます。 コンパイル結果がおかしくないか、またコンパイル時のパフォーマンスなどを調べてほしいようなので、上記のコマンドを実行したらスレッドに投稿すると大変な貢献になると思います。 はじめに Rustコンパイラは現在、部分的に並列に動作しています。具体的には以下のようになっています。 パッケージマネージャ Cargo は、依存関係のな

以下補足です。 効率 トレードオフを強調するために、相対的な効率を星の個数で表しています。しかし、効率をことさら気にする必要はありません。他の多くのプログラミング言語では、Rustでいうところの Arc<Mutex<T>> をデフォルトで使っているような状況です。要件にあったものを使うことが大事です。 ライフタイム 「短命」とついているものは基本的に、ある関数のスコープに紐付いた形でしか使えません。特に慣れないうちは、これらの型を構造体に入れて使うのはやめておいたほうが無難でしょう。 例外として、グローバル変数 (static, lazy_static!) は &'static 参照として扱うことができます 共有 「ポインタ」と聞くと、参照先が共有されている様子を思い浮かべる人が多いと思いますが、所有権の概念のあるRustでは必ずしもそのイメージは当てはまりません。 &mut T と Bo

概要: Rustの Arc 型の実装は宝の宝庫です。そこで、これを隅から隅まで解説してみます。 第1回「Arc/Rcの基本」では、実際に Arc のソースを読む前に Arc/Rc の使い方を解説します。 第1回 Arc/Rcの基本 第2回 Rcを読む基本編 第3回 Rcを読む発展編 第4回 アトミック変数とメモリ順序 第5回 Arcを読む はじめに Arc<T> はRustの基本的な型のひとつですが、 Box<T> のようにコンパイラに特別扱いされているわけでもなく、実装も比較的コンパクトです(コメントやテスト、安定性に関する指示などを除いて500LOC程度) その一方で Arc は並行性制御や Deref, ドロップチェッカー, Unpin, Layoutの扱いなどRustをよりよく理解するための題材を多く含んでいます。そこで本記事では Arc<T> の実装を読んでいきます。 とはいえ、

printf に関する以下のツイートが流行っていました。 上のツイートでは割とあっさり説明されていますが、amd64 SysV ABIでこの現象が起こる理由にはもっと深遠なものがあると思うので、可変長引数とからめて説明してみたいと思います。 前提条件として「ABI」「可変長引数」「non-prototyped関数」の知識が必要なのでそこから説明します ABIとは ABI (Application Binary Interface) とは、機械語レベルでのインターフェースのことです。 機械語そのもののルールはISA (Instruction Set Architecture) によって規定されていますが、たとえばC言語の「関数呼び出し」などの概念を機械語でどのように表現するかについては規定していません。そのルールを定めたのがABIです。したがって、ISAとABIはおよそ1対多の関係にあります

cargo-crevとは 最近、複数のRubyライブラリにバックドアが発見されました。このような事件はnode/npmやPython/PyPIなどでも発生しています。これらは正当な作者のアカウントがハックされてアップロードされているケースや、はじめから悪意のある作者が公開しているケースなどがありますが、いずれのケースでも公開されているライブラリバージョンの安全性が検証されていないことが問題であるといえます。 これに対してRustのcrates.ioに関してもコミュニティーから懸念が表明されています (URLO18860, URLO29989) が、その中でdpc氏が提案しているのが分散コードレビューによる信頼性の担保です。これを実際に実装したのがcargo-crevというツールです。 (なお、RustSecチームがcargo-auditというツールを公開していますが、これは既知の脆弱性デー

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

async/awaitの最小限の機能が、 Rust 1.38.0 リリースを目標に準備されています。Rust1.36.0のリリースが2019-07-04で、Rustは6週間ごとにリリースされるので、順調にいけば 2019-09-26 頃にリリースされると思われます。もちろんnightlyではすでに試せます。 さてこのasync/awaitですが、他の言語のasync/awaitと基本コンセプトは近いものの、いくつか異なる点があります。個人的には以下のことを把握しておくとよいと思いました。 後置await構文 戻り値型 (内部戻り値型・実装ごとに異なる型) 駆動 (awaitまたはspawnしないと進まない) キャンセル (awaitポイントは中止ポイント) 本稿は現象の説明にとどめ、そうなっている理由には基本的に言及しませんが、どれもきちんと理由があってそうなっています。その点はご承知おき