Thanks to bug 1642505, our integration of ICU and tzdata and related imported
code in the tree is now documented:
https://searchfox.org/mozilla-central/source/intl/icu/README.md
If you ever wondered how our imported ICU is integrated into SpiderMonkey and
Gecko builds, this documentation should
On 09/05/2018 02:29 AM, Benjamin Bouvier wrote:
> I don't buy Jeff's argument at all; in the case of the (in)famous Apple SSL
> bug, there *was* proper indentation and missing braces on the if, and
> though this wasn't enough to catch the failure.
*Having* the rule is not the same as *enforcing* i
On 09/04/2018 10:59 AM, David Teller wrote:
> Point taken. Not going to fight over this :)
:-) ^ 2
Jeff
___
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-in
On 09/04/2018 07:50 AM, David Teller wrote:
> I am all for making braces a requirement, both to unify with Gecko and
> for safety reasons – it would be really annoying to introduce bugs, as
> Apple did not that long ago, just because of missing braces.
I say this all with a bit of a smile (in case
It's a long-term SpiderMonkey goal to break up jsapi.h into separate, small
headers. jsapi.h is *maybe* convenient in that it's one #include, but that
also means compiling SpiderMonkey is super-slow when that file is touched
(which is often).
I just took a notable step in that direction, that
On 04/08/2017 02:04 AM, Shu-yu Guo wrote:
> 7am is... hard. I'll try.
Whoops, I misread the time in the original email when I first saw this -- I
thought it said 10:00 Pacific. :-( I can't make 07:00, or at least I can't
make it til 30-40mins. in. Likely that doesn't change anything for anyon
On 04/29/2016 10:19 AM, Tom Schuster wrote:
> I want to inquire if we could maybe speed up the implemention of Bug
> 449811.
It's at the top of my list.
Although I caution that in our current architecture, I remain at a loss for how
to do the "clone the left-hand side of a for-in/of loop" behavi
On 04/20/2016 06:41 AM, Ehsan Akhgari wrote:
> About Unbox specifically, what are the methods that you're suggesting to
> use? For example thinking about BooleanObject, I can't find any other
> public API that allows me to extract the boolean primitive inside it...
Hypothetical future public APIs
On 04/19/2016 08:37 PM, Ehsan Akhgari wrote:
> As far as I understand, the js namespace is used internally in
> SpiderMonkey, and the JS namespace contains the public API symbols.
> However, I occasionally come across things in the public headers in
> namespace js that I need to use. Examples incl
Hi all,
Most bugfixes can be accompanied by automated tests. But sometimes, a test for
a fix isn't automatable. Maybe it needs gobs of memory, or it's
non-deterministic at the margins. Most such tests probably just don't land,
effectively memory-holing knowledge that could be useful in the f
On 06/12/2015 06:01 PM, Jason Orendorff wrote:
> Instead of advertising, wouldn't
> you be better off deleting the macro?
I have been, slowly.
> You can set the reason-string to either "laws of the ancients" or
> "(obviously)", take your pick, r=me.
I don't consider it acceptable to convert thes
SpiderMonkey has a JS_STATIC_ASSERT macro only because it's historically had
one. These days, C++11's static_assert keyword provides the same functionality
more clearly and more powerfully, and it includes an explanatory reason-string
that's displayed if the assertion fails.
If you're adding s
Fed up with self-hosted code that mistakenly (and non-obviously) threw an Error
instead of the specified RangeError, I just added two new self-hosting
intrinsics: ThrowRangeError and ThrowTypeError[0]. They're exactly identical
to the current ThrowError *except* that they assert if the provided
On 03/17/2015 11:37 AM, Boris Zbarsky wrote:
> It fails because the invalid function-in-block source gets desugared by
> SpiderMonkey like so (from your original mail) into valid JS:
>
> if (q) {
> var client1 = {on:function(){}};
> client1.on('close', onclose);
> var onclose = function onc
On 02/14/2015 08:43 PM, Boris Zbarsky wrote:
> On 2/14/15 11:06 PM, obastemur wrote:
>> On Friday, February 13, 2015 at 5:06:31 PM UTC+1, Boris Zbarsky wrote:
>>> Note that this does not do the same thing as obastemur's proposed API.
>>> Whether it does what he actually wants is an interesting ques
https://bugzilla.mozilla.org/show_bug.cgi?id=1019955
Something's broken in the self-hosting build stuff right now, it seems. So
please modify the top-level CLOBBER file in patches that add self-hosted
methods, or modify any of the ancillary files. Until we figure this out, this
is on reviewer
On 2/7/14 6:56 AM, Branislav Rankov wrote:
I am not able to assign this patch to myself. Can someone do it for me?
I see this has been done, but I just gave you editbugs/canconfirm bits
so you can make the normal range of changes to bugs that any regular
developer can make. :-)
Jeff
__
On 2/3/14 10:37 PM, Chris Peterson wrote:
Jeff, regarding proxies and JSClass, can you elaborate on "the idea of
classes is in the middle of deprecation in ECMAScript"?
In ES5 there's this thing called [[Class]] which in name is just a
string ("Array" for arrays, "Object" for plain old objects
On 2/4/14 7:02 AM, Boris Zbarsky wrote:
On 2/4/14 1:37 AM, Chris Peterson wrote:
Jeff, regarding proxies and JSClass
Note that we're currently sort of moving in the opposite direction: we
just gave proxies distinct JSClasses.
The goal is to unify the two concepts into one, called "proxy", wh
There's a bunch of tribal knowledge among JS hackers of where we want
the engine to go, but we just haven't quite yet taken it. Sometimes
that info's useful/relevant to design of present-day patches or
approaches. It would be useful to have that documented somewhere so
that people are more on
Python exposes docstrings because they're not really comments -- they're
first-class syntax in the language (overloaded syntax, but still part of the
language definition). Go also includes them as part of the language, assuming
I understand your description of its setup. Same for Rust, or at l
On 12/16/2013 07:51 PM, Chris Peterson wrote:
> These bugs were completed (resolved fixed) in Firefox 28:
>
> [DONE] 903332 - document.watch() Proxies
I would not mention/tout this. We don't want people using watch. Telling them
it "works" again in particular cases will only incent further usa
On 12/12/2013 01:09 PM, Jeff Walden wrote:
> Try working on anything that touches JSAPI or friend API. Or try working on
> the GC. Or even try the make-generator-frames-store-locals-in-the-heap work.
> Or try any of the wrappers stuff. Or really XPConnect writ larger. Or
> any
On 12/12/2013 12:45 PM, Kannan Vijayan wrote:
> Isn't part of the reason for that the fact that TraceMonkey (and with Jaeger,
> Ion, and with Baseline, etc.) wasn't really a JS-specific tree?
No, as sfink notes.
> I would expect far less overlap between "general browser work" and "JS work"
> th
On 12/12/2013 12:08 PM, Brian Hackett wrote:
> I think mozilla-inbound is a failed experiment.
I don't fully agree, but I see the point.
Personally, I just buffer up patches when I want to push and inbound's closed.
Out of sight, out of mind temporarily is an easy enough way to avoid
frustrati
On 11/18/2013 11:32 AM, Jason Orendorff wrote:
> Is that the bug you meant to link? It looks unrelated.
Oops, I meant this:
https://bugzilla.mozilla.org/show_bug.cgi?id=939367
> Autogenerating docs is rad. I'm fine with establishing a rule that
> patches affecting the API must update the docs in
Apparently the build system docs are now maintained in-tree, and they're
translated/mirrored automatically to a website. The system is build-specific
right now, but work is happening to make it whole-tree:
https://bugzilla.mozilla.org/show_bug.cgi?id=939505
I think it's substantially more like
On 10/14/2013 03:34 AM, Benjamin Peterson wrote:
> I wonder if JS shell builds should (at least optionally) link with
> mozalloc and jemalloc to better simulate browser conditions in our
> everyday correctness and performance testing.
Really, all of mozalloc/mozglue/etc. should move into mfbt, and
On 08/26/2013 10:30 AM, Steve Fink wrote:
> - JS::Handle is indeed ugly. But you can't compare to
> HandleValue; it'd still be JS::HandleValue. It sounds like people aren't
> crazy about 'using namespace JS' or 'using JS::Value', so it's probably
> "JS::Handle vs JS::HandleValue" or "Handle vs
> Ha
On 06/14/2013 02:55 PM, Nicholas Nethercote wrote:
> I propose that we do the following: take the full path within js/src,
> replace '/' and '.' with '_', and add two underscores to the end. For
> example:
>
> - jsapi.h: jsapi_h__
> - gc/Barrier.h: gc_Barrier_h__
> - vm/Stack.h: vm_Stack_h__
On 06/20/2013 11:36 AM, Bobby Holley wrote:> I think we could pretty easily
promote the typedefs, which will
> get used anyway because they're easier
I think that's debatable. The typedefs are (negligibly) easier to *type*. But
they are not easier to understand. Extra abstraction layers obfus
If you make changes to JSAPI, please note them in the draft 24 release notes,
just cloned from the 17 release notes:
https://developer.mozilla.org/en-US/docs/SpiderMonkey/24
It shouldn't be too hard to keep up with documentation, as long as we keep up
with them as we go. Please do so!
24 not
https://bugzilla.mozilla.org/show_bug.cgi?id=871857 recently got filed as a
fuzz bug discovered by the fuzzers, in which they stumbled across internal,
totally-unsafe (when misused) functionality and hilarity ensued. It occurs to
me that this isn't the first time that we've had fuzzers report
On 04/30/2013 02:12 PM, David Anderson wrote:
> Would it make sense to have the option of using system/external icu if
> available, similar to nspr? It doesn't make sense to rebuild icu all the
> time if it's not going to change.
Certainly. I expect, once we enable this in desktop Firefox, some L
With bug 866305 landed, the shell build by default now includes the Intl
object, and the existing toLocale*String methods all use Intl functionality to
work. Yay!
But this also means that building now requires building ICU as well. Not so
yay. That adds several minutes to compile time (for m
Everyone talks about how discussions on IRC are opaque unless you're there for
them, but nobody ever does anything about it. :-) Given Till and I just had a
spectacularly successful (in my super-humble opinion) discussion of
self-hosting ideas (some short-term fixing/slight hacks, some longer-
On 03/15/2013 09:17 AM, Andreas Gal wrote:
> We did some research work on this for JIT compilers way back at UCI as part
> of my thesis. This was 5 years ago and the architecture world was different,
> and this was focused on x86, but the rough result was that on x86 all that
> matters is schedu
On 12/18/2012 09:08 PM, Norbert Lindenberg wrote:
> When happens when the value of the |undefined| variable of one frame is
> passed to another frame? Does it compare === to the |undefined| variable of
> the other frame?
The value of the global |undefined| property is immutable, and it is the on
On 12/10/2012 10:02 PM, Norbert Lindenberg wrote:
> a) Should we follow established JavaScript conventions and allow only
> constructor and namespace names to start with a capital letter (i.e., Array
> and Intl)? Or should we follow the SpiderMonkey C/C++ conventions, which
> allow other functio
On 11/21/2012 12:08 PM, Dave Mandelin wrote:
> Fair enough. Just out of curiosity, if it didn't have the security benefits,
> would you think compartments are worthwhile?
Fixing the leak (the khueyfix to make zombie compartments much harder to
create) depends on compartments. That's actually ki
On 09/14/2012 04:05 AM, Till Schneidereit wrote:
> My question to the list is, then, what you all think I should work on
> with the highest priority.
>
> Also, I'm not sure that updating the embedding API even makes sense
> currently, what with the ongoing work on implementing a C++ API and
> all.
On 07/13/2012 12:18 PM, Brendan Eich wrote:
> Because many objects (most in popular workloads for which V8's nursery
> collection
> wins) are short-lived and by definition won't be moved, so they should not be
> taxed by an optional private-keyed identity property.
>
> Don't walk into known perfo
On 07/13/2012 11:28 AM, Brendan Eich wrote:
> Steve Fink wrote:
>> Another hole is when we use the pointer value to compute a hash code,
>> which we unfortunately do pretty often. For JSObjects, at least, it
>> would be really nice if we had an identity value to use instead.
>> dmandelin and I talk
As a further improvement to Luke's changes, noted here a couple days ago, I
just added the Value interface stuff to Rooted, EncapsulatedValue, and
MutableHandle.
As an added bonus, the additions only replicate the isInt32, isBoolean,
setObject, etc. methods once -- so they exist in Value, and i
44 matches
Mail list logo
