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?
Introduction | https://epiktistes.com/introduction |
---|---|
GitHub | https://github.com/toddsundsted/ktistec |
Pronouns | he/him |
馃寧 | Sector 001 |
Happy New Year, happy new release! 馃巼
1.15.0 is out with a new, efficient event loop, support for MinGW-W64 and MSYS2, improvements for BSD platforms, and many more features.
Watch out for the formatter changes, they'll likely affect your codebase!
@jayvii i just discovered your introduction page. i liked it so much i copied the idea!
I've been on the Fediverse since January 2017. I initially ran a single-user instance of Mastodon. In March 2020 I started to write Ktistec, my own implementation of an ActivityPub server in Crystal (a language with the ergonomics of Ruby but the speed of Go) because I wanted something more supportive of writing. This #introduction was written and published on Epiktistes, my Ktistec instance.
I'm an Engineer by training but now I run teams for companies in climate-tech.
I love #music, #sciencefiction and #fantasy literature (yes, I'm an R. A. Lafferty fan), attend fan conventions like #worldcon and #dragoncon, and do regular #weightlifting. I am also learning to play the #bagpipes, and I'm (re)learning #japanese.
Migrated a simple API endpoint from #Rails to #Crystal (#CrystalLang) using the #Marten web framework. It鈥檚 incredible to see a web application running on just 2MB of memory鈥攈ard to imagine that鈥檚 even possible!
PS: Congratulations on the release of Crystal 1.15!
The prologue to this post, and other posts in the series, is here.
Investigating commit b65d292f was fruitful but not for obvious reasons.
Dumping the symbols (nm -j server
) before and after the commit showed large number of new equality (==
) methods. From the diff:
1765a1772 > _*ActivityPub::Activity::Accept#==<Translation>:Bool 1920a1928 > _*ActivityPub::Activity::Add#==<Translation>:Bool 2062a2071 > _*ActivityPub::Activity::Announce#==<Translation>:Bool 2237a2247 > _*ActivityPub::Activity::Block#==<Translation>:Bool ...
The use, in a controller action, of the new Translation
model seemingly triggered their generation. What was going on?
A long time ago I implemented a MVC model framework in the style of ActiveRecord (2de4a4b3) and it included a method for testing for equality. Note the method signature.
# Returns true if all properties are equal. # def ==(other : self) {% begin %} {% vs = @type.instance_vars.select(&.annotation(Persistent)) %} if {% for v in vs %} self.{{v}} == other.{{v}} && {% end %} self.id == other.id true else false end {% end %} end
The Reference
class鈥攖he default parent for classes鈥攄efines two base implementations of this method:聽 one that tests for identity (not equality), with the signature def ==(other : self)
, and another that returns false
, with the signature def ==(other)
. When I implemented my method, my assumption was: redefine the former for model classes and let the latter take care of everything else. This assumption was incorrect.
In circumstances that I still don't completely understand, the compiler will generate calls to the latter (the method that just returned false
) when it "should have" been calling the former, and comparisons failed when they should have succeeded. I "fixed this" with commit effeaa26 that removed the type restriction and explicitly handled the type check. Everything worked!
The problem is Crystal creates a version of this method for every possible model comparison, specialized by both self
and other
. Most of the time the type check fails and the method returns false
. But the rest of the code is still present.
The fix (re)adds a method specialization that returns false
and lets the compiler handle the type check.
# Returns `false`. # def ==(other) false end
Because this method just returns a constant value, the compiler gets rid of the method call, as well.
Interestingly, this change reduced the size of the Ktistec server executable by 4.0% when building without the --release
flag but only 0.2% when building with it, so optimization does a good job at cleaning this up even without the change.聽
my content filters are getting a聽workout today...!
what's the union of all errors that a call like HTTP::Client.get(...)
(in Crystal) might raise?
i typically rescue IO::Error
(which gets hostname lookup and socket connection problems), OpenSSL::Error
(which gets a few edge-case problems with SSL configuration on the other end), Compress::Deflate::Error
and Compress::Gzip::Error
(which gets a few even more edge-case configuration problems on the other end), and URI::Error
.
what am i missing?
I've been wanting to start up a blog again for a while. So I finally did, using Ktistec by @toddsundsted.
Since Ktistec uses ActivityPub, you can follow @jamie@jgaskins.blog if you want to read it.
Ktistec release v2.4.4 fixes a few things in the prior release and introduces at least one killer feature!
Fixed
Changed
I'm spending some cycles looking at the size of the server executable. You can read about my approach to reducing Crystal Language executable size and build time here.
The prologue to this post is here.
Investigating commit e2327eea might be a bust.
I dumped the symbols before and after this change. The new symbols were all specializations of the core library Hash
class introduced by adding JSON parsing support for the "language" property.
So what does that mean and why is this commit a dead end?
You can think of Crystal classes and methods as being implicitly generics. If you have a method foo
with one parameter bar
and call it with an Array
, Crystal creates a version of that method specialized to handle an Array
type as an argument. If you call it with a Hash
, Crystal creates another version of that method specialized to handle a Hash
type as an argument. If the method has 20 lines of code, you effectively get two copies of those 20 lines of code. There is no runtime polymorphic dispatch, which is one of the reasons Crystal is so fast. You can make all of this explicit with Crystal type restrictions, method overloading, and generics, of course, but you don't have to.
This path is a dead end (for now) because any improvements that I can see that I can make (replacing hash construction with a more fluent sequence of attribute assignments) will need to be made to other classes where this is a problem, and there are only a few of those, so the net potential for improvement seems small.