<hannes>
can I make this with some magic such that if nocrypto is installed anyways, by default the other rng is used?
<Drup>
hum, I somehow missed that
<Drup>
huuum
<hannes>
there is some magic around to detect whether nocrypto is in there...
<hannes>
but I'm clueless about the phasing and how to get it in the right shape
<Drup>
I have an idea, but I'm not even sure it'll work :D
<hannes>
Drup: I'd be happy to see any ideas :) (you might have missed it since it just got merged...)
<hannes>
but we'll suffer^Whave the same issues in the future when more people implement alternative implementations of <foo> (such as my standalone arp package)
<Drup>
let test_entropy : bool Functoria.Key.value = Functoria.Key (pure is_entropy_enabled $ pure ())
<Drup>
then you use Functoria.if_ to switch between the two random devices
<Drup>
no, wait, that doesn't work
<hannes>
would you mind instead of trying to explain me which lines to change to change them and put a diff somewhere? I'm happy to compile and test
<Drup>
Well, you trying to do something that I worked a bit hard to disallow :D
<Drup>
you are*
<hannes>
huh?
<hannes>
this is disallowed?
<Drup>
dynamically changing the graph of devices depending on other nodes in the graphs ? Yeah.
<hannes>
hmmmm, but you see what I would like to achieve and that this makes sort of sense!?
<Drup>
the graph of devices is intended to be quite static. You just have if nodes that are *external* conditions (such as keys).
<Drup>
hannes: I guess you don't want to add a key that decides if we use the normal random or the nocrypto random ?
<hannes>
Drup: a key what is the default would be nice as well... but furthermore making the default depend on whether nocrypto is around or not would be epic
<Drup>
yeah
<Drup>
honestly, I see no way of making that happening
<Drup>
You say that "the logic for this is already in the mirage tool" ... but it isn't
<Drup>
it's just a hackish patch to ensure that people who do not declared their device dependency properly are yelled at, and to abort in that case
<Drup>
It's not a way to dynamically change the shape of the graph depending on the presence of the nocrypto device .. it just aborts
<hannes>
hmm :(
<Drup>
Does nocrypt rng needs entropy init ?
<Drup>
(I guess yes, but I'm not knowledgable
<hannes>
yes
<hannes>
I did not put a `connect` in there since its already in the nocrypto device
<Drup>
then why is there no dependency from nocrypt_random towards nocrypto ?
<hannes>
'coz i missed it... sorry
<Drup>
Heh, I'm the one who should apologize, I should really have looked at that patch set. I glanced over it and though "oh, it's a rng device, it's out of my area of expertise" ... =')
<Drup>
hannes: I'm trying to think of a nice way to make this work, this is really akward to encode, grmbl. :/
<Drup>
hannes: I think it's best to make the user explicitly ask for it (via a key). So a "generic_random" similar to "generic_kv_ro"
<hannes>
hmmm
<hannes>
I thought about that, yes... maybe it is smarter to try not to do much magic there, but just require everything to be explicit
<Drup>
that's very much functoria's way of doing thing, yes
<Drup>
be explicit about your devices
<Drup>
so that everything can be inspected statically with the tool.
mort___ has quit [Quit: Leaving.]
<Drup>
hannes: the issue is that there is no order in the reduction of the graph. Consider the case where a unikernel uses nocrypto or not conditionally (typicall, mirage-ww does that, by having https or not). If you use the rng device in another part of the graph, then doing the reduction is very problematic
mort___ has joined #mirage
<hannes>
Drup: but functoria has atm some defaults, and of course leaving everything to the user is a bit awkward... in the end, there should be sensible defaults depending on target platform and build configuration, but leave it up to a user to overwrite defaults
<Drup>
sure, but that's what keys are for.
<hannes>
ah, now I can see how the generic_kv_ro looks like (just had to open my eyes)
<Drup>
I should update the documentation of that, because it's not very clear but, with generic_kv_ro, you can *also* fix things statically in your configuration if you want it: generic_kv_or ~key:(Key.pure `Fat) ...
<Drup>
then, no keys are exposed, it uses the value directly
<hannes>
that was above my head, what does it mean?
<Drup>
so, if you do `generic_kv_ro "foo"`, then a key is exposed on the command line
<Drup>
(which allow you to choose which kv_ro)
<hannes>
yes
<Drup>
but if you do `generic_kv_ro ~key:(Key.value `Fat) "foo"`, it doesn't, it just uses `Fat to find things out
<Drup>
and you can compute on things of type Key.value.
<Drup>
So, you can create a key "https" (like in mirage-www) and use that key to compute something of type, let's say [`Nocrypto|`Std] value, and pass that generic_random. And tada, one configuration, still figures out the right random
<Drup>
hannes: It wasn't clearer, wasn't it ?
<hannes>
but at the time of evaluating keys I do not yet know which packages are in the graph?
<Drup>
nope
<hannes>
what I got is that keys can be auto-filled by other keys
rgrinberg has joined #mirage
<Drup>
(since evaluating keys pretty much determines which packages are in the graph)
<hannes>
i can see...
<hannes>
so passing an "abstract nocrypto" dependency (is this a key?), as we do in several unikernels, can that lead to the choice of a RNG?
<Drup>
No.
<hannes>
this 'abstract nocrypto' is not a key, or is it?
<Drup>
no, it's just a device
<Drup>
`abstract` just hides the phantom type. `nocrypto` is just a device.
<Drup>
hum, there is no example of https-or-not in mirage-skeletong
<Drup>
-g
<yomimono>
mirage-www has one
<Drup>
Yes, I know
<yomimono>
is static_website_tls not switching on config-time info ?
<yomimono>
probably we should collapse static_website and static_website_tls into an example of how to do that
<yomimono>
maybe a nicer example than mirage-www which is convoluted
copy` has quit [Quit: Connection closed for inactivity]
mort___ has joined #mirage
miragebot has joined #mirage
<miragebot>
mirage/master 6ae61af Hannes Mehnert: cleanup: remove dead code
<miragebot>
mirage/master 206a07e Hannes Mehnert: connect does not return a result
<miragebot>
mirage/master 67e0df0 Hannes Mehnert: functoria needs return
miragebot has left #mirage [#mirage]
<miragebot>
[mirage] yomimono pushed 5 new commits to master: https://git.io/vPmvk
<hannes>
\o/
<yomimono>
:D
dograt has quit [Ping timeout: 265 seconds]
yomimono has quit [Quit: Leaving]
<mort___>
random opam question - is there an easy way to force opam to *never* install a package?
<mort___>
no matter what dependencies say (barfing in preference)
<Drup>
that's an interesting request
<Drup>
mort___: create a new package with "opam pin add --edit FOO", give it a reasonably unique name, remove install, build fields and dependencies, add one conflict with the package you don't want
<mort___>
the context was a (mistaken) belief that there were remaining camlp4 dependencies where we didn't want them
<Drup>
strictly speaking, that doesn't mean it will never be installed, but when installed, it will be forced to remove that dummy package
<mort___>
so i wondered about forcing my switch to conflict with camlp4 in some fashion
<hannes>
mort___: the xen stuff is full of it, as well as mirage-console (but samoht has a PR which needs some rebasing)
<Drup>
oh, you could actually make it part of your base package, so that it's never removed
<Drup>
(but only in opam 2.0)
<mort___>
hannes: yeah it turns out avsm belief that mirage-www didn't build with 4.03 was xen specific and not to do with direct use of syntax extensions in mirage-www itself
<mort___>
drup: thanks, i might try that some time :)
<hannes>
mort___: but someone should get rid of the syntax extension anyways ;)
<Drup>
note that the conflict messages that opam spurt are a bit .. well, verbose
<mort___>
yes indeed. and make the default logging that travis handles less verbose too — too big for this web session, need to download the raw log
<hannes>
mort___: I did my community service for this month already (and it is only the 2nd October) ;)
<mort___>
yeah, i know :)
<mort___>
about time i actually got myself a docker thingy for building the xen version anyway
<mort___>
(and thanks for the community service, it's appreciated!)
<hannes>
mort___: and I have a long list of "things to be done" in various repositories.. like porting to logs, porting to topkg ;)
<mort___>
well, fwiw i was going to spend some time with mirage-www once i'd finished mirage-decks
<hannes>
and fixing up dependencies... some are unneccessary..
<hannes>
\o/
<Drup>
wrt mirage-www, it would be nice to have a better story wrt client ocaml code
<Drup>
the build system story is horrendous
<mort___>
drup: tyxml question: with tyxml, is there any particular benefit to using combinators directly over the ppx let%html thing?
<mort___>
drup: yes, it is
<mort___>
i shall probably try and do something about that when i pick it up
<Drup>
huum, some things are not expressible in the ppx
<Drup>
like "div @@ List.map foo l"
<mort___>
ah ok
<Drup>
I mean, you can express it, but at some point, you might just as well, use the combinators
<mort___>
also, is there an easy way to print the structure resulting from the combinators to a string?
<mort___>
yeah.. it's when porting an existing pile of html both from template files and embedded via cow.syntax
<Drup>
Depends, which instance of the combinators are you using ?
<mort___>
er, dunno :)
<mort___>
how many instances are there?
<Drup>
which module did you open ? :D
<mort___>
Tyxml.Html
<Drup>
ok
<Drup>
so then it's easy, Tyxml.Html.pp
<mort___>
have been manually converting to direct use of ocmbinators so far
<mort___>
but it's tedious
<Drup>
Yeah, that's the reason we have the syntax extension, people seem to like to write the boilerplate with the actual html syntax
<mort___>
ok— imagine i'm some kind of idiot n00b who doesn't understand all that Format.formatter magic — how do i invoke pp on the result of the ocmibnators to get a string? :)
<Drup>
It's written in the documentation ! :D
<mort___>
i did look, must've missed it...
<Drup>
let s = Format.asprintf "%a" (Tyxml.Html.pp ()) my_html
<Drup>
(I agree tyxml is extremely confusing, it has a ridiculously large surface API, the types are very complicated and it uses functors in a way that ocamldoc really doesn't like. I tried my best with the documentation but ...)