Visual Studio Code / VSCode Part8

■ このスレッドは過去ログ倉庫に格納されています
2020/06/11(木) 12:01:27.72ID:zrBfgML9
Microsoft発のエディタVisual Studio Codeのスレ

公式
https://code.visualstudio.com/
https://github.com/Microsoft/vscode/

開発状況
https://github.com/Microsoft/vscode/wiki/Iteration-Plans

更新内容(日本語訳)
https://vscode-doc-jp.github.io/updates/

前スレ
Visual Studio Code / VSCode Part7
https://mevius.5ch.net/test/read.cgi/tech/1576059976/
2020/07/13(月) 12:18:34.94ID:8gxxLZRp
1.47でEmmetの画像ファイルのサイズ自動入力updateImageSize使うと
"No valid image source"エラーが出るようになってたんだが今やったら直ってた・・・どういうことだ
2020/07/13(月) 12:21:55.59ID:8gxxLZRp
ああ、直前にHTMLタグのミスを修正したんだった　なるほど自動入力ってこういう動作するんだ
359デフォルトの名無しさん
垢版 |
2020/07/14(火) 14:35:17.40ID:wxNuZUMy
TypeScript の設定ファイル・tsconfig.json では、
//, /* 〜 */ の2種類のコメントを使っているけど、

JSON にはコメントがないから、
右側のファイルエクスプローラーでは、1つの間違いがあると表示されてしまう

これを消す方法ある？
2020/07/14(火) 15:07:54.51ID:2Tt/Vrq1
コメントをもう一つ追加すれば、
1つの間違いがあるという表示は消える
2020/07/14(火) 15:24:02.39ID:rnlBwfUm
>>359
自分の環境ではエラーなんて表示されないんですが、
ファイルタイプはちゃんと「JSON with Comments」で読み込んでるんですよね？

https://i.imgur.com/sUsWtl1.png
362359
垢版 |
2020/07/14(火) 15:53:13.65ID:wxNuZUMy
漏れは、tsconfig.json を少し修正したからね。
どこで間違ったか、なかなか分からない

うわー！
再起動したら、エラーが消えてる！

編集すると、言語モードが変ったのかも。
今のファイル形式は、JSON with Comments になってる
2020/07/14(火) 16:28:02.08ID:UqAnAnhr
なんかファイル開くとエディタの選択ドロップダウンが出るようになった。ウザい。消したい！
2020/07/14(火) 16:59:40.61ID:rnlBwfUm
>>362
自分も行消したり追加したり編集したり、ソース追加したりビルドしたけど結局再現しなかった
https://i.imgur.com/2l5bEPO.png

まぁ直ってよかったね
2020/07/14(火) 17:27:10.70ID:wxNuZUMy
>>363
.txt とか、そのファイルの拡張子に対応して起動する、
エディタを決めていないからでは？

決めている場合は、一々、聞かれないのでは？
2020/07/14(火) 19:20:03.27ID:uU11QeUM
いやあホントにJSONは初手が色々とまずかったなあ
いまのJSONCみたいなレギュレーションだったらもっと可能性が広がったろうに
2020/07/14(火) 19:32:43.16ID:wgJ0zUGI
いや、むしろJSONはムリヤリ広く使われ過ぎ。

仮定の話でいいのなら、ブラウザで流行ったのがJavaScriptでなければよかったのに。
2020/07/14(火) 19:38:12.23ID:uzBWm+4M
でも筋の良いスクリプト言語って思いつかないな
みんな癖がある
2020/07/14(火) 20:17:39.02ID:9/KzgQCa
癖はあるけどそんなに筋が悪いとは思わんがな。
もともと関数型言語として設計された出自が今評価されている気がする。
2020/07/14(火) 20:22:23.08ID:a8718MgF
なんか以前は単語を選択した状態で左の虫眼鏡マークをクリックするだけで
検索窓に選択した単語が入ってくれたような気がするのだけど、いまは
いちいちコピーペーストの操作が要るようになってしまった

