「PC」カテゴリーアーカイブ

Proxy 下で vscode の WSL 拡張へ接続できない

投稿日時:
更新日時:
1

Windows 上の Visual Studio Code (以下、 vscode) で、WSL 上のファイルやシェルを使えるようになる、 Remote - WSL 拡張機能。

これを、プロキシ環境下でインストールしたり更新したりすると、 vscode から WSL 環境ににアクセスするときに、

VS Code Server for WSL closed unexpectedly.
Check WSL terminal for mor details.

とエラーになってしまう。

WSL ターミナルのログを見てみると、だいたい以下のようになっていて、どうやら update.code.visualstudio.com から VS Code Server の更新版のファイルをダウンロードするのに失敗しているように見える。

Starting VS Code Server inside WSL (default distro)
Extension version: 0.39.5, Windows build: 17763. Multi distro support: disabled. WSL path support: enabled
Probing if server is already installed: C:\WINDOWS\System32\wsl.exe  -e sh -c "[ -d ~/.vscode-server/bin/3db7e09f3b61f915d03bbfa58e258d6eee843f35 ] && echo found || echo missing"
No server install found on WSL, downloading server on client side: C:\Users\user\AppData\Local\Temp\vscode-remote-wsl\3db7e09f3b61f915d03bbfa58e258d6eee843f35\vscode-server-linux-x64.tar.gz
Unable to detect if server is already installed: Error: connect ECONNREFUSED 104.42.78.153:443
Launching C:\WINDOWS\System32\wsl.exe sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" 3db7e09f3b61f915d03bbfa58e258d6eee843f35 stable .vscode-server 0  --disable-telemetry' in c:\Users\user\.vscode\extensions\ms-vscode-remote.remote-wsl-0.39.5
WSL version: 4.4.0-17763-Microsoft 
Updating server...
Updating VS Code Server to version 3db7e09f3b61f915d03bbfa58e258d6eee843f35
Removing previous installation...
Downloading:     
Failed
--2019-09-11 20:50:12--  https://update.code.visualstudio.com/commit:3db7e09f3b61f915d03bbfa58e258d6eee843f35/server-linux-x64/stable
Resolving update.code.visualstudio.com (update.code.visualstudio.com)... 104.42.78.153
Connecting to update.code.visualstudio.com (update.code.visualstudio.com)|104.42.78.153|:443... 
failed: Connection refused.
ERROR: Failed to download https://update.code.visualstudio.com/commit:3db7e09f3b61f915d03bbfa58e258d6eee843f35/server-linux-x64/stable to ~/.vscode-server/bin/3db7e09f3b61f915d03bbfa58e258d6eee843f35-xxxxxxxxxx.tar.gz
VS Code Server for WSL closed unexpectedly.
For help with startup problems, go to
https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips

どう解決したものか。

そもそも wget でダウンロードができる状態なのか

続きを読む →

同一ファイルに対して、 複数種類のファイルハッシュを高速に計算する

投稿日時:
返信

ネットワークドライブ上の GB オーダーのファイルに対して、複数のハッシュアルゴリズムでファイルハッシュを計算する必要に駆られていた。
「そんなシチュエーションが本当にあるのか？」と思うかも知れないが、あったのだから仕方ない。

最初は、 PowerShell を使って 愚直に Get-FileHash を 2回 計算していた。
しかし当たり前だが、 2回ファイルをダウンロードすることになるこの方法は遅くて仕方ない。

ということで、 C# でコンパイルしたコード上で、 一度メモリに読み込ませてから複数のハッシュアルゴリズムで計算できるようなコードを作成した。

バッファーサイズを 80KiB 程度とすると、 .NET の仕様で 85KB を境にメモリの扱いが変わる (LOH と呼ばれる特別なヒープに移動する) ことから、 このサイズを超えると一般的に動作速度が下がると言われている。
しかし、今回のコードの場合バッファーが小さいと、 Task 周りの処理がボトルネックになってしまうので、 8MiB くらいのサイズとしている。

80KiB としているのは、 .NET mscorlib の System.IO.Stream.CopyTo メソッドなどでもおなじみなのだが、これが必ずしも正解とは限らないわけだな。

GitHub
dotnet/coreclr
https://github.com/dotnet/coreclr/blob/v2.2.6/src/mscorlib/src/System/IO/Stream.cs#L36-L39
CoreCLR is the runtime for .NET Core. It includes the garbage collector, JIT compiler, primitive data types and low-level classes. - dotnet/coreclr

パフォーマンス

800Mbps 位でシーケンシャルリードできるリモート上の 4GB のファイルを、 4回 ずつ計測した平均を計測した。
Get-FileHash の 2種類目 以外はクライアントキャッシュが効かないように注意し、 計測の各回でハッシュを計算するファイルはそれぞれ別のファイルで、中身はランダムバイナリとした。
Get-FileHash については、 計測の各回では同じファイルに対して -Algorithm パラメータを変えて複数回連続で呼び出した。

計算したハッシュの種類 Get-FileHash 上記の改良スクリプト
1種類 (SHA1) 48.8s 43.3s
2種類 (MD5, SHA1) 60.4s 44.2s
3種類 (MD5, SHA1, SHA256) 83.3s 48.2s

ん？ 計算したハッシュが 1種類 の場合でも、改良スクリプトの方が早いぞ？

うわっ… HashAlgorithm.ComputeHash の実行速度、低すぎ…？

PowerShell v5 相当

GitHub
PowerShell/PowerShell
https://github.com/PowerShell/PowerShell/blob/v0.4.0/src/Modules/Microsoft.PowerShell.Utility/Microsoft.PowerShell.Utility.psm1#L71-L73
PowerShell for every system! Contribute to PowerShell/PowerShell development by creating an account on GitHub.

PowerShell v6 相当

GitHub
PowerShell/PowerShell
https://github.com/PowerShell/PowerShell/blob/v6.0.0/src/Microsoft.PowerShell.Commands.Utility/commands/utility/GetHash.cs#L128-L129
PowerShell for every system! Contribute to PowerShell/PowerShell development by creating an account on GitHub.

上記のように、 Get-FileHash は、内部的に HashAlgorithm.ComputeHash でハッシュ計算を実行している。

で、その HashAlgorithm.ComputeHash がどうなっているかというと、 4KiB 毎に ファイルの読み込みと、 ハッシュストリームへの書き込みを 同期的に 行っている。

ファイルの読み込みも、 (使うアルゴリズムにもよるけど) ハッシュの計算も、 どちらもコストがかかるので、同期的にやってたらそりゃ遅いわ。

ideapad Miix720 Core i7 16GB ~2018年のベストバイ~

投稿日時:
更新日時:
返信
01/15 追記: 価格.com のページは残っているが Lenovo の直販ページへのリンクが切れていて、どうも Lenovo 直販モデルの扱いがなくなってしまっているようだ…
販売代理店モデルはまだあるようなのだが、そちらはメインメモリサイズが 8GB にとどまってしまっている。
CES 2019 で後継モデルが発表されたのかと思いきや、そんなことは全くなく、リーズナブルな Surface ライクのサイズ＆性能のモデルがなくなってしまったのが残念でならない…

唐突だが、 2018 年のベストバイだった Lenovo の 2-in-1 タブレット, Miix 720 の Core i7 16GB モデル をレビューしたいと思う。
（2018年中の記事0は悲しいからね）

のっけから話の腰骨を折るが、 このモデルの発売日は 2017年 の夏ごろで、 2018年 に発売されたものではない。
にもかかわらず挙げているのは、 2019年も迫る現在でもこの端末に相当する良機が見つからないからだ。

購入経緯

まず、私はこれまで Surface Pro 2 (Core i5, 256GB SSD, 8GB Memory) を使っていた。
2013年当時は、 ペン同梱の本体と Type Cover をセットにしても14万円くらい購入ができた。
かれこれもうまる5年使っているので、 バッテリーがヘタヘタだし、 少しの衝撃で勝手に再起動されるようになってしまったので、 これの代替になるマシンが欲しかったのだ。

そこで、 2018年 にこれから数年使うために求めたのが以下の通り。

  • 筆圧対応ペン付きタッチパネル搭載 ラップトップ または 2-in-1
  • メモリは 人権 最低 8GB, できれば 16GB
  • ストレージは 256GB 以上
  • モニターは WUXGA 以上
  • SD または micro SD カードスロット

これを、 Surface Pro 5 や 6 で揃えようとすると、
8GB メモリですら 16万円、 16GB メモリにこだわると 27万円 などというとても手が出さない値段になってしまう。

ところが、この Miix720 であれば実質 12万円 ですべてがそろってしまうのだ。


Surface Pro 2 と比べると、ふた回りでかいが、携帯性は高いので全然問題ない。

主な仕様と特徴

主な仕様は以下の通り。

続きを読む →

Pandoc の Portable Windows バージョンを作る

投稿日時:
返信

Pandoc は、 HTML や、 Markdown, Textile, LaTeX などはじめとした、豊富な各種マークアップ形式を、別の形式に変換できるコマンドラインツールだ。

例えば、 textile → markdown 変換 とか、 HTML → markdown 逆変換 といったようなことができる。

何ができるかは、 Pandoc ユーザーズガイド あたりを参照してほしい。

sky-y.github.io
 
http://sky-y.github.io/site-pandoc-jp/users-guide/
http://sky-y.github.io/site-pandoc-jp/users-guide/

さて、 この Pandoc の Windows 版は msi のインストーラ形式でしか配布されていない。

このインストーラでインストールすると、 ユーザディレクトリの %LOCALAPPDATA%\Pandoc\ (もしくは %ProgramFiles(x86)%\Pandoc\) に実行ファイルを展開して、 PATH を通してくる。
どうやら、システムディレクトリにファイルを置いたりしないようなので、 正直これだけのためにインストーラを実行して、 PATH や レジストリを汚すようなことをしたくない。

ということで、 msi インストーラから、 インストールをせずに実行ファイルだけ取り出して、 Portable 版を作成してみよう。

続きを読む →

ZoneId を PowerShell を使って一括削除 [v3 以上]

投稿日時:
2

Windows では、リモートからダウンロードしたファイルに、 "ZoneId" という物が付加される。
このID が付加されたファイルは、 exe として 実行する際にセキュリティ警告が表示されたり、 .NET アセンブリ dll として PowerShell に読み込む際に、

Add-Type : ファイルまたはアセンブリ 'file:///*.dll'、またはその依存関係の 1 つが読み込めませんでした。操作はサポートされません。 (HRESULT からの例外: 0x80131515)
発生場所 行:1 文字:1
+ Add-Type -Path 'C:\*.dll'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Add-Type], FileLoadException
    + FullyQualifiedErrorId : System.IO.FileLoadException,Microsoft.PowerShell.Commands.AddTypeCommand

などとエラーになってしまう。
160925_1

ファイルが一つだけなのであれば、ファイルのプロパティから『ブロックの解除』をチェックすれば、簡単に ZoneId を削除することができる。
160925_2
しかし、複数個のファイルの ZoneId を一回の操作で同じように削除することができないため、 ZoneId を削除したいファイルが大量にある場合はなかなかウザい。

PowerShell v3 以上を使えば、この ZoneId 削除をいとも簡単に行うことができるので、紹介しよう。

続きを読む →

Photon 2 を BungBungame のオンラインショップで買おうとしたら、罠がいっぱいあった

投稿日時:
更新日時:
1

BungBungame Photon 2 という、 台湾企業の日本法人が販売している、Windows タブレットPC がある。
160701_1

これが、

  • Atom Z3775 より強力らしい、 AMD製 64bit CPU (APU)
  • 4GB RAM
  • 1920 x 1200 視野角 178° IPS液晶
  • N-Trig らしい 筆圧 1024レベルスタイラスペン
  • Wi-Fi 802.11a/b/n/ac 対応
  • それでいて、お値段送料込で 23,056円!! (税込み 24,900円)

