Bug #57894 for JavaScript-SpiderMonkey: Why do we need "init" and "new"?

Thu May 27 03:56:50 2010 bkb [...] cpan.org - Ticket created

Subject:

Why do we need "init" and "new"?

Another question about this; is there any reason why we need to have "init" and "new"? All "new" does is just fills in the object with undefs, and then "init" fills in the same fields with the meaningful values. Is there actually a case where someone would need to call "new" without calling "init"? It seems really unlikely, since "new" actually doesn't do anything useful at the moment. I suggest merging these into one routine, and making "init" into a no-op for backwards compatibility.

Thu May 27 07:42:41 2010 bkb [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #57894] AutoReply: Why do we need "init" and "new"?
Date:	Thu, 27 May 2010 20:42:31 +0900
To:	bug-JavaScript-SpiderMonkey [...] rt.cpan.org
From:	Ben Bullock <benkasminbullock [...] gmail.com>

Re this bug and the other one I discussed, please find attached a patch which fixes it. This also adds three new methods to the JavaScript::SpiderMonkey object, which are "eval_file", "compile_file" and "decompile". The "eval_file" method is as discussed on the other bug report. The "compile_file" method might be useful for someone who wants to do a syntax check of their JavaScript. The "compile" plus "decompile" can be used, e.g. to make an indenter. There are some new test scripts which test some of the functions but the documentation is not complete. Some notes: the "name" and "indent" arguments to JS_DecompileScript I've included for completeness, but "name" doesn't seem to do anything, and "indent" just indents everything by a fixed amount, with the actual indentation of braces etc. used being four spaces regardless of what this is set to. Also, I've used the return value from the function "as is", but it seems to me that it should be copied into a new string, since otherwise it seems to be a memory leak somewhere, and maybe the JavaScript interpreter will garbage collect it? I'll hold off writing full documentation for the new functions pending approval of them. Please let me know what you think of these new things.

Download javascript-spidermonkey-patch-2010-05-27.txt.gz
application/x-gzip 2.4k

Message body not shown because it is not plain text.

Sun May 30 18:42:41 2010 bkb [...] cpan.org - Correspondence added

From:

benkasminbullock [...] gmail.com

Re the "decompile" method (should be "decompile_script" as noted by email), I've been studying the source code of SpiderMonkey and found a couple of things. Line numbers here refer to SpiderMonkey 1.7. (lines 4130, 4131 of jsapi.c) 1. The "indent" flag contains a bit (0x8000) which controls whether to "pretty print". The bit is defined by a macro JS_DONT_PRETTY_PRINT. This isn't documented in https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference/JS_Decompi leScript There may be some other stuff (bit flags) hiding in there. 2. The memory which the string is in is in is allocated by js_GetPrinterOutput on line 637 of jsopcode.c. This is done by something called js_NewStringCopyZ in jsstr.c which calls JS_malloc to assign and then copies the string. JS_malloc is just a call to malloc plus a byte counter, on line 1659 of jsapi.c. I don't know too much about Perl XS so I'm not sure how Perl should handle this allocated memory, or whether it's automatically freed.