これって戻せるのやろか？
2020/07/14(火) 20:26:43.82ID:UqAnAnhr
いやVSCodeで開く選んで来てんだから前みたいにそのまま開けや。
VSCodeはエディタじゃないんですか？と。
なんでいちいちひとつしかない選択肢ビルトイン選ばねえとなんねーんだ？
2020/07/14(火) 20:44:15.03ID:DdAw4wpa
ctrl+fのショートカットじゃダメ？
2020/07/14(火) 22:05:04.90ID:a8718MgF
んー　虫眼鏡のほうは範囲がファイル全部なんだよね
2020/07/14(火) 22:16:43.90ID:DkXMpQVM
>>370
設定の search.seedOnFocus ってやつにチェック入れたら、ファイル検索(Ctrl+Shift+F)の方も選択テキストが入力済みになったよ
2020/07/14(火) 23:27:25.46ID:ZOVsPt12
>>369
>もともと関数型言語として設計された出自が今評価されている気がする。
元から関数型言語なんかに設計されてないから他所で言ったら戦争になってたな。
純粋主義者とかモナドしか知らん連中は息災だろうか。
2020/07/14(火) 23:37:53.56ID:2Tt/Vrq1
JavaScriptで関数型っていうのは
jQueryとかUnderscoreとか関数型を取り入れた
ライブラリと組み合わせて初めて実現できる
素のJavaScript（DOM API含む）は関数型になってないよ
2020/07/15(水) 00:17:56.92ID:DV8DGLcn
jsonはデータの受け渡しに使えばいいだけであって人間が扱うファイルにするのが間違い
yaml使え
2020/07/15(水) 02:56:31.84ID:UH7/Xpl5
>>375
JavaScriptはプロトタイプベースオブジェクト指向言語である、という根本がわかってないヤツはめんどくさそう。
2020/07/15(水) 04:53:18.53ID:IqfNcqeZ
JSON with Comments が主流になってほしい

Yaml は、特定の範囲の再利用ができるので、
例えば、開発用と製品用の設定を同じファイルに書いて、
同じ設定を、コピーせずに使える

でも、形式が格段に難しい
2020/07/15(水) 06:11:25.87ID:4uyaG9vI
へえ

JSON にもコメントを書きたい
https://qiita.com/yokra9/items/1ac03876415d7fd47a65
2020/07/15(水) 06:47:29.33ID:Iul+D8/c
>>375
当初のコンセプトは「ブラウザでschemeを動かす」ってことだった。
Javaっぽい文法やオブジェクト指向とか取り入れられたのはその後。
2020/07/15(水) 10:21:47.72ID:UH7/Xpl5
>>381
コンセプトは、結果と関係ない。
現実は非情である。
2020/07/15(水) 12:13:21.10ID:gwK3CNky
>>381
最初にJavaScriptと独自にリリースされた
DOM APIがオブジェクト指向だった
2020/07/15(水) 12:15:28.97ID:eVOQY7dl
DOMもそろそろ見直しの時期が来てるんじゃないか？
関数型に置き換えるべき
2020/07/15(水) 12:18:58.65ID:gwK3CNky
jQueryをそのまま導入したらいいのにね
DOM APIはJavaScriptだけのものじゃないから

他の言語で対応しづらかったんだろうけど
今はJavaScriptの力が強くなったから
他の言語側でどうにか対応しろって言えるだろ
2020/07/15(水) 14:42:54.88ID:KZXXAVqP
さすがはjQueryバカ、頭悪いなぁ…
jQueryはDOM APIラップしてるだけなんだから、取り入れて呼び出しの形式を同じにしたところが現行DOMの制限はそのまま残る。
そういうレベルの話ししてないから巣へお帰りください。
2020/07/15(水) 14:59:40.35ID:DD98k58m
JavaScript質問スレ荒してるのが今度はここに来たのかｗ
2020/07/15(水) 15:16:00.68ID:02BKVnT1
JavaScriptウゼーからはよWebAssembly実用化して欲しいわ
2020/07/15(水) 15:19:22.69ID:gIMauWsn
jsスレはﾜｯﾁｮｲどころかIDすら非表示だから荒らし御用達
このスレはﾜｯﾁｮｲで防衛すべき
2020/07/15(水) 16:00:24.57ID:FW4X/8zu
すみません、教えてください。よろしくお願いします。
vscodeでjavaを使おうとしたのですが
java:create java project
できません。

