I personally use XXX all the time; but I tend to use it in places where perhaps ATTN or NOTE would be more explicit.
It may be simply an artifact of other code in the past; when I switched to vim ~10 years ago I noticed XXX was specifically highlighted along with FIXME and TODO and so I used it as a third option: here's something that doesn't need to be fixed, isn't really a todo, but you should read and understand.
Interestingly, I just did a quick check in vim to see which prefixes were highlighted and ATTN / HACK were not, but the usual suspects (BUG, FIXME, TODO, NOTE, XXX) were. I should probably use NOTE in most places that I currently use XXX...
Yep. Been a long requested feature. One of the reasons why the post states: "This feature also removes the last significant barrier to migrating legacy MySQL applications to PostgreSQL."
What do they mean by "legacy" in this context? INSERT ... ODKU is not a legacy feature of MySQL, it's a currently supported first-class feature of the database, nor is MySQL itself a "legacy" database.
I think they're referring to mysql. The sentence would have worked just as well without the word "legacy". I say this as someone who prefers PostgreSQL.
No, they are referring to an application that is being moved from MySQL to PostgreSQL. The application is "legacy" in that it is an older version and the new version is "current".
Due to the English language however there can be some debate as to what they meant. In this case "legacy" is most likely meant to describe the "MySQL application" not "MySQL" itself.
A meaning that adds something to a sentence is a more likely meaning than one that adds nothing to a sentence. If you take "legacy" to mean "being migrated from" then the sentence becomes
This feature also removes the last significant barrier to migrating being-migrated-from MySQL applications to PostgreSQL.
It's more likely that if "being migrated from" was the intended meaning, they would have simply left the word out.
Your comment assumes the author of the release notes has perfect command of the English language and they thought through in detail what the word "legacy" would mean in this context.
First, my comment says "more likely" so it isn't assuming anything.
Second, if we change "more likely" to "definitely", the assumption is merely that the sentence in question is written with the same command of the English language as the rest of the announcement, i.e. no egregiously redundant words.
That definition does not help the argument that "legacy application" is a more likely meaning than "legacy mysql". In the sentence in question, the application hasn't been migrated yet, so clearly it has not been superseded.
Replace MySQL with Django. Do you assume Django itself legacy, or the Django based application? I parse it correctly as "a legacy application that uses MySQL".
That's a good question, but it's hard for me to objectively say how I'd immediately parse that, due to the close examination I've given that sentence.
You definitely have a point, though. How the phrase "legacy X applications" is interpreted likely depends on whether the context is an announcement by a competitor to X.
Eh... unless there's more to the story that I'm missing out on, I don't think it's fair to say they "threw a tantrum".
Basically, that company has a service that lets developers do real-time collaboration. Like working on a Google Docs document... except that it's for code, and collaborators can all use whatever supported editors they like. When they went to add support for Vim, they ran into problems with the "real-time collaboration" part... because Vim is single-threaded and doesn't have a non-blocking event loop:
The Vim maintainers kept rejecting it, for different reasons each time. After two months of back-and-forth, the Floobits guys asked the Vim guys to either give a comprehensive list of things in the patch that need to be different... or else acknowledge that they simply don't want the event loop thingy merged at all, and that Floobits should move forward with their own fork of Vim instead:
Personally, I don't have an opinion one way or the other on the merits of that patch. However, I think the Floobits guys were justified in feeling frustrated about the Vim guys dragging their feet and not being completely forthcoming.
Either way, if you do some quick web searching, you'll notice that Floobits became pretty big fans and online promoters of NeoVim from that time forward! So much so that you kinda have to take it with a grain of salt.
I'm not exactly sure what to even think about NeoVim. They've been plugging away for over a year, their GitHub repo has over a hundred contributors and two-thousand commits, and yet it's still pre-alpha? Also, the primary purpose seems to be allowing people to write Vim plugins in any programming language. However, it's not like the Vim ecosystem is hurting for plugins today. Besides, the whole point of "vimscript" is that it's self-contained and baked-in as part of the editor. Totally cross-platform, and always there. If I install a NeoVim plugin, then I have to make sure I have the right version of Ruby or Python or whatever on my box to support it? Yuck, no thanks.
As near as I can tell, any real value-prop for NeoVim is using it as an embeddable component. Like the Cloud9 guys' cloud-based Ace editor (http://ace.c9.io), or as something that IDE makers could bake into their desktop IDE apps. I don't really see what's compelling about it head-to-head with standard Vim, assuming it ever fully ships.
You're the one whose bad patches were rejected, you just dug through a year's worth of my comment history, and you're constantly and heavily promoting a terrible-design-and-still-no-beta-even-after-a-year-and-a-lot-of-donated-money fork of someone else's open source project ...
Neovim will have Lua (and LuaJIT) baked-in too, so Lua will always be there.
In my opinion initially there might be many different languages used by developers as they try out the new versatile plugin infrastructure. But after a while only a few languages should emerge as the dominant ones, because developers have the desire to help as many people as they can by making their plugins easy to be deployed and configured. I would guess Vimscript and Lua(both baked in), Python(nowadays it's practically ubiquitous) are the more popular choices. Personally I like Go (fast, easy concurrency, and single executable deployment).
Though admittedly facts like whether they support source maps (such as Traceur) or preserve comments (not Traceur) are omitted. EJS is impressive though.
Where do you see that @transaction.atomic is deprecated? It's not in the release notes[1] and if I recall correctly, was only introduced in 1.6 as a means to come up with a consistent API for nested transactions and savepoints. Are you implying that it's deprecated as a decorator? Even if that's the case, I still can't find a source.
So, you can only bind to '0.0.0.0'? Which means, by default, you're opening up read/write to the specified directory without permissions, to the entire world?
Maybe the default should be 127.0.0.1; and if the user specifies 0.0.0.0 then it comes with a big fat warning?
Seems to me it's actually writing to the database twice for each page view; once to update the render_started_at property on #845, and once again on #881.
The homepage mentions you can use your account here to stream content to any device, including consoles. How does that work? Can we connect to it as a network file server?
It may be simply an artifact of other code in the past; when I switched to vim ~10 years ago I noticed XXX was specifically highlighted along with FIXME and TODO and so I used it as a third option: here's something that doesn't need to be fixed, isn't really a todo, but you should read and understand.
Interestingly, I just did a quick check in vim to see which prefixes were highlighted and ATTN / HACK were not, but the usual suspects (BUG, FIXME, TODO, NOTE, XXX) were. I should probably use NOTE in most places that I currently use XXX...