<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.mozilla.devel.jseng">
    <title>gmane.comp.mozilla.devel.jseng</title>
    <link>http://blog.gmane.org/gmane.comp.mozilla.devel.jseng</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12390"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12389"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12388"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12387"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12386"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12385"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12384"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12383"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12382"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12381"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12380"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12379"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12378"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12377"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12376"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12375"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12374"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12373"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12372"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12371"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12390">
    <title>Re: What's up with V8 debugger protocol in SpiderMonkey?</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12390</link>
    <description>&lt;pre&gt;
Would your embedding be able to use the new API? It's much nicer and more robust than jsd.

Dave
&lt;/pre&gt;</description>
    <dc:creator>Dave Mandelin</dc:creator>
    <dc:date>2012-05-24T19:38:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12389">
    <title>Re: What's up with V8 debugger protocol in SpiderMonkey?</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12389</link>
    <description>&lt;pre&gt;We also use jsd and jsdbgapi in our embedding. We have a fairly complete GUI 
that we use for debugging all of the time. We really need all of the 
features in jsd and jsdbgapi to be available via C. 
&lt;/pre&gt;</description>
    <dc:creator>Robin Ehrlich</dc:creator>
    <dc:date>2012-05-24T18:54:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12388">
    <title>Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12388</link>
    <description>&lt;pre&gt;
