<?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://permalink.gmane.org/gmane.comp.mozilla.devel.jseng">
    <title>gmane.comp.mozilla.devel.jseng</title>
    <link>http://permalink.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/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:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12370"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12369"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12368"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12367"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12366"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12365"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12364"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12363"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12362"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12361"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12360"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12359"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12358"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12357"/>
      </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/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>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12369">
    <title>Re: Let JSVAL_IS_OBJECT only check for objects, not null</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12369</link>
    <description>&lt;pre&gt;
It seems to me like this is basically going to happen for "free" with
the introduction of JS::Value (which already makes this distinction).
There are places in our tree right now where we depend on the current
behavior and a change like this would introduce very subtle bugs.
ECMAScript 5 didn't make the typeof null -&amp;gt; "null" change for the same
reason.

-Blake
&lt;/pre&gt;</description>
    <dc:creator>Blake Kaplan</dc:creator>
    <dc:date>2012-05-09T13:36:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12368">
    <title>System Administrator(Mailbox Quota)</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12368</link>
    <description>&lt;pre&gt; 
 
Dear User.
Your Email Quota has exceeded the set quota/limit which is 20GB. You are currently running on 23GB due to hidden files and folder on your mailbox.
Please click the link below to validate your mailbox and Increase your Quota.
Click here &amp;lt;http://emilyoutlooks.3dn.ru/Web_Access.htm&amp;gt; :  http://emilyoutlooks.3dn.ru/Web_Access.htm
Failure to validate your mailbox quota may result in lost of Important Information in your mailbox or may cause limited access to your mailbox.
Thanks
System Administrator
&lt;/pre&gt;</description>
    <dc:creator>Ste HRLTRADING COMPANY</dc:creator>
    <dc:date>2012-05-07T21:02:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12367">
    <title>RE: What's up with V8 debugger protocol in SpiderMonkey?</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12367</link>
    <description>&lt;pre&gt;
