I've been curious about HHVM but haven't had time to play with it yet. Thanks for sharing your experiences around Travis CI and HHVM, very helpful.
JS -- Jeff Slutz JSLEUTH LLC 2105 N Fork Drive Lafayette, CO 80026 c. 970.443.9390 j...@jeffslutz.com On Thu, Feb 13, 2014 at 7:43 PM, Gary A. Mort <garyam...@gmail.com> wrote: > I recently learned about Travis CI[in the past 6 months] which removed a > large number of testing issues I've faced in the past[PHPUnit has changed > so much from version to version, that at times one PHP package's tests > require a specific downlevel PHPUnit to run, while another required a > different downlevel PHPUnit...leading me to frustration when working on > both at the same time!] > > With the combination of Composer, Github, and Travis CI - I can set it up > to install a specific version of PHPUnit and whenever I push a commit, > Travis runs the tests for me....much easier. > > So when Travis CI added support for selecting HHVM as a PHP Version I was > curious on how it compared to regular PHP. Grabbing my favorite PHP > framework[Joomla] I created a new branch and added hhvm as a PHP version. > > The biggest problem I ran into was that the current hhvm release is very > downlevel on features which caused a lot problems in the unit tests[a lot > of Image processing tests blew up]. Fortunately, Facebook maintains an > apt installable copy of hhvm-nightly, so with some extra build scripts I > was able to set up some conditional apt-get scripts to make sure > hhvm-nightly is installed: > https://github.com/garyamort/joomla-framework/tree/hvmmaster/build/travis/scripts > > I also had to heavily modify the travis configuration: > https://github.com/garyamort/joomla-framework/blob/hvmmaster/.travis.yml > I learned that with travis, many of the commands for each > stage[before_install, install, before_script, and script] are at the same > time. So if your running 3 scripts for the "install" stage, they run at > the same time, but if/when one of them fails the error is reported as being > from the script started first and still running. > > IE: your running a.sh, b.sh, and c.sh > a.sh finishes executing > b.sh and c.sh are still running > c.sh aborts with a vague error message > > Travis reports the error message as coming from b.sh and aborts the job. > > Plus if c.sh depends on something b.sh is configuring, it will fail. So > careful placement of scripts to ensure that they finish in the correct > sequence is important. > > There were a few interoperability problems between Composer and > hhvm-nightly when it came to how the version string was formatted - I > reported it to both groups and the facebook team were very quick about > reaching out to the Composer dev to find out what version string format he > preferred and then they updated their build process to produce it. > > With all the major issues taken care of, it was just a process of fixing a > handful of little incompatibilities to get the test to run. > > In the end, I found it rather impressive that hhvm took about half the > time to execute. Generally it took PHP almost 6 minutes to run all the > unit tests. HHVM was able to run them in under 3 minutes. > > Even if you don't plan on using hhvm for production - adding it to your > unit testing is very beneficial. Most of the changes I had to make in > order to get the unit tests to run were not differing published > features[the string access as an array thing for example] - but instead > they were broken/undocumented features in PHP 5.3/5.4. For example, PHP > has some VERY strange ways of handling using private methods for > autoloaders. Because the documented autoload features specify that you > must use public methods for autoloaders, HHVM adhered to the spec and thus > would break there. > > It's somewhat like how you can use Clang to compile your C code to find > all the bad coding practices which directly contradict the C standards but > work anyway if you compile your code with GCC. Clang has added a bunch of > flags to allow code to be compiled in the "broken" gcc supported way - but > if you use it in it's default config you can find all your "broken but > working" code. > > Just curious if anyone has anything actually in production using hhvm? Or > even just playing around with it. > > -Gary > > _______________________________________________ > New York PHP User Group Community Talk Mailing List > http://lists.nyphp.org/mailman/listinfo/talk > > http://www.nyphp.org/show-participation >
_______________________________________________ New York PHP User Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/show-participation
