User Details
- User Since
- Jul 25 2013, 6:56 PM (690 w, 6 d)
- Availability
- Available
Aug 20 2020
For what it's worth, the only reason I was trying to figure out stuff with the built-in server was because at the time trying to get Phabricator running in Docker correctly was... not nearly as easy as I would have liked. Quickly skimming online suggests that's improved in the interim.
Feb 24 2017
Just a note for the above - the initial DB seed script will need to be updated accordingly as well. Right now, trying to perform a clean install on a 2nd-gen Google Cloud SQL instance (which has the above limitation) simply errors out when it reaches one of the tables coded as MyISAM.
Feb 24 2016
Implementation of what's described above - also seems to provide the expected results in my case, and limits impact to PHPUnit results. If a file is executed at all, it should show up normally; when completely untouched (which tends to show up with phpunit whitelisting, now necessary in the newest versions).
That seems totally reasonable. It seems like a bit of a stretch for PHP code specifically, but sane as a general-purpose answer.
Feb 23 2016
Jul 9 2014
Jul 2 2014
Jul 1 2014
Jun 19 2014
Thanks @chad :)
Jun 18 2014
Mar 25 2014
Mar 10 2014
I just ran into that one in practice today, so I'll probably take a crack at another grammar update to handle it in the next 48 hours or so.
Feb 5 2014
Found another issue with some array dereferencing: if ($state && !isset(self::getSearchStates()[$state])) { still fails. I'll look into that one a bit later - once I saw what the zend grammar was doing... ick.
Feb 4 2014
Update here - did spot one issue: (new Foo)->bar (added in 5.4) fails:
Jan 23 2014
Just as an update - so far all of the changes I've tested have been working really well for 5.4 source. The stock symbol generation script seems to not mind files with more modern grammar ($x = [];, trait, use, closures, etc), and the XHPAST linter seems ok too. As you'd expect we have a massive number of files in our codebase seeing that it started close to five years ago so naturally I haven't been able to run it on everything but I'm feeling pretty good about this :)
Jan 21 2014
This is incredible, thanks! Our devops team is going to comb through all of this and the reviews and see if we need to take a crack at anything else.
Jan 15 2014
Sounds good. We're trying to push everyone through the arc workflows for everything so if it's still a legitimate issue I should have an update pretty soon.
Jan 3 2014
Ok, --background 0 DID allow it to go through. I don't have the stack from SIGHUP as apparently she doesn't have the pcntl extension installed either (I can get it installed if necessary, although given that your first instinct was right I'm guessing it probably isn't...)
Jan 2 2014
Ah, gotcha. I just confirmed that the developer that reported the issue to me doesn't even have xdebug installed, so it's definitely not the listener. However I told her to grab me the next time it happens (it *was* originally being run completely normally), so I'll upload a new trace with the SIGHUP trick when I have one.
Super weird. On a new branch to reproduce the issue it submitted the diff just fine (although still hangs if I arc diff --recon --no-diff manually)
eric@eric-dev ~/wepay: cat /tmp/phabricator_backtrace_511
#0 /home/sites/dev/libphutil/src/error/PhutilErrorHandler.php(188): __phutil_signal_handler__(1)
#1 [internal function]: PhutilErrorHandler::handleError(2, 'stream_select()...', '/home/sites/dev...', 196, Array)
#2 /home/sites/dev/libphutil/src/channel/PhutilChannel.php(196): stream_select(Array, Array, Array, 1, 0)
#3 /home/sites/dev/libphutil/src/channel/PhutilChannel.php(99): PhutilChannel::waitForActivity(Array, Array, Array)
#4 /home/sites/dev/libphutil/src/channel/PhutilProtocolChannel.php(135): PhutilChannel::waitForAny(Array)
#5 /home/sites/dev/libphutil/src/console/PhutilConsole.php(215): PhutilProtocolChannel->waitForMessage()
#6 /home/sites/dev/libphutil/src/console/PhutilConsole.php(117): PhutilConsole->waitForMessage()
#7 /home/sites/dev/arcanist/src/workflow/ArcanistLintWorkflow.php(530): PhutilConsole->confirm('Apply this patc...', false)
#8 /home/sites/dev/arcanist/src/workflow/ArcanistDiffWorkflow.php(1236): ArcanistLintWorkflow->run()
#9 /home/sites/dev/arcanist/src/workflow/ArcanistDiffWorkflow.php(1197): ArcanistDiffWorkflow->runLint()
#10 /home/sites/dev/arcanist/src/workflow/ArcanistDiffWorkflow.php(418): ArcanistDiffWorkflow->runLintUnit()
#11 /home/sites/dev/arcanist/scripts/arcanist.php(322): ArcanistDiffWorkflow->run()
#12 {main}I never explicitly set it up on my machine which exhibits the problem, but I thought I saw something for eclipse running on the machine we first spotted the problem from.
It does not (I assume you mean on the arc diff command, as arc lint --background 0 just errors out with an unrecognized option)
Oct 16 2013
Interesting. Someone on my team mentioned arc diff complaining about no content earlier, so he must have sent this one up by hand. I'd always wondered why sometimes I'd see "context not available" on diffs; I had figured it wasn't able to line something up cleanly with the previous revision/version in master/etc. Should either manually doing a git branch (as compared to arc feature) and/or pulling in changes from master daily have any impact on its use?