News for hackers. Stuff that matters.
Re:Porting to Emscripten by AgentME on Tuesday November 04, 2014 @05:52PM (#8559556)
One thing missing from the article: If you have a fullscreen mode, provide an alternative to the escape key for opening menus or whatever action you had bound to that key, because the browser interprets escape as a command to exit fullscreen mode. Plenty of the Humble Bundle asmjs games didn't get this.
Re:Porting to Emscripten by pmalynin on Tuesday November 04, 2014 @03:21PM (#8558827)
So when can we see Firefox ported to Emscripten?
Re:Porting to Emscripten by corysama on Tuesday November 04, 2014 @03:34PM (#8558891)
Re:Porting to Emscripten by Lerc on Tuesday November 04, 2014 @03:37PM (#8558905)
That is a more serious question than it first appears at first glance.

Firefox, GCC, cat, gzip, PovRay are all things that should be potentially doable. Each one will not necessarily _have_ to be done, but the idea should be embraced to see if they are possible. If there is any reason why these things are impossible, that should be an area to focus on. Why is it not possible? Should it be possible, and if so, how to make it possible.

Re:Porting to Emscripten by bobajeff on Tuesday November 04, 2014 @05:32PM (#8559466)
I can't wait until the tooling gets to where I don't have to debug natively first.

I perticularly ran into issue dealing with unimplemented functions in some POSIX libraries. Then I tried to use the source maps in a debug build to find out when and where they were being used during runtime because they would stop the rest of the program. Unfortunately I couldn't compile the debug build because emscripten kept getting stuck in the linking phase (I had to force quit). I hope one day this all works as well as the Android NDK.

Re:Porting to Emscripten by captaincrowbar on Tuesday November 04, 2014 @10:09PM (#8560352)
This looked like great news until I came to "Heavy use of threads is also going to be a problem since Emscripten doesn't currently support them."

Sorry, this is a total showstopper for me. I'll check back when Emscripten actually lets me use more than 1/4 or 1/8 of the CPU.

Re:Porting to Emscripten by marcosscriven on Wednesday November 05, 2014 @03:50PM (#8564162)
You can use the other core, but you have to think of them a little like separate machines. They can't share memory, but you can pass messages between them very fast (using JS's underlying Trasferale Objects) If you can use bump/frame allocators those 'messages' can be whole chunks of 'memory'.
Re:Porting to Emscripten by hippich on Wednesday November 05, 2014 @12:28AM (#8560629)
It already does - just run your code in webworker. I am doing it at https://hashcash.io/

Detection of number of available cores is totally different problem. On the other hand, probably detecting number of cores should not be used in first place..

Re:Porting to Emscripten by bobajeff on Wednesday November 05, 2014 @12:17AM (#8560613)
According to this document Jukka Jylänki is working on it: https://docs.google.com/spreadsheets/d/t3AwIGGaM-4Z9UZM2jpF6...
Re:Porting to Emscripten by marcosscriven on Wednesday November 05, 2014 @03:52PM (#8564172)
Oooh - how did you come across that? I had an idea for a way to do this https://groups.google.com/forum/#!searchin/emscripten-discus...
Re:Porting to Emscripten by AlexeyBrin on Tuesday November 04, 2014 @10:58PM (#8560460)
This is because of how JavaScript is implemented, you can't use threads in JS like you can in a C++ program.
Re:Porting to Emscripten by flohofwoe on Wednesday November 05, 2014 @06:13AM (#8561318)
Shameless plug for my MIT licensed, experimental, mini C++11 multiplatform engine which has been designed specifically with emscripten in mind: http://floooh.github.io/oryol/
Re:Porting to Emscripten by dbpokorny on Tuesday November 04, 2014 @05:02PM (#8559332)
This is great news, it feels like the future is finally starting to arrive. Check this out: http://jamesfriend.com.au/pce-js/