NYCPHP Meetup

[Jeff Slutz]

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
jeff at jeffslutz.com


On Thu, Feb 13, 2014 at 7:43 PM, Gary A. Mort <garyamort at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20140214/4bfdfed5/attachment.html>