<div dir="ltr">Including ppx-rewriters in the distribution would be the wrong resolution, I think. The modularity afforded by the current world is worth a lot, letting independent sets of people to work on different pieces of the infrastructure, and making the work of the core team as simple as possible. I think the core team should be loathe to give this up.<div><br></div><div>Having some kind of compatibility story that most PPXs could use which would make PPXs compatible across compiler versions could help a great deal, though. Maybe that's where the effort can be best spent. Such a thing could even be done outside of the core distribution, though it would have to be among the very first packages ported. Indeed, given that it would need to work with multiple compiler versions, it is perhaps best for it to be developed outside.</div><div><br></div><div>y</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 30, 2016 at 4:57 AM Fabrice Le Fessant <<a href="mailto:Fabrice.Le_fessant@inria.fr">Fabrice.Le_fessant@inria.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>If you look at the announce of opam-builder, you will notice that it was monitoring 4.03.0+beta1 from the beginning:</div><a href="http://lists.ocaml.org/pipermail/opam-devel/2016-March/001412.html" target="_blank">http://lists.ocaml.org/pipermail/opam-devel/2016-March/001412.html</a><br><div><br></div><div><div style="line-height:15.6px">4.03.0+beta2 was monitored too, as soon as it was released.</div></div><div style="line-height:15.6px"><br></div><div style="line-height:15.6px">But indeed, opam-builder's website is far from perfection, it could be faster to load, send notifications by email, recognize and display error messages (and much more, as the information sleeping there is huge...). We will try to improve it when we have time, but for now, it is on our spare-time list of projects.</div><div style="line-height:15.6px"><br></div><div style="line-height:15.6px">I agree with Yaron that PPX are more and more going to become a problem for upgrading to the latest OCaml, as Camlp4 was before (and is still, unfortunately). Many packages now depend on ppx-rewriters, that will almost never be in sync with trunk, which makes testing trunk very hard, even if we patch OPAM not to use the upper-bounds on ocaml-version in package descriptions. Soon, OCaml users will probably ask us to merge some ppx-rewriters in the OCaml distribution to force the sync, as they asked for Camlp4 long ago.</div></div><div dir="ltr"><div style="line-height:15.6px"><br></div><div style="line-height:15.6px">--Fabrice</div><div style="line-height:15.6px"><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 30, 2016 at 9:19 AM Alain Frisch <<a href="mailto:alain.frisch@lexifi.com" target="_blank">alain.frisch@lexifi.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 30/06/2016 03:56, Alain Frisch wrote:<br>
> OCamlPro's opam builder (<br>
> <a href="http://opam.ocamlpro.com/builder/html/report-last.html" rel="noreferrer" target="_blank">http://opam.ocamlpro.com/builder/html/report-last.html</a> ) really needs to<br>
> be more advertised and its UI a bit polished to encourage people to<br>
> actually look at it.  Also a report per maintainer (with emails sent<br>
> automatically?) could be useful.<br>
<br>
Here is some wishlist for this tool:<br>
<br>
  - Add trunk testing: this is what will put pressure for people to<br>
continuously upgrade their packages.  Ideally, it would also show the<br>
(date of the) latest successful build on trunk.  Same for release<br>
branches once they are forked.<br>
<br>
  - Make the grid more narrow to fit more versions on a screen (e.g.<br>
abbreviate Broken Deps to "Deps") and show more recent versions<br>
(including trunk) to the left.<br>
<br>
  - By default, show only the latest version of each package.<br>
<br>
  - Add a mode where packages are grouped by maintainer.<br>
<br>
  - Try to make the errors more visible.  E.g. for<br>
<a href="http://opam.ocamlpro.com/builder/html/github/github.1.0.0/3b48ac1bc360931d68afa4e126d96b44" rel="noreferrer" target="_blank">http://opam.ocamlpro.com/builder/html/github/github.1.0.0/3b48ac1bc360931d68afa4e126d96b44</a>,<br>
the section "=== ERROR while compiling github.1.0.0 ==" could be moved<br>
to the top of the screen.<br>
<br>
   - There could also be heuristics to detect the error and show<br>
directly in the main report grid the category. For instance,<br>
<a href="http://opam.ocamlpro.com/builder/html/acgtk/acgtk.1.0b/764d15d569e342c5ee761551e398fb38" rel="noreferrer" target="_blank">http://opam.ocamlpro.com/builder/html/acgtk/acgtk.1.0b/764d15d569e342c5ee761551e398fb38</a><br>
is simply about a new warning and "-warn-error A" in the package.<br>
<br>
  - It would be useful to force building package even if they claim they<br>
are not compatible with the latest version (or trunk).  For instance, I<br>
was curious about why ocamlnet.4.0.4 did not build with 4.03.  (In case<br>
people wonder, the first problem comes from the new error on multiple<br>
definitions of exceptions with the same name; this error was introduced<br>
on trunk in 2014 IIRC.  The fix for ocamlnet is just to remove one line.)<br>
<br>
<br>
Alain<br>
_______________________________________________<br>
Platform mailing list<br>
<a href="mailto:Platform@lists.ocaml.org" target="_blank">Platform@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/platform" rel="noreferrer" target="_blank">http://lists.ocaml.org/listinfo/platform</a><br>
</blockquote></div>
_______________________________________________<br>
Platform mailing list<br>
<a href="mailto:Platform@lists.ocaml.org" target="_blank">Platform@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/platform" rel="noreferrer" target="_blank">http://lists.ocaml.org/listinfo/platform</a><br>
</blockquote></div>