lots of bugs / warnings c2runtime

hey everybody..

Ashley - i have a question (or few), i've exported html 5 pure empty project with nothing in it, nonminified, and i've noticed after running it in visual studio and some web analyzer that a lot of bugs suddenly appears (as you can see on image).

http://i.imgur.com/vsHNsFp.jpg

now i've ran through these warnings and stuff and i've noticed that some are really "heavier" bugs that might cause some overheads when compiling / running because they create exception objects and traverse upwards until they find a catch statement to be thrown or caught. so this might be a problem maybe that is flooding c2 currently.

i've also attached a c2runtime.js that is cleaned of these bugs, you can use araxis merge / kdiff and compare it to normal exported empty project c2runtime.js to see the changes and tell me what you think? could you insert those fixes for next release? (they might not improve performance and all, but they might create more stability though)

https://www.dropbox.com/s/124wyh4f20f4p ... me.js?dl=1

p.s. if you wonder how i found those bugs - download visual studio 2015 community, install everything (cordova tools and all), export empty project, open visual studio, create blank apache cordova app, copy c2runtime.js to www/scripts folder, open tools, extensions and updates, find Web Analyzer tool, install, restart VS, and open again the same project and opet c2runtime.js in visual studio, after a few sec it will show you errors like on picture above.

another thing to notice (for semicolons) .

http://www.bradoncode.com/blog/2015/08/ ... insertion/

it would seem that a lot of things are processed if there is a missing semicolon, valid tokens get immidiately to read the next one, but the ones missing seem to do a bit of overhead. (check image "putting it all together")

hey

Ashley - i've cleaned all the behaviours with Web Analyzer and will leave clean versions on my dropbox, download file is here:

https://dl.dropboxusercontent.com/u/136 ... thLint.rar

i've also replaced them in html/exporters, ran a project and everything seems to be smooth, no errors, no bugs, seems to be okay.

i'll go clean plugins next. and then the JS files in html5/exporters

I don't think any of those messages matter at all. They are just coding style messages. We use our own tools for that.

mostly i agree, but compilers / interpreters have to handle javascript errors when they are caught and losing time to handling them just to avoid errors takes some small amount of time. when it gets loaded with such small time errors - all together it causes a bit more of time wasted.

nontheless i'll do my job and clean the rest of the files on the current version of C2 and upload them here. you can still check them and use if you want, if you don't want won't bother me, i'm just trying to help you out guys <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

anyway this analyzer does the following: CoffeeLint, ESLint, CSSLint, TSLint.

more details here: https://visualstudiogallery.msdn.micros ... 820d79be1d

here, i've cleaned the plugins with JSLint (runtime and editme). tested on 3-4 projects and my huge one, everything seems to work normally, didn't have errors before, don't have them now, still might help with minimizing / compiling errors.

Ashley

https://dl.dropboxusercontent.com/u/136 ... lugins.rar

i'll go and finish with JS files in c2/exporters/html

mostly i agree, but compilers / interpreters have to handle javascript errors when they are caught and losing time to handling them just to avoid errors takes some small amount of time. when it gets loaded with such small time errors - all together it causes a bit more of time wasted.

I'd have thought this would make almost no difference at all. They are not errors, it's just coding tips provided by a style tool, and whether they are corrected or not it's still standards-compliant Javascript code. Can you actually measure an improvement after the changes?

maybe, not sure that there is a performance improvement, but following these fixes that JSLint provides makes code more "stable" and less prone to errors. also minification works better when it's clean.

i was checking code for performance improvements and i'll do that next once i finish this "cleanup". i've spotted some functions and stuff that can be improved, possibly only in microbenchmarks, but lots of micro ~ 1 macro

i noticed that some statements don't end with ";" for example, which makes compiler compile 2 times the same statement because JS compilers "try" to parse the same thing with / without ";", so if it's missing it's doing a double job. (at least according to guys on stack overflow). still some functions that are long one liners (saw these a lot) and end up with })})})}) are better written }); }); }); just because it provides more stability when compiling and reducing errors.

