Re: ocaml - how can we get more recent version of core-kernel and common ppx'es
Great, this is exactly what I was hoping to find! I had of course forgotten to search the debbugs and in the devel mailing list there were only really old threads about the 4.07 stuff. Thanks for your work here, I will test your patches and let you know :) Sent from my iPhone > On 18 May 2021, at 22:38, pukkamustard wrote: > > Hi Erik, > > There has been some work towards updating the OCaml packages in Guix (see > https://issues.guix.gnu.org/47768). > > A lot of packages have been updated so that there is a now an updated ocaml-X > package for a previously existing ocaml4.07-X package. This includes a lot of > ppx'es. However not everything has been updated yet and there are still a few > packages missing to be able to update ocaml-core-kernel. But maybe you could > use the #47768 as a basis and update some packages towards ocaml-core-kernel? > > Help is also required in reviewing the patches. The series has become quite > large and hard to review (42 patches). If you could try them out that would > be great. > > -pukkamustard > > > Erik writes: > >> Hi, I have a project that requires a more recent core-kernel and some of the >> ppx'es (such as ppx_fields_conv). >> >> Being very new to guix I've managed to add/update packages for python and >> ruby >> stuff, but this ocaml.scm file is quite different. There's a lot going on >> which >> I'm guessing is related to complexities arising from the whole ppx transition >> that happened in the ocaml ecosystem a few years ago, or perhaps just to the >> somewhat unsynchronized way libraries move to new versions of the compiler >> and >> libs (just speculating here). >> >> Anyway afaict (with my limited guix-fu) I would either need to duplicate a >> whole >> lot of packages or somehow reorganize things to share definitions where it >> makes >> sense. Both those options would require some coordination with the people who >> made the ocaml.scm infrastructure first, because clearly there are projects >> out >> there that need the current set of packages to work like they do now and I >> don't >> want to just post a huge patch that surprises these people. >> >> Can we get a thread going somewhere on adding a recent version of >> ocaml-core-kernel (for the 4.11.1 ocaml package, possibly bumping that to >> 4.11.2 in the process)? >> >> Best regards, >> Erik Lovlie >
Re: What’s next?
Katherine Cox-Buday writes: Ludovic Courtès writes: BTW, another thing that’d be nice it to use Guile-Netlink to provide a more capable static-networking service. Thank you for the reminder! This is blocking me from standing up a few edge-routers. Also, more focus on aarch64-linux substitutes! We’re currently waiting for three new 16-core Honeycomb LX2 boards to arrive Berlin, which should help with aarch64-linux substitutes. -- Ricardo
Re: What’s next?
Ludovic Courtès writes: > BTW, another thing that’d be nice it to use Guile-Netlink to provide a > more capable static-networking service. Thank you for the reminder! This is blocking me from standing up a few edge-routers. Also, more focus on aarch64-linux substitutes! -- Katherine
Re: Scala package
Ludovic Courtès writes: >> I think the best way to bootstrap would be to reimplement Scala in > another language. I tried that too, but even the parser is crazy. Yes, the syntax is complex. Maybe even worse than C++ in terms of parsing. I abandoned scala awhile ago, but I saw that with its latest release, maybe some things got simplified. Maybe it's worth another look? > Could you share a link to that so everyone realizes just how far you > went? :-) Before I outright abandoned the language, I was looking into bootstrapping this too. I did not go nearly as far, but was strongly dissuaded by core scala contributers from even trying (to be fair, they probably don't hold bootstrapping in high regard as we do). The only thought I have to contribute is: would it be possible to bootstrap off of a binary seed, and then do what's possible to grow that down to prior versions as much as possible? It's a compromise, but it at least gets Guix into the scala ecosystem and provides scaffolding to work off of. Of course this might run contrary to Guix's goals/needs. -- Katherine
Re: Bringing substitutes from the Guix Build Coordinator to users
Mathieu Othacehe writes: > Hey Chris, > >> That sounds sensible. On the specific name, given this is just about >> substitutes, and at least in my opinion has nothing to do with >> continuous integration, maybe picking just another word would avoid >> thinking too much, it could be bordeaux, or hippo, or anything >> really. As you say, stability and not being tied to a particular machine >> is the important thing. > > The substitutes coverage is one indicator to take into account but there > are many others. For instance, the evaluation speed, the failed > evaluation count, the average evaluation builds completion time, the > availability of the connected build machines between other things. Indeed, and I'm aware that the Guix Data Service, which performs a similar function to the evaluations in Cuirass, is much slower. > Deploying a solution that builds substitutes is fine, but as soon as it > is deployed and accessible to all Guix users, the system administrators > will have to monitor it and maintain it in the long run. > > Having two heterogeneous build infrastructures on two sets of machines, > providing different metrics will make the update and maintenance of > those machines harder. > > I hear your point about K-out-of-N policy and it also makes sense to > me. However, we should maybe consider doing it using two similar > infrastructures. Indeed. The reality though is that two different approaches have been in development now for a little over a year, and this is a reflection of that. signature.asc Description: PGP signature
Re: Bringing substitutes from the Guix Build Coordinator to users
Hey Chris, > That sounds sensible. On the specific name, given this is just about > substitutes, and at least in my opinion has nothing to do with > continuous integration, maybe picking just another word would avoid > thinking too much, it could be bordeaux, or hippo, or anything > really. As you say, stability and not being tied to a particular machine > is the important thing. The substitutes coverage is one indicator to take into account but there are many others. For instance, the evaluation speed, the failed evaluation count, the average evaluation builds completion time, the availability of the connected build machines between other things. Deploying a solution that builds substitutes is fine, but as soon as it is deployed and accessible to all Guix users, the system administrators will have to monitor it and maintain it in the long run. Having two heterogeneous build infrastructures on two sets of machines, providing different metrics will make the update and maintenance of those machines harder. I hear your point about K-out-of-N policy and it also makes sense to me. However, we should maybe consider doing it using two similar infrastructures. Thanks, Mathieu
