jcolag
/
entropy-arbitrage
1
1
Fork 0
Code Issues 2 Pull Requests Packages Projects Releases Wiki Activity

Automated updates: 2020-06-08

This commit is contained in:
John Colagioia 2020-06-08 08:04:33 -04:00
parent a7b3a4f862
commit 6ec38faad0
2 changed files with 70 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
2020-06-07-updates.md
View File

@ -7,9 +7,9 @@ tags: [update, rant]
summary: Additional thoughts on earlier posts
thumbnail: /blog/assets/structure-pattern-line-art-nederland-rotterdam-473033-pxhere.com.png
update: [
2020-03-01-electability,
2020-03-29-copyleft,
2020-05-31-police
2020-03-01-electability.md,
2020-03-29-copyleft.md,
2020-05-31-police.md
]
---
@ -41,7 +41,7 @@ Because those serialization languages are (a primitive kind of) programming lang
Do I think that a court would find that some troll has the right to demand an AGPL-licensed service provider's API keys and encryption keys? No, of course I don't, so this isn't alarmist or an attack on people choosing the AGPL for their license; I'll continue to use the AGPL, myself.
However, a good copyleft license should have some guidance along the lines of "use CC0 or MIT for your configuration files that providers will need to change," alongside making a decision about what constitutes "source code" for a project.
However, in reference to my ["wish list" post]({% post_url 2020-03-29-copyleft %}), a good copyleft license should have some guidance along the lines of "use CC0 or MIT for your configuration files that providers will need to change," alongside making a decision about what constitutes "source code" for a project.
## On Electability and Complicity

66
2020-06-08-oceans.md Normal file
View File

@ -0,0 +1,66 @@
---
layout: post
title: Developer Journal, World Oceans Day
date: 2020-06-08 08:04:12-0400
categories:
tags: [programming, project, devjournal, uxuyu]
summary: Progress on assorted projects
thumbnail: /blog/assets/Nr_Vorupoer_2013-12-29_1_cropped.png
offset: -23%
---
Yes, I'm reaching for holidays, but using names of days instead of just early/mid/late-whichever-month makes it harder (for me!) to distinguish one post the next. Whereas, the difference between [Global Day of Parents]({% post_url 2020-06-01-parents%}) and World Oceans Day is useless for sequencing (which there's already a date for), but easier to tell that they're different in a list.
![The Atlantic Ocean](/blog/assets/Nr_Vorupoer_2013-12-29_1_cropped.png "The Atlantic Ocean")
Plus, there are multiple celebrations/remembrances every day and the fixed observances will change day of the week from year to year, making it less likely to repeat a post title.
So no, this isn't the "I checked the calendar, and you might be interested to know..." shtick. Though if you decide to celebrate [Culture Freedom Day]({% post_url 2020-05-18-freecul %}) in future years because of the post, that's a handy side-benefit.
## Uxuyu
Anyway, after a long time nibbling around the edges, **Uxuyu** has finally moved forward, again, and I actually got to work on it all week. The account thread's "status check" now returns all known accounts to the main thread, and the non-followed threads are also checked, though not as frequently as the followed accounts.
And, because of that, *mentions* now work...or, rather, they work as well as the user interface will easily allow. This still needs more work to be able to *read* the mentions, but after a heap of refactoring, since the non-followed feeds are processed in the same way as the followed feeds and **Uxuyu** pulls out URLs and referenced accounts in each post, it's now possible to pull out any reference to the user's own feed.
With *that* handled (and yet more refactoring and catching a few bugs), the list of mentions gets pushed to the mention panel, where each post is converted to a button with the user's name and how long ago the local user was mentioned.
Then, some sleight of hand!
You see, I had two problems at this point: There's still no scrolling in [Proton Native](https://proton-native.js.org/#/) and now there are buttons to show mentions in feeds that aren't otherwise displayed, with nothing for them to do. Conveniently, they have the same solution...*paging*.
That is, all things being equal, running **Uxuyu** (as of Thursday) on my laptop only shows the most recent eleven posts of the people I follow *or* any specific person I follow. So, I've updated my twtxt configuration file (`limit_timeline`) to only show the most recent eleven posts. However, if I slip a page number into the `state`, I can get the fiftieth page by showing the eleven posts starting with (11 x 49) #539, ending at #550.
And with *that* set into place, I can now show any run of eleven (or whatever the local `limit_timeline` is) posts from any user, by changing the page number along with the user. At the same time---and with much less work---I can add "older posts" and "newer posts" buttons to page through the history.
The user needs to configure the number of posts separately, unfortunately, since I have no way of knowing how many post fit on the screen. But that's still not terrible, and I can (and should) eventually add an **Uxuyu**-specific configuration file to override my default colors, font size, and so forth. And that option can be done away with, once Proton Native is more ready for that sort of work.
## Other Discoveries
Since I have been using [Visual Studio Code](https://code.visualstudio.com/) more frequently (the tools are better than working manually, of course, but it's much more difficult to look at multiple projects at the same time), I started wondering *how* "free" it is in terms of being Free Software.
It turns out that it's *very* close, but the Microsoft builds include telemetry features, which isn't really optimal. Conveniently, somebody already did this thinking, creating [VSCodium](https://vscodium.com/), saving me from wasting my time trying to build the application, myself.
The two applications don't share configuration files, so I needed to make changes---such as using [Victor Mono](https://rubjo.github.io/victor-mono/) and setting the comments to show as italicized---but now I shouldn't need to worry about Microsoft slipping anything creepy into their builds.
Unrelated to VSCodium, it appears that my recent computer slowdown woes have largely been due to...[gPodder](https://gpodder.github.io/)? It sounds bizarre, but I caught it taking a third of one CPU core. And shutting it down when I don't need it has resulted in fewer crashes. It's a shame, because I like (and highly recommend) gPodder, but this temporary solution'll work well enough for now.
## Next
It looks like **Uxuyu** might be getting close to some sort of "minimum viable product," which will be interesting to announce, when the time comes. But there are still a few major features that need to be put in.
* The most important step is probably going to be to start scraping the major twtxt user registries, automatically discovering new users.
* Probably the easiest feature would be adding an external configuration file---just like I already do for [**Miniboost**](https://github.com/jcolag/Miniboost)---to override my application defaults; the existing configuration options are in an object specifically to support this feature, in fact. At some point, it *might* even be useful to move all configuration into the **Uxuyu** file, so that there's no need to install twtxt at all, for people who want to avoid it for whatever reason.
* Before trying to cut ties with the twtxt application, though, I need some sort of user management, to follow and unfollow users.
* Now that all discovered feeds (as far as I can tell) are being pulled, it should be easy to add a *search* facility, possibly even extending the filtering currently used to limit messages to followed accounts or a specific user. Similarly, it should be easy to add a "firehose" feed of every post available.
* It's probably a good idea to "age out" feeds. That is, if a feed no longer seems to be available or hasn't been updated in a while, it makes sense to start checking it less frequently, so that the thread isn't wasting time looking for updates that aren't there. I'm already checking the last time the feed was found and the last post date in the database, so it shouldn't be too hard to come up with a formula that doesn't waste client resources pulling data that probably isn't useful.
Will I get to all of these in the near future? Probably not, and certainly not this week. But at least a few of these should be compelling enough to make happen sooner than later, with account management likely being the lowest priority; anybody who's willing to run **Uxuyu** from the command line can also edit the configuration file to add someone's timeline, if they *really* want.
And I still have other projects. I may start creating repositories so that I can try browser plugins, Visual Studio Code (or VSCodium) plugins, and so forth, since those are a big part of an upcoming project idea.
On top of that, I see it's time to upgrade a couple of packages, so that'll probably happen, too.
* * *
**Credits**: The header image is [Coast of Nørre Vorupør at sunset](https://commons.wikimedia.org/wiki/File:Nr_Vorupoer_2013-12-29_1_cropped.jpg) by [Slaunger](https://commons.wikimedia.org/wiki/User:Slaunger), made available under the terms of [Creative Commons Attribution-Share Alike 3.0 Unported](https://creativecommons.org/licenses/by-sa/3.0/deed.en).