<reynir>
Yes. It's a functor that you have to pass a whole lot of modules to, but I guess mirage magic can help/hide this. But the last module is basically passing the Stack.t and such so the IRC library can connect
<yomimono>
hm, maybe some discussion on mirageos-devel wouldn't go amiss for ideas on handling that
<yomimono>
(I am the last person to give good advice on avoiding ugly functors)
<yomimono>
reynir: the only thing that seems weird to me here is the T module, which seems to include only stuff you already get through other modules?
adrianl_ has joined #mirage
<reynir>
yomimono: Hmm, I thought you didn't get the Pclock.t value from the Pclock module
<reynir>
I think the Pclock.t value is passed to the Main.start function - maybe I missed something
<yomimono>
I trust your memory more than mine, but I agree that there should be a nicer way to do that
* yomimono
is still waiting for a git clone
<hannes>
oh hi!
<yomimono>
hi hannes!
<reynir>
Regarding my item on the list: I think it would make sense if you could generate a .merlin file from a given config.ml in mirage. Besides being convenient, I think it's not always clear what packages will be used for your unikernel. You can of course check the generated opam file, but it will often include more packages AFAIK
<reynir>
I can maybe attempt implementing this with some guidance ?
<hannes>
reynir: imho yes, mirage merlin (!?) should be able to generate a .merlin just from config.ml!
<hannes>
(there should imho as well be the possibility to generate a .ocamlinit from/after mirage configure -t YYY)
<yomimono>
reynir: Pclock includes Mirage_device.S which includes a type t
<yomimono>
also, I would like .merlin autogeneration :)
<hannes>
reynir: I believe the merlin generation should be a separate phase (or how you call it), next to build and configure
<reynir>
yomimono: Yes, it's a value of type t I'm missing - sorry, I was confusing
<hannes>
which means that at least functoria (and maybe mirage) will need some added functionality
<reynir>
Ah
* reynir
hasn't looked at the code at all (sorry)
<hannes>
I'm happy to answer questions about the bits and pieces i understand there, though it's designed and implemented by drup who may have more insights
<reynir>
What files would be a good place to start staring at? :)
<hannes>
in functoria, app/functoria_app and app/functoria_command_line ... you could follow on along the lines how the .opam is generated..
<reynir>
Thanks
<reynir>
Ok, I don't really have more to say about that right now. I will probably ping you and/or Drup later :)
adrianl_ has quit [Remote host closed the connection]
adrianl_ has joined #mirage
<yomimono>
thanks, reynir! :)
<yomimono>
nothing more on the agenda. anything else from anyone?
<yomimono>
(if not: reminder that the next MirageOS hack retreat will be in early October, and more details are available at retreat.mirage.io)
<hannes>
is anyone maintaining io-page?
<reynir>
Oh, I just noticed that mirage.io seems to be a bit broken - some js doesn't load. The layout looks a bit funky as a result
<yomimono>
hannes: I will have patches to it because of various hacking I'm doing in the Xen layer, so that question is relevant to me too :(
<reynir>
Oh, also some css (makes more sense)
<yomimono>
AFAICT the closest person to a maintainer is djs55 but I don't know whether his interest in that library is ongoing
adrianl_ has quit [Ping timeout: 256 seconds]
<yomimono>
reynir: hm, indeed!
<reynir>
xen hacking \o/
<yomimono>
reynir: yes, if you want to make unikernels that crash on boot, I'm your hookup
<hannes>
yomimono: the build system is in a sad state, I suspect... I _think_ it should instead use whatever bigstringaf etc. does -- define a single library, and C stubs, and then some hacks to get xen+freestanding cross-compilation going on (checkseum/digestif use the same hacks iirc)
<yomimono>
hannes: yes, I agree that the build system there needs some attention, it's quite the accretion of strange things at the moment
<hannes>
but I still fail to understand how this whole building and linking works, e.g. in bigstringaf... on a freestanding/xen target we should somehow _avoid_ the for-unix-compiled C-stubs (but I've not enough knowledge on how to do that properly)
<yomimono>
I think there are various features in dune which are supposed to solve this, but I don't understand them sufficiently to comment further
<yomimono>
I only barely understand how the existing processes work
<yomimono>
(although I do understand that well enough to document it at this point, I think, and perhaps that's worth doing)
<hannes>
I'm close to installing my very first author-signed package \o/ (sorry, not very much MirageOS related)
<reynir>
yomimono: what repos should I check out for crash-on-boot unikernels? :)
<reynir>
hannes: \o/ \o/ \o/
<yomimono>
hannes: but awesome!
<yomimono>
reynir: if you're really interested I can give you a set of ~10 pins
<yomimono>
and then you can experience the joy of seeing a PVH unikernel spew a bunch of debug output and then immediately crash before launching your application
<hannes>
yomimono: while I understand what mirage - the command-line utility - is doing in respect to linking, I fail to understand how ocamlbuild/ocamlfind/dune play in here...
<yomimono>
hannes: ah, sorry, thought you were talking about library/flag handling here, which there is supposed to be some help for in the form of variants somehow
<reynir>
yomimono: I don't think I'll have too much time to hack on it, but if it's not too much trouble I'd like to check it out!
<hannes>
yomimono: yes, that's what is done... using these ocamlbuild/ocamlfind flags "xen_linkopts" / "freestanding_linkopts", plus some pkg-config magic to retrieve a ld, and some additional ldflags...
<yomimono>
reynir: I'll push my WIPs and send you an `opam pin` list
<hannes>
but what I'm missing is whether "normal" stubs are embedded into cm(x?)a(s?) / how linking works out on unix with ocaml
<hannes>
with the rise of opam2, we should also rethink the pkg-config stuff we accumulated, and maybe have switch-specific variables!?
<hannes>
but maybe that is a topic for a different call..