thanks, fixing.

This may actually be not-too-terrible. I think there's a good chance that db005 really does have less than 22% of a volume of "actual" data, since the compressed size of backups for all active instances on the shard is only about 300MB. We had a bunch of heavy test instance churn on that shard for whatever reason.

I'm going to do this tonight/tomorrow, but this is going to be fairly involved. Current utilization is:

Works for me on the iPad Pro. Thank you!

Sorry to necro an old thread, but I, too, am looking for information about this particular API method.

what the heck

Yeah, I checked before writing that last post, and I thought the same thing, but it's not split up the way we want. e.g.

Maybe clang-format could be changed to give an output that's properly "split up" -- I don't know how feasible it would be, but given how fiddly it is (the whole tool is a collection of special cases), I expect that would be Hard.

I think the piece of information that differs between your model and the actual behavior of arc is that the linter does not (and must not) emit three separate corrections to fix foo(a, b, ...) one line at a time. It should emit a single correction for the entire block.

Seems OK for me on a physical iPhone 4s.

This is live on this server (secure.phabricator.com) -- let us know if you're still seeing issues. Seems OK for me on a physical iPhone 4s.

This is now deployed to this server (secure.phabricator.com) -- let me know if you're still seeing issues? Behavior seems OK in the simulator and with my physical iPhone 4s, but I don't have a fancy physical 6s to test.

Specifically, this is my best guess at what's going on:

Yep and to be honest this huge iPad is fairly desktop-y. The first time I saw it I kind of had to look twice to make sure it wasn't some run away item from Alice in Wonderland that had snuck into my reality.

I've marked D15135 as fixing this out of a general abundance of sunny optimism.

I think D15135 actually fixes this. I can't reproduce it in iOS Simulator after applying that patch.

D15136 distinguishes between "touch-device" mouseovers and "mouse-device" mouseovers rather than relying on device detection, since the screen resolution of the iPad Pro is apparently a billion pixels by a trillion pixels and device detection is clearly increasingly hopeless.

I gave this solution a quick whirl and it works. It preserves mouse over behaviour in regular browsers, and removes the need for double tapping in iOS (while still getting the selection highlights). Let me know if you'd like a patch or if you prefer your device detection approach.

Yeah. On a pure touch device, mouseover is not the most useful event to listen for when it comes to highlighting rows.

Nice work! I arrived at the same conclusion shortly after you did.

I have found the bug. For iOS Safari to send a click event, the handlers of mouseover and mousemove must not change the document content. (Presumably to allow a touch user to reveal things that require mousing over, without actually clicking things.)

I can reproduce this on my iPhone 4s which correctly selects 1-up mode, so I agree that this is probably not a duplicate of T9969.

Okay I don't think it's related to the 1up vs 2up renderer. Reading the source code I found out that the "1up" renderer seems to be triggered for certain screen widths. So I used an iOS Split View to reduce the width of my browser until it was fairly narrow, and as result I got a unified diff instead, which I believe is the "1up" view.

(Oh, there's a missing comma after e in some of the output above, but that's just because I typed the replacement text for the patch wrong in my "linter".)

Here's what I did:

I got the same issue. Fixed it by manually updating the database entry for the ui.custom-header file.

Not sure what the "1-up renderer" is but if it's 1 vs 2 columns, that's not the problem really. The formatting of the diff is fine (it's a large, desktop size screen).

@epriestley this is already a vast improvement, thanx for {D15093}.

"View Raw" is our solution to the problem you describe. It allows you to review the Remarkup in any comment and paste wherever you like. "Edit" is only available to the comment owner.

Unless I'm overlooking something, view raw leads to the same workflow as edit: still need to select and paste into comment box

View Raw

I haven't tried to write this rule, and you've almost convinced me to try, but -- forgive me -- I don't quite believe it's possible to do this correctly (or, as correctly as clang-format) in the context of formatting C++.

(Where "XYZ" and "QWERTY" can be arbitrarily long sequences and may each contain zero or more newlines, and may each be of arbitrary length -- you can replace a single character with a huge block, or vice versa, etc. -- lint is not line-oriented internally.)

The expectation is that this will just work properly already. We have a number of similar rules in the upstream.

Thank you for your quick response.

Should the user be warned that invisible files are still attached when they remove them?

• Emit messages for every line with a problem.
• If you raise them at "warning" severity, they will only be shown if the user modified the line.

In T10233#155967, @chad wrote:

Well it was mandatory.

This is intentional. The file is visible in the UI in the edit history of the comment, and still part of the object in that sense.

For now I've modified my local copy of this file and did few changes like:

I think we can do the background drag thing too, that shouldn't interact poorly with anything else (I think? Probably?).

We're probably going to do per column scrolling, or at least see how it feels in testing. Will have to see where we end up.

In a semi-related topic, I find myself constantly expecting Trello-style behavior where a user can click + drag outside of cards to scroll vertically/horizontally.

i totally agree we need a time tracking in phabricator

You can't edit the revision history; However, only the latest diff is "active" - that's what shown in the UI, and those are the changes that will be committed when you arc land.

Which la what I tried to do but i was not able to replace the wrong one both the revisions are there :(

bin/host destroy exists now and no one has specifically asked for this, so I think it's OK to leave it as an "email us" option until the workload justifies making it explicit.

I've implemented this and relieved pressure on db005, although see followup in T10236.

Chad, thanks a lot for your help. I will check out the install script.

I did read that Oracle Linux is essentially RHEL, so maybe our install script will provide some additional insight. https://github.com/phacility/phabricator/blob/master/scripts/install/install_rhel-derivs.sh

I've never heard of anyone having similar issues. My guess is something is wrong, mis-compiled, or misconfigured at the PHP / OS level and we're not going to be able to help you figure that one out. In general, our expectation is Phabricator will be installed on a normal computer, and one that a user has normal (admin) rights to.

ds fd fddgfdhgh

Please find the command i ran an the output i got. it doesn't show all config variables as you said.