vscodeとjdkをインスツールし
jdkはshellで確認できますので、pathも通っています。
vscodeのjava.homeも設定できていると思うのですが
どうすれば、create java projectできるようになるでしょうか？
2020/07/15(水) 16:11:05.50ID:r1yGajkX
エラーメッセージは？
2020/07/15(水) 16:13:05.11ID:KZXXAVqP
「おやじ！メロンパンくれ！」
「うちは果物屋🍈だよ？」
2020/07/15(水) 16:53:30.48ID:2PJdiH7v
>>386
DOMの制限ってなんだよ？
言った誰がDOMの制限の話をしてるんだよ
2020/07/15(水) 16:55:46.07ID:2PJdiH7v
>>388
WebAssembly実用化してもDOMの制限は残るぞ
2020/07/15(水) 17:22:15.36ID:02BKVnT1
>>394
C#のパーサー使うからどうでもいいです
2020/07/15(水) 19:04:50.32ID:+kFtUTX/
>>374
ををを　サンクス！
2020/07/15(水) 19:06:02.51ID:Iul+D8/c
>>382
あの後から取って付けた感ありありのプロトタイプが根本に見えちゃう人はさすがにｗ
2020/07/15(水) 19:33:21.89ID:UH7/Xpl5
>>397
「取って付けた感」を具体的に？
2020/07/15(水) 20:54:46.51ID:Iul+D8/c
prototypeとか[[prototype]]とか__proto__とか
2020/07/15(水) 21:14:26.34ID:UH7/Xpl5
で、それのどこに「取って付けた感」があんの？
プロトタイプベースでそのプロトタイプ情報をオブジェクトに持たせるなら、表現は簡単だし、実装もたぶん簡単だし、悪くないやろ。

ほとんど見当たらないScheme要素よりもはるかに根本的。
2020/07/15(水) 23:39:14.30ID:TFnsludK
[[prototype]]はともかくprototypeと__proto__は最初からじゃねーか
どこが取って付けてるんだ？文句言いたいだけじゃん
そんなんだったらプロトタイプベース自体に文句言うやつのほうがなんぼかマシだわ
2020/07/16(木) 00:41:37.20ID:4le5mWZs
つまりオブジェクトやプロパティというものが実装された言語の上に「特殊なプロパティ」として
プロトタイプチェーンを載っけているところを指してそう言ったわけだが。
Ioのように言語の不可分な要素として実装されていたりあるいはせめてluaのメタメソッドのように
最初から考慮された設計なら違って見えたが。
2020/07/16(木) 01:06:27.07ID:QwF0ci9g
じゃpythonの__hoge__みたいなのは？
phpにも似たようなのあるよね。
2020/07/16(木) 01:25:34.43ID:fGKOjjQM
Pythonはきれいな言語じゃないよお
やっつけ感が大きい
2020/07/16(木) 01:40:17.48ID:ezlrRJ+a
1.47とMarkdown Preview Enhancedの組み合わせでMarkdownのファイルリンクが上手く動かなくなってる
これまでに大量に書いてきたメモの蓄積が･･･
MPEのバージョンアップで直るといいんだが
2020/07/16(木) 02:14:03.73ID:6G5cK3Pi
>>402
それは、個人的な嗜好であり、ただ潔癖なだけ。
# 気持ちはわかるが。
配列オブジェクトも、プロパティにメチャクチャ感があるけど、つまり、そういうポリシー。
「取って付けた感」では全然ない。

たとえば今から新しくつくる言語だとしても、表現や実装の都合で、特殊なプロパティをほかに混ぜてしまう選択は、ふつうにあり得る。

で、Schemeの話はどこにいったんだよ？
2020/07/16(木) 08:17:23.65ID:4le5mWZs
プロトタイプチェーンというものがその配列と同じようなレイヤーで実現されていることを
指して言ったわけなんだが。
それが「根本」に見えちゃうのは主観なんでそれ以上は言わんけど。
2020/07/16(木) 09:07:29.56ID:yJ975u67
スレチ
2020/07/16(木) 09:29:46.00ID:6G5cK3Pi
>>407
日本語能力と言語センスがないことはわかった。

>>408
まあまあ。。。
2020/07/17(金) 21:16:25.00ID:O51Ni2cF
最初からオブジェクト指向言語として設計していたならあのthisはないよなぁ。
2020/07/17(金) 23:39:54.29ID:S1GMEh9P
なんで？最初からプロトタイプベースオブジェクト指向言語として設計されてたよ？
おかしくなったのはそのプロトタイプベースオブジェクト指向言語として設計されてたものに後付けでnewやらthisやらのC++/Java系のクラスベースオブジェクト指向用語を無理やり導入してJavaっぽいクラスベースオブジェクト指向言語に見えるよう無理やりガワを被せようとしたため。
2020/07/18(土) 05:17:12.44ID:gM32+Vtw
TypeScriptでラップすると快適やわ
2020/07/18(土) 11:34:26.80ID:zDePOjuW
>>411
その珍説はどこから？
プロトタイプベースだろうがオブジェクト自身へのアクセスにthisは必要だし、
newによるコンストラクタ呼び出しがなければ別の方法でプロトタイプチェーンを構築
していたことになるが、そいつらがプロトタイプ自身より後付けとは考えにくいんだが。
もちろんどっちもクラスベース固有の概念じゃあない。
2020/07/18(土) 12:25:08.69ID:cNrPu/ON
es2015以降のclass構文はともかく（あれもシンタックスシュガーなのに文法上new使用を強制してるだけだが）、
JSのnewはJavaに見た目を寄せるためのシンタックスシュガー以上の意味はない。
見た目こそ同じnewだが、C++やJavaのnewとは全く異なる。
JavaScript: The Good Parts 133ページ
> new演算子の持つ問題に対するもっとも良い方法は、newをまっまく使わないことである。

使わなくて全く問題ない。
JSのnewはJavaに見た目を寄せるためのシンタックスシュガー以上の意味はない。
見た目に騙されてC++やJavaの知識を転用しようとすると理解を誤る。
2020/07/18(土) 13:48:24.95ID:fwbEJCvA
> 見た目に騙されてC++やJavaの知識を転用しようとすると理解を誤る。

C++やJavaの知識ってなんのこと？
2020/07/18(土) 14:00:57.09ID:N4WthBbf
newとはこういうもの！これ以外のはずがない！という思い込み・囚われている常識、のことかな
2020/07/18(土) 15:08:39.55ID:7WBm5sdR
プロトタイプ系とクラス系の違いも。

つうか、プロトタイプ系はわかりにくいんだよ！
実装は簡単というか、手っ取り早いと聞くので、当時ブラウザに埋め込むにはちょうどよかったんやろけども。
2020/07/18(土) 16:25:25.54ID:DrPRguB/
もともとネスケのためだけのマクロに過ぎなかったしねえ
20数年後にこれを使ってアプリを書く人たちが現れるとは想定してなかったんじゃなかろうか
2020/07/18(土) 16:33:34.40ID:zDePOjuW
>>4124
ああ、プロトタイププロトタイプ言いながら自分でプロトタイプベースで書いたことはないのね。
newをまったく使わないというのは自分で__proto__を操作するかあるいはプロトタイプ継承を
使わないってことになるんだが。
当然、前者を推奨しているわけがない。
2020/07/18(土) 17:07:44.12ID:fwbEJCvA
>>417
プロトタイプが分かりづらいんじゃなくて
昔のJavaScriptが面倒だっただけ

プロトタイプベースでの継承の仕方っていうのは
Object.createを使ってB.prototype = Object.create(A.prototype)
ってするだけの簡単なものなんだが、昔のJavaScriptは肝心のObject.createがなかった。

JavaScriptは最初（1995年ぐらい）からプロトタイプベースのオブジェクト指向だったが
Object.createができたのはECMAScript 5からChromeだと2010年の5から
IEだと2011年のIE9から、つまり15年もの間、JavaScriptは重要な機能が欠けた
不便なプロトタイプベースオブジェクト指向だった
2020/07/18(土) 17:36:07.70ID:7WBm5sdR
>>420
そういう話じゃない。
そもそも継承なんかしないユーザーレベルでも、なんかわかりにくいんだから。

JavaScriptが不出来だからとかドキュメント不足とか、理由はいろいろあったと思うけど、それだけでもない。
2020/07/18(土) 17:53:27.03ID:vfrpqE6H
それはライブラリが不足していただけ
どんな言語でもライブラリがなければ使いづらい
JavaScriptはjQueryが登場してから世界が変わっただろ
2020/07/18(土) 18:19:52.24ID:pq9oSxH0
スレチ
2020/07/18(土) 21:26:08.79ID:7WBm5sdR
>>422
だから、そういう話じゃない。
JavaScriptの使いやすさのことではない。
言語としてのわかりやすさについて言っている。

むしろ、prototype.jsとかjQueryとか出てきてから、JavaScript自体はわかりにくくなった気さえする。
こなれたコードを見る機会が増えて、慣れてもいいはずなのに。なんかわかりにくくて、あやしいからか？

>>423
まあ、VSCodeの話題も出てこないことだし。。。
2020/07/18(土) 21:47:03.20ID:Iib9EfYg
とりあえずお前らのおすすめの拡張
説明付きで教えろください
2020/07/19(日) 00:25:37.44ID:KyV15c0l
最近使うようになったやつ
Draw.io Integration - 作図に便利
Code Spell Checker - typo が減った
2020/07/19(日) 05:09:46.41ID:W3hSYpRn
>>424
JavaScriptのどこがわかりにくいのか全くわからん

日本人が日本語は簡単だが英語はわかりにくいって
言ってるようなもんだろ

言語としてのわかりやすさじゃなくて
お前の知識の問題

でないと俺みたいにJavaScriptが分かる人がいることが説明できない
2020/07/19(日) 07:36:22.70ID:m5eV0pvm
>>425

■SynthWave '84
ネオン調に光るテーマ。
（説明にもある通り、別途Custom CSS and JS拡張を入れてCSSの設定が必要）
https://i.imgur.com/hmvfda3.jpg
https://marketplace.visualstudio.com/items?itemName=RobbOwen.synthwave-vscode

■GlassIt-VSC
VSCodeを透過できる。
https://i.imgur.com/yvH2LSA.jpg
https://marketplace.visualstudio.com/items?itemName=s-nlf-fh.glassit

■Remote Containers
革命。Dockerコンテナ内でVSCodeを開いて開発ができる。
これのせいでもうVSCode以外で開発する気起きない。
https://microsoft.github.io/vscode-remote-release/images/remote-containers-readme.gif
https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers
2020/07/19(日) 11:32:11.41ID:xggXZiaY
>>428
一番下便利そうだな。
どうせDockerで開発するならこれありゃWSL2なんかいらんかったなｗ
2020/07/19(日) 11:38:21.65ID:m5eV0pvm
>>429
ホストとコンテナのボリュームをマウントするときに、ホストがWindowsだといろいろめんどいのでWSL2も使うのがオススメ

Windowsで使う場合、WSL2で立てたlinuxマシンにRemote WSLで繋いで、そこからRemote Containersを使うのが良い
2020/07/19(日) 11:59:48.19ID:W3hSYpRn
>>429
そのDockerはWSL2上で動いてるんだぞ？
2020/07/19(日) 12:00:08.13ID:xggXZiaY
ややこしいな…
2020/07/19(日) 12:06:59.74ID:jXwWFSFG
WSL2のDockerはメモリ消費しすぎで使い物にならない
2020/07/19(日) 12:11:35.65ID:Jl4hgH9c
WSL2とかじゃなくて時代はDockerなんですよ！
2020/07/19(日) 12:17:50.75ID:4P1FEtjj
>>431
違う。別物。
2020/07/19(日) 12:22:25.01ID:kmbJyWa5
コンテナにせよエミュレーションにせよ仮想化テクノロジが最重要であることは言うまでもない
ということは開発機は仮想化に強いMacかLinuxということになる
Linuxはデバイスサポート保障があるマシンのラインナップが魅力的とは言い難い
なので開発者はMacを買うべきという正解が導かれる
2020/07/19(日) 12:23:49.61ID:rDt79pjx
>>133
またObsidian.mdやRoamResearchに触発されたのが出てきた
https://github.com/svsool/vscode-memo
2020/07/19(日) 12:31:10.24ID:ZFRvNo6R
デファクトスタンダードが決まったらまた連絡してくれ
2020/07/19(日) 12:44:55.36ID:n0f5aqSv
>>433
具体的には？
2020/07/19(日) 12:59:28.71ID:W3hSYpRn
>>436
> ということは開発機は仮想化に強いMacかLinuxということになる
Macが仮想化に強いって何のこと？
MacはLinuxじゃないからDockerはそのまま動かないのに
2020/07/19(日) 13:02:09.25ID:W3hSYpRn
>>435
別物じゃないよ
2020/07/19(日) 13:02:29.46ID:8D9pzTQx
>>440
結論ありきで途中の過程がやる気無さすぎなんだろう
2020/07/19(日) 13:06:54.86ID:W3hSYpRn
Dockerの重要な点として手元で作ったDockerイメージを
そのまま本番環境でつかえるというのがある

しかしMacのCPUがARMになるからこれが難しくなった
本場環境の多くはIntelなのでCPUが違う

そうなると実機はIntel版LinuxのDockerイメージを使って
手元ではARM版LinuxのDockerイメージを使うか
パフォーマンスの低下を諦めて手元でIntel版LinuxのDockerイメージを
エミュレータを使って動かすしかなくなる

Macは開発に向かなくなってきている
2020/07/19(日) 13:09:27.60ID:4tyOlEBs
>>440
Macが強いというよりWindowsが弱いので相対的に良いってだけ
2020/07/19(日) 13:10:01.14ID:W3hSYpRn
Macの仮想化機能は限定的で、
Hypervisorフレームワークは用意しているが
それを使うためのインターフェースも持っていない
つまりサードパーティのソフトに頼らざるを得ないわけだ

HyperVとそれを扱うHyperVマネージャーを
OS標準で用意しているWindowsとは対照的
2020/07/19(日) 13:11:14.96ID:7Q5fXF4C
>>443
現時点で軽量VM使ってるから大きな変化はないのでは？
2020/07/19(日) 13:12:31.66ID:W3hSYpRn
>>444
Windowsの仮想化機能はMacを超えてるぞ
仮想マシン機能は当然備えているし
Macにはない仮想マシン管理アプリも付属

さらにWindows独自のコンテナ機能もある
Windows ServerコンテナというLinuxコンテナに近い機能と
Hyper-Vコンテナの二種類が用意されてる。
そしてDockerもWindowsコンテナに対応している
2020/07/19(日) 13:13:17.94ID:Vqf8sefQ
>>445
そのHyperVの完成度がお粗末
2020/07/19(日) 13:14:06.16ID:W3hSYpRn
>>446
軽量VMが何の関係があるのか知らんが、
MacのCPUがARMに変わったら
Linuxと同じDockerイメージが使えなくなるか
CPUエミュレーションで遅くなるという話をしてる

同じCPU上での仮想マシンとは違って
CPUが異なると大きなパフォーマンス低下が発生する。
2020/07/19(日) 13:14:28.08ID:W3hSYpRn
>>448
> HyperVの完成度がお粗末
どこがおそまつなの？
それを言えないんじゃ説得力ゼロなんですよ。
2020/07/19(日) 13:15:13.17ID:W3hSYpRn
HyperVの完成度の高さはDockerが実用的に動いていることからも明らか
WSL2だけではなくWSL1もHyperVを使っている
2020/07/19(日) 13:21:12.09ID:Vqf8sefQ
>>447
標準の管理ｱﾌﾟﾘは別に要らないと思う
実用性を考えるとDockerやVagrantのようなｻーﾄﾞﾊﾟーﾃｨﾂーﾙと合わせて使うから

Windowsｺﾝﾃﾅは使ったことないからわからないけどLinuxｺﾝﾃﾅと比べると需要少なそう

ﾊﾞｯｸｴﾝﾄﾞがなにか気にせずｺﾝﾃﾅを管理できるから便利なのであって
ﾊﾞｯｸｴﾝﾄﾞの種類が豊富でもあまり嬉しくないような？
2種類あるとなにが便利なの？

あなたが列挙した機能はもっともらしいﾒﾘｯﾄには思えないな
それよりもVirtualBoxとの共存で不具合が出やすいなどのﾃﾞﾒﾘｯﾄのほうがより目立つ
2020/07/19(日) 13:22:18.06ID:W3hSYpRn
> 標準の管理ｱﾌﾟﾘは別に要らないと思う
いるだろ。Macはユーザーインターフェースが不便なOSだって言いたいのか？
2020/07/19(日) 13:22:42.26ID:W3hSYpRn
VirtualBoxはいらんよ
なんで複数の仮想マシンが必要なんだｗ
2020/07/19(日) 13:23:12.78ID:W3hSYpRn
> ﾊﾞｯｸｴﾝﾄﾞの種類が豊富でもあまり嬉しくないような？
> 2種類あるとなにが便利なの？
だからVirtualBoxはいらんよねｗ
2020/07/19(日) 13:24:33.64ID:W3hSYpRn
>>452
俺が話をしているのはWindowsの方が仮想化機能が充実しているという話
MacはHypervisorフレームワークしかない
2020/07/19(日) 13:24:38.44ID:m5eV0pvm
スレタイ関係なくなっちゃったじゃん
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況