[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] sexplib v0.9.0 breakage of MirageOS unikernels (xen & solo5)



For the question of changing sexplib v0.9.0 to be dependency free
again; basically the reversing of dependencies happened quite a long
time ago and code has been written since then, so I don't know how
hard it would be to change things back in v0.9 and get all v0.9
packages working again. I'd have to look more into it.

At least, now that we can build all JS packages at once with jbuilder,
doing this would be so much easier :)

There is another solution that I think would be a lot simpler and
might be acceptable for you: the code that was imported from sexplib
into Base is near the roots of the DAG in Base. So what we could do is
extract this part into Base.0 and Sexplib itself would use only
Base.0. I don't think we use many of Base functionalities in Sexplib
yet so this shouldn't be too hard. Base.0 would have no C stubs.

In any case, before doing anything I'd like to know what are you plans
regarding sexpm. Daniel when do you think it will be ready? If you
plan to switch to it in the near future, I don't think it's worth
doing anything now in Base/Sexplib.




On Thu, Mar 23, 2017 at 1:54 PM, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
> On 23/03/2017 14:30, Anil Madhavapeddy wrote:
>> We could also ask the Sexplib maintainers if the Base dependency is a
>> hard one.  I'm CCing Jeremie Dimino -- is it possible to relax this for
>> Sexplib so that it can be as dependency-free as previous versions are?
>
> According to
> https://github.com/janestreet/ppx_inline_test/issues/7#issuecomment-288691669
> the motivation behind base was to use it in sexplib.  I doubt they want
> to revert this design decision.
>
>> I don't think a hard Base dependency is practical right now -- we do
>> need some time to evaluate it and to check how it interacts with LTO.
>> It is promising since it uses module aliases throughout, but we haven't
>> tested it at all in this regard.
>
> Agreed.
>
> From Jeremy on GitHub
> (https://github.com/ocaml/opam-repository/pull/8793#issuecomment-288721643
> -- no, I won't discuss on GitHub in random PRs (as explicitly written
> there) - because nobody will be able to follow the discussion or read it
> in aftermath)
>> In any case the C code in Base is trivial, it is of the same nature as
> the C code for the intXX modules for instance. So I assume they should
> be no problem in doing the same thing as what was done for bin_prot.
>
>
> While this may be true, it is another 5MB in binary size.  LTO was not
> merged into 4.05.  We can discuss depending on base again once MirageOS
> drops all non-LTO OCaml versions.
>
>
> I agree with Daniel Buenzli (use https://github.com/dbuenzli/sexpm once
> released, get rid of ppx converters -- which are usually more trouble
> than problems they solve).
>
>
> hannes



-- 
Jeremie

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.