26m6h 54m21m10m1h 58m18m36m37m

asciilifeform: apol. for noise, but must test bot :
snsabot: Logged on 2019-08-11 18:20:41 asciilifeform: lobbes, mp_en_viaje : did feedbot actually emit irc lines in #e ? cuz i'm not seeing either or or in mine ?
mp_en_viaje: asciilifeform, i was tuned out aug2-8.
mp_en_viaje: **** ENDING LOGGING AT Fri Aug 2 08:47:20 2019
mp_en_viaje: **** BEGIN LOGGING AT Thu Aug 8 21:04:21 2019
asciilifeform: right but evidently feedbot was here ?
asciilifeform: and emitted these ln
mp_en_viaje: i think so yes. since they're in the lobbesbot log. possibly diana_coman or lobbes have it in their local log ?
lobbes: asciilifeform: according to your index number scheme, this is the first line >>
snsabot: Logged on 2019-08-11 18:21:17 asciilifeform: apol. for noise, but must test bot :
asciilifeform: ( unless lobbes's item somehow puts feedbot as specialcase in all logs ? )
asciilifeform: lobbes: i noticed earlier, hence the q
snsabot: Logged on 2019-08-11 18:21:57 asciilifeform: << bot does work. but observe, this is index 1000000 ! i.e. 1st line it ever saw ?!!
lobbes: aa odd. lemme check my logs
lobbes: << first record of join, at least
lobbesbot: Logged on 2019-08-08 17:25:29: *** Joins: snsabot (~snsabot@
asciilifeform: there's a whole buncha folx here, one of'em has gotta have raw e.g. znc log from 8/3, 8/6, 8/7
asciilifeform: lobbes: find all of its joins plz ?
lobbes: and no record of anything else being said since then
asciilifeform: ( and parts )
lobbes: that was the first that I saw
asciilifeform: lobbes: grep plz for these, and at same time for all feedbot lines
mp_en_viaje: asciilifeform,
lobbes: connectolade is logged in that logger
mp_en_viaje: you only joined on 8th, how could you have seen lines from before 8th ?
asciilifeform: mp_en_viaje: was supposed to have sat here from day1 of snsabot . evidently did not. currently looking in its log to see why
mp_en_viaje: aok
asciilifeform: almost certainly answer is
mp_en_viaje: ah ok
mp_en_viaje: no big deal anyways.
asciilifeform: well no this is a potentially catastrophic bugola
asciilifeform: i.e. when joining chans, there is a chance that fails
asciilifeform: will have to add routine which verifies that we're actually ~in~ the specified chans, and ring alarm if not
asciilifeform: cuz apparently the 'wait 20s after auth' does not 100% deterministically force !!
mp_en_viaje: hm
asciilifeform: at the risk of log clutter, observe:
asciilifeform: # Auth to server
asciilifeform: send("NICK %s\r\n" % Nick)
asciilifeform: send("USER %s %s %s :%s\r\n" % (Nick, Nick, Nick, Nick))
asciilifeform: send("NICKSERV IDENTIFY %s %s\r\n" % (Nick, Pass))
asciilifeform: time.sleep(Join_Delay) # wait to join until fleanode eats auth
asciilifeform: # Join selected channels
asciilifeform: for chan in Channels:
asciilifeform:"Joining channel '%s'..." % chan)
asciilifeform: send("JOIN #%s\r\n" % chan)
asciilifeform: while connected:
asciilifeform: ...
asciilifeform: see, 1st auths, then awaits fleanode to eat the auth (so can join e.g. #t, where +r is in effect, but without waiting for any fleanode-specific messages)
asciilifeform: then operates until disconnected
asciilifeform: Join_Delay is presently 20s.
asciilifeform: (empirically derived)
asciilifeform: currently log set to 'catastrophic only' debug level, but dollars to doughnuts it was same problem as there , the delay proved insufficient
asciilifeform: there are 3 possible pills : 1) increase delay (and there is no guarantee from fleanode re what suffices) 2) do as ben's bot did, and await the fleanode-specific 'you've been authed' string when connecting 3) perform test re which chans we are in, when connected, and retry until the set of which-chans is equal to the config'd set
mp_en_viaje: asciilifeform, but #eulora is open, can join with no reg

Random(eulora) | Download daily DB snapshot | Get Source Code