Replies

This profile is from a federated server and may be incomplete. Browse more on the original instance.

tokyo_0, to random

Love is... sitting down to code at 9pm on a Friday night when you're actually exhausted and really don't want to code anything right now. 🤪

tokyo_0,

Just realised the other night I declared a variable to count seconds while waiting for console input, and instead of just using an integer I used a (larger capacity) long-type number variable instead.

If I'd used an integer it would've been good as long as my console prompt wasn't kept waiting over 68 years 🤪

(I was tired that night, too) 🤦‍♀️

tokyo_0,

I wonder if Mastodon will still exist in 68 years... 🤔😂

(I wonder if Gargron will still be holding out on building-in content portability 😬😅)

tokyo_0,

Trying to wrap my head around creating a store of posts where each has a unique id that won't change when reposted to a new instance, because what I want is for people (including me) to be able to incrementally build their archive of posts even if they move several times, but still have their own threads preserved correctly.

Was going to do it based on post creation date, but that will fail if an instance #2 post replies to an instance #1 (reposted) post. 🤔

tokyo_0,

I think it's definitely possible... just a little bit more complicated than I had been thinking.

Maybe the dates are only going to be useful for structuring the data in the file system in a user-readable way. Starting to think I'm going to need multiple pointers to a reposted post - so perhaps each post remembers the different ids it has had, and each time it's reposted the new id is added. Then all the replies will point to the right thing.

tokyo_0,

Oh, this is going to be exciting.

To "boost" a status, all you need is the id of the status you are boosting.

But that id is instance-specific. So if you're boosting it again on a different instance, how are you supposed to find the toot to boost? Even if you use the information from the earlier instance to find it on its own instance, you'd then have to find it on your new instance.

Not sure this can actually be done right now. But it must be possible. 🤔

tokyo_0,

There is a way... mwahaha. I've missed this.... this... being able to do something. Being able to create something that didn't exist, from nothing but my own idea and some very rusty programming skills. This mental challenge. ☺️

(And the way is to search for the url of the status that is to be boosted - which is included in the data from the old instance - and perform that search on the new instance specifying "resolve=true", and that gives you the new id.)

tokyo_0,

Improved parameter handling for consistency and to parse parameters entered in any order, and to fail with a helpful message if they are specified incorrectly.

(Did some work on the classes that will store post data as well today - going to shift back to that for a bit now I know I'm not writing a bunch of parameter handling code that I'll have to write again to tidy up later.)

tokyo_0,

Oh my god... the API includes the full profile details of the posting user for every single one of the statuses they posted (when you've asked for their statuses) in, like, a page of 40 statuses.

But to get the raw text of the status without the HTML Mastodon has added to it, you have to do an individual API call for every single one.

Surely this can't be true 🤦‍♀️ It's late.... I must be missing something... 😂

tokyo_0,

Seriously, who did this? 😂😂😂

Just as well I wasn't planning on maxing out my API calls, huh.

tokyo_0,

And I can't even access it in the browser to test because it needs an App token... lordy 🙃

tokyo_0,

I only have 757 statuses 🤔😅

tokyo_0,

Amid the many hurdles I've overcome on this project so far, little did I think what would wrongfoot me would be date formats.

I should've known better.

In 20 years, all they've done is made the Java date libraries more confusing. Now I have an "UnsupportedTemporalTypeException" and a "TemporalAccessor" and a problem with my "ChronoField"... it's like something out of Dr. Who.

tokyo_0,

"As such, an Instant cannot be formatted as a date or time without providing some form of time-zone"

Yeah that needs to be in the summary at the top of the Javadocs for Instant, not buried in the definition of a constant field in DateTimeFormatter. 😒

tokyo_0,

The beginnings of some post data, saved as an xml file in the right place in the directory structure.

Each post will be saved in a folder, named according to the date and time when the post was first created. Most of the post data will be saved in an xml file of the same name within that folder, but there will also be a folder for media.

The idea is that you'd be able to manually inspect or edit your post data if you wanted after saving.

tokyo_0,

Been too exhausted the last few days to even look at this, but I really want to get something working this weekend and ideally in a state where other people could test it. A lot of functionality I'd like to include may have to be skipped for that, but given the need it would be better to get a test version out sooner rather than later.

I might go mad if I keep spending every spare and usable waking moment on it for much longer, too. 🤪

  • All
  • Subscribed
  • Moderated
  • Favorites
  • megavids
  • thenastyranch
  • rosin
  • GTA5RPClips
  • osvaldo12
  • love
  • Youngstown
  • slotface
  • khanakhh
  • everett
  • kavyap
  • mdbf
  • DreamBathrooms
  • ngwrru68w68
  • provamag3
  • magazineikmin
  • InstantRegret
  • normalnudes
  • tacticalgear
  • cubers
  • ethstaker
  • modclub
  • cisconetworking
  • Durango
  • anitta
  • Leos
  • tester
  • JUstTest
  • All magazines