という、値段の割には夢のような構成なので、なかなか興味深い。 低価格液タブとして考えても破格のお値段。
もともと2014年登場予定で、2015年に発売開始されたものなので、少し古めの機種ではあるが、ぼちぼち使える性能ではあるだろう。 なにより、格安タブレットなのに 64bit マシンで メモリが 4GB 載っているのは頼もしい。

某匿名掲示板で購入者の感想を見てみても、評判はなかなか上々。
(一応、「値段の割に」と注釈がいるが)

我が家の母艦PCが、家族によってペンタブお絵かきマシンとして占領されているうえ、液タブ（Cintiq みたいな高いヤツじゃなくていいから）ほしいとか言い始めたので、こいつに使わせて母艦を奪還するのにもってこいだ。

どうやら OS は Win 8.1 で届くらしいので、 Win 10 無償アップグレード 期間中に手に入れておこうと思い、購入を決意した。

つい先日まで、Photon 2 の購入は、メールでの手続き ・ UFJ銀行 への振込での支払い という、このご時世なかなか珍しい方法だったらしいが、 どうやら最近オンラインショップ機能と、クレジット決済に対応したようだ。
早速これらを使って購入手続きをしてみたのだが… とにかく途中で購入を躊躇する罠がいくつもあった。
そんな解説を付け加えながら、方法を紹介してみる。

この記事を読んで、自分も買ってみようと思う方は、自己責任でお願いしたい。

会員仮登録する

続きを読む →

npm config -g でプロキシの設定をしているのに electron-quick-start や electron-prebuilt でコケる

投稿日時:
更新日時:
4

プロキシ環境下で、 electron-quick-start レポジトリを npm install しようとしたり、 npm で electron-prebuilt モジュールをインストールしようとすると、 npm config set https-proxy "http://proxy.example.com:8080/" とプロキシを設定しているのにもかかわらず、

Error: connect ECONNREFUSED 192.30.252.128:443
    at Object.exports._errnoException (util.js:949:11)
    at exports._exceptionWithHostPort (util.js:972:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1080:14)

などとエラーが出てしまうことがある。
特定の通信に、 npm のプロキシの設定が使われていないのだ。

Qiita
 
Windowsのnpm installで串を刺してもコケる場合 - Qiita
http://qiita.com/yupika/items/3662166f7872e4011957
Electron-prebuiltのnpmインストールの際にECONNREFUSEDというエラーが出ました。この解決はProxyであることはわかったのですが、npm set proxy "proxy:8080"を設定して...
などでは、 netsh winhttp import proxy source=ie のコマンドを実行するといった解決方法が紹介されているが、 これは WinHTTP を使った通信全体に、 IE の proxy の設定をコピーするものであって、今回の問題の本質ではない。

あくまで、 npm config の https-proxy や proxy で設定したプロキシで、エラーとなっている通信を実行させたい場合の解決方法について述べよう。

解決方法

結論を先に言うと、 npm config --global https-proxy ではなく、 npm config https-proxy を使って プロキシを設定する のだ。

続きを読む →

マザーボードが GA-P55-UD3R のPC を Win 10 アップグレードしたら、ネットワークにつながらない！

投稿日時:
更新日時:
3

来たる 7月29日 に Windows 10 の 無料アップグレードが終了してしまうので、 後回しにしていた 自作のデスクトップPC を Windows 7 から Windows 10 にアップグレードしてみた。

実はこの デスクトップPC は、一度 Windows 8 に更新したあと、使いにくかったのと、当時載せていたグラボとの相性が悪かったのもあって、 Windows 7 に戻した経緯がある。
その後、 グラボは新しいモノに取り替えていたので、 Windows 8.x と互換性がよい Windows 10 なら、なんの問題も発生しないだろうと考えていた。
アップグレード前の互換性チェックも問題なく、更新をダウンロードして長いこと待てば問題なく更新される… はずだった。

ところが、Windows 10 へのアップグレードが完了したあと、OS にサインアップしたら、ネットワークに繋がらないではないか!

Realtek の ネットワークドライバが Win 10 に対応していなかった？

起動後のアクションセンターの通知で、ご丁寧にも 「Realtek の ネットワークアダプター が Win 10 に対応していないから、機能を無効にした」 などと通知をしてくれていた。
お節介な奴め。

