<yomimono>
while i'm still not confident that there's a bug in anything other than my patches to mirage, the behavior of if_impl seems unambiguously surprising here
<yomimono>
drup: aha. method name is the same for ipv4_qubes_conf and ipv4_dhcp_conf, which seems likely to break things after looking at functoria_app
yomimono has quit [Ping timeout: 244 seconds]
yomimono has joined #mirage
noddy has quit [Quit: WeeChat 1.6]
noddy has joined #mirage
<Drup>
huuum
<Drup>
Everything should be done by hash, so that's definitly a bug
<yomimono>
giving them unique names did indeed result in less baffling behavior
<yomimono>
I'd probably go so far as to say it fixed the problem, if I were a more confident sort
rgrinberg has quit [Remote host closed the connection]
rgrinberg has joined #mirage
andreas23 has joined #mirage
rgrinberg has quit [Ping timeout: 268 seconds]
yomimono has quit [Ping timeout: 244 seconds]
jermar has joined #mirage
jermar has quit [Ping timeout: 256 seconds]
andreas23 has quit [Quit: Leaving.]
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
fgimenez has left #mirage [#mirage]
fgimenez_ has joined #mirage
fgimenez_ has quit [Remote host closed the connection]
fgimenez has joined #mirage
andreas23 has joined #mirage
AltGr has joined #mirage
calculemus has quit [Ping timeout: 245 seconds]
calculemus has joined #mirage
gjaldon has joined #mirage
fgimenez has quit [Ping timeout: 252 seconds]
fgimenez has joined #mirage
jermar has joined #mirage
jermar has quit [Remote host closed the connection]
<hannes>
morning!
mort___ has joined #mirage
<gjaldon>
hannes: morning! btw, I've been working on mirage dashboard https://github.com/gjaldon/mirage_dashboard but progress is slow since I'm still getting familiar with the libraries I can use for web development in ocaml. What I have so far is just setup stuff.
<hannes>
nice! :)
<hannes>
any progress on the Canopy recent changes?
boadie_ has joined #mirage
boadie_ has quit [Client Quit]
boadie has quit [Ping timeout: 256 seconds]
fgimenez has quit [Ping timeout: 256 seconds]
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
jermar has joined #mirage
copy` has joined #mirage
<gjaldon>
hannes: about the Canopy recent changes, I just figured out how to read the contents of view. will work on it again later and may finish the HTML part, at least
<hannes>
:D
fgimenez has quit [Ping timeout: 265 seconds]
fgimenez has joined #mirage
fgimenez has quit [Changing host]
fgimenez has joined #mirage
mort___1 has joined #mirage
mort___2 has joined #mirage
mort___3 has joined #mirage
mort___4 has joined #mirage
mort___5 has joined #mirage
mort___4 has quit [Read error: Connection reset by peer]
mort___ has quit [Ping timeout: 240 seconds]
mort___ has joined #mirage
mort___4 has joined #mirage
mort___6 has joined #mirage
mort___5 has quit [Read error: Connection reset by peer]
mort___1 has quit [Ping timeout: 240 seconds]
mort___2 has quit [Ping timeout: 240 seconds]
aggelos_ has quit [Ping timeout: 245 seconds]
mort___1 has joined #mirage
mort___3 has quit [Ping timeout: 256 seconds]
mort___ has quit [Ping timeout: 260 seconds]
mort___4 has quit [Ping timeout: 245 seconds]
mort___6 has quit [Ping timeout: 240 seconds]
mort___ has joined #mirage
aggelos_ has joined #mirage
mort___1 has quit [Ping timeout: 240 seconds]
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
fgimenez has quit [Ping timeout: 258 seconds]
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
gjaldon has quit [Remote host closed the connection]
gjaldon has joined #mirage
gjaldon has quit [Remote host closed the connection]
gjaldon has joined #mirage
yomimono has joined #mirage
rgrinberg has joined #mirage
_longines has joined #mirage
fgimenez has quit [Ping timeout: 245 seconds]
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
mort___1 has joined #mirage
miragebot has joined #mirage
<miragebot>
mirage/master 8409e7f Hannes Mehnert: rename M_pp to M_util (there'll be more than pp)
<miragebot>
[mirage] yomimono pushed 4 new commits to master: https://git.io/vXPfV
<miragebot>
mirage/master cc82ae5 Hannes Mehnert: move CONSOLE.error out of module type
<miragebot>
mirage/master b49bd8f Hannes Mehnert: remove log, rename log_s to log
<miragebot>
mirage/master 9ef56b1 Hannes Mehnert: updates
<miragebot>
[mirage] yomimono pushed 2 new commits to master: https://git.io/vXPT4
miragebot has left #mirage [#mirage]
mort___ has joined #mirage
<hannes>
(I hope someone (@Drup?) can enlight me what mirage/lib/mirage_key.ml vs mirage/lib_runtime/mirage_runtime.mli ... they're looking so similar))
noddy has quit [Ping timeout: 252 seconds]
rgrinberg has quit [Remote host closed the connection]
<mato>
hannes: thank you very much for the help with the topkg/pkg-config mess!
<hannes>
mato: I was surprised to see _lots of discussion_ when it came to pathnames
<hannes>
esp. since there's no cross compilation, 32/64 bit stuff anywhere ongoing atm... feel like I'm in an overengineering department
<hannes>
but nevertheless, I'm happy with how you do it in mirage-solo5, and guess getting 669 in is easy
<mato>
well... I can understand the discussion since these decisions tend to stick and then come back to bite us
<mato>
however, there is no good solution for this one
<hannes>
I was curious about that one... the log_s was printing twice, once directly via write_one, the other time via print_string
<hannes>
the print_string never occured on the console since it was a buffer cached in the ocaml runtime, and never flushed...
rgrinberg has joined #mirage
<hannes>
but as of now, it is different, and only printed once \o/
<mato>
hah. yeah. that's probably left over from some early hacky incarnation of the solo5 console code.
<mato>
thx for spotting it.
<hannes>
I cleaned up that log vs log_s mess... but took me an hour to get the idea with the buffering :)
<hannes>
(and resulted in a happy hannes since re-thinking APIs and going through code leads to finding undetected problems :)
<mato>
indeed...
<hannes>
and regarding an earlier mailing list discussion, I completely agree to you that the xen side of mirage-xen-ocaml/mirage-xen-posix is a bit insane... and should be reverted
<hannes>
the solo5 backend is much nicer designed in my opinion (when it comes to opam packages) -- thx for this!
<mato>
the xen side should be ported to ocaml-freestanding, but someone needs to find the time and inclination to do it
<hannes>
I won't
<mato>
I won't in the short term, so hoping someone else does
yomimono has joined #mirage
<Drup>
hannes: mirage_key is configure time and linked by the mirage command line tool. mirage_runtime is linked by every unikernel
<hannes>
Drup: could you elaborate what the implication for code sharing is?
<Drup>
so, mirage_runtime is quite a lot smaller
<hannes>
Drup: I can see the mirage_runtime includes logs stuff, which is included in mirage_key.
<hannes>
but there is ip stuff in both of them. would it be worth to include the mirage_runtime also in mirage_key instead of rewriting it?
<Drup>
the "ip stuff" is quite a lot smaller in mirage_runtime, though
<Drup>
the log stuff was added a bit violently, I agree, it should probably be shared
<hannes>
the log stuff is shared
<hannes>
Drup: but so, I do understand it correctly that mirage_runtime can easily be completely included into mirage_key, and than there can be more stuff in mirage_key!?
<hannes>
(I, for example, didn't (even try to) understand the module_of constructs and whether this results in the same thing)
jermar has quit [Ping timeout: 268 seconds]
<Drup>
it's not the same thing
<hannes>
and mirage_runtime must include the stuff needed for passed boot parameters
<Drup>
mirage_runtime only include how to access printers and parsers
<Drup>
nothing else
<Drup>
it's basically name re-export
<hannes>
ok
<Drup>
(well, except the log stuff, but it really should be in the log library, not sure why it isn't
<Drup>
hannes: honestly, there used to be no code sharing, because there was no code to share at all
<hannes>
Drup: ok. I'd be much more happy with no code sharing
<Drup>
yeah, same here
<hannes>
the mirage.runtime should be an independent package (or distributed with mirage-types, whatever you like).
<Drup>
well, it depends on functoria.runtime
<hannes>
fine with me.
<Drup>
(which was carefully separated from functoria itself)
<hannes>
but the module Arg in both mirage_key and mirage_runtime look _very_ much the same
<Drup>
there is one crucial difference: the one in mirage_key has to deal with CSP
<Drup>
and that's the difficult job, really
<Drup>
most of the code is here to do that in a not-too-dirty way
<Drup>
the concepts are mirror in both implementations because, well, I need to mirror them to have similar features at configure and runtime
<Drup>
but other than that, Functoria_runtime.Arg is doing a lot lot less work than Functoria_key.Arg
<Drup>
(just look at the implementation ..)
<hannes>
Drup: this means when I want to support IPX addresses, I need to add converter code to both Mirage_key and Mirage_runtime!?
<Drup>
yeah
<Drup>
no way around that
<hannes>
Drup: and would you fight against making the .runtime explicit custom OPAM packages?
<Drup>
not really, no
<hannes>
(this "making" is, the code magically appears somewhere, I don't want to force you to do that)
<Drup>
It should stay in the same codebase, though
<hannes>
yes!
<hannes>
I'm at times in cleaning up mode, and this code might need some cleanups
<Drup>
I'm not sure about that, it does so little anyway ...
<hannes>
I'm mainly talking about the dependency introduced by the logging
<Drup>
yeah, I'm not sure it should be there
<hannes>
plus I do want to have some more convenience code in mirage.runtime which I currently put into mirage-types.runtime -- which I want to get rid of again
insitu has joined #mirage
gjaldon has quit [Remote host closed the connection]
andreas23 has quit [Quit: Leaving.]
noddy has joined #mirage
rgrinberg has quit [Remote host closed the connection]
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
<hannes>
Drup: as a matter of fact, atm functoria has a META requirement on functoria.runtime...
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
miragebot has joined #mirage
<miragebot>
mirage/master 4cb9d7b Hannes Mehnert: pkg_config_path is now both lib/pkgconfig and share/pkgconfig
<miragebot>
mirage/master 5d575bf Hannes Mehnert: Merge pull request #669 from hannesm/share...
miragebot has left #mirage [#mirage]
<miragebot>
[mirage] hannesm pushed 2 new commits to master: https://git.io/vXPwI
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andreas231 has joined #mirage
andreas23 has quit [Ping timeout: 256 seconds]
<hannes>
i don't understand the mirage-types failures in https://travis-ci.org/mirage/mirage/builds/175804619 (tls.mirage seems to be missing)... sth is messed up and tls is likely built without mirage support...
<mato>
might be some transient failure, i had a meaningless one on mirage-solo5#15, went away after i restarted the build
<mato>
i.e. if in doubt, kick travis and try again :)
<hannes>
mato: I guess the solo5#15 and mirage-dev#211 are good to go now
<mato>
hannes: yeah, just give me a few more mins to test against a fresh switch
<hannes>
the failures happen on the mirage repo when package name is mirage-types, the mirage ones all are fine...
<mato>
hannes: hmm. actually, there *is* something wrong with tls. just trying static_website_tls on a fresh switch and it failed, with not much to go on
<mato>
[ERROR] The compilation of tls failed at "./configure --prefix /home/mato/.opam/mirage-dev-4.04.0 --enable-lwt --enable-mirage".
<mato>
with nothing in the stdout/stderr file, which is odd
<hannes>
but ./configure is so last century...
<hannes>
we just switched to topkg, and the opam file in mirage-dev is updated..
<yomimono>
(which is probably not the right fix, but might be a fix)
<hannes>
s.maker.mato. travis cannot find the symbol caml_startup
<yomimono>
mato: i'll be curious to see what's in the lease -- there's not proper routing in tcpip.ipv4 at the moment but if we get only one route in the lease that's for everywhere, it's simple to expose that as the default gateway
<mato>
hannes: ugh. that's odd. let me try to repro back with 4.03.0 (was on 4.04.0)
<hannes>
mato: same happens with 4.04 on travis
<mato>
hannes: oh, i see. .../libmirage-solo5_bindings.a needs to come *after* asmrun in the link line. which it does on my machine, but not on travis :-/
<mato>
hannes: yes, sorry, i was wrong, the order is correct
<mato>
hannes: in that it should be bindings (uses caml_startup) followed by asmrun (provides caml_startup)
<mato>
but how to get the travis version of pkg-config to agree on that i don't know
<hannes>
mato: yes. so. order is correct... do you think this pkg-config requires field will be of any use?
<mato>
i won't know until i've tried :-)
<mato>
we could use requires in mirage-solo5 to require ocaml-freestanding (and not list it explicitly in the mirage frontend)
<hannes>
yes, this is what I tried to indicate at 23:03
* mato
is trying to reproduce using an ubuntu 14.04 container
<yomimono>
brb dinner, trying to figure out why MODE is getting unset in the meantime
<mato>
ok, i can reproduce the problem, which is good
<mato>
hannes: unfortunately hand-editing the .pc to add in Requires: ocaml-freestanding doesn't help (same, wrong, order)
agarwal1975 has quit [Ping timeout: 256 seconds]
<hannes>
mato: interesting. i get if I add the requires: ocaml-freestanding to mirage-solo5.pc a stable sort order where the solo5-bindings come first
<mato>
hannes: switching around the order in PKG_CONFIG_PATH *does* help
<hannes>
using pkg-config --static --libs manually
yomimono has quit [Ping timeout: 265 seconds]
<mato>
hannes: afaict this is a broken pkg-config, ubuntu 14.04 has an ancient 0.26
<hannes>
mato: so what do we do to fix it?
<hannes>
I'd propose: a) requires of ocaml-freestanding into mirage-solo5 (doesn't hurt, is the right thing) b) remove ocaml-freestanding from mirage.ml c) adjust the sort order to be share : lib in mirage.ml!?
<mato>
hannes: yeah, that sounds about right, just verifying that it does the right thing on old and new pkg-config
<hannes>
I verified it on FreeBSDs pkgconf-1.0.2 (which is another implementation of pkg-config)
<mato>
hannes: ok, let's do that then
<mato>
hannes: and add a comment about why the order is the way it is in lib/mirage.ml
alfredo has joined #mirage
<mato>
hannes: will you do it or shall i?
alfredo is now known as abeaumont
<hannes>
mato: for aesthetic reasons we should have the same order + comment in ocb-stubblr
<mato>
hannes: ack
<mato>
thinking about it, with this mess we'd be better off having conf-pkg-config install our own local copy of pkg-config (possibly called opam-pkg-config or something) with the right paths already set
<mato>
and a non-broken version
<mato>
then again, if we're doing that we might as well just install a bunch of wrappers to use opam per-package variables instead and do away with pkg-config altogether :)
<mato>
ok, i'm rambling somewhat, should probably get some sleep
<hannes>
well, getting rid of pkg-config would be nice
<mato>
+100
<mato>
but maybe not tonight :-)
<mato>
if we do that then we should do it in a way that's future-proof for OPAM 2