Dominoes posted:

What method do you recommend for causing a long calculation to not block the main thread? I'm attempting to use async, but am likely doing it wrong. Case: Have some long validations that once complete, trigger a Redux update. What currently happens is the app hangs until they're done. Is there a way I can make the GUI run smoothly while the calc is being performed, and update the Redux state once complete? From what I've read, it appears that prepending the long funcs with 'async' should accomplish this. Don't need to return anything, just let Redux update the state once complete.

Nolgthorn posted:

Not to tell you how to do it but I'd just compile separate js files as needed, then use the `async` html tag. Bingo bongo and it's done. The only thing typescript's compiler is bizarrely still missing is iife, so I use something lightweight like buble when I need it if I'm using typescript.

Webpack is like trying to land a rocket on mars, when all you really want is a little fin that's on the rocket. It has like 8 billion dependencies, it's a bloody mess.

Dominoes posted:

What method do you recommend for causing a long calculation to not block the main thread?

roomforthetuna posted:

A method I used that's easy and cheap is something like this:

code:

function moment() {
	return new Promise((f) => {
		setTimeout(() => f(true), 0);
	});
}
async function yourLongFunction() {
	// [at some not-too-common occasion]
	await moment();
}

If you await moment() too often it will take thousands of times longer to run your function though. You can either call it less often, or put something in there so it returns Promise.resolve() if it was called recently, and the setTimeout promise otherwise - even then you still don't want to call it super often, but like 10000 times a second with that version is fine.

Dominoes posted:

This appears to work as a quick in-place fix! Much easier than I'd assumed. Of note, the call to await moment_() must be at the top of the func; eg the slow code below.

Dominoes posted:

What method do you recommend for causing a long calculation to not block the main thread? I'm attempting to use async, but am likely doing it wrong. Case: Have some long validations that once complete, trigger a Redux update. What currently happens is the app hangs until they're done. Is there a way I can make the GUI run smoothly while the calc is being performed, and update the Redux state once complete? From what I've read, it appears that prepending the long funcs with 'async' should accomplish this. Don't need to return anything, just let Redux update the state once complete.

Nolgthorn posted:

Javascript is still single threaded. Although you may async appropriately, if it's CPU heavy it will block the thread at whatever point that the stack decides to process it. What you may be looking for is web workers.

Munkeymon posted:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop is already kind of convoluted but then there are also microtasks which, well, have fun!

roomforthetuna posted:

You have to call await moment() repeatedly from the slow function to have it work. Waiting for a setTimeout of duration zero to resolve essentially means "yield for one UI cycle now". There is no way to actually multithread javascript other than introducing webworkers, which are relatively high effort.

Lumpy posted:

This: https://www.youtube.com/watch?v=8aGhZQkoFbQ is in my opinion, the bestest thing for understanding the event loop.

roomforthetuna posted:

Relatedly, has anyone here done anything with WebRTC? That's nearly as much of a clusterfuck to get going as webpack+typescript+npm. I got that working too, finally, and all it requires is like 14 messages through two server connections in order to establish one peer-to-peer connection.

MrMoo posted:

Sounds like you are holding it wrong. The spec has changed a lot which is the most annoying. I have a video wall setup to render a 16K video with it.

Dumb Lowtax posted:

I have a key-value collection of arrays, and each array is expected to be the same length.

Example test data:

code:

const arrays = { a: Array(10), b: Array(10), c: Array(10) };

What is the most concise way to retrieve that length?

Object.values( arrays )[0].length seems kind of excessive since it has to touch all the stored arrays when i just need one.

Dumb Lowtax posted:

I have a key-value collection of arrays, and each array is expected to be the same length.

Example test data:

code:

const arrays = { a: Array(10), b: Array(10), c: Array(10) };

What is the most concise way to retrieve that length?

Object.values( arrays )[0].length seems kind of excessive since it has to touch all the stored arrays when i just need one.

roomforthetuna posted:

As far as I can tell you need:
1. one peer sends an RTCSessionDescriptionInit to the other via the server.
2. the other peer applies that one and generates a response one, sends that RTCSessionDescriptionInit to the first peer.
3. both peers now start generating IceCandidates, which it seems to be recommended you communicate as soon as they are generated. In my test case, each side generated 6 RTCIceCandidateInit objects, which makes it 14 messages through the server total. I figure you probably could clump all the IceCandidates together into one message each way, since more are generated even if you don't send them, but I'm not sure if that would be better or worse (also not sure if the list is communicated via the callback with some kind of a null-terminator at the end or what, none of the examples were clear on why it's valid for an IceCandidateEvent to have its 'candidate' property unset.)

roomforthetuna posted:

If you're targeting an ES6 target and you're also in control of your key-value collection, you could make the collection as a Map rather than a {} object, which would then allow you to access it as an iterator rather than duplicating the keys into an array, which I believe would allow you to look at just the first element.

But if your data is going to/from JSON or something then you might be just front-loading the extra pass to do that.

Dumb Lowtax posted:

I use SimpleHTTPServer to develop JS locally and just now started trying to use es6 modules. Unfortunately SimpleHTTPServer doesn't know about .mjs files and delivers the wrong mime type for them. Is there a workaround anyone knows that's simple enough to get hundreds of my students to reliably repeat, or should I just wait on introducing modules to our code until a fix comes in (which looks like soon)?

Dominoes posted:

Here's a script I use, for the Python3 version and wasm. Edit the handler.extensions section for your mime type:

Dumb Lowtax posted:

Sorry, I don't know how to do this. I hope I would just need to paste that into a file somewhere but I'm not confident Windows makes it that easy. Basically assume that I have no experience with Python besides running the Windows installer and then running a batch file I wrote that calls SimpleHTTPServer in the current folder. This is going to be the experience level of many of my students too. Either way, is this going to make my instructions document for them twice as long about how to set up our local JS development? If so I need another way.

Secondly, is this bug maybe already fixed? It looks like they were working on it last week, and the issue is marked as fixed: https://bugs.python.org/issue31715
Can anyone read bug-tracker speak and find out what Python release version this patch can be expected in?

Dumb Lowtax posted:

Sorry, I don't know how to do this. I hope I would just need to paste that into a file somewhere but I'm not confident Windows makes it that easy. Basically assume that I have no experience with Python besides running the Windows installer and then running a batch file I wrote that calls SimpleHTTPServer in the current folder. This is going to be the experience level of many of my students too. Either way, is this going to make my instructions document for them twice as long about how to set up our local JS development? If so I need another way.

Secondly, is this bug maybe already fixed? It looks like they were working on it last week, and the issue is marked as fixed: https://bugs.python.org/issue31715
Can anyone read bug-tracker speak and find out what Python release version this patch can be expected in?

The Fool posted:

The mimetype addition appears to have been committed 20 days ago, which would put it in the 3.7.2 and 3.6.8 releases.

LifeLynx posted:

I was happy with this script I wrote (maybe not entirely from an efficiency standpoint) until I realized it doesn't work in any iOS browser. It doesn't work in IE11 either, but I don't mind that too much.

Is it possible to tweak this slightly so it works without IntersectionObserver, which is the reason it's not behaving nicely with Safari on iOS?

Siddhartha Glutamate posted:

Siddhartha Glutamate posted:

The biggest problem I have is that the variable game.playerMoves, which right now logs the color of one of the four options the player has, will at first show the correct selection, but then it will double the selection. So if on the first turn the player clicks on the blue X the log will read "blue" then on the second turn if the player clicks red it will log "blue, red, red" and each additional time through it will log the click multiple times instead of once.

Strong Sauce posted:

playerMoves is an array. when you print an array in javascript it prints out all the elements separated by a comma. to get the last color chosen from the array, you need to output

code:

game.playerMoves[game.playerMoves.length - 1]

. if you have no need to keep track of all the moves, then you can change that variable into a string containing the color instead of an array.

edit: wait a minute, you don't even call numCrunch, the thing that is duplicating itself in your console log is game.compMoves, which you keep adding onto every time you call "selector()" which is everytime you click the start button...

roomforthetuna posted:

The linked codepen doesn't include the same code you posted, and doesn't even have responsive buttons.

quote:

I think the problem you have (that you described, not from the CodePen) is that you're calling numCrunch before each turn, and you never remove the eventListeners from your buttons, so on the first turn they each have one eventListener, on the second turn they have two, etc.
You could either remove the eventListeners and add them again after each move (which would be good if you want buttons to be nonresponsive while noises are playing or something), or just leave them active until the game is over and not add them repeatedly.

Nolgthorn posted:

Yes, it's not a vue thing it's a javascript thing.