<hannes>
OH RLY? PPL WANT TO USE UDP AND NOT SPECIFY A SRCPORT!!!??!?!?!
<yomimono>
...did you make a lot of espressos today maybe
<hannes>
1.5 cappuccino was my intake so far, no plans to top up
<yomimono>
re: that problem, if you're actually tripping over it maybe make an issue; I've meant to fix it in the direct udp for a long time by putting some state in Udp.t
<yomimono>
but keep getting distracted :(
<yomimono>
perhaps some enterprising soul will pick it up
<hannes>
oh, hannes just fixed it
<hannes>
sorry... but (weighted) interaction with my webbrowser was more expensive than with my emacs
<yomimono>
that works pretty good too :D
insitu has joined #mirage
<hannes>
hmm, how would one get the udp listener ports? I fail to understand this tcpip stack again and again
<yomimono>
that's the reason I didn't make this patch yet :P
<hannes>
also: does it matter in udp?
<yomimono>
not unless you have a *lot* of listeners
<yomimono>
but I think tcp has the same problem
<hannes>
since udp is connectionless, applications should deal with it, no?
<yomimono>
yes, I'd expect any application that's using udp to be able to deal with a packet not arriving (or arriving to a listener when it shouldn't)
<yomimono>
oh hey mort___, I have an unrelated thing to ask you
<yomimono>
the existing deploy scripts have a 1:1 correspondence between either a XENIMG or HOST variable and the hostname of the thing that's being hosted
<yomimono>
sorry, not hostname but FQDN
<yomimono>
which interacts badly with something that generates artifacts that get used in opam
<yomimono>
I resolved this by having mirage strip all the `.`s from these names, but that's going to break the deploy scripts in a similar way as https://github.com/mirage/mirage/pull/725 , probably
<mort___>
hannes: istr one can't extract listener ports with current API? there were bits of API that weren't orthogonal anyway
<mort___>
yomimono: ah yes
<yomimono>
mort___ : you could store them in `t` when there's a call to `listen` with that `t`, I think was how I was going to solve it
<mort___>
cool :)
<mort___>
re scripts — yeah, simple enough to change `NAME` in post-merge.hook i think; or if we wanted to keep the sudo-xl-list-reads-nice feature, compute HTTP from `echo $NAME | tr -d "."` or similar
<hannes>
since I don't understand much of the intended lifecycle of t in Udp, and its dynamic (intended) behaviour -- should you be able to unregister listeners? if so, how? etc. -- I'd not try to solve it for 3.0
<yomimono>
right now you can unregister by calling listen again with a different function, which will replace the previous listener at least as I understand it
<hannes>
(+my mention that I'd have to re-read UDP rfc to understand whether it is an issue at all, having udp packets originating from a listener socket)
<yomimono>
hannes: ah. generally no I think, but if you want a random source port and you expect a reply, you probably also want to establish a listener on that port
<yomimono>
I see what you're getting at better now
<yomimono>
mort___: cool, thanks; sounds like it won't be a problem
<hannes>
yomimono: since in writev () the randomly generated src_port is not exposed, you'll have a hard time finding your potential answer ;)
<yomimono>
yeah -- the API that forces the user to choose a source port and then register their own listener is more honest in that regard
<yomimono>
it works for sockets because you punt to the OS for that management
<mort___>
confused. travis log shows that tyxml is installed by opam, and that the `-package tyxml` is present on the ocamlfind ocamlc command line; but whines that `module Tyxml is not defined`
<mort___>
huh
<yomimono>
mort___: that's a pretty old tyxml
_whitelogger has joined #mirage
<mort___>
hm. 3.1.1?
<mort___>
thanks github. opam-repository/packages is now too long for me to browse
<mort___>
"
<mort___>
"
<mort___>
Sorry, we had to truncate this directory to 1,000 files. 443 entries were omitted from the list.
<yomimono>
yeah, github is not the best interface for dealing with opam-repository
<yomimono>
tyxml.mllib in the 3.1.1 tag has a number of modules none of which are named tyxml
<mort___>
that is an old tyxml
<mort___>
i wonder why
<yomimono>
that's probably the more reasonable question to answer, yes
<yomimono>
could be camlp4 vs ppx-related?
<yomimono>
try slapping a constraint in there somewhere and see what becomes uninstallable maybe
<mort___>
odd thing is it doesn't happen wtih the unix builds
<mort___>
and didn't happen with the previous PRs that updated decks to use tyxml
<mort___>
so i guess it might be a new constraint added to other packages subseuqently
<mort___>
yomimono: i am an opam dunce so just to check i understand — slap a constraint in to tyxml=4.0.1 and then see what fails?
<mort___>
how do i do that — via a "PINS=tyxml.4.0.1" in the .travis.yml or stg?
<yomimono>
what I'd probably try is making a fresh 4.02 switch locally then installing the same sets of packages in the same groups, but once I get to `opam depext --yes crunch cstruct`... saying `opam depext tyxml.4.0.1`
<yomimono>
if you're cool with the travis test cycle, I think "PINS=tyxml.4.0.1" should work, although it's possible that it needs a URL instead
<yomimono>
it'd be PINS=tyxml:4.0.1 maybe... let me look at ocaml-ci-scripts
<yomimono>
I usually pin it to a branch or a commit
<yomimono>
the syntax for that is definitely PINS=tyxml:https://github.com/ocsigen/tyxml.git#4.0.1
<yomimono>
(which might even work as written, since that's what they called the tag)
<mort___>
checking the readme, i think tyxml.4.0.1 would work (or tyxml.4.0.1:url if i wanted)
<mort___>
but i'll try locally instead :)
<mort___>
(and why is travis showing me these builds that exited with non-zero code as green?? ho hum)
<yomimono>
did the others fail too and it only looks like they succeeded? that's obnoxious
<yomimono>
yuck
<mort___>
yes idd :/
<mort___>
ok, travis is running that one again
<mort___>
wat?!
<mort___>
if pinned explicitly, travis is ok with that
<mort___>
what causes opam to not get the most recent version that satisfies constraints?
<mort___>
aspcud does seem to be installed
<mort___>
…and now tyxml is being rebuilt and that's failing. sigh. computers are rubbish
<yomimono>
straaaaaange
<mort___>
Drup: any ideas why I'd get the following in a travis log:
<mort___>
#=== ERROR while installing tyxml.4.0.1 =======================================#