How to use 'require' in XPCOM javascript components?
I was trying to use require('sdk/') to import
some javascript libraries in
XPCOM javascript components.
But I can not do that.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: http-schemed URLs and HTTP/2 over unauthenticated TLS
On 11/17/14 1:48 AM, Henri Sivonen wrote: As for cat and mouse, I'd prefer putting our cat-and-mouse energies into patching up https PKI instead of introducing a new cat-and-mouse situation to pay attention to. (Despite being able to walk and chew gum, our end isn't 100% immune to opportunity cost issues, either.) Given Mozilla's announcements around Let's Encrypt, are there still use cases for HTTP+OE? https://letsencrypt.org/2014/11/18/announcing-lets-encrypt.html chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How to use 'require' in XPCOM javascript components?
Yonggang Luo writes:
> I was trying to use require('sdk/') to import
> some javascript libraries in
> XPCOM javascript components.
> But I can not do that.
You need to import "require" first
const require = Cu.import("resource://gre/modules/devtools/Loader.jsm",
{}).devtools.require;
then you could require the modules you want.
Disclaimer: I don't know whether using sdk modules in XPCOM components
is allowed or not. Presumably you're writing addons then it's ok..
Kanru
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
PSA: JavaScript, const, and you
Just a heads up, a few of us have run into problems with extensions
breaking in nightly. The problem is probably not restricted to extensions.
The scoping rules for const in JavaScript have changed to conform w/ the
ES6 spec [1]. My understanding is that a const variable is now
restricted to the scope it was declared in.
Basically the following no longer works:
if (foo) {
const bar = ...;
}
bar.baz();
This broke lightbeam [2], mozmill 1.5 (I believe it's fixed in the 2.0
branch) which AWSY uses, and probably plenty of other things that have
been using const since, I'm not sure when it showed up, but at least the
past 4 years.
So if you're seeing failures since around 11/5 this could be it, you
just need to rework the scope of your const statements (and maybe not
use const unfortunately).
-e
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=611388
[2] https://github.com/mozilla/lightbeam/issues/622
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: http-schemed URLs and HTTP/2 over unauthenticated TLS
On Wed, Nov 19, 2014 at 1:20 PM, Chris Peterson wrote: > On 11/17/14 1:48 AM, Henri Sivonen wrote: > >> As for cat and mouse, I'd prefer putting our cat-and-mouse energies >> into patching up https PKI instead of introducing a new cat-and-mouse >> situation to pay attention to. (Despite being able to walk and chew >> gum, our end isn't 100% immune to opportunity cost issues, either.) >> > > Given Mozilla's announcements around Let's Encrypt, are there still use > cases for HTTP+OE? > > https://letsencrypt.org/2014/11/18/announcing-lets-encrypt.html > Given Richard Barnes is listed as the editor of Let's Encrypt's ACME spec ( https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.md) and has also been advocating HTTP+OE ... Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: http-schemed URLs and HTTP/2 over unauthenticated TLS
> On Wed, Nov 19, 2014 at 1:20 PM, Chris Peterson > wrote: >> Given Mozilla's announcements around Let's Encrypt, are there still use >> cases for HTTP+OE? >> >> https://letsencrypt.org/2014/11/18/announcing-lets-encrypt.html In particular: https://wiki.mozilla.org/Platform/2014-10-14#Necko_.28dougt.2Fjduell.29 says: "Opportunistic Encryption (OE) for HTTP/2 (i.e. if server opts-in we'll upgrade http to use TLS w/o certs) has landed (bug 1003448). Akamai will be our first main use case." Does Akamai's logo appearing on the Let's Encrypt announcements change Akamai's need for OE? (Seems *really* weird if not.) On Wed, Nov 19, 2014 at 3:46 AM, Robert O'Callahan wrote: > Given Richard Barnes is listed as the editor of Let's Encrypt's ACME spec ( > https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.md) > and has also been advocating HTTP+OE ... So what are the remaining use cases? HTTP+OE requires you to have TLS set up on the server. Let's Encrypt is about to take away the argument "boohoo certs are too expensive and hard to get". AFAICT, the arguments that remain are: 1) Home routers or NAS boxes don't have a DNS name, so they can't get a publicly trusted certs. 2) Making sure the right keys are on the right servers at the right time is too hard. 3) It's too hard to change old content with third-party includes not to get broken by the mixed content blocker. For case #1, you want https+TOFU--not http+OE. I think we should make the self-signed cert warning different (more situation-appropriate) for RFC 1918 addresses (192.168, etc.). Argument #2 seems silly: If you have enough servers for it to be a problem, you should have the staff/tools/knowhow to solve it. As for argument #3, getting the Web encrypted in an authenticated manner seems so important that it seems reasonable to tell admins of sites with legacy content that if they want to get HTTP/2 speed, they need to revise those old includes. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Web Speech API - Speech Recognition with Pocketsphinx
Chris, I was discussing with sphinx leaders and we can build models from audiobooks as well. This approach saves a lot of time and enhances the quality since the narrative is well accurate and clear. We are currently defining a way to create hindi and brazilian portuguese models. Thanks Andre On Oct 30, 2014 5:47 PM, "Chris Hofmann" wrote: > On 10/30/14 5:24 PM, smaug wrote: > >> On 10/31/2014 02:21 AM, smaug wrote: >> >>> Intent to ship is too strong for this. >>> We need to first have implementation landed and tested ;) >>> >>> I wouldn't ship the implementation in desktop FF without plenty of more >>> testing. >>> >>> >> But I guess the question is what people think about shipping the >> pocketspinx + API, even if disabled by default. >> >> Andre, we need some numbers here. How much does Pocketsphinx increase >> binary size? or download size? >> When the pref is enabled, how much does it use memory on desktop, what >> about on b2g? >> >> >> This is important work and the competition is ramping quicky after many > years of promises about this year being the year of voice recognition. We > will probably fall behind quickly if we don't get something going here in > the next year. > > Can you also talk a bit about what the plan and set of challenges look > like for expanding the supported languages, and how these would impact the > numbers ollie has asked for? > > The place we really need this is b2g, but phones are only shipping in > international markets right now so english only is not all that helpful. > > -chofmann > > >>> >>> -Olli >>> >>> >>> On 10/31/2014 01:18 AM, Andre Natal wrote: >>> I've been researching speech recognition in Firefox for two years. First SpeechRTC, then emscripten, and now Web Speech API with CMU pocketsphinx [1] embedded in Gecko C++ layer, project that I had the luck to develop for Google Summer of Code with the mentoring of Olli Pettay, Guilherme Gonçalves, Steven Lee, Randell Jesup plus others and with the management of Sandip Kamat. The implementation already works in B2G, Fennec and all FF desktop versions, and the first language supported will be english. The API and implementation are in conformity with W3C standard [2]. The preference to enable it is: media.webspeech.service.default = pocketsphinx The required patches for achieve this are: - Import pocketsphinx sources in Gecko. Bug 1051146 [3] - Embed english models. Bug 1065911 [4] - Change SpeechGrammarList to store grammars inside SpeechGrammar objects. Bug 1088336 [5] - Creation of a SpeechRecognitionService for Pocketsphinx. Bug 1051148 [6] Also, other important features that we don't have patches yet: - Relax VAD strategy to be les strict and avoid stop in the middle of speech when speaking low volume phonemes [7] - Integrate or develop a grapheme to phoneme algorithm to realtime generator when compiling grammars [8] - Inlcude and build models for other languages [9] - Continuous and wordspotting recognition [10] The wip repo is here [11] and this Air Mozilla video [12] plus this wiki has more detailed info [13]. At this comment you can see a cpu usage on flame while recognition is happening [14] I wish to hear your comments. Thanks, Andre Natal [1] http://cmusphinx.sourceforge.net/ [2] https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1051146 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1065911 [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1088336 [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1051148 [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1051604 [8] https://bugzilla.mozilla.org/show_bug.cgi?id=1051554 [9] https://bugzilla.mozilla.org/show_bug.cgi?id=1065904 and https://bugzilla.mozilla.org/show_bug.cgi?id=1051607 [10] https://bugzilla.mozilla.org/show_bug.cgi?id=967896 [11] https://github.com/andrenatal/gecko-dev [12] https://air.mozilla.org/mozilla-weekly-project-meeting-20141027/ (Jump to 12:00) [13] https://wiki.mozilla.org/SpeechRTC_-_Speech_enabling_the_open_web [14] https://bugzilla.mozilla.org/show_bug.cgi?id=1051148#c14 >>> >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