このネットワークアダプターは、 GIGABYTE の マザーボード GA-P55-UD3R のオンボードのものだ。
GA-P55-UD3R は 7年前の M/B なので、当然サポートはとっくに切れており、 Windows 10 はおろか Windows 8 のドライバすら提供されていない。
ただ、それは GIGABYTE サポートサイト上での話だ。

GIGABYTE のサポートサイトによると、 GA-P55-UD3R は Realtek RTL8111D のチップセットを載せている。
幸い、 Realtek のサポートサイトには、このチップセットの Windows 10 用のドライバーが提供されているので、それを USB メモリか何かを経由して、インストールすれば良いのだ。

2016/05/15 現在、 Realtek のサポートサイト上の、 RTL8111D を含めた Network Interface Controllers チップセットのドライバーのダウンロードページはこちら↓
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=4&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false

ドライバーをインストールしても、ネットワークに繋がらない？

ドライバーのインストールが完了しても、すぐにネットワークが繋がるわけではない。
Windows 10 アップグレード時に 無効にされたネットワークアダプタは、 ドライバーを更新しても自動で有効にならないからだ。

ご丁寧に、ネットワークアダプタの各項目一つ一つの項目が無効になっているので、必要な機能を有効にしよう。
ローカルエリア接続の各機能の項目を有効にする

これで、ネットワークが有効になったはずだ。

しかし… このデスクトップPCは、 7年間使い続けていることになるのか。
SSD を交換したり、 メモリを積みましたり、 グラフィックボード、 Blu-ray ライターをを交換したりはしているものの、それ以外はそのままだ。
Core i5-750, メモリ 6GB, SSD 128GB (+HDD) の構成だが、現状性能に全く不足を感じず、極めてサクサク動いてくれる。（PC上で、リッチなグラフィックのゲームをしないってのもあるが）
2～3年ごとくらいに H/W を刷新しないと 動作がもたついて使い物にならなかった、 2000年代中盤までは考えられなかったことだ。

Award BIOS で loading operating system から先に進まない

投稿日時:
返信

自作 PC でのおはなし。

容量アップもかねて、バックアップを取りながら データドライブに使っている HDD を取り替えたところ、なぜか

loading operating system...

と表示されたまま止まってしまい、OS が起動しなくなってしまった。

いろいろ試しているうちに、ブートメニュー (ワタシの M/B だと、起動時に F12 キー押し) からブートするシステムドライブを選択すると、問題なく起動することに気づいた。
そして問題の症状は、ブートドライブ選択時にデータドライブを選んだときと同じ状態。
これは… ブートドライブの選択が間違えられているみたい…

ということで、自動的に本来のシステムドライブをブートドライブとして自動的に選択してくれれば解決なのだが、Award BIOS の設定を探しても、HDD の中でどれを優先してブートするか の設定が見つからない。

少し悩んだ結果行き着いた解決策は、「一旦システムドライブだけ接続してブートさせる」。
システムドライブだけ接続すれば、ブートドライブを間違う余地もなく、正常に起動してくれる。
そして一旦自動で選択されたブートドライブは、覚えられるのかなんなのか、次回ブート時に優先して選択されるらしい。
(ブートメニューから手動で選択した場合はダメっぽい)

そもそも、システムの入っていないデータドライブをブーとしようとして止まってしまうこと自体、なんかおかしいのだが、ちゃんと動くようになったので、とりあえずこれで良しとしよう。

※BIOS のメーカやバージョンによって、上記のかなり変わってくると考えられるので、参考にしようと考えている方は注意。

[Powershell] UTF-8 でエンコードされた標準出力を受け取る

投稿日時:
更新日時:
返信

2バイト目に ASCII コードがくることを想定していないコンソールアプリなど、標準出力を UTF-8 として使用するコンソールアプリは少なくない。
しかし、PowerShell は標準では UTF-8 の標準出力をそのまま読み取ることができない。
(後述するが、単純な方法はある)

そういった場合でも、.NET Framework を駆使すれば、ちゃんと文字列として取得できる。

続きを読む →