| 14:57 |
awt |
$ticker btc usd |
| 14:57 |
busybot |
Current BTC price in USD: $31492.27 |
| |
~ 1 hours 27 minutes ~ |
| 16:25 |
asciilifeform |
$ticker btc usd |
| 16:25 |
asciilifeform |
hmm no dice? |
| 16:26 |
asciilifeform |
shinohai: does one currently have to peer directly with the bot to make a query? |
| 16:28 |
busybot |
Current BTC price in USD: $31300.11 |
| 16:29 |
asciilifeform |
... a hm merely slow? |
| 16:30 |
shinohai |
Nah it *should* work, might be a bit slow. (Has worked fine testing from u0_a280 station which isn't peered to bot directly). |
| 16:34 |
asciilifeform |
$ticker btc usd |
| 16:34 |
busybot |
Current BTC price in USD: $31235.54 |
| 16:34 |
asciilifeform |
shinohai: loox like the 1st time there was a buncha chain sync traffic |
| |
↖ |
| 16:35 |
* |
asciilifeform introduced 'prod' for this, among other, reasons -- no reason wai have to wait for a msg from $peer to stay synced -- but afaik not implemented in blatta just yet |
| 16:43 |
shinohai |
$uptime |
| 16:43 |
busybot |
The bot has been up for: 45 days 20 minutes and 54 seconds |
| 16:43 |
shinohai |
awt so far only bug I have encountered with 9977 is when trying to use "resolve" http://paste.deedbot.org/?id=UA2O |
| |
~ 39 minutes ~ |
| 17:23 |
signpost |
went ahead and farted up 9977 too. |
| |
~ 28 minutes ~ |
| 17:51 |
asciilifeform |
!!help |
| 17:51 |
asciilifeform |
hmm signpost is deedbot on pestnet already or notyet ? |
| 17:53 |
signpost |
not yet |
| 17:53 |
asciilifeform |
a ok |
| 17:58 |
shinohai |
test |
| 17:59 |
signpost |
shinohai: what'd you do btw, separate pest station for bot? |
| 18:00 |
shinohai |
Yeah I run bot on separate station. |
| |
~ 1 hours 11 minutes ~ |
| 19:11 |
signpost |
test |
| 19:20 |
deedbot |
test |
| 19:23 |
signpost |
!!help |
| 19:29 |
signpost |
!!help |
| 19:29 |
signpost |
hm, working in direct messages atm. |
| 19:32 |
deedbot |
http://deedbot.org/help.html |
| 19:33 |
signpost |
hm, quite slow it seems |
| 19:33 |
signpost |
!!help |
| 19:35 |
signpost |
going to let it sit for a while and see whether this persists, and what happens in logs |
| 19:35 |
signpost |
I've got two pest instances on the same box here. |
| 19:36 |
signpost |
appears the lag is between those two, not within deedbot |
| 19:36 |
signpost |
awt: does having multiple local instances of pest break any assumptions of blatta? |
| |
↖ |
| 19:40 |
billymg |
signpost: i've seen significant bot delays with mine sometimes too |
| 19:40 |
billymg |
one is on another pest station on the same box as my primary, the other is on ec2 |
| 19:40 |
billymg |
(with its own pest station also, of course) |
| 19:41 |
billymg |
!. uptime |
| 19:41 |
bitbot |
billymg: time since my last reconnect : 40d 1h 32m |
| 19:41 |
billymg |
not much delay that time, that's the one on the same box |
| 19:41 |
billymg |
!c net-summary |
| 19:41 |
crawlerbot |
Bitcoin Network (IPv4 Nodes Active Within the Last 48 hours) Global: 7880; TRB-Compatible: 30; TRB: 13 |
| 19:41 |
crawlerbot |
TRB-Compatible by Country: United States: 8; Germany: 4; Romania: 3; Algeria: 3; Russia: 3; Singapore: 2; Canada: 1; Italy: 1; Mexico: 1; France: 1; Sweden: 1; Belgium: 1; Bulgaria: 1; |
| 19:42 |
crawlerbot |
TRB by Country: United States: 8; Canada: 1; Romania: 1; Lithuania: 1; France: 1; New Zealand: 1; |
| 19:44 |
billymg |
fast also. if there's a pattern as to when it's slow i haven't figured it out yet |
| 19:44 |
billymg |
hmm... that last line not yet showing in the logger (after 2 min) |
| 19:45 |
billymg |
and there they both are, so looks like the second line either knocked it loose, or just a coincidence |
| 19:45 |
billymg |
but yeah, stuff like that i've noticed before, without any apparent pattern |
| 19:46 |
asciilifeform |
billymg: see this hypothesis |
| 19:46 |
bitbot |
Logged on 2022-06-06 16:34:51 asciilifeform: shinohai: loox like the 1st time there was a buncha chain sync traffic |
| 19:46 |
asciilifeform |
billymg: right nao seems that blatta doesn't 'prod', so you dun know yer outta sync w/ $peer until he speaks |
| 19:47 |
asciilifeform |
at which point can trigger a lengthy getmsg sequence |
| 19:47 |
asciilifeform |
if you have the debug info log scrolling in a visible shell, becomes apparent |
| 19:48 |
* |
asciilifeform seeing buncha getmsg back'n'forth even nao |
| 19:48 |
asciilifeform |
incl. repeatedly for same msg's from shinohai -- suspect that 'smalpest' has a bug where doesn't properly store old msgs |
| 19:49 |
asciilifeform |
in principle one ought never to see a req for same old msg from one given $peer |
| 19:49 |
asciilifeform |
(unless his hdd burned down etc) |
| 19:52 |
jonsykkel |
cant remember how my code works but iirc it retrys getdata evry 10sec on broken chains |
| 19:53 |
shinohai |
I switched back to blatta on main station yesterday asciilifeform (just fyi) |
| 19:53 |
asciilifeform |
a hm |
| 19:54 |
asciilifeform |
then bug obv not in 'smalpest' lol |
| 19:54 |
asciilifeform |
wb jonsykkel btw |
| 19:54 |
jonsykkel |
thank |
| 19:55 |
jonsykkel |
wokring on a markdown replacment soon redy but i dont have a name for it so canot release - plz someone invent |
| |
↖ |
| 20:02 |
billymg |
asciilifeform: btw i've got something going with postgres full text search locally, still needs tuning before i can make it live |
| 20:02 |
billymg |
it's very fast |
| 20:02 |
asciilifeform |
nifty |
| 20:04 |
billymg |
figuring out the results highlighting is what i'm currently working on |
| 20:05 |
asciilifeform |
billymg: what's missing from this pov in the orig. highlighter ? |
| 20:05 |
billymg |
the original highlighter gives false positive highlights, since it mirrors the behavior of the old search mechanism |
| 20:06 |
asciilifeform |
a |
| 20:06 |
asciilifeform |
iirc if you were to pass the string b/w the " to it, oughta highlight correctly |
| 20:09 |
billymg |
i'll give an example, if i search for "ai machine" (no quotes) it will match 'ai' surrounded by word boundaries and words containing 'machin' (determined to be the stem) |
| 20:09 |
billymg |
one of the results is: http://logs.bitdash.io/trilema/2019-05-20#1914738 |
| 20:09 |
bitbot |
(trilema) 2019-05-20 asciilifeform: i suspect that mp_en_viaje is right, and even the 'ai beautifier' thing is redundant, all the machine needs to do is to work like the mirror in brothers grimm, whisper 'you are the fairest of them all' to the sow, will suffice. |
| 20:10 |
billymg |
the current highlighter also highlights the 'ai' in 'fairest', even though that was not matched by the search |
| 20:10 |
* |
asciilifeform not looked at reader.py for rather long time |
| 20:14 |
billymg |
in the highlighter the modification is easy, i can surround the token in '\b' (python regex word boundary), but the tricky part is getting the list of matches that postgres comes up with from a given stem |
| 20:14 |
billymg |
e.g. if you search for "banished" it will match the stem "banish", so all words with that stem match |
| |
↖ |
| 20:15 |
asciilifeform |
billymg: ah hm interesting |
| 20:15 |
* |
asciilifeform unrelatedly, looking fwd to 1y anniversary of 'p2p day' |
| 20:16 |
billymg |
i've found the function for going in the other direction, ts_lexize, but not yet found the one that produces the set of variations from a given stem |
| 20:16 |
asciilifeform |
billymg: imho ideally oughta have no mutation of search string if in doublequotes |
| 20:16 |
billymg |
yes, that's how it behaves |
| 20:16 |
billymg |
quoted strings are treated as literals |
| 20:16 |
* |
asciilifeform never liked 'stemming' |
| 20:17 |
asciilifeform |
a |
| 20:17 |
billymg |
it requires some wrangling, but having the tokenized stem index speeds it up a ton |
| 20:18 |
billymg |
ftr my example here had quotes to show the boundaries of the query, not that the term was quoted in the query |
| 20:18 |
bitbot |
Logged on 2022-06-06 20:14:21 billymg: e.g. if you search for "banished" it will match the stem "banish", so all words with that stem match |
| 20:21 |
billymg |
if you feed it ""real me"" (this time quoted), it finds the actually relevant lines, and very quickly. it's two stage, first does a full text search for 'real' and 'me' then a regex for '\yreal me\y' (surrounded by word boundaries) of those results |
| 20:21 |
asciilifeform |
iirc was what asciilifeform suggested last wk |
| 20:22 |
asciilifeform |
i.e. pg search (w/ indices etc) on quoted phrase, then filter in proggy for grep-like conformance |
| 20:22 |
billymg |
this all happens in postgres, and happens even faster than the ILIKE over the indexed 'payload' field |
| 20:22 |
asciilifeform |
given as pg's results are a superset of the desired results |
| 20:22 |
asciilifeform |
a hm neato |
| 20:33 |
signpost |
!!help |
| 20:34 |
signpost |
responds quite quickly in private. |
| 20:36 |
signpost |
now lagging in private after sending messages here. |
| 20:36 |
signpost |
smells like b00g |
| 20:37 |
billymg |
asciilifeform: with some numbers: http://paste.deedbot.org/?id=W7Rv |
| |
↖ |
| 20:38 |
deedbot |
http://deedbot.org/help.html |
| 20:39 |
billymg |
the first two are both "all in pg" queries, with diff strategies. the third is the "wide net in pg, filter in python" method |
| 20:39 |
billymg |
the results are from my laptop, not the rk |
| 20:42 |
billymg |
on the rk the results are more pronounced, ~193ms vs ~15s for the first two queries |
| |
↖ |
| 20:48 |
awt |
http://logs.bitdash.io/pest/2022-06-06#1006391 << just need to use different ports |
| 20:48 |
bitbot |
Logged on 2022-06-06 19:36:50 signpost[asciilifeform]: awt: does having multiple local instances of pest break any assumptions of blatta? |
| 20:49 |
signpost |
yep, they're on different ports |
| 20:49 |
signpost |
messages appear to be trickling into deedbot's instance, but sporadically and slowly |
| 20:49 |
* |
signpost can do some deeper diligence soon |
| 20:49 |
awt |
pestbot: ping |
| 20:49 |
pestbot |
pong |
| 20:50 |
signpost |
^ saw that very quickly. |
| 20:53 |
awt |
signpost: pestbot is fully synced |
| 20:57 |
awt |
blatta currently indeed does not support PROD - so there are no retries if your chain is broken and for whatever reason you're missing a GETDATA response. Gotta wait until next BROADCAST or DIRECT command to trigger another GETDATA. |
| 20:58 |
awt |
That said I have not yet encountered a case with the past couple of versions in which a sync failed. |
| 21:02 |
awt |
You could actually speed up the process by starting off with an up to date message table. |
| 21:05 |
awt |
shinohai: resolve is not supported. Appears I neglected to fully remove support for that command. |
| 21:07 |
shinohai |
ah kk I was going thru code and pulling out all the stops xD |
| 21:11 |
awt |
asciilifeform: dupe GETDATA responses area little tricky to debug. You WILL get them since you're requesting missing messages from all peers. |
| |
↖ |
| 21:11 |
awt |
You won't see dupes in the db, but they may be logged multiple times. |
| 21:18 |
awt |
Quite possible that there is a timing bug in which a dupe GETDATA response triggers a dupe GETDATA request, but I have yet to see an infinite loop in the released versions. |
| |
~ 38 minutes ~ |
| 21:57 |
shinohai |
https://archive.ph/0CMGZ << lol Costa Rica ,gov rekt AGAIN ? |
| 21:59 |
signpost |
which hero will use CR's inability to run tech infrastructure as a tax-avoidance defense? |
| 22:00 |
awt |
shinohai: this has been ongoing |
| 22:00 |
signpost |
to be clear, CR's *govt* ineptitude only makes CR the *place* more appealing. |
| 22:00 |
awt |
signpost: I'm currently unable to pay social security tax so I guess me |
| 22:00 |
signpost |
lol |
| 22:01 |
shinohai |
I'm thinking more we should possibly join force and try to hold CR for ransom. |
| 22:02 |
signpost |
get in line I guess. |
| 22:02 |
signpost |
shinohai: I'm still waiting for russia's "give us 1mil BTC or we'll launch your own nukes at your head" |
| 22:04 |
shinohai |
kek |