| lobbes: | dorion: ty for the references, I'll keep those within arm's reach. | [00:10] |
| lobbes: | http://logs.ericbenevides.com/log/ossasepia/2020-01-30#1016647 << this makes sense. I know that being able to at least talk to a human is top on my list (and yeah, I've had two encounters with asiatic hosters so far and both were ~100\% automated...) | [00:10] |
| ericbot: | Logged on 2020-01-30 08:14:36 diana_coman: lobbes: so if you want to filter them more stringently, you need to decide first what are you filtering them for ie what you really can't live with (as usual, it's the negative that defines it, what can one do) | [00:10] |
| lobbes: | http://logs.ericbenevides.com/log/ossasepia/2020-01-30#1016648 << yeah, I guess save for flying and visiting a potential hoster it will always be hard to sniff out odd up-front. Still, I like your suggestion re: net pipes. I'll keep that in my back pocket. | [00:10] |
| ericbot: | Logged on 2020-01-30 08:20:10 diana_coman: re search, I took at some point in anger the map of net pipes and went from there, datacentre lists per country etc; the trouble however is that as long as you search online only, the options are really "many of the same thing" with the odd stuff quite invisible as far as I can tell. | [00:10] |
| lobbes: | http://logs.ericbenevides.com/log/ossasepia/2020-01-30#1016650 << ack and agreed | [00:10] |
| ericbot: | Logged on 2020-01-30 08:21:27 diana_coman: lobbes: also, you should publish your "fuck you, shinjiru", for your own future ref if nothing else | [00:10] |
| whaack: | diana_coman: EOD Report: I spent the greater portion of my day writing the network socket notes article, and then went on to study the mother board, taking notes as well. The most notable discovery I made is that my GPU is not plugged into the fastest slot (the PCIe x16 - the only PCIe slot that connects to the North Bridge controller.) | [00:57] |
| diana_coman: | whaack: a day of discoveries at least, lolz. | [04:14] |
| whaack: | diana_coman: (and trinque:) I explored the problem with reconnecting with ircbot a bit more thoroughly and I have a few questions about submitting a vpatch. (1) There are some other side bugs I have found in ircbot, do I lump extra fixes into one vpatch or do I keep my vpatch concise with only one goal. (2) Reconnection atm is broken entirely (when the bot tries to reconne | [11:45] |
| ossabot: | (trilema) 2017-12-24 asciilifeform: you changed 'channel' slot in ircbot class to 'channels', but never bothered to change the corresponding line in make-ircbot !! ben_vulpes ) | [11:45] |
| whaack: | ct the program is guaranteed to crash). I can fix the immediate bug that causes this, but even then reconnection hardly does anything - because even with the fix the bot will only reconnect in a very specific narrow case that i'm not sure ever happens in the wild. | [11:45] |
| diana_coman: | whaack: from my pov, as long as it doesn't result in a huge vpatch, I don't see any problem in one vpatch fixing several issues; just make it clear and readable, that's all. | [11:47] |
| whaack: | diana_coman: ok. wrt to point (2) I can make a simple vpatch that fixes what is a clear bug but likely doesn't help further the goal of 'keeping ircbot connected' or I can write something more complicated to make ircbot reconnect aggressively | [11:54] |
| diana_coman: | whaack: do first the vpatch that fixes the clear bug, since that needs fixing anyway, right? | [12:03] |
| diana_coman: | as to the reconnect, do what *you* need and then pack that. | [12:03] |
| whaack: | diana_coman: okay. I will fix the clear bug and include in the reconnect fix a fix to some side bugs and submit a vpatch for that. Then I will submit a second vpatch (or perhaps regrind the first one) that redesigns reconnection all together. | [12:06] |
| whaack: | in the end i may just regenesis ircbot, the current vpatches use sha512 hashes | [12:08] |
| diana_coman: | whaack: ha; so then yes, regenesis it with keccak and that's it. | [12:09] |
| whaack: | diana_coman: kk | [12:11] |
| spyked: | whaack: this might prove useful | [12:11] |
| diana_coman: | oh hey, good point spyked; thank you. | [12:12] |
| whaack: | spyked: ah yup, thanks. I'll have to think how to properly insert my vpatch in the tree and I'm sure I'll have some questions shortly. | [12:19] |
| spyked: | diana_coman, np. whaack: I think patching on top of ircbot-multiple-channels-corrected (or whatever you want to use for your code) is the right way to go. then whoever maintains their branch (e.g. I'm working on top of the trilemabot/feedbot branch) can add the patch separately and work from there | [12:24] |
| spyked: | trinque: does this ^ sound reasonable to you? | [12:24] |
| whaack: | spyked: that seems reasonable. btw, any chance you know why ircbot immediately rejoins a channel when it is kicked? I can't see why that behavior would be desired, and the multiple channels version rejoins all channels when kicked from 1 channel certainly makes no sense. | [12:30] |
| diana_coman: | spyked: comment in your modqueue. | [12:56] |
| diana_coman: | dorion: do you want to discuss the structure for that 2nd attempt at the +ev contribution to the tmsr-os article? | [13:02] |
| dorion: | diana_coman I do, but have a lunch meeting that I've got to leave for in about 15 minutes. are you available tomorrow evening 19:00 UTC ? | [13:28] |
| diana_coman: | dorion: on Sunday then; tomorrow won't work. | [13:30] |
| dorion: | diana_coman aok, confirmed, thanks. | [13:33] |
| trinque: | spyked: I'd be willing to at least question whether what's already there can be generalized for people's use-cases, rather than branching the thing so soon | [21:18] |
| trinque: | arguably someone's wrong if such a tiny thing is being branched | [21:18] |
| trinque: | whaack: it aggressively rejoins channels because it was built to handle the voice model and "be in channel at all costs" was a goal of mine. | [21:19] |
| trinque: | I'd certainly sign a patch that made that a constructor flag, :rejoin t or something | [21:19] |
| trinque: | also would love an explanation of the bug you found! | [21:20] |
| trinque: | I bet this has plaged the thing for a long time if so. | [21:20] |
| whaack: | trinque: alright, i can make my vpatch make the rejoin channels feature be set by a flag | [21:21] |
| trinque: | I think it's important to differentiate between two reasonable use-cases, and fundamental disagreement about design. | [21:22] |
| trinque: | I think the former is appropriate as a flag, and the latter *must* be a fork in the V-tree | [21:22] |
| whaack: | trinque: I explained the bug briefly in #o but i'll have it in an article going over it in more detail likely by tomorrow evening along with the vpatch | [21:24] |
| ossabot: | Logged on 2020-01-04 22:56:08 whaack: trinque: I think I may understand this if you never got around to it. The thread that normally calls ircbot-reconnect is the ircbot-ping-thread. However the ping-thread commits suicide because ircbot-disconnect calls (sb-thread:terminate-thread (ircbot-ping-thread bot)) . So when the ping thread calls ircbot-reconnect after calling ircbot-disconnect it never gets to the ir | [21:24] |
| whaack: | trinque: makes sense re two use-cases and disagreement. That said I can't say I really understand your use case - I didn't know that the voice model kicks people from channel | [21:28] |
| trinque: | I didn't want "oops I accidentally kicked the bot" to require human interaction. | [21:38] |
Comments feed: RSS 2.0