(replying to felix because it seems Stanislav's email was not replied-to-all and I can't see it in my inbox, only in the archives)
> When people submit patches they did not write to the code they don’t understand, the burden on maintainers increases tremendously. 100% agree with you. I think the key here is to differentiate between AI slop and AI-assisted coding by someone that could understand and vet the output. IE was AI used as a proper tool to get to an outcome faster? or was it used blindly to just generate something without care? Best, Rolando On Mon, Feb 9, 2026 at 2:17 AM Felix Winkelmann <[email protected]> wrote: > (At Peter's suggestion I forward this to the mailing list, as the > discussion may > be of interest to other contributors. We don't have a policy regarding LLM > usage yet, but need to make up our minds on how we approach this in > general. > > Note that this does _not_ mean a lack of trust in you or your > contribution, but > reviewing LLM-assisted code is a new and somewhat unsettling experience to > me, and > I'm not quite sure how we want to handle this in the future) > > On Mon Feb 9, 2026 at 5:07 AM CET, Rolando Abarca wrote: > > Hi Felix, > > > > Thanks for taking the time to review this! > > > > I'll look into the code cleanup suggestions, the points about removing > the > > unnecessary #ifdefs, the _VAL macros, and the redundant clause in > > url-protocol all make sense. I'll also look at the error handling in > > make-ssl-input-port and the static build approach you suggested. > > I really like the idea of including and using cond-expand to add it or > not. > > I'll play with that. > > > > To answer your question: yes, I used LLM assistance (Claude Code) for the > > initial research to understand the codebase and figure out what the > > implementation would entail. From there I created a manual plan for how > to > > approach it and had the AI run with it. There were a few manual fixes > along > > the way, but to my non-expert eyes it looked good enough to share as a > > proof of concept. > > > > I appreciate the thorough review, I'll work through your suggestions and > > follow up. > > > > Cheers, > > Rolando Abarca > > > > > > On Sun, Feb 8, 2026 at 3:42 AM Felix Winkelmann < > [email protected]> > > wrote: > > > >> Hi, Rolando! > >> > >> I finally got around to reviewing this, sorry again for the long delay. > >> I have a few questions and suggestions regarding the code. > >> > >> Always building the ssl module in dynamic mode is problematic when > >> CHICKEN is built statically. It would be better to compile it > conditionally > >> and link it to chicken-install (excusively). An alternative would be > >> to "include" it (similar to egg-download.scm). You could then avoid the > >> eval-trick, for example by using cond-expand, after adding a feature > >> to the build of chicken-install. > >> > >> SSL support needs to be activated explicitly, I guess it would be fine > >> to enable it by default, if the configure script succeeds in testing > >> for ssl availability, since your checks are quite thorough. > >> > >> In egg-download.scm, the 2nd clause in url-protocol seems to be > >> redundant. > >> > >> In ssl.scm, the #ifdefs are not needed (it is built only when SSL > >> is available, anyway). Also the "..._VAL" macro defs are not needed, > >> you can use the constants from ssl.h directly. Also, the function > >> prototype for get_tcp_fd is unnecessary, I think. make-ssl-input-port > >> does not handle other errors besides the _want_... cases, is this > >> intentional? > >> > >> One question: did you use LLM assisstance for this code? Some of > >> the redundancies seem to indicate that. That is not indented to > >> diminish your effort (I'd very much like to add this feature to > >> CHICKEN), just to make sure with what amount of diligence I should > >> review the code. > >> > >> > >> cheers, > >> felix > >> > >> > >
