Scratch

nXIII wrote:

Async will make it so it doesn't totally crash when it tries to load giant projects, but it probably won't get that much faster (I'm not sure, though—it depends how optimized the code is right now).

Asynchronous loading can affect the user's perception of speed, but it does nothing to change the actual time requirement.  So it works (subjectively) when the loading time is dominated by the running time and can be spread out thinly over the latter.  When the user's experience is dominated by loading time, async won't help at all.  I suppose one could try to take advantage of multicore processors by having the loading and running truly in parallel.

It's still a worthy effort, not for gargantuan projects, but to help me convince Jens to import the tool library all the time on startup. 

Gargantuan projects shouldn't crash, though.  By all means please find and fix whatever's causing that.

JS is single-threaded (I'm ignoring web workers because we don't use them), so when the serializer is running, user input is neither received nor handled and the display is never updated. Loading asynchronously would mean that we could continue receiving user input and updating the display (and allowing the browser to run its UI for non-multi-process browsers) while the serializer ran. It would do very little to change the load time (it might make it a tiny bit slower because each morphic.js display cycle takes some processing power), but would give the user a sense of the elapsed and remaining time as well as the total progress, and make Snap! feel more responsive.

I also said that if I made the (de)serializer asynchronous I'd rewrite it from scratch with speed as the primary concern, which could make it substantially faster.

To this end, I need some reasonably large projects which load in the current serializer, as well as some that fail to load due to errors and some that hang Snap! indefinitely. Contributions would be greatly appreciated 

joefarebrother wrote:

Anyone got any idea why i'm getting this error message?

Can you post the raw JS file? Much easier to debug that way. 

You could also try JSLint; I sometimes find that a different error message, that helps find the problem.

I'm writing a text-based Snap! language in JS based on the [scratchblocks] syntax 

Cool!

Last edited by blob8108 (2013-04-18 11:51:57)

Hardmath123 wrote:

Missing semicolon at end of line 30?

One of the most common reasons for a program not functioning: A missing semicolon. 

Last edited by nathanprocks (2013-04-18 12:13:53)

Look what I found: westley.c. It makes my mind boggle just looking at it. 

technoboy10 wrote:

another reason I use Python. Semicolons are irritating

Python has semicolons too, you know... 

joefarebrother wrote:

Anyone got any idea why i'm getting this error message?
http://i.imgur.com/ixhNiuf.png
I'm writing a text-based Snap! language in JS based on the [scratchblocks] syntax 

FYI lines 23-30 can be replaced with something like this:

code = code.replace(/([:)>\]] )([<>])( [:(<\[])/g, function (_, left, sign, right) { // Woo, regex emoticons
    return left + (sign === '<' ? '&lt;' : '&gt;') + right;
});

(if you need dynamic regexes, the constructor is RegExp, not regExp)

Also, use forEach instead of for…in for looping through arrays (for…in is for objects, and even then it has problems [and even the solutions to those problems have problems]).

Last edited by nXIII (2013-04-18 16:28:30)

@Hardmath I took another look at the giant xml file, and here are two few things that might help with the size of files that snapin8r generates:
- Don't pretty-print the XML. Whitespace alone accounts for 903,240 characters in that file (over 5% of the 17,424,524 total)
- base64-encode images rather than url-encoding them—it's much more efficient

bharvey wrote:

blob8108 wrote:

should I submit a github pull request? 

Sure!  Just don't put any colon-Ps in the code or Jens will get mad...

blob8108 wrote:

Question: Is coding late into the night a good idea? 

Depends, what're you programming?

blob8108 wrote:

Question: Is coding late into the night a good idea? 

If you have school, it's a really bad idea. Otherwise, go ahead (but beware of awkward family situations  ).

blob8108 wrote:

Question: Is coding late into the night a good idea? 

It depends how important it is that your code actually work.  Teams building life-critical software typically require programmers to quit work and go home at 5pm like normal people.  On the other hand, if you're building the first prototype of some new idea, banging away at it round the clock for three days can foster great creativity, I think.

A friend of mine in college once decided to live on a 28-hour day because 28*6=24*7 and by rotating phase he'd be awake at the same time as each of his friends at least once in the week.