avsm changed the topic of #mirage to: mirage 2 released! party on!
yomimono has quit [Ping timeout: 258 seconds]
smondet has quit [Ping timeout: 260 seconds]
rgrinberg has joined #mirage
abeaumont has quit [Ping timeout: 268 seconds]
agarwal1975 has joined #mirage
abeaumont has joined #mirage
brson has quit [Quit: leaving]
noddy has quit [Ping timeout: 268 seconds]
rgrinberg has quit [Ping timeout: 246 seconds]
insitu has joined #mirage
copy` has quit [Quit: Connection closed for inactivity]
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
insitu has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
insitu has joined #mirage
insitu has quit [Client Quit]
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
insitu has joined #mirage
AltGr has joined #mirage
fgimenez has quit [Ping timeout: 268 seconds]
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
w10have has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
fgimenez has quit [Ping timeout: 240 seconds]
fgimenez has joined #mirage
fgimenez has quit [Changing host]
fgimenez has joined #mirage
insitu has joined #mirage
agarwal1975 has quit [Quit: agarwal1975]
yomimono has joined #mirage
agarwal1975 has joined #mirage
fgimenez has quit [Ping timeout: 258 seconds]
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
yomimono has quit [Ping timeout: 258 seconds]
rgrinberg has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
yomimono has joined #mirage
rgrinberg has quit [Remote host closed the connection]
rgrinberg has joined #mirage
fgimenez has quit [Ping timeout: 268 seconds]
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
copy` has joined #mirage
insitu has joined #mirage
fgimenez has quit [Ping timeout: 240 seconds]
fgimenez has joined #mirage
fgimenez has quit [Changing host]
fgimenez has joined #mirage
brson has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
fgimenez has quit []
w10have has quit [Ping timeout: 256 seconds]
yomimono has quit [Ping timeout: 258 seconds]
yomimono has joined #mirage
insitu has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<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!
AltGr has left #mirage [#mirage]
<yomimono> :D
<hannes> I'd like to peek into the first positional command line argument, but I cannot :/
<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?
<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?
<hannes> (I suspect Drup might know the answer to that)
<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?
<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)
<hannes> esp since I'd try to centralise the configuration parameters of unikernels to be valid only for mirage configure..
<hannes> (and have no merging of parameters, since I don't understand that anyways)
<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.
<hannes> anyways, off to star wars... will read backlog if mato or drup or yomimono or someone else has seen the light
<yomimono> hannes: ^, you already have my blessing
<yomimono> enjoy star wars :)
<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)
<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 ?
<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
<Drup> (and that's orthogonal to the presence of extra configure argument, which are used regardless)
insitu has joined #mirage
w10have has joined #mirage
smondet has joined #mirage
abeaumont has quit [Ping timeout: 265 seconds]
aantron has quit [Ping timeout: 250 seconds]
noddy has joined #mirage
aantron has joined #mirage
yomimono has quit [Quit: Leaving]
brson has quit [Ping timeout: 258 seconds]
noddy has quit [Ping timeout: 246 seconds]
brson has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
w10have has quit [Ping timeout: 268 seconds]
copy` has quit [Quit: Connection closed for inactivity]
noddy has joined #mirage
agarwal1975 has quit [Quit: agarwal1975]
smondet has quit [Ping timeout: 258 seconds]
<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.
<Drup> When new pass options, it'll evaluate that the graph according to that option
<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
<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"
<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?
<Drup> I agree that, when the unikernel is configured, this is a bit weird, and maybe we could reject additional arguments in this case
<hannes> in the end, how would a graph look if configured for xen, and I pass in a -t unix?
<Drup> hannes: go to mirage-www, execute "mirage describe --xen", then "mirage configure --xen && mirage describe"
<Drup> it'll not be the same
<Drup> (because the first is partially evaluated, the second is fully evaluated)
<hannes> ah, ok. i begin to understand
<Drup> I feel like you are asking two questions here
<hannes> but need sleep now.. thanks for your patience trying to explain me that :)
<Drup> Well, I mean, your question mean that the documentation/discoverability of the tool is crap
<Drup> (which is true, I just have no idea how to make those feature easy to discover)
<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 :)"
<hannes> but now, sleep..
<Drup> And disallow options for mirage describe on a configured unikernel ?
<hannes> i didn't say anything about allowing and disallowing things..
<hannes> (in my last sentence)
<Drup> I know, but you implied that before, hence the question :p
<hannes> yes, for me this would be a valuable thing to do
<hannes> because it makes it less complex in my mind, which otherwise asks itself what should happen with conflicting arguments
<Drup> Yeah, I'm not sure I'm willing to write the help page to explain that :D
<Drup> conflicting arguments are easy, the last one prevails
<Drup> it's the same that on the CLI. You just inherit the options that you configured with
<hannes> so what does eval and non-eval do?
<hannes> (in the case of a unconfigured unikernel and in the case of an already configured unikernel)
<Drup> they do the same as always
<hannes> uhm, this is not helpful. from the help i get something about evaluate the graph... *shrug*
<Drup> hannes: Well, I'm open to improvements on the help page
<Drup> :D