I think it originated with the Lisa. It's mentioned in that context on folklore.org (1):
> Lisa users never dealt with Lisa applications directly (these were called tools in Lisa parlance) but instead always manipulated stationery pads which produced documents.
It's been there for a very long time. I used to teach DTP with QuarkExpress back in 92 and this feature was gold. It helped to preserve and not destroy the page templates of the magazine. The fine folks at this publisher had a hard time adjusting to the new world and it saved me so much time when they messed around with the layout and page settings
OneNote is not bad. However, there is no way to export your notes from it and move them to another program. At least with Evernote I was able to export all my notes very easily and then import them to Bear.app.
> Remember when Linux and open source were paragons of security? Man, how times have changed....
I remember a time when Linux was a paragon of security compared to the corresponding Windows version, Windows 95. I do not remember a time when Linux had no vulnerabilities. What happened is not that Linux got worse but that Windows got much better.
It was. When I got my first Mac in 2008, it was very straightforward. When Apple started to tighten OSX security they stumbled a little IIRC (I cannot find the old warnings and notes on the page). Also, around the same time, OSX installer changed, and OS upgrades started to take longer since TeX installation had so many files.
When they were working on these problems, I was in the middle of my Ph.D., and I needed a stable TeX installation, fast. I installed a Linux VM, all my woes went away, and that method just stuck.
I just checked the MacTeX page now, and it looks like they solved the problems I mentioned above, but currently I'm too lazy and need that TeX installation keep working, so I'll not retry it now.
I've downloaded the beta and played for 5 minutes. First remarks and thoughts:
- When the realtime typesetting works it is impressive. For example, changing the coordinates in a tikz picture results in almost immediate change of the PDF. And command / environment auto-completion is very smooth, very well done.
- However, the typesetter can get stuck and this happened for me in the first try. I am aware it is only the first public beta so I guess things will improve.
- Please, oh please, can any specialized TeX editor reproduce the following feature I have setup in Emacs? In the editor (not live preview) display standard mathematical symbols as symbols and not as commands. For example, make \alpha appear as α or \int appear as ∫. This is so nice that I hesitate moving to other tex editors because I know I will miss it.
Regarding the bug: Is there any chance you could email us at support at vallettaventures dot com? that way we can get back to you when there is a fix. Also, we may need a spindump to find out where it is locked up, so we can send instructions on how to create that if you have a moment.
We've had a request or two for this in the past. I've added your vote, the plan during the 1.8 series is to do a series of small updates, and this would be nice.
Personally, I'd be really against that feature, because I think Unicode symbols as math juxtaposed with monospace can look awful. If they do implement it, please keep a toggle to turn it off.
That’s not at all what the article claims. It presents a hypothetical scenario, based on real SAT average scores, where somebody can reach a very wrong conclusion (teacher unions are bad) based on this data. Then the article proceeds to explain how the difference in the average scores can be attributed to self-selection among students who take the SAT rather than unions. So, the article not only remarks on the suspicious causality but the suspicious causality is the article’s main point.
I understand what you are saying, but really don't think that suspicious causality is what the article is about at all. It's about selection bias. (not the same as causality)
Indeed after reading the article I feel it is generally well written and compelling. However the contrived teacher union scenario is a big distraction for me as I was reading the article hoping that issue would be addressed and it wasn't. It would have been much stronger without this gaping logic hole introduced in the beginning.
Two things. First, it is really troubling if Apple wants to impose a tax on transactions between app users. Tipping is used often in China (for example, in the form of "red envelopes" at Chinese New Year) and a 30% cut for Apple is simply incomprehensible and downright immoral. Second, the day that WeChat gets out of the App Store is the day that Apple becomes irrelevant in China. If the story is true, I am afraid somebody at Apple has not thought this thing through.
Apple doesn't charge for person to person transfers, or buying physical goods. They only charge if you are selling digital products (apps, features, content) through the App Store. Just those things that cost Apple to store and transfer.
Do you really think WeChat pays Apple for the file transfers for hundreds of millions of copies of WeChat to customer iPhones every month (when you include updates). Essentially at least 100 Megabytes times 100 to 200 million a month.
It's entirely relevant. That 30% pays the costs of the app store, and bandwidth is probably the biggest cost of running the app store.
Please show me where Apple says the $99 I pay every year pays for their Sales, Marketing, Distribution and Operating costs of running the app store and getting me customers.
Yes, despite all the problems in C++ it's just a much better language than C for defining new types that are on par with "native types". std::vector has so many benefits over any possible C implementation that there is no real comparison. Genericity is one, no need to remember to free after use is another.
By the way, why is this C implementation something that requires C99 or C11 features? It looked just like standard old-fashioned ANSI C to me.
I like my C alternative better. I pass growth factors/increments as parameters to the vector macros so that I can affect how it grows on capacity exhaustion during each call and I have macros for creating and closing uninitialized gaps. C++ loses on many potential optimizations by insisting that its types always be in fully well-defined states except inside methods. Moreover the particular GNU implementation of the STL on Linux completely fails to turn certain vectors methods into memsets, memcpies and memmoves where it could, which pesimizes those particular ops by like two decimal orders of magnitude. The insistence on using new/delete based allocators instead of reallocs is a significant pessimization too. Reallocs perform, on average, several tens of percents better than new allocs followed by copies. An even more noticable pessimization is in the compilation times. Including `<vector>` adds good chunks of a second to the build time of an average-length translation unit. In comparison, working with C, even with all my generics included, on top of a good build system makes me feel as if I was working with a scripting language. No lags.
These are fair points and issues like these are why many larger projects have their own custom vector-like classes. One thing I did want to call attention to is your point that C++ best practices require that objects be in well-defined states except inside methods. That's true, although it's not a language requirement, but in many cases you can get the best of both worlds through the use of lambdas. A simple example to give the flavor:
template <typename Function>
void my_vector::munge(Function initialize_gap) {
create_uninitialized_gap();
// Some of our elements now contain uninitialized memory.
// We don't want to expose this to arbitrary code, but
// it's OK to expose this to the function the user
// provided specifically to handle this.
initialize_gap(gap_begin(), gap_end());
// The gap is now initialized, so when we return from
// this method, we'll be in a well-defined state.
}
This is the standard pattern you use for such things in functional languages, and it works very well. The idea is to ensure that intermediate states are only seen by code that explicitly expects to handle them.
Your criticisms of vector are well put, but if anything they're all really problems with a particular implementation of the standard library, not the C++ language. If you make your own libraries you're free to do whatever you want, and template metaprogramming can help you gain even more performance by easily using optimized implementations for specific types, etc.
Are you referring to https://github.com/kahole/edamagit ?