Hi Felix (and chicken-hackers), Thanks for bringing this to the list. I think it's an important conversation to have.
First, I want to be clear: I'm totally fine if this doesn't get merged. The feedback you've already shared has been incredibly valuable, and that alone made the exercise worthwhile. Getting insight into how CHICKEN's build system works, the static vs dynamic considerations, and the cond-expand approach... that's exactly the kind of learning I was hoping for. On the broader topic of LLM-assisted contributions: I work in BigTech, and I can tell you things are moving faster than most people outside these environments would expect. AI-assisted development is becoming the norm, not the exception. I think the CHICKEN community (and really, any open source project) will need to figure out how to handle this sooner rather than later. One idea: what if there was a way for agents to self-check contributions before submission? Something like a CONTRIBUTING_AI.md or similar document that outlines the specific code quality concerns, style expectations, and common pitfalls. An agent could review the PR against those criteria before a human even sees it. This wouldn't replace human review, but it could raise the quality bar and focus reviewer attention on what matters most. That said, if the community isn't ready to tackle this now, I completely understand. This work isn't blocking anything critical. It started as a personal exploration to learn CHICKEN's internals, and it served that purpose well. But if there's interest, it could also be an opportunity to start thinking through how the project handles this new wave of contributions. Either way, I appreciate the thoughtful engagement. Cheers, 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 > >> > >> > >