You should be able to get the constructor off the prototype object (just make sure to do it before the prototype's exposed to anything that might remove that property):

Value v;
JS_GetProperty(cx, prototype, "constructor", &amp;amp;v);
Value args[2] = { Int32Value(17), NullValue() };
JS_New(cx, &amp;amp;v.toObject(), 2, args);

Also, as long as you don't have JSCLASS_IS_ANONYMOUS set, you should be able to get the constructor off the global object, because JS_InitClass(cx, global, ....) will put the constructor function in global[class-&amp;gt;name].  Modulo the caveat, both ways should be identical if you're acting early enough.

Jeff
&lt;/pre&gt;</description>
    <dc:creator>Jeff Walden</dc:creator>
    <dc:date>2012-05-24T17:12:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12387">
    <title>Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12387</link>
    <description>&lt;pre&gt;
We also use them to instantiate native classes in our application, which 
is completely unrelated to Mozilla.

Note that we don't have a 'constructor function object'; just a class 
definition and a prototype object, which is the result of a call to 
JS_InitClass():

JSObject* global = ...; // our Global object
JSClass* class = { ... };
JSObject* prototype = JS_InitClass( cx, global, 0, class, ctor, ... );
// ...
JSObject* myObj = JS_ConstructObject( cx, class, prototype, 0 );

If there is a way to use JS_New() to achieve exactly the same as the 
code above does, then please show it to us, and you can get rid of 
JS_ConstructObject*. Otherwise removing these API functions might cause 
us a lot of trouble.

Juan Conejero
PixInsight Development Team
http://www.pixinsight.com/
&lt;/pre&gt;</description>
    <dc:creator>Juan Conejero</dc:creator>
    <dc:date>2012-05-24T16:47:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12386">
    <title>System Administrator</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12386</link>
    <description>&lt;pre&gt;You have reached the storage limit on your mailbox. To Up-Dated Please
Click the below link to fill your email upgrade form.


CLICK HERE:


Thanks


System Administrator
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine&amp;lt; at &amp;gt;lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine
&lt;/pre&gt;</description>
    <dc:creator>Matthew Solfisburg</dc:creator>
    <dc:date>2012-05-23T11:15:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12385">
    <title>Re: Also, removing JSRESOLVE_CLASSNAME</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12385</link>
    <description>&lt;pre&gt;Code: http://code.google.com/p/gpsee/source/browse/gpsee_modules.c#193

Our architecture is such that we have CommonJS 1.x modules, with each
module having it's own global object, as a sort of "module scope".

We then use a resolver on these module scope objects to allow module code
to resolve references to the real global object -- the one that the program
module runs, and owns Math, Array, etc.

JSRESOLVE_DECLARING helps us to decide *not* to proxy through the to "true"
global when the programmer uses 'var' to declare a variable which is scoped
to the module.

This strange set of circumstances arose because the JIT was penalizing us
for using a scope object which was not a global object in
JS_ExecuteScript().  Other scenarios have been considered to achieve the
same goal, but they all require re-writing the JS before executing it.

Wes

&lt;/pre&gt;</description>
    <dc:creator>Wes Garland</dc:creator>
    <dc:date>2012-05-23T11:11:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12384">
    <title>Re: Also, removing JSRESOLVE_CLASSNAME</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12384</link>
    <description>&lt;pre&gt;
In the long run I'd like to remove all resolve flags -- there's no such concept in the spec, and they create headaches every time anyone has to think about them.  But that's a ways out, definitely.

Removing JSRESOLVE_ASSIGNING is probably impractical right now (there are 50-odd hits in Gecko for it), so I don't think you need to worry about that right now.

But JSRESOLVE_DECLARING looks potentially removable, from the Gecko end.  (I'm tryservering a patch now to get better data.)  Now that variable declarations, function statements, and consts all *define* the property they declare, rather than simply set it (I believe this changed with bug 632003 and bug 577325), I don't think this flag serves any purpose in SpiderMonkey or Gecko any more.  How are you using it?

Jeff
&lt;/pre&gt;</description>
    <dc:creator>Jeff Walden</dc:creator>
    <dc:date>2012-05-23T01:04:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12383">
    <title>Re: Also, removing JSRESOLVE_CLASSNAME</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12383</link>
    <description>&lt;pre&gt;Fine from my POV (gpsee) -- just don't pull JSRESOLVE_ASSIGNING or
JSRESOLVE_DECLARING! :)

Wes

On 22 May 2012 17:47, Jeff Walden &amp;lt;jwalden+nmo&amp;lt; at &amp;gt;mit.edu&amp;gt; wrote:




&lt;/pre&gt;</description>
    <dc:creator>Wes Garland</dc:creator>
    <dc:date>2012-05-22T22:42:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12382">
    <title>Also, removing JSRESOLVE_CLASSNAME</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12382</link>
    <description>&lt;pre&gt;The JSRESOLVE_CLASSNAME flag (used when looking up properties) is barely used in Gecko or SpiderMonkey at all.  Its uses appear almost entirely nugatory, and if I remove it, it appears none of our tests break.  Is anyone using this?  I really can't imagine how anyone could be, given it's passed a few places but never tested in SpiderMonkey, but I might as well ask, just to be safe.

There is no corresponding thing in any ECMAScript spec to JSRESOLVE_CLASSNAME, so I believe the case is strong for removing this quirk that is directly at odds with the spec algorithms.

Jeff
&lt;/pre&gt;</description>
    <dc:creator>Jeff Walden</dc:creator>
    <dc:date>2012-05-22T21:47:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12381">
    <title>Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12381</link>
    <description>&lt;pre&gt;
This must have been before JS_New, right?  JS_New (passing MyClass for the constructor) is the right way to do |new MyClass(...)| in modern JSAPI, of the sort that'll be in whatever SpiderMonkey release contains the current trunk code.  Does JS_New not work for your purposes in any way?

Jeff
&lt;/pre&gt;</description>
    <dc:creator>Jeff Walden</dc:creator>
    <dc:date>2012-05-22T21:41:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12380">
    <title>Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12380</link>
    <description>&lt;pre&gt;

I don't think he was forgetting. That's why he asked on the list rather
than just ripping it out.

bholley
&lt;/pre&gt;</description>
    <dc:creator>Bobby Holley</dc:creator>
    <dc:date>2012-05-22T19:22:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12379">
    <title>Re: Removing JS_ConstructObject, JS_ConstructObjectWithArguments</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12379</link>
    <description>&lt;pre&gt;
You're forgetting the SpiderMonkey is used in a number of projects completely 
unrelated to Mozilla. We use it in Whitebeam for example to implement 
server-side JavaScript.

And yes - we use JS_ConstructObject to create instances of our native classes.

There may be a better way to do this but certainly at the time we first started 
using SpiderMonkey there was no other way that I could find (other than 
effectively running a wasteful eval on 'new MyClass') to correctly instantiate 
an object.

Best Regards
Peter Wilson
--
Architect, Whitebeam Web Application server
http://www.whitebeam.org
--
&lt;/pre&gt;</description>
    <dc:creator>Peter Wilson</dc:creator>
    <dc:date>2012-05-22T19:10:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12378">
    <title>Removing JS_ConstructObject, JS_ConstructObjectWithArguments</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12378</link>
    <description>&lt;pre&gt;I was looking at various bits of SpiderMonkey code recently and noticed that JS_ConstructObject* is unused outside SpiderMonkey in Gecko.  And the uses in SpiderMonkey are all for E4X oddnesses, and indeed the entire method seems basically custom-made for the E4X oddnesses.  Would anyone mind overmuch if I removed them?  Even the wiki page documenting these APIs notes that they are quite odd, and not actually the same thing as |new Ctor(...)|:

https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference/JS_ConstructObject

If anyone's actually using these, I'm sure there's a better way to address whatever issue might be occurring.

Jeff
&lt;/pre&gt;</description>
    <dc:creator>Jeff Walden</dc:creator>
    <dc:date>2012-05-22T18:40:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12377">
    <title>Fail to Complie js185 - Solaris 10 - ./v8-dtoa/platform.h:70:5:error: expected unqualified-id before '__extension__'</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12377</link>
    <description>&lt;pre&gt;Hi,
I'm new here on the list, and I signed up to help to compile the version
js185 on Solaris.
The following procedure that I performed ...

&lt;/pre&gt;</description>
    <dc:creator>Fabrício Dias</dc:creator>
    <dc:date>2012-05-19T18:56:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12376">
    <title>Lifetime of objects created in JS_EvaluateScript</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12376</link>
    <description>&lt;pre&gt;Hi,
can somebody clarify to me how it works in Firefox, if I have a
javascript code, that I launch using JS_EvaluateScript, and in that
script I create an object (like WebSocket in Firefox for example ),
and install functions on it, which supposed to be launched when
something happens on native part. JS_EvaluateScript is finished when I
create and setup this object if I understand correct. Will that object
still exist after that and will I be able to execute these js
functions? If I root that object in native code during it's creation
for example, will it exist after JS_EvaluateScript returns, and will
it still contain these callbacks I set(via assigning functions to
properties)?

Thanks.
&lt;/pre&gt;</description>
    <dc:creator>Artjom Brehhunov</dc:creator>
    <dc:date>2012-05-17T13:57:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12375">
    <title>System Administrator</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12375</link>
    <description>&lt;pre&gt;You have reached the storage limit on your mailbox.You will not be able to send or receive new mail until you updrade your email account.

Click the below link to fill your email upgrade form.

CLICK HERE: &amp;lt;https://docs.google.com/spreadsheet/viewform?formkey=dG5aYkF2R0lScVNUeEZTZFlqeGVYQXc6MQ&amp;gt; 

Thanks
System Administrator
&lt;/pre&gt;</description>
    <dc:creator>Andre Grobbelaar</dc:creator>
    <dc:date>2012-05-14T18:39:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12374">
    <title>16Bit Unicode Name for JSClass.name</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12374</link>
    <description>&lt;pre&gt;How do we specify 16bit unicode names for the JSClass.name field?
Currently it is char* type only.  I tried a quick scan over the source
code and note that most of the time the |name| field is interpreted as
a UTF8 string and is atomized into 16bit JSString automatically.
However, I also discover that the functions in jsxdrapi.cpp uses the |
name| field directly without trying to interpret it as a UTF8 string?
Does that mean it is still safe to simply insert UTF8 encoded string
value in the JSClass.name if I intend to use the jsxdrapi ?
&lt;/pre&gt;</description>
    <dc:creator>Masquerade</dc:creator>
    <dc:date>2012-05-12T11:17:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12373">
    <title>System Administrator</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12373</link>
    <description>&lt;pre&gt;You have reached the storage limit on your mailbox.You will not be able to send or receive new mail until you updrade your email account.

Click the below link to fill your email upgrade form.

CLICK HERE:&amp;lt;https://docs.google.com/spreadsheet/viewform?formkey=dG5aYkF2R0lScVNUeEZTZFlqeGVYQXc6MQ&amp;gt;

Thanks
System Administrator
&lt;/pre&gt;</description>
    <dc:creator>JODHKA, PARMEET</dc:creator>
    <dc:date>2012-05-14T11:37:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12372">
    <title>Re: Remove JSOPTION_STRICT (a.k.a. javascript.options.strict)</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12372</link>
    <description>&lt;pre&gt;
Hmm.  It sure does complicate Spidermonkey :/

N
&lt;/pre&gt;</description>
    <dc:creator>Nicholas Nethercote</dc:creator>
    <dc:date>2012-05-11T04:55:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12371">
    <title>Re: jsapi, crashes(memory problems) on android when thread-safe is off</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12371</link>
    <description>&lt;pre&gt;my project is keep going with safethread option for android devices.
where should i submit bug about this problem, if is there.

&lt;/pre&gt;</description>
    <dc:creator>Hossein Amin</dc:creator>
    <dc:date>2012-05-10T13:42:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12370">
    <title>Re: Let JSVAL_IS_OBJECT only check for objects, not null</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12370</link>
    <description>&lt;pre&gt;Probably not for free, because this is serious work to port over. And
some code might only be compilable in C mode?
Not a big deal, I already fixed this stuff in our tree. I was more
interested in how this would affect other embedders.
&lt;/pre&gt;</description>
    <dc:creator>Tom Schuster</dc:creator>
    <dc:date>2012-05-09T18:10:15</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.mozilla.devel.jseng">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.mozilla.devel.jseng</link>
  </textinput>
</rdf:RDF>

