<mort___>
appears to be pingable but can't make connection on 80/tcp or 443/tcp
lars_kurth has quit [Remote host closed the connection]
AltGr has left #mirage [#mirage]
lars_kurth has joined #mirage
x-ip has joined #mirage
rgrinberg has joined #mirage
neatonk has quit [Remote host closed the connection]
rgrinberg has quit [Ping timeout: 260 seconds]
neatonk has joined #mirage
neatonk has quit [Remote host closed the connection]
mort___1 has joined #mirage
mort___ has quit [Ping timeout: 246 seconds]
lars_kurth_alt has joined #mirage
lars_kurth has quit [Ping timeout: 246 seconds]
mort___1 has quit [Ping timeout: 244 seconds]
cr409_ has joined #mirage
cr409 has quit [Ping timeout: 240 seconds]
rgrinberg has joined #mirage
lars_kurth_alt has quit [Read error: No route to host]
lars_kurth has joined #mirage
mort___ has joined #mirage
<noddy>
Drup: ping
x-ip has quit [Quit: Leaving]
<Drup>
pong
<noddy>
tokk
<noddy>
here's the thing: i want nocrypto logic *out* of the mirage tool, but as of this spring, that was impossible
<noddy>
for an actually decent solution, we should try to figure out how to get rid of that logic. it's a hack to have it in there.
<noddy>
the problem is that an independent library can't signal its special requirements to mirage atm
<Drup>
well, it can, that's what devices are for
<Drup>
I don't see what's the issue with devices advertising the fact that they want some entropy
cjab has joined #mirage
<noddy>
there is no entropy device.
<noddy>
this concept is a mistake. it makes no sense.
<Drup>
why ?
<Drup>
(there is one at the moment ...)
<noddy>
nope, there isn't. which is why it isn't exposed as a device.
<Drup>
It is in the new version of mirage.
<noddy>
again?
<Drup>
Yes, it works just fine really, I just had the wrong dependencies (and the fact that conduit is making weird things with optional dependencies)
<Drup>
What is your problem with the concept exactly ?
<noddy>
here's the problem with a device: a uniform interface for entropy does not make sense:
<Drup>
it doesn't ?
<noddy>
entropy behaves differently when... well, the entropy is different. environmental noise does not even have the same interface as a system rng.
<noddy>
the rng uses them in different ways
<noddy>
at the same time, there is no other reason to have entropy other than building a rng
<Drup>
then how can you have a common interface for nocrypto.xen and .lwt ?
<Drup>
(you clearly have one)
<noddy>
because these are parts of nocrypto. two pieces of code interact with the rest of nocrypto in different ways.
<noddy>
look into the code
<noddy>
entropy is really just a detail of the rng operation
<noddy>
the entire "entropy device" concept was only a burden. it makes no sense, as entropy is neither a device, nor uniform.
<Drup>
Ok. I really don't know the details, because I don't really care about entropy to begin with. Currently, in mirage, there is a "nocrypto" device
<Drup>
And the only thing it does is call the init function
<noddy>
yeah
<noddy>
does this not feel a bit hacky?
<Drup>
No.
<Drup>
It's a runtime dependencies. There are other similar runtime dependencies
<Drup>
devices don't necessarily imply being taken as a functor anymore.
<Drup>
as a functor argument*
<noddy>
and it doesn't seem to imply constructing a runtime representation of a device either
<Drup>
Ah, yes, it does
<Drup>
a runtime dependencies imply there is a value passing around, that's the general framework
<noddy>
yeah, you would logically think that. i thought that.
<noddy>
but then what does nocrypto device construct and pass around?
<Drup>
Well, in this case, none, so it's unit
<noddy>
therefore, devices do not imply constructing a runtime representation of a device either.
x-ip has joined #mirage
<Drup>
If you want to see it like that ^^
x-ip has quit [Changing host]
x-ip has joined #mirage
<noddy>
well if you think that fine, its fine by me
neatonk has joined #mirage
<noddy>
i just wished we had a way to say: "this lib wants either this other supporting lib, or the third lib, and needs this preamble code" inside the lib itself, not in the tool
<Drup>
Ah, yes
<Drup>
I agree, but that's quite tricky
<Drup>
consider the mirage website
<Drup>
it can be built with or without tls
<noddy>
yeah
<Drup>
the decision is based on configure time flags. We look at all the devices and then ask opam to install all the dependencies
<noddy>
i would very much like to be able to supply that option, or possibility, from the library itself
<noddy>
instead of the tool. it feels wrong to make the tool know about these relationships.
<Drup>
but that would mean I would have to discover as many dependencies as I can, then query each of them "do you have additional requirements", then reach a fixpoint
<noddy>
*or* piggyback the same information that is currently baked into the tool inside of META files or similar
<noddy>
X-META-SUPER-MIRAGE-IF-XEN
<Drup>
the META is only a partial information
<noddy>
can information be added that ocamlfind does not know about? custom meta?
<noddy>
in that case, mirage would only have to perform one scan of META files
<Drup>
no it wouldn't, because of generic things
<Drup>
(the generic stack example)
<noddy>
nono i mean for *externally* added relationships
<noddy>
it could do what it does, plus a scan of META files to add more information
<Drup>
(and you still need to put the initialization code somewhere)
<Drup>
I'm not sure how I feel about having this
<noddy>
that could be worked around with the same interface i guess
<noddy>
you would want to associate an interface with a library in the META
<Drup>
noddy: could you post your proposal on the functoria bug tracker ?
<noddy>
i'm not even sure i have a coheren proposal
<Drup>
well, at least the beginning of the idea
<noddy>
i just hated adding information about random libs into the tool
<noddy>
ok, i'll make noise there
<Drup>
the thing is, needing entropy is really a device runtime property
<noddy>
yes and no. because it has no uniform api, nor representation
<noddy>
it somehow feels like a device. but it turns out to not exactly be.
<Drup>
but, hum, you do kinda have an API
<Drup>
Nocrypto.generate
<noddy>
aha
<noddy>
but that's the api for the RNG, a faaaaar more derived concept. not for the *entropy*.
<Drup>
what does the external world is suppose to use ?
<noddy>
that one
<Drup>
irk, grammar
<Drup>
ok, then let's rephrase everything
<Drup>
with want an *rng* device. This device will do whatever it takes to have it's entropy. The rest of the world want rng and will add a dependency to this device.
<Drup>
its*
<Drup>
(Is this formulation more satisfactory ? :p)
<Drup>
from my point of view of non-expert that don't really care, there is no difference whatsoever :]
<noddy>
well this is close to what i almost posted, but deleted, because you mentioned it was not relevant to the issue at hand
<noddy>
bah dunno. that has a long list of cascading consequences too..
<Drup>
Well, the whole "rng" device is pretty close to what we have.
<Drup>
It's just that it's called "nocrypto"
<noddy>
oh sure
<noddy>
except there is no device you can put somewhere. there are no private types in the interfaces. there is a difference of calling function "A" or "B" on startup.
<Drup>
Well, it could be really an rng device, that gives an rng function
<noddy>
its not horrible. it would just be better if i could define that nocrypto device with the nocrypto library instead of polluting the tool.
<Drup>
(fwiw, daniel also wanted to encode devices in ocamlfind)
englishm_ has joined #mirage
<Drup>
(about zarith-xen, if we don't put it in the tool, it might not be installed, then nocrypto.xen would not be compiled)
<noddy>
it's a necessary conclusion. you want them out of the tool, but you want to inform the tool about extra things about the libraries. and there is a database of libraries. ocamlfind.
<Drup>
the thing is, you still need this fixpoint thing if you put them in ocamlfind
<Drup>
and I really don't want to have to do a fixpoint on libraries
<noddy>
actuall i recall dodging the fixpoint computation while adding nocrypto to mirage in the first place
<noddy>
re: zarith-xen: it is not possible for nocrypto to be installed, mirage-xen to be installed, and zarith-xen not to be. or?
englishm_ has quit [Client Quit]
<noddy>
if you have nocrypto, you either have all the supporting stuff, or mirage-no-xen (which conflicts with all of those). that was iirc the rationale behing that dep.
<Drup>
oh, there is a conflict
<noddy>
aha
<Drup>
Yes, it's fine then, ok
<Drup>
I think you should open tickets to discuss which formulation of the rng device is best. I really only care about the technical feasibility of it in functoria, so I'm not the ideal person to talk about that.
<hannes>
Drup: there is a Random device, currently using OCaml's Random, where someone manually has to call self_init. What we should have is choice over Nocrypto RNG or Random (or some static no-random thingy). I think self_init should be called by the mirage tool, similar to Nocrypto_init, if Random is used.
<hannes>
and Nocrypto should provide a Random device (which API might need some extensions)
<Drup>
hannes: with a configure time flag, like generic_stack ?
<hannes>
Drup: I should look into functoria how to do it.... for me, it would be sensible to have Random be the nocrypto RNG if nocrypto is pulled in anyways, otherwise use OCaml's LFSR (and warn user), but have the possibility (for testing) to pull in the /dev/zero RNG
<hannes>
so, configure time flag sounds about right... (but this random trickery should maybe wait a bit more)
<Drup>
Yes. Please open a ticket to discuss it, and if you have implementation question, I will gladly help :p
contrapumpkin has joined #mirage
copumpkin has quit [Ping timeout: 240 seconds]
<Drup>
noddy: Now I'm confused
<Drup>
that never happened before
andreas23 has quit [Quit: Leaving.]
neatonk has quit [Remote host closed the connection]
neatonk has joined #mirage
SilverKey has joined #mirage
<noddy>
Drup: me too
<Drup>
noddy: the most confusing is that the same set of option used to work ..
<noddy>
it *should*, what confuses me is that *this* set should work :)
yomimono has joined #mirage
nullcat has joined #mirage
neatonk has quit [Remote host closed the connection]
SilverKey has quit [Quit: Halted.]
nullcat has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
lars_kurth has quit [Remote host closed the connection]
neatonk has joined #mirage
mort___ has quit [Ping timeout: 240 seconds]
nullcat has joined #mirage
SilverKey has joined #mirage
jonludlam has quit [Ping timeout: 260 seconds]
SilverKey has quit [Quit: Halted.]
yomimono has quit [Ping timeout: 250 seconds]
nullcat has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
nullcat has joined #mirage
brson has joined #mirage
SilverKey has joined #mirage
nullcat has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
dezzy has quit [Read error: Connection reset by peer]
dezzy has joined #mirage
jonludlam has joined #mirage
nullcat has joined #mirage
x-ip has quit [Ping timeout: 252 seconds]
neatonk has quit []
mort___ has joined #mirage
rgrinberg has quit [Ping timeout: 255 seconds]
jgjl has joined #mirage
nullcat has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
yomimono has joined #mirage
rgrinberg has joined #mirage
nullcat has joined #mirage
jgjl has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
yomimono has quit [Quit: Leaving]
jonludlam has quit [Ping timeout: 240 seconds]
lobo has joined #mirage
nullcat has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
welterde has quit [Quit: WeeChat 0.4.3]
SilverKey has quit [Quit: Halted.]
nullcat has joined #mirage
rgrinberg has quit [Ping timeout: 268 seconds]
nullcat has quit [Quit: My Mac has gone to sleep. ZZZzzz…]