Would it be better if GPU drivers could compile open-spec bytecode and upload the result to the GPU to do all of the computation? This way OpenGL may be used as a library, shipped with the application.
I just came here to write that I think this is THE right approach for wysiwyg editor. Having a full model of the document tree rather and working from that rather than sanitizing `contenteditable`. I expect this approach to automatically solve many problems that other wysiwyg editors have.
No, light is not different. If you want to adjust for "red/blue shift", you may use special relativity, and in special relativity you have the conservation of 4-momentum, which will give you the same result.
From what I see, the only thing that can help with post-mortem debugging is changing the promise so that it doesn't catch the exception when calling the initialiser or handler. You can still do whatever you could with Promises (but you have to do `Promise.reject(...)` or `reject(...)` instead of `throw ...`), but it's not going to conform with the standard. Many libraries are probably going to break if you drop-in a Promise implemented this way.
Edit: I didn't explain why this change is important: if the Promise is catching the exception, the Execution Context where exception was thrown is lost and (potentially) irrecoverable, the program has to crash there and now if you want to debug the reason for the exception. This is a property of the Promise standard, changes to debugging tools or environment won't help.
You could make Node aware of promises, and capture the execution context with promise exception, but I don't think Promises are special enough.
> To make your GC-when-appropriate advice real, one has to show a real implmentation.
I haven't tested it closely, but I believe that Rust with this crate: https://github.com/Manishearth/rust-gc is an implementation for "GC only when you need it".
I don't support using GC for everything. If there is a problem that can only be solved with GC, it doesn't mean that we should express our entire running programs in terms of dynamic cyclic graphs. I believe we can do much better, with much fewer resources.
> Of course, there is an argument that just GCing everything is as efficient as bothering with manual memory management
I specifically said that it should be possible to mix GC with other types of memory management.
The problem is that I often hear from C++ crowd "GC is bad, mmkay!", without mentioning that there are specific cases where you have to use/implement GC.
Do you understand that the linked article, and the talk referenced in the article describe a way to implement garbage collection as a solution to (memory management for) data structures with cycles?
Do you think that this problem is not equivalent to "how do I allow my dog to make a 'press this button for fart sound' app?"?
Do you have a better solution to reclaiming data structures with cyclic pointers?
I recently watched Herb Sutter's talk "Leak-Freedom in C++", described in the article [1], and I can't help but notice that C++ community has a strong bias against garbage collection. ... And then he describes the very problem you can't solve without GC: memory management for graphs with cycles. Solving this problem is equivalent to implementing GC. Of course, having your own specialized GC may help, but you may also benefit from your own memory allocation.
Why can't you acknowledge that there are problems that have GC as the only and best solution?
(Note: it's possible to mix memory management approaches, e.g only pointers to graph nodes are being garbage collected and everything else has a nice hierarchical ownership.)
If you're a photographer, I can always make a screenshot, or record the video from my HDMI/DVI cable to the monitor or take a very precise photo of my screen, and I WILL get the photo from your website or app.
There is plenty of evidence that DRM doesn't stop copying: millions of torrents ripped from crunchyroll/hulu/netflix/Blu-Rays, all of those have some sort of DRM, all of them were circumvented. There are people who think that DRM is not designed to stop copying, but it's designed to control how legitimate users consume your product (see: DVD ads).
Edit: Please don't assume that this is the only argument I have, it's just the most obvious argument from the top of my head. There are plenty of people who explain the negative sides of DRM and reasons it doesn't solve the problem you described. They do it in a very eloquent way with rigorous arguments, and I don't believe that I need to repeat those arguments. I'd like you to listen to Cory Doctorow: https://www.youtube.com/watch?v=HUEvRyemKSg
The answer is that it's technologically impossible to prevent third parties from using your work if you publish it. DRM doesn't solve this problem, but claims to do so. As a result, genuine users suffer from DRM.
There is a significant difference between self-driving cars in 1960, flying cars and self-driving cars today.
Flying cars are doable, and there are several prototypes of a flying car. However, flying cars aren't safe and aren't cost-effective.
Self-driving cars in 1960 require a significant infrastructure to operate, and can't operate with human drivers. (Edit: Not to mention they don't exist)
Self-driving cars today work, and are cost-effective, and it's likely that they will be safer and create a much better traffic ecosystem than humans ever will.
- http://www.ifp.illinois.edu/~jyang29/papers/chap1.pdf
* Image super-resolution: Historical overview and future challenges
- http://www.robots.ox.ac.uk/~vgg/publications/papers/pickup08...
* Machine Learning in Multi-frame Image Super-resolution
- http://www.cs.huji.ac.il/~peleg/papers/icpr90-SuperResolutio...
- http://www.wisdom.weizmann.ac.il/~vision/SingleImageSR.html
- http://chiranjivi.tripod.com/EDITut.html
- http://www.tecnick.com/pagefiles/appunti/iNEDI_tesi_Nicola_A...
- http://www.eurasip.org/Proceedings/Eusipco/Eusipco2009/conte...
- http://bengal.missouri.edu/~kes25c/
* http://bengal.missouri.edu/~kes25c/nnedi3.zip
* http://forum.doom9.org/showthread.php?t=147695
- http://arxiv.org/pdf/1501.00092v2.pdf
* http://waifu2x.udp.jp/
* https://github.com/nagadomi/waifu2x
* http://waifu2x-avisynth.sunnyone.org/
* https://github.com/sunnyone/Waifu2xAvisynth
- http://i-programmer.info/news/192-photography-a-imaging/1010...
* https://github.com/david-gpu/srez
- http://arxiv.org/pdf/1609.04802v1.pdf
- https://github.com/alexjc/neural-enhance