15:20 <farkuhar> braewoods: my intention with pkgmeek was to make something a little more maintainable than what we're currently using. When I took on the task of adding renaming functionality to pkgmk last year, the primary stumbling block was just how disorganized it had become, after accumulating so many patches over the years.

15:27 <farkuhar> it turns out that nearly every feature added as a patch over the years can be implemented in 560 LOC (50 of those lines being comments). Also I got around to tackling FS#1851 and FS#1763, the first of which has gone more than a year without any action in our bugtracker.

15:31 <braewoods> farkuhar: I see. Do you have any experience with C?

15:32 <farkuhar> dlcusa: thanks again for taking a look at the script and sharing your preliminary impressions. The last 24 hours have been a sprint toward ironing out the bugs, and I encourage you to try the latest version in my git repo.

15:34 <farkuhar> braewoods: alas, I've only worked with a handful of codebases written in C. would be willing to learn more sometime, though.

15:34 <braewoods> The other half that could use an overhaul is the C++ code that's all over the crux source repos.

15:35 <braewoods> Unfortunately it's even rarer to find programmers that can handle that. I'm probably the only one around here.

15:37 <braewoods> One thing that bothered me was the lack of reusable code for common stuff like database access.

15:37 <braewoods> everyone just rolls their own.

15:37 <farkuhar> I was actually considering as my next side project a rewrite of pkgadd in Perl. Isn't there a flavor of BSD that uses Perl for its package/ports manager?

15:38 <braewoods> You may be thinking of Debian. APT uses Perl extensively.

15:38 <braewoods> I've looked at the Perl C API before. It's a mess from what I recall.

15:39 <braewoods> If I had to choose any language to extend with it'd probably be Lua. It's easy to learn and has a very simplified C API for extending it.

15:40 <farkuhar> Anyway, my first step towards realizing that rewrite was to grok the source code of pkgadd. I posted my notes in a revised manpage: https://git.sdf.org/jmq/Documentation/src/branch/master/man8/pkgadd.8

15:49 <farkuhar> I take your point about not reusing a common codebase for database operations. Although pkgadd and prt-get do outsource their database operations to a shared library, the other tools just roll their own, as you said.

15:52 <farkuhar> s/prt-get/pkgrm,pkginfo/

15:55 <braewoods> i'm considering making the C++ code into a C + Lua setup. Maybe turn pkgutils into a Lua script after that.

15:56 <braewoods> Lua mostly because it's friendlier to scripters and easy to integrate with. I've started using Lua to make my C programs better.

16:11 <farkuhar> if i'm understanding correctly, the C part would be a thin layer providing filesystem operations and database transactions, while the user-facing aspects of pkgutils are all in Lua?

16:17 <braewoods> more or less. the stuff that's expensive or hard to do from Lua.

16:17 <braewoods> Though most of the heavy lifting is already done by libarchive, there's still some intensive processing on the C++ code.

16:18 <braewoods> the idea is i would create Lua modules that can be reused by other scripts. the modules would be written in C.

16:22 <braewoods> Lua would be leveraged to greatly simplify things like memory and resource management since you can hook into the GC and more to get something similar to C++ destructors.

16:22 <braewoods> as well

16:23 <braewoods> userdata and metatables can be leveraged to create C modules with an OO interface on the Lua side

16:35 <braewoods> the idea i was having is to make it more approachable for our typical users to contribute something. having more code in a scripting language would probably help that a lot.

16:37 <braewoods> the C parts should probably be code that rarely needs changing

16:45 <braewoods> one thing i'm thinking of adding that current pkgutils doesn't provide is the ability to rollback an interrupted database operation

16:53 <braewoods> e.g., power loss during a pkgadd/pkgrm operation