IRC Logs for #crux-devel Thursday, 2019-03-28

ryuojaeger: i see. i'm making up the library design as i go... truth is, i don't have complete perspective of every design constraint, so i start trying to build something more flexible, but may decide to use a more hard coded approach for something that is unlikely to change anytime soon.01:53
ryuoi found that my idea for a single function to handle the 2 package file modes of pkginfo seems difficult to do.01:54
ryuoand it needs to work independent of the database structure.01:55
ryuoi'm going to strip out some of the configuration stuff i was trying to do with the filename parsing01:55
ryuoit's not done often enough to benefit from the more dynamic regular expression appraoch.01:56
ryuoand it hasn't changed in 18 years.01:56
ryuoa hard-coded parser will still suffice.01:56
ryuoi was experimenting with using a RE pattern to allow it to be easily changed, but...01:56
ryuoit seems more trouble than it's worth. more variables to track, etc.01:57
ryuojaeger: with any luck, perhaps the new version in C will invite more contributions as a byproduct.02:07
ryuoi'm already seeing potential to replace some scripts with C versions.02:07
ryuoi may also add new frontends that don't require new dependencies02:08
ryuoa database checker could be useful.02:09
ryuochecking for database inconsistencies02:09
ryuoRomster carries some script called pkg-not i thought would be useful as a C frontend.02:09
ryuoit's somewhat slow to do in shell.02:09
ryuotek__: i think i'm done with my revisions to LXC. if i give you the tarball of the new packaging, could you find some time to review it?02:48
*** irclogger_do has joined #crux-devel10:49
ryuointeresting. not sure if it matters much, but the footprint mode of pkginfo can be sped up significantly if more RAM is used for caching information.15:45
ryuocurrently it does two passes through the archive.15:45
ryuoif you cache all the information you need from the first pass, you can then evaluate it faster on the second pass...15:46
ryuoin my tests, the caching technique cuts the time expended in half.15:46
ryuojaeger: should I use more caching in pkgutils? it increases RAM requirements but RAM is more plentiful than it was in 2001 or so when this was first written.15:47
ryuoeven 64 bit systems commonly come with 2G-4G these days.15:48
ryuoif my estimates are correct, a massive tarball the size of the kernel would consume around 8MB of extra RAM.16:25
ryuosounds like a worthwhile tradeoff16:25
ryuoi'm going to implement it and see what the actual RAM usage is.16:36
ryuowith any luck it could mean somewhat faster footprint generation.16:37
*** onodera has joined #crux-devel18:26
*** onodera has quit IRC22:24

Generated by 2.14.0 by Marius Gedminas - find it at!