[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nyphp-talk
Subject:    Re: [nyphp-talk] Anyone play with HHVM?
From:       Jeff Slutz <jeff () jeffslutz ! com>
Date:       2014-02-14 16:23:56
Message-ID: CAOjZntvqBB1+BawEbTv2ryY_YYWNjqoc0dEHzKvXkUcs52tyPA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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@jeffslutz.com


On Thu, Feb 13, 2014 at 7:43 PM, Gary A. Mort <garyamort@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
>

[Attachment #5 (text/html)]

<div dir="ltr"><div>I&#39;ve been curious about HHVM but haven&#39;t had time to play \
with it yet.<br><br>Thanks for sharing your experiences around Travis CI and HHVM, \
very helpful.<br><br></div>JS<br></div><div class="gmail_extra"> <br \
clear="all"><div><div dir="ltr"><div>--<br>Jeff Slutz <br>JSLEUTH LLC<br></div><div \
style="color:rgb(34,34,34);font-family:arial;font-size:small;font-style:normal;font-va \
riant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:st \
art;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)">
 2105 N Fork Drive</div><div \
style="color:rgb(34,34,34);font-family:arial;font-size:small;font-style:normal;font-va \
riant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:st \
art;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)">
 Lafayette, CO 80026</div><div><div>c. 970.443.9390<br><a \
href="mailto:jeff@jeffslutz.com" \
target="_blank">jeff@jeffslutz.com</a></div></div></div></div> <br><br><div \
class="gmail_quote">On Thu, Feb 13, 2014 at 7:43 PM, Gary A. Mort <span \
dir="ltr">&lt;<a href="mailto:garyamort@gmail.com" \
target="_blank">garyamort@gmail.com</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">

  

    
  
  <div text="#000000" bgcolor="#FFFFFF">
    I recently learned about Travis CI[in the past 6 months] which
    removed a large number of testing issues I&#39;ve faced in the
    past[PHPUnit has changed so much from version to version, that at
    times one PHP package&#39;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!]<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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:
    
    <a href="https://github.com/garyamort/joomla-framework/tree/hvmmaster/build/travis/scripts" \
target="_blank">https://github.com/garyamort/joomla-framework/tree/hvmmaster/build/travis/scripts</a><br>
  <br>
    I also had to heavily modify the travis configuration:<br>
    
    <a href="https://github.com/garyamort/joomla-framework/blob/hvmmaster/.travis.yml" \
target="_blank">https://github.com/garyamort/joomla-framework/blob/hvmmaster/.travis.yml</a><br>
  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 &quot;install&quot; 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.<br>
    <br>
    IE: your running a.sh, b.sh, and c.sh<br>
    a.sh finishes executing<br>
    b.sh and c.sh are still running<br>
    c.sh aborts with a vague error message<br>
    <br>
    Travis reports the error message as coming from b.sh and aborts the
    job.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    Even if you don&#39;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.<br>
    <br>
    It&#39;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
    &quot;broken&quot; gcc supported way - but if you use it in it&#39;s default
    config you can find all your &quot;broken but working&quot; code.<br>
    <br>
    Just curious if anyone has anything actually in production using
    hhvm?  Or even just playing around with it.<span class="HOEnZb"><font \
color="#888888"><br>  <br>
    -Gary<br>
  </font></span></div>

<br>_______________________________________________<br>
New York PHP User Group Community Talk Mailing List<br>
<a href="http://lists.nyphp.org/mailman/listinfo/talk" \
target="_blank">http://lists.nyphp.org/mailman/listinfo/talk</a><br> <br>
<a href="http://www.nyphp.org/show-participation" \
target="_blank">http://www.nyphp.org/show-participation</a><br></blockquote></div><br></div>




_______________________________________________
New York PHP User Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

http://www.nyphp.org/show-participation

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic