Hi, for Intel processors, the renamer can detect instructions that will always result in a zero (zero-idioms or dependency breaking idioms). As a result, the renamer will not send the instruction to the execution engine.
Basically, just think of this as repointing your registers to a register that's always zero. Note this only appears for the value zero.
This is one of the reasons you're supposed to wipe out sensitive data with random numbers, not zeros.
Also note that your compiler may copy data to the stack whenever it wants to. So even wiping out data with random numbers may not wipe out the copied data that lives (momentarily) on the stack.
I'm speaking completely outside of my subject area, so take this with a large grain of salt but hear me out -- I think the video is great and success from the Kickstarter is proof of that.
But, I think a business needs to have solid distinguishing characteristics. An ad that basically says, "It's more durable and just a little more expensive, so if you do the math, it will work out in your favor after a long enough period of time" doesn't sound like you're playing your strongest cards in your hand.
If you can make a product that no one else can, such as 3-6 denier, or super-strong athletic compression tights, then you create name-brand distinction. Even if it means that the bulk of sales end up being what you just advertised in Kickstarter, the tail-ends of the market is what defines the brand. "Super-sheer, super-strong."
Regarding native cross-platform UI frameworks, isn't this what Xwt is supposed to be (https://github.com/mono/xwt)? There's no XAML non-sense and it's an object-oriented approach to building your UI, similar to Windows.Forms.
The primary benefit to it over something browser-based is start-up time. Since it's ultimately using native assemblies and there's no web server that needs to be spun up causing start-time lag.
Is anyone using Xwt? The NuGet packages for it are up-to-date (but don't have very many downloads), and the official forum for it seems very dead.
This is an interesting meta-analysis of some of the studies done on the efficacy of vitamins: https://www.youtube.com/watch?v=2mDrAQi1SwU (Presentation by Dr. Jeffrey Tice of the University of California).
He covers vitamins A, E, and C around 18 minutes into the presentation.
I'm sorry for my ignorance, but there's something about type providers I just can't wrap my head around.
It seems like the primary purpose of using a typed provider is so that the types (classes) can dynamically change during runtime (for example, you get different table objects for the different connection strings you pass in). But how do you program a client against an API that can change at will? Is your client code just basically doing runtime reflection on the data the type provider returns?
Great demo. That's exactly how the handwriting UI should have been designed.
I have one small suggestion, if you don't mind: How about making the input box increase in size (maybe double in size) so you don't have to write so small? The resizing wouldn't need to reflow the rest of the page; it could turn into a modal textbox in the same location as the original textbox. It would make it easier for children, the elderly and people who aren't native speakers of the language, etc.
Same problem for me. I couldn't make out the letters in the word I was typing because the word was hidden behind other words.
The word that is being typed should automatically move to top z-index. Maybe that word could also get a little larger than the other words to make it more obvious which one you are targeting.
Basically, just think of this as repointing your registers to a register that's always zero. Note this only appears for the value zero.
This is one of the reasons you're supposed to wipe out sensitive data with random numbers, not zeros.
Also note that your compiler may copy data to the stack whenever it wants to. So even wiping out data with random numbers may not wipe out the copied data that lives (momentarily) on the stack.
https://webcourse.cs.technion.ac.il/234267/Winter2015-2016/h...