Projects: Slackhammer, ZACL, testing Perl on Slackware-current

I try to stay focused on a small number of projects at a time, so that they get finished sooner, but I seem doomed to spread myself thin.

Slackhammer

Sometimes it's because someone gives me a nudge and gets me all excited. Earlier this week, Idlemoor pointed me at https://release-monitoring.org which tracks packages' upstream sources, which is one of the core functions of my Slackhammer project http://ciar.org/ttk/codecloset/slackhammer/

Work on Slackhammer had been slow and tedious, since I was having to track down the upstream sources of all of Slackhammer's packages one by one and make an entry for them in its package-tracker metadata. I was about a quarter the way through them when Idlemoor pointed out release-monitoring.

By mapping Slackware package names to Fedora package names, I was able to use the release-monitoring API to look up the upstream URLs for hundreds of packages. The mapping was straightforward for many packages (Slackware and Fedora both use "htop", for instance), but others had no equivalent, while others were more complex. Slackware has separate packages for different BerkeleyDB packages (db42, db44, db46, db48) whereas Fedora just has one (db4).

Nonetheless, I was able to automate a large part of the process, and now I only have about four hundred packages to go .. well, sort of. The release-monitoring data provides URLs for the upstream home page, not always for its download page, which is what Slackhammer needs. So there's still some massaging of data to be done there.

I'm stoked. The last few days have seen more progress on Slackhammer than it's seen in a year.

ZACL

In other news, I've been working on my ZACL project too ("ZACL's A Concurrency Language"), continuing to hammer out the formal grammar. It's a lot of work, and avoiding logical ambiguities gets harder the larger it gets.

The main gist of ZACL is to preserve as much of the expressive power of dynamic languages like Python and Perl as possible without sacrificing compile-time problem detection and allowing for a leaner run-time.

To that end it is a "gradually typed" language (https://en.wikipedia.org/wiki/Gradual_typing), which means the programmer can use strict types in some places for superior performance and compile-time checks, and dynamic types in other places for more rapid development time.

The other main point is seamless support for concurrency, such that other process' public data structures can be operated upon as though they are local, with any necessary message-passing happening behind the curtains. The expression "foo + bar" might compile to a simple "add" instruction if both "foo" and "bar" are local, or it might compile to a remote procedure call to fetch one or both from a different process, potentially from a different host.

I'm loathe to start on the lexer/parser until there's a fully fleshed-out grammar, since it's easy to paint one's self into a corner, but earlier this week I found a project with a very nice, small, easy-to-read lexer/parser, implemented in C, which should be easy to build upon to make a ZACL lexer/parser -- mujs https://mujs.com/

It's a tiny javascript compiler for embedded scripting, and javascript's grammar has some significant differences from ZACL's grammar, but I think modifying mujs might be less work than writing something from scratch.

Slackware-current

When the development branch of Slackware upgraded to Perl-5.28, I said I'd help test it, but I only got around to setting up a dedicated Slackware-current test system last week, on a used laptop I picked up on eBay for the princely sum of $15.

I like short hostnames, so "amp" seemed like the obvious name for a host running "-current" (hyuk, hyuk). I whacked together a test framework and it's testing/installing its way through all of the thirty-two-thousand Perl modules on CPAN.

At the rate it's going, it's going to take weeks to test them all, and I need to come up with some software to distinguish between relevant and irrelevant failure modes. Some will fail due to a dependency on a library not included in Slackware, for instance, and I don't care about those. I'm trying to detect failures which might be caused either by Slackware as a platform or by the changes specific to Perl-5.28.

I'll be journaling the effort sporadically in this LQ thread -- https://www.linuxquestions.org/quest...nt-4175632527/

Wikipedia

You know that xkcd punchline? "Someone is wrong on the internet!" https://xkcd.com/386/ Yeah, I'm prone to that a little, and sometimes it goads me into trying to make the internet a little bit of a better place.

Most recently, on Wikipedia.

One of my side interests is materials engineering and composite armor. I've spent the last twenty years educating myself on it, and maintain a website where I try to keep relevant reference material organized (though I've fallen waaaay behind on that, with gigabytes of material waiting to be uploaded and curated) -- http://ciar.org/ttk/mbt/

So there's this Wikipedia article on "Sloped armour" which waaay triggered my "someone is wrong on the internet" urge. https://en.wikipedia.org/wiki/Sloped_armour

The authors have tried, but the article's a bit of a mess. It's not their fault, as it's a complex topic, with a lot of plausible-sounding myths floating around. Part of the problem is that it's often not understood that the physics of interacting objects is different in the "ballistic" and "hypervelocity" velocity domains, and the page addresses the behavior of munitions ranging from the WW2 era (when velocities were primarily in the "ballistic" domain) to the modern era (when velocities are primarily in the "hypervelocity" domain).

It does have a link to the Wikipedia page on "Hypervelocity", but this page too suffers from problems. It's a stub, and deals primarily with other discipline's definitions of "hypervelocity", with the military definition tacked on as an after-thought, and woefully incomplete.

So I've been thinking I should perhaps start there, and flesh out the "Hypervelocity" page so I can link to it from additions in the "Sloped armour" page. Hopefully it will make the counterintuitive and sometimes contradictory effects of armor slope clearer.

Graphing Ballistics Calculator

On a related note, I've been working on some software I've been meaning to write for years, a graphing ballistics calculator which wraps my published Physics::Ballistics CPAN module -- https://metacpan.org/pod/Physics::Ballistics

The inspiration is the Renegade graphing ballistics calculator, here -- http://ipgeneral.com/~renegade/rifle/rifle1.shtml which I use frequently to explore the GPC concept -- http://www.ciar.org/ttk/blog/index.c...Water_E3674803 and other related ballistics issues.

Renegade is nice, but it has some significant shortcomings that keep chafing me. I frequently want to model multiple cartridges on the same graph, for instance, and Renegade only allows one user-specified cartridge to be graphed with any number of their pre-prepared "standard" cartridges. Also, sometimes I want to graph estimates of lethality and bullet penetration, but Renegade only provides velocity and energy graphs, which are sort of relevant to lethality and penetration, but mostly not. There's also no way to normalize its "stock" cartridges to a particular barrel length, which changes the initial velocity.

All of this functionality is provided in Physics::Ballistics, but it lacks a convenient interface and an easy way to generate graphs, so I started writing a separate Physics::Ballistics::Calculator module that provides these things.

I could have written it as part of Physics::Ballistics, but it drags in some external dependencies which the rest of Physics::Ballistics doesn't need, like Chart::Gnuplot (which might pose an obstacle to potential Physics::Ballistics users who don't have or want gnuplot on their systems). Keeping it separate minimizes extraneous dependencies in Physics::Ballistics.

It's about two-thirds the way written now, and I'm quite pleased at how it's coming together. I'll be hosting a webapp similar to Renegade's when it's ready.

RedisMQ

Database-as-IPC is a common anti-pattern, but sometimes it just makes sense to leverage existing infrastructure as the basis for new capabilities. There's a gap in the message-passing world for lightweight, easy-to-use message-queuing through a central server, and Redis' pub/sub functionality makes it seem like a shoo-in for such a purpose.

I looked around, and found a half-dozen other RedisMQ-like projects, but they are in many different languages and are all mutually incompatible, and they all have shortcomings that made me curl my lip a bit.

So I feel totally justified in making my own incompatible RedisMQ in yet another language (Perl) which addresses those shortcomings. It's coming right along. Redis is fast and easy, and its blob-store capability makes it easy to organize message queues and consumers in queryable ways (one of the features I liked about PVM, back when that was still viable).

It won't be as fast as ZeroMQ (which doesn't use a central server at all), and it won't be as flexible as Messaging-via-HTTP (which is slow as hell), but I think it might serve me well.

* * * * *

Sometimes it seems like I spread myself too thin to ever get anything done, but things do get done, slowly but surely. My modest list of published CPAN modules is growing, so I can look at that to convince myself that progress is indeed happening -- https://metacpan.org/author/TTKCIAR

Looking at that now, it reminds me that I have some half-finished work teaching Algorithm::CurveFit::Simple how to make piecewise functions, which I will need to finish my ongoing work on Physics::Hardness. It's never going to all get done, I fear, but we'll see.