oh...
別板の 753 が…
>>949 テストってgrunt.js＋mochaとかでいいのか
テレッテッテッテ、テッテ、テレレレ～♪
∧,＿∧ ∧,＿∧
( ；`ω；´) ♪ (´･ｪ･｀)
/ ＼ ♪ ／ ヽ
レ'＼ γ∩ミ γ∩ミ. ／し´
> ⊂:: ::⊃⊂:: ::⊃〈 ﾍﾟﾁﾍﾟﾁ
. ／ 乂∪彡 乂∪彡 ＼ ﾍﾟﾁﾍﾟﾁ
(ﾟДﾟ)ﾆｬ～ (ﾟДﾟ)ﾆｬ～ (ﾟДﾟ)ﾆｬ～ (ﾟДﾟ)ﾆｬ～
955 ：
デフォルトの名無しさん：2013/09/12(木) 02:07:48.36
window.location.search以外でwindow間で値を渡すにはどうやれば良いですか？
jshintでチェックするとconsole.logをwindow.console.logみたいにトップのオブジェクトを省略できないんだけど
律儀に省略せずかくべきなの？
Windowsに今日npmからJShintを入れました
プロジェクト毎に共通化したいので.jshintrcで管理したいのですが
C:\Users\takahashiに.jshintrcを入れて
jshint test.jsってやってもjshintrcの内容が反映されません
やり方間違ってますか？
.jshintrcの内容は
{
"maxlen":1
}
です
ふと気づいたんだけど
今ってブラウザがどんどんサンドボックス化されてるじゃん？
で、GoogleがBlinkで実現したいことの１つにiframeの別プロセス化があるんだけど
今の仕様だと同オリジンだと勿論互いのwindow触れるし、
そうじゃなくてもpostMessageで発生するmessageイベントからは
別オリジンのwindowコンテキストも取得できることになってるから
相当難しくないかな？
それでもし、セマフォみたいな仕組み導入するんなら、
部分同期Workerが可能になると思うんだけどどう？
>>961 プラグインの別プロセス化とかUIプロセスとタブプロセスの分離とか、そういうの散々やってきてるのに、
スクリプトエンジンのプロセス間呼び出しとか、手間はかかっても今更致命的な障害になるワケがないと思うんだが。
Workerってメッセージングにコストかかるじゃん
それでも別「スレッド」同「プロセス」だから
メモリ共有できるからバッファの低コストな受け渡しとか出来る
プラグインとかは当然変数やメモリ共有してないでしょ
でもiframeは
>>961の仕様だからそれが必要
もしプロセス間通信で変数のセマフォを実現するとなると相当な負担になると思う
別プロセスでもメモリ共有はフツーにできるし、してる。
WindowsでもUnix系OSのFreeBSDやLinuxでもFreeBSDを改造して作られたMacOSでも出来る。
プラグインなFlashのExternalInterfaceみたいなのもある(さすがにコレはちと効率が不安だが)。
Chromeでは機能拡張も別プロセスで走ってるし…
>>964 できる出来ないの問題じゃなくて排他処理が高コストでしょ
拡張機能もページ内で動くのはページ内にスクリプト埋め込むことで動いてんのよ
＞別プロセスでもメモリ共有はフツーにできる
何のための別プロセス化か分からんなｗ
そこまでするのなら別プロセスにしなくていいでしょ。
だから結局
>>961はできない、現にやってない。
>>965 スレッド間でも排他は要るし、プロセス間用でスレッド間用の排他する事もよくあるくらいには微妙なコスト差なんだが。
拡張機能の方は実装しらんけど、一切プロセス間通信してないってことはないと思うって話な。
ページに埋め込んでるのは知ってるよ。
>>966 同時にマップ出来るメモリ空間の拡大とか、トラブル起こした場合にプロセスごと殺す手が取れるとか。
というかだな、「現にやってない」は「出来ない」を意味しないって事を言いたかったんだが。
アホはもう黙っとけって、、
共通に作業する領域を共有するのと、
windowオブジェクトツーカーは次元が違うんだよ。
ノータリンだな。
思い込みで不可能とか断定するほうがノータリンだろ…
>>961はどう見てもworkerのことを話題にしたかっただけで
プロセス間云々はどうでもいいというかスレチ…
frame 単位じゃなく domain 単位で別プロセスじゃないの？javascript の場合。
>>966 これどういう意味？
プロセス間通信でshmemって別に普通だよね？
>>973 セキュリティのために別々プロセスにするんだからshmemで密結合にしたら意味ないってことでしょ。
>>972 ドメインが違ってもwindow触れる手段があるからそれどうなるのってことでしょ
勉強得意なやつ同士の議論は深堀して戻ってこなくなる
Workerの別ドメインへのバッファ受け渡しって、現状どうなってるの？
自分でソース読んできた。
post時にSerializeしてから、送信してるみたい。ArrayBufferも。
一見すると、コストかけてでもセキュリティを気にしてるように見える。
斜め読みなので、間違ってたらすまん。
Worker-host間、またWorker-Worker間では
バッファ系オブジェクトのバッファ部分の所有権を「委譲」することが出来る。共有ではない。
つまりどういうことになるかというと、例えば100byteのArrayBufferを「委譲」したら、
プログラムからは元のは0byteになって、先に100byteの「新しい」ArrayBufferができるように見える。
内部的には参照の所有権を委譲してるだけだから低コスト。
これもWorker環境が同プロセスだからできること。
最初から共有メモリにバッファを置いておくなんてことは当然しないし。
使われ方でも、仕組み的にも「渡す」より「委せる」の方が適切と考えて「委譲」を推したい。
よし最初から全てのJavaScript用メモリは共有メモリに置こう！
マップしたまま放置すれば専有メモリとアクセスコストは大差ないし、
プロセス跨いだ所有権譲渡しない限りは管理コストも大差ない筈！
プロセス跨いだオブジェクトだけ別で管理すれば、その量が過剰でなければまぁ何とか！
ハンドル消費数とかバグの作り込みが怖いな。
ローカルで実行してるJavaScriptで自身のSCRIPT_NAMEを取得する方法ってありますか？
スマホ向けのJavaScriptってES5に対応してますか？
986 ：
デフォルトの名無しさん：2013/09/19(木) 00:00:16.13
してる
>>984 wsh なら WScript.ScriptName とか他は知らん
988 ：
デフォルトの名無しさん：2013/09/19(木) 00:38:11.07
url = [].pop.call(document.getElementsByTagName('script')).src
name = url.match(/.+\/(.+)\.js/)[1]
>>988 ありがとうございます
タグ使ってないので無理でしたがグリモンでなら動いたので別口で参考にします
>>987 JavaScript単体ではdefinedになるのでやはり無理そうですね
JScriptとJavaScriptは違うぞ
>>990 お前はJavaScriptって言うときはなにを指してるの？
JavaScriptとECMAScriptも違いますよね
JScriptつったらMSのECMAScript実装のことだろう
MSIEのJavaScript実装はJScriptだったよな？
JScript自体がJavaScriptの方言だとしても、
JavaScript実装として使われてる分にはJavaScriptでよくね？
>>984>>989 JavaScript(またはECMAScript)自体にはそんな機能ないから、
「ローカルで実行」するホスト環境が提供してる機能を使うべし。
ホスト環境が何なのか書かないとドンピシャな回答は得られないぞ。
ECMAScriptは仕様＋αの拡張は許してる
その代表的名称がJavaScript
JScriptはESのどのバージョンにも準拠してない
だからまるきり別物
バグとか例外的仕様とかでIEはクソって認識から認めたくない人は認めないんだろうけど、
そんなこと言い出すと大半のブラウザはSGMLやHTMLに準拠してない事になるからな。
ECMAScriptに限らずC/C++とかだってそういう所があるし、原理主義も大概にしとけ。
他のブラウザならバグだけど、
IEならES非準拠のJScriptの仕様となってしまうのが問題だね。
ES3ならIE8くらいからかな
最近のJScriptは準拠してると言っても悪くないんじゃないかな
1001 ：
１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。