On the topic of vibe coding...
long long rtapi_get_time(void) {
struct timespec now;
evl_read_clock(EVL_CLOCK_MONOTONIC, &now);
return (now.tv_sec * 1000000000LL) + now.tv_nsec;
}
/* src/rtapi/rtapi_evl.c - Simplified Fragment */
#include <evl/thread.h>
#include <evl/clock.h>
#include "rtapi.h"
int rtapi_task_new(rtapi_task_handle *task, int id) {
struct evl_sched_attrs attrs;
int efd;
// Create an EVL thread
efd = evl_attach_self("rtapi-task-%d", id);
if (efd < 0) return -1;
// Set priority (EVL uses 1-99)
attrs.sched_policy = SCHED_FIFO;
attrs.sched_priority = 80;
evl_set_schedattr(efd, &attrs);
return 0;
}
I could actually try tying this into LinuxCNC and building the Xenomai 4/EVL
kernel/userspace libs.
Alec
On Monday, March 16, 2026 at 07:18:03 PM CDT, Greg C <[email protected]>
wrote:
Good evening,
I've noticed recent mentions of "vibe coding" - rapidly coding a solution
in a short period of time with most of the code being completely AI
generated - on the forum lately. I've also noticed that some of these vibe
coded features have already been merged into our code base, and others
claim to have plans to create pull requests to add their weekend AI
adventures to the code base in an effort to give back.
Given that there are a limited number of developers who are available to
review the incoming changes, and even fewer that have the necessary
specific knowledge of the project, I think it's important to take steps to
protect the integrity and maintainability of LinuxCNC. The project has
hard earned reputation of reliability, and while there will always be bugs,
that reputation shouldn't be ruined by poorly understood or insufficiently
vetted contributions, regardless of intent.
I wonder if we should take a stance similar to the one FreeCAD has taken?
https://blog.freecad.org/2026/03/16/rules-regarding-ai-generated-patches/
This would be a starting point that would likely need to be expanded upon
to fit our specific workflow and standards.
I do think AI can be a useful tool in the toolbox. It can be valuable when
used appropriately by experienced developers. However, in its current
state, it is also capable of producing code that is superficially plausible
but fundamentally incorrect, incomplete, or misaligned with the project.
When the person who submits it fades back into the bushes, it becomes even
harder to maintain.
At a minimum, I think any contribution should meet our standards, be
maintainable, and be fully understood by the person submitting it.
Contributions that don't meet those standards should not be merged.
-Greg
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