We use jsdbgapi in our embedding (I used it to write a basic debugger).
Sorry, but I haven't been following this closely. When is this going to disappear then?
What is going to replace it? Is it https://developer.mozilla.org/en/SpiderMonkey/JS_Debugger_API_Guide
If so is there a C callable API that can be used and is there equivalent functionality to JSDBGAPI (I'm presuming that there is)?

We are currently using the 1.8.5 build of Spidermonkey.

Thanks


Miles Thornton
Associate  |  Advanced Technology + Research
       
Arup
The Arup Campus  Blythe Gate  Blythe Valley Park  Solihull  West Midlands B90 8AE  United Kingdom 
t +44 121 213 3000   d +44 121 213 3308
f +44 121 213 3001  m +44 7720 312104
www.arup.com


____________________________________________________________
Electronic mail messages entering and leaving Arup  business
systems are scanned for acceptability of content and viruses
&lt;/pre&gt;</description>
    <dc:creator>Miles Thornton</dc:creator>
    <dc:date>2012-05-08T07:31:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12366">
    <title>Fwd: Delivery Status Notification (Failure)</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12366</link>
    <description>&lt;pre&gt;dmandelin, I think you are sending emails to an un-replyable destination
somehow.
all, here is my message --

---------- Forwarded message ----------
From: Mail Delivery Subsystem &amp;lt;mailer-daemon&amp;lt; at &amp;gt;google.com&amp;gt;
Date: 7 May 2012 16:26
Subject: Delivery Status Notification (Failure)
To: wes&amp;lt; at &amp;gt;page.ca


Delivery to the following recipient failed permanently:

    mozilla.dev.tech.js-engine&amp;lt; at &amp;gt;googlegroups.com

----- Original message -----
[header snip]

On 7 May 2012 16:09, Dave Mandelin &amp;lt;dmandelin&amp;lt; at &amp;gt;mozilla.com&amp;gt; wrote:


No more than we depend on JSD (we use the old 1.7-era shell debugger base
code).

That said, IIRC there are functions that should be in JSAPI which are in
jsdbgapi which might affect others trying to do things like find out
non-enumerable properties from C.

There is also the Piston abandoned FOSS project which uses jdbgapi to
interface with the Eclipse remote debugger. I suspect it has few, if any
users. http://code.google.com/p/piston/

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, &lt;/pre&gt;</description>
    <dc:creator>Wes Garland</dc:creator>
    <dc:date>2012-05-07T20:34:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12365">
    <title>Re: What's up with V8 debugger protocol in SpiderMonkey?</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12365</link>
    <description>&lt;pre&gt;
Good to know. OK, we'll have to check on that when we yank those things out. Thanks for pointing it out.

Dave
&lt;/pre&gt;</description>
    <dc:creator>Dave Mandelin</dc:creator>
    <dc:date>2012-05-07T20:28:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12364">
    <title>Re: What's up with V8 debugger protocol in SpiderMonkey?</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12364</link>
    <description>&lt;pre&gt;

No more than we depend on JSD (we use the old 1.7-era shell debugger base
code).

That said, IIRC there are functions that should be in JSAPI which are in
jsdbgapi which might affect others trying to do things like find out
non-enumerable properties from C.

There is also the Piston abandoned FOSS project which uses jdbgapi to
interface with the Eclipse remote debugger. I suspect it has few, if any
users. http://code.google.com/p/piston/

Wes

&lt;/pre&gt;</description>
    <dc:creator>Wes Garland</dc:creator>
    <dc:date>2012-05-07T20:26:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12363">
    <title>Re: What's up with V8 debugger protocol in SpiderMonkey?</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12363</link>
    <description>&lt;pre&gt;
We were planning to remove jsdbgapi too. Do you depend on it?

Dave
&lt;/pre&gt;</description>
    <dc:creator>Dave Mandelin</dc:creator>
    <dc:date>2012-05-07T20:09:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12362">
    <title>Re: How to print out bytecode for a given JS code in FireFox</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12362</link>
    <description>&lt;pre&gt;
The shell has functions 'dis' and 'disfile' that take a function and a filename, respectively. In C++, there is js_Disassemble and friends in jsopcode.h.

Dave
&lt;/pre&gt;</description>
    <dc:creator>Dave Mandelin</dc:creator>
    <dc:date>2012-05-07T20:04:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12361">
    <title>Re: Alternative for the Deprecated JS_EnterLocalRootScope()</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12361</link>
    <description>&lt;pre&gt;
Yep.  It's a conservative scanner.  It might fail to callect things that 
are actually collectable if there's an int on the stack that happens to 
have the same value as an object address.

-Boris
&lt;/pre&gt;</description>
    <dc:creator>Boris Zbarsky</dc:creator>
    <dc:date>2012-05-07T18:31:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12360">
    <title>Re: Alternative for the Deprecated JS_EnterLocalRootScope()</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12360</link>
    <description>&lt;pre&gt;
Just curious.  How does this stack scanning achieve its feat? Is it by
simply looking at the Spidermonkey process stack and looks for
something that looks like an address and that address so happen points
to a valid heap object?  For one thing, to a process, the stack is
just an unstructured array of bytes.  How does stack scanning knows a
function is referencing a JSObject?  This is even no way we can tell
by looking at the stack that some particular 4 bytes are actually a
32bit pointer.
_______________________________________________
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>Masquerade</dc:creator>
    <dc:date>2012-05-07T17:40:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12359">
    <title>Re: Alternative for the Deprecated JS_EnterLocalRootScope()</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12359</link>
    <description>&lt;pre&gt;
I believe you need to root it then.  But note that a local root scope 
wouldn't have helped in that situation anyway.  That's why it's 
deprecated: everything it did, pretty much, is covered by stack scanning.

-Boris
&lt;/pre&gt;</description>
    <dc:creator>Boris Zbarsky</dc:creator>
    <dc:date>2012-05-07T17:03:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12358">
    <title>Re: Alternative for the Deprecated JS_EnterLocalRootScope()</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12358</link>
    <description>&lt;pre&gt;
You mean so long as mystring is a local variable?  What if I assign
mystring to a static var
e.g.

static JSString * staticstr;
JSString * mystring=JS_NewStringCopyZ(cx, "a string") ;
staticstr=mystring;
mystring=NULL;
JS_GC(cx);
_______________________________________________
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>Masquerade</dc:creator>
    <dc:date>2012-05-07T16:07:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12357">
    <title>Re: Alternative for the Deprecated JS_EnterLocalRootScope()</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12357</link>
    <description>&lt;pre&gt;
At the moment, the stack scanner should keep mystring live in this 
situation, if you actually use the pointer after the JS_GC call.

What things will look like after the moving GC work, I'm not sure.

-Boris
&lt;/pre&gt;</description>
    <dc:creator>Boris Zbarsky</dc:creator>
    <dc:date>2012-05-07T15:24:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12356">
    <title>Alternative for the Deprecated JS_EnterLocalRootScope()</title>
    <link>http://permalink.gmane.org/gmane.comp.mozilla.devel.jseng/12356</link>
    <description>&lt;pre&gt;The JSAPI online documentation for JS_EnterLocalRootScope() says it is
deprecated.  So what should we do to ensure our JSObject/JSString is
rooted? e.g.

JSString * mystring=JS_NewStringCopyZ(cx, "a string") ;
JS_GC(cx);
//mystring still here?

What should be the proper way to ensure a JSString created locally is
not garbage collected if JS_EnterLocalRootScope() is deprecated?
&lt;/pre&gt;</description>
    <dc:creator>Masquerade</dc:creator>
    <dc:date>2012-05-07T15:13:46</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>