Unless you can actually provide benchmarks that indicate a measurable difference, this is basically a waste of time. I don't see any real measurements proving there is an improvement, and I don't believe there is any technical reason for there to be any improvement either. Minification radically alters the code so much that the original formatting doesn't matter much, coding styles don't usually affect functionality, and I don't know what you mean by "compiling stability" or "reducing errors", the current code is still standards-compliant Javascript so will be parsed, compiled and executed more or less identically regardless of whether there are extra/missing semicolons, parentheses, etc.

i don't see why following conventions that were written by JSLint and other JS developers shouldn't be followed. even a small semicolon missing can cause errors in execution of code, same as badly written code. i've just used the tool to fix the few missing errors in each JS file you provide.

if you really don't trust me, just check how much "fight" did they have about one single semicolon on bootstrap, and in the end both jQuery and bootstrap fix'd the error - https://github.com/twbs/bootstrap/issues/3057

also like i said, i'll post (today or tommorow) cleaned the rest of files, and then i will go do some microoptimizations (maybe i find even some larger ones, we'll see), just don't come then saying "but this small optimization doesn't mean much, so we won't implement it", because in tight performing systems like game engines, each optimization is a bless.

saiyadjin Personally, I'm really interested in your results. So if you can do some performance tests after your fixes, please post it here. I'll check this topic very often. I think it's great that you do these experiments/fixes in your free time. It might be important what you discovered, it might not, but I think it's worth finding out.

That bug referenced broke the code when it was minified. C2's runtime does not break when it's minified, so there is no issue.

glerikud - i will keep this post updated with everything i do, so stay tuned.

R0J0hound - true. but some users report that some stuff doesn't work when minimized from c2. therefore those might get fixed.

What stuff breaks? I've only seen third party plugins cause minifying to break things. If it's an official plugin that breaks, wouldn't fixing that directly be better?

i've noticed another "bug", while c2runtime.js is being created, i'll have to display that in images. but first things first - here's all JS's cleaned in exporters/html folder.

tested on my big project, works ok.

here's the DL:

https://dl.dropboxusercontent.com/u/136 ... rFiles.rar

still though i've tried exporting empty project and i noticed there is still some problems and i've found out which ones:

if you open c2runtime.js and find this line (1485):

RenderCell_.prototype.isEmpty = function ()
	{
		if (!this.objects.length)
		{
;
;
			return true;
		}
		if (this.objects.length > this.pending_removal.count())
			return false;
;
		this.flush_pending();		// takes fast path and just resets state
		return true;
	};[/code:38s3eehs]

as you can notice there are some ";" appearing randomly inside that code which is very very wierd. it happens because the following code which is found in common_prelude.js has some "assert2" statements that are on export translated to ";" instead to empty space:

[code:38s3eehs]RenderCell_.prototype.isEmpty = function ()
	{
		// 'Empty' state is a little non-trivial since there is the set of objects pending_removal
		// to take in to consideration. First of all if objects is empty then we know the cell is empty.
		if (!this.objects.length)
		{
			assert2(this.pending_removal.isEmpty(), "expected empty pending removal list");
			assert2(!this.any_pending_removal, "expected no pending removal state");
			return true;
		}
		
		// 'objects' is not empty. However if there are fewer instances in the removal queue, then
		// even if we called flush_pending we know there would still be instances left.
		// So we can safely indicate that the cell is not empty.
		if (this.objects.length > this.pending_removal.count())
			return false;
		
		// Otherwise every item in objects must be in the pending removal set.
		// The set will be empty if we update it. Use this opportunity to clear the state
		// and indicate empty.
		assert2(this.objects.length === this.pending_removal.count(), "expected pending queue to be same size as object list");
		this.flush_pending();		// takes fast path and just resets state
		return true;
	};[/code:38s3eehs]

as you all know, to minimize size, comments are removed, and assert2  statements are removed, which leave a semicolon in their place for no obvious reason. since this happens in runtime while exporting i can't fix that one, this one is on Ashley <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">