It seems like a good idea to me too, and the sort of thing I could also put on my (long) todo list. Possibly there are enough of us with some C/Python knowledge, some interest, and some small bits of time to JDI (Just Do It) that pooled together it can actually get done?
Actually, there is! It is called vimagit
For the moment, it is mainly focused on the stage/commit feature, with a lot of actions possible (e.g. stage by file/hunk/line/word). And it is very stable.
It does not as much as magit because:
That's a question that came up in the conversation; I didn't manage to work it into the article, sorry. There is definitely interest in doing that, and it seems possible, but nobody is working on it at the moment.
This assertion routinely happens in PHP space, by people who are otherwise good enough programmers that they should know better.
The complexity all comes in if you want to serve your users well (which boudewijn & co seem to, as doing so has led to Krita's success). For me €10 towards a feature I'd like is not a sacrifice, €100 might need discussion with my family, while €1,000 or more would need some form of return on investment to allow me to justify the spend. Further, I'm already a C++ developer, and I've some experience of Qt; thus, for simple features, I can do it myself in a reasonable amount of time, and complex features are "just" a matter of me wanting to put enough time in.
In contrast, an up-and-coming artist might have to decide to skip a meal or three to save up €10 for a feature; more than that involves skipping more meals. They don't have the programming skills (and developing good enough skills to be a useful Krita contributor would take away from developing their art skills that they're passionate about), so they can't easily put in the time and effort that way. Yet, because (unlike me), they're trying to make their living from their art skills, their insight into what would make Krita more productive is a lot more valuable than mine.
Hence this being a hard problem - how do you ensure that the high value contributions from people without much money (yet) are rated above those of rich dilettantes?
ORC will track neither of those things; it just provides the information needed to make sense of the kernel stack. The kallsyms mechanism can associate symbols with addresses, as always.
Just kidding. You meant TCB, didn't you?
I was one of a few people who regularly griped that, for all of Perl 6's amazing Unicode support, it barely did anything interesting with it. I tried making a half-baked external module for things like the latin-1 arithmetic and unicode set operators many years ago that didn't work too well (there weren't even Set types back then!)
Today all that stuff is built in and super-polished. My favourite is actually the smart quote pairs: they were only added because someone's IRC client kept mangling them, but they also make shell one-liners a million times less painful than other languages which suffer from leaning toothpick syndrome, and the parser errors are more helpful too.
For users, an application running 100x slower may be nearly as unusable as an application crashing with an "instruction not supported" error, and is much harder for the application's developer to debug from a bug report. In both cases the developer would probably just switch their compiler flags from SSE2 to x87 once they recognise the problem.
Applications that do lots of number crunching and want to support a wide range of users will already provide both x87 and SSE2 code paths, and select one based on CPU capabilities, so the emulation won't improve compatibility there (and might confuse the capability detection code).
The only case where emulation would really help is code that uses a non-zero but tiny amount of SSE2, so it would improve compatibility and nobody would care about the performance cost, and that doesn't sound common enough to justify a substantial effort.
There is an Intel Software Development Emulator <https://software.intel.com/en-us/articles/intel-software-...> that emulates recent SIMD instructions etc, but that's for developers to test them before hardware support is available, it's not intended for users. (It seems to do a sort of JIT translation that can replace certain instructions with calls into the emulator, which is much faster than reacting to illegal instruction exceptions.)
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds