Can you take a quick look at this with the added UI changes?
Update unarchive, add code to daemon console to use this new data.
Tue, Feb 19
The "whitespace added" side of your screenshot looks a little weird. It would be nice to give the chevron the same amount of green background padding on both sides.
Sat, Feb 16
Fri, Feb 15
Can't wait for unit tests like
This is clearly the smallest possible change that fixes PHI810, but what would be cooler would be detecting "this revision is unapprovable because of the combination of current away statuses and review requirements" so we only show this message when it's definitely a problem. Don't we have most of that code server-side already for deciding when a revision has reached the "approved" status?
Thu, Feb 14
Wed, Feb 13
Tue, Feb 12
new PhutilURI('/x/?y=1', array('y' => 2));
Mon, Feb 11
Do you have an example of phlog() misbehaving on arrays? I get tailored behavior in the simple case:
It has taken some soul searching on my part to be ok with the fact that interleavings of appendQueryParam() and setQueryParam() are effectively changing the "type" of the key in question. I can't decide if it would make sense to change the code to do something like "if you're doing a set and you find some duplicate key names that you're going to blow away, decide that now is a good time to go through the rest of the params and blow away all the other dupes, except for the first one of each". That's probably even even more confusing though. Maybe the class could have a variable that can only be set on construction called $duplicate_keys_allowed or something, that would make append throw on duplicate key names? This is all probably overthinking things and the current implementation is fine, even though it doesn't feel like it's totally eliminating surprises.
This is much better than having to tab over to the terminal where my nginx logs are scrolling when I'm fixing a fatal!
Instead, it will return 'x' => '2'. That is, it has lost the PHP-specific notion of what x=1&x=2 means.
Does it make any sense to change phutil_build_http_querystring to implement this this "if it's an object or an array, turn it into a JSON string" behavior?
This load chart for admin001, where steady state CPU load has dropped from ~20% to ~10%, suggests that the new scheme is legitimately more efficient and the deploy actually changed something:
Sun, Feb 10
Fri, Feb 8
Is there some other abuse vector here I'm not aware of?
Wasn't there supposed to be an icon getting upstreamed in this revision? I can see the change to the celerity map but not the associated icon file.
Unrelated to this diff, but we rate limit users attempting to add new payment methods, right?