Hacker Newsnew | past | comments | ask | show | jobs | submit | manilafolder's commentslogin

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.

https://webcourse.cs.technion.ac.il/234267/Winter2015-2016/h...


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."


I think "tougher and more expensive" is enough of a distinction. I buy a lot of gear in the hiking/camping/onebag world, and a lot of companies there comprise nothing other than a "our shit don't break" philosophy. For example, Goruck bags or Wolverine boots.


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.


Not XWT, but it's worth checking out Eto.Forms as it's very robust, uses native components, and you can build UIs using straight C#.


I just spent some time working with Eto.Forms (based upon your recommendation, thanks!). It looks pretty nice and seems straight-forward. I also appreciate that it officially supports F# in addition to the regular C# and VB.NET.

Unfortunately, it doesn't support .NET Core/Standard yet. The lead dev, Curtis Wensley (@cwensley), is currently working on supporting it and said that he hopes to have to completed in time for the Eto 2.4 release, per their Gitter chat (https://gitter.im/picoe/Eto?at=59d65ab4177fb9fe7e41ff9e).

Another interesting detail is that Avalonia seems to be using Eto's parser implementation. And Eto is (will?) using AvaloniaUI's (the parent of Avalonia) monomac implementation.


Maybe non-Xamarin-employee interest has declined sine the announcement of Xamarin Forms coming to the desktop?

https://blog.xamarin.com/glimpse-future-xamarin-forms-3-0/ (2017May)


That's good point.

But one big difference between Xwt and Xamarin Forms is that Xwt supports Linux via GTK (GTK1, GTK2 & GTK3) whereas Xamarin Forms does not.

Xamarin Forms also requires different code for different targets, such as:

   // Android
   Forms.Init(this, null);
   var androidFragment = new MyFormsPage().CreateFragment(this);
 
   // iOS
   Forms.Init()
   var iosViewController = new MyFormsPage().CreateViewController();
 
   // UWP
   Forms.Init(e);
   var uwpElement = new MyFormsPage().CreateFrameworkElement();


From the roadmap linked in that blog post:

Xamarin Forms Gtk# Backend - https://github.com/xamarin/Xamarin.Forms/pull/1174

It's all floating out there right now but maybe by end-of-year ("Q4 2017") there will be something solid. This uncertainty promises enough to keep people like me from evaluating alternatives.


Here's a link to the author's blog post on the subject, which has the text from the talk (in addition to the examples contained in the PDF slides): https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-objec...


Thanks—we changed the URL to that from http://kievfprog.net/talks/oleksandr-manzyuk.pdf, which is linked in the first paragraph.


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?


My understanding is that type providers define the types at compile time.


As far as I can tell, Type Providers are just a slicker way of having external codegen tools. So instead of "SoapToVBCode.exe" you have it wrapped up in a type provider and can just do "type MySoap = SoapProvider<http://wsdl>".

It seems like a useful feature but far from the power of having full macros.


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.


Actually, my plan was to have the recognition area expand beyond the visual size of the input box as soon as your pen touched the input box, so as not to penalize the user for wandering out of the box a bit, while not having any visually jarring effect, but it's worth experimenting.

And of course, there is still the option of scaling the page overall. It's possible the audiences that would want bigger input boxes would also want the text and images to be bigger as well, but it needs research to confirm.


Another option would be to set the text caret inside the text box, but allow people to write anywhere, while the focus is on a text field. This is probably something where you'd have to do a ton of different prototypes, and see which one feels best.


Agreed that there are plenty of ideas that warrant prototyping, but I think there is special value in not having a text cursor to manage at all, similar to how touchscreens obviated mouse cursors for certain tasks.


Yes, if you can pull that off, it's a huge win.


Maybe he loves programming just for the sake of programming, not for sake of earning money. Not all of us want to corrupt our souls.


If that were the case, I can't help thinking he could have released the app without the ads, or at least pushed out an update removing the ads at this point, instead of removing it. I don't think this is about money.


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.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: