This action will delete this post on this instance and on all federated instances, and it cannot be undone. Are you certain you want to delete this post?
This action will delete this post on this instance and on all federated instances, and it cannot be undone. Are you certain you want to delete this post?
This action will block this actor and hide all of their past and future posts. Are you certain you want to block this actor?
This action will block this object. Are you certain you want to block this object?
commits 984e28b7 through a367c215 include changes that support following threads, hashtags and mentions:
next up is support for actively finding and fetching followed content from elsewhere in the fediverse.
also included are a bunch of bug fixes, some internal enhancements, and greatly reduced build times and executable sizes.
the crystal programming language always inlines blocks, which is great for performance but trades off space for speed. using blocks effectively means keeping this in mind.
somewhere along the line, i learned the habit of passing a block to a function as a means of customizing the behavior of the function. if the function that takes the block is large, it's important to remember that the body of the function is inlined where the function is called, which may not be what you are expecting. if you call the function multiple times, you even get multiple copies.
i just committed code that fixes an egregious example of this problem. in this case these ~30 lines of code replace the blocks with procs (which aren't inlined) and cut ~24mb (that's megabytes) off the executable (over a third of its size).
i regularly shoot myself in the foot trying to be clever, so i don' t know how prevalent this problem is in practice, but it's definitely something to keep in mind, especially if you see compile times and executable sizes growing!
one of the crystal programming language’s greatest strengths is the ease with which you can work with c apis and external libraries without leaving crystal. you can even implement callbacks in crystal!
in sqlite you can define new functions—callable from sql—with sqlite3_create_function
by providing a name and a callback that implements the function. i created a new function called strip, entirely in crystal, that removes html markup and leaves text. it can be used in a sql query like so:
select * from objects where strip(content) like "%term%"
it’s part of the recently released content filtering code.
I just released v2.0.0-8 of ktistec. The most impactful changes are:
Volume has dropped off in my timeline, for the most part, now that the surge of people who signed up for Mastodon accounts a couple months ago have gone back to posting on Twitter, or have stopped posted about the transition, or whatever. But fine grained control is nice, and filtering allows me to tune my experience—better late than never!
Read the changelog for all of the details.
i released 2.0.0-7 just in time for the new year. it includes contributions from @relistan and @rahul, the introduction of CI (the build is successful), and bug fixes.
i am slowly working my way toward more flexibility for reading and managing federated content.
#ktistec (as always, it's pronounced "tiz-tek")
(i should probably just add support for mastodon style polls to ktistec...)
i have an informal poll for ktistec users. should we require (and use features from) the most recent versions of sqlite? how recent is too recent? if you're running ktistec, i'd love your point of view.
some background... sqlite is the most significant dependency in ktistec. to minimize problems for potential users, i intentionally stuck to features found in "older" versions of sqlite. as i write this, the current version of sqlite is 3.40.0. ktistec only depends on 3.11.0, which was released in 2016. that's very conservative.
Today's release of code fixes things that have been annoying me for a while:
nil
and other garbage was not. Lesson learned? We'll see...getter
(which is, effectively, a read-only property). Previously, this code wouldn't even compile, thereby unintentionally coupling database persistence and bulk assignability.i built @relistan 's branch this morning and tried out ktistec support for mastodon profile metadata. the attachment shows profile metadata pulled from the ruby.social mastodon instance, as well as @relistan 's own personal ktistec instance. this is something i've wanted for a long time!
a shoutout is due both these two (the owners of the two profiles shown in the attachment): @alexanderadam has been posting encouragement about ktistec all year long, and maybe before—an intangible that's immensely valuable when you're banging away on open source software—and @relistan is the first person besides me to contribute major feature functionality to the project—which takes a huge leap of faith.
thanks!