18:22 <hannes> about our discussion in here yesterday, with https://github.com/mirage/functoria/pull/97 there is sane behaviour again for `mirage help` without a config.ml present!

18:25 <yomimono> :D

18:26 <hannes> I'd like to peek into the first positional command line argument, but I cannot :/

18:45 <hannes> could someone shed some light into this eval vs no-eval thing? or, rather: if I have a configured unikernel, will mirage describe --no-eval --my-custom-options be useful?

18:46 <hannes> or, asking differently: why can't I just drop eval and no-eval, and have mirage describe behave that if it finds a configured unikernel to show me that, and if there is no config yet, it shows me the default?

18:46 <hannes> (I suspect Drup might know the answer to that)

18:47 <yomimono> FWIW the behavior you just described seems sensible to me; we can get the other possible values for keys with mirage configure --help still, right?

18:47 <hannes> for me, having mirage describe behaving differently on a) configured and non-configured and b) --no-eval vs --eval and c) getting another custom set of command-line options sounds very complex (and my head is not willing to understand what should happen there)

18:48 <hannes> esp since I'd try to centralise the configuration parameters of unikernels to be valid only for mirage configure..

18:48 <hannes> (and have no merging of parameters, since I don't understand that anyways)

18:49 <hannes> so, if you don't have a configured unikernel, you get mirage describe --no-eval. if you have a configured one and want to get the not confgured, do a mirage clean followed by mirage describe.

18:50 <hannes> anyways, off to star wars... will read backlog if mato or drup or yomimono or someone else has seen the light

18:50 <yomimono> hannes: ^, you already have my blessing

18:51 <yomimono> enjoy star wars :)

19:23 <Drup> hannes: well, the behavior of configured vs non-configured is completely explained in term of eval/no-eval (since it just changes the default)

19:24 <Drup> Your proposition would be to conflate evaluation and configuration ? Remove the switches and "do the right thing" when we are in the configured state ?

19:25 <Drup> That's pretty much what's already done, no ? If you ignore the fact that --eval and --no-eval exists, that's what happen

19:25 <Drup> (and that's orthogonal to the presence of extra configure argument, which are used regardless)

23:42 <hannes> Drup: I don't understand " that's orthogonal to the presence of extra configure argument, which are used regardless" -- what is the intended use case of a configured unikernel and doing mirage describe --my-new-option-1? what of an unconfigured and passing extra arguments -- I don't see the value to have configure options passed in there.

23:48 <Drup> When new pass options, it'll evaluate that the graph according to that option

23:49 <Drup> if --eval is present (of if it's already configured), then it'll evaluate the rest regardless, but otherwise no. So the graph is partially evaluated

23:49 <Drup> the idea was to be able to "clean up" the graph according to certain decision, like "Ok, what are my options if I'm on xen"

23:50 <hannes> hm. i just don't see the value of being able to pass options there. you can get a new, more configured graph, by saying mirage configure -t xen and rerun mirage describe, no?

23:50 <Drup> I agree that, when the unikernel is configured, this is a bit weird, and maybe we could reject additional arguments in this case

23:51 <hannes> in the end, how would a graph look if configured for xen, and I pass in a -t unix?

23:51 <Drup> hannes: go to mirage-www, execute "mirage describe --xen", then "mirage configure --xen && mirage describe"

23:51 <Drup> it'll not be the same

23:51 <Drup> (because the first is partially evaluated, the second is fully evaluated)

23:51 <hannes> ah, ok. i begin to understand

23:52 <Drup> I feel like you are asking two questions here

23:52 <hannes> but need sleep now.. thanks for your patience trying to explain me that :)

23:52 <Drup> Well, I mean, your question mean that the documentation/discoverability of the tool is crap

23:52 <Drup> (which is true, I just have no idea how to make those feature easy to discover)

23:54 <hannes> for me, something easy means less options. and I guess what I read here is hat "mirage describe of a configured unikernel should be fully evaluated" and "mirage describe of a non-configured unikernel may be partially evaluated by passing more options to it :)"

23:55 <hannes> but now, sleep..

23:55 <Drup> And disallow options for mirage describe on a configured unikernel ?

23:56 <hannes> i didn't say anything about allowing and disallowing things..

23:56 <hannes> (in my last sentence)

23:56 <Drup> I know, but you implied that before, hence the question :p

23:56 <hannes> yes, for me this would be a valuable thing to do

23:56 <hannes> because it makes it less complex in my mind, which otherwise asks itself what should happen with conflicting arguments

23:57 <Drup> Yeah, I'm not sure I'm willing to write the help page to explain that :D

23:57 <Drup> conflicting arguments are easy, the last one prevails

23:57 <Drup> it's the same that on the CLI. You just inherit the options that you configured with

23:57 <hannes> so what does eval and non-eval do?

23:58 <hannes> (in the case of a unconfigured unikernel and in the case of an already configured unikernel)

23:58 <Drup> they do the same as always

23:59 <hannes> uhm, this is not helpful. from the help i get something about evaluate the graph... *shrug*

23:59 <Drup> hannes: Well, I'm open to improvements on the help page

23:59 <Drup> :D