It's pretty big deal for us because we are using phriction to collect helpdesk FAQ. We have modified TOC to be displayed in the beginning of the page and would like to use ponder are storing questions. Atm using ponder links in phriction as headings also shows toc values as X.

Fixed by D17188.

Presuming this was resolved by D16967, let me know if there was more to be done.

T11744 has a vaguely-related special case where "split + count" was unreasonably slow for very large inputs.

@HarryOtto, your message is off topic in this thread and is so tenuously related to anything here that it looks like it might be SEO linkbuilding spam, so I've removed it.

Looks like we use the function to mean "codepoints" in some places in phabricator/.

In the short term, I'll accept a patch to do this if you want to test it?

T9640 and T2383 are somewhat related.

Changes associated with T11592 probably fix this in practice. The new behavior is transparent: subprocesses get SIGTERM at the timeout, and SIGKILL a little while later if they fail to exit.

This doesn't seem to be doing anything bad in practice. I think you can put the data in the URI if you want too and it works fine. Not clear that this is wrong/invalid enough to completely prevent it, and hasn't moved forward in a year and a half or so.

Re-reading D9115, I think I was never able to understand or reproduce this and it was ultimately mooted anyway.

After D16333 there's still a tiny amount of unique spelling correction code in Arcanist, but it's just calling into libphutil and part of code duplication which would be better resolved elsewhere (like T7487).

After the introduction of PhutilHTTPEngineExtension (T10227) we have a more viable pathway to bring support for this upstream, but I'd still like to see more interest in it before thinking about upstream support. It looks like only 1-2 installs would use it, today (not sure if both of you represent the same install or not).

I just ran into the issue with this error on Windows:
Usage Exception: arc diff` is only supported under git, hg, svn.`

From T10610, this can reasonably occur in arc unit subprocesses.

Well, apparently I chose another base than I intended, making the diff huge indeed. The 16554943 lines were correct, thanks for the pointer there. I think this issue can be closed.

how many lines would you say the diff is? is it reviewable?

Thanks for your response. I just tried php 5.6:

Can you try php 5, we don't support php 7 at this time. These also sound like Windows errors, not sure what we can do about them.

Thanks for the report! This should be fixed in HEAD of master, and will promote to stable in about 48 hours. Let us know if you're still seeing issues after updating or if you run into anything else.

Yes, the problem is also mentioned there, thank you. I wasn't able to find it somehow.

This is probably a variant on T4551.

I'd also very much welcome an option to turn off colors, since they don't work very well in the Emacs shell.

This looks like a known issue with implementors using NSS instead of OpenSSL. Here's the Red Hat bug:

I'm using CentOS 6.7. I could reproduce the problem on 3 centos servers.
Debian seems to work fine.

What system are you on that doesn't support this cipher?

Minor tangential discussion in T5297, too.

For me, the big advantage to using IAM roles is that the credentials rotate automatically, every hour.

I've realigned this around support for IAM Roles, because we now use a first-party client after D14982.

(The case for doing this is weaker if it isn't for IAM Roles, but the S3.php thing doesn't support signature v4 (which AWS now requires in some regions) and the official SDK doesn't support older PHP, and having a first-party, future-based client will perhaps makes things easier eventually with T5544.)

I think there are two different issues with IAM.

I tink at least some of this was added in, e.g., D14231.

I'm just going to close this because it doesn't identify any specific problems and I don't want to build these things to deal with hypothetical problems.

We haven't seen other installs encounter difficulty here. T5055 will eventually build some flavor of first-party package manager which should address a large superset of this problem class.

D14523 possibly describes a cleaner fix for this (special case autoloads when class_exists() is on the stack).

No upstream use case in years.

ssh git@<our_server> "git-upload-pack 'repo.git'"

• git-upload-pack is the server-side part of the git fetch/git pull transfer protocol.
• 'repo.git' should look like diffusion/CALLSIGN/name.git; Is that right?

I'm not sure why our workaround for this in rPHUe9fea5c64c0c wouldn't work for you, but it seems to work for other people so I'm going to chalk this up to something else in your environment until we see more reports.

Right .. with 7.42.1 it's now OK.

You have a version of cURL which has a bug with Content-Length (see T8654 for discussion), but your version of libphutil should include a workaround, so I'm not sure what's up. I can't reproduce this problem on this server.