JS8Call-improved
Replies: 13 comments 11 replies
|
If it looks suspicious, reject it or ask for further review. I've also seen a couple lately that were "co-authored" by claud. I'm not sure who or what claud is, but it sounds like AI to me. |
|
The correct name is Claude. https://claude.ai |
|
Ok, Claude. Let's just say if I see anything from Claude I'll be highly skeptical of it :-) |
|
Standards? Y'all let me work on it; ergo, your standards are low, just so very, very low.... |
|
So far, I've found Claude Code and ChatGPT to be below my coding skill in C++, and that's saying even more! 🙄 |
|
Well, I guess we didn't claim to have high standards. Just. Standards. One of those could be - please don't add more stuff to mainwindow.cpp. It took me a couple days to strip 8,000 lines of code out of that thing. |
|
You should have seen what it started with.... |
|
Well, now we got Subspace mode evidently created by AI. Maybe the Romulans or Star Fleet Command come in on this, I'm not sure. |
|
I have to say I like how the wfview software for Icom and certain Kenwood radios displays the build hash and who built it in the About dialog. I might add that to the About for JS8Call too. wfview is a more modern replacement for Flrig, but at present only supports a limited number of rigs. I built this version on Qt 6.10.2 
|
|
I'm totally ok with that. Helps keep track of PR builds as well. |
|
It also displays the version of Qt that was used to build it. This is dynamically generated at build time. I'll have to look at the wfview source code to see how they did that. I made a few modifications to the wfview code to build it on SDK 26 with hardened runtime. I want to get this app running on iPad with JS8Call so I can use it to provide a network layer to connect to rigs over wireless like a FlexRadio does. 
|
|
@Chris-AC9KH If you can get the iPad version into TestFlight, I might be able to help you do some iPad testing. I don't have the latest and greatest iPad, but I do have current OS. |
All I got JS8Call to work with (so far) is FlexRadio on iPad using the SmartSDR iOS client for the audio transport layer. I've been working on it as I get time. But I did convert wfview's old qmake-configured build system to CMake, which allows me to use CMake's Xcode generator so I can configure a build for iPadOS now. Once I get that working decent then wfview can provide the audio transport layer over the network and it adds Icom and some Kenwood radios to the mix. So it's a spare time project. And realistically I need to port JS8Call to Swift because of the licensing issues with GPL code. |
|
Hi everyone, I'm jumping in as a full-stack developer with a strong background in C# and web applications. I've used AI in 2025 for code generation, and one thing I've learned is that the quality difference between free and commercial AI tools can be significant. AI-generated code often ends up bloated, with poor architecture, duplicated logic, or patterns that don't align with a clean, maintainable codebase. The key is treating AI as a helpful assistant rather than a full replacement for the developer. I get the best results when I clearly define the project's coding standards, architecture guidelines, and desired patterns upfront, then guide the AI iteratively instead of asking it to generate large sections from scratch. Looking forward to contributing in a way that respects the existing standards and helps keep the codebase clean. Happy to discuss further or help review AI-assisted PRs. David |
|
Hi @SaludaLabs good to meet you and hope to work with you! I don't personally have anything against AI tools, I've never used them myself. I've seen AI generated code that's pretty poor and we've had PR's submitted here using AI generated code that don't even work. So each one needs to be evaluated on a one-on-one basis and when I see something that's using a bunch of booleans to accomplish something, instead of an array, I have to question it as to why are we writing code like this? The developer that submitted the PR don't know why because some AI program wrote it and then we have a dead PR that can't be fixed. And I'm not going to take time to start re-writing PR's. |
|
TL;DR after several weeks working with Claude to implement a MIL-STD 188-110A data mode for the g90, no succesful transmit or receive has been done. I'm not a coder/developer, but my buddy has some experience with coding, and we're working on a project together building a data model based on MIL-STD 188-110A. Its all in python, using GNU radio, Qt, rigctl, and probably more things. After about a month of iteration on weekends, we do not have a functional program. This is all to say: AI alone is probably not ready to be used. A human who knows what they're doing should look at the outputs and know what's going on before pushing it out to a public project. I hope my insight is helpful, somehow. Thank you for working on JS8call, there are so many people who are very grateful! |
|
I find both Claude and Codex to be fantastic tools, but in my case, I use them for things that I'd find tedious to implement or to conduct experiments that I think would be worth pursuing, but would take too much time to conduct on my own only to find out that it was a blind alley. If I can compress 8 hours to find out that it was a bad idea into 10 minutes to find out that it was a bad idea, that's huge. I am, however, very experienced in both EE and CS, so they're like handing a carpenter a power saw instead of a hand saw, so they're, well, like power tools to me, but I think if you were to hand a power saw to someone who didn't know how to use a saw at all, it's probably not going to end well, you just get there faster. |
|
A good and accurate review of Claude Code.
Thanks Allan.
I've been using Claude code to build CommStat. It's an amazing tool!
https://commstat-improved.com/
…On Monday, April 13th, 2026 at 12:01 PM, Allan Bazinet ***@***.***> wrote:
I find both Claude and Codex to be fantastic tools, but in my case, I use them for things that I'd find tedious to implement or to conduct experiments that I think would be worth pursuing, but would take too much time to conduct on my own only to find out that it was a blind alley. If I can compress 8 hours to find out that it was a bad idea into 10 minutes to find out that it was a bad idea, that's huge.
I am, however, very experienced in both EE and CS, so they're like handing a carpenter a power saw instead of a hand saw, so they're, well, like power tools to me, but I think if you were to hand a power saw to someone who didn't know how to use a saw at all, it's probably not going to end well, you just get there faster.
—
Reply to this email directly, [view it on GitHub](#222 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ACDJQ7DKZR2B23TAL4MOQMD4VUFL7AVCNFSM6AAAAACWLDQCDOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNJUGYZTGNA).
You are receiving this because you commented.Message ID: ***@***.***>
|
|
There is no way that any maintainer should feel obliged to rewrite a single line of AI-generated code. The biggest risk to open-source projects from AI is that maintainers reject it on principle because it can take less time for the requester to generate the code than for the maintainer to review it. That needn't be the case though. If the requester is using a top frontier model and tooling, and willing to pay for enough tokens, they should be able to test their own code to the extent that it can be merged without objection. AI's not going anywhere: the fastest growing open-source project in history hit 250k GitHub stars, overtaking React's record in just 60 days. It's not an exemplar project (or I'd link to it) but Google reported last month that 75% of all new code at the company is AI-generated, and Microsoft put their figure at 20-30% a year ago. How we code isn't a deciding factor for the majority of software users. I think we need clear contribution guides on the tests that contributors using AI need to put their code through, and how to document that, prior to PR. I'd be happy to draft a markdown file that they could point their AI to. |
This is a key point, they need to test what they are doing. I won't reject on principle, but if it doesn't pass the smell test, or does obviously weird things, or the submitter won't respond to questions, those are red flags for me.
We've never setup a testing framework for JS8Call, although there was some discussion about it last year, but nobody really had time to work at it (although, as I recall, qtest seemed to be our best bet for what we could test).
Is this something like a llms.txt file? |
|
Yeah, I'm hoping we could make the smell test a little easier too, by having the PR author explicitly state what smoke tests they have run, what it compiles succesfully on, if it adds any new compiler warnings etc., and then what physical tests they ran. Something like qtest would be great, and we could certainly add that as stage 2. For now I'm thinking just an AGENTS.md. This sits at the repo root and gives specific instructions for a contributor's coding agent on how to build, what to test, and what conventions to follow, pointing at CONTRIBUTING.md rather than duplicating it. I imagine submitter responsiveness requirements should probably go in CONTRIBUTING.md but AGENTS.md could require that the agent ensures they are aware of them. An llms.txt file could be good too, but my understanding is that's more a docs-site index which answers "what is this project, where are its docs" for an LLM to efficiently learn about JS8Call, so it can answer questions. Conversely AGENTS.md is an add-on to CONTRIBUTING.md for agents working on PRs. If nobody objects I'll include an AGENTS.md with the proposed CONTRIBUTING.md relocation and doxygen PR. It would aim to replicate what I did with #361 - for example disclosing what models were used with what harness, what was tested, what wasn't tested and known issues (which should be maintained as a live list). Controversially it could prescribe use of an adversarial harness, where you have independent agents reviewing the spec and the code, etc. rather than one-shot, or letting the agent mark its own homework. More controversially (as it's likely more expensive) we could also request final review by an independent frontier model - #361 used Anthropic's Claude Models (Fable 5 lead with Opus 5 adversarial agents) but the PR was reviewed by Google's Gemini 3.1 Pro before I hit [Create pull request]. |
|
I'm leery of tech that thinks it's smart but isn't; but I'm willing to explore it. I queried on llms.txt because there was a recent news article about AI monkeying with stuff it should not via that file. For reference: GitHub blog on agents.md |
|
@SaludaLabs Might be able to help in this regard. |
|
One thing worth flagging on that blog post: it’s about Copilot’s custom agent personas, which live in .github/agents/*.md, rather than the single root-level AGENTS.md I’m proposing. November 2025 was 3 generations ago in AI terms, but his "Hitting these areas puts you in the top tier: commands, testing, project structure, code style, git workflow, and boundaries." is still excellent, even if we need to decide which components of those belong in AGENTS.md and which would be better in CONTRIBUTING.md. |
Uh oh!
There was an error while loading. Please reload this page.
This discussion is primarily about how we want to handle PRs containing AI generated code.
We have had a few PRs show up lately that seem to be either partially or wholly created by AI that do not hold to various standards that we have on the codebase. What, if anything, should we do?
All reactions