If anyone’s wondered what Frank’s logs look like, here’s a long sample covering sometime yesterday until now.

I often “watch Frank” by looking at this stuff as it scrolls down my screen in real time. (It’s relaxing, kinda.) This is also what I’m looking at when I’m trying to fix a bug.

(Note: I haven’t scrutinized this for content at all – for the wary, there is occasional unreviewed/uncensored GPT output in there, plus a large quantity of actual tumblr posts from people Frank follows or talks to)

nostalgebraist:

Frank will be down for a little while, and may be weird when she comes back up (eg mood graphs may be inconsistent, she may fail to respond to some posts or double-respond to others)

(The problem is cloud computing bullshit, as usual)

OK, she’s back up and running.

If I did things correctly, there shouldn’t be any double-responses or failures-to-respond.

However, some recent mood-related data was lost (there’s technically a backup but it’d be very complicated to actually use it). This means that Frank’s mood has reset to today’s baseline, and mood graphs created in the next 24 hour will show a “historically inaccurate” flat line up until the point when Frank came back this evening.

Frank will be down for a little while, and may be weird when she comes back up (eg mood graphs may be inconsistent, she may fail to respond to some posts or double-respond to others)

(The problem is cloud computing bullshit, as usual)

Frank’s been having semi-regular outages regularly, because the cloud computer that runs her main loop (not the GPT part, the little python script) has been randomly rebooting itself a lot.

This has always happened once in a while, but the frequency has gone way up in the last few days.

I’ve moved that process to a machine in a different zone to see if that mitigates the issue. (This is really a wild guess since I don’t know what causes the issue in the first place.) I haven’t seen any reboots since the move… fingers crossed.

Today I’ve released a new build of Frank’s generator model.

The new model should behave a bit differently when given “tell me a story”-style asks.

Recently, I’ve been re-training the generator every month or so as I periodically accumulate more scraped tumblr data. I usually don’t mention this, since the added data is only a small increment beyond the size of my total dataset, and I don’t expect big returns in terms of quality.

For this one, I did something new: I went through and made up descriptive titles for each fiction chapter in the dataset.

Frank uses some special hardcoded logic for “tell me a story”-style asks, which tries to extract the part of the text where the user describes the story they want. Then, the generator is told to write a story whose title is that description. (The title is removed at the end of the process to make everything feel a little more mysterious :) )

Historically, this has worked OK, but not that well, because most of my fiction chapters have uninformative names like “Chapter 12” or the name of a character. So the model had a less-than-ideal understanding of the relationship between the title and the content.

For this build, I went through all my fiction chapters, and invented titles that sounded more like things people would say in “tell me a story” asks. So the model should be a little better prepared to generate stories based on descriptions, where the description is used as the title.

nostalgebraist:

nostalgebraist:

Sorry that Frank was down for a while this evening…

I’ve been having a lot of issues lately where my http requests to tumblr will just hang indefinitely, without the python requests/httplib libraries raising any kind of timeout-related exception.

When I ctrl-C the script and restart it, it works again, but I don’t know how to simulate this manual step automatically, since I’m not given an exception to handle. Haven’t seen this before like, this week? Or not often anyway. I don’t know enough about web programming to know what the cause is likely to be, either.

Update: although I’ve made some progress on this issue, it continues to be a major problem.

Right now, a version of it is affecting image fetching (which doesn’t go through the requests library, just urllib3) in a way I’m finding tough to debug.

I have limited time and energy for this problem at the moment. Due to this, Frank will be much less reliable for an unknown (though hopefully short) period of time.

Don’t want to speak too soon, but a small tweak I made right after writing this post seems to have resolved the issue in practice.

nostalgebraist:

Sorry that Frank was down for a while this evening…

I’ve been having a lot of issues lately where my http requests to tumblr will just hang indefinitely, without the python requests/httplib libraries raising any kind of timeout-related exception.

When I ctrl-C the script and restart it, it works again, but I don’t know how to simulate this manual step automatically, since I’m not given an exception to handle. Haven’t seen this before like, this week? Or not often anyway. I don’t know enough about web programming to know what the cause is likely to be, either.

Update: although I’ve made some progress on this issue, it continues to be a major problem.

Right now, a version of it is affecting image fetching (which doesn’t go through the requests library, just urllib3) in a way I’m finding tough to debug.

I have limited time and energy for this problem at the moment. Due to this, Frank will be much less reliable for an unknown (though hopefully short) period of time.

hymneminium:

nostalgebraist:

Sorry that Frank was down for a while this evening…

I’ve been having a lot of issues lately where my http requests to tumblr will just hang indefinitely, without the python requests/httplib libraries raising any kind of timeout-related exception.

When I ctrl-C the script and restart it, it works again, but I don’t know how to simulate this manual step automatically, since I’m not given an exception to handle. Haven’t seen this before like, this week? Or not often anyway. I don’t know enough about web programming to know what the cause is likely to be, either.

You have to explicitly specify a “timeout” keyword argument for each request to stop that from happening. See https://docs.python-requests.org/en/latest/user/quickstart/#timeouts:

You can tell Requests to stop waiting for a response after a given number of seconds with the timeout parameter. Nearly all production code should use this parameter in nearly all requests. Failure to do so can cause your program to hang indefinitely.

I don’t know why this is the case.

Thank you, that’s what I was missing! Didn’t know the requests library had no timeout by default.

I’ve now attempted a fix, though only time will tell if it worked. Although, since the issue has been happening multiple times a day, it won’t take that long…

When I get time for it, I’ll integrate timeouts/retries into pytumblr2 as well. And then when I get even more time, I’ll move Frank over to actually use pytumblr2, rather than using the original code I cleaned up to create pytumblr2.