rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
rohitksingh has quit [Read error: Connection reset by peer]
sandeepkr__ has quit [Ping timeout: 260 seconds]
kuldeep has quit [Ping timeout: 276 seconds]
kaalikahn has quit [Quit: Leaving]
kuldeep has joined #m-labs
sandeepkr__ has joined #m-labs
tariq786 has joined #m-labs
<whitequark>
rjo: I will check
<whitequark>
rjo: hm, it's up now
<whitequark>
more specifically, it is up if you use ipv4
<whitequark>
oh. only the router is up. the buildserver is actually down. so i suppose what happened is it crashed or something.
key2 has quit [Ping timeout: 276 seconds]
<whitequark>
rjo: do you want me to just reboot it or do you want me to try and look at the kernel panic, if any? not sure what sort of hardware-related bugs we can expect
<rjo>
whitequark: i have no preference.
<whitequark>
ok. then i will just reboot it once the trains start running.
rohitksingh has joined #m-labs
key2 has joined #m-labs
rohitksingh has quit [Client Quit]
<sb0>
rjo, I have an idea to deal with slow sync_struct subscribers (and slow applets)
<rjo>
whitequark: ack. afaict it has been down for a couple of days already. fwiw no unusual level of urgency
<sb0>
if the size of all non-init messages in the queue is larger than the size of the last sent init message, clear the queue and replace with a init
<rjo>
sb0: ok. but they can still pile up just on inits. and maybe processing inits is more expensive. but those are details...
<sb0>
"clear the queue" == clear everything including any existing init message that may be there
<rjo>
ok
<sb0>
so no, they won't pile up
<sb0>
it will just make the updates slower, at the rate that the subscriber can process them
<rjo>
well. yes. they might still pile up. but not "earlier" than now.
<whitequark>
rjo: well, I'm going to need it to work on openocd, for one
<rjo>
whitequark: are you going to try to use msvc?
<rjo>
sb0: yes. i remember seeing that a while ago when i did some pubsub with 0mq. the "compress queue by replaceing with an init" looks good to me.
<sb0>
if init processing is more expensive, there can be some tweaking of the compression condition, e.g. compress when size of queued mods is 1.2x size of last init
<rjo>
and a good condition for "definitely too slow" might be that algorithm finding an init in the queue.
<sb0>
the way sync_struct works is written, each message is a queue entry. it's straightforward to add a boolean flag to determine if the message is init or not without deserializing it on the publisher
key2 has quit [Ping timeout: 260 seconds]
<whitequark>
rjo: yes, it is assigned to me and I did some preliminary work already
<whitequark>
no, I will not use msvc, since openocd uses autocrap for building
<whitequark>
instead, I will simply cross-compile it using Debian's cross-gcc for Windows
<rjo>
and make a cross conda package out of it?
<whitequark>
yeah
<whitequark>
tht's the only part that worries me.
<whitequark>
but there ought to be some way to make those.
<sb0>
ignore conda-build, make the tarball yourself?
<whitequark>
`conda convert` apparently
sb0 has quit [Quit: Leaving]
larsc has quit [Ping timeout: 244 seconds]
EvilSpirit has quit [Ping timeout: 260 seconds]
larsc has joined #m-labs
nkaretnikov has quit [Ping timeout: 244 seconds]
sandeepkr__ has quit [Ping timeout: 252 seconds]
mumptai has quit [Remote host closed the connection]