<?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://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12391"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12386"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12382"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12378"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12377"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12376"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12375"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12374"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12373"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12368"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12356"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12352"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12345"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12343"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12342"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12341"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12337"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12336"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12335"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12328"/>
      </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://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12391">
    <title>Removing JSRESOLVE_WITH</title>
    <link>http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12391</link>
    <description>&lt;pre&gt;It turns out that JSRESOLVE_WITH, added to SpiderMonkey a few years ago because of a bizarre special-case in Gecko, is no longer needed by it.  (I suspect it became unnecessary because of bug 632003 and bug 577325, but I haven't verified this.)  It's rather hackish, and it would be truly wicked sweet to remove it.  Is anyone somehow using this?  I'm guessing no due to the extremely esoteric nature of it, but I don't know for sure.  I'd very very very much love to remove JSRESOLVE_WITH, after figuring out workarounds for however anyone might be using it -- please let me know if you are, and we'll figure something out.

Jeff
&lt;/pre&gt;</description>
    <dc:creator>Jeff Walden</dc:creator>
    <dc:date>2012-05-25T03:47:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12386">
    <title>System Administrator</title>
    <link>http://comments.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://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12382">
    <title>Also, removing JSRESOLVE_CLASSNAME</title>
    <link>http://comments.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://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12378">
    <title>Removing JS_ConstructObject, JS_ConstructObjectWithArguments</title>
    <link>http://comments.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://comments.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://comments.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://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12376">
    <title>Lifetime of objects created in JS_EvaluateScript</title>
    <link>http://comments.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://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12375">
    <title>System Administrator</title>
    <link>http://comments.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://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12374">
    <title>16Bit Unicode Name for JSClass.name</title>
    <link>http://comments.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://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12373">
    <title>System Administrator</title>
    <link>http://comments.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://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12368">
    <title>System Administrator(Mailbox Quota)</title>
    <link>http://comments.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://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12356">
    <title>Alternative for the Deprecated JS_EnterLocalRootScope()</title>
    <link>http://comments.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>
  <item rdf:about="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12352">
    <title>Let JSVAL_IS_OBJECT only check for objects, not null</title>
    <link>http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12352</link>
    <description>&lt;pre&gt;Hello!

I was looking into removing any use of JSVAL_IS_OBJECT from the
mozilla codebase. Turns out that this function would really win in
usefulness if it wouldn't return true for |null|. So I am proposing to
do that, let JSVAL_IS_OBJECT do what it says, return true _only_ for
JSObjects. Furthermore I propose that JSVAL_TO_OBJECT also only
returns objects and not null, thus probably getting rid of a lot of
null checks.

This way we could also get rid of the terrible !JSVAL_IS_PRIMITIVE
anti-pattern. We use these functions quite a few times and I would
think embedders do that too.

So my question is how useful feasible is this?

~Tom
&lt;/pre&gt;</description>
    <dc:creator>Tom Schuster</dc:creator>
    <dc:date>2012-05-05T17:50:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12345">
    <title>What's up with V8 debugger protocol in SpiderMonkey?</title>
    <link>http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12345</link>
    <description>&lt;pre&gt;Hi, everyone,

I'd like to develop SpiderMonkey remote debugger with V8 debugger protocol, not depending on Firefox.
I think it can be possible with the low-level JSDBGAPI and somehow higher-level JSD API (being in $firefox/js/jsd/*), but JSDBGAPI seems too low-level and JSD seems a part of Firefox. I need high-level API which doesn't depend on Firefox.

Is someone trying to do or interested in it?
Or, are there existing projects about it?

Best regards,
&lt;/pre&gt;</description>
    <dc:creator>Goro Fuji</dc:creator>
    <dc:date>2012-05-01T08:29:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12343">
    <title>Chanel bags, Chanel hats, Gucci hats,New Era hats for sale at http://www.mynewerahats.org/</title>
    <link>http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12343</link>
    <description>&lt;pre&gt;Discount smet 2011 caps www.mynewerahats.org
cheapsale NBA 2011 caps and hats www.mynewerahats.org
Supply AFF 2011 caps and hat www.mynewerahats.org
cheapsale winter warm 2011 caps www.mynewerahats.org
Discount ed hardy hats and 2011 capswww.mynewerahats.org
Discount juicy 2011 caps www.mynewerahats.org
Discount dc hats and 2011 caps www.mynewerahats.org
Discount ca 2011 caps www.mynewerahats.org
Cheap ny 2011 caps www.mynewerahats.org
Cheap polo 2011 caps and hats www.mynewerahats.org
Cheap bape 2011 caps www.mynewerahats.org
Supply Caddice 2011 caps www.mynewerahats.org
New Fasion Hats &amp;amp; 2011 caps
Gucci chanel www.mynewerahats.org
Chanel Hats www.mynewerahats.org
Chanel Drink Hats www.mynewerahats.org
White Chanel Hats www.mynewerahats.org
Chanel Fitted Hats www.mynewerahats.org
Youth Chanel Energy Hats
Chanel New Era Hats www.mynewerahats.org
Chanel Cap www.mynewerahats.org
Chanel Drink Cap www.mynewerahats.org
White Chanel Cap www.mynewerahats.org
Chanel Fitted Cap www.mynewerahats.org
Youth Chanel Cap
Chanel New Era Cap www.mynewerahats.org
Gucci New Era Hats www.mynewerahats.org
Gucci New Era New Era www.mynewerahats.org
Gucci New Era 2011 caps www.mynewerahats.org
Gucci New Era Fitted Hat www.mynewerahats.org
Gucci New Era New Era Hats www.mynewerahats.org
Gucci New Era Energy Hats www.mynewerahats.org
White Gucci New Era Hats www.mynewerahats.org
Black Gucci New Era Hats
Blue Gucci New Era Hats www.mynewerahats.org
Gucci New Era Hats Ebay www.mynewerahats.org
Buy Gucci New Era Hats www.mynewerahats.org
Team Gucci New Era Hats www.mynewerahats.org
Gucci New Era New Era Hats www.mynewerahats.org
Gucci New Era Baseball Hats www.mynewerahats.org
New Era 2011 caps
New Era Hats www.mynewerahats.org
New Era NY 2011 caps www.mynewerahats.org
New Era NY Hats www.mynewerahats.org Discount smet 2011 caps www.mynewerahats.org
cheapsale NBA 2011 caps and hats www.mynewerahats.org
Supply AFF 2011 caps and hat www.mynewerahats.org
cheapsale winter warm 2011 caps www.mynewerahats.org
Discount ed hardy hats and 2011 capswww.mynewerahats.org
Discount juicy 2011 caps www.mynewerahats.org
Discount dc hats and 2011 caps www.mynewerahats.org
Discount ca 2011 caps www.mynewerahats.org
Cheap ny 2011 caps www.mynewerahats.org
Cheap polo 2011 caps and hats www.mynewerahats.org
Cheap bape 2011 caps www.mynewerahats.org
Supply Caddice 2011 caps www.mynewerahats.org
New Fasion Hats &amp;amp; 2011 caps
Gucci chanel www.mynewerahats.org
Chanel Hats www.mynewerahats.org
Chanel Drink Hats www.mynewerahats.org
White Chanel Hats www.mynewerahats.org
Chanel Fitted Hats www.mynewerahats.org
Youth Chanel Energy Hats
Chanel New Era Hats www.mynewerahats.org
Chanel Cap www.mynewerahats.org
Chanel Drink Cap www.mynewerahats.org
White Chanel Cap www.mynewerahats.org
Chanel Fitted Cap www.mynewerahats.org
Youth Chanel Cap
Chanel New Era Cap www.mynewerahats.org
Gucci New Era Hats www.mynewerahats.org
Gucci New Era New Era www.mynewerahats.org
Gucci New Era 2011 caps www.mynewerahats.org
Gucci New Era Fitted Hat www.mynewerahats.org
Gucci New Era New Era Hats www.mynewerahats.org
Gucci New Era Energy Hats www.mynewerahats.org
White Gucci New Era Hats www.mynewerahats.org
Black Gucci New Era Hats
Blue Gucci New Era Hats www.mynewerahats.org
Gucci New Era Hats Ebay www.mynewerahats.org
Buy Gucci New Era Hats www.mynewerahats.org
Team Gucci New Era Hats www.mynewerahats.org
Gucci New Era New Era Hats www.mynewerahats.org
Gucci New Era Baseball Hats www.mynewerahats.org
New Era 2011 caps
New Era Hats www.mynewerahats.org
New Era NY 2011 caps www.mynewerahats.org
New Era NY Hats www.mynewerahats.org
&lt;/pre&gt;</description>
    <dc:creator>Andy</dc:creator>
    <dc:date>2012-04-24T10:37:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12342">
    <title>Chanel bags, Chanel hats, Gucci hats,New Era hats for sale at http://www.capscollection.org/</title>
    <link>http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12342</link>
    <description>&lt;pre&gt;Discount smet 2011 caps http://www.capscollection.org/
cheapsale NBA 2011 caps and hats http://www.capscollection.org/
Supply AFF 2011 caps and hat hhttp://www.capscollection.org/
cheapsale winter warm 2011 caps http://www.capscollection.org/
Discount ed hardy hats and 2011 caps http://www.capscollection.org/
Discount juicy 2011 caps http://www.capscollection.org/
Discount dc hats and 2011 caps http://www.capscollection.org/
Discount ca 2011 caps http://www.capscollection.org/
Cheap ny 2011 caps http://www.capscollection.org/
Cheap polo 2011 caps and hats http://www.capscollection.org/
Cheap bape 2011 caps http://www.capscollection.org/
Supply Caddice 2011 caps http://www.capscollection.org/
New Fasion Hats &amp;amp; 2011 caps
Monster Energy http://www.capscollection.org/
Chanel Hats http://www.capscollection.org/
Chanel Drink Hats http://www.capscollection.org/
Chanel Energy Hats http://www.capscollection.org/
Chanel Fitted Hats http://www.capscollection.org/
Youth Chanel Hats
Chanel New Era Hats http://www.capscollection.org/
Chanel Energy Cap http://www.capscollection.org/
Chanel Energy Drink Cap http://www.capscollection.org/
White Chanel Cap http://www.capscollection.org/
Chanel Fitted Cap http://www.capscollection.org/
Youth Monster Energy Cap
Monster Energy New Era Cap http://www.capscollection.org/
Gucci chanel http://www.capscollection.org/
Gucci chanel New Era http://www.capscollection.org/
Gucci chanel 2011 caps http://www.capscollection.org/
Gucci chanel Fitted Hat http://www.capscollection.org/
Gucci chanel New Era Hats http://www.capscollection.org/
Gucci chanel Energy Hats http://www.capscollection.org/
White Gucci chanel Hats http://www.capscollection.org/
Black Gucci chanel Hats
Blue Gucci chanel Hats http://www.capscollection.org/
Gucci chanel Hats Ebay http://www.capscollection.org/
Buy Gucci chanel Hats http://www.capscollection.org/
Team Gucci chanel Hats http://www.capscollection.org/
Gucci chanel New Era Hats http://www.capscollection.org/
Gucci chanel Baseball Hats http://www.capscollection.org/
New Era 2011 caps
New Era Hats http://www.capscollection.org/
New Era NY 2011 caps http://www.capscollection.org/
New Era NY Hats http://www.capscollection.org/

Discount smet 2011 caps http://www.capscollection.org/
cheapsale NBA 2011 caps and hats http://www.capscollection.org/
Supply AFF 2011 caps and hat hhttp://www.capscollection.org/
cheapsale winter warm 2011 caps http://www.capscollection.org/
Discount ed hardy hats and 2011 caps http://www.capscollection.org/
Discount juicy 2011 caps http://www.capscollection.org/
Discount dc hats and 2011 caps http://www.capscollection.org/
Discount ca 2011 caps http://www.capscollection.org/
Cheap ny 2011 caps http://www.capscollection.org/
Cheap polo 2011 caps and hats http://www.capscollection.org/
Cheap bape 2011 caps http://www.capscollection.org/
Supply Caddice 2011 caps http://www.capscollection.org/
New Fasion Hats &amp;amp; 2011 caps
Monster Energy http://www.capscollection.org/
Chanel Hats http://www.capscollection.org/
Chanel Drink Hats http://www.capscollection.org/
Chanel Energy Hats http://www.capscollection.org/
Chanel Fitted Hats http://www.capscollection.org/
Youth Chanel Hats
Chanel New Era Hats http://www.capscollection.org/
Chanel Energy Cap http://www.capscollection.org/
Chanel Energy Drink Cap http://www.capscollection.org/
White Chanel Cap http://www.capscollection.org/
Chanel Fitted Cap http://www.capscollection.org/
Youth Monster Energy Cap
Monster Energy New Era Cap http://www.capscollection.org/
Gucci chanel http://www.capscollection.org/
Gucci chanel New Era http://www.capscollection.org/
Gucci chanel 2011 caps http://www.capscollection.org/
Gucci chanel Fitted Hat http://www.capscollection.org/
Gucci chanel New Era Hats http://www.capscollection.org/
Gucci chanel Energy Hats http://www.capscollection.org/
White Gucci chanel Hats http://www.capscollection.org/
Black Gucci chanel Hats
Blue Gucci chanel Hats http://www.capscollection.org/
Gucci chanel Hats Ebay http://www.capscollection.org/
Buy Gucci chanel Hats http://www.capscollection.org/
Team Gucci chanel Hats http://www.capscollection.org/
Gucci chanel New Era Hats http://www.capscollection.org/
Gucci chanel Baseball Hats http://www.capscollection.org/
New Era 2011 caps
New Era Hats http://www.capscollection.org/
New Era NY 2011 caps http://www.capscollection.org/
New Era NY Hats http://www.capscollection.org/
&lt;/pre&gt;</description>
    <dc:creator>Andy</dc:creator>
    <dc:date>2012-04-24T10:36:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12341">
    <title>jsapi, crashes(memory problems) on android when thread-safe is off</title>
    <link>http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12341</link>
    <description>&lt;pre&gt;I used jsapi(spidermonkey) in my project, built on linux and i tested it
works fine.
When i tired to cross-compile it throw android, after building and
debugging small problems, i found an error in my javascript init
function, it failed with SIGSEGV signal error 11 which it crashes
without any log for failing.
Worked around to fix the problem probably when i increased size of init
runtime size, problem solved for little,not so long the program crashed
with same issue.
After all today i found the problem was i didn't thread-safe option in
compilation time, after another test i think problem is solved.
probably there is bug in none thread-safe.
I used both mozilla-centeral package and mozjs185-1.0.0 without
thread-safe, but mozjs185-1.0.0 also with thread safe.
android cpus tried to build are `armv7', `armv5te'.

Thanks!!
&lt;/pre&gt;</description>
    <dc:creator>Hossein Amin</dc:creator>
    <dc:date>2012-04-24T08:00:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12337">
    <title>shapes and insertion order</title>
    <link>http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12337</link>
    <description>&lt;pre&gt;IIUC, we give objects different shapes if they have the same properties but different insertion order. This has kind of bothered my subconscious for a while, and I think I understand why now: I suspect a lot of JS code actually isn't sensitive to insertion order. I wanted to ask here: would it be a) possible b) useful to represent insertion order as a separate piece of meta-data, to cut down on the number of shapes and stop distinguishing superficially different uses of a type?

Rough sketch of one possible approach: a Shape stores the n properties in alphabetical order, or better in order by JSAtom address, regardless of insertion order. Then you have a separate OrderMap data structure, that has n slots, each with an index into the Shape. Each instance of the object would have a pointer to a Shape and a pointer to an OrderMap.

Maybe it's just a non-starter to have an additional pointer slot in every object. Maybe you can aggressively memoize OrderMaps, since they aren't actually tied to a specific Shape. I.e., you could reuse OrderMaps between all Shapes of size n. And then maybe you could store OrderMap pointers in a smaller number of bits, if there's room to shove that in some free space somewhere else in the object representation.

I'm sure I'm too far from how engines work and this is probably less than half-baked. But it just seemed to me like the for-in enumeration order is not conceptually a part of the "class" of a JS object, and since it's so easy to have multiple code paths that accidentally insert properties in different orders, it seems too easy to accidentally have a collection of different shapes for objects that are actually all part of the same conceptual "class." I find this happens in my code all the time, where I have conditionals like:

    function C(...) {
        if (...) {
            this.foo = ...
            this.bar = ...
        } else {
            this.bar = ...
            this.foo = ...
        }
    }

Also, I could imagine this might tax enumeration, since it has to go through the OrderMap indirection. But if this made ordinary property accesses faster, maybe it'd be worth it? Again, I'm probably embarrassing myself showing off my ignorance. But that'd be nothing new. :-P

Dave
&lt;/pre&gt;</description>
    <dc:creator>David Herman</dc:creator>
    <dc:date>2012-04-21T21:07:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12336">
    <title>inheritance chain from C++ to javascript</title>
    <link>http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12336</link>
    <description>&lt;pre&gt;Hi,

I'm creating a javascript binding for cocos2d-x (https://github.com/
funkaster/cocos2d-x/tree/js-bindings/js). So far so good, but I just
found an issue when facing an inheritance chain.

Let's say I have this class inheritance in C++:

class A;
class B : A;
class C : B;
class D : C;

To create the bindings, what I'm doing is sub-classing every C++ with
a custom S_&amp;lt;klass&amp;gt; that inherits *only* from the real C++ class, and
then in javascript, I set the parent proto to reflect the actual C++
inheritance, more or less like this:

class S_A : A;
class S_B : B;
class S_C : C;
class S_D : D;

I do this because I need to override methods in order to catch
possible events coming from C++ and then redirect that to javascript
(and this was the easiest way to do it without modifying the original C
++ code). Also, the bindings/classes/etc are being (almost)
automatically generated from a script that parses the AST from a C++
header.

When registering the javascript classes, this is what I'm doing:

S_A::jsObject = JS_InitClass(cx, globalObj, NULL, S_A::jsClass,
S_A::jsConstructor, 0, properties, funcs, NULL, st_funcs);
S_B::jsObject = JS_InitClass(cx, globalObj, S_A::jsObject,
S_B::jsClass, S_B::jsConstructor, 0, properties, funcs, NULL,
st_funcs);
S_C::jsObject = JS_InitClass(cx, globalObj, S_B::jsObject,
S_C::jsClass, S_C::jsConstructor, 0, properties, funcs, NULL,
st_funcs);
S_D::jsObject = JS_InitClass(cx, globalObj, S_C::jsObject,
S_D::jsClass, S_D::jsConstructor, 0, properties, funcs, NULL,
st_funcs);

If you're wondering, the actual hierarchy for this would be:

A: CCNode
B: CCMenuItem
C: CCMenuItemSprite
D: CCMenuItemImage

The problem I have right now is that for classes that reach only until
level "B" this works perfectly: they can get and set properties
inherited by their parent's prototype with no problem (every class has
its own getter and setter), but for classes that extend this further,
apparently the search for prototypes stops after the first level...

Any ideas on how to properly implement/fix this?

Thanks!
Rolando
&lt;/pre&gt;</description>
    <dc:creator>rolando</dc:creator>
    <dc:date>2012-04-19T16:59:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12335">
    <title>Wiki Wednesday (SpiderMonkey) - April 19, 2012</title>
    <link>http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12335</link>
    <description>&lt;pre&gt;Here are today's Wiki Wednesday articles! If you know about these
topics, please try to find a few minutes to look over these articles
that are marked as needing technical intervention and see if you can
fix them up. You can do so either by logging into the wiki and editing
the articles directly, or by emailing your notes, sample code, or
feedback to mdnwiki&amp;lt; at &amp;gt;mozilla.org.

Contributors to Wiki Wednesday will get recognition in the next Wiki
Wednesday announcement. Thanks in advance for your help!

1) Debugger.Frame ( http://mzl.la/rujvHj )
2) SpiderMonkey compartments ( http://mzl.la/n2Irys )
3) JS_GetPropertyDefault ( http://mzl.la/n1bnNi )
&lt;/pre&gt;</description>
    <dc:creator>Sheppy</dc:creator>
    <dc:date>2012-04-19T12:10:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12328">
    <title>CVE-2012-0464</title>
    <link>http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12328</link>
    <description>&lt;pre&gt;Hello everybody,

I am currently working on my thesis, in which I try to evaluate the
security-implications of JIT-compilation (and ways to improve security
there).
I also made some slight modifications to the js-tracer (in particular,
I made nanojit mark its code-pages read/write instead of rwx). Now, I
would like to test my changes on a real bug. For this purpose, the
array.join("") problem revealed in the Pwn2Own contest looks
interesting.

However, information about it seems somewhat ...sparse. Could anybody
tell me some more about the causes of this particular problem and how
I might reproduce it?

The only real change I found in array_join itself seems to be a
replacement of js_ValueToString() with ToString(). The latter of
which, I believe, contains an additional check whether or not the
argument already is a string before further action (ToPrimitive and so
on) is taken. So... Is that the relevant change, or is there something
in array_toString_sub I missed, or was that bug fixed by a write-
barrier somewhere? Or is that information still strictly confidential?

Anyway, I would appreciate any hints and other input, if it possibly
can be given.
Best regards and thanks in advance,
Martin
&lt;/pre&gt;</description>
    <dc:creator>IHNames</dc:creator>
    <dc:date>2012-04-16T14:48:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12327">
    <title>System Administrator</title>
    <link>http://comments.gmane.org/gmane.comp.mozilla.devel.jseng/12327</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:
Thanks
System Administrator
Disclaimer

“This e-mail and any files transmitted with it may contain information
which is confidential, private or privilege in nature and it is for the
sole use of the recipient to whom it is addressed. If you are not the
intended recipient, you must immediately notify the sender via
electronic mail and further refrain from reading, disseminating,
distributing, copying or using this message or any of its transmitted
files. Any views of this message and its transmitted files are those of
the sender unless the sender specifically states such views to be those
of the North-West Provincial Government. Though this message and its
transmitted files have been swept for the presence of computer viruses,
the North-West Provincial Government accepts no liability whatsoever for
any loss, damage or expenses resulting directly or indirectly from the
use or access of this message or any of its transmitted files”
_______________________________________________
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>Tumelo Mokaila</dc:creator>
    <dc:date>2012-04-14T09:17:06</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>

