11:56 <farkuhar> beerman: i think the surprising behaviour of prt-get update -fr foo bar (when either foo or bar is not installed) can be traced to line 607 in prtget.cpp. The code path that checks whether packages are installed doesn't get executed if you give prt-get more than one pkg name.

12:12 <farkuhar> before constructing a patch, it would help to have a definitive idea on what would constitute "smarter" parsing of such a command. Do you want it to stop and report an error if ANY pkg given on the command line is not installed? continue with the update operation for those packages where it makes sense, but report a warning about the other packages?

12:56 <beerman> all i can voice is my personal opinion: if prt-get update foo fails because foo is not installed, and prt-get update foo bar attempts to update foo even if bar is an invalid ports name

12:57 <beerman> i would rather expect it to throw an error to say foo is not installed and bar is shite

12:57 <beerman> but thats without having spend more thoughts on the topic either, i had to do a few commits and i am not done but now i am putting crux aside for real life activities ;)

12:58 <beerman> at least after rebasing contrib, which should be a quick matter

13:43 <farkuhar> noted, thanks for the input. Based on my current understanding of prtget.cpp, it's probably not too hard to implement the behaviour you expected. I'll work on it later, after real life activities of my own ;)

14:36 <jaeger> I would also expect prt-get to stop with an error if you tell it to update a package that is not installed

15:31 <jaeger> httpup has a bug in it that gcc 11/12 don't like: http://ix.io/3Yn7

15:32 <jaeger> I've worked around it in 3.7 core for now but if someone more well-versed with c++ knows the proper fix, let me know

15:59 <groovy3shoes> jaeger, i think you might need to change line 92 to `delete[] pwd;` (i found a nearly identical issue here, albeit with a much more helpful error message attached: https://github.com/bazelbuild/bazel/issues/1347 )

16:00 <braewoods> yep, delete[]. it's moot for this data type since it's a simple builtin but for consistency it needs to be delete[].

16:01 <braewoods> the allocators for arrays and scalars are different and all

16:02 <braewoods> weird though. why are they using new[] for such a trivial static allocation? hm.

16:02 <braewoods> stack based would make more sense.

16:05 <braewoods> oh wow this utility is so ancient

16:05 <braewoods> yea. a stack buffer would make more sense for this situation.

16:05 <braewoods> I have no idea why they chose this approach.

16:06 <braewoods> Cisms sometimes make more sense even in C++.

16:07 <groovy3shoes> if i had to guess, i'd say it's to avoid permanent space in the main() stack frame for such a brief need. but 256 bytes isn't so much, so i dunno.

16:08 <braewoods> that makes little sense. they do use one above for urlBuf in the main.cpp file

16:08 <braewoods> in any case i'm preparing a patch to refactor this code section

16:10 <braewoods> stack buffers are so generous these days, 1K isn't enough to worry about

16:10 <groovy3shoes> yeah

16:10 <groovy3shoes> and it's not like there's no cost to allocating/deallocating

16:11 <braewoods> stack avoids the cost of cleanup and more

16:11 <braewoods> jaeger: https://dpaste.com/7FNU93E4A

16:11 <braewoods> that should simplify it

16:12 <braewoods> i can't say i understand the reasoning of the original author for this. i always use stack buffers for small or temporary data stores

16:13 <braewoods> new would make sense if the data was intended to persist but it isn't.

16:13 <braewoods> the end result is just copied into a C++ string object

16:25 <jaeger> ok, will take a look in a bit

16:25 <jaeger> thanks for checking it out

17:12 <jaeger> That seems to work fine, thanks again. I'll get that into httpup.git and make a new release for it soon

17:23 <jaeger> any objection to me mentioning your name in the changelog?

17:40 <braewoods> jaeger: not really

17:41 <braewoods> honestly get the feeling a lot of the ancient crux source code should be rebuilt with plain C seeing as people seem to find the C++ implementation unapproachable

17:53 <jaeger> Agreed. I started a full rewrite of pkgutils in C but have limited time to pursue it... with that said, maybe a more attainable goal for the short term would be to rewrite or replace prt-get in C first, then expand later

17:57 <braewoods> jaeger: i was also considering whether something like Lua could be a useful addition since it's a proper scripting language unlike shell. allows for stuff that is hard or impossible with shell.

18:00 <braewoods> I've been writing Lua -> C bridge code for awhile and it's pretty simple to do. I was surprised.

18:02 <braewoods> It could make the utilities more approachable for regular scripters. Main reason it seems interesting.

18:43 <jaeger> worth thinking about, at least. I've never done any plugin or scripting language integration with C so no idea how that works

23:27 <beerman> i like that idea 👍️ also good catch and fix, nice work